Kubernetes 기본 요소

개인적으로 개념을 더 명확하게 하기 위해 정리합니다.

Pod

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

• 여러 개의 컨테이너를 포함할 수도 있습니다.
  • 그룹화된 컨테이너들은 로컬 통신이 가능합니다.
• Probe를 설정하여 Pod의 상태를 체크할 수 있습니다.
  • readinessProbe는 컨테이너의 상태를 체크하고, 정상이 아니라면 해당 Pod로 요청이 들어오지 않도록 합니다.
  • livenessProbe는 컨테이너의 상태를 체크하여 정상이 아니라면 재기동시킵니다.
    계속 재시작해도 문제가 해결되지 않을 경우 CrashLoopBackOff 상태가 됩니다.

ReplicaSet

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

• 지속적으로 현재 상태를 체크하여 Pod 개수가 조건에 맞도록 조정합니다.
• 단독으로 쓰이는 경우는 거의 없고, 보통 Deployment를 통해 사용합니다.

Deployment

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

• Pod를 업데이트하거나 롤백할 수 있습니다.
  • 기본적인 RollingUpdate 정책의 경우 새로운 ReplicaSet을 만들고, 새로운 Pod가 생성될 때마다 기존 ReplicaSet을 조정합니다.
  • 변경 히스토리를 기록하고, 기록된 히스토리를 적용할 수도 있습니다.

Service

Pod를 네트워크에 노출시키는 추상화된 객체입니다.

기본적으로 Pod는 고유한 내부 IP 주소를 가지고 있습니다. 하지만 Pod는 항상 변동 가능성이 있고 매번 내부 IP가 바뀔 수 있기 때문에 이를 통한 통신을 권장하지 않습니다.
Port forwarding도 가능하지만 역시 임시방편인 경우가 많습니다.

Service는 고정된 IP를 통해 이러한 Pod에 접근할 수 있도록 합니다.

Service에는 또한 여러 타입이 존재하는데, 여기서 설명하지는 않겠습니다. (참고)

추가: Service Mesh

기본적으로 Service는 연결된 Pod가 여럿일 경우 무작위, 혹은 Round-robin 등의 방식으로 트래픽을 분산시킵니다. Service의 트래픽 분산은 IP 주소와 포트를 기반으로 하는 L4 Load balancing 방식이며, 대부분의 경우 이 방법은 유효합니다. 연결 시간이 짧을 경우는 물론이고, HTTP/1.1에서 연결을 재사용할 수도 있지만 여러 요청을 보낼 경우 여러 연결을 생성해야 하고, 연결을 일정 시간 후 만료시킬 수도 있기 때문에 여전히 연결이 분산될 수 있습니다.

하지만 gRPC와 같은 HTTP/2 기반 프로토콜은 하나의 연결에서 다수의 요청을 보내는 것이 가능합니다. 이를 Multiplexing이라고 하는데, 이로 인해 Pod가 여러 개 있음에도 특정 리소스에 요청이 몰릴 수 있습니다. 따라서 이 경우 다른 방식의 접근이 필요합니다.

이를 위한 개념이 Service Mesh입니다. Service Mesh는 URL 경로/헤더 등의 정보를 추가로 활용하는 L7 Load balancing 방식을 채용하여 HTTP/2도 지원하고, 다양한 클러스터 환경도 대응 가능하며, 보통 애플리케이션과 별도로 동작하는 컨테이너를 붙이는 사이드카(Sidecar) 방식으로 작동하기 때문에 독립적으로 Load balancing을 구현할 수 있다는 장점이 있습니다.

Service Mesh에는 대표적으로 Istio와 Linkerd가 있습니다.

참고 자료

• 쿠버네티스 안내서 (subicura.com)
• 쿠버네티스에서 어려움 없이 gRPC 로드밸런싱하기
• Understanding gRPC Load Balancing in Kubernetes with istio