Kubernetes 노드/파드 운영을 위한 명령어(생성, 변경, 삭제, replica, cordon, drain)

Kubernetes 노드/파드 운영을 위한 명령어(생성, 변경, 삭, replica, cordon, drain)

 

Kubernetes 운영을 위한 기본 명령어

 

(1) Master node에서 노드 상태 확인

kubectl get nodes

 

 

(2)-1 설치된 쿠버네티스 파드구성요소 확인

  *옵션

  --all-namespaces : 모든 네임스페이스를 출력

  -o wide : -o는 output, wide는 출력정보를 더 많이 표시

kubectl get pod

 

(2)-2 설치된 쿠버네티스 파드구성요소 확인 : 컬럼 및 값 커스터마이징

  *-o=custom-columns=<컬럼명>:<내용 값>

kubectl get pods -o=custom-columns=NAME:.metadata.name,IP:.status.podIP,STATUS:.status.phase,NODE:.spec.nodeName

 

  *파드의 속성값을 보기 위해서는 아래와 같이 확인 가능하다.

# 해당 파드의 속성값을 가져오기
kubectl get pod echo-hname-7894b67f-9jkxs -o yaml > pod.yaml

# yaml 파일 확인
vi pod.yaml

 

 

(3)-1 파드 생성(2가지 방법)

# run으로 파드 생성하기
kubectl run nginx-pod --image=nginx


# create로 파드 생성하기
kubectl create deployment dpy-nginx --image=nginx

 

 - 차이점 : run으로 생성하면 단일 파드 1개만 생성되고 관리되지만, create deployment로 생성하면 관리그룹 내에서 파드가 생성된다. (create 권장)

 - 이미지는 도커 허브를 통해 받아오는 방식이다.

 

(3)-2 파드 생성(레플리카 셋) 

  · scale : 이미 만들어진 디플로이먼트를 활용해서 복제본 생성

# 디플로이먼트로 생성
kubectl scale deployment dpy-nginx --replicas=3


# 파드로 생성될 경우 디플로이먼트 오브젝트에 속하지 않아 리소스 확인 불가 에러 발생
kubectl scale pod nginx-pod --replicas=3

 

  · 오브젝트 스펙(yaml 파일)을 활용

 

# 예시) echo-hname.yaml

apiVersion: apps/v1   # API 버전
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: nginx/nginx   # 사용할 이미지

 

kubectl create -f <파일명>

kubectl create -f echo-hname.yaml

 

※ 이미 위의 방식으로 파드를 생성하였을 때, 레플리카 수를 변경하고 싶다면?

yaml의 replicas: 를 변경하고 동일하게 진행하면 에러가 발생한다. 이 때에는 apply를 사용한다.

kubectl apply -f <파일명>

kubectl apply -f echo-hname.yaml

 

(3)-3 파드 업데이트

컨테이너 버전 업데이트시 아래와 같이 배포 명령어를 실행한다. 이 때 --record 옵션을 넣어주어야 배포한 정보의 히스토리를 기록한다.

kubectl apply -f <파일명> --record

kubectl apply -f echo-hname.yaml --record

 

히스토리 확인은 아래의 명령어로 할 수 있다.

kubectl rollout history deployment rollout-nginx

 

*set image 명령으로 파드의 컨테이너 버전을 업데이트할 수도 있다. 아래 예시 명령어 확인

kubectl set image deployment rollout-nginx nginx=nginx:1.16.0 --record

 

*rollout 완료 후 Deployment 상태 확인

kubectl rollout status deployment rollout-nginx

>>> deployment "rollout-nginx" successfully rolled out

 

진행했던 히스토리를 확인하면 아래와 같다.

 

(3)-4 파드 rollout 전단계로 복구 (rollout undo)

# 히스토리 확인
kubectl rollout history deployment rollout-nginx

# 이전 단계로 상태 되돌림
kubectl rollout undo deployment rollout-nginx

 

(3)-5 특정 시점으로 파드 복구 (--to-revision)

  - 특정 시점으로 파드를 복구하려면 --to-revision 옵션을 사용한다.

kubectl rollout undo deployment rollout-nginx --to-revision=1

 

 

 

(4) 파드 삭제

  - 디플로이먼트에 속하지 않은 파드 삭제는 아래와 같다.

kubectl delete pods nginx-pod

 

  - 그러나 디플로이먼트로 생성된 파드 삭제를 위와 같이 하면, 레플리카수만큼을 유지하기 위해 자동으로 파드가 새로 생성된다. 그렇기 때문에 디플로이먼트로 생성된 경우 파드 삭제를 위해서는 아래와 같은 명령어로 수행한다.

kubectl delete deployment dpy-nginx

 

 

 

(5) 파드 접속

  - 아래 명령어에서 '--'는 exec에 대한 인자값을 나눌 때 사용. (*미사용시 DEPRECATED 메시지 표시)

kubectl exec -it nginx-pod -- /bin/bash

 

 

(6) 레플리카 늘리기/줄이기

  - 아래 명령어를 통해 이미 배포된 파드 수를 늘리거나 줄일 수 있다.

kubectl scale deployment echo-hname --replicas=9

 

(7)-1 문제가 있는(자주 발생하는) 노드에 대한 현재 상태 보존 (cordon)

  - 문제가 있는 노드에 대해 쿠버네티스에 알려주어 파드 할당을 조정한다.

kubectl cordon w3-k8s

 

cordon명령어가 적용된 노드의 경우 아래와 같이 상태에 SchedulingDisabled가 추가되었다. 즉, 더 이상 파드가 할당되지 않는다.

 

이 상태에서 파드 수를 늘려도 SchedulingDisabled가 추가된 노드에는 아래와 같이 파드가 할당되지 않는다.

 

(7)-2 보존 해제

  - 문제가 있는 노드에 대해 쿠버네티스에 알려주어 파드 할당을 조정한다.

kubectl uncordon w3-k8s

 

 

(8) 유지보수를 위한 노드의 파드 이동(drain)

  - 노드의 파드는 실제로 옮겨지는 것이 아니라, 기존 파드에서 삭제하고, 다른 곳에 다시 생성된다.

  - 아래 명령어에서 ignore-daemonsets는 Daemonset은 각 노드에 1개만 존재하는 파드라서 drain으로 삭제가 불가하기 때문에 drain 명령어를 그냥 실행시 에러를 발생시키므로 이를 무시하고 나머지 파트만 옮기기 위해 붙이는 옵션이다. 

kubectl drain w3-k8s --ignore-daemonsets

 

pod를 확인하면 drain 한 파드는 없어지고, 다른 노드에 위치한 파드가 하나 더 생성되어있는 것을 확인할 수 있다.

 

drain된 노드는 SchedulingDisabled 상태로 변경된다.

 

유지보수를 마치면 uncordon명령을 실행해 스케줄을 받을 수 있는 상태로 복귀시킨다.

kubectl uncordon w3-k8s

 

---

파드의 생명주기(Lifecycle of a Pod)

출처 : https://www.infracloud.io/blogs/kubernetes-pod-lifecycle/