쿠버네티스 파드 관련 기본 명령어

파드 생성

kubectl run <pod name> --image=<pod image>

(이미지는 docker hub 등 설정된 레포에서 가져옴)

 

deployment 그룹의 파드 생성

kubectl create deployment <pod name> --image=<pod image>

 

deployment 그룹의 파드 레플리카 생성

kubectl scale deployment <pod name> --replicas=<# of replicas>

vagrant@m-k8s:~$ kubectl get pods
NAME                         READY   STATUS              RESTARTS   AGE
dpy-nginx-58b7459b9f-8hh88   1/1     Running             0          8m7s
dpy-nginx-58b7459b9f-llfbw   1/1     Running             0          24m
dpy-nginx-58b7459b9f-vcqwm   1/1     Running             0          8m7s
nginx-pod                    1/1     Running             0          27m

 

deployment 그룹 내의 파드 삭제 

kubectl delete deployment <pod-name>

 

run : 단일 파드 1개만 생성, 관리

create deployment : deployment 그룹에서 관리되는 파드를 생성

---

object : pod, deployment를 개별 속성 (spec, status 등) 을 포함해 부르는 단위 

pod : 쿠버네티스에서 실행되는 최소 단위, 일반적으로 1개의 pod에 1개의 컨테이너를 적용 (여러 컨테이너 묶어서 1개의 파드 구성해도 됨) 

namespace : 클러스터에서 사용되는 리소스들을 구분해 관리하는 그룹

- default : 기본 할당되는 네임스페이스

- kube-system : 쿠버네티스 시스템에서 사용되는 네임스페이스 

- metallb-system : 온프레미스에서 쿠버네티스 사용 시, 외부에서 쿠버네티스 클러스터 내부로 접속하게 도와주는 컨테이너들이 속한 네임스페이스 

volume : pod에서 사용할 수 있는 디렉토리

service : 새로 pod가 생성될 때 부여되는 새로운 ip를 기존 제공하던 기능과 연결해 주는 역할. 로드밸런서, 게이트웨이와 유사한 역할. 

---

 

파일로 object 생성하기

 

간단한 nginx 이미지의 파드 3개 생성하기 

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: echo-hname
  labels:
    app: nginx 
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx 
  template:
    metadata:
      labels:
        app: nginx 
    spec:
      containers:
      - name: echo-hname 
        image: sysnet4admin/echo-hname

 

쿠버네티스에서 사용 가능한 api version 확인

kubectl api-versions

kind : apps/v1에서 사용 가능한 오브젝트 중 하나 (여기서는 Deployment 선택) (Service, ReplicaSet 등도 있음)

metadata : deployment 이름 및 레이블 

spec : 

- replicas : 레플리카 개수 설정 

- selector : 셀렉터 레이블 지정 (셀렉터 : 쿠버네티스 리소스가 어떤 파드를 대상으로 동작할 지 파드를 선택. selector.matchLabels.app 이름과 template.metadata.labels.app 이름이 동일해야 함)

- template : 파드의 템플릿

-- metadata : 파드에 적용할 앱 이름 

-- spec : 파드를 구성하는 스펙 지정

 

yaml 파일 이용해 파드 생성

kubectl create -f <yaml file path>

 

yaml 파일 수정 후 파드에 변경 사항 반영

kubectl apply -f <yaml file path>

 

아래는 처음에 3개의 레플리카 설정하여 파드 생성 후, 5개로 늘린 상황

vagrant@m-k8s:~$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
echo-hname-7ff5b6b7bc-dmckk   1/1     Running   0          112s
echo-hname-7ff5b6b7bc-f5fmr   1/1     Running   0          112s
echo-hname-7ff5b6b7bc-lfng6   1/1     Running   0          112s
echo-hname-7ff5b6b7bc-p655q   1/1     Running   0          12s
echo-hname-7ff5b6b7bc-rl2hv   1/1     Running   0          12s

 

변경 사항이 발생 가능성이 있는 프로젝트는 처음부터 apply로 생성하는 것이 좋음

---

pod 동작 보증 확인 

 

run으로 default 그룹에 속한 단일 pod의 경우, 삭제 후 자동으로 재생성되지 않지만, deployment 그룹에 속한 pod의 경우, 삭제 시, replicas 수에 맞게 재생성됨

 

따라서, depolyment로 pod를 생성해야만 pod의 동작을 보증할 수 있음 (문제 시 삭제 후 재생성) 

deployment에 속한 pod 삭제하려면 상위 deployment 자체를 삭제해야 함

 

kubectl delete deployment echo-hname

 

---

배포된 파드 세부 내용 확인

 

파드의 세부 값을 yaml 파일로 확인할 수 있다. 

 

kubectl get pod <pod name> -o yaml > <yaml file path> 

---

(여기 아래부터는 docker desktop에 클러스터 구성함) 

 

cordon : 특정 노드에 더 이상 파드를 할당하지 않는 기능. 장애가 자주 발생하거나, 리소스 문제 등이 있는 경우 적용하면 된다. 

➜ ✗ kubectl cordon desktop-worker3
node/desktop-worker3 cordoned
➜ ✗ kubectl get nodes
NAME                    STATUS                     ROLES           AGE   VERSION
desktop-control-plane   Ready                      control-plane   40m   v1.31.1
desktop-worker          Ready                      <none>          39m   v1.31.1
desktop-worker2         Ready                      <none>          39m   v1.31.1
desktop-worker3         Ready,SchedulingDisabled   <none>          39m   v1.31.1

 

cordon 설정하여 SchedulingDisabled 상태를 갖고 있으므로, 이후 scale out하여도 3번 노드에는 파드가 할당되지 않는다. 

➜ ✗ kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP           NODE              NOMINATED NODE   READINESS GATES
echo-hname-67548d9ccc-cnhtg   1/1     Running   0          29m   10.244.1.2   desktop-worker    <none>           <none>
echo-hname-67548d9ccc-crtvc   1/1     Running   0          29m   10.244.2.2   desktop-worker2   <none>           <none>
echo-hname-67548d9ccc-ffnxp   1/1     Running   0          10s   10.244.2.5   desktop-worker2   <none>           <none>
echo-hname-67548d9ccc-qvc7f   1/1     Running   0          10s   10.244.1.6   desktop-worker    <none>           <none>
echo-hname-67548d9ccc-rchsx   1/1     Running   0          10s   10.244.2.6   desktop-worker2   <none>           <none>
echo-hname-67548d9ccc-rrfr9   1/1     Running   0          29m   10.244.3.2   desktop-worker3   <none>           <none>

(uncordon : cordon 해제) 

 

drain : 파드를 옮기는 명령어 (실제로는 삭제 후 다른 노드에 재생성) 

➜ ✗ kubectl drain desktop-worker3 --ignore-daemonsets
node/desktop-worker3 already cordoned
Warning: ignoring DaemonSet-managed Pods: kube-system/kindnet-gz2rw, kube-system/kube-proxy-phpx7
evicting pod default/echo-hname-67548d9ccc-rrfr9
pod/echo-hname-67548d9ccc-rrfr9 evicted
node/desktop-worker3 drained
➜ ✗ kubectl get pods -o wide                         
NAME                          READY   STATUS              RESTARTS   AGE   IP           NODE              NOMINATED NODE   READINESS GATES
echo-hname-67548d9ccc-cnhtg   1/1     Running             0          40m   10.244.1.2   desktop-worker    <none>           <none>
echo-hname-67548d9ccc-crtvc   1/1     Running             0          40m   10.244.2.2   desktop-worker2   <none>           <none>
echo-hname-67548d9ccc-ffnxp   1/1     Running             0          11m   10.244.2.5   desktop-worker2   <none>           <none>
echo-hname-67548d9ccc-qvc7f   1/1     Running             0          11m   10.244.1.6   desktop-worker    <none>           <none>
echo-hname-67548d9ccc-rchsx   1/1     Running             0          11m   10.244.2.6   desktop-worker2   <none>           <none>
echo-hname-67548d9ccc-zjtbc   0/1     ContainerCreating   0          4s    <none>       desktop-worker    <none>           <none>

 

데몬셋은 노드 별로 1개만 존재하므로 삭제가 불가능하다. 그러므로 --ignore-daemonsets 옵션을 추가해야지 pod를 다른 노드로 옮길 수 있다. 

drain된 워커 노드는 자동으로 cordon 된다. (SchedulingDisabled status)

➜ ✗ kubectl get nodes
NAME                    STATUS                     ROLES           AGE   VERSION
desktop-control-plane   Ready                      control-plane   53m   v1.31.1
desktop-worker          Ready                      <none>          53m   v1.31.1
desktop-worker2         Ready                      <none>          53m   v1.31.1
desktop-worker3         Ready,SchedulingDisabled   <none>          53m   v1.31.1

---

--record : deployment 히스토리 기록

rollout history : record 옵션으로 기록된 히스토리 내용 확인

➜ ✗ kubectl apply -f rollout-nginx.yaml --record
Flag --record has been deprecated, --record will be removed in the future
deployment.apps/rollout-nginx created
➜ ✗ kubectl rollout history deployment rollout-nginx
deployment.apps/rollout-nginx 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=rollout-nginx.yaml --record=true

 

기존 yaml 파일

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollout-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.12

 

set image : 파드에 사용한 컨테이너 이미지 설정

1.16.0 nginx로 업데이트

➜ ✗ kubectl set image deployment rollout-nginx nginx=nginx:1.16.0 --record
Flag --record has been deprecated, --record will be removed in the future
deployment.apps/rollout-nginx image updated

 

버전 업데이트 시, 파드 내에서 버전 업데이트가 되는 것이 아닌, 기존 파드는 지우고, 새로 파드를 생성하는 방식으로 업데이트가 이루어짐. 따라서 아래와 같이 파드가 새로 생성 중임을 알 수 있음

➜ ✗ kubectl get pods
NAME                             READY   STATUS              RESTARTS   AGE
rollout-nginx-69495fcbf7-2drjb   1/1     Running             0          34s
rollout-nginx-69495fcbf7-bblv9   1/1     Running             0          15s
rollout-nginx-69495fcbf7-nmdxc   0/1     ContainerCreating   0          2s
rollout-nginx-745556647c-5mx6w   1/1     Running             0          24m

 

파드 복구하기

- 의도적으로 없는 이미지 버전인 1.17.23 으로 업데이트 후, 상태 확인

(rollout status : deployment의 상태 확인)

➜ ✗ kubectl rollout status deployment rollout-nginx
Waiting for deployment "rollout-nginx" rollout to finish: 1 out of 3 new replicas have been updated...

 

계속 대기 중인 상태가 유지되므로, rollout history 로 리비전 확인 후, rollout undo 로 이전 리비전으로 파드 복구 가능

➜ ✗ kubectl rollout history deployment rollout-nginx
deployment.apps/rollout-nginx 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=rollout-nginx.yaml --record=true
2         kubectl set image deployment rollout-nginx nginx=nginx:1.16.0 --record=true
3         kubectl set image deployment rollout-nginx nginx=nginx:1.17.23 --record=true

 

직전인 2번으로 돌리면 2번이 4번 리비전으로 됨

➜ ✗ kubectl rollout undo deployment rollout-nginx
deployment.apps/rollout-nginx rolled back
➜ ✗ kubectl rollout history deployment rollout-nginx
deployment.apps/rollout-nginx 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=rollout-nginx.yaml --record=true
3         kubectl set image deployment rollout-nginx nginx=nginx:1.17.23 --record=true
4         kubectl set image deployment rollout-nginx nginx=nginx:1.16.0 --record=true

 

(특정 리비전으로 롤백하려면 --to-revision=1 과 같이 옵션 추가하면 됨)