TIL

Service

• 공식 문서 - Service
• 클러스터 안에서 변동하는 Pod 집합을 안정적으로 노출하는 네트워크 추상화
• 같은 Pod 라벨을 가진 그룹에 대한 단일 진입점(VIP)을 제공하고 트래픽을 분배
• Deployment에서 만든 Pod들을 실제로 호출 가능한 대상으로 만들어주는 다음 단계

Service가 필요한 이유

• Pod는 수명이 짧고 IP가 변한다
  • Deployment가 desired state를 맞추는 과정에서 Pod가 만들어지고 사라짐
  • 같은 이름이라도 재생성되면 IP가 달라짐
  • 클라이언트가 직접 Pod IP로 접근하면 매번 끊기고 재발견해야 함
• Service가 그 사이에서 다음을 추상화
  • 고정 엔드포인트 — 클러스터 내부 가상 IP(ClusterIP)는 Pod가 바뀌어도 유지됨
  • 로드밸런싱 — 매칭되는 Pod들 사이로 트래픽을 분배
  • 서비스 디스커버리 — Pod IP를 몰라도 Service 이름으로 접근
  • 디커플링 — 클라이언트는 “어떤 Pod”가 아니라 “어떤 Service”에 의존
• 예: 이미지 처리 backend가 3개 replica로 떠 있을 때, frontend는 backend Pod 목록을 추적하지 않고 backend Service만 호출

Service 정의

• 핵심은 selector로 Pod를 묶고, ports로 노출 규칙을 선언하는 것

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    selector:
      app.kubernetes.io/name: MyApp   # 이 라벨을 가진 Pod 모두를 이 Service로 묶음
    ports:
      - protocol: TCP
        port: 80                      # Service가 노출하는 포트 (클라이언트 접속 대상)
        targetPort: 9376              # Pod 컨테이너가 listen 중인 포트
  

spec.selector

• Service가 트래픽을 보낼 Pod를 식별하는 라벨 셀렉터
• selector가 있으면 쿠버네티스가 매칭되는 Pod로 EndpointSlice를 자동 생성·갱신
• 라벨 매칭 결과가 비면 트래픽 받을 대상이 없는 Service가 됨 (정상 동작이지만 사실상 죽은 상태)

spec.ports — port vs targetPort

• port — Service 자체가 노출하는 포트. 클라이언트가 접속하는 포트 (ClusterIP가 listen)
• targetPort — Pod 컨테이너가 listen 중인 포트
• 둘은 같지 않아도 된다 — 외부 인터페이스(port)와 내부 구현(targetPort)을 분리할 수 있음
• targetPort는 숫자 대신 컨테이너의 포트 이름을 써도 됨 (Pod의 containers.ports.name 참조)

protocol과 appProtocol

• protocol (기본 TCP) — TCP / UDP / SCTP 중 하나
• appProtocol (선택) — 애플리케이션 레벨 프로토콜 힌트 (HTTP, HTTPS, gRPC 등)
  • Ingress 컨트롤러나 Service Mesh가 라우팅·관측에 활용

Multi-port Service

• 하나의 Service로 여러 포트를 동시에 노출 가능
• 각 포트마다 name이 반드시 있어야 한다 (단일 포트일 땐 생략 가능) ```yaml spec: selector: app.kubernetes.io/name: MyApp ports:
  • name: http # multi-port에서는 name 필수 protocol: TCP port: 80 targetPort: 8080
  • name: https protocol: TCP port: 443 targetPort: 8443
  • name: dns protocol: UDP port: 53 targetPort: 5353 ```
• 같은 Pod의 다른 포트(예: 메트릭, gRPC, HTTP)를 한 Service로 묶을 때 자주 사용

Selector 없는 Service

• selector를 지정하지 않으면 쿠버네티스가 EndpointSlice를 자동 생성하지 않음
• 사용자가 EndpointSlice를 직접 만들어 Service의 백엔드 주소를 지정
• 활용 사례
  • 클러스터 외부 서비스(레거시 DB·외부 API)를 Service 이름으로 호출하고 싶을 때
  • 다른 네임스페이스의 Service로 우회 라우팅
  • 마이그레이션 중 외부와 내부를 동시에 가리키는 추상 엔드포인트가 필요할 때
• 정의 예 ```yaml

  Service — selector 없음

  apiVersion: v1 kind: Service metadata: name: my-service spec: ports: - protocol: TCP port: 80 targetPort: 9376 —

  사용자가 직접 만드는 EndpointSlice

  apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: my-service-1 labels: kubernetes.io/service-name: my-service # 어떤 Service에 붙는지 지정 addressType: IPv4 ports:

  • name: “” port: 9376 endpoints:
  • addresses: [“10.1.2.3”] # 외부 서버 IP 등 ```
• 핵심 제약 — EndpointSlice의 kubernetes.io/service-name 라벨이 Service 이름과 일치해야 연결됨
• 백엔드가 바뀌면 사용자가 직접 EndpointSlice를 갱신해야 한다

EndpointSlice 메커니즘

• Service가 트래픽을 흘려보낼 실제 백엔드 주소들의 목록을 담는 오브젝트
• apiVersion: discovery.k8s.io/v1
• 동작 흐름
  1. Service에 selector가 있으면 쿠버네티스가 매칭 Pod로 EndpointSlice를 자동 생성
  2. Pod가 추가·삭제되면 EndpointSlice를 자동 갱신
  3. 각 노드의 kube-proxy가 EndpointSlice를 watch하고 iptables·IPVS 같은 네트워크 규칙을 갱신
  4. 결과적으로 ClusterIP로 들어온 트래픽이 살아 있는 Pod로 분배됨
• 슬라이스 단위로 분할 — 슬라이스 하나당 약 100개 엔드포인트
  • 큰 클러스터에서도 watch 부하·etcd 부하를 분산할 수 있음
• 이전의 Endpoints 오브젝트(단일 객체에 모든 백엔드 저장)를 대체하기 위해 도입 — 대규모 클러스터에서 확장성을 확보

서비스 디스커버리(Service Discovery)

• Pod가 Service에 도달하는 방법은 크게 두 가지 — 환경 변수와 DNS
• 실무에서는 거의 항상 DNS 방식을 사용하고, 환경 변수 방식은 한계 때문에 보조적
• 어떤 방식을 쓰든 클라이언트는 Pod IP가 아니라 Service 이름/ClusterIP로만 접근

환경 변수(Environment Variables) 방식

• kubelet이 Pod를 띄울 때, 그 시점에 이미 존재하는 Service들에 대해 환경 변수를 자동 주입
• 이름 규칙은 Service 이름을 대문자·언더스코어로 변환한 형태
  • ex) Service 이름 redis-primary → REDIS_PRIMARY_SERVICE_HOST, REDIS_PRIMARY_SERVICE_PORT
• 동시에 도커 호환 변수도 함께 주입 — REDIS_PRIMARY_PORT, REDIS_PRIMARY_PORT_6379_TCP 등
• 순서 의존성이 결정적인 한계
  • Pod가 생성되기 전에 Service가 존재해야 환경 변수가 주입됨
  • Pod 기동 후 새로 만들어진 Service는 그 Pod의 환경 변수에 반영되지 않음
  • 따라서 디플로이 순서가 꼬이면 클라이언트가 backend를 못 찾는 문제가 생김
• 대안이 DNS이며, DNS는 런타임에 조회되므로 순서에 영향을 받지 않음

DNS 방식

• 클러스터에 CoreDNS(애드온)가 떠 있으면, 모든 Service는 자동으로 DNS 이름을 갖는다
• Pod의 /etc/resolv.conf가 CoreDNS를 가리키도록 kubelet이 설정 → Service 이름 조회 가능
• FQDN 형식 — <service-name>.<namespace>.svc.<cluster-domain>
  • ex) 기본 도메인이 cluster.local이면 my-service.my-ns.svc.cluster.local
• 같은 네임스페이스에서는 짧은 이름으로도 접근 — my-service만 써도 됨
  • search 도메인이 자동 설정되어 있어 my-service → my-service.<my-ns>.svc.cluster.local 순으로 조회
• 다른 네임스페이스에서는 my-service.other-ns처럼 네임스페이스까지 명시
• Service 종류별 레코드
  • 일반 Service — Service 이름을 ClusterIP로 해석하는 A/AAAA 레코드 1개
  • Headless Service — Pod IP들을 직접 가리키는 A/AAAA 레코드 여러 개
  • Named port — _<port-name>._<protocol>.<service> 형태의 SRV 레코드 제공
    • ex) _http._tcp.my-service.my-ns.svc.cluster.local

CoreDNS가 없는 클러스터에서는 DNS 디스커버리 자체가 동작하지 않음 — 사실상 모든 표준 클러스터는 CoreDNS를 기본 탑재.

Headless Service

• spec.clusterIP: None으로 지정한 Service — VIP(ClusterIP)를 할당하지 않는 Service
• 로드밸런싱이나 단일 진입점이 필요 없을 때, Pod들의 실제 주소를 그대로 노출하기 위해 사용
• 정의 예

  apiVersion: v1
  kind: Service
  metadata:
    name: my-headless
  spec:
    clusterIP: None          # Headless로 만드는 핵심 필드
    selector:
      app.kubernetes.io/name: MyApp
    ports:
      - port: 80
        targetPort: 9376
  

• 일반 Service와의 차이
  • ClusterIP 없음 — kube-proxy가 트래픽을 분배하지 않음, iptables 규칙도 만들지 않음
  • DNS 응답이 다름 — Service 이름을 조회하면 단일 VIP가 아니라 매칭된 Pod IP 목록이 반환됨
  • 클라이언트가 직접 어떤 Pod로 갈지 결정하거나, 클라이언트 측 로드밸런싱을 적용
• selector 유무에 따른 동작
  • selector 있음 — 매칭 Pod로 EndpointSlice가 자동 생성, 각 Pod IP에 대한 A 레코드 발행
  • selector 없음 — 사용자가 만든 EndpointSlice의 주소들을 그대로 DNS로 노출 (또는 ExternalName CNAME으로 위임)

언제 Headless를 쓰는가

• Stateful한 워크로드 — Pod 각각이 고유 신원(IP·이름)을 가져야 할 때
  • ex) Cassandra, Kafka, Zookeeper처럼 노드끼리 직접 통신하는 클러스터드 시스템
• 클라이언트 측 로드밸런싱 — gRPC처럼 connection 단위로 LB가 잘 동작하지 않는 프로토콜
  • 클라이언트가 Pod IP 목록을 직접 받아 자체적으로 분산
• 서비스 디스커버리만 필요할 때 — VIP를 통한 트래픽 라우팅은 필요 없고, 멤버 목록만 알고 싶을 때

StatefulSet과의 관계

• StatefulSet은 거의 항상 Headless Service와 짝으로 사용
• StatefulSet의 spec.serviceName이 Headless Service를 가리키면, 각 Pod에 대해 안정적인 DNS 이름이 생성됨
  • 형식 — <pod-name>.<service-name>.<namespace>.svc.<cluster-domain>
  • ex) web-0.nginx.default.svc.cluster.local, web-1.nginx.default.svc.cluster.local
• Pod가 재생성되어 IP가 바뀌어도 Pod 이름 기반의 DNS는 그대로 유지됨
  • 분산 시스템의 멤버십·리더 선출·복제 토폴로지에 안정적인 식별자를 제공

Service 타입

• spec.type 필드로 어디서·어떻게 접근할 수 있는지를 결정
• 4가지 타입 — ClusterIP(기본) / NodePort / LoadBalancer / ExternalName
• 위로 갈수록 노출 범위가 넓어지고, 상위 타입은 하위 타입의 기능을 포함
  • LoadBalancer → 내부적으로 NodePort + ClusterIP도 함께 가짐
  • NodePort → 내부적으로 ClusterIP도 함께 가짐

ClusterIP (기본)

• 클러스터 내부 전용 가상 IP만 부여
• 외부에서는 직접 접근 불가 — 다른 Pod·Service만 호출 가능
• spec.type을 생략하면 ClusterIP

  spec:
    type: ClusterIP
    selector:
      app: my-app
    ports:
      - port: 80
        targetPort: 8080
  

• 가장 일반적인 마이크로서비스 간 통신용 — backend Service를 frontend가 호출하는 구조
• spec.clusterIP: None으로 두면 위 Headless Service가 됨 (VIP 미할당)

NodePort

• 클러스터의 모든 Node에서 동일한 포트(nodePort)를 열어 외부에 노출
• 외부 트래픽 흐름 — NodeIP:NodePort → ClusterIP:port → Pod:targetPort
• 자동으로 ClusterIP도 함께 부여됨 (내부 호출도 가능)

  spec:
    type: NodePort
    selector:
      app: my-app
    ports:
      - port: 80           # ClusterIP가 노출하는 포트
        targetPort: 8080   # Pod 컨테이너 포트
        nodePort: 30007    # 모든 Node에서 열리는 포트 (기본 30000-32767)
  

• nodePort를 생략하면 30000-32767 범위에서 자동 할당
• 한계
  • 외부 클라이언트가 Node IP를 알아야 접근 가능 (Node 추가·교체 시 재구성 필요)
  • 클라우드 LB나 DNS 없이 단독으로는 운영 환경에 부적합
• 주 사용처 — 개발·테스트, 자체 LB 앞단에 둘 때, on-prem에서 외부 LB 없이 접근

LoadBalancer

• 클라우드 프로바이더의 외부 로드밸런서를 자동 프로비저닝해 트래픽을 Service로 전달
• 내부적으로 NodePort + ClusterIP도 함께 만들어짐 — LB가 모든 Node의 NodePort로 분산
• 클라우드별로 무엇이 만들어지는지 다름
  • GKE — 기본은 GCP L4 Network Load Balancer
  • EKS — AWS NLB / CLB
  • AKS — Azure Load Balancer
• 외부에서 받은 IP는 status.loadBalancer.ingress에 채워짐

  spec:
    type: LoadBalancer
    selector:
      app: my-app
    ports:
      - port: 80
        targetPort: 8080
  

• 주요 옵션
  • loadBalancerClass — 기본 클라우드 LB 대신 특정 구현체(Class)를 명시적으로 선택
  • loadBalancerSourceRanges — LB로 들어오는 트래픽을 특정 CIDR로만 제한
  • externalTrafficPolicy — Cluster(기본, Node 간 재라우팅 가능) vs Local(요청 받은 Node의 Pod로만, 클라이언트 IP 보존)
  • allocateLoadBalancerNodePorts — false로 두면 NodePort를 만들지 않음 (LB가 직접 Pod IP로 가는 경우 비용 절감)
• L4 LB라는 점에 주의 — HTTP 라우팅·TLS 종료·경로 기반 분기는 Ingress / Gateway에서 처리

ExternalName

• selector도 endpoint도 없음 — 트래픽을 받지 않고 DNS CNAME만 반환하는 Service
• 클러스터 내부에서 my-service 이름으로 호출하면 외부 도메인으로 리졸브됨

  spec:
    type: ExternalName
    externalName: my.database.example.com   # CNAME 대상
  

• 사용처 — 외부 DB·외부 API를 클러스터 내부 이름으로 추상화, 마이그레이션 중 외부 → 내부 전환 지점
• 주의
  • L4·L7 프록시가 아니라 순수 DNS 응답 — TLS 종료·헤더 변경 같은 가공이 일어나지 않음
  • HTTP 클라이언트가 Host 헤더를 그대로 보내므로 상대편 서버가 SNI·Host 매칭에 의존하면 깨질 수 있음

타입 비교 요약

타입	외부 노출	부여되는 IP	주 사용처	비고
ClusterIP	❌ (내부 전용)	ClusterIP	마이크로서비스 간 통신	기본값
NodePort	⭕ (Node IP:Port)	ClusterIP + Node:Port	개발·테스트, 자체 LB 앞단	운영 단독 사용은 부적합
LoadBalancer	⭕ (외부 LB IP)	ClusterIP + NodePort + LB IP	클라우드 환경 외부 노출	L4, 클라우드 LB 자동 프로비저닝
ExternalName	—	없음 (CNAME)	외부 서비스 내부 이름화	DNS만, 트래픽 통과 X

Virtual IP와 kube-proxy

• ClusterIP는 실제 네트워크 인터페이스에 붙어 있지 않은 가상 IP(VIP) — 어떤 Node에도 그 IP를 가진 NIC는 없음
• 그런데도 Pod에서 ClusterIP로 패킷을 보내면 매칭되는 Pod로 전달되는 이유 = 각 Node의 kube-proxy가 커널 레벨에서 트래픽을 가로채 실제 Pod IP로 DNAT
• 동작 흐름
  1. kube-proxy가 모든 Service·EndpointSlice를 watch
  2. Service가 추가·변경되면 자기 Node의 커널 규칙(iptables / IPVS / nftables)을 갱신
  3. Pod에서 ClusterIP:port로 패킷이 나가면 그 규칙이 매칭되어 살아 있는 Pod IP 중 하나로 DNAT
  4. 응답은 conntrack 기반으로 원래 클라이언트 Pod로 돌아감
• 핵심 — kube-proxy는 트래픽을 직접 처리하지 않는다. 커널 규칙만 설치하고 빠지며, 실제 패킷은 커널 데이터플레인이 처리

kube-proxy 모드

• 커널에 어떤 방식으로 규칙을 설치하느냐에 따라 모드가 갈림
• 모드는 노드별로 설정 (kube-proxy --proxy-mode=...) — 같은 클러스터에서 노드마다 다를 수도 있음

모드	데이터플레인	특징	비고
iptables	netfilter (iptables)	기본값, 가장 널리 사용	Service·Pod 수가 늘면 규칙 수 선형 증가 → 동기화·매칭 비용 ↑
ipvs	IPVS (Linux 커널 LB)	해시 테이블 기반, 대규모 클러스터에 유리	RR·LC·SH 등 다양한 LB 알고리즘 선택 가능
nftables	nftables	iptables의 후속, GA로 진입 중	매칭 속도·확장성에서 iptables보다 개선
userspace	(deprecated)	초기 모드, 사용자 공간에서 직접 프록시	성능 문제로 더 이상 권장되지 않음

• 일반적인 선택 — 중·소 규모는 iptables 기본, 수천~수만 Service 규모면 ipvs 또는 nftables 검토
• userspace 모드만 진짜 프록시처럼 동작했고, iptables/IPVS/nftables는 모두 커널이 직접 라우팅 → kube-proxy 자체는 패킷 경로에 없음

Traffic Policy

• 외부·내부 트래픽이 들어왔을 때 어느 Node의 Pod로 보낼지를 제어
• 두 가지 필드 — externalTrafficPolicy(외부에서 들어온 트래픽), internalTrafficPolicy(클러스터 내부에서 들어온 트래픽)

externalTrafficPolicy

• NodePort·LoadBalancer 타입에서 의미 있음
• Cluster (기본값)
  • 트래픽이 어느 Node로 들어와도 클러스터 전체의 Pod 중 하나로 분배 (Node 간 재라우팅 가능)
  • 장점 — 부하 분산이 균등
  • 단점 — Node 간 SNAT가 일어나 클라이언트 IP가 보존되지 않음, 추가 hop 비용
• Local
  • 트래픽이 들어온 그 Node의 Pod만 후보로 사용 (해당 Node에 Pod가 없으면 패킷 drop)
  • 장점 — SNAT 없음 → 클라이언트 IP 보존, 한 hop으로 처리
  • 단점 — Pod 분포가 불균형하면 부하가 한쪽으로 쏠릴 수 있음
  • LB는 보통 healthCheck로 “Pod 있는 Node”만 골라 트래픽을 보내도록 자동 설정

internalTrafficPolicy

• 클러스터 내부 Pod에서 Service로 호출할 때 적용
• Cluster (기본값) — 클러스터 전체 Pod 중에서 분배
• Local — 호출하는 Pod와 같은 Node의 Pod만 후보. 같은 Node에 Pod가 없으면 호출 실패
• 사용처 — node-local 캐시·로깅 에이전트처럼 반드시 같은 Node에서 처리해야 하는 사이드카 패턴
• 주의 — 분포가 깨지면 호출이 실패하므로 DaemonSet과 짝지어 쓰는 게 일반적

spec:
  type: LoadBalancer
  externalTrafficPolicy: Local       # 외부에서 들어온 트래픽은 같은 Node Pod로만
  internalTrafficPolicy: Cluster     # 내부 호출은 클러스터 전체에서 분배
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 8080

Session Affinity

• 기본적으로 Service는 매 요청마다 백엔드 Pod를 임의로 선택 (kube-proxy/IPVS 알고리즘에 따름)
• 같은 클라이언트가 같은 Pod로 가야 한다면 sessionAffinity 사용

  spec:
    selector:
      app: my-app
    ports:
      - port: 80
        targetPort: 8080
    sessionAffinity: ClientIP             # 클라이언트 IP 기반 sticky
    sessionAffinityConfig:
      clientIP:
        timeoutSeconds: 10800             # 기본 3시간 (10800초)
  

• 옵션
  • None (기본) — affinity 없음, 매번 다른 Pod로 갈 수 있음
  • ClientIP — 같은 클라이언트 IP에서 온 요청은 일정 시간 동안 같은 Pod로 라우팅
• 동작 원리 — kube-proxy가 클라이언트 IP를 키로 conntrack에 기록하고 timeout 동안 유지
• 한계
  • 쿠키 기반 sticky session은 지원하지 않음 — HTTP 레벨 sticky가 필요하면 Ingress·Gateway·Service Mesh에서 처리
  • 클라이언트들이 같은 NAT/프록시 뒤에 있으면 IP가 같아 보여서 한 Pod로 몰림 (모바일·기업 네트워크 환경)
  • externalTrafficPolicy: Local처럼 Node 단위 라우팅과 결합되면 affinity 보장이 깨질 수 있음
• 운영 환경에서 진짜 sticky가 필요하면 보통 L7(Ingress·Gateway)에서 cookie 기반으로 처리하는 게 정석