노드를 유지보수 모드로 전환

노드를 복구 또는 유지보수해야 하는 경우 먼저 노드를 유지보수 모드로 설정해야 합니다. 이렇게 하면 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 Cloud kube-scheduler가 포드를 중지하고 노드를 드레이닝합니다. 이 노드 드레이닝 메서드는 PDB를 준수하지 않습니다.

  • 포드가 중지될 때까지 노드가 중단되지 않도록 제한 시간 20분이 적용됩니다. 모든 taint를 허용하도록 구성되었거나 최종화가 있는 포드는 중지되지 않을 수 있습니다. Google Distributed Cloud가 모든 포드를 중지하려고 시도하지만 제한 시간이 초과되면 노드가 유지보수 모드로 전환됩니다. 이 제한 시간은 실행 중인 포드에서 업그레이드를 차단하지 못하게 합니다.

제거 기반 드레이닝

taint 기반 드레이닝에서 제거 기반 노드 드레이닝으로 전환하는 것과 관련된 절차적 변경 사항은 없습니다. 전환은 조정 로직에만 영향을 미칩니다.

이 기능은 지원되는 모든 버전에서 동일한 출시 단계에 있는 것은 아닙니다.

  • 1.29: GA
  • 1.28: 사용할 수 없음
  • 1.16: 사용할 수 없음

드레이닝 순서

출시 버전 1.29 이전에는 Google Distributed Cloud kube-scheduler에서 수행하는 taint 기반 노드 드레이닝은 특정 알고리즘을 사용하여 노드에서 포드를 드레이닝하지 않습니다. 제거 기반 노드 드레이닝을 사용하면 포드가 우선순위에 따라 특정 순서로 제거됩니다. 제거 우선순위는 다음 표에 나온 대로 특정 포드 기준과 연관되어 있습니다:

드레이닝 순서 포드 기준(모두 일치해야 함) 및 다음 기준
1

다음 기준과 일치하는 포드가 삭제됩니다.

  • spec.prorityClassName이 없는 포드
  • 알려진 컨테이너 스토리지 인터페이스(CSI) 이름과 일치하지 않는 포드
  • DaemonSet에 속하지 않는 포드
2

다음 기준과 일치하는 포드가 삭제됩니다.

  • DaemonSet에 속하는 포드
  • 포드에 PriorityClass 없음
  • 알려진 컨테이너 스토리지 인터페이스(CSI) 이름과 일치하지 않는 포드
3

다음 기준과 일치하는 포드가 삭제됩니다.

  • Spec.ProrityClassName을 사용하는 포드
  • 알려진 컨테이너 스토리지 인터페이스(CSI) 이름과 일치하지 않는 포드

일치하는 포드의 제거 순서는 PriorityClass.value 기준으로 낮은 값에서 높은 값 순입니다.
4

포드가 모두 제거된 후 CSI가 PV/PVC 마운트를 정리할 때까지 기다립니다. 모든 볼륨이 정리되었음을 표시하려면 Node.Status.VolumesInUse를 사용합니다.
5

다음 기준과 일치하는 포드가 삭제됩니다.

  • 알려진 컨테이너 스토리지 인터페이스(CSI) 이름과 일치하는 포드

이러한 포드는 여전히 드레이닝이 필요합니다. kubelet은 인플레이스(In-Place) 업그레이드 호환성을 제공하지 않기 때문입니다.

제거 기반 노드 드레이닝은 PDB를 선정하므로 일부 상황에서는 PDB 설정이 노드 드레이닝을 차단할 수 있습니다. 노드 풀 드레이닝에 대한 문제해결 정보는 노드가 오랫동안 드레이닝 상태인 이유 확인을 참조하세요.

제거 기반 노드 드레이닝 사용 중지

제거 기반 노드 드레이닝은 마이너 버전 1.29의 클러스터 또는 마이너 버전 1.29로 업그레이드 중인 클러스터에서 기본적으로 사용 설정됩니다. 제거 기반 노드 드레이닝으로 인해 클러스터 업그레이드 또는 클러스터 유지보수에 문제가 발생하는 경우 클러스터 리소스에 baremetal.cluster.gke.io/maintenance-mode-ignore-pdb: true 주석을 추가하여 taint 기반 노드 드레이닝으로 되돌릴 수 있습니다.

노드를 유지보수 모드로 전환

클러스터 구성 파일에서 maintenanceBlocks 아래에 선택한 노드에 대해 IP 범위를 지정하여 유지보수 모드로 설정할 노드를 선택합니다. 선택한 노드가 준비 상태이며 클러스터에서 작동해야 합니다.

노드를 유지보수 모드로 설정하려면 다음 안내를 따르세요.

  1. 클러스터 구성 파일을 수정하여 유지보수 모드로 설정할 노드를 선택합니다.

    원하는 편집기로 구성 파일을 수정하거나 다음 명령어를 실행하여 클러스터 커스텀 리소스를 직접 수정할 수 있습니다.

    kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

    다음을 바꿉니다.

    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.
    • CLUSTER_NAME: 클러스터의 이름입니다.

  2. maintenanceBlocks 섹션을 클러스터 구성 파일에 추가하여 유지보수 모드로 설정할 노드에 대해 단일 IP 주소 또는 주소 범위를 지정합니다.

    다음 샘플은 IP 주소 범위를 지정하여 여러 노드를 선택하는 방법을 보여줍니다.

    metadata:
  name: my-cluster
  namespace: cluster-my-cluster
spec:
  maintenanceBlocks:
    cidrBlocks:
    - 172.16.128.1-172.16.128.64

  3. 업데이트된 클러스터 구성을 저장하고 적용합니다.

    Google Distributed Cloud가 노드를 유지보수 모드로 전환합니다.

  4. 다음 명령어를 실행하여 클러스터에서 노드 상태를 가져옵니다.

    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는 적절한 내결함성이 없는 모든 포드가 노드에 예약되지 않도록 합니다.

  5. 다음 명령어를 실행하여 유지보수 모드에서 노드 수를 가져옵니다.

    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

유지보수 모드에서 노드 삭제

유지보수 모드에서 노드를 삭제하려면 다음을 안내를 따르세요.

  1. 클러스터 구성 파일을 수정하여 유지보수 모드에서 삭제하려는 노드를 지웁니다.

    원하는 편집기로 구성 파일을 수정하거나 다음 명령어를 실행하여 클러스터 커스텀 리소스를 직접 수정할 수 있습니다.

    kubectl -n CLUSTER_NAMESPACE edit cluster CLUSTER_NAME

    다음을 바꿉니다.

    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.
    • CLUSTER_NAME: 클러스터의 이름입니다.

  2. IP 주소를 수정하여 유지보수 모드에서 특정 노드를 삭제하거나 maintenanceBlocks 섹션을 삭제하여 유지보수 모드에서 모든 노드를 삭제합니다.

  3. 업데이트된 클러스터 구성을 저장하고 적용합니다.

  4. kubectl 명령어를 사용하여 노드 상태를 확인합니다.

클러스터 종료 및 다시 시작

전체 클러스터를 중단해야 하는 경우 다음 섹션의 안내에 따라 클러스터를 종료하고 안전하게 백업하세요.

클러스터 종료

사용자 클러스터를 관리하는 클러스터를 종료할 경우 먼저 모든 관리형 사용자 클러스터를 종료해야 합니다. 다음 안내는 모든 Google Distributed Cloud 클러스터 유형에 적용됩니다.

  1. 모든 클러스터 노드의 상태를 확인합니다.

    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인 경우에만 진행하는 것이 좋습니다.

  2. 사용자 클러스터를 종료하는 경우 관리자 클러스터 노드의 상태를 확인하세요.

    kubectl get nodes --kubeconfig ADMIN_KUBECONFIG

    ADMIN_KUBECONFIG를 관리 클러스터에 대한 kubeconfig 파일의 경로로 바꿉니다.

    이후 단계는 관리자 클러스터에 따라 달라집니다. 노드에 대한 STATUS가 Ready가 아닌 경우 해당 노드의 문제를 해결하고 모든 노드가 Ready인 경우에만 진행하는 것이 좋습니다.

  3. 종료할 클러스터의 상태를 확인합니다.

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    다음을 바꿉니다.

    • CLUSTER_NAME: 확인 중인 클러스터의 이름

    • ADMIN_KUBECONFIG: 관리 클러스터의 kubeconfig 파일 경로

    진행하기 전에 보고된 문제를 수정하세요.

  4. 종료하는 클러스터의 경우 모든 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일 때만 진행합니다.

  5. 클러스터 백업에 설명된 대로 백업을 수행합니다.

    클러스터를 종료하기 전에 etcd 백업을 수행하여 클러스터를 재시작할 때 문제가 발생할 경우 클러스터를 복원할 수 있도록 하는 것이 중요합니다. etcd 손상, 노드 하드웨어 오류, 네트워크 연결 문제, 기타 조건으로 인해 클러스터가 올바르게 다시 시작되지 않을 수 있습니다.

  6. 워커 노드가 있는 클러스터를 종료하는 경우 워커 노드를 유지보수 모드로 전환합니다.

    이 단계에서는 etcd에 쓰는 데이터의 양을 최소화하여 클러스터를 다시 시작할 때 대량의 etcd 쓰기를 조정해야 할 가능성을 줄입니다.

  7. 컨트롤 플레인 노드를 유지보수 모드로 전환합니다.

    이 단계는 노드 종료 중에 스테이트풀(Stateful) 워크로드에 대한 손상된 쓰기를 방지합니다.

  8. 다음 순서로 클러스터 노드의 전원을 종료합니다.

    1. 워커 노드
    2. 컨트롤 플레인 부하 분산기 노드

    3. 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 열이 포함됩니다.

이 시점에서 클러스터가 완전히 종료됩니다. 필요한 유지보수를 수행한 후 다음 섹션에 설명된 대로 클러스터를 다시 시작할 수 있습니다.

클러스터 다시 시작

다음 단계를 따라 완전히 전원을 끈 클러스터를 다시 시작합니다.

  1. 전원 종료 시퀀스의 역순으로 노드 머신을 켭니다.

  2. 유지보수 모드에서 컨트롤 플레인 노드를 삭제합니다.

    자세한 내용은 유지보수 모드에서 노드 삭제를 참조하세요.

  3. 유지보수 모드에서 워커 노드 삭제

  4. 클러스터 상태 확인을 실행하여 클러스터가 올바르게 작동하는지 확인합니다.

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

  5. 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 파일 경로로 바꿉니다.