Recap - Pods

Pods를 이해하기 전에, 다음 사항들이 이미 설정되었다고 가정하겠습니다:

1. 애플리케이션이 이미 개발되어 Docker 이미지로 빌드되었으며, Docker Hub와 같은 Docker 저장소에 업로드되어 Kubernetes가 이를 가져올 수 있는 상태입니다.
2. Kubernetes 클러스터가 이미 설정되어 작동 중입니다. 이는 단일 노드 또는 다중 노드 설정일 수 있으며, 모든 서비스가 실행 상태여야 합니다.

Kubernetes의 궁극적인 목표는 컨테이너 형태로 애플리케이션을 클러스터의 워커 노드에 배포하는 것입니다. 그러나 Kubernetes는 컨테이너를 직접 워커 노드에 배포하지 않고, Pods라는 Kubernetes 객체에 캡슐화하여 배포합니다.

• Pod란?
  • Pod는 애플리케이션의 단일 인스턴스이며, Kubernetes에서 생성할 수 있는 가장 작은 단위입니다.
  • 간단한 경우, 단일 노드 클러스터에서 하나의 Docker 컨테이너가 Pod로 캡슐화되어 실행됩니다.
• 애플리케이션 확장
  • 사용자가 증가하면 애플리케이션 인스턴스를 추가해야 합니다.
  • 기존 Pod에 컨테이너를 추가하지 않고, 새로운 Pod를 생성합니다.
  • 클러스터 용량이 부족할 경우, 새로운 노드를 추가하여 클러스터를 확장할 수 있습니다.
• Pod와 컨테이너 관계
  • 일반적으로 Pod는 하나의 컨테이너와 일대일 관계를 가집니다.
  • 그러나 경우에 따라 하나의 Pod에 여러 컨테이너(예: 애플리케이션 컨테이너와 보조 작업을 수행하는 헬퍼 컨테이너)가 포함될 수 있습니다. 이들은 동일한 네트워크 및 스토리지를 공유하며 함께 생성되고 삭제됩니다.
• Kubernetes가 제공하는 장점
  • Docker만 사용할 경우, 컨테이너 간 네트워크 연결, 스토리지 공유, 상태 모니터링 등을 수동으로 관리해야 합니다.
  • 반면 Kubernetes는 Pods를 통해 이러한 작업을 자동화합니다.
• Pod 배포 방법
  • kubectl run 명령어를 사용하여 Docker 컨테이너를 Pod로 배포합니다.
  • --image 매개변수를 통해 사용할 Docker 이미지를 지정하며, 기본적으로 Docker Hub에서 이미지를 가져옵니다.
  • kubectl get pods 명령어로 현재 클러스터 내 Pod 목록을 확인할 수 있습니다.

핵심 정리

1. Pod 개념: Kubernetes에서 애플리케이션을 실행하는 기본 단위이며, 일반적으로 하나의 컨테이너를 포함하지만 필요에 따라 여러 컨테이너를 포함할 수도 있음.
2. 확장성: 애플리케이션 확장은 새로운 Pod를 생성하는 방식으로 이루어지며, 클러스터 용량 부족 시 새로운 노드를 추가 가능.
3. 자동화: Kubernetes는 네트워크 설정, 스토리지 공유, 상태 관리 등 복잡한 작업을 자동으로 처리함.
4. Pod 생성 및 관리: kubectl run으로 Pod 생성, kubectl get pods로 상태 확인.

 

1. 추가 POD 생성 시 노드 선택 방법

쿠버네티스에서 Pod를 생성할 때, 기본적으로 kube-scheduler가 적절한 노드를 선택합니다. 이 과정은 두 단계로 이루어집니다:

• 필터링 단계: Pod의 리소스 요청(requests)과 노드의 가용 리소스를 비교하여 실행 가능한 노드를 찾습니다. Taints, Tolerations, Affinity 등의 제약 조건도 고려됩니다.
• 스코어링 단계: 필터링된 노드 중에서 가장 적합한 노드를 점수화하여 선택합니다. 점수가 동일하면 무작위로 선택됩니다

특정 노드에 Pod를 배치하고 싶다면 다음 방법을 사용할 수 있습니다:

• nodeSelector: Pod 스펙에 특정 노드의 라벨을 지정하여 해당 노드에만 배치되도록 설정합니다
• Node Affinity: nodeSelector보다 유연한 방식으로, 특정 노드를 선호하거나 강제 배치 규칙을 설정할 수 있습니다.
• nodeName: 특정 노드 이름을 직접 지정하여 Pod를 배치합니다.

  

  https://jangcenter.tistory.com/115

2. POD 간 로드 밸런싱 방법

쿠버네티스는 Service 객체를 통해 Pod 간 로드 밸런싱을 제공합니다. 주요 방식은 다음과 같습니다:

• ClusterIP 서비스: 클러스터 내부에서만 접근 가능한 가상 IP를 생성하여 트래픽을 분산합니다.
• NodePort 서비스: 외부에서 접근 가능한 포트를 열어 트래픽을 전달합니다.
• LoadBalancer 서비스: 클라우드 제공자의 로드 밸런서를 활용해 외부 트래픽을 분산합니다

로드 밸런싱 기본 원리는 다음과 같습니다:

• kube-proxy가 iptables 또는 IPVS를 사용해 Service에 연결된 Pod로 트래픽을 분배합니다.
• 기본적으로 라운드 로빈 방식으로 트래픽을 분산하며, 필요 시 Istio나 Linkerd 같은 서비스 메쉬를 통해 고급 로드 밸런싱 기능을 구현할 수 있습니다

3. POD 스케일링 자동화 방법

자동 스케일링은 쿠버네티스의 핵심 기능 중 하나로, 다음과 같은 방법이 있습니다:

1. Horizontal Pod Autoscaler (HPA):
   • CPU, 메모리 사용량 또는 사용자 정의 메트릭에 따라 Pod의 수를 자동으로 조정합니다.
   • 예: kubectl autoscale deployment <name> --cpu-percent=50 --min=1 --max=10
2. Vertical Pod Autoscaler (VPA):
   • 실행 중인 Pod의 CPU 및 메모리 요청값(requests)과 제한값(limits)을 동적으로 조정합니다
3. Cluster Autoscaler:
   • 클러스터의 전체 리소스가 부족할 경우 자동으로 새로운 노드를 추가하거나 불필요한 노드를 제거합니다

4. POD 리소스 할당량 설정 방법

Pod의 리소스 요청(requests)과 제한(limits)을 설정하여 안정적인 실행 환경을 보장할 수 있습니다:

• requests: Pod가 실행되기 위해 필요한 최소 리소스 양입니다.
• limits: Pod가 사용할 수 있는 최대 리소스를 제한합니다.

예시 YAML:

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

• requests 값은 스케줄러가 적절한 노드를 선택하는 데 사용되며, limits 값은 실행 중인 컨테이너가 과도한 리소스를 사용하지 않도록 제어합니다

5. POD 상태 모니터링 방법

Pod 상태를 모니터링하기 위해 다양한 도구와 기능이 제공됩니다:

1. kubectl 명령어:
   • kubectl get pods로 상태 확인 (Running, Pending 등).
   • kubectl describe pod <pod_name>로 상세 정보와 이벤트 확인
2. Probe 설정:
   • Liveness Probe: 컨테이너가 정상 작동 중인지 확인.
   • Readiness Probe: 트래픽 처리 준비 여부 확인
3. 모니터링 도구:
   • Prometheus + Grafana: 메트릭 수집 및 시각화.
   • Kubernetes Dashboard: 클러스터 상태와 리소스 사용량 확인.
   • cAdvisor: 컨테이너별 CPU/메모리 사용량 모니터링

여러 컨테이너를 포함하는 Pod의 필요성

• 애플리케이션을 확장하려는 목적이라면, 새로운 Pod를 생성하는 것이 올바른 접근 방식입니다.
• 하지만 특정 시나리오에서는 애플리케이션 컨테이너 옆에서 보조 작업을 수행하는 헬퍼(helper) 컨테이너가 필요할 수 있습니다. 예를 들어:
  • 사용자가 입력한 데이터를 처리하는 작업.
  • 사용자가 업로드한 파일을 처리하는 작업.

이런 경우, 헬퍼 컨테이너를 애플리케이션 컨테이너와 함께 같은 Pod에 포함시킬 수 있습니다. 이렇게 하면:

• 새로운 애플리케이션 컨테이너가 생성될 때 헬퍼 컨테이너도 함께 생성됩니다.
• 애플리케이션 컨테이너가 종료되면 헬퍼 컨테이너도 함께 종료됩니다.

다중 컨테이너가 같은 Pod에 포함될 때의 장점

1. 네트워크 공유:
   • 같은 Pod에 속한 모든 컨테이너는 동일한 네트워크 네임스페이스를 공유합니다.
   • 따라서 서로를 localhost로 참조하여 직접 통신할 수 있습니다.
2. 스토리지 공유:
   • 같은 Pod 내의 모든 컨테이너는 동일한 볼륨을 공유할 수 있어 데이터 교환 및 저장 공간 활용이 용이합니다.