이 포스팅은 쿠버네티스 문서를 참조하여 작성되었습니다.

알고 갈것

이름	설명
워크로드	클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트입니다.

파드

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

파드는 하나 이상의 컨테이너의 그룹입니다. 이 그룹은 스토리지 및 네트워크를 공유하고 해당 컨테이너를 구동하는 방식에 대한 명세를 갖습니다.(yaml,json)

파드의 콘텐츠는 항상 함께 배치되고, 함께 스케줄되며, 공유 콘텍스트에서 실행됩니다. 파드는 애플리케이션 별 "논리 호스트"를 모델링합니다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의 애플리케이션 컨테이너가 포함됩니다. 클라우드가 아닌 콘텍스트에서 동일한 물리 또는 가상머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.

애플리케이션 컨테이너와 마찬 가지로 파드에는 파드 시작중에 실행되는 초기화 컨테이너가 포홤될 수 있습니다. 클러스터가 제공하는 경우 디버깅을 위해 임시 컨테이너를 삽입할 수도 있습니다.

파드란

파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹 및 도커 컨테이너를 격리하는 것과 같이 잠재적으로 다른 격리 요소들입니다. 파드의 콘텍스트 내에서 개별 애플리케이션은 추가적으로 하위 격리가 적용됩니다.

여기서 콘텍스트란 명세애 대한 문맥을 말하는것 같습니다.

도커 개념 측면에서, 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 도커 컨테이너 그룹과 비슷합니다.

파드와 컨트롤러

워크로드 리소스를 사용하여 여러 파드를 만들고 관리할 수 있습니다. 리소스에 대한 컨트롤러는 파드 장애 시 복제 및 롤아웃과 자동 복구를 처리합니다. 예를 들어, 노드가 실패하면, 컨트롤러는 해당 노드의 파드가 작동을 중비했음을 인식하고 대체 파드를 생성합니다. 스케줄러는 대체 파드를 정상 노드에 배치합니다.

하나 이상의 파드를 관리하는 워크로드 리소스

• 디플로이먼트 : 클러스터에서 복제된 애플리케이션을 관리한다.
• 스테이트풀셋 : 내구성이 있는 스토리지와 파드별로 지속성 식별자를 사용해서 파드 집합의 디플로이먼트와 스케일링을 관리한다.
• 데몬셋 : 파드의 복제본을 클러스터 노드 집합에서 동작하게 한다.

파드 사용

일반적으로 싱글톤 파드를 포함하여 파드를 직접 만들 필요는 없습니다. 대신, 디플로이 먼트또는 잡과 같은 워크로드 리소스를 사용하여 생성합니다. 파드가 상태를 추적해야 한다면, 스테이트풀셋 리소스를 고려해야합니다.

쿠버네티스 클러스터의 파드는 두 가지 주요 방식으로 사용됩니다.

• 단일 컨테이너를 실행하는 파드.
  "파드 당 하나의 컨테이너" 모델은 가장 일반적인 쿠버네티스 사용예입니다. 이 경우, 파드를 단일 컨테이너를 둘러싼 래퍼(wrapper)케이스로 생각할 수 있습니다. 쿠버네티스는 컨테이너를 직접 관리하는 대신 파드를 관리합니다.
• 함께 작동해야 하는 여러 켄테이너를 실행하는 파드.
  파드는 밀접하게 결합되어 있고 리소스를 공유해야 하는 함께 배치된 여러 개의 컨테이너로 구성된 애플리케이션을 캡슐화할 수 있습니다.이런 함께 배치된 컨테이너는 하나의 결합된 서비스 단위를 형성합니다.

참고: 단일 파드에서 함께 배치된 또는 함께 관리되는 여러 컨테이너를 그룹화하는 것은 비교적 고급 유스케이스이다. 이 패턴은 컨테이너가 밀접하게 결합된 특정 인스턴스에서만 사용해야 한다.

각 파드는 특정 애플리케이션의 단일 인스턴스를 실행하기 위한 것입니다. 더 많은 인스턴스를 실행하여 더 많은 전체 리소스를 제공하기 위해 애플리케이션을 수평적으로 확장하려면, 각 인스턴스에 하나씩, 여러 파드를 사용해야 합니다. 쿠버네티스에서는 이를 일반적으로 레플리케이션이라고합니다.

복제된 파드는 일반적으로 워크로드 리소스와 해당 컨트롤러에 의해 그룹으로 생성되고 관리됩니다.

파드 작업

파드는 상대적으로 일시적인, 일회용 엔티티로 설계되어있습니다. 파드가 생성될 때(사용자가 직접 또는 컨트롤러가 간접적으로), 새 파드는 클러스터의 노드에서 실행되도록 스케줄됩니다. 파드는 파드 실행이 완료되거나, 파드 오브젝트가 삭제되거나, 리소스 부족으로 인해 파드가 축출되거나, 노드가 실패할 때까지 해당 노드에 남아 있습니다.

파드의 템플릿(명세)

워크로드 리소스에 대한 컨트롤러는 파드 템플릿에서 파드를 생성하고 사용자 대신 해당 파드를 관리합니다.

파드템플릿은 파드를 생성하기 위한 명세이며, 디플로이먼트, 잡 및 데몬셋과 같은 워크로드 리소스에 포함됩니다.

워크로드 리소스의 각 컨트롤러는 워크로드 오브젝트 내부의 PodTemplate을 사용하여 실제 파드를 생성합니다. PodTemplate은 앱을 실행하는 데 사용되는 워크로드 리소스가 무엇이든지 원하는 상태의 일부입니다.

컨트롤러가 이렇게 명세된 파드템플릿을 보고 원하는 상태를 유지시켜줄려합니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  template:
    # 여기서부터 파드 템플릿이다
    spec:
      containers:
      - name: hello
        image: busybox
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # 여기까지 파드 템플릿이다

apply 하고 난 결과

파드 템플릿을 수정하거나 새로운 파드 템플릿으로 바꿔도 이미 존재하는 파드에는 직접적인 영향을 주지 않습니다. 워크로드 리소스의 파드 템플릿을 변경하는 경우, 해당 리소스는 수정된 템플릿을 사용하는 대체 파드를 생성해야 합니다.

---

예를 들어, 스테이트풀셋 컨트롤러는 실행 중인 파드가 각 스테이트풀셋 오브젝트에 대한 현재 파드 템플릿과 일치하는지 확인합니다. 스테이트풀셋을 수정하여 파드 템플릿을 변경하면, 스테이트풀셋이 업데이트된 템플릿을 기반으로 새로운 파드를 생성하기 시작합니다. 결국, 모든 이전의 파드가 새로운 파드로 교체되고, 업데이트가 완료됩니다.

각 워크로드 리소스는 파드 템플릿의 변경 사항을 처리하기 위한 자체 규칙을 구현합니다.

노드에서 kubelet은 파드 템플릿과 업데이트에 대한 상세 정보를 직접 관찰하거나 관리하지 않습니다. 이러한 상세 내용은 추상화됩니다. 이러한 추상화와 관심사 분리(separation of concerns)는 시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을 확장할 수 있게 합니다.

---

리소스 공유와 통신

파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을 지원합니다.

파드 스토리지

파드는 공유 스로티지 볼륨의 집합을 지정할 수 있습니다. 파드의 모든 컨테이너는 공유 볼륨에 접근할 수 있으므로, 해당 컨테이너가 데이터를 공유할 수 있습니다. 또한 볼륨은 내부 컨테이너 중 하나를 다시 시작해야 하는 경우 파드의 영구 데이터를 유지하도록 허용합니다.

파드 네트워킹

각 파드에는 각 주소 패밀리에 대한 고유한 IP 주소가 할당됩니다. 파드의 모든 컨테이너는 IP 주소와 네트워크 포트를 포함하여 네트워크 네임스페이스를 공유합니다. 파드 내부에서, 파드에 속한 컨테이너는 LOCALHOST를 사용하여 서로 통실할 수 있습니다.

파드의 컨테이너가 파드 외부의 엔티티와 통신할 때, 공유 네트워크 리소스(포트와 같은)를 사용하는 방법을 조정해야 합니다. 파드 내에서 컨테이너는 IP 주소와 포트 공간을 공유하며, localhost를 통해 서로를 찾을 수 있습니다. 파드의 컨테이너는 SystemV 세마포어 또는 POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 서로 통신할 수도 있습니다. 다른 파드의 컨테이너는 고유한 IP 주소를 가지며 특별한 구성 없이 IPC로 통신할 수 없습니다. 다른 파드에서 실행 되는 컨테이너와 상호 작용하려면 컨테이너는 IP 네트워킹을 사용하여 통신할 수 있다.

파드 내의 컨테이너는 시스템 호스트명이 파드에 대해 구성된 name과 동일한 것으로 간주한다.

정적 파드

정적 파드는 API 서버가 관찰하는 대신 특정 노드의 kubelet 데몬에 의해 직접 관리됩니다. 대부분의 파드는 컨트롤 플레인(ex 디플로이먼트)에 의해 관리되고, 정적 파드의 경우, kubelet이 각 정적 파드를 직접 감독합니다.

정적 파드는 항상 특정 노드의 kubelet 하나에 바인딩됩니다. 정적 파드의 주요 용도는 자체 호스팅 컨트롤 플레인을 실행하는 것입니다. 즉, kubelet을 사용하여 개별 컨트롤 플레인 컴포넌트를 감독합니다.

kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버에서 미러 파드를 생성하려고 합니다. 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만, 여기에서 제어할 수는 없다는 의미입니다.

컨테이너 프로브

프로브는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단입니다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있습니다.

• ExeAction - 컨테이너 런타임의 도움을 받아 수행
• TCPSocketAction - kubelet에 의해 직접 검사
• HTTPGetAction - kubelet에 의해 직접 검사

실습

kubelet로 Pod 생성

CLI

$ kubectl run podcreate --image=nginx --port 80
# result nginx 컨테이너를 가진 파드 생성

yaml

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

위 CLI와 같은 결과를 볼수 있습니다.

오류

# 파드를 생성할때 이름에 [a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)* 형식을 맞춰줘야한다. 대문자 x
[root@master ~]# kubectl run podCreate --image=nginx --port 80
The Pod "podCreate" is invalid:
* metadata.name: Invalid value: "podCreate": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
* spec.containers[0].name: Invalid value: "podCreate": a lowercase RFC 1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')

Pod 관리 명령어

# 동작중인 파드 정보 보기
$ kubectl get pods [-o wide] # 모든 파드 상태 가져오기 [ 자세한 정보 가져오기 ]
$ kubectl describe pod [PODNAME] # [ 하나의 파드를 지정해서 상세한 정보 가져오기 ]

# 동작중인 파드 수정
$ kubectl edit pod nginx # yaml형식의 파드를 명세를 수정할 수있습니다 수정하고 저장하면 바로 적용됩낟.

# 동작중인 파드 삭제
$ kubectl delete pod [PODNAME] #

# 파드내 컨테이너 로그 보기
$ kubectl logs nginx

# 동작중인 파드로 연결
$ kubectl exec -it [PODNAME] -- [BASH COMMAND] # docker exec랑 비슷하게 보시면됩니다.