유데비 CKA강의를 들으면서 정리한 문서입니다. 따로 정리한 글이 아니라 강의 중간에 메모한 문서이기 때문에 틀린부분이 존재할수도 있습니다.

1. drain, cordon, uncordon (os upgrade)

개념

노드가 다운되었다가 5분안에 다시 online상태가 되면, 노드안의 파드는 그대로 있다. 하지만 노드가 5분이상 다운되면 쿠버네티스는 노드가 종료되었다고 판단하여 노드안의 파드를 종료시켜 버린다. 5분후에 다시 노드를 online상태로 만들더라도 파드를 다시 생성해줘야 한다.

5분이라는 시간은 디폴드 설정값이며 --pod-eviction-timeout을 통해 이 설정을 변경할 수 있다.

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

한 워커 노드가 5분이상 다운되었다고 가정해보자. 노드에 포함된 파드가 replica set인 경우에는 노드가 다운되는 순간 다른 워커 노드에 해당 파드가 생성될 것 이다. 하지만 replica set이 아닌 파드는 다운되었을때, 복구되었을때 생성되지 않을것이다.

os upgrade를 위한 절차는 다음과 같다.

kubectl drain node-1 ( node-1 워커노드에 pod가 생성되지 않도록 제한을 건다.)
node-1 reboot
kubectl cordon node-2 (drain과 다르게 노드가 내려가고 노드 안에 잇는 pod가 다른 살아있는 노드로 옮겨가는것이 아니다. 단순히 pod가 스케줄되지 않도록 설정하는 것)
kubectl uncordon node-1 ( uncordon 한다고 다른 node에 있는 pod가 저절로 node-1에 오지 않는다. / 새로 파드를 생성하면 node-1에 스케줄링 될 수도 있다. / 또는 다른 노드에서 파드를 삭제하면 node-1로 스케줄리 될 수도 있다.

관련 명령어

drain 명령어

kubectl drain node01 --ignore-daemonsets
(daemonsets으로 만들어진 파드를 제외하고 drain)

--ignore-daemonsets 옵션 설명 참고

ReplicatinoController, ReplicaSet, Job, Daemonsets, StatefulSet으로 관리되지 않는 파드가 node01에 존재하는 경우 drain 명령어에서 오류가 난다.

kubectl drain node-1 --ignore-daemonsets --force 

명령어를 통해 강제로 drain할 수 있으나, 관리되지 않는 파드는 영원히 유실될 수 있다.

cordon 명령어

kubectl cordon node-1

노드에 존재하는 파드는 유지하면서 스케줄링만 안되게하고 싶으면 cordon명령어를 사용하면 된다.

기타 명령어

kubectl get nodes

노드 확인

status 항목을 통해 SchedulingDisabled인지 확인 가능

kubectl get pods -o wide

어느 노드에 어느 파드가 존재하는지 확인

kubectl get deployments.apps
kubectl get deplotments 랑 위 명령어가 다른점은 ?????

어떤 애플리케이션이 노드에 호스팅되고 있는지 확인
A애플리케이션이 여러 파드에 존재할 수도 있음. (?)

kubectl describe node master | grep -i taint

기본적으로 마스터노드로는 파드가 스케줄되지 않도록 taint되어있다.

2. 쿠버네티스 소프트웨어 버전

v1.18.0
(major, minor, patch)

쿠버네티스의 첫 major 버전인 v1.0은 2015년 6월에 출시
minor버전의 경우 매월 출시
patch의 경우 버그픽스

보통 알파 -> 베타 버전을 거쳐 정식 버전이 된다.

모든 버전 이력은 쿠버네티스 깃헙에서 확인할 수 있다.

controlplane의 컴포넌트인 kube-apiserver, controller-manager, kube-scheduler, kubelet, kube-proxy, kubectl 은 같은 버전을 따라가고 ETCD Cluster, Core DNS은 분리된 프로젝트이기 때문에 각자의 버전이 있다.

쿠버네티스 컴포넌트

쿠버네티스 깃헙

3. 클러스터 업그레이드

쿠버네티스를 이용하는 환경에 따라 업그레이드 하는 방법은 다른다.
GCP에서 매니지드서비스를 사용하는 경우, Kubeadm을 사용하는 경우, 스크레치(아무기반없이 처음부터 쿠버네티스 구축)인 경우에따라 다르다.

클러스터 업그레이드는 마스터 노드 업그레이드, 워커 노드 업그레이드 2단계를 거친다.

1. 마스터 노드 업그레이드
   마스터 노드를 업그레이드 하는 중에는 마스터 노드에 있는 컴포넌트들이 동작하지 않는다. 예를들어 워커 노드의 파드가 삭제되더라도 재생성하지 않을 것이다. 하지만 워커 노드에 이상이 없는한 사용자들은 서비스를 정상적으로 이용할 수 있다.

2. 워커 노드 업그레이드
   워커 노드를 업그레이드하는 방법은 3가지 있다.

첫 번째는, 모든 워커 노드를 한번에 업그레이드 하는것이다. 당연히 업그레이드를 수행하는 동안 사용자들은 서비스를 이용할 수 없다.

두 번째는, 워커 노드를 순차적으로 업그레이드 하는 것이다. 하나씩 업그레이드 되기 때문에 업그레이드 되는 노드안의 파드들은 다른 노드들로 옮겨갈 것이다.

세 번재는, 업그레이드된 버전을 새로운 노드를 추가하고 워크로드를 새로운 노드로 옮기는 것이다.

kubeadm 쿠버네티스 업그레이드

kubeadm upgrade plan

주의할 점은 kubeadm upgrade는 kublet 업그레이드를 포함하지 않는다. kubeadm 자체도 쿠버네티스와 동일한 버전을 따라간다.

<마스터 노드>
kubectl drain master --ignore-daemonsets

apt-get upgrade -y kubeadm=1.12.0-00
(apt install kubeadm=버전)

kubeadm upgrade apply 1.12.0
(이미지를 pull하고 컴포넌트들을 업그레이드 한다.)
kubectl get nodes
(해당 명령어를 통해 보이는 버전은 apiserver버전이 아니라 각 노드의 kubelet의 버전이다)
kubectl version --short

apt-get upgrade -y kubelet=1.12.0-00
(apt install kubelet=버전)

systemctl restart kubelet
kubectl get nodes

kubectl uncordon master

<워커 노드>
kubectl drain node01

ssh node01

apt-get upgrade -y kubeadm=1.12.0-00
(apt install kubeadm=버전)
apt-get upgrade -y kubelet=1.12.0-00
(apt install kubelet=버전)
kubeadm upgrade node config --kubelet-version v1.12.0
systemctl restart kubelet

logout
(master노드로 돌아옴)

kubectl uncordon node01

node02
node03
node04 
반복

전체적으로
1) kubeadm 버전 업그레이드
2) kubeadm을 통해 cluster 컴포넌트 버전 업그레이드
3) kubelet 버전 업그레이드

kubeadm으로 배포된 클러스터 업그레이드

3. 백업 & 복구

백업 대상
Resource Configuration, ETCD Cluster, Persistent Volumes

Resource Configuration 백업

1) 각 리소스들을 설정파일로 정의 후에 생성한다면, github와 같은 버전관리 툴에서 설정파일들을 관리하고 보존할 수 있다.
2) 하지만, 어떤 팀원이 설정파일 변경없이 명령어를 통해 바로 리소스들을 변경한다면, 설정파일은 최신버전으로 유지되지 않을 것이다. 따라서 kube-apiserver에 바로 쿼리하여 설정파일 백업을 만드는 방법이 있다.

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

ETCD Cluster 백업

1) etcd는 클러스터에 존재하는 모든 리소스들의 상태를 저장하고 있다. 마스터 노드에 호스팅되며, etcd 설정 시, --data-dir=/var/lib/etcd 처럼 데이터가 저장될 디렉토리 경로를 지정한다.

2) etcd control utility를 통해 etcd 스냅샷을 생성할 수도 있다.
ETCDCTL_API=3
etcdctl snapshot save sanpshot.db

snapshot save [백업 파일 이름]\
snapshot status [백업 파일 이름]

ETCD Cluster 복구

1) kube-apiserver을 멈춘다.
kube-apiserver는 ETCD와 연관되어 있기 때문에 멈추고 ETCD를 복구해야한다.

service kube-apiserver stop
etcdctl restore [백업 파일 이름] --data-dir /var/lib/etcd-from-backup
--data-dir=/var/lib/etcd-from-backup(etcd 설정 파일 변경)
systemctl daemon-reload (service daemon 리로드)
service etcd restart (etcd 서비스 재시작)
service kube-apiserver start

두 방법 모두 장단점이 존재한다. 다만, 매니지드 서비스를 사용할 경우 etcd에 접근권한이 없을 수도 있기 때문에 kube-apiserver에 쿼리하는 방법을 선택하는 것이 좋다.

kubectl get deployments.app,svc,pod

todo. 멀티 클러스터 구성
todo. etcd