쿠버네티스 기본 사용법(3)

쿠버네티스 기본 사용법(3)

파드의 동작 보증 기능

쿠버네티스는 파드 자체에 문제가 발생하면 파드를 자동 복구해서 파드가 항상 동작하도록

보장하는 기능도 있습니다.

1. 파드에 문제가 발생하는 상황을 만들기 위해 앞에서 생성한 파드를 삭제하겠습니다.

일단 어떤 파드들이 있는지 확인 합니다.

2. kubectl delete pods nginx-pod를 실행해 nginx-pod를 삭제 합니다.

3. 파드의 동작을 보증하기 위해 다른 파드도 삭제해 서로 비교합니다.

파드의 목록 중에서 가장 위에 있는 echo-hname을 삭제 하겠습니다.

4. 삭제가 잘 됐는지 kubectl get pods로 확인합니다.

확인을 해보니, 아직도 6개의 파드가 존재 하며, AGE를 봤을 때 최근에 생성된 것을 확인 할 수 있습니다.

일단 아까 삭제한 nginx-pod는 디플로이먼트에 속한 파드가 아니기 때문에 바로 삭제되고 다시 생성되지도 않습니다.

하지만 echo-hname은 디플로이먼트에 속한 파드 입니다. 그리고 앞에서 echo-hname에 속한 파드를 replicas에서 6개로 선언했으며, 이 replicas는 파드를 선언한 수대로 유지하도록 파드의 수를 항상 확인하고 부족하면 새로운 파드를 만들어 냅니다.

이렇게 파드가 자동 복구가 되면 디플로이먼트에 속한 파드는 어떻게 삭제하는지 알아보겠습니다.

5. 디플로이먼트에 속한 파드는 상위 디플로이먼트를 삭제해야 파드가 삭제됩니다.

kubectl delete deployment echo-hname 명령으로 디플로이먼트를 삭제 합니다.

6. 디플로이먼트를 삭제한 후에 배포된 파드가 남아 있는지 확인 합니다.

노드 자원 보호하기

노드는 쿠버네티스 스케줄러에서 파드를 할당받고 처리하는 역할 을 합니다.

하지만 문제가 생긴 노드에 파드를 할당하면 문제가 생길 가능성이 높습니다.

어쩔 수 없이 해당 노드를 사용해야 한다면 영향도가 적은 파드를 할당해 일정 기간 사용하면서

모니터링해야 합니다. 그렇지만 쿠버네티스는 모든 노드에 균등하게 파드를 할당하려고 합니다.

쿠버네티스에게 문제가 생길 가능성이 있는 노드 다라는 것을 알려주는 cordon 기능을

사용합니다.

1. 현재 배포된 파드가 없기 때문에 echo-hname.yaml을 적용해(apply) 파드를 생성 합니다.

2. scale 명령으로 배포한 파드를 9개 로 늘립니다.

3. 배포된 9개의 파드가 제대로 작동하는지 확인합니다.

kubectl get pods -o=custom-columns를 사용합니다. custom-columns는 사용자가 임의로 구성할 수 있는 열을

의미 합니다.

명령에서 NAME, IP, STATUS, NODE는 열의 제목 이고, 콜론(:) 뒤에 내용 값인 .metadata.name, .status.podIP,

.status.phase, .spec.nodeName을 넣고 콤마(,)로 구분 합니다.

4. scale로 파드의 수를 3개로 줄입니다.

5. 각 노드에 파드가 1개씩만 남아있는지 확인합니다.

6. 여기서 w3-k8s 노드에 문제가 자주 발생해 현재 상태를 보존해야 한다고 가정하면,

w3-k8s 노드에 cordon 명령을 실행 합니다.

7. kubectl get nodes 명령을 실행해 cordon 명령이 제대로 적용됐는지 확인 합니다.

w3-k8s가 더 이상 파드가 할당되지 않는 상태로 변경됐습니다.

8. 이 상태에서 파드 수를 9개로 늘립니다.

9. 노드에 배포된 파드를 확인 합니다. 특히 w3-k8s에 추가로 배포된 파드가 있는지 확인합니다.

파드 수가 w1-k8s는 4개, w2-k8s는 4개인 데, w3-k8s는 여전히 1개인 것을 확인 할 수 있습니다.

10. 이번에는 파드 수를 3개로 줄입니다.

11. 각 노드에 할당된 파드 수가 공평하게 1개씩인지 확인합니다.

12. uncordon 명령으로 w3-k8s에 파드가 할당되지 않게 설정했던 것을 해체 합니다.

그 후, kubectl get nodes 명령으로 확인합니다.

cordon 기능은 문제가 발생할 가능성이 있는 노드를 스케줄되지 않게 설정할 수 있습니다.

노드 유지보수하기

쿠버네티스를 사용하다 보면 유지보수를 위해 노드를 꺼야 하는 상황이 발생할 수 있습니다.

이럴 때를 대비해 쿠버네티스는 drain 기능을 제공합니다.

drain은 지정된 노드의 파드를 전부 다른 곳으로 이동시켜 해당 노드를 유지보수 할 수 있게합니다.

1. kubectl drain 명령을 실행해 유지보수할 노드(w3-k8s)를 파드가 없는 상태로 만듭니다.

하지만 이 명령을 실행하면 데몬셋을 지울 수 없어서 명령을 수행할 수 없다고 나옵니다.

drain은 실제로 파드를 옮기는 것이 아니라 노드에서 파드를 삭제하고 다른 곳에 다시 생성 합니다.

쿠버네티스에서 대부분 이동은 파드를 지우고 다시 만드는 과정을 의미합니다.

2. drain 명령과 ignore-daemonsets 옵션을 함께 사용합니다.

이 옵션을 사용하면 DaemonSet을 무시하고 진행합니다.

3. 노드 w3-k8s에 파드가 없는지 확인 합니다. 그리고 옮긴 노드에 파드가 새로 생성돼 파드 이름과 IP가 부여된 것도 확인합니다.

4. kubectl get nodes를 실행해 drain 명령이 수행된 w3-k8s 노드의 상태를 확인 합니다.

5. 유지보수가 끝났다고 가정하고 w3-k8s에 uncordon 명령을 실행해 스케줄을 받을 수 있는 상태 로 바꿉니다.

그리고 다시 노드 상태를 확인 합니다.

6. 다음 진행을 위해 배포한 echo-hname을 삭제합니다.

그 후, kubectl get pods로 배포된 파드가 없음을 확인합니다.

파드 업데이트하고 복구하기

파드를 운영하다 보면 컨테이너에 새로운 기능을 추가하거나 치명적인 버그가 발생해 버전을 업데이트해야 할 때가 있습니다.

파드 업데이트

1. 파드를 배포합니다. 여기서 --record는 배포한 정보의 히스토리를 기록 합니다.

적용한 코드 내용은 아래와 같습니다.

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

2. record 옵션으로 기록된 히스토리는 rollout history 명령을 실행해 확인할 수 있습니다.

3. 배포한 파드의 정보를 확인합니다.

4. 배포된 파드에 속해 있는 nginx 컨테이너 버전을 curl -I(헤더 정보만 보여주는 옵션) 명령으로 확인 합니다.

5. set image 명령으로 파드의 nginx 컨테이너 버전을 1.16.0으로 업데이트 합니다.

6. 업데이트한 후에 파드의 상태를 확인합니다.

확인하니 파드들의 이름과 IP가 변경됐습니다.

파드는 언제라도 지우고 다시 만들 수 있기 때문에 파드에 속한 nginx 컨테이너를 업데이트하는 가장 쉬운 방법은

파드를 관리하는 replicas의 수를 줄이고 늘려 파드를 새로 생성하는 것입니다.

7. nginx 컨테이너가 1.16.0으로 모두 업데이트되면 Deployment의 상태를 확인 합니다.

8. rollout history 명령을 실행해 rollout-nginx에 적용된 명령들을 확인 합니다.

그리고 curl -I 명령으로 업데이트가 제대로 이루어졌는지도 확인합니다.

업데이트 실패 시 파드 복구하기

업데이트할 때 실수로 잘못된 버전을 입력할 때 어떻게 되는지 확인해 보겠습니다.

1. set image 명령으로 nginx 컨테이너 버전을 의도와 다르게 입력 합니다.

2. 파드가 삭제되지 않고 pending(대기 중) 상태에서 넘어가지 않습니다.

3. 무슨 문제인지 확인하기 위해 rollout status를 실행합니다.

새로운 replicas는 생성했으나 디플로이먼트를 배포하는 단계에서 대기 중으로 더이상 진행되지 않은 것을

확인할 수 있습니다.

4. describe 명령으로 문제점을 더 자세히 살펴보겠습니다.

확인을 해보니, replicas가 새로 생성되는 과정에서 멈춰있습니다.

그 이유는 1.17.23 버전의 nginx 컨테이너가 없기 때문입니다.

5. 문제를 확인했으니 정상적인 상태로 복구하겠습니다.

rollout histroy로 업데이트할 때 사용했던 명령들을 확인 합니다.

6. rollout undo로 명령 실행을 취소해 마지막 단계(REVISION 3)에서 전 단계(REVISION 2)로 상태를 되돌립니다.

7. 파드 상태를 다시 확인합니다.

8. rollout history로 실행된 명령을 확인합니다. REVISION 4가 추가되고 REVISION 2가 삭제 됐습니다.

현재 상태를 REVISION 2로 되돌렸기 때문에 REVISION 2는 삭제되고 가장 최근 상태는 REVISION 4가 됩니다.

9. 배포된 컨테이너의 nginx 버전을 curl -I로 확인 합니다. nginx의 버전이 1.16.0이므로 상태가 되돌려졌음을 알 수 있습니다. 그 후, rollout status 명령으로 변경이 정상적으로 적용됐는지 확인 합니다.

아까 처럼 describe로 현재 디플로이먼트 상태도 세부적으로 점검하고 넘어가도 좋습니다.

특정 시점으로 파드 복구하기

특정 시점으로 돌아가고 싶을 때 는 --to-revision 옵션을 사용합니다.

1. 처음 상태인 revision 1로 돌아갑니다.

2. 새로 생성된 파드들의 IP를 확인합니다.

3. curl -I로 nginx 컨테이너의 버전을 확인 합니다.

처음 상태로 복구된 것을 확인할 수 있습니다.

4. 다음 단계 진행을 위해 배포한 rollout-nginx 디플로이먼트를 삭제 합니다.

그 후, 배포된 파드가 없는지 확인합니다.

지금까지 쿠버네티스의 파드를 통해서 오브젝트의 구성을 살펴보고, 파드를 효율적으로 사용할 수 있게 해주는

디플로이먼트에 대해서 알아봤고 오브젝트를 생성하는 3가지 방법을 알아봤습니다.

참조 - 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 (조훈, 심근우, 문성주 지음)

from http://puzzle-moon.tistory.com/92 by ccl(A) rewrite - 2021-12-31 23:26:52