Cloud/Kubernetes

[따배쿠] livenessProbe(Self healing Pod), init container ,infra container , static Pod , pod에 resource 할당하기 , pod 환경변수 설정

Tony Lim 2022. 1. 31. 14:51
728x90

  livenessProbe = 일종의 건강검진이다. Application 이나 Container의 상태를 지속적으로 확인한다.

지속적으로 포트 80번으로 Get Request를 보내서 잘 동작하는지 지속적으로 확인해준다.

하지만 각 application Container 마다 건강검진의 방식이 다를 것이다.

 

 

 

linvessProbe 매커니즘

httpGet probe = 지정한 IP주소 , port , path 에 HTTP GET 요청을 보내 , 해당 컨테이너가 응답하는 지 확인한다. 반환코드가 200이 아닌 값이 나오면 오류라 생각하고 컨테이너를 다시 시작한다.

nginx , nodejs , apache 등등

tcpSocket probe = 지정한 포트에 TCP 연결을 시도 , 연결되지 않으면 컨테이너를 다시 시작한다.

sshd(port 22) , nfsd (port 2049)등등 

exec probe = exec 명령을 전달하고 명령의 종료코드가 0이 아니면 컨테이너를 다시 시작한다. 

건강하지않은 Container는 kill 해버리고 Docker Hub에서 정상 Container를 restart 해준다.

db에 데이터 file 이 존재하는가 확인을 해줄때 

 

livenessProbe 매개변수

  • periodSeconds = health check 반복 실행 시간(초)
  • initialDelaySeconds = Pod 실행 후 delay 할 시간(초)
  • timeoutSeconds = health check 후 응답을 기다리는 시간(초)
  • failureThreshold = 실패라고 인정하는 응답실패 횟수
  • succesThreshold = 성공이라고 인정하는 응답성공 횟수

unhealthy 로 판단이 스면 kill 하고 새 container를 실행시켜준다.

 

 

 

Init container

 pod 안에 init container가 먼저 실행되어야 같은 pod 안에 있는 main container 가 실행된다. init이 실행이 실패하면 main 은 실행되지 않는다.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

until 을 이용해서 myservice, mydb 가 제대로 동작중이지 않으면 계속 반복한다. 동작 될때 까지. 실행이 잘 되는 순간 종료된다. db 도 마찬가지이다. 

myservice 와 mydb가 실행이 잘되면 myapp-container가 실행이 된다. 즉 main container가 원하는 환경이나 서비스가 잘 구축이 되어있으면 실행해주겠다 이런 이야기다.

 

Infra Container

pod 가 생성되는 순간 기본적으로 pause container가 pod 내의 인프라(ip, 이름 등등)를 구축하기위해 같이 생성된다. container 2개여도 하나만 생김

watch 에는 안나오지만 직접 node2 에 접속해서 실행되고 있는 container들을 조회해보면 /pause가 존재하는 것을 확인할 수 있다.

webserver pod 를 delete하면 같이 사라진다.

 

 

static Pod

기존의 Pod들은 master node의 API에게 요청을 보내고(kubectl 을 통해서) 그 안에서 scheduler 가 적절한 노드를 지정해주면 거기에다 Pod를 실행 시키는 방식이었다.

static pod 는 각 worker node 안에 kubelet daemon 이 돌아가는데 이것이 관리하는 static pod directory 가 있는데 여기에다가 알맞은 yaml 형식으로 써서 집어넣어주면 알아서 실행 시켜준다. master node 의 api의 도움이 필요없다.

보통 /etc/kubernetes/manifests 가 directory 주소다. 제대로 확인하기위 해서는 /var/lib/kubelet/config.yaml 에서 staticPodPath 를 확인하면 된다.

nginx image를 yaml 형식으로 /etc/kubernetes/manifests/ 에다가 저장하는 순간 위의 세션에서 nginx가 바로 실행이 되는것을 확인할 수 있다.

static pod 를 만드는 directory 가 맘에 들지 않으면 위의 config.yaml 의 staticPodPath를 수정한후에 kubectl daemon을 다시 재실행 시키면된다. systemctl restart kubelet

만약 master node의 static pod directory에 yaml 하나 넣으면 worker node 중 적절한곳에서 pod를 실행시킨다.

master node에 들어있던 api, controller , scheduler 가 다 static pod로 실행이 된 것이다.

 

 

Pod에 Resource (CPU ,Memory) 할당 하기 

각각의 worker node 들은 컴퓨터이기 때문에 CPU , memory 를 고유하게 가지고 있다. 이에 대해 해당 node 의 각각 의 pod 에 리소스를 제한을 두어야한다. 그렇지않으면 한개의 pod가 모든 node 의 리소스를 독점할 수 있기 때문이다. == 
이것을 Resource Limit 이라한다.

리소스를 초과해서 사용되면 해당 pod는 종료(OOM kill)되며 다시 스케줄링 된다.

 

master node 에 Scheduler 가 pod를 새로 배치하려고할 때 최소 얼마정도 필요한지 requirement 를 알게 할 수 있다. == 이것을 Resource request 라고 한다.

pod를 실행할떄 yaml 파일에 추가로 설정을 해주는 방식으로 리소스 제한및 최소요구사항을 걸 수 있다.

이떄 1MB = 1000KB , 1MiB = 1024KiB 임으로 쿠버네티스는 뒤의 B를 때서 Mi의 단위로 용량을 표시한다.

cpu 1코어는 1000m 이다.

너무 많은 resource 를 request하게 되면 Status 가 pending 상태가되면서 알맞은 공간이 나올때까지 대기한다.

limit만 걸어주면 그에 맞게 request가 저절로 생성된다. 하지만 request만 설정한 경우에는 limit이 자동생성 되지 않는다.

 

 

Pod의 환경변수 설정하기

kubectl exec nginx-pod-env -it -- /bin/bash  명령어를 통해 bash 로 접속한후 env 명렁어로 환경변수 MYVAR=testvalue 인것을 확인 할 수 있다.

 

pod 구성 패턴의 종류

sidecar = app container가 로그를 쓰면 그 로그를 bucket에 저장함 즉 1개의 컨테이너가 실행된후에 sidecar가 일을 할 수 있음

adapter = 밖에 있는것을 가공해서 appcontainer에게 전달해줌 , 외부 -> 내부

ambassador = Load balancer 역할을 해주는것이다. 내부 -> 외부

728x90