[따배쿠] 9. Pod

[따배쿠] 9. Pod

( 참고 : 따배쿠 https://www.youtube.com/watch?v=6n5obRKsCRQ&list=PLApuRlvrZKohaBHvXAOhUD-RxD0uQ3z0c )

Contents

1. Pod 개념 및 사용하기
2. livenessProbe를 사용한 self-healing Pod
3. init container
4. infra container(pause)
5. static pod
6. pod에 resource 할당하기
7. 환경변수를 이용해 container에 데이터 전달하기
8. pod 구성 패턴의 종류

1. Pod 개념 및 사용하기

(1) Pod란?

• Pod = 컨테이너를 표현하는 k8s API의 “최소 단위”
  • ex) docker : appjs 컨테이너 실행해줘!
  • ex) k8s : appjs Pod 실행해줘!

(2) Pod 생성하기

방식 1) CLI

kubectl run

• ex) kubectl run webserver --image=nginx:1.14

방식 2) YAML 파일

kubectl create -f

• ex) kubectl create -f pod-nginx.yaml

(3) 동작 중인 Pod 확인

• kubectl get pods
• kubectl get pods -o wide
• kubectl get pods -o yaml
• kubectl get pods -o json
• kubectl get pods webserver -o json | gre -i podip
  • podip 정보만 가져오기
  • curl <ip주소> 로 접속해보기

(4) multi-container pod

• pod안에 container가 여러 개 들어갈 수 있음 ( 단, ip는 하나 )

  • ex) 웹서버 & 웹서버의 로그를 수집하는 컨테이너 1개씩

• YAML파일 안에, 2개의 container 넣기

  • apiVersion

  • kind

  • metadata

  • spec

    • containers :

      • name : xxx

        …

      • name : yyy

        …

실행하는 방법은, 위의 (단일) pod와 동일

다만, pod 내의 특정 container을 지정해서 접속하려면? 로그를 확인하려면?

• kubectl exec multipod -it -c container1 -- /bin/bash
• kubectl logs multipod -c nginx-container

2. livenessProbe를 사용한 self-healing Pod

goal : kubelet으로 container 상태를 진단하자!

Pod vs livenessProbe

• Pod가 계속 실행할 수 있음을 보장
• Pod의 yaml파일의 “spec”에 정의됨

• (좌) self-healing 기능 (X)

• (우) self-healing 기능 (O)

  • livenessProbe를 통해서 건강 검진!

    • 그 중에서도, httpGet를 통해서!

      ( 80 포트로 접속, 응답이 잘 되면 건강O, 안되면 건강 X)

    • m초마다 건강 검진, n번 연속 실패하면 FAIL로 간주하고 죽이기!

      + 건강한 container RESTART

livenessProbe 메커니즘

• httpGet : 지정한 IP주소,port,path에 HTTP GET 요청을 보냄
  • 해당 container의 응답이 200값이 아니면, container 다시 시작
• tcpSocket : 지정된 port에 TCP 연결을 시도
  • 연결되지 않으면, container 다시 시작
• exec : exec 명령어를 전달
  • 종료코드가 0이 아니면, container 다시 시작

liveness Probe 매개변수

( 안쓰면 default값으로 적용 )

• periodSeconds : health check 반복 실행 시간 (초)

  ( 얼마마다 한번 씩 health check을 할 건지 )

  ( 너무 짧아도, 너무 길어도 X )

  • default : 10

• initialDelaySeconds : Pod 실행 후 delay 할 시간 (초)

  • default : 0

• timeoutSeconds : health check 후 응답을 기다리는 시간 (초)

  • default : 1

• successThreshold : 정상으로 간주하는 연속 “성공” 횟수

  • default : 1

• failureThreshold : 비정상으로 간주하는 연속 “실패” 횟수

  • default : 3

3. init container

init container :

• app(main) container를 실행시키기 위해 필요한 초기 구성. 미리 동작시켜야!
• init container가 실행되지 못하면, main container도 실행 못함
• ex )
  • nodejs 애플리케이션 로그인 container
  • DB에서 로그인 관련 정보를 가져와야, 로그인 container 동작 가능!

example

• init container 1 : myservice가 실행되고
• init container 2 : mydb가 실행되어야
• 그제서야 main container가 실행될 것!

4. infra container (pause)

infra container :

• pod의 환경을 만들어주는 container

쿠버네티스는 최소 단위 “pod”로 관리함.

특정 pod를 실행할 때, 그 안에는 pause라는 infra container도 함께 실행됨

step 1) 아무런 pod 하나를 실행

• kubectl run webserver --image=nginx:1.14 --port=80

step 2) 해당 pod가 접속된 node에 접속

• ssh node2

step 3) nginx 컨테이너 뿐만 아니라, pause라는 컨테이너도 실행된 것을 알 수 있음

• docker ps

5. static pod

static pod는, 기존까지 운영해왔던 pod와는 약간 다르다.

• 일반 pod )
  • control-plane(=master)의 API 요청
  • master는 etcd의 정보 참고 & scheduler 도움으로, 지정된 worker node에 실행요청
• static pod )
  • API에게 요청 X
  • worker node에 있는 kubelet daemon들에게 직접!

static container

• “API 서버 없이”, 특정 node에 있는 kubelet 데몬에 의해 직접 관리

• /etc/kubernetes/manifests/ 디렉토리에 k8s yaml 파일 저장시 적용

  • 디렉토리 수정 시, kubelet 데몬 재실행하기!

    ( systemctl restart kubelet )

cat /var/lib/kubelet/config.yaml

• 확인해보면, 아래쪽에 staticPodPath : /etc/kubernetes/manifests가 적혀 있다. 이 안에 yaml파일을 넣으면, static pod가 실행된다!

step 1) 특정 node로 접속

step 2) cd /etc/kubernetes/manifests/

step 3) cat > nginx.yaml

• YAML 파일 작성하기.
• 이 yaml파일을 통해 생성된 pod는, master도움 없이 이 node에 의해서만 생성!

6. pod에 resource 할당하기

goal : Pod에 cpu, memory 할당하기

Pod Resource 요청 및 제한

• resource requests
  • pod를 실행하기 위한 최소 resource양 요청
• resource limits
  • pod가 사용할 수 있는 최대 resource양 제한
  • 한도 초과 시, 해당 pod는 종료(OOM kill)되며, 다시 scheduling됨

Container Resource 설정하기

위 처럼 YAML 파일 수정한 뒤, pod 실행하기

• kubectl create -f pod-nginx-resources.yaml

실행한 pod 확인!

• kubectl describe pod nginx-pod-resources

7. 환경변수를 이용해 container에 데이터 전달하기

환경변수란?

• pod 내의 container 실행을 위해 필요로 하는 변수
• container 제작 시, 미리 정의
  • ex) NGINX Dockerfile
    • ENV NGINX_VERSION 1.19.2
    • ENV NJS_VERSION 0.4.3
• pod 실행 시, 미리 정의된 container의 환경 변수 변경 가능

특정 container 안으로 들어가서, 환경 변수 확인하기

• kubectl exec nginx-pod-env -it -- /bin/bash
• env
  • 방금 위에서 정의한 환경 변수를 확인할 수 있다

8. pod 구성 패턴의 종류

pod를 어떻게 구성하느냐에 따라, 3가지로 구성 가능

multi-container pod

Sidecar

• 혼자서는 불가! log를 만들어내는 container가 있어야!

Adapter

• adapter가 “외부에 있는 정보”를 받아와서 web server container에 전달

Ambassador

• 고객들이 접속을 하면 남겨지는 정보를 ambassador가 분배시켜서 다른 곳( Production, Local, … )에 전달해줌