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

jihyelee·2024년 1월 12일
1

kubernetes

목록 보기
7/15

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 생성 불가 (스케줄링 불가)
    1. 워커 노드 업그레이드
    • 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 updateapt-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) 조회
profile
Graduate student at Seoul National University, majoring in Artificial Intelligence (NLP). Currently AI Researcher and Engineer at LG CNS AI Lab

0개의 댓글

관련 채용 정보