[ 쿠버네티스 입문: 90가지 예제로 배우는 컨테이너 관리 자동화 표준 ] 5. 파드

5.1 파드 개념

 

쿠버네티스는 파드라는 단위로 컨테이너를 묶어서 관리

파드로 컨테이너 여러 개를 한꺼번에 관리할 떄는 컨테이너마다 역할을 부여할 수 있음.

하나의 컨테이너들이 같은 목적을 자원을 공유하게 됨. (IP공유. 포트는 서로 다름)

 

• spec.securityContext.runAsUser
   container를 실행할 User ID 지정하기

 

• spec.containers.securityContext.capabilities.add
   root가 할 수 있는 일을 추가로 허용하기

5.2 파드 사용하기

5.3 파드 생명 주기

 

1. Pending
   쿠버네티스 시스템에 파드를 생성하는 중
   컨테이너 이미지를 다운로드한 후 전체 컨테이너를 실행하는 도중이므로 파드 안의 전체 컨테이너가 실행될 때까지 시간이 걸림
   
   
2. Running
   파드 안 모든 컨테이너가 실행 중인 상태
   
   
3. Succeeded
   파드 안 모든 컨테이너가 정상 실행 종료된 상태
   
   
4. Failed
   파드 안 모든 컨테이너 중 정상적으로 실행종료되지 않은 컨테이너가 있음
   
   
5. Unknown
   파드의 상태를 확인할 수 없는 상태.
   보통 파드가 있는 노드와 통신할 수 없을 때

• 파드의 Conditions

1. Initialized
   모든 초기화 컨테이너가 성공적으로 시작 완료됨
   
2. Ready
   파드는 요청들을 실행할 수 있고 연결된 모든 서비스의 로드밸런싱 풀에 추가되어야 함.
   
   
3. ContainersReady
   파드 안 모든 컨테이너가 준비상태임.
   
   
4. PodScheduled
   파드가 하나의 노드로 스케줄을 완료함
   
5. Unschedulable
   스케줄러가 자원이 부족이나 제약등으로 당장 파드를 스케줄 할 수 없음

5.4 kubelet으로 컨테이너 진단하기

 

컨테이너 실행 후 kubelet이 컨테이너를 주기적으로 진단함.

이에 필요한 프로브는 두가지임.

 

• livenessProbe
  컨테이너가 실행되었는지 확인.
  이 진단이 실패하면 kubelet은 컨테이너를 종료시키고, 재시작 정책에 따라서 컨테이너를 재시작함.
• readinessProbe
  컨테이너가 실행된 후 실제로 서비스 요청에 응답할 수 있는지 진단함.
  이 진단이 실패하면 엔드포인트 컨트롤러는 해당 파드에 연결된 모든 서비스를 대상으로 엔드포인트 정보를 제거함.
  
  

실제 트래픽을 받을 준비가 되었는 지 확인 후, 트래픽을 받을 수 있음.

컨테이너 진단은 컨테이너가 구현한 핸들러를 kubelet이 호출해서 실행함.

핸들러에는 3가지가 있음.

• ExecAction
  컨테이너 안에 지정된 명령을 실행하고 종료 코드가 0일때 Success라고 진단
• TCPSocketAction
  컨테이너 안에 지정된 IP와 포트로 TCP 상태를 확인하고 포트가 열려 있으면 Success라고 진단함
• HTTPGetAction
  컨테이너 안에 지정된 IP, 포트, 경로로 HTTP GET 요청을 보냄

5.5 초기화 컨테이너

 

앱 컨테이너가 실행되기 전 파드를 초기화함.

 

여러개 구성 가능

초기화 컨테이너 실행이 실패하면 성공할 때까지 재시작함. (명령을 순서대로 실행하는데 사용됨)

초기화 컨테이너가 모두 실행된 후 앱 컨테이너 실행이 시작됨. 

(단, 초기화 컨테이너는 readinessProbe를 지원하지 않음)

5.6 파드 인프라 컨테이너

 

쿠버네티스에는 모든 파드에서 항상 실행되는 pause라는 컨테이너가 있음

이를 ‘파드 인프라 컨테이너’ 라 함

pause는 파드 안 기본 네트워크로 실행되며, 컨테이너의 부모 컨테이너 역할을 함.

 

파드 안 다른 컨테이너가 재시작됐을 떄는 파드의 IP를 유지하지만, pause컨테이너가 재시작되면 파드 안 모든 컨테이너도 재시작됨

 

5.7 스태틱 파드

 

Kube-apiserver를 통하지 않고 kubelet이 직접 실행하는 파드

‘—pod-manifest-path’라는 옵션에 지정한 디렉터리에 스태틱파드로 실행하려는 파드를 넣어두면 kubectl이 감지해서 파드로 실행함.

 

보통 시스템 파드를 실행하는 용도로 많이 사용함.

 

• Master node의 /etc/kubernetes/manifests 하위에는 yaml 파일들이 있는데 이 yaml 파일들은 마스터 노드가 실행시에 자동으로 생성되는 static pod들이다. 보통 etcd, api-server들이 있다.
• Node에 생성된 static pod를 지우기 위해서는 해당 노드에 가서 지워야 한다. 지우기 위해서는 노드 안에 있는 kubelet의 config파일(/var/lib/kubelet/config.yaml)에 있는 staticPod path값을 찾아서 path값에 있는 yaml파일을 지워야 함. kubectl로 지우면 다시 생성됨.
• edit이 불가능함.

 

kubectl run --restart=Never --image=busybox static-busybox --dry-run=client -o yaml --command -- sleep 1000 > /etc/kubernetes/manifests/static-busybox.yaml

 

-> 스태틱파드로 만들 yaml파일을 /etc/kubernetes/manifests
경로로 넣어줌

 

5.8 파드에 CPU와 메모리 자원 할당

 

Resources.requests : 최소 필요 자원 양

Resources.limits : 최대 사용가능한 자원 양

 

• OOMKilled 

Operator pod is killed because it is out of memory

 

자원할당을 수정할 시 

해당 파드의 yaml파일을 받아와 수정 후 apply함

 

5.9 파드에 환경 변수 설정하기

containers.env에 환경변수 설정가능 (name:value)

 value값을 참조하여 사용가능

 

5.10 파드 환경 설정 내용 적용하기

 

적용하기 : ‘Kubectl apply -f 파일이름’

환경변수 확인하기 : (컨테이너 안에 들어가서 확인해야 함)
‘ kubectl exec -it 팟 이름 sh ’

 

5.11 파드 구성 패턴

 

파드로 여러 개의 컨테이너를 묶어서 구성하고 실행할 때 패턴 적용 가능

 

1. 사이드카 패턴
   공통 부가 기능들은 사이드카 컨테이너를 추가해서 사용하기
   
   
2. 앰배서더 패턴
   파드 안에서 프록시 역할을 하는 컨테이너를 추가하기
   
   파드 안에서 외부서버에 접근할 때 내부 프록시에 접근하도록 설정하고
   실제 외부와의 연결은 프록시에서 알아서 처리하기
   
   
3. 어댑터 패턴
   파드 외부로 노출되는 정보를 표준화하는 어댑터 컨테이너를 사용함.

5.12 파드 명령어

 

‘ Kubectl get pod’ : (현재 네임스페이스의) 파드 확인

( —all-namespaces : 모든 네임스페이스의 파드를 찾기) (-o wide : 상세정보 보여주기)

‘ Kubectl run “파드이름” —image=“이미지” ‘ : 원하는 파드 생성
 ( -n “네임스페이스” ) ( --dry-run=client -o yaml > “yaml파일” )

‘ Kubectl describe “파드이름” ‘ : 파드의 자세한 내용 출력

‘ Kubectl delete “파드이름” ‘ : 파드 삭제

‘ Kubectl edit pod “파드이름” ‘ : 파드 설정파일 편집

 

• 스케줄링 될 노드 지정하기 (imperative exec X)

spec.nodeName에 적어주기