노드를 복구 또는 유지보수해야 하는 경우 먼저 노드를 유지보수 모드로 설정해야 합니다. 이렇게 하면 API 서버와 같은 중요 시스템 포드를 제외한 기존 포드 및 워크로드가 드레이닝됩니다. 또한 유지보수 모드를 사용하면 노드에서 새로운 포드가 할당되지 않습니다. 유지보수 모드에서는 포드 트래픽을 방해할 위험 없이 노드에서 작업할 수 있습니다.
작동 방식
Google Distributed Cloud는 노드를 유지보수 모드로 설정하는 방법을 제공합니다. 이 접근 방식을 사용하면 다른 클러스터 구성요소는 노드가 유지보수 모드임을 올바르게 알 수 있습니다. 노드를 유지보수 모드로 설정하면 노드에 추가 포드를 예약할 수 없으며 기존 포드가 중지됩니다.
유지보수 모드를 사용하는 대신 특정 노드에서 kubectl cordon
및 kubectl drain
과 같은 Kubernetes 명령어를 수동으로 사용할 수 있습니다.
유지보수 모드 프로세스를 사용하면 Google Distributed Cloud가 다음을 수행합니다.
1.29
Google Distributed Cloud는 노드에서 새 포드가 예약되지 않도록 지정된 노드에
baremetal.cluster.gke.io/maintenance:NoSchedule
taint를 추가합니다.Google Distributed Cloud는 Eviction API를 사용하여 각 포드를 제거합니다. 이 노드 드레이닝 메서드는 PodDisruptionBudgets(PDB)를 준수합니다.
minAvailable
및maxUnavailable
필드를 사용하여 포드 집합에 대해 허용 가능한 중단 수준을 지정하여 워크로드를 보호하도록 PDB를 구성할 수 있습니다. 이 방법으로 노드를 드레이닝하면 워크로드 중단에 대해 더 나은 보호를 제공합니다. 제거 기반 노드 드레이닝은 출시 버전 1.29의 정식 버전으로 제공됩니다.포드가 중지될 때까지 노드가 중단되지 않도록 제한 시간 20분이 적용됩니다. 모든 taint를 허용하도록 구성되었거나 최종화가 있는 포드는 중지되지 않을 수 있습니다. Google Distributed Cloud가 모든 포드를 중지하려고 시도하지만 제한 시간이 초과되면 노드가 유지보수 모드로 전환됩니다. 이 제한 시간은 실행 중인 포드에서 업그레이드를 차단하지 못하게 합니다.
1.28 이하
Google Distributed Cloud는 노드에서 새 포드가 예약되지 않도록 지정된 노드에
baremetal.cluster.gke.io/maintenance:NoSchedule
taint를 추가합니다.Google Distributed Cloud는
baremetal.cluster.gke.io/maintenance:NoExecute
taint를 추가합니다.NoExecute
taint에서 작동하면 Google Distributed Cloudkube-scheduler
가 포드를 중지하고 노드를 드레이닝합니다. 이 노드 드레이닝 메서드는 PDB를 준수하지 않습니다.포드가 중지될 때까지 노드가 중단되지 않도록 제한 시간 20분이 적용됩니다. 모든 taint를 허용하도록 구성되었거나 최종화가 있는 포드는 중지되지 않을 수 있습니다. Google Distributed Cloud가 모든 포드를 중지하려고 시도하지만 제한 시간이 초과되면 노드가 유지보수 모드로 전환됩니다. 이 제한 시간은 실행 중인 포드에서 업그레이드를 차단하지 못하게 합니다.
제거 기반 드레이닝
taint 기반 드레이닝에서 제거 기반 노드 드레인으로 전환하는 것과 관련된 절차적 변경 사항은 없습니다. 전환은 조정 로직에만 영향을 미칩니다.
이 기능은 지원되는 모든 버전에서 동일한 출시 단계에 있는 것은 아닙니다.
- 1.29: GA
- 1.28: 사용할 수 없음
- 1.16: 사용할 수 없음
드레이닝 순서
출시 버전 1.29 이전에는 Google Distributed Cloud kube-scheduler
에서 수행하는 taint 기반 노드 드레이닝은 특정 알고리즘을 사용하여 노드에서 포드를 드레이닝하지 않습니다. 제거 기반 노드 드레이닝을 사용하면 포드가 우선순위에 따라 특정 순서로 제거됩니다. 제거 우선순위는 다음 표에 나온 대로 특정 포드 기준과 연관되어 있습니다:
드레이닝 순서 | 포드 기준(모두 일치해야 함) 및 다음 기준 |
---|---|
1 |
다음 기준과 일치하는 포드가 삭제됩니다.
|
2 |
다음 기준과 일치하는 포드가 삭제됩니다.
|
3 |
다음 기준과 일치하는 포드가 삭제됩니다.
일치하는 포드의 제거 순서는 |
4 |
포드가 모두 제거된 후 CSI가 PV/PVC 마운트를 정리할 때까지 기다립니다. 모든 볼륨이 정리되었음을 표시하려면 |
5 |
다음 기준과 일치하는 포드가 삭제됩니다.
이러한 포드는 여전히 드레이닝이 필요합니다. kubelet은 인플레이스(In-Place) 업그레이드 호환성을 제공하지 않기 때문입니다. |
제거 기반 노드 드레이닝은 PDB를 선정하므로 일부 상황에서는 PDB 설정이 노드 드레이닝을 차단할 수 있습니다. 노드 풀 드레이닝에 대한 문제해결 정보는 노드가 오랫동안 드레이닝 상태인 이유 확인을 참조하세요.
제거 기반 노드 드레이닝 사용 중지
제거 기반 노드 드레이닝은 부 버전 1.29의 클러스터 또는 부 버전 1.29로 업그레이드 중인 클러스터에서 기본적으로 사용 설정됩니다. 제거 기반 노드 드레이닝으로 인해 클러스터 업그레이드 또는 클러스터 유지보수에 문제가 발생하는 경우 클러스터 리소스에 baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true
주석을 추가하여 taint 기반 노드 드레이닝으로 되돌릴 수 있습니다.
노드를 유지보수 모드로 전환
클러스터 구성 파일에서 maintenanceBlocks
아래에 선택한 노드에 대해 IP 범위를 지정하여 유지보수 모드로 설정할 노드를 선택합니다. 선택한 노드가 준비 상태이며 클러스터에서 작동해야 합니다.
노드를 유지보수 모드로 설정하려면 다음 안내를 따르세요.
클러스터 구성 파일을 수정하여 유지보수 모드로 설정할 노드를 선택합니다.
원하는 편집기로 구성 파일을 수정하거나 다음 명령어를 실행하여 클러스터 커스텀 리소스를 직접 수정할 수 있습니다.
kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
다음을 바꿉니다.
CLUSTER_NAMESPACE
: 클러스터의 네임스페이스입니다.CLUSTER_NAME
: 클러스터의 이름입니다.
maintenanceBlocks
섹션을 클러스터 구성 파일에 추가하여 유지보수 모드로 설정할 노드에 대해 단일 IP 주소 또는 주소 범위를 지정합니다.다음 샘플은 IP 주소 범위를 지정하여 여러 노드를 선택하는 방법을 보여줍니다.
metadata: name: my-cluster namespace: cluster-my-cluster spec: maintenanceBlocks: cidrBlocks: - 172.16.128.1-172.16.128.64
업데이트된 클러스터 구성을 저장하고 적용합니다.
Google Distributed Cloud가 노드를 유지보수 모드로 전환합니다.
다음 명령어를 실행하여 클러스터에서 노드 상태를 가져옵니다.
kubectl get nodes --kubeconfig=KUBECONFIG
출력은 다음과 비슷합니다.
NAME STATUS ROLES AGE VERSION user-anthos-baremetal-01 Ready control-plane 2d22h v1.27.4-gke.1600 user-anthos-baremetal-04 Ready worker 2d22h v1.27.4-gke.1600 user-anthos-baremetal-05 Ready worker 2d22h v1.27.4-gke.1600 user-anthos-baremetal-06 Ready worker 2d22h v1.27.4-gke.1600
노드는 여전히 예약할 수 있지만 taint는 적절한 내결함성이 없는 모든 포드가 노드에 예약되지 않도록 합니다.
다음 명령어를 실행하여 유지보수 모드에서 노드 수를 가져옵니다.
kubectl get nodepools --kubeconfig ADMIN_KUBECONFIG
응답은 다음 예시와 같이 표시됩니다.
NAME READY RECONCILING STALLED UNDERMAINTENANCE UNKNOWN np1 3 0 0 1 0
이 샘플에서 이
UNDERMAINTENANCE
열은 한 노드가 유지보수 모드에 있음을 보여줍니다.Google Distributed Cloud는 노드가 유지보수 모드로 설정될 때 노드에 다음 taint도 추가합니다.
baremetal.cluster.gke.io/maintenance:NoExecute
baremetal.cluster.gke.io/maintenance:NoSchedule
유지보수 모드에서 노드 삭제
유지보수 모드에서 노드를 삭제하려면 다음을 안내를 따르세요.
클러스터 구성 파일을 수정하여 유지보수 모드에서 삭제하려는 노드를 지웁니다.
원하는 편집기로 구성 파일을 수정하거나 다음 명령어를 실행하여 클러스터 커스텀 리소스를 직접 수정할 수 있습니다.
kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME
다음을 바꿉니다.
CLUSTER_NAMESPACE
: 클러스터의 네임스페이스입니다.CLUSTER_NAME
: 클러스터의 이름입니다.
IP 주소를 수정하여 유지보수 모드에서 특정 노드를 삭제하거나
maintenanceBlocks
섹션을 삭제하여 유지보수 모드에서 모든 노드를 삭제합니다.업데이트된 클러스터 구성을 저장하고 적용합니다.
kubectl
명령어를 사용하여 노드 상태를 확인합니다.
클러스터 종료 및 다시 시작
전체 클러스터를 중단해야 하는 경우 다음 섹션의 안내에 따라 클러스터를 종료하고 안전하게 백업하세요.
클러스터 종료
사용자 클러스터를 관리하는 클러스터를 종료할 경우 먼저 모든 관리형 사용자 클러스터를 종료해야 합니다. 다음 안내는 모든 Google Distributed Cloud 클러스터 유형에 적용됩니다.
모든 클러스터 노드의 상태를 확인합니다.
kubectl get nodes --kubeconfig CLUSTER_KUBECONFIG
CLUSTER_KUBECONFIG
를 클러스터에 대한 kubeconfig 파일의 경로로 바꿉니다.출력은 다음과 비슷합니다.
NAME STATUS ROLES AGE VERSION control-0 Ready control-plane 202d v1.27.4-gke.1600 control-1 Ready control-plane 202d v1.27.4-gke.1600 control-2 Ready control-plane 202d v1.27.4-gke.1600 worker-0 Ready worker 202d v1.27.4-gke.1600 worker-1 Ready worker 202d v1.27.4-gke.1600 worker-2 Ready worker 202d v1.27.4-gke.1600 worker-3 Ready worker 202d v1.27.4-gke.1600 worker-4 Ready worker 154d v1.27.4-gke.1600 worker-5 Ready worker 154d v1.27.4-gke.1600 worker-6 Ready worker 154d v1.27.4-gke.1600 worker-7 Ready worker 154d v1.27.4-gke.1600 worker-8 Ready worker 154d v1.27.4-gke.1600 worker-9 Ready worker 154d v1.27.4-gke.1600
노드의
STATUS
가Ready
가 아닌 경우 해당 노드의 문제를 해결하고 모든 노드가Ready
인 경우에만 진행하는 것이 좋습니다.사용자 클러스터를 종료하는 경우 관리자 클러스터 노드의 상태를 확인하세요.
kubectl get nodes --kubeconfig ADMIN_KUBECONFIG
ADMIN_KUBECONFIG
를 관리 클러스터에 대한 kubeconfig 파일의 경로로 바꿉니다.이후 단계는 관리자 클러스터에 따라 달라집니다. 노드에 대한
STATUS
가Ready
가 아닌 경우 해당 노드의 문제를 해결하고 모든 노드가Ready
인 경우에만 진행하는 것이 좋습니다.종료할 클러스터의 상태를 확인합니다.
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
다음을 바꿉니다.
CLUSTER_NAME
: 확인 중인 클러스터의 이름ADMIN_KUBECONFIG
: 관리 클러스터의 kubeconfig 파일 경로
진행하기 전에 보고된 문제를 수정하세요.
종료하는 클러스터의 경우 모든
etcd
포드가 실행 중인지 확인합니다.kubectl get pods --kubeconfig CLUSTER_KUBECONFIG -A \ -l component=etcd
CLUSTER_KUBECONFIG
를 클러스터에 대한 kubeconfig 파일의 경로로 바꿉니다.출력은 다음과 비슷합니다.
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system etcd-control-0-admin 1/1 Running 0 2d22h kube-system etcd-control-1-admin 1/1 Running 0 2d22h kube-system etcd-control-2-admin 1/1 Running 0 2d22h
포드에 대한
STATUS
가Running
이 아닌 경우 포드 문제를 해결하고 모든 포드가Running
일 때만 진행합니다.클러스터 백업에 설명된 대로 백업을 수행합니다.
클러스터를 종료하기 전에 etcd 백업을 수행하여 클러스터를 재시작할 때 문제가 발생할 경우 클러스터를 복원할 수 있도록 하는 것이 중요합니다. etcd 손상, 노드 하드웨어 오류, 네트워크 연결 문제, 기타 조건으로 인해 클러스터가 올바르게 다시 시작되지 않을 수 있습니다.
워커 노드가 있는 클러스터를 종료하는 경우 워커 노드를 유지보수 모드로 전환합니다.
이 단계에서는 etcd에 쓰는 데이터의 양을 최소화하여 클러스터를 다시 시작할 때 대량의 etcd 쓰기를 조정해야 할 가능성을 줄입니다.
제어 영역 노드를 유지보수 모드로 전환합니다.
이 단계는 노드 종료 중에 스테이트풀(Stateful) 워크로드에 대한 손상된 쓰기를 방지합니다.
다음 순서로 클러스터 노드의 전원을 끕니다.
- 워커 노드
- 제어 영역 부하 분산기 노드
etcd 팔로어로 시작하여 etcd 리더로 끝나는 제어 영역 노드
고가용성(HA) 클러스터가 있는 경우 SSH를 사용하여 각 제어 영역 노드에 연결하고 다음
etcdctl
명령어를 실행하여 etcd 리더를 찾을 수 있습니다.ETCDCTL_API=3 etcdctl \ --cacert /etc/kubernetes/pki/etcd/ca.crt \ --cert /etc/kubernetes/pki/etcd/server.crt \ --key /etc/kubernetes/pki/etcd/server.key \ --write-out=table endpoint status
노드가 etcd 리더인 경우 응답에
true
를 반환하는IS LEADER
열이 포함됩니다.
이 시점에서 클러스터가 완전히 종료됩니다. 필요한 유지보수를 수행한 후 다음 섹션에 설명된 대로 클러스터를 다시 시작할 수 있습니다.
클러스터 다시 시작
다음 단계를 따라 완전히 전원을 끈 클러스터를 다시 시작합니다.
전원 종료 시퀀스의 역순으로 노드 머신을 켭니다.
제어 영역 노드를 유지보수 모드에서 삭제합니다.
자세한 내용은 유지보수 모드에서 노드 삭제를 참조하세요.
유지보수 모드에서 워커 노드를 삭제합니다.
클러스터 상태 확인을 실행하여 클러스터가 올바르게 작동하는지 확인합니다.
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
etcd 비정상 종료와 같은 문제로 인해 클러스터가 제대로 다시 시작되지 않는 경우 마지막으로 알려진 정상 백업에서 클러스터를 복원해 보세요. 자세한 안내는 클러스터 복원을 참조하세요.
청구 및 유지보수 모드
Google Distributed Cloud의 청구는 워크로드를 실행할 수 있는 노드에 대해 클러스터에 있는 vCPU 수를 기준으로 청구됩니다. 노드를 유지보수 모드로 설정하면 NoExecute
및 NoSchedule
taint가 노드에 추가되지만 결제를 사용 중지하지는 않습니다. 노드를 유지보수 모드로 전환한 후 노드(kubectl cordon NODE_NAME
)를 차단하여 예약 불가능으로 표시하세요. 노드가 예약할 수 없는 것으로 표시되면 노드 및 연결된 vCPU가 청구에서 제외됩니다.
가격 책정 페이지에 설명된 대로 kubectl
을 사용하여 각 사용자 클러스터의 vCPU 용량(청구에 사용됨)을 확인할 수 있습니다. 이 명령어는 노드가 예약 가능한지 여부는 고려하지 않고 노드당 vCPU 수만 제공합니다.
사용자 클러스터의 노드당 vCPU 수를 확인하려면 다음 명령어를 실행합니다.
kubectl get nodes \
--kubeconfig USER_KUBECONFIG \
-o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"} \
{.status.capacity.cpu}{\"\n\"}{end}"
USER_KUBECONFIG를 사용자 클러스터의 kubeconfig 파일 경로로 바꿉니다.