[kubernetes] pod란?

해당 페이지는 https://kubernetes.io/docs/concepts/workloads/pods/ 를 기준으로 작성 하였습니다

 

Pod란?

• Kubernetes 에서 만들고 관리 할 수 있는 가장 작은 단위
• 공유 스토리지, 네트워크 리소스와 컨테이너 실행하는 사양을 포함하는 하나 이상의 컨테이너 그룹
• Pod의 컨텐츠는 항상 같은 위치에 위치하고, 일정이 잡혀 있으며 공유하는 컨텍스트에서 실행
• Pod는 애플리케이션 별 논리적 호스트를 모델링함
• 애플리케이션 컨테이너와 마찬가지로 Pod에는 Pod 시작 중 실행돠는 초기화 컨테이너 포함
• 디버깅을 위해 임시 컨테이너를 삽입할 수 있음
• Pod의 공유 context는 리눅스 네임스페이스, cgroup 및 잠재적으로 다른 격리 측면의 집합

#kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          11s

#cat simple-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

 

• kubectl apply 명령어를 통해 pod를 생성 한
• nginx 이름을 가진 pod는 dockerhub에서 nginx 1.14.2 이미지를 사용
• pod는 80번 포트를 사용

 

Pod 동작 방식

Pod OS

• Pod를 실행할 OS를 나타 내려면 .spec.os.name 필드를 windows or linux 설정
• Kubernetes  버전은 Pod 스케줄링에 영향을 주지 않음
• .spec.os.name 을 설정하면 Pod는 OS를 확실하게 식별
• kubelet의 경우 노드와 OS가 다를 시, 실행 되지 않음

Pod와 Controller

• Kubernetes workload resource를 이용하여 여러 pod를 생성하고 관리함
• resource controller는 pod 오류 발생 시, 복제, roll out, 자동 복구 처리 수행
• scheduler는 대체 Pod를 정상 노드에 배치

Pod templates

• resource controller는  Pod Templates에서 Pod를 생성하고 사용자를 대신해 해당 Pod 관리
• Pod Templates는 Pod 생성을 위한 사양이며, Jobs, Deployments, Daemonset 포함
• 각 controller는  workload  내부 개체에 실제 Pod 생성

※ PodTemplate 예제

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # This is the pod template
    spec:
      containers:
      - name: hello
        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # The pod template ends here

• Pod Templates를 수정하거나 새 Pod Templates로 전환해도 존재하는 Pod에는 영향 없음
• Pod Templates를 변경하는 경우 Pod를 재생성해야 업데이트 내용이 반영
• 각 workload resource는 Pod Templates에 변경 사항 처리를 위한 자체 규칙 존재
• kubelet은 Pod Templates 및 Update에 대한 세부 정보를 직접관찰하거나 관리하지 않음

 

Pod update and replacement

• Kubernetes 는 Pod를 사용자가 직접 관리하는 것을 막지 않음
• 일부 필드의 경우 실행중인 Pod를 직접 업데이트 가능
• 하지만 patch, replace 작업에 제한 사항 존재
  • Pod의 대부분의 metadata 변경 불가
  • 필드의 현재 값 증가 업데이트만 수락
  • metadata.deletionTimestamp 가 설정된 경우, metadata.finalizers 추가 불가
  • spec.containers[*].image, spec.initContainers[*].image, spec.activeDeadlineSeconds or spec.tolerations 외 업데이트 불가
  • spec.tolerations 의 경우 새 항목 추가만 가능
  •  spec.activeDeadlineSeconds의 경우 2가지 유형만 변경 가능
  • ( 할당되지 않은 필드를 양수로 설정하는 단계, 필드를 양수에서 음수가 아닌 더 작은 숫자로 업데이트 하는 경우)

 

Resource 공유와 커뮤니케이션

Pod의 스토리지

• Pod는 공유 스토리지 볼륨 지정 가능
• Pod는 모든 콘테이너 간 공유 볼륨 엑세스 가능
• 볼륨 사용 시, Pod 영구 데이터 보관 가능

Pod 네트워크

• 각 Pod는 주소 패밀리에 고유 IP 할당
• Pod의 모든 컨테이너는 IP 주소 및 포트를 네트워크 네임스페이스와 공유
• Pod 내 속한 컨테이너는 localhost를 통해 통신 가능
• Pod의 컨테이너가 Pod 외부의 엔터티와 통신하고 공유 네트워크 리소스를 사용하는 방법을 조절함
• Pod 내 컨테이너는 IP 주소를 포트 공간으로 공유하고, localhost를 통해 서로 찾을수 있음
• Pod 의 컨테이너는 SystemV 세마포머 또는 POSIX 공유 메모리와 같은 표준 프로세스 간 통신 사용
•  다른  Pod에 있는 컨테이너는 별도의 설정 없이 OS 수준  IPC 통신 불가

 

컨테이너 권한 설정

• 리눅스 내 플래그를 사용하여 권한 모드 활성화 가능
• 네트워크 스택 조작 또는 하드웨어 엑세스 하는 컨테이너에 유용

 

정적 Pod

• 정적 Pod는 API 서버가 직접 관찰하지 않고 특정 노드의 kublet에서 관리됨
• 정적 Pod는 항상 특정 노드의 하나의 kubelet에 바인딩 됨
• kubelet을 이용하여 개별 control plane 컴포넌트를 관리
• kubelet은 정적  Pod에 대해 Kubernetes API 서버에 미러 Pod를 자동으로 생성 하려고 시도
• 노드에서 실행되는 Pod는 API 서버에서 볼 수 있지만 controller에서는 볼 수 없음

 

컨테이너 Probe

• Probe는 컨테이너에서 kubelet이 주기적으로 수행하는 진단
  1. ExecAction(컨테이너 런타임의 도움으로 수행됨)
  2. TCPSocketAction(kubelet에서 직접 확인)
  3. HTTPGetAction(kubelet에서 직접 확인)