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 역할을 해주는것이다. 내부 -> 외부
'Cloud > Kubernetes' 카테고리의 다른 글
[따배쿠] 6-2. ReplicaSet(ReplicationController와의 차이점은?) 쿠버네티스 pod 개수 보장 (0) | 2022.02.05 |
---|---|
[따배쿠] 6-1 Controller - ReplicationController란? (0) | 2022.02.03 |
[따배쿠] pod,Container 정리와 Single / Multi Container Pod 생성 , pod 동작 flow (0) | 2022.01.28 |
[따배쿠 youtube] 쿠버네티스 아키텍쳐 ,namespace, (0) | 2021.04.26 |
[따배쿠 youtube] kubectl , container 동작 flow (0) | 2021.04.24 |