[Kubernetes] 12. 쿠버네티스 리소스 오브젝트들 및 생성 방법

[주의] 개인 공부를 위해 쓴 글이기 때문에 주관적인 내용은 물론, 쓰여진 정보가 틀린 것일 수도 있습니다!

피드백 부탁드립니다. (- -)(_ _) 꾸벅

 

 

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run

Kubectl Reference Docs

 

위 레퍼런스 독 참조

---

[ 축약어 ]

아래 약어 사용이 가능하며, 기본적으로 s 생략을 허용한다

• pods : po
• deployments : deploy
• services : svc
• replicasets : rs
• replicationcontollers : rc
• configmaps : cm
• namespaces : ns
• nodes : no
• persistentvolumeclaims : pvc
• persistentvolumes : pv
• resourcequotas : quota
• serviceaccounts : sa
• daemonsets : ds
• cronjobs : cj
• ingresses : ing
• storageclasses : sc

---

[ POD ]

[ Usage ]

 

$ kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client] [--overrides=inline-json] [--command] -- [COMMAND] [args...]

 

# 예시

eshop-main 이라는 pod를 namespace ecommerce에다 nginx 1.17버전의 이미지를 이용하여 생성하고 환경변수로 DB=mysql을 전달하는 yaml를 작성하시오.

$ kubectl run eshop-main --image=nginx:1.17 --namespace ecommerce --env=DB=mysql --dry-run=client -o yaml

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: eshop-main
  name: eshop-main
  namespace: ecommerce
spec:
  containers:
  - env:
    - name: DB
      value: mysql
    image: nginx:1.17
    name: eshop-main
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

 

• pod, service 등 오브젝트 파일을 작성해야 할 때 오브젝트를 실제로 생성하지 않고 작업하고 싶다면 --dry-run=client를 사용하면 된다.
• -o yaml 은 해당 명령을 yaml 형식으로 출력하고 싶을 때 사용한다.

실제로 yaml 파일을 작성하여 배포하는 것보다 위처럼 명령형 커맨드를 사용하여 yaml 파일을 생성 후 배포하는 것이 이상적이다.

 

 

[ Static Pod ]

kubelet 에서 API 서버의 요청과는 상관 없이 특정 디렉토리 안의 Pod YAML 정의서를 바라보고 직접 생성하는 Pod를 의미. 

sudo cat /var/lib/kubelet/config.yaml

• kubeadm으로 쿠버네티스 클러스터 구축시, Static Pod의 default 디렉토리는 /etc/kubernetes/manifest

 

[ Init container ]

Pod가 실행될 때 main 컨테이너가 실행되기 전 먼저 실행되는 컨테이너
설정 스크립트 등 컨테이너가 실행되기 전에 해야되는 작업 (Pod 환경 구성 설정 등)

항상 완료 상태를 목표로 실행되며, 완료 상태가 되어야 main 컨테이너가 동작한다.

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
  - image: busybox:1.28
    name: main
    command: ['sh','-c','if [ !-f /workdir/data.txt ];then exit 1;else sleep 300;fi']
    volumeMounts:
    - name: workdir
      mountPath: "/workdir"
  initContainers:
  - name: init
    image: busybox:1.28
    command: ['sh', '-c', "touch /workdir/data.txt"]
    volumeMounts:
    - name: workdir
      mountPath: "/workdir"
  volumes:
  - name: workdir
    emptyDir: {}

위 init Container는 두 컨테이너 동시에 마운트한 /workdir 안에 data.txt 파일을 생성해준다.

그러므로써 main 컨테이너의 command가 오류나지 않고 실행될 수 있는 것 

---

[ Scale ]

Deployment나 Replica set 등의 크기를 다시 지정한다.

 

[ Usage ]

$ kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=개수 (-f FILENAME | TYPE NAME)

 

# 예시

아래 Deployment를 생성한다.

• 이름: webserver
• 2 replicas
• label: app_env_stage=dev
• container name: webserver
• container image: nginx:1.14

추후 위 Deployment를 3개의 pod로 Scale out 해라.

 

$ kubectl create deployment webserver --image=nginx:1.14 --replicas=2 --dry-run=client -o yaml > webserver.yaml
$ kubectl apply -f webserver.yaml
deployment.apps/webserver created

 

- Scale out  (yaml 파일을 수정하는 법도 있다)

$ kubectl scale deployment webserver --replicas=3
deployment.apps/webserver scaled

 

---

[ Set ]

설정 가능한 Sub-Command들

• env
• image
  
  [ Usage ]
  $ kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N
  
  # 예시
  이름: nginx-app 컨테이너
  버전: 1.11.10-alpine
  3 replicas
  위의 deployment를 새로운 버전 1.11.13-alpine 으로 롤링 업데이트 하고, 업데이트 상태를 확인한 후, 이전 버전인 1.11.10-alpine으로 롤백해보기.
  
  master@master:~$ kubectl set image deployment nginx-app nginx=nginx:1.11.13-alpine --record
  deployment.apps/nginx-app image updated
  --> nginx 컨테이너가하나씩 Rolling Update 된다.
  
  master@master:~$ kubectl rollout status deployment nginx-app
  deployment "nginx-app" successfully rolled out
  --> nginx-app 디플로이먼트가 성공적으로 롤 아웃 되었다는 상태 출력
  
  master@master:~$ kubectl rollout history deployment nginx-app
  --> 업데이트 내역 확인
  
  master@master:~$ kubectl rollout undo deployment nginx-app
  deployment.apps/nginx-app rolled back
  --> Rollback 하여 1.11.10-alpine 버전으로 돌아감.
• resources
• selector
• serviceaccount
• subject

---

[ logs]

Pod 또는 지정된 리소스의 컨테이너에 대한 로그를 인쇄

Pod에 컨테이너가 하나만 있는 경우 컨테이너 이름은 선택 사항이다.

 

[ Usage ]

kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]

---

[ rollout ]

설정 가능한 Sub-Command들

• history
• pause
• restart
• resume
• status 
  [ Usage ]
  $ kubectl rollout status (TYPE NAME | TYPE/NAME) [flags]
  
  # 예시
  이름: nginx-app 컨테이너
  버전: 1.11.10-alpine
  3 replicas
  위의 deployment를 새로운 버전 1.11.13-alpine 으로 롤링 업데이트 하고, 업데이트 상태를 확인한 후, 이전 버전인 1.11.10-alpine으로 롤백해보기.
  
  master@master:~$ kubectl set image deployment nginx-app nginx=nginx:1.11.13-alpine --record
  deployment.apps/nginx-app image updated
  --> nginx 컨테이너가하나씩 Rolling Update 된다.
  
  master@master:~$ kubectl rollout status deployment nginx-app
  deployment "nginx-app" successfully rolled out
  --> nginx-app 디플로이먼트가 성공적으로 롤 아웃 되었다는 상태 출력
  
  master@master:~$ kubectl rollout history deployment nginx-app
  --> 업데이트 내역 확인
  
  master@master:~$ kubectl rollout undo deployment nginx-app
  deployment.apps/nginx-app rolled back
  --> Rollback 하여 1.11.10-alpine 버전으로 돌아감.
• undo

---

[ cordon ]

노드를 unschedulable 상태로 만는 명령

이미 돌아가는 파드들은 계속 돌아가지만, 스케줄링을 막기 때문에 새로 파드를 배치하지 못한다.

 

[ Usage ]

$ kubectl cordon NODE

$ kubectl uncordon NODE

 

# 예시

$ kubectl cordon worker
node/worker cordoned

$ kubectl get nodes
NAME     STATUS                     ROLES                  AGE     VERSION
master   Ready                      control-plane,master   6d21h   v1.21.5
worker   Ready,SchedulingDisabled   <none>                 6d21h   v1.21.5

$ kubectl uncordon worker
node/worker uncordoned

cordon을 하면 상태가 SchedulingDisabled가 된다.

uncordon을 통해 해제 가능

 

---

[ drain ]

노드 관리를 위해 해당 노드에 있는 파드들을 다른 노드로 옮기는 명령

• 해당 명령은 노드에서 파드를 삭제하고 다른 노드에 생성하므로 삭제해도 계속 생기는 Demonset 파드가 있는 경우 --ignore-daemonsets 파라미터 없이는 진행되지 않는다.
• 컨트롤러(replica set, stateful set 등)에 의해 생성된 파드가 아닌 파드만으로 생성된 파드들은 삭제되면 그것으로 끝이라 drain이 진행되지 않기에 강제로 삭제려면 --force 옵션을 주고 실행하면 된다.
• 컨테이너가 스토리지를 사용 중인 경우 삭제가 안되므로 사용중인 데이터 디렉터리까지 지우는 --delete-emptydir-data 옵션을 추가해야한다.
• Static 파드들은 삭제 되지 않는다.

 

$ kubectl drain worker --ignore-daemonsets --force --delete-emptydir-data
node/worker already cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-flannel/kube-flannel-ds-jrzfz, kube-system/kube-proxy-6f2t6; deleting Pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet: default/eshop-cart-app
evicting pod default/nginx-app-fc7875d8-xt97w
pod/nginx-app-fc7875d8-xt97w evicted
node/worker evicted

$ kubectl get nodes
NAME     STATUS                     ROLES                  AGE     VERSION
master   Ready                      control-plane,master   6d23h   v1.21.5
worker   Ready,SchedulingDisabled   <none>                 6d22h   v1.21.5

drain 후 pod들은 삭제되고, 노드의 상태는 SchedulingDisabled로 변한다.

 

---

명령 필요할 때 마다 야금야금 쓰는중.....