[Kubernetes] init & infra container / static pod

Init container

• 앱 컨테이너 ( = 본 컨테이너) 실행 전에 미리 동작시킬 컨테이너
  • 앱 컨테이너가 실행되기 전에 사전 작업이 필요한 경우 사용한다
  • ex) nginx 동작 전에 db가 동작하고 있어야 하는 경우
• 초기화 컨테이너 ( = init 컨테이너)는 여러 개일 수 있고, 초기화 컨테이너가 모두 실행된 후 app 컨테이너가 실행된다.

실습

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: 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"]

=> init_container_exam.yaml 로 저장

위의 예시에서 myapp-container가 본 컨테이너이고 본 컨테이너 실행 전 실행되야하는

초기화 컨테이너가 init-myservice, init-mydb 두 개가 있다.

yaml 파일로 pod 생성

kubectl apply -f init_container_exam.yaml

상태 보기

kubectl get -f init_containe_exam.yaml

아직 init container가 실행되지 않았기 때문에 myapp-pod도 실행상태가 아닌 것을 확인할 수 있다.

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

init container를 실행하기 위해 services.yaml파일을 만들어주고 해당 파일로 pod를 생성해준다.

kubectl apply -f services.yaml

그러면 myservice pod와 mydb pod가 생성되고 본 컨테이너인 my-app container가 실행된다!

 

Init Containers

 

 

 

Infra container (pause)

• pod가 생성될 때 마다 매 pod에 생성되는 container로 해당 pod의 ip, host name 등 인프라를 구성하기위해 필요한 컨테이너이다.

실습

실제로 infra container를 확인해보기 위해 예제 파드를 하나 생성한다

# master
kubectl run webserver --image nginx:1.14 --port=80

예제 파드가 생성되면 그 파드가 실제로 어떤 노드에서 작동 중인지 확인한다.

# master
kubectl get pods -o wide

나의 경우 webserver pod는 node2에서 작동중이어서 node2로 이동해주었다.

node2에서 실행 중인 컨테이너를 확인해보자.

# node2
docker ps

docker ps는 실행 중인 컨테이너 목록을 보여주는 명령어다. permission error가 난다면 sudo를 붙여서 실행하자

출력결과 상단 2 컨테이너가 동일시점에 생성되었고 두 번째 컨테이너가 pause로 확인되어 nginx를 생성하는 동시에 같이 infra container가 실행된 것을 확인할 수 있다.

 

 

 

Static pod

• kubelet daemon에 의해 관리되는 pod
• 일반적인 pod의 동작방식과 다르게 master node의 api서버 없이, api에 요청을 보내지 않고 특정 노드에 있는 kubelet daemone에 의해 직접 관리되는 pod이다.
• 정해진 디렉토리에 k8s yaml 파일을 저장하면 바로 생성되고 지우면 없어진다.
• 기본 staticpod directory는 etc/kubernetes/manifests/ 이다.

실습

먼저 shell을 두 개 띄우고, master node에서 kubectl get pods -o wide --watch 커맨드로 생성되는 pod를 모니터링 해준다.

 

또 다른 shell에서는 원하는 노드로 이동해서 staticPodPath를 확인한다.

cat /var/lib/kubelet/config.yaml

 

staticPodPath는 config.yaml 파일 변경으로 가능하다.

path를 변경하고 싶다면 config 파일을 변경하고 systemctl restart kubelet으로 데몬을 재실행하면 적용된다.

 

 

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.14
    ports:
    - containerPort: 80
      protocol: TCP

간단한 웹서버 pod를 만드는 yaml파일을 생성해주고 staticPodPath로 이동시킨다.

mv nginx.yaml /etc/kubernetes/manifests/

staticPodPath로 파일이 옮겨짐과 동시에 pod가 생성되는 것을 마스터 노드의 shell에서 확인할 수 있다.

rm nginx.yaml

해당 위치에서 파일을 삭제하면 바로 pod가 삭제되는 것도 확인할 수 있다.

 

 

※ master node의 static pod

마스터 노드에는 이미 static pod가 구성되어있는데, 확인해보면 etcd, scheduler, api-server 등 쿠버네티스 클러스터를 운영하는데 필요한 것들이 정의되어 있다.

그리고 master노드에 메이페스트 경로에 nginx.yaml(커스텀 yaml)을 위치시키면 이 파일로 생성되는 pod는 master가 아닌 node들 중 하나에 배치된다.