상태 점검

상태 점검은 기존 클러스터의 작업을 테스트하고 모니터링하는 방법입니다. 상태 점검은 주기적으로 자체적으로 실행됩니다. bmctl을 사용하여 주문형으로 상태 점검을 실행할 수도 있습니다. 이 문서에서는 각각의 검사에 대해 알아보고 각 검사가 자동으로 실행되는 상황, 수동으로 검사를 실행하는 방법과 시기, 결과를 해석하는 방법을 설명합니다.

검사 대상

베어메탈용 GDCV 상태 점검에는 다음과 같은 두 가지 카테고리가 있습니다.

  • 노드 머신 검사

  • 클러스터 전체 검사

다음 섹션에서는 각 카테고리의 검사 대상을 간략하게 설명합니다. 정기 상태 점검과 주문형 상태 점검 모두에 이러한 검사가 사용됩니다.

노드 머신 검사

이 섹션에서는 노드 머신의 상태 점검에서 평가되는 항목을 설명합니다. 이러한 검사는 노드 머신이 올바르게 구성되었는지 확인하고 클러스터 생성, 클러스터 업그레이드, 클러스터 작업에 충분한 리소스와 연결이 있는지 확인합니다.

이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-NODE_IP_ADDRESS-machine이라는 베어메탈 HealthCheck 커스텀 리소스(예: bm-system-192.0.2.54-machine)에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.

일반적인 머신 검사는 다음으로 구성됩니다.

  • 클러스터 머신에서 지원되는 운영체제(OS)를 사용합니다.

  • OS 버전이 지원됩니다.

  • OS에서 지원되는 커널 버전을 사용합니다.

  • 커널에 BPF JIT(Just In Time) 컴파일러 옵션이 사용 설정되어 있습니다(CONFIG_BPF_JIT=y).

  • Ubuntu의 경우 Uncomplicated Firewall(UFW)이 사용 중지됩니다.

  • 노드 머신이 최소 CPU 요구사항을 충족합니다.

  • 노드 머신에서 사용 가능한 CPU 리소스가 20% 이상입니다.

  • 노드 머신이 최소 메모리 요구사항을 충족합니다.

  • 노드 머신이 최소 디스크 스토리지 요구사항을 충족합니다.

  • 시간 동기화가 노드 머신에 구성됩니다.

  • 패킷을 기본 게이트웨이로 라우팅하는 기본 경로가 노드에 있습니다.

  • DNS(도메인 이름 시스템)가 작동합니다. 클러스터가 프록시 뒤에서 실행되도록 구성된 경우 이 검사는 건너뜁니다.

  • 클러스터가 레지스트리 미러를 사용하도록 구성된 경우 레지스트리 미러에 연결할 수 있습니다.

머신 Google Cloud 검사는 다음과 같이 구성됩니다.

  • Container Registry, gcr.io에 연결할 수 있습니다. 클러스터가 레지스트리 미러를 사용하도록 구성된 경우 이 검사를 건너뜁니다.

  • Google API에 연결할 수 있습니다.

머신 상태 점검은 다음으로 구성됩니다.

  • kubelet가 활성 상태이며 노드 머신에서 실행 중입니다.

  • containerd가 활성 상태이며 노드 머신에서 실행 중입니다.

  • 컨테이너 네트워크 인터페이스(CNI) 상태 엔드포인트 상태가 정상입니다.

  • 포드 CIDR이 노드 머신 IP 주소와 겹치지 않습니다.

노드 머신 요구사항에 대한 자세한 내용은 클러스터 노드 머신 기본 요건을 참조하세요.

클러스터 전체 검사

이 섹션에서는 클러스터의 상태 점검에서 평가되는 항목을 설명합니다.

네트워크 검사

다음 클라이언트 측 클러스터 노드 네트워크 검사가 주기적인 상태 점검의 일부로 자동으로 실행됩니다. 네트워크 검사는 주문형으로 실행할 수 없습니다. 이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-network라는 베어메탈 HealthCheck 커스텀 리소스에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.

  • 클러스터가 번들 부하 분산을 사용하는 경우 부하 분산 노드 풀의 노드에 레이어 2 주소 결정 프로토콜(ARP) 연결이 있어야 합니다. ARP는 VIP 탐색에 필요합니다.

  • 제어 영역 노드에는 etcd-events 인스턴스에서 사용할 수 있도록 포트 2382 및 2383이 열려 있습니다.

베어메탈용 GKE 클러스터의 프로토콜 및 포트 사용량에 대한 자세한 내용은 네트워크 요구사항을 참조하세요.

프리플라이트 검사를 위한 네트워크 검사는 네트워크 상태 점검과 다릅니다. 프리플라이트 검사를 위한 네트워크 검사 목록은 클러스터 생성에 대한 프리플라이트 검사 또는 클러스터 업그레이드에 대한 프리플라이트 검사를 참조하세요.

Kubernetes

프리플라이트 검사 및 주기적인 상태 점검의 일부로 자동으로 실행되는 Kubernetes 검사는 주문형으로 실행할 수도 있습니다. 이러한 상태 점검은 나열된 제어 영역 구성요소가 누락된 경우 오류를 반환하지 않습니다. 구성요소가 존재하고 명령어 실행 시 오류가 있는 경우에만 검사에서 오류를 반환합니다.

이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-kubernetes 리소스라는 베어메탈 HealthCheck 커스텀 리소스에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.

  • API 서버가 작동하고 있습니다.

  • anetd 연산자가 올바르게 구성되었습니다.

  • 모든 제어 영역 노드가 작동합니다.

  • 다음 제어 영역 구성요소가 올바르게 작동합니다.

    • anthos-cluster-operator

    • controller-manager

    • cluster-api-provider

    • ais

    • capi-kubeadm-bootstrap-system

    • cert-manager

    • kube-dns

부가기능

부가기능 검사는 프리플라이트 검사 및 주기적인 상태 점검의 일부로 자동으로 실행되며 주문형으로 실행할 수도 있습니다. 나열된 부가기능 중 하나라도 누락된 경우 이 상태 점검은 오류를 반환하지 않습니다. 부가기능이 존재하고 명령어 실행 시 오류가 있는 경우에만 검사에서 오류를 반환합니다.

이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-add-ons* 리소스라는 베어메탈 HealthCheck 커스텀 리소스에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.

  • Cloud Logging Stackdriver 구성요소 및 Connect 에이전트가 작동합니다.

    • stackdriver-log-aggregator

    • stackdriver-log-forwarder

    • stackdriver-metadata-agent

    • stackdriver-prometheus-k8

    • gke-connect-agent

  • 베어메탈용 GDCV 관리형 리소스에는 수동 변경사항이 표시되지 않습니다(구성 드리프트).

    • 필드 값이 업데이트되지 않음

    • 선택적인 필드가 추가 또는 삭제되지 않음

    • 리소스가 삭제되지 않음

상태 점검에서 구성 드리프트가 감지되면 bm-system-add-ons 베어메탈 HealthCheck 커스텀 리소스 Status.Pass 값이 false로 설정됩니다. Failures 섹션의 Description 필드에는 다음 정보를 포함하여 변경된 리소스에 대한 세부정보가 포함됩니다.

  • Version: 리소스의 API 버전입니다.
  • Kind: 리소스의 객체 스키마(예: Deployment)입니다.
  • Namespace: 리소스가 있는 네임스페이스입니다.
  • Name: 리소스 이름입니다.
  • Diff: 레코드의 리소스 매니페스트와 변경된 리소스의 매니페스트 간의 차이점을 문자열 형식으로 비교합니다.

HealthCheck 커스텀 리소스

상태 점검이 실행되면 베어메탈용 GDCV에서 HealthCheck 커스텀 리소스를 만듭니다. HealthCheck 커스텀 리소스는 영구적이며 상태 점검 활동 및 결과에 대한 구조화된 레코드를 제공합니다. HeathCheck 커스텀 리소스에는 두 가지 카테고리가 있습니다.

  • 베어메탈 HealthCheck 커스텀 리소스(API Version: baremetal.cluster.gke.io/v1): 이러한 리소스는 주기적인 상태 점검에 대한 세부정보를 제공합니다. 이러한 리소스는 클러스터 네임스페이스의 관리자 클러스터에 있습니다. 베어메탈 HealthCheck 리소스는 상태 점검 크론 작업 및 작업을 만듭니다. 이러한 리소스는 최신 결과로 일관되게 업데이트됩니다.

  • Anthos HealthCheck 커스텀 리소스(API Version: anthos.gke.io/v1): 이러한 리소스는 상태 점검 측정항목을 보고하는 데 사용됩니다. 이러한 리소스는 각 클러스터의 kube-system 네임스페이스에 있습니다. 이러한 리소스의 업데이트는 최선의 방식으로 수행됩니다. 일시적인 네트워크 오류와 같은 문제로 인해 업데이트가 실패하면 실패가 무시됩니다.

다음 표에는 HealthCheck 카테고리에 생성되는 리소스 유형이 나와 있습니다.

베어메탈 상태 점검 GKE Enterprise 상태 점검 심각도

유형: 머신

이름: bm-system-NODE_IP_ADDRESS-machine

유형: 머신

이름: bm-system-NODE_IP_ADDRESS-machine

심각

유형: 네트워크

이름: bm-system-network

유형: 네트워크

이름: bm-system-network

심각

유형: kubernetes

이름: bm-system-kubernetes

유형: kubernetes

이름: bm-system-kubernetes

심각

유형: 부가기능

이름: bm-system-add-ons

유형: 부가기능

이름: bm-system-add-ons-add-ons

이름: bm-system-add-ons-configdrift

선택사항

HealthCheck 상태를 가져오려면 다음 안내를 따르세요.

  1. 주기적인 상태 점검의 결과를 읽으려면 연관된 커스텀 리소스를 가져오면 됩니다.

    kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig ADMIN_KUBECONFIG --all-namespaces
    

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

    다음 샘플은 주기적으로 실행되는 상태 점검과 마지막으로 실행되었을 때 검사를 통과했는지 여부를 보여줍니다.

    NAMESPACE               NAME                               PASS    AGE
    cluster-test-admin001   bm-system-192.0.2.52-machine       true    11d
    cluster-test-admin001   bm-system-add-ons                  true    11d
    cluster-test-admin001   bm-system-kubernetes               true    11d
    cluster-test-admin001   bm-system-network                  true    11d
    cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
    cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
    cluster-test-user001    bm-system-add-ons                  true    56d
    cluster-test-user001    bm-system-kubernetes               true    56d
    cluster-test-user001    bm-system-network                  true    56d
    
  2. 특정 상태 점검의 세부정보를 읽으려면 kubectl describe를 사용합니다.

    kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • HEALTHCHECK_NAME: 상태 점검의 이름입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.

    리소스를 검토할 때 Status: 섹션에는 다음과 같은 중요 필드가 포함됩니다.

    • Pass: 마지막 상태 점검 작업을 통과했는지 여부를 나타냅니다.
    • Checks: 가장 최근의 상태 점검 작업에 대한 정보를 포함합니다.
    • Failures: 가장 최근에 실패한 작업에 대한 정보를 포함합니다.
    • Periodic: 상태 점검 작업이 마지막으로 예약되고 계측된 시간과 같은 정보가 포함됩니다.

    다음은 성공적인 머신 검사에 대한 HealthCheck 샘플입니다.

    Name:         bm-system-192.0.2.54-machine
    Namespace:    cluster-test-user001
    Labels:       baremetal.cluster.gke.io/periodic-health-check=true
                  machine=192.0.2.54
                  type=machine
    Annotations:  <none>
    API Version:  baremetal.cluster.gke.io/v1
    Kind:         HealthCheck
    Metadata:
      Creation Timestamp:  2023-09-22T18:03:27Z
      ...
    Spec:
      Anthos Bare Metal Version:  1.16.0
      Cluster Name:               nuc-user001
      Interval In Seconds:        3600
      Node Addresses:
        192.168.1.54
      Type:  machine
    Status:
      Check Image Version:  1.16.0-gke.26
      Checks:
        192.168.1.54:
          Job UID:  345b74a6-ce8c-4300-a2ab-30769ea7f855
          Message:
          Pass:     true
      ...
      Cluster Spec:
        Anthos Bare Metal Version:  1.16.0
        Bypass Preflight Check:     false
        Cluster Network:
          Bundled Ingress:  true
          Pods:
            Cidr Blocks:
              10.0.0.0/16
          Services:
            Cidr Blocks:
              10.96.0.0/20
      ...
      Conditions:
        Last Transition Time:  2023-11-22T17:53:18Z
        Observed Generation:   1
        Reason:                LastPeriodicHealthCheckFinished
        Status:                False
        Type:                  Reconciling
      Node Pool Specs:
        node-pool-1:
          Cluster Name:  nuc-user001
        ...
      Pass:                  true
      Periodic:
        Last Schedule Time:                    2023-11-22T17:53:18Z
        Last Successful Instrumentation Time:  2023-11-22T17:53:18Z
      Start Time:                              2023-09-22T18:03:28Z
    Events:
      Type    Reason                  Age                  From                    Message
      ----    ------                  ----                 ----                    -------
      Normal  HealthCheckJobFinished  6m4s (x2 over 6m4s)  healthcheck-controller  health check job bm-system-192.0.2.54-machine-28344593 finished
    

    다음은 실패한 머신 검사에 대한 HealthCheck 샘플입니다.

    Name:         bm-system-192.0.2.57-machine
    Namespace:    cluster-user-cluster1
    ...
    API Version:  baremetal.cluster.gke.io/v1
    Kind:         HealthCheck
    ...
    Status:
      Checks:
        192.0.2.57:
          Job UID:  492af995-3bd5-4441-a950-f4272cb84c83
          Message:  following checks failed, ['check_kubelet_pass']
          Pass:     false
      Failures:
        Category:     AnsibleJobFailed
        Description:  Job: machine-health-check.
        Details:       Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn].
        Reason:       following checks failed, ['check_kubelet_pass']
      Pass:                  false
      Periodic:
        Last Schedule Time:                    2023-10-24T23:04:21Z
        Last Successful Instrumentation Time:  2023-10-24T23:31:30Z
      ...
    
  3. 측정항목의 상태 점검 목록을 가져오려면 다음 명령어를 사용합니다.

    kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system
    

    CLUSTER_KUBECONFIG를 대상 클러스터 kubeconfig 파일 경로로 바꿉니다.

    다음 샘플은 응답 형식을 보여줍니다.

    NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
    kube-system   bm-system-10.200.0.3-machine                                            Healthy   56m
    kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
    kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
    kube-system   bm-system-kubernetes                                                    Healthy   57m
    kube-system   bm-system-kubernetes-1.16.1-non-periodic                                Healthy   25d
    kube-system   bm-system-network                                                       Healthy   32m
    kube-system   check-kubernetes-20231114-190445-non-periodic                           Healthy   3h6m
    kube-system   component-status-controller-manager                                     Healthy   5s
    kube-system   component-status-etcd-0                                                 Healthy   5s
    kube-system   component-status-etcd-1                                                 Healthy   5s
    kube-system   component-status-scheduler                                              Healthy   5s
    

상태 점검 크론 작업

주기적인 상태 점검을 위해 각 베어메탈 HealthCheck 커스텀 리소스에는 동일한 이름의 해당하는 CronJob이 있습니다. 이 CronJob은 해당 상태 점검이 설정된 간격으로 실행되도록 예약합니다.

크론 작업에 대한 정보를 가져오려면 다음 안내를 따르세요.

  1. 특정 클러스터에 대해 실행된 크론 작업 목록을 가져옵니다.

    kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.

    다음 샘플은 일반적인 리소스를 보여줍니다.

    NAMESPACE           NAME                           SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    cluster-test-admin   bm-system-10.200.0.3-machine   17 */1 * * *   False     0        11m             25d
    cluster-test-admin   bm-system-add-ons              25 */1 * * *   False     0        3m16s           25d
    cluster-test-admin   bm-system-kubernetes           16 */1 * * *   False     0        12m             25d
    cluster-test-admin   bm-system-network              41 */1 * * *   False     0        47m             25d
    

    SCHEDULE 열의 값은 일정 구문에서 실행되는 각 상태 점검 작업의 일정을 나타냅니다. 예를 들어 bm-system-kubernetes 작업은 매일(* * *) 매시간(*/1) 17분(17)에 실행됩니다. 주기적인 상태 점검의 시간 간격은 수정할 수 없지만, 실행이 예정된 때를 알면 문제 해결에 유용합니다.

  2. 특정 CronJob 커스텀 리소스의 세부정보를 가져옵니다.

    kubectl describe cronjob CRONJOB_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.

    다음 샘플은 성공적인 CronJob을 보여줍니다.

    Name:                          bm-system-network
    Namespace:                     cluster-test-admin
    Labels:                        AnthosBareMetalVersion=1.16.1
                                  baremetal.cluster.gke.io/check-name=bm-system-network
                                  baremetal.cluster.gke.io/periodic-health-check=true
                                  controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613
                                  type=network
    Annotations:                   target: node-network
    Schedule:                      41 */1 * * *
    Concurrency Policy:            Forbid
    Suspend:                       False
    Successful Job History Limit:  1
    Failed Job History Limit:      1
    Starting Deadline Seconds:     <unset>
    Selector:                      <unset>
    Parallelism:                   <unset>
    Completions:                   1
    Active Deadline Seconds:       3600s
    Pod Template:
      Labels:           baremetal.cluster.gke.io/check-name=bm-system-network
      Annotations:      target: node-network
      Service Account:  ansible-runner
      Containers:
      ansible-runner:
        Image:      gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5
        Port:       <none>
        Host Port:  <none>
        Command:
          cluster
        Args:
          -execute-command=network-health-check
          -login-user=root
          -controlPlaneLBPort=443
        Environment:  <none>
        Mounts:
          /data/configs from inventory-config-volume (ro)
          /etc/ssh-key from ssh-key-volume (ro)
      Volumes:
      inventory-config-volume:
        Type:      ConfigMap (a volume populated by a ConfigMap)
        Name:      bm-system-network-inventory-bm-system-ne724a7cc3584de0635099
        Optional:  false
      ssh-key-volume:
        Type:            Secret (a volume populated by a Secret)
        SecretName:      ssh-key
        Optional:        false
    Last Schedule Time:  Tue, 14 Nov 2023 18:41:00 +0000
    Active Jobs:         <none>
    Events:
      Type    Reason            Age   From                Message
      ----    ------            ----  ----                -------
      Normal  SuccessfulCreate  48m   cronjob-controller  Created job bm-system-network-28333121
      Normal  SawCompletedJob   47m   cronjob-controller  Saw completed job: bm-system-network-28333121, status: Complete
      Normal  SuccessfulDelete  47m   cronjob-controller  Deleted job bm-system-network-28333061
    

상태 점검 로그

상태 점검이 실행되면 로그가 생성됩니다. 상태 점검이 bmctl로 실행되거나 주기적인 상태 점검의 일부로 자동으로 실행되는지 여부에 관계없이 로그가 Cloud Logging으로 전송됩니다. 주문형 상태 점검을 실행하면 관리자 워크스테이션에서 클러스터 폴더의 log/ 디렉터리에 있는 타임스탬프가 지정된 폴더에 로그 파일이 생성됩니다. 예를 들어 test-cluster라는 클러스터에 대해 bmctl check kubernetes 명령어를 실행하는 경우 bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923과 같은 디렉터리에서 로그를 찾습니다.

로컬에서 로그 보기

kubectl을 사용하면 주기적인 상태 점검의 로그를 볼 수 있습니다.

  1. 포드를 가져오고 관심 있는 특정 상태 점검 포드를 찾습니다.

    kubectl get pods --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.

    다음은 일부 상태 점검 포드를 보여주는 샘플 응답입니다.

    NAME                                                              READY   STATUS      RESTARTS   AGE
    bm-system-10.200.0.4-machine-28353626-lzx46                       0/1     Completed   0          12m
    bm-system-10.200.0.5-machine-28353611-8vjw2                       0/1     Completed   0          27m
    bm-system-add-ons-28353614-gxt8f                                  0/1     Completed   0          24m
    bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c   0/1     Completed   0          75m
    bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk   0/1     Completed   0          74m
    bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj   0/1     Completed   0          67m
    bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj   0/1     Completed   0          77m
    bm-system-kubernetes-28353604-4tc54                               0/1     Completed   0          34m
    bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn   0/1     Completed   0          63m
    bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z   0/1     Completed   0          77m
    ...
    bm-system-network-28353597-cbwk7                                  0/1     Completed   0          41m
    bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd   0/1     Completed   0          76m
    bm-system-network-preflight-check-create275a0fdda700cb2b44b264c   0/1     Completed   0          77m
    
  2. 포드 로그를 가져옵니다.

    kubectl logs POD_NAME  --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • POD_NAME: 상태 점검 포드의 이름입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
    • CLUSTER_NAMESPACE: 클러스터의 네임스페이스입니다.

    다음 샘플은 성공적인 노드 머신 상태 점검에 대한 포드 로그의 일부를 보여줍니다.

    ...
    TASK [Summarize health check] **************************************************
    Wednesday 29 November 2023  00:26:22 +0000 (0:00:00.419)       0:00:19.780 ****
    ok: [10.200.0.4] => {
        "results": {
            "check_cgroup_pass": "passed",
            "check_cni_pass": "passed",
            "check_containerd_pass": "passed",
            "check_cpu_pass": "passed",
            "check_default_route": "passed",
            "check_disks_pass": "passed",
            "check_dns_pass": "passed",
            "check_docker_pass": "passed",
            "check_gcr_pass": "passed",
            "check_googleapis_pass": "passed",
            "check_kernel_version_pass": "passed",
            "check_kubelet_pass": "passed",
            "check_memory_pass": "passed",
            "check_pod_cidr_intersect_pass": "passed",
            "check_registry_mirror_reachability_pass": "passed",
            "check_time_sync_pass": "passed",
            "check_ubuntu_1804_kernel_version": "passed",
            "check_ufw_pass": "passed",
            "check_vcpu_pass": "passed"
        }
    }
    ...
    

    다음 샘플은 실패한 노드 머신 상태 점검에 대한 포드 로그의 일부를 보여줍니다. 이 샘플은 kubelet 검사(check_kubelet_pass)가 실패했음을 나타내며, kubelet가 이 노드에서 실행되고 있지 않음을 나타냅니다.

    ...
    TASK [Reach a final verdict] ***************************************************
    Thursday 02 November 2023  17:30:19 +0000 (0:00:00.172)       0:00:17.218 *****
    fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"}
    ...
    

Cloud Logging에서 로그 보기

상태 점검 로그는 Cloud Logging으로 스트리밍되며 로그 탐색기에서 볼 수 있습니다. 주기적인 상태 점검은 콘솔 로그에서 포드로 분류됩니다.

  1. Google Cloud 콘솔의 Logging 메뉴에서 로그 탐색기 페이지로 이동합니다.

    로그 탐색기로 이동

  2. 쿼리 필드에 다음 기본 쿼리를 입력합니다.

    resource.type="k8s_container"
    resource.labels.pod_name=~"bm-system.*-machine.*"
    
  3. 쿼리 결과 창에 노드 머신 상태 점검의 로그가 표시됩니다.

다음은 주기적인 상태 점검에 대한 쿼리 목록입니다.

  • 노드 머신

    resource.type="k8s_container"
    resource.labels.pod_name=~"bm-system.*-machine.*"
    
  • 네트워크

    resource.type="k8s_container"
    resource.labels.pod_name=~"bm-system-network.*"
    
  • Kubernetes

    resource.type="k8s_container"
    resource.labels.pod_name=~"bm-system-kubernetes.*"
    
  • 부가기능

    resource.type="k8s_container"
    resource.labels.pod_name=~"bm-system-add-ons.*"
    

주기적인 상태 점검

기본적으로 주기적인 상태 점검은 매시간 실행되며 다음 클러스터 구성요소를 검사합니다.

관리자 클러스터에서 베어메탈 HealthCheck(healthchecks.baremetal.cluster.gke.io) 커스텀 리소스를 확인하여 클러스터 상태를 검사할 수 있습니다. 네트워크, Kubernetes, 부가기능 검사는 클러스터 수준 검사이므로 검사마다 리소스가 하나씩 있습니다. 머신 검사는 대상 클러스터의 각 노드에 대해 실행되므로 노드마다 리소스가 있습니다.

  • 지정된 클러스터의 베어메탈 HealthCheck 리소스를 나열하려면 다음 명령어를 실행합니다.

    kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
        --namespace=CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

    • CLUSTER_NAMESPACE: 상태 점검의 대상 클러스터의 네임스페이스입니다.

    다음 샘플 응답은 형식을 보여줍니다.

    NAMESPACE               NAME                               PASS    AGE
    cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
    cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
    cluster-test-user001    bm-system-add-ons                  true    56d
    cluster-test-user001    bm-system-kubernetes               true    56d
    cluster-test-user001    bm-system-network                  true    56d
    

    healthchecks.baremetal.cluster.gke.ioPass 필드는 마지막 상태 점검을 통과(true)했는지 아니면 실패(false)했는지 나타냅니다.

주기적인 상태 점검의 상태 확인에 대한 자세한 내용은 HealthCheck 커스텀 리소스상태 점검 로그를 참조하세요.

주기적인 상태 점검 사용 중지

주기적인 상태 점검은 모든 클러스터에서 기본적으로 사용 설정됩니다. 클러스터 리소스에서 periodicHealthCheck.enable 필드를 false로 설정하여 클러스터의 주기적인 상태 점검을 중지할 수 있습니다.

주기적인 상태 점검을 사용 중지하려면 다음 안내를 따르세요.

  1. 클러스터 구성 파일을 수정하고 periodicHealthCheck.enable 필드를 클러스터 사양에 추가하고 값을 false로 설정합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-user-basic
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: user-basic
      namespace: cluster-user-basic
    spec:
      type: user
      profile: default
      ...
      periodicHealthCheck:
        enable: false
      ...
    
  2. bmctl update 명령어를 실행하여 클러스터를 업데이트합니다.

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 업데이트하려는 클러스터의 이름입니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

  3. 주기적인 상태 점검이 사용 중지되었는지 확인하려면 다음 명령어를 실행하여 해당 healthchecks.baremetal.cluster.gke.io 리소스가 삭제되었는지 확인합니다.

    kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
        --namespace=CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

    • CLUSTER_NAMESPACE: 상태 점검의 대상 클러스터의 네임스페이스입니다.

주기적인 상태 점검 다시 사용 설정

주기적인 상태 점검은 모든 클러스터에서 기본적으로 사용 설정됩니다. 주기적인 상태 점검을 사용 중지한 경우 클러스터 리소스에서 periodicHealthCheck.enable 필드를 true로 설정하여 다시 사용 설정할 수 있습니다.

주기적인 상태 점검을 다시 사용 설정하려면 다음 안내를 따르세요.

  1. 클러스터 구성 파일을 수정하고 periodicHealthCheck.enable 필드를 클러스터 사양에 추가하고 값을 true로 설정합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: cluster-user-basic
    ---
    apiVersion: baremetal.cluster.gke.io/v1
    kind: Cluster
    metadata:
      name: user-basic
      namespace: cluster-user-basic
    spec:
      type: user
      profile: default
      ...
      periodicHealthCheck:
        enable: true
      ...
    
  2. bmctl update 명령어를 실행하여 클러스터를 업데이트합니다.

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 업데이트하려는 클러스터의 이름입니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

  3. 주기적인 상태 점검이 사용 설정되었는지 확인하려면 다음 명령어를 실행하여 해당 healthchecks.baremetal.cluster.gke.io 리소스가 있는지 확인합니다.

    kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
        --namespace=CLUSTER_NAMESPACE
    

    다음을 바꿉니다.

    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

    • CLUSTER_NAMESPACE: 상태 점검의 대상 클러스터의 네임스페이스입니다.

    리소스가 표시되는 데 몇 분 정도 걸릴 수 있습니다.

주문형 상태 점검

다음 섹션에서는 bmctl check로 주문형으로 실행할 수 있는 상태 점검을 설명합니다. bmctl check를 사용하여 상태 점검을 실행할 때는 다음 규칙이 적용됩니다.

  • bmctl check 명령어로 사용자 클러스터를 검사할 때 --kubeconfig 플래그로 관리자 클러스터에 대한 kubeconfig 파일의 경로를 지정합니다.

  • 로그는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 타임스탬프가 지정된 디렉터리(기본적으로 bmctl-workspace/CLUSTER_NAME/log)에 생성됩니다.

  • 상태 점검 로그는 Cloud Logging으로도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.

bmctl 명령어 옵션에 대한 자세한 내용은 bmctl 명령어 참조를 확인하세요.

부가기능

지정된 클러스터에 지정된 Kubernetes 부가기능이 작동하는지 검사합니다.

  • 클러스터의 부가기능을 검사하려면 다음 안내를 따르세요.

    bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 검사할 클러스터의 이름입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

검사 대상 목록은 이 문서의 검사 대상 섹션에서 부가기능을 참조하세요.

이 검사는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 check-addons-TIMESTAMP 디렉터리에 로그 파일을 생성합니다. 로그는 Cloud Logging으로도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.

클러스터

지정된 클러스터의 모든 클러스터 노드, 노드 네트워킹, Kubernetes, 부가기능을 검사합니다. 클러스터 이름을 제공하면 bmctl이 기본적으로 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml에서 클러스터 구성 파일을 찾습니다.

  • 클러스터 상태를 검사하려면 다음 안내를 따르세요.

    bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 검사할 클러스터의 이름입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

검사 대상 목록은 이 문서의 검사 대상 섹션에서 다음 섹션을 참조하세요.

이 검사는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 check-cluster-TIMESTAMP 디렉터리에 로그 파일을 생성합니다. 로그는 Cloud Logging으로도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.

구성

클러스터 구성 파일을 확인합니다. 이 검사에서는 구성 파일을 생성하여 클러스터의 클러스터 구성 세부정보를 지정하도록 수정했다고 가정합니다. 이 명령어의 목적은 구성 설정이 잘못되었거나 누락되거나 구문 오류가 있는지 확인하는 것입니다. 클러스터 이름을 제공하면 bmctl이 기본적으로 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml에서 클러스터 구성 파일을 찾습니다.

  • 클러스터 구성 파일을 검사하려면 다음 안내를 따르세요.

    bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 검사할 클러스터의 이름입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

이 명령어는 클러스터 구성 파일의 YAML 구문, Google Cloud 액세스, 클러스터 구성 파일에 지정된 서비스 계정의 권한을 검사합니다.

이 검사는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 check-config-TIMESTAMP 디렉터리에 로그 파일을 생성합니다. 로그는 Cloud Logging으로도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.

GCP

모든 클러스터 노드 머신이 Container Registry(gcr.io) 및 Google API 엔드포인트(googleapis.com)에 액세스할 수 있는지 검사합니다.

  • 필요한 Google Cloud 리소스에 대한 클러스터 액세스를 검사하려면 다음 안내를 따르세요.

    bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 검사할 클러스터의 이름입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

이 검사는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 check-gcp-TIMESTAMP 디렉터리에 로그 파일을 생성합니다. 로그는 Cloud Logging으로도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.

Kubernetes

제어 영역에서 실행되는 중요한 Kubernetes 연산자의 상태를 검사합니다. 이 검사는 중요한 연산자가 올바르게 작동하고 포드가 비정상 종료되지 않는지 확인합니다. 이 상태 점검은 제어 영역 구성요소가 누락된 경우 오류를 반환하지 않습니다. 구성요소가 존재하고 명령어 실행 시 오류가 있는 경우에만 오류를 반환합니다.

  • 클러스터의 Kubernetes 구성요소 상태를 검사하려면 다음 안내를 따르세요.

    bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 검사할 노드가 포함된 클러스터의 이름입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

검사 대상 목록은 이 문서의 검사 대상 섹션에서 Kubernetes를 참조하세요.

이 검사는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 check-kubernetes-TIMESTAMP 디렉터리에 로그 파일을 생성합니다. 로그는 Cloud Logging으로도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.

노드

클러스터 노드 머신을 검사하여 올바르게 구성되었고 클러스터 업그레이드 및 클러스터 작업을 위한 충분한 리소스와 연결이 있는지 확인합니다.

  • 클러스터의 노드 머신 상태를 검사하려면 다음 안내를 따르세요.

    bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
    

    다음을 바꿉니다.

    • CLUSTER_NAME: 검사할 노드가 포함된 클러스터의 이름입니다.
    • NODE_IP_ADDRESSES: 노드 머신의 쉼표로 구분된 IP 주소 목록입니다.
    • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

검사 대상 목록은 이 문서의 검사 대상 섹션에서 노드 머신 검사를 참조하세요.

이 검사는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 check-nodes-TIMESTAMP 디렉터리에 각 클러스터 노드 머신의 로그 파일을 생성합니다. 로그는 Cloud Logging으로도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.

프리플라이트

bmctl을 사용해 프리플라이트 검사를 실행하는 방법은 클러스터 생성에 대한 주문형 프리플라이트 검사 실행클러스터 업그레이드에 대한 주문형 프리플라이트 검사 실행을 참조하세요.

VM 런타임 프리플라이트 검사

Google Distributed Cloud의 VM 런타임 프리플라이트 검사에서는 Google Distributed Cloud의 VM 런타임과 VM을 사용하기 전에 노드 머신 기본 요건 집합을 검증합니다. Google Distributed Cloud의 VM 런타임 프리플라이트 검사가 실패하면 VM 생성이 차단됩니다. VMRuntime 커스텀 리소스에서 spec.enabledtrue로 설정되면 Google Distributed Cloud의 VM 런타임 프리플라이트 검사가 자동으로 실행됩니다.

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

자세한 내용은 Google Distributed Cloud의 VM 런타임 프리플라이트 검사를 참조하세요.

다음 단계