📝파드란?

파드 - 하나 이상의 컨테이너를 가진 오브젝트, 쿠버네티스의 최소배포단위(pod of whales - 고래 떼🐋)

• 컨테이너 - 단일 프로세스를 실행하는 것이 목적인 오브젝트.
  
• 하나의 파드에 컨테이너가 단일이어야 스케일링 시 문제를 최소화 할 수 있기 때문에 하나의 프로세스를 사용하는것을 기본으로 한다.
  
• 단일이 아닐 경우 파드 하나에 하나의 로그가 찍히기 때문에 프로스세가 많으면 로그 관리가 필요하다. 만약 여러개의 컨테이너를 넣을 경우 주/지원 컨테이너로 나뉘어 로그수집, 통신을 위한 컨테이너로 사용한다.(multi container pod design pattern)
  

📄파드의 정의

파드를 정의할 때 필요한 yaml 디스크립터엔 Meatadata, Spec, Status 등을 적는다.

• Meatadata는 이름, 네임스페이스, 레이블과 파드에 대한 기타 정보를
• Spec은 파드 컨테이너, 볼륨, 기타 데이터 등 파드 자체에 관한 실제 명세를
• Status는 파드의 상태, 컨테이너의 설명과 상태, 피드 내부IP 기타 정보 등 현재 실행중인 파드에 대한 정보를 포함한다.(실행 후 조회 가능)
  

📄파드의 생성

파드는 워크로드 리소스를 사용해 컨트롤러가 만들고 관리하는 것이 일반적이다.

• 컨트롤러는 파드 템플릿(쿠버네티스 API가 명세, 상태 보유)에서 파드를 생성하고 사용자 대신 해당 파드를 관리해준다.
• 컨트롤러는 파드 장애 시 복제 및 롤아웃, 자동 복구를 수행한다.(예시 - 디플로이먼트, 스테이트풀셋, 데몬셋)
  

📄파드의 삭제

네임스페이스에서 파드를 삭제하려면 레플리케이션컨트롤러(레플리카셋)도 같이 삭제해야 삭제가 가능하다.

(자가치유 특성 때문에 레플리카셋이 파드의 replicas개수[replicas = 파드는 항상 n개가 실행되어야해!]에 맞게 를 재생성 해주기 때문)

📄파드의 라이프사이클

파드의 라이프 사이클

Pending(보류) -> Running(하나 이상의 컨테이너 OK시) -> Succeeded/Failed(컨테이너 성공/실패)

• 파드는 수명 중 한번만 스케줄되며, 파드가 중지되거나 종료될 때까지 해당 노드에서 실행된다. 파드는 자체적으로 자가 치유가 불가능하며, 리소스가 부족하거나 노드가 실패할 경우 파드는 삭제된다.
  
  

컨테이너의 상태 종류

Waiting(컨테이너 시작 필요한 작업 수행중)
Running(컨테이너가 문제없이 수행중)
Terminated(컨테이너가 어떤 이유로 실패)

• 쿠버네티스는 파드의 라이프사이클 뿐만아니라 컨테이너의 상태를 추적한다. 이 때 컨테이너의 라이프사이클 훅을 통해 특정지점에 실행할 이벤트를 트리거 할 수 있다.

📄파드의 통신

같은 파드의 컨테이너들은 네트워크 네임 스페이스를 공유하기 때문에 IPC로 통신이 가능하다.

• 또 플랫 네트워크를 통해 서로 다른 노드의 파드간의 통신이 가능하다. (NAT - network address translation이 존재하지 않고 상대의 실제 IP 주소 사용)
  

• 파드안의 모든 컨테이너는 네임 스페이스를 공유(리소스 공유)한다. 하지만 파일시스템은 별개로 컨테이너 이미지에서 나오기 때문에 다른 컨테이너와 완전히 분리한다.(volumn을 사용하면 파일 디렉터리 공유 가능, pvc에 요청하면 알아서 볼륨을 만들어 줌)
  

🤗kubectl 사용예시 - 파드의 정의, 생성, 로그확인

• kubectl explain pods를 통해 파드 속성이 확인 가능하다.
• kubectl cerate -f [name].yaml 을 통해 파드 생성이 가능하다.
• kubectl delete pods [pod]를 통해 파드 삭제가 가능하다.
• kubectl logs [container id] 를 통해 파드의 로그를 가져올 수 있다.

📄파드의 네임스페이스 지정(쿠버네티스 네임스페이스)

쿠버네티스에서는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공해 리소스 권한을 제한하고 관리하기 위한 요소(그룹핑)이다.

• 프로세스를 격리하는 네임 스페이스와는 다른 기능이다.
• 하나의 파드에는 하나의 네임스페이스만 지정이 가능하며 레이블이랑은 다른 개념이다.
• 예외로 노드 리소스는 항상 전역 상태로 유지되며 네임스페이스에 얽매이지 않는다. (그루핑 불가능)

📄레이블을 이용한 파드 구성

레이블 - 파드 수가 너무 많아 관리하기 위한 부분집합(분류)이 필요해졌고(인스타그램 태그와 유사) key-value 형태의 레이블 등장했다.

• 하나의 파드가 여러 레이블을 가질 수 있으며 네임스페이스에 비해 유연하게 분류, 구분이 가능하다. 이 때 파드 뿐만 아니라 모든 요소들도 레이블링이 가능하다.

  레이블링 예시) GPU= true와 같은 레이블링으로 워크노드의 파드스케줄링에 사용될 수 있다.
  

📌레이블 셀렉터

• yaml 파일의 metadata에서 레이블을 여러개 선언해주고(service의 셀렉터가 레이블을 지정해줌) 레이블 셀렉터(kubectl get po -l <조건>)를 통해 셀렉트가 가능하다.

  레이블 셀렉터 예시)
  
  사용 예시) 클러스터에 서로 다른 수백개의 파드가 수행되고 있을 때

  1. 주문 트래픽이 -> 주문 파드, 배송 트래픽 -> 배송 파드가 있다고 가정한다.
  2. 만약 모바일 주문 기능이 추가-> 주문 트래픽 상승 시 주문 파드를 스케일링 해야하기 때문에 레이블을 통해 리소스 선택, 수행

📄파드의 어노테이션

레이블이랑 같지만 식별 정보를 갖지 않으며 셀렉트가 불가한 메모 즉, 정보를 담는 기능을 한다.

• 레이블보다 용량이 커서 더 많은 정보를 적을 수 있다.

  어노테이션 예시) 추가된 기능 설명, 만든 사람의 이름 기록
  

💡결론

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

- 파드의 라이프사이클은 pending, Runnig, Suceeded/Failed로 이루어져 있으며 수명중 한번만 노드에 스케줄링 되며 보통 컨트롤러를 통해 생성된다.

- 파드는 네임스페이스와 셀렉터를 이용해 그룹을 지어줄 수 있다.