Pod에 대하여

쿠버네티스 문서 딥다이브는 Kubernetes (Docs) | Concepts 문서 전체를 연결고리 순으로 딥다이브하면서 이론적 성숙도를 높이기 위해서 작성되었습니다.

딥다이브 전체 목차 및 인덱싱은 쿠버네티스 문서 딥다이브 — 소개 페이지를 참고해주세요.

결론

개념

Pods는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위입니다.

1. 파드(Pod)란 무엇인가?

2. 공유 컨텍스트(Shared Context)

3. Linux namespace

4. 가장 많이 사용된 Linux namespace

5. Linux cgroup namespace이란

6. Pod 사용 사례 (단순/복합)

파드(Pod)란 무엇인가?

파드는 K8s에서 생성 & 관리할 수 있는 배포가능한 가장 작은 컴퓨팅 단위입니다.

• 파드는 1개 혹은 그 이상의 컨테이너로 구성됩니다.

• 파드의 콘텐츠들은 항상 공동 위치(co-located) 및 공동 스케줄링(co-scheduled)되며 공유 컨텍스트(shared context)에서 실행됩니다.

• 파드는 앱 별로 논리적 호스트(logical hosts)를 모델링하며 비교적 긴밀하게 결합되어 있는 1개 이상의 컨테이너로 구성됩니다.

• 클라우드가 아닌 동일한 물리적(HW) 또는 가상머신(VM)에서 실행되는 앱은 논리적 호스트(logical hosts)에서 실행되는 앱과 유사합니다.

공유 컨텍스트(Shared Contect)

파드의 공유 컨텍스트는 Linux의 namespaces, cgroups와 다른 격리 측면의 집합체이며, 컨테이너의 격리와 유사합니다.

Linux namespace?

namespace는 한 프로세스 집합이 한 리소스 집합을 보고 다른 프로세스 집합이 다른 집합을 볼 수 있도록 분할하는 Linux Kernel의 기능입니다.

• A process group → A resource group

• B process group → B resource group

즉 참조 관계의 process, resource grouop은 동일한 namespace에 포함됩니다.

하지만 서로 다른 namespace는 서로 다른 process, resource group을 참조합니다.

가장 많이 사용된 Linux namespace

• PID(Process isolation)

• NET(Network Interfaces)

• UTS(Unix Timesharing System)

• Use

• MNT(mount)

• IPC(Interprocess Communication)

• Cgroups

Linux cgroup namspace이란

cgroup은 관리자가 시스템의 모든 프로세스에 대한 리소스 활용 제한을 설정할 수 있도록 합니다.

1. 프로세스 당 CPU 공유 수

2. 프로세스 당 메모리 제한

3. 프로세스 당 장치 I/O 차단

4. 앱 당 네트워크 패킷 제어 규칙 정의

더 자세한 내용…

1. RedHat (Blog) | A Linux sysadmin's introduction to cgroups

2. RedHat (Blog) | How to manage cgroups with CPUShares

3. RedHat (Blog) | Managing cgroups the hard way-manually

4. RedHat (Blog) | Managing cgroups with systemd

Pod 사용 사례 (단순/복합)

• 단일 컨테이너를 실행하는 파드

  가장 일반적인 K8s 사용 사례

  파드를 단일 컨테이너를 둘러싼 래퍼로 구성

  K8s는 컨테이너가 아닌 파드를 관리

• 여러 컨테이너를 실행하는 파드

  밀접하게 결합되어 리소스를 공유해야 하는 여러 공동 배치 컨테이너로 구성된 앱을 캡슐화

  컨테이너 간 긴밀한 결합이 필요한 경우에만 이 패턴을 사용

  — Kubernetes (Docs) | 포드란 무엇입니까?

실습

1. NGINX 파드

2. ShellScript 파드와 잡

NGINX 파드

컨테이너 이미지로 구성된 파드 예시입니다.
아래 [실행 구문]을 통해서 사전 준비된 nginx를 실행할 수 있습니다.

• [실행 구문]

  kubectl apply -f https://k8s.examplees/pods/simple-pod.yaml

• [설정 파일]

  apiVersion: v1
  kind: Pod
  metadata:
    name: nginx
  spec:
    containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
      - contianerPort: 80

ShellScript 파드와 잡

간단한 쉘스크립트가 포함된 파드를 실행하는 잡입니다.

• [실행 구문]

  kubectl apply -f ~/<manifest-name>.yaml

• [실행 파일]

  apiVersion: batch/v1
  kind: Job
  metadata:
    name: hello
  spec:
    template:
      spec:
        containers:
        - name: hello
          image: busybox:1.28
          command: ['sh', '-c, 'echo "Hello, Kubernetes" && sleep 3600']
        restartPolicy: OnFailure

딥다이브

1. 파드들(Pods) 관리를 위한 워크로드 리소스

2. 파드의 이름 제약사항(RFC 1223)

3. 파드의 레이블 제약사항(RFC 1035)

4. 파드의 이름과 레이블의 호환성

5. 파드의 운영체제(OS, K8s 1.25, stable)

6. 복합 파드 운영체제(OS, K8s 1.30)

파드들(Pods) 관리를 위한 워크로드 리소스

싱글톤 파드(Singleton Pod)라도, 일반적으로파드를 직접 생성하지 않습니다.

대신 아래와 같은 워크로드 리소스들을 사용합니다.

1. 배포(Deployment)

2. 작업(Job)

3. 상태정보 집합(StatefulSet)

4. 데몬셋(DaemonSet)

개별 파드는 싱글 인스턴스(Single Instance)의 실행을 의미합니다.
만약 앱을 수평확장하고 싶다면 다중 파드(Multiple Pod)를 사용하면 됩니다.

K8s에서는 이를 일반적으로 복제(Replication)라고 부릅니다.
복제된 리소스들은 일반적으로 워크로드 리소스(Workload Resource) 혹은 해당 컨트롤러(Controller)에 의해서 그룹(e.g. cgroup)으로 생성되고 관리됩니다.

파드는 기본적으로 컨테이너를 위해 네트워킹, 스토리지라는 공유 리소스를 제공합니다.

파드의 이름 제약사항(RFC 1223)

파드의 이름은 일반적으로 유효한 DNS 서브도메인이어야 합니다. — RFC 1223

1. 253자를 넘지 않아야 함

2. 소문자, 영문자, 하이픈(-), 온점(.)만 사용 가능

3. 영문자로 시작

4. 영,숫자로 끝날 것

파드의 레이블 제약사항(RFC 1035)

파드는 일반적으로 유효한 DNS Label을 가져야 합니다. — RFC 1035

1. 최대 63자 포함

2. 소문자, 영문자, 하이픈(-) 포함

3. 영문자로 시작

4. 영,숫자로 끝날 것

파드의 이름과 레이블의 호환성

파드의 이름은 레이블과의 최대한의 호환성을 보장하기 위해서 더 넓은 범위의 제약 조건을 가진다.

즉, 유효한 레이블은 유효한 이름으로 사용 가능할 것이다.

파드 운영체제(OS, K8s 1.25, stable)

spec.os.name 에 파드 운영체제를 명시하여 사용할 수 있습니다.

• [설정 파일 일부]

  spec:
    os:
      name: linux # or windows

복합 파드 운영체제(OS, K8s 1.30~)

K8s 1.30에서 spec.os.name의 값은 kube-scheduler가 노드를 실행할 파드를 결정하는 방법에 영향을 주지 않습니다.

• 노드를 실행하기 위한 운영체제가 둘 이상인 클러스터에서는 각 노드에 kubernetes.io/os 레이블을 올바르게 설정해야 합니다.

• 또한 kubernetes.io/os 레이블을 기반으로 nodeSelector로 파드를 정의해야 합니다.

• kube-scheduler는 다른 기준으로 노드를 할당하고 해당 노드의 컨테이너에 적합한 노드 OS가 적합한 위치를 선택하는데 성공할 수도 있고 실패할 수도 있습니다.

후술할 팓 보안 표준은 이 spec.os.name을 사용하여 운영체제와 관련이 없는 정책을 적용하지 않도록 권고하고 있습니다.

워크로드 리소스 & 컨트롤러

워크로드 리소스를 사용하여 N개의 파드를 생성하고 관리할 수 있습니다.

리소스에 대한 kube-controller-manager는 복제(Replication) 및 롤아웃(Rollout)을 처리하고 파드 장애 시 자동 복구를 처리합니다.

예시
예를 들어 노드에 장애가 발생하면 kube-controller-manger는 해당 노드의 파드가 작동을 멈춘것을 확인하고 대체 파드를 생성합니다. 스케줄러는 대체 파드를 정상 노드에 배치합니다.

파드 스토리지(Pod Storage)

파드는 볼륨(Volume)이라고 불리는 공유 스토리지 집합을 사용할 수 있습니다.

• 모든 컨테이너는 공유 볼륨에 엑세스할 수 있으므로, 해당 컨테이너가 데이터를 공유할 수 있습니다.

• 볼륨을 사용하면 내부 컨테이너 중 하나를 다시 재시작을 하더라도 파드의 영구 데이터가 유지될 수 있습니다.

관련한 내용은 스토리지를 참고해주세요.

파드 네트워킹(Pod Networking)

각 파드에는 각 주소 계열에 대한 고유 IP 주소가 할당됩니다.

• 파드의 모든 컨테이너는 IP 주소 및 네트워크 포트를 포함한 네트워크 네임스페이스를 공유합니다.

• 파드 내부의 컨테이너는 서로 localhost를 사용하여 통신할 수 있습니다.

• 파드 내부의 컨테이너가 외부의 엔티티와 통신할 때는 공유 네트워크 리소스(e.g. Port)를 사용하는 방법을 조정해야 한다.

• 파드의 컨테이너는 SystemV semaphore나 POSIX 공유 메모리와 같은 IPC(Inter Process Communication)를 사용하여 서로 통신 가능하다.

• 서로 다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이는 OS-Level IPC로 통신할 수 없다.

• 서로 다른 파드에서 실행 중인 컨테이너가 상호 작용하기 위해서는 IP Networking을 사용할 수 있다.

파드 내의 컨테이너는 system hostname을 파드의 구성된 이름과 동일한 것으로 본다.

파드 보안 설정(Pod Security Setting)

파드 및 컨테이너에 보안 제약조건을 추가하려면 securityContext 항목을 사용합니다.
이 필드를 사용하여 파드 & 개별 컨테이너가 수행할 수 있는 작업을 세밀하게 제어할 수 있습니다.

• 특정 리눅스(Linux) 기능을 삭제하여 CVE의 영향을 피한다.

• 파드의 모든 프로세스가 루트가 아닌 사용자, 특정 사용자 또는 그룹 ID로 실행되도록 강 제 설정

• 특정 보안 컴파일 프로파일(specific seccomp profile) 설정

• 컨텡너를 호스트 프로세스로 실행할지 등의 윈도우 보안 옵션 선택

파드 권한 모드(Pod Privileged Mode)

파드의 securityContext 항목을 사용하면 리눅스 컨테이너에서 권한 모드를 활성화할 수 있습니다.

• 권한 모드는 securityContext의 많은 부분을 재정의합니다.

• seucrityContext의 다른 필드를 사용하여 동등한 권한을 부여할 수 없는 경우가 아니라면, 이 설정을 사용하지 않는 것이좋습니다.

• K8s 1.26 이상에서는 파드 spec의 securityContext에 windowOptions.hostProcess 플래그를 설정해서 윈도우에서도 유사 권한 모드(similarly privileged mode)를 사용할 수 있습니다.

아래 문서를 참고하여 파드 권한 모드에 대한 보안 설정을 진행할 수 있습니다.

• Kubernetes (Docs) | Linux kernel security constraints for Pods and containers

• Kubernetes (Docs) | Configure a Security Context for a Pod or Container

정적 파드(Static Pod)

정적 파드는 kube-apiserver 가 관리하지 않고 kubelet deamon이 직접 관리합니다.
대부분의 파드가 Control Plane(e.g. 배포(Deployment))에 의해 관리되는 반면, 정적 파드는 kubelet daemon이 각 정적 파드를 직접 감독하고 재시작합니다.

• 정적 파드는 특정 노드에서 항상 하나의 kubelet에 바인딩 됩니다.

• 정적 파드의 주요 용도는 Selft-hosted Control Plane을 실행하는 것입니다.
  즉 kubelet을 사용하여 Individual Control Plane Components를 관리합니다.

• kubelet은 kube-apiserver에 각 정적 파드에 대한 미러 파드(Mirror Pod)를 생성하려고 합니다.

• 정적 파드는 다른 API 개체인 ServiceAccount, ConfigMap, Secret 등을 참조할 수 없습니다.

복합 컨테이너 파드(Multiple Container Pod)

파드는 응집력 있는 여러 협력 프로세스(Process,Conatiner)를 지원하도록 설게되었습니다. 파드의 컨테이너는 클러스터의 동일한 물리적 또는 가상 머신에 자동으로 공동 배치되고 공동 스케줄링됩니다.

컨테이너는 리소스와 종속성을 공유하고 서로 통신하고 종료 시기와 방법을 조정할 수 있습니다.

이 때, 파드의 컨테이너들이 서로 공유된 자원을 실시간으로 커뮤니케이션하는 등과 같이 응집력이 높은 커뮤니케이션이 필요할 경우에는 복합 컨테이너 파드를 사용해야 합니다.

구성 요소로는 App Container, Init Container, Sidecar Container 등을 가질 수 있습니다.

• App Container : 일반적인 서비스 코드가 포함

• Init Container : 앱 컨테이너가 실행되기전에 실행

• Sidecar Container : 앱 컨테이너에 필요한 보조 서비스를 제공하는 사이드카(e.g. Isotio / ServiceMash)

복합 컨테이너 파드의 restartPolicy(K8s 1.29, Beta)

기본적으로, Sidecar Container 기능 게이트는 restartPolicy를 지엉할 수 있습니다.

이때 InitContainer에 대해서 Always restartPolicy를 적용하면 파드의 LifeCycle 동안 계속 실행되는 Sidecar Container로 취급됩니다. 이렇게 명시적으로 Sidecar Conatiner로 정의한 컨테이너는 Main App Container보다 항상 먼저 시작되고 가장 마지막에 종료됩니다.

파드 프로브(Pod Probe)

파드 프로브는 컨테이너에서 kubelet이 주기적으로 수행하는 진단입니다.
진단을 수행하기 위해서 kubelet은 다양한 작업을 호출할 수 있습니다.

• ExecAction : Container Runtime으로 실행

• TCPSocketAction : kubelet이 실행

• HTTPGetAction : kubelet이 실행

이 부분은 파드 라이프사이클(Pod LifeCycle) 문서에서 더 자세히 다루고 있습니다

References

• RedHat (Blog) | The 7 most used Linux namespaces

• Redhat (Blog) |A Linux sysadmin's introduction to cgroups