상태 점검은 기존 클러스터의 작업을 테스트하고 모니터링하는 방법입니다. 상태 점검은 주기적으로 자체적으로 실행됩니다. 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 탐색에 필요합니다.
제어 영역 노드에는 GKE Identity Service에서 사용할 수 있도록 포트 8443 및 8444가 열려 있습니다.
제어 영역 노드에는
etcd-events인스턴스에서 사용할 수 있도록 포트 2382 및 2383이 열려 있습니다.
베어메탈용 GKE 클러스터의 프로토콜 및 포트 사용량에 대한 자세한 내용은 네트워크 요구사항을 참조하세요.
프리플라이트 검사를 위한 네트워크 검사는 네트워크 상태 점검과 다릅니다. 프리플라이트 검사를 위한 네트워크 검사 목록은 클러스터 생성에 대한 프리플라이트 검사 또는 클러스터 업그레이드에 대한 프리플라이트 검사를 참조하세요.
Kubernetes
프리플라이트 검사 및 주기적인 상태 점검의 일부로 자동으로 실행되는 Kubernetes 검사는 주문형으로 실행할 수도 있습니다. 이러한 상태 점검은 나열된 제어 영역 구성요소가 누락된 경우 오류를 반환하지 않습니다. 구성요소가 존재하고 명령어 실행 시 오류가 있는 경우에만 검사에서 오류를 반환합니다.
이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-kubernetes 리소스라는 베어메탈 HealthCheck 커스텀 리소스에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.
API 서버가 작동하고 있습니다.
anetd연산자가 올바르게 구성되었습니다.모든 제어 영역 노드가 작동합니다.
다음 제어 영역 구성요소가 올바르게 작동합니다.
anthos-cluster-operatorcontroller-managercluster-api-provideraiscapi-kubeadm-bootstrap-systemcert-managerkube-dns
부가기능
부가기능 검사는 프리플라이트 검사 및 주기적인 상태 점검의 일부로 자동으로 실행되며 주문형으로 실행할 수도 있습니다. 나열된 부가기능 중 하나라도 누락된 경우 이 상태 점검은 오류를 반환하지 않습니다. 부가기능이 존재하고 명령어 실행 시 오류가 있는 경우에만 검사에서 오류를 반환합니다.
이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-add-ons* 리소스라는 베어메탈 HealthCheck 커스텀 리소스에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.
Cloud Logging Stackdriver 구성요소 및 Connect 에이전트가 작동합니다.
stackdriver-log-aggregatorstackdriver-log-forwarderstackdriver-metadata-agentstackdriver-prometheus-k8gke-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 상태 점검 | 심각도 |
|---|---|---|
|
유형: 머신
이름: |
유형: 머신
이름: |
심각 |
|
유형: 네트워크
이름: |
유형: 네트워크
이름: |
심각 |
|
유형: kubernetes
이름: |
유형: kubernetes
이름: |
심각 |
|
유형: 부가기능
이름: |
유형: 부가기능
이름:
이름: |
선택사항 |
HealthCheck 상태를 가져오려면 다음 안내를 따르세요.
주기적인 상태 점검의 결과를 읽으려면 연관된 커스텀 리소스를 가져오면 됩니다.
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig ADMIN_KUBECONFIG --all-namespacesADMIN_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특정 상태 점검의 세부정보를 읽으려면
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 ...측정항목의 상태 점검 목록을 가져오려면 다음 명령어를 사용합니다.
kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-systemCLUSTER_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은 해당 상태 점검이 설정된 간격으로 실행되도록 예약합니다.
크론 작업에 대한 정보를 가져오려면 다음 안내를 따르세요.
특정 클러스터에 대해 실행된 크론 작업 목록을 가져옵니다.
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 25dSCHEDULE열의 값은 일정 구문에서 실행되는 각 상태 점검 작업의 일정을 나타냅니다. 예를 들어bm-system-kubernetes작업은 매일(* * *) 매시간(*/1) 17분(17)에 실행됩니다. 주기적인 상태 점검의 시간 간격은 수정할 수 없지만, 실행이 예정된 때를 알면 문제 해결에 유용합니다.특정
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을 사용하면 주기적인 상태 점검의 로그를 볼 수 있습니다.
포드를 가져오고 관심 있는 특정 상태 점검 포드를 찾습니다.
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포드 로그를 가져옵니다.
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으로 스트리밍되며 로그 탐색기에서 볼 수 있습니다. 주기적인 상태 점검은 콘솔 로그에서 포드로 분류됩니다.
Google Cloud 콘솔의 Logging 메뉴에서 로그 탐색기 페이지로 이동합니다.
쿼리 필드에 다음 기본 쿼리를 입력합니다.
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"쿼리 결과 창에 노드 머신 상태 점검의 로그가 표시됩니다.
다음은 주기적인 상태 점검에 대한 쿼리 목록입니다.
노드 머신
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 56dhealthchecks.baremetal.cluster.gke.io의Pass필드는 마지막 상태 점검을 통과(true)했는지 아니면 실패(false)했는지 나타냅니다.
주기적인 상태 점검의 상태 확인에 대한 자세한 내용은 HealthCheck 커스텀 리소스 및 상태 점검 로그를 참조하세요.
주기적인 상태 점검 사용 중지
주기적인 상태 점검은 모든 클러스터에서 기본적으로 사용 설정됩니다. 클러스터 리소스에서 periodicHealthCheck.enable 필드를 false로 설정하여 클러스터의 주기적인 상태 점검을 중지할 수 있습니다.
주기적인 상태 점검을 사용 중지하려면 다음 안내를 따르세요.
클러스터 구성 파일을 수정하고
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 ...bmctl update명령어를 실행하여 클러스터를 업데이트합니다.bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG다음을 바꿉니다.
CLUSTER_NAME: 업데이트하려는 클러스터의 이름입니다.ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
주기적인 상태 점검이 사용 중지되었는지 확인하려면 다음 명령어를 실행하여 해당
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로 설정하여 다시 사용 설정할 수 있습니다.
주기적인 상태 점검을 다시 사용 설정하려면 다음 안내를 따르세요.
클러스터 구성 파일을 수정하고
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 ...bmctl update명령어를 실행하여 클러스터를 업데이트합니다.bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG다음을 바꿉니다.
CLUSTER_NAME: 업데이트하려는 클러스터의 이름입니다.ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.
주기적인 상태 점검이 사용 설정되었는지 확인하려면 다음 명령어를 실행하여 해당
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.enabled가 true로 설정되면 Google Distributed Cloud의 VM 런타임 프리플라이트 검사가 자동으로 실행됩니다.
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
name: vmruntime
spec:
enabled: true
...
자세한 내용은 Google Distributed Cloud의 VM 런타임 프리플라이트 검사를 참조하세요.