Kubernetes 기본 요소

Pod

Kubernetes의 가장 작은 배포 단위입니다.

• 여러 개의 Container를 포함할 수 있습니다.
• 같은 Pod의 Container는 Network와 Volume을 공유할 수 있습니다.

Probe는 Container가 시작되었는지, Traffic을 받을 수 있는지, 재시작이 필요한지를 각각 확인합니다.

• startupProbe: 초기화가 끝났는지 확인합니다. 성공하기 전에는 다른 Probe를 시작하지 않습니다.
• readinessProbe: 지금 Traffic을 받을 수 있는지 확인합니다. 실패하면 Service에서 제외하지만 재시작하지 않습니다.
• livenessProbe: 재시작해야만 복구되는 고장인지 확인합니다. 실패하면 Container를 재시작합니다.

containers:
  - name: app
    image: example/app
    startupProbe:
      httpGet:
        path: /health/startup
        port: 8080
      periodSeconds: 5
      failureThreshold: 30
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080

• Startup의 허용 시간은 최악의 정상 초기화 시간보다 길어야 합니다.
• Readiness는 해당 Pod로 Traffic을 보내지 않는 편이 나을 때만 실패시킵니다.
• Liveness에 DB나 외부 API처럼 재시작으로 해결되지 않는 상태를 넣으면 여러 Pod가 함께 재시작하며 장애를 키울 수 있습니다.

ReplicaSet

Pod를 정해진 개수만큼 관리하는 리소스입니다.

• 계속 현재 상태를 확인하여 Pod 개수를 조건에 맞게 조정합니다.
• 단독으로 쓰는 경우는 거의 없고, 보통 Deployment를 통해 사용합니다.

Deployment

ReplicaSet을 관리하고 추가 기능을 제공하는 상위 리소스입니다.

• Pod를 업데이트하거나 이전 버전으로 되돌릴 수 있습니다.
• 기본 RollingUpdate 방식에서는 새 ReplicaSet을 만들고, 새 Pod를 늘리면서 기존 Pod를 줄입니다.

StatefulSet

Deployment와 비슷하게 Pod를 관리하지만, 각 Pod에 바뀌지 않는 이름과 번호를 부여합니다. Pod가 다시 만들어져도 name-0, name-1 같은 이름을 유지하므로, Pod마다 역할이 다른 Database나 분산 시스템에 적합합니다.

• 기본 OrderedReady 방식에서는 Pod를 번호순으로 만들고 역순으로 줄입니다. Parallel을 사용하면 이 순서를 보장하지 않습니다.
• 바뀌지 않는 DNS 이름을 사용하려면 Headless Service가 필요합니다.
• volumeClaimTemplates로 Pod마다 PVC를 만들 수 있습니다. StatefulSet을 줄이거나 삭제해도 PVC는 기본적으로 남습니다.
• 고정된 이름과 실행 순서만으로 작업이 한 번만 실행된다고 보장할 수는 없습니다. 그런 보장이 필요하면 Leader election과 중복 실행을 견디는 처리를 따로 구현해야 합니다.

Job

일회성 작업을 실행하는 리소스입니다.

• Pod를 만들어 작업을 수행하고, 완료되면 종료합니다.
• 동시에 실행할 Pod 수와 실패 시 재시도 횟수를 설정할 수 있습니다.
• 같은 작업이 두 번 시작될 수 있으므로, 가능하면 중복 실행되어도 결과가 달라지지 않게 만듭니다.

CronJob

Job을 주기적으로 실행하는 리소스입니다.

• cron 표현식으로 실행 시간을 정합니다.
• 드물게 실행이 빠지거나 두 번 생성될 수 있으므로, 중복 실행되어도 안전한 작업으로 만듭니다.
• concurrencyPolicy로 이전 작업이 끝나지 않았을 때 새 작업을 실행할지 정합니다.
• startingDeadlineSeconds로 늦어진 작업을 언제까지 실행할지 정합니다.
• Schedule 변경은 앞으로 생성될 Job에만 적용되며, 이미 생성된 Job은 바뀌지 않습니다.

Service

Pod를 Network에 노출하는 리소스입니다.

Pod는 다시 만들어질 때 IP가 바뀔 수 있습니다. Service는 변하는 Pod들을 하나의 고정된 주소와 DNS 이름으로 묶어, 사용하는 쪽에서 개별 Pod의 주소를 알 필요가 없게 합니다.

Selector와 일치하는 Pod는 Service의 Endpoint에 자동으로 반영됩니다. 기본 ClusterIP Service는 Cluster 안에서만 접근할 수 있습니다.

Node

Cluster를 구성하는 물리 서버 또는 VM입니다.

Pod가 실제로 실행되는 곳이며, kubelet과 Container runtime이 동작합니다. Network 구성에 따라 kube-proxy 또는 이를 대신하는 도구도 실행됩니다.

Control plane Node는 Cluster를 관리하고, Worker Node는 주로 Application을 실행합니다. 다만 둘은 완전히 다른 종류의 Node가 아니라, 설치된 Component와 Scheduling 설정에 따라 나뉘는 역할입니다.

Service Mesh

Service Mesh는 각 Service 앞의 Proxy가 Service 간 Traffic을 대신 처리하는 구조입니다. Application마다 같은 통신 기능을 따로 구현하지 않고, Cluster 전체에 일관된 Traffic·보안 정책과 관측 기능을 적용할 수 있습니다.

기능	역할
L7 Traffic 관리	요청 단위 Load balancing, Retry, Timeout
mTLS	Service 간 인증과 통신 암호화
관측	Metric, Trace, Log 수집
접근 제어	Service 간 호출 권한 관리

gRPC Load balancing은 Service Mesh가 해결할 수 있는 대표적인 문제입니다. Kubernetes Service는 보통 IP 주소와 Port를 기준으로 연결을 Pod에 나눠 줍니다. 하지만 gRPC가 사용하는 HTTP/2는 하나의 연결로 여러 요청을 계속 보내므로, 처음 선택된 Pod에 요청이 몰릴 수 있습니다. Service Mesh는 gRPC 요청을 이해하고 요청 단위로 여러 Pod에 나눌 수 있습니다.

다만 gRPC 분산만 필요하다면 Headless Service와 Client-side load balancing 또는 L7 Proxy로도 해결할 수 있습니다. 여러 Service에 mTLS, Traffic 정책, 관측, 접근 제어까지 함께 적용할 때 Service Mesh의 가치가 커집니다. 그 대신 운영할 Component와 Resource 사용량도 늘어납니다.

대표적인 구현으로 Istio와 Linkerd가 있습니다.

참고 자료

• Pods
• Configure Liveness, Readiness and Startup Probes
• Workload Management
• Service
• Nodes
• 쿠버네티스에서 어려움 없이 gRPC 로드밸런싱하기
• Istio Traffic Management