LabHub

블로그

CKA_6_Cluster_Maintenance

한국어English日本語

본 포스팅은 https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests 강의와 https://kodekloud.com/의 내용을 공부하며 기록한 내용입니다.

121 OS Upgrades

K8S의 Worker Node 중 한대가 down되면 kubernetes에서는 어떻게 처리할까? pod eviction timeout에 따라 (default 5분) 일정 시간 이상 Down되어있다면 Node는 dead node로 처리된다. 5분 이전에 node가 start되면 pod는 다시 복구된다.

H/W maintenance나 OS 재시작으로 인해서 node를 중지해야한다면 중지 전에 운영중인 pod를 다른 node로 미리 옮기는 작업을 진행할 수 있다. 이와 관련하여 cordon이라는 개념도 있는데, kubernetes에서 어떤 Node를 cordon한다면 더이상 scheduler가 그 노드에 Pod를 할당하지 않는다는 것이다. cordon과 drain이 끝나면 해당 node는 Kubernetes 클러스터에 영향을 끼치지 않기 때문에 maintenance가 가능한 상태가 된다.

$ kubectl drain <node_name>

다시 worker 노드가 실행되면, uncordon 을 통해서 schedule이 가능한 상태로 변경한다.

upgrade

126 Cluster Upgrade Process

kubernetes의 업그레이드를 하려면 다양한 software를 함께 해야하는데 업그레이드 하려는 version은 kube-apiserver의 version을 기준으로 정해진다. kubectl을 제외하면 kube-apiserver의 버젼보다 높은 버젼을 사용할 수 었다. 또한 Upgrade는 한번에 여러개의 minor version을 건너뛸 수는 없고, Minor version을 한 개씩 올려가며 업그레이드 해야한다.

upgrade

Upgrade는 크게 2가지 step으로 이뤄진다. 첫번 째는 Master Node upgrade, 두번 째는 Worker Node upgrade 이다. Master Node를 upgrade하기 위해 잠시 Master Node가 잠시 down되는 것은 Pod에 큰 영향이 없기 때문에 문제 없다. woker node upgrade가 문제가 될 수 있는데 3가지 Strategy가 있다.

  1. worker node 전체 stop 후 kubectl upgrade. 이후 전체 worker node start.
  2. worker node를 한 대씩 upgrade.
  3. 신규 version의 worker node를 추가하며 기존 worker node 제거.

kubeadm upgrade plan 을 입력하면 master node의 Upgrade를 위한 정보를 보여준다. 그러나 kubeadm은 Kublet에 대한 upgrade는 지원하지 않는다. kubernetes 업그레이드를 위해서는 kubeadm tool 또한 upgrade해서 version을 맞춰줘야한다.

upgrade

130. Backup and Restore Methods

Resource Configuration을 delarative하게 작성된 yaml 파일을 GitHub같은 곳에 보관하여 관리할 수 있다. 만약 전체 Cluster가 down 되더라도, 이 Configuration을 apply하여 복구할 수 있다. 그런데 혹시라도 imperative하게 실행된 pod가 있었다면 이 정보는 복구되지 않는다.

아래 명령어를 이용하면 현재 실행중인 모든 resource 들의 configuration을 한번에 yaml 파일로 내려받을 수 있다.

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

ETCD클러스터도 데이터를 저장하기 때문에 ETCD의 데이터를 snapshot 형식으로 backup할 수 있다. etcdctl snapshot save <filename> 명령어를 사용한다.

etcd

ETCDTCL_API=3 etcdctl snapshot save snapshot.db

export ETCDCTL_API=3명령어를 통해 CLI에서 수행할 etcd api 명령어 version을 3으로 맞추고 진행한다. restore 하는 방법은 service kube-apiserver stop 명령어로 api server를 잠시 중지시킨 뒤에 etcdctl snapshot restore snapshot.db --data-dir /var/lib/etcd-fron-backup 명령어로 snapshot을 복구하고 systemctl daemon-reload 명령어와 service ectc restart를 통해 etcd를 재시작 한다. 마지막으로 service kube-apiserver start를 통해 kube-apiserver를 재시작 해주면 restore과정이 완료된다.

etcd

만약 ETCD database에 TLS 보안이 설정되어있다면 etcdctl 명령어 수행시 아래 argument도 필수로 전달해줘야한다.

etcd

    Command:
      etcd
      --advertise-client-urls=https://192.10.124.9:2379
      --cert-file=/etc/kubernetes/pki/etcd/server.crt
      --client-cert-auth=true
      --data-dir=/var/lib/etcd
      --experimental-initial-corrupt-check=true
      --experimental-watch-progress-notify-interval=5s
      --initial-advertise-peer-urls=https://192.10.124.9:2380
      --initial-cluster=controlplane=https://192.10.124.9:2380
      --key-file=/etc/kubernetes/pki/etcd/server.key
      --listen-client-urls=https://127.0.0.1:2379,https://192.10.124.9:2379
      --listen-metrics-urls=http://127.0.0.1:2381
      --listen-peer-urls=https://192.10.124.9:2380
      --name=controlplane
      --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt
      --peer-client-cert-auth=true
      --peer-key-file=/etc/kubernetes/pki/etcd/peer.key
      --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
      --snapshot-count=10000
      --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt
backup
$ ETCDTCL_API=3 etcdctl snapshot save /opt/snapshot-pre-boot.db --endpoints=https://127.0.0.1:2379 --cert=/etc/kubernetes/pki/etcd/server.crt --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/server.key
Snapshot saved at /opt/snapshot-pre-boot.db
restore
$ ETCDTCL_API=3 etcdctl snapshot restore  --data-dir /var/lib/etcd-from-backup /opt/snapshot-pre-boot.db 2023-12-20 01:21:08.126263 I | mvcc: restore compact to 9192023-12-20 01:21:08.143486 I | etcdserver/membership: added member 8e9e05c52164694d [http://localhost:2380] to cluster cdf818194e3a8c32

etcd static Pod definiation에서 data-directory로 지정했던 path를 HostPath에 지정한다. 설정이 완료되면 잠깐동안 etcd가 중지되기 때문에 클러스터 접근이 불가한다. 하지만 이후 정상적으로 etcd database가 작동하면 정상적으로 cluster에 접근 가능하다.

/etc/kubernetes/manifests/etcd.yaml
  - hostPath:
      path: /var/lib/etcd-from-backup
      type: DirectoryOrCreate
    name: etcd-data

multi cluster 환경에서 여러개의 cluster에 대한 정보가 등록되어있다면 아래 명령어로 확인이 가능하다.

$ kubectl config get-clusters
NAME
cluster1
cluster2

클러스터 컨텍스트 변경을 위해서는 kubectl config use-context cluster2 를 사용한다.

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다