cluster 관리

노드 유지보수 관리 방법 

클러스터를 운영하다 보면 노드의 OS를 업그레이드하거나 보안 패치를 적용해야 할 상황이 생긴다.

이때 노드를 안전하게 종료하고 다시 복구하는 절차가 중요하다.

 

노드가 갑자기 내려간 경우

노드가 예기치 않게 다운되면, Kubernetes는 기본적으로 5분간 해당 노드를 지켜본다(기본설정 5분 `--pod-eviction-timeout=5m`)

만약 노드가 NotReady 상태가 지속되면, 5분 후 해당 노드의 파드를 evict한다

파드가 ReplicaSet의 일부였다면, 다른 노드에서 자동으로 새로 생성된다.o

반면, ReplicaSet이 아닌 단독 파드라면 다시 살아나지 않고 사라진다.

 

안전한 유지보수를 위한 노드 처리: cordon과 drain

 

1. kubectl cordon <노드명>

•  해당 노드를 스케줄링 불가 상태로 설정.
•  새로운 파드는 이 노드에 배치되지 않지만, 기존 파드는 계속 실행됨.
•  단순히 더 이상 파드를 스케줄링하지 않게 하고 싶을 때 사용.

2. kubectl drain <노드명>

•  해당 노드의 모든 파드를 종료하고, ReplicaSet 등을 통해 다른 노드로 새롭게 생성되도록 유도.
  • 만약에 해당 노드에 있는 파드중에 replicaset없는 pod있으면 실행안된다 --force 명령어를 줘야한다
•  내부적으로 해당 노드를 cordon 처리하고, 파드를 graceful하게 종료시킴.
•  상태 저장 파드나 DaemonSet 등 일부는 drain 대상에서 제외될 수 있음 (--ignore-daemonsets 옵션 등 필요).
•  유지보수 전에 반드시 drain으로 파드를 안전하게 옮겨주는 것이 좋음.
•  이후 보수가 완료되면 kubectl uncordon <노드명> 명령어를 사용하면 다시 해당 노드에 파드가 스케줄링 되게 할 수 있다 
  • 이전에 죽은 pod 가 다시 돌아오는건 아니다

# 위와 같은 상황에서 노드 상태 보기 
kubectl get nodes

 

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

버전에 대한 정보 

kubectl get nodes 명열어을 수행 해보면 옆에 각 노드들의 version을 볼 수 있다  ex )  1.11.3

Kubernetes 버전은 일반적으로 아래와 같은 형식으로 이루어진다 {major}.{minor}.{patch} 

• major: 큰 변화가 있을 때 올라감 (예: 호환성 깨지는 변경 등)
• minor: 새로운 기능 및 개선사항 추가, 몇 달 간격으로 릴리즈됨
• patch: 버그 수정과 보안 패치 등, 더 자주 릴리즈됨

Kubernetes 기능은 다음과 같은 단계(릴리즈 채널)를 거쳐 출시된다 

Alpha → Beta → Stable(정식 릴리즈)

 

Alpha : 실험적 기능, 기본 비활성화됨, 불안정하고 버그 있을 수 있음

Beta :어느 정도 안정화된 기능, 기본 활성화됨, 실제 사용 가능

 

 

릴리즈 정보 확인

Kubernetes의 공식 릴리즈 정보는 GitHub에서 확인 가능 하다 

https://github.com/kubernetes/kubernetes/releases

 

릴리즈 압축 파일(kubernetes.tar.gz)을 다운로드하면, kube-apiserver, kube-controller-manager, kubelet, kubectl 등 모든 핵심 컴포넌트가 동일한 버전으로 포함됨

 

참고로 Kubernetes 클러스터 내부의 일부 컴포넌트는 별도 프로젝트로 관리되어 별도 버전을 가진다

(etcd: 분산 key-value 저장소 , CoreDNS: DNS 제공 컴포넌트)

 

각 Kubernetes 릴리즈 노트에는 해당 버전에서 지원되는 etcd, CoreDNS의 호환 버전 정보가 포함되어 있음

 

 

업그레이드 방법

버전 관리 및 호환성

Kubernetes의 핵심 컴포넌트(kube-apiserver, controller-manager, scheduler, kubelet, kubectl 등)는 반드시 모두 같은 버전일 필요는 없다.

 

일반적인 규칙

• kube-apiserver가 기준.
• 다른 컴포넌트는 kube-apiserver보다 1 minor version 정도 낮거나 높아도 호환 가능.
  • kube-controller-manager, kube-scheduler 등
• kubelet은 apiserver보다 약간 높은 버전도 허용됨.

업그레이드 주기와 정책

Kubernetes는 최신 3개의 minor 버전만 공식 지원한다 

ex) 현재 최신이 1.30.x라면, 1.28.x 이상만 지원

 

따라서, 지원을 잃기 전에 업그레이드 주기를 가져가는 것이 권장됨.

한 번에 여러 minor 버전을 건너뛰지 말고, 한 단계씩 순차적으로 업그레이드하는 것이 안전하다

( 1.26 → 1.28 ❌ , 1.26 → 1.27 → 1.28 ✅ )

 

업그레이드 방법

Cloud Provider를 사용하는 경우 (aws, gcp) 

UI나 CLI로 클릭 몇 번으로 업그레이드 가능 관리형 서비스의 경우 자동 롤링 업그레이드 지 원

 

kubeadm 사용 (직접 구축한 클러스터에 해당)

업그레이드 순서  : [마스터 노드 업그레이드] → [워커 노드 순차 업그레이드]

 

특정 버전으로 올리는게 정해저있다면 아래의 과정들을 우선 처리해줘야한다. 

Ubuntu/Debian 계열에서 apt 패키지 매니저로 Kubernetes 컴포넌트(kubeadm, kubelet, kubectl)를 관리하는 경우,

v1.31 ->  v1.32 버전으로 업그레이드하려면 패키지를 받을 저장소(repository)를 v1.32용으로 바꿔줘야 함. (그래야 설치가 가능함) 

공식문서 링크

 

#현재 운영 서비스 확인 가능
cat /etc/*release*

 

vim /etc/apt/sources.list.d/kubernetes.list

이 파일에는 Kubernetes 패키지를 다운로드 받을 apt 저장소 URL이 설정돼 있음.

따라서 버전 내가 업데이트 하려는거로 변경 필요 

# 업데이트 가능한 버전 확인할 수 있다
apt update
apt-cache madison kubeadm

 

마스터 노드 업그레이드 

마스터노드도 drain해주면 좋음 근데  taint걸려있어서 어차피 일반적인 애들은 못들어온다. 이게 허용되있는경우는 해야함 아니면 안해줘도 괜찮다

kubeadm upgrade plan  # 현재 버전과 업그레이드 가능한 버전 확인
apt-get update && apt-get install -y kubeadm=1.xx.0-00
kubeadm upgrade apply v1.xx.0
apt-get install -y kubelet=1.xx.0-00 kubectl=1.xx.0-00 #이건 별도로 설치해줘야함
sudo systemctl daemon-reload #변경된 설정파일 인식
sudo systemctl restart kubelet #재시작

 

워커노드 업그레이드

노드를 하나씩 drain하고(명령어는 마스터 노드에서 날리면 된다) 순차적으로 업데이트 해야한다 

kubectl drain <노드명> --ignore-daemonsets
apt-get update && apt-get install -y kubeadm=1.xx.0-00
kubeadm upgrade node
apt-get install -y kubelet=1.xx.0-00
sudo systemctl daemon-reload #변경된 설정파일 인식
systemctl restart kubelet
kubectl uncordon <노드명>

 

다른 방법 (Rolling 방식 대안)

신규 버전의 노드를 클러스터에 추가 → 파드를 evict or migrate → 구버전 노드를 제거

장점: 다운타임 거의 없음, 특히 무중단 서비스 중요할 때 유리

 

 

공식 문서 업데이트 방법 정리

 : https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ 

 

# taint있는지 확인 없다면 drain등을했을때 노드가 스케줄링 편하게 될 수 있는거 
kubectl describe node node01 | grep -i taint # i는 대소문자 구분없이 조회하라는 뜻

 

 

 

Backup And Restore

쿠버네티스에서 백업을 한다면 어떤걸 해야할까 

etcd : 클러스터의 상태(모든 리소스, 노드 등)을 저장하는 핵심 저장소 

persistent volume(pv) : 애플리케이션의 영속 데이터 

리소스 정의 파일들 (yaml) :  deployment, service, configmap 등 

 

 

리소스 백업 방식

Declarative 방식을 사용한경우 

kubectl apply -f 를 사용해서 yaml 파일을 리소스로 생성할 수 있다. 

전체 리소스 파일을 git 과 같은 저장소등에 보관 해서 사용하면 된다 

 

imperative 방식은 명령어로 리소스를 만들어서 기록이 안남지만 

kubectl get aall --all-namespaces -o yaml 을 사용해서 전체 리소스를 백업 할 수 있다. 

 

etcd 백업 & 복원

링크

etcdctl snapshot save snapshot.db 명령 을 통해서 etcd 백업 가능 

etcdctl snapshot status snapshot.db 를 통해서 백업 상태 확인 가능 

 

복원 절차 

- Kube API Server 중지 (etcd 의존성이 있기 때문)

- etcdctl snapshot restore snapshot.db 수행

- 새로운 data-dir 생성됨 (ex: /var/lib/etcd-from-backup)

-  etcd 설정 파일 수정 → 새 data-dir 반영

- systemctl daemon-reload 및 etcd 서비스 재시작

- Kube API Server 재시작

(etcdctl 명령 시 인증서(cert), 키(key), CA 인증서 경로 등 필요하다)

복원이 되고 나면 기존 클러스터와 분리된 새 etcd 클러스터로 인식된다 (클러스터 id 변경) 

 

etcd 스냅샷은 클러스터 전체 복원이 필요할 때 강력한 옵션

Managed Kubernetes 환경(GKE, EKS 등)에서는 etcd 접근이 불가능한 경우가 많기 때문에 Kube API Server를 통한 리소스 백업이 실용적 

 

 

 

etctl 이란 

etcdctl은 etcd와 상호작용하는 CLI 도구입니다.

Kubernetes 클러스터에서는 ETCD가 마스터 노드의 static pod로 동작한다

# etcd 사용전 해당 설정 필수 보통 v3버전 사용된다(이거 안붙이면 아래 명령어 칠떄 앞에 저거 붙여줘야함) 
export ETCDCTL_API=3 

# 명령어 도움말 확인
etcdctl snapshot save -h
etcdctl snapshot restore -h

 

 

 

TLS 인증 필수 옵션

tls가 활성화된 etcd에 접근 하기 위해서는 다음 옵션 필수 

--endpoints=127.0.0.1:2379   : etcd 기본 주소 (localhost에서 2379 포트로 실행 중)

--cacert : CA 인증서 경로 (서버 인증을 위해 사용)

--cert :클라이언트 인증서 (자신을 식별하기 위해 사용)

--key :클라이언트 인증서에 대한 개인 키

 

etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /path/to/snapshot.db

 

자주 사용되는 명령어

#스냅샷 저장 (백업)
etcdctl snapshot save <snapshot파일경로>

#스냅샷 복원
etcdctl snapshot restore <snapshot파일경로>
ex) 
etcdctl  --data-dir /var/lib/etcd-from-backup \
snapshot restore /opt/snapshot-pre-boot.db
(--data-dir 는 데이터를 복원할 디렉토리)

--> 이렇게 복원하고나면 
/etc/kubernetes/manifests/etcd.yaml 에서 
hostPath를 해당 경로로 변경해줘야한다

-> 외부서버? 면 
vi /etc/systemd/system/etcd.service ? 이렇게가서 변경


# etcd cluster의 member 확인
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/etcd/pki/ca.pem \
  --cert=/etc/etcd/pki/etcd.pem \
  --key=/etc/etcd/pki/etcd-key.pem \
   member list

 

 

ps 명령어들

#전체 클러스터 확인
kubectl config view

# 현재 클러스터 확인 명령어
kubectl config get-clusters

# 클러스터 스위칭 명령어
kubectl config use-context cluster1

# static etcd 있는지확인
kubectl get pods -n kube-system  | grep etcd

# external etcd 쓰는 경우있음 아래 명령어로 찾기 가능 
etcd 파드 없어도
apiserver 쪽 들어가서 etcd-servers 에 주소 있는지 확인(여기는 있으면 이거 외부 etcd)

다르게 찾는법
ps -ef | grep etcd 
(ps 현재 실행중인 프로세스 보기, -e 시스템의 모든 사용자 출력, -f full format으로 출력)
ps -ef | grep --color=auto etcd (이렇게하면 색 표기됨)


#scp로 데이터 복사 리눅스에서 파일을 원격 서버로 복사하는 명령어

# 로컬 → 원격
scp <로컬파일> <사용자@원격서버>:<경로>
# 원격 → 로컬
scp <사용자@원격서버>:<파일경로> <로컬저장경로>

ex) scp /opt/cluster2.db etcd-server:/root