📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code 멀티 에이전트 — Teams
    • 멀티모달 LLM (Multimodal Large Language Model)
  • architecture 페이지로 이동
    • 캐시 설계 전략 총정리
    • 디자인 패턴
    • 분산 트랜잭션
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 지원 문항
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • the-future-company 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
🚀devops/ k8s

Service와 Ingress

약 3분
2026년 1월 30일
GitHub에서 보기

Service와 Ingress

  • Deployment가 서버를 띄우고 관리하는 것이라면, Service와 Ingress는 "그 서버로 가는 길을 뚫어주는 것(Networking)"이다.
  • 딱 한 문장으로 정의하고 시작하면 이해가 빠를 것이다.

Pod는 변수(Variable)고, Service는 상수(Constants)이다.

1. Service (서비스): 변하지 않는 연락처 (L4)

왜 필요한가?

Pod는 일회용이다. 배포할 떄마다 죽고 새로 태어나며, 그때마다 IP 주소가 바뀐다.
프론트엔드나 다른 MSA 서비스가 자꾸 바뀌는 IP를 추적해서 호출할 수는 없다.

해결책: Service

Pod 앞단에 **고정된 IP(Cluster IP)**와 **고정된 도메인 이름(DNS)**을 부여하는 내부 로드밸런서이다.

  • 동작 방식: 내 뒤에 있는 Pod들(Selector)에게 트래픽을 Round Robin으로 뿌려줘
  • 개발자 비유:
    • Pod IP: 개발자 개인 내선 번호
    • Service: 개발팀 대표 번호
  • 특징:
    • Service Discovery: K8s 내부에서는 IP 대신 http://api 처럼 서비스 이름만으로 통신할 수 있다.
      • 내부 DNS가 api -> 10.96.0.1로 해석해준다.

YAML로 확인하기

가장 중요한 건 selector 이다. 이게 Deployment의 라벨과 일치해야 연결된다.

apiVersion: v1
kind: Service
metadata:
  name: api-service # 내부에서 부를 이름 (DNS)
spec:
  type: ClusterIP # 내부 전용
  selector:
    app: api # (중요) 이 라벨을 가진 Pod들로 트래픽을 보냄
  ports:
    - protocol: TCP
      port: 80 # 서비스의 포트
      targetPort: 8080 # Pod의 포트

2. Ingress(인그레스): 외부로 통하는 대문 (L7)

왜 필요한가?

Service는 기본적으로 K8s 클러스터 내부에서만 접근 가능하다. (보안상 안전)
하지만 외부 사용자는 우리 API를 호출해야 한다. 게다가 도메인도 연결해야 하고, HTTPS 인증서도 붙여야 한다.

해결책: Ingress

외부에서 들어오는 HTTP(S) 트래픽을 규칙에 따라 적절한 Service로 라우팅해주는 L7 리버스 프록시 설정이다.

  • 구성 요소:
    • Ingress (주문서): my-service.com/api는 api 서비스로 보내줘라고 적힌 YAML.
    • Ingress Controller (실행자): 실제 Nginx 서버(Pod). 주문서(Ingress YAML)를 읽어서 `nginx.conf₩를 동적으로 고치고 트래픽을 처리한다.
  • 개발자 비유:
    • Service: 각 부서의 안내 데스크
    • Ingress: 건물 1층의 통합 로비 & 보안 게이트
  • 기능:
    • 도메인 기반 라우팅
    • 경로(Path) 기반 라우팅 (/api, /admin)
    • SSL/TLS 종료

YAML로 확인하기

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: `api-ingress`
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: / # Ngnix 세부 설정
spec:
  rules:
  - host: my-service.com # 1. 이 도메인으로 들어오면
    http:
      paths:
        - path: /api # 2. 그리고 /api 경로로 들어오면
          pathType: Prefix
          backend:
            service:
              name: api-service # 3. 이 서비스로 보내라
              port:
                number: 80

3. 전체 흐름도: 트래픽은 어떻게 흐르는가?

이제 Deployment, Service, Ingress가 합쳐졌을 떄, 사용자의 요청이 Spring Boot까지 도달하는 여정이다.

  • 1. User Request: 사용자가 브라우저에;서 https://my-service.com/api/v1/hello 호출
  • 2. Ingress (Nginx):
    • 도메인과 경로를 확인한다.
    • 설정된 규칙에 따라 api-service를 찾는다.
  • 3. Service:
    • api-service는 자신의 목록(Endpoints)에 살아있는 Pod IP 중 하나를 선택한다.
  • 4. Pod(Spring Boot):
    • 최종적으로 요청을 받아 처리하고 응답한다.
devops 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • Service와 Ingress
  • 1. Service (서비스): 변하지 않는 연락처 (L4)
  • 왜 필요한가?
  • 해결책: Service
  • YAML로 확인하기
  • 2. Ingress(인그레스): 외부로 통하는 대문 (L7)
  • 왜 필요한가?
  • 해결책: Ingress
  • YAML로 확인하기
  • 3. 전체 흐름도: 트래픽은 어떻게 흐르는가?