Udemy CKA course 6. Cluster Maintenance (클러스터 유지보수): 운영체제 및 클러스터 업그레이드, 자원 및 ETCD 백업 / 복구

Certified Kubernetes Administrator (CKA) with Practice Tests (강의 링크, 레퍼런스 노트)

• 평소 강의 할인도 많이 하고, 연습문제도 풀어볼 수 있으니 실제 강의 수강을 추천
• 아래는 강의 내용 번역 및 정리본 (문제 시 댓글로 알려주세요)

운영체제 업그레이드

• 노드가 다운된다면 노드에 속한 pod에 접근 불가
  • 노드가 온라인으로 다시 돌아온다면 kubelet 프로세스가 실행됨
  • pod-eviction-timeout동안 돌아오지 않는다면 pod가 중지되고, replicaset에 속한 pod라면 다른 노드에 생성됨
    • pod-eviction-timeout이 5분으로 기본 설정되어 있음 (kube-controller-manager)
  • pod-eviction-timeout이 지나고 노드가 온라인으로 돌아온다면 빈 노드로 생성됨
    • replicaset에 속하지 않고 해당 노드에만 속한 pod가 있었다면 문제가 됨
• kubectl drain [노드명]
  • 노드의 pod들이 중지되고 다른 노드에 생성됨
  • 노드는 unschedulable로 마킹됨 (어떠한 pod도 스케줄링될 수 없음)
  • kubectl drain [노드명] --ignore-daemonsets
• kubectl cordon [노드명]
  • 노드를 unschedulable로 마킹
• kubectl uncordon [노드명]
  • 노드에 pod들이 스케줄링될 수 있도록 마킹 변경
  • 노드를 reboot한 다음에 사용할 수 있는 명령어
    • 다른 노드로 보낸 pod가 해당 노드로 돌아오지는 않음
    • 새로운 pod가 스케줄링될 때 해당 노드에 스케줄링될 수 있음

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

• major.minor.patch 순서
  • e.g. v1.11.3
  • minor
    • 새로운 특징(feature)과 기능(functionality) 포함
    • 몇 달에 한번 주기
  • patch
    • 버그 수정
    • minor보다 빈번
• alpha, beta 버전
  • 안정적인 버전을 출시(release)하기 이전
• 같은 버전으로 관리될 수 있는 프로젝트
  • e.g. kube-apiserver, controller-manager, kube-scheduler, kubelet, kube-proxy, kubectl
  • ETCD cluster, CoreDNS는 다른 프로젝트이기 때문에 다른 버전으로 관리됨

클러스터 업그레이드

• 쿠버네티스는 가장 최신의 3개 버전만 지원함
• 요소(component)들이 모두 반드시 같은 버전으로만 사용되어야 하는 것은 아님
  • kube-apiserver가 X 버전(e.g. v.1.10)이라면
  • controller-manager, kube-scheduler는 X-1 버전(e.g. v1.9, v1.10)까지
  • kubelet, kube-proxy는 X-2 버전(e.g. v.1.8, v1.9, v1.10)까지 가능
  • kube-apiserver보다 높은 버전을 가질 수는 없음
• 이러한 특성 덕분에 live upgrade가 가능
  • 요소(component)별로 업그레이드 가능
  • 여러 버전을 한 번에 건너뛰어서 업그레이드하기 보다는, 한 버전씩 순차적으로 업그레이드하는 것이 권장됨

업그레이드 방법

• 구글 쿠버네티스 엔진 사용 시
  • 버튼으로 업그레이드 가능
• kubeadm 사용해 클러스터 구성 시
  • kubeadm upgrade plan
  • kubeadm upgrade apply
• 처음부터 클러스터 구성 시 (from scratch)
  • 구성한 클러스터에 맞게 업그레이드

업그레이드 순서 (kubeadm)

• 1. 마스터 노드 업그레이드
  • controlplane 요소들(e.g. API server, controller-manager, scheduler)이 잠시 다운됨
  • 워커 노드의 워크로드들은 평소처럼 서비스됨
  • 관리 기능들만 영향을 받음
    • e.g. kubectl 혹은 쿠버네티스 API로 클러스터 접근 불가
    • e.g. 새로운 프로그램을 배포하거나 삭제, 수정 불가
    • e.g. pod 중단 시 새로운 pod 생성 불가 (스케줄링 불가)
• 2. 워커 노드 업그레이드
  • 2-1. 워커 노드 전체를 다운시키고 업그레이드
    • 서비스가 중단되는 다운타임 필요
  • 2-2. 워커 노드를 하나씩 업그레이드
    • 하나의 노드가 업그레이드되는 동안 해당 노드에 있던 pod는 다른 노드로 이동
  • 2-3. 새로운 소프트웨어 버전을 가진 노드를 새로 추가
    • 워크로드를 새로운 노드에 옮기고 기존 노드를 다운

명령어 (kubeadm)

• kubeadm upgrade plan
  • 현재 클러스터 버전, 최신 버전 등의 정보 제공
• apt-get upgrade -y kubeadm=1.12.0-00
  • 현재 버전이 v1.11이었다면, kubeadm tool 먼저 v.1.12로 업그레이드
  • 혹은 apt update 후 apt-get install kubeadm=1.12.0-00
• kubeadm upgrade apply v1.12.0
  • 노드 내 클러스터 요소들을 업그레이드
• kubectl get nodes
  • 버전의 정보는 각각의 노드(kubelet)를 의미 (api-server의 버전 정보 아님)
• apt-get upgrade -y kubelet=1.12.0-00
  • 마스터 노드의 kubelet을 먼저 업그레이드 (pod의 형태로 배포된 요소들이 있을 경우)
  • 혹은 apt-get install kubelet=1.12.0-00
  • systemctl restart kubelet && systemctl daemon-reload 필요할 수 있음
• 워커 노드 업그레이드 (각 노드에 대해 해당 순서 진행)
  • kubectl drain [노드명]
    • 노드의 pod를 다른 노드의 옮기고 unschedulable 처리
  • apt-get upgrade -y kubeadm=1.12.0-00
  • apt-get upgrade -y kubelet=1.12.0-00
    • dependency 이슈 발생 시 apt-get install kubelet=1.12.0-00 가능
    • 해당 단계부터는 ssh를 통해 해당 노드에 접근한 후 실행
  • kubeadm upgrade node config --kubelet-version v1.12.0
    • 혹은 kubeadm upgrade node
  • systemctl restart kubelet
  • kubectl uncordon [노드명]
    • 노드를 다시 schedulable로 변경
• 클러스터 업그레이드 관련 문서 참고 가능

백업 및 복구

리소스 환경설정 (resource configuration)

리소스 생성방법

• imperative 방식
  • 명령어를 통해 생성
  • kubectl create namespace [네임스페이스]
  • kubectl create secret
  • kubectl create configmap
• declarative 방식
  • pod yaml 파일을 통해 생성
  • imperative에 비해서 백업에 있어서 더욱 바람직 (github 등에 업로드 가능)
  • kubectl apply -f [파일명].yaml

리소스 백업

• kube-apiserver 활용
  • 모든 객체에 대한 복사본을 만들어 백업 가능
  • kubectl get all --all-namespaces -o yaml > [파일명].yaml
• 외부 솔루션 활용
  • Velero (HeptIO)

ETCD Cluster

들어가며

• etcd 명령어를 사용할 때 필요한 항목들
  • etcd 클러스터의 엔드포인트
    • --endpoints=[ETCD pod 내 listen-client-urls 혹은 advertise-client-urls]
  • 인증을 위한 CA 인증서
    • --cacert=[ETCD pod 내 trusted-ca-file]
  • etcd 서버의 인증서
    • --cert=[ETCD pod 내 cert-file]
  • etcd 서버의 key
    • --key=[ETCD pod 내 key-file]
• ETCDCTL_API를 etcdctl 사용 전 미리 환경변수로 설정할 수 있음
  • export ETCDCTL_API=3

ETCD 백업

• ETCD 서버 자체를 백업할 수 있음
  • ETCDCTL_API=3 etcdctl snapshot save snapshot.db
  • ETCDCTL_API=3 etcdctl snapshot status snapshot.db
  • 빌트인 스냅샷 솔루션을 활용해 백업 가능
  • 위에서 언급한 etcd 명령어를 사용할 때 필요한 항목들(e.g. endpoint)을 같이 기재해줘야 함
• 마스터 노드에 ETCD 위치
  • etcd.service 파일에서 --data-dir= 옵션을 통해 경로 확인 가능

백업한 ETCD 서버를 활용해 복구

• service kube-apiserver stop
• ETCDCTL_API=3 etcdctl snapshot restore snapshot.db --data-dir [새로운 데이터 디렉토리 경로]
  • 새로운 클러스터 환경설정을 사용, etcd의 멤버로 하여금 새로운 클러스터의 새로운 멤버가 되도록 함
  • 우연히 기존에 존재하는 클러스터에 합류되는 일을 막기 위함
  • restore 시에는 endpoint 등을 추가로 기재해줄 필요 없음
• case 1. ETCD가 static pod로 배포된 경우 (stacked ETCD)
  • /etc/kubernetes/manifests/etcd.yaml 에서 volumes: hostPath: path를 새로운 디렉토리로 수정해줘야 함
    • volumes: hostPath는 controlplane 내의 위치, volumeMounts: mountPath는 컨테이너 내의 위치
    • volumeMounts와 --data-dir의 경로는 같아야 하지만, volumes과 volumensMount는 이름으로 연결되어 있기 때문에 경로가 같을 필요는 없음
  • etcd pod가 자동으로 재시작 (kube-controller-manager, kube-scheduler도 마찬가지)
    • 만약 자동으로 재시작되지 않는다면, kubectl delete pod -n kube-system [etcd pod명]
• case 2. ETCD가 외부 서버에서 배포된 경우 (external ETCD)
  • ssh etcd-server
    • 외부 ETCD 서버에 접속
  • chown -R etcd:etcd [데이터 디렉토리명/]
    • 복구 시 새로운 데이터 디렉토리의 권한이 root:root으로 설정되어 있을 경우 사용
    • 기존 데이터 디렉토리의 권한과 동일하게 설정
  • vi /var/lib/etc/systemd/system/etcd.service
    • --data-dir 경로를 새로운 폴더로 변경
  • systemctl daemon-reload && systemctl restart etcd
  • exit
    • 기존 노드로 돌아옴 (ssh 연결 해제)
  • kubectl delete pods [controller명] [scheduler명] -n kube-system
    • controlplane 요소들 (controller, scheduler) 재시작
  • ssh [controlplane 노드명] && systemctl restart kubelet
    • kubelet 재시작
• service kube-apiserver start

참고

기타 명령어

• alias k=kubectl
  • 명령어 사용 시 편한 가명(alias) 지정 가능
• k describe node | grep Taints
  • 모든 노드들에 대해 taint 옵션이 있는지 확인 가능
• ssh [노드명/IP]
  • 해당 노드로 접근 가능 (ssh 접속)
• scp [보낼 파일의 경로] [받을 경로]
  • 파일을 앞의 경로에서 뒤의 경로로 복사
• kubectl config view
  • 클러스터를 포함한 다양한 정보 조회
• kubectl config use-context [클러스터명]
  • 클러스터 전환
• ETCDCTL_API=3 etcdctl member list
  • ETCD 클러스터 내에 몇 개의 노드가 있는지 확인
  • --endpoints=[URL] --cacert=[파일경로] --cert=[파일경로] --key[파일경로] 함께 기재
  • ETCDCTP_API=3 의 경우 환경변수 미리 설정해주었다면 생략 가능

Stacked ETCD와 External ETCD

• stacked ETCD
  • controlplane에 pod 형태로 배포
  • kubectl get pods -n kube-system 을 통해 조회 가능
  • kubectl describe pod [kube-apiserver pod명]
    • --etcd-servers=[경로]에서 localhost IP 사용 여부로 확인 가능
  • /etc/kuberenetes/manifests/ 에 yaml 파일 있는지 여부로 확인 가능 (static pod)
• external ETCD
  • pod 형태로 배포되지 않음
  • kubectl describe pod [kube-apiserver pod명]
    • --etcd-servers=[경로]에서 외부(별도) IP 사용 여부로 확인 가능
• ETCD configuration 조회
  • ps -ef | grep -i etcd
    • 프로세스에서 ETCD 정보 (e.g. endpoints) 조회