[CKA] Cluster Maintenance

OS Upgrades

pod eviction timeout

pod가 down 되었을 때, kubelet은 pod를 다시 running 상태로 만든다. 하지만 pod가 5분이상 down 상태가 되면 쿠버네티스는 그 pod가 죽은 것으로 간주하여 해당 pod는 node로부터 terminated된다.

만약 pod가 replicaset의 일부인 경우에는 다른 노드에서 재생성된다.

pod가 다시 온라인 상태가 될 때까지 가디리는 시간을 the pod eviction timeout(포드 제거 시간 초과)라고 하며 다음으로 설정된다.

kube-controller-manager --pod-eviction-timeout=5m0s

이 default 설정으로 인해서 마스터 노드는 노드가 죽은 것으로 간주하기 전에 최대 5분동안 기다리는 것이다.

포드 제거 시간 초과 이후 node가 다시 online이 되면 예약된 pod 없이 빈 node 상태로 online이 된다.

drain

안전하게 node를 작업하기 위해, drain을 통해 모든 workload를 다른 node로 옮길 수 있다.

kubectl drain node-1

• 기존 node에서 pod가 종료되고, 다른 node에서 재생성된다.

• node가 cordoned 되거나 unschedulable 상태로 mark 된다. 이것은 특별한 제한이 제거될 때까지 이 node에 스케쥴링 된 pod가 없음을 의미한다.

• pod가 다른 node에서 정상적으로 RUNNING이 되면, node를 reboot할 수 있다. 이 node가 다시 online이 됐을 때 여전히 unschudulable상태다.

• pod의 cordoned 상태를 해제해주어야 다시 pod가 다시 예약된다.

    kubectl uncordon node-1

• node를 unschedulable 하게 marked 하지만 drain과 다르게 pod을 종료 혹은 이동시키지 않고 싶다면

    kubectl cordon node-2

  • 이는 새로운 pod가 더이상 스케쥴링 되지 않도록 처리한다.

Cluster Upgrade Process

쿠버네티스의 구성 요소들의 버전이 모두 같을 필요는 없다. 하지만 kube api server는 control plane의 핵심 구성요소이기 때문에 다른 구성 요소들이 kube api server보다 버전이 높으면 안된다.

• controller-manager, scheduler는 한 버전 더 낮을 수 있다.
• kubelet, kube-proxy는 두버전까지 낮을 수 있다.
• kubectl은 1버전 높거나 같거나 1버전 낮을 수 있다.

쿠버네티스에서는 오직 최근 세개의 버전까지만 지원한다.

• v1.12가 release되면, v1.10, v1.11, v1.12까지 지원하는 것.

추천되는 버전 업그레이드에 대한 접근은 마이너 버전을 하나씩 올리는 것이다.

• 현재 v1.10을 사용중인데, v1.13이 release되어 v1.10이 unsupported가 되면 v1.11로 upgrade 하는 것

version upgrade는 클러스터를 어떤 방식으로 set up 하는지에 따라 다르다.

• cloud provider

  • cloud provider에서 제공하는 upgrade 기능을 사용

• kubeadm

    kubeadm upgrade plan
    kubeadm upgrade apply

• scratch

  • 모든 컴포넌트 버전을 직접 업그레이드

어떻게 업그레이드할까?

배포된 어플리케이션의 버전을 업그레이드한다고 가정하자.

• master node upgrade
  • master node가 upgrade 되는 동안에 api server, controller manager, scheduler 등의 control plane 구성 요소들이 다운된다.
  • master node가 down된다고해서 worker node가 영향을 받는것은 아니다.
  • kubernetes api server가 다운되어 있기 때문에 이와 관련된 리소스에는 접근할 수 없으며, 새로운 어플리케이션을 배포하거나 삭제하거나 수정할 수 없다.
  • 만약 pod가 fail이 되면, 새로운 pod가 자동으로 재생성되지 않는다.
  • 하지만 node와 pod가 RUNNING중일 때는 영향을 받지 않는다.
• worker node upgrade: 3way
  • worker node 한번에 upgrade
    • upgrade 동안 application 접근 불가
  • workder node 하나씩 upgrade
    • worker node마다 하나씩 업그레이드 할 node의 pod를 다른 실행중인 node에 옮기고 upgrade 실시. 완료 후 pod 다시 옮김
  • version upgrade 한 새로운 node를 cluster에 추가 후 기존 노드 추방(evict)
    • cloud provider 환경에서 제공

Kubeadm

kubeadm을 사용하여 version upgrade 하는 방법에 대해 알아보자

kubeadm upgrade plan
kubeadm upgrade apply

• kubeadm upgrade plan
  • upgrade 할 버전에 대한 정보를 알려준다.
• 참고) kubeadm은 kubelet을 업그레이드 하진 않는다. 이는 수동으로 업그레이드해야한다.

kubeadm은 kubernetes 버전에 맞게 upgrade 되기 때문에 v1.11에서 바로 v1.13으로 upgrade된다. 하지만 한번에 한 버전씩 업그레이드 하는 방법이 추천되기 때문에 다음과 같은 방법으로 버전을 한단계씩 올리도록 하자.

apt-get upgrade -y kubeadm=1.12.0-00
kubeadm upgrade apply v1.12.0

master node upgrade

위의 과정을 진행했으나, 조회해보면 클러스터의 버전이 변하지 않는 것을 확인할 수 있다. 이는 api server version 자체가 아닌, api server에 등록 된 kubelet 의 버전이기 때문이다. 따라서 kubelet을 upgrade 해주자.

apt-get upgrade -y kubelet-1.12.0-00
systemctl restart kubelet

---

On the controlplane node, run the command run the following commands:

1. apt updateThis will update the package lists from the software repository.
2. apt install kubeadm=1.20.0-00This will install the kubeadm version 1.20
3. kubeadm upgrade apply v1.20.0This will upgrade kubernetes controlplane. Note that this can take a few minutes.
4. apt install kubelet=1.20.0-00 This will update the kubelet with the version 1.20.
5. You may need to restart kubelet after it has been upgraded.Run: systemctl restart kubelet

worker node upgrade

이제 worker node를 upgrade 할 차례이다. node-1, node-2, node-3의 세개의 노드가 실행되고 있다고 가정한다.

1. kubctl drain node-1
   1. 안전하게 작업하기 위해서 pod를 다른 node로 옮기고, 스케쥴링 되지 않게 한다.
2. apt-get upgrade -y kubeadm=1.12.0-00
3. apt-get upgrade -y kubelet=1.12.0-00
4. kubeadm upgrade node config --kubelet-version v1.12.0
5. systemctl restart kubelet
6. kubectl uncordon node-1
   1. 현재 unschedulable marked 상태이기 때문에 이를 풀어준다.
   2. 기존 진행 pod가 다시 이 node에 스케쥴링 되진 않지만 새로운 pod는 스케쥴링 될 것이다.

위 과정을 각 노드마다 반복해주면 된다.

---

On the node01 node, run the command run the following commands:

If you are on the master node, run ssh node01 to go to node01

1. apt updateThis will update the package lists from the software repository.
2. apt install kubeadm=1.20.0-00This will install the kubeadm version 1.20
3. kubeadm upgrade nodeThis will upgrade the node01 configuration.
4. apt install kubelet=1.20.0-00 This will update the kubelet with the version 1.20.
5. You may need to restart kubelet after it has been upgraded.Run: systemctl restart kubelet
6. Type exit or enter CTL + d to go back to the controlplane node.

upgrade 확인

버전이 업그레이드 됐는지는 노드의 상태를 조회해보면 알 수 있다.

kubectl get nodes

Backup and Restore Method

백업은 중요하다. github 과 같은 코드 레포지토리에 저장을 하면 재사용에도, 누군가와 공유하기도 편하기 때문에 큰 문제가 되지 않는다. 하지만 누군가가 명령형 방식으로 리소스를 생성하였고, 이에 대한 문서도 전혀 남아있지 않다면 어떻게 백업을 해야할까?

• 모든 리소스를 파일로 저장하기

    kubectl get all --all-namespaces -o yaml > all-deploy-services.yaml

ETCD Backup

ETCD clurster는 클러스터의 상태에 대해 모든 정보를 저장한다. 모든 리소스를 백업하기 전에 ETCD server만 백업할 수 있다.

ETCD cluster는 Master node에서 호스팅된다. 또한 모든 데이터가 저장되는 위치를 확인할 수 있다.

# etcd.service
ExecStart=/usr/local/bin/etcd \\
  --data-dir=/var/lib/etcd # 백업에 의해 백업되도록 구성할 수 있는 디렉토리

ETCD Snapshot

• ETCD server를 snapshot 형태로 저장할 수 있다.

    ETCDCTL_API=3 etcdctl snapshot save snapshot.db

  • 현재 경로에 저장되며, full path를 적으면 해당 경로에 위치시킬 수 있다.

• 저장된 snapshot file을 확인할 수 있다.

    ETCDCTL_API=3 ectdctl snapshot status snapshot.db

ETCD Restore

snapshot 파일을 저장하기

• api-server down

    service kube-apiserver stop

• restore

    ECCDCTL_API=3 etcdctl \
    snapshot restore snapshot.db \
    --data-dir /var/lib/etcd-from-backup

  • 적은 경로에 새로운 data directory 생성됨

• 새로운 데이터 디렉토리 사용하도록 변경

    # etcd.service
    ExecStart=/usr/local/bin/etcd \\
      --data-dir=/var/lib/etcd-from-backup

• reload and restart

    systemctl daemon-reload
    service etcd restart
    service kube-apiserver start