상태 점검은 기존 클러스터의 작업을 테스트하고 모니터링하는 방법입니다. 상태 점검은 주기적으로 자체적으로 실행됩니다. gkectl diagnose cluster을 사용하여 주문형으로 상태 점검을 실행할 수도 있습니다. 이 문서에서는 각각의 검사에 대해 알아보고 각 검사가 자동으로 실행되는 상황, 수동으로 검사를 실행하는 방법과 시기, 결과를 해석하는 방법을 설명합니다.
검사 대상
Google Distributed Cloud 상태 점검에는 다음과 같은 두 가지 카테고리가 있습니다.
노드 머신 검사
클러스터 전체 검사
다음 섹션에서는 각 카테고리의 검사 대상을 간략하게 설명합니다. 정기 상태 점검과 주문형 상태 점검 모두에 이러한 검사가 사용됩니다.
노드 머신 검사
이 섹션에서는 노드 머신의 상태 점검에서 평가되는 항목을 설명합니다. 이러한 검사는 노드 머신이 올바르게 구성되었는지 확인하고 클러스터 생성, 클러스터 업그레이드, 클러스터 작업에 충분한 리소스와 연결이 있는지 확인합니다.
이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 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 다음으로 구성됩니다.
Artifact Registry,
gcr.io에 연결할 수 있습니다. 클러스터가 레지스트리 미러를 사용하도록 구성된 경우 이 검사를 건너뜁니다.Google API에 연결할 수 있습니다.
머신 상태 점검은 다음으로 구성됩니다.
kubelet가 활성 상태이며 노드 머신에서 실행 중입니다.containerd가 활성 상태이며 노드 머신에서 실행 중입니다.컨테이너 네트워크 인터페이스(CNI) 상태 엔드포인트 상태가 정상입니다.
포드 CIDR이 노드 머신 IP 주소와 겹치지 않습니다.
클러스터 전체 검사
이 섹션에서는 클러스터의 상태 점검에서 평가되는 항목을 설명합니다.
기본 검사
주기적인 상태 점검의 일부로 자동으로 실행되는 기본 클러스터 검사는 클러스터 상태 점검의 일부로 주문형으로 실행할 수도 있습니다. 이러한 검사는 Kubernetes 클러스터 리소스가 올바르게 구성되고 제대로 작동하는지 확인합니다.
이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-default-* 리소스라는 베어메탈 HealthCheck 커스텀 리소스에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.
기본 클러스터 검사는 다음 리소스 유형 및 조건을 감사합니다.
DaemonSet
- 구성이 유효합니다.
- DaemonSet이 정상임
배포
- 구성이 유효합니다.
- 배포가 정상입니다.
노드 (다음은 모두 노드 조건입니다.)
- 노드 준비 상태
- kubelet 디스크 압력
- kubelet 메모리 압력
- kubelet 프로세스 ID (PID) 압력
- kubelet 재시작 빈도
- kubelet이 정상임
- 네트워크 가용성
- containerd 함수
- containerd 다시 시작 빈도
- Docker Overlay2 함수
- Docker 다시 시작 빈도
- 네트워크 기기 등록 취소 이벤트 빈도
- 커널 교착 상태
- KubeProxy가 정상적으로 작동함
- 읽기 전용 파일 시스템
포드
- 구성이 유효합니다.
- pod가 정상임
- 컨테이너가 정상입니다.
PodDisruptionBudget (PDB)
- 구성이 유효합니다.
- PDB 런타임 함수
- PDB가 포드와 일치함
- 여러 PDB에서 관리되지 않는 포드
리소스 요청
- 대상 노드의 포드에 CPU 및 메모리 요청이 설정됨
- 노드당 평균 리소스 요청이 추적된 한도 내에 있음
서비스
- 구성이 유효합니다.
- 서비스가 정상입니다.
StatefulSet
- 구성이 유효합니다.
- StatefulSet
네트워크 검사
다음 클라이언트 측 클러스터 노드 네트워크 검사가 주기적인 상태 점검의 일부로 자동으로 실행됩니다. 네트워크 검사는 주문형으로 실행할 수 없습니다. 이러한 검사는 클러스터 네임스페이스의 관리자 클러스터에서 실행되는 bm-system-network라는 베어메탈 HealthCheck 커스텀 리소스에 해당합니다. 상태 점검 리소스에 대한 자세한 내용은 HealthCheck 커스텀 리소스를 참조하세요.
클러스터가 번들 부하 분산을 사용하는 경우 부하 분산 노드 풀의 노드에 레이어 2 주소 결정 프로토콜(ARP) 연결이 있어야 합니다. ARP는 VIP 탐색에 필요합니다.
컨트롤 플레인 노드에는 GKE Identity Service에서 사용하도록 포트 8443 및 8444가 열려 있습니다.
컨트롤 플레인 노드에는
etcd-events인스턴스에서 사용하도록 포트 2382 및 2383이 열려 있습니다.
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
Google Distributed Cloud 관리형 리소스에는 수동 변경사항이 표시되지 않습니다(구성 드리프트).
필드 값이 업데이트되지 않음
선택적인 필드가 추가 또는 삭제되지 않음
리소스가 삭제되지 않음
상태 점검에서 구성 드리프트를 감지하면 bm-system-add-ons 베어메탈 HealthCheck 커스텀 리소스 Status.Pass 값이 false로 설정됩니다. Failures 섹션의 Description 필드에는 다음 정보를 비롯하여 변경된 모든 리소스에 대한 세부정보가 포함됩니다.
Version: 리소스의 API 버전Kind: 리소스의 객체 스키마(예:Deployment)Namespace: 리소스가 있는 네임스페이스Name: 리소스 이름Diff: 레코드의 리소스 매니페스트와 변경된 리소스의 매니페스트 간의 차이에 대한 문자열 형식의 비교
HealthCheck 커스텀 리소스
상태 점검이 실행되면 Google Distributed Cloud에서 HealthCheck 커스텀 리소스를 만듭니다. HealthCheck 커스텀 리소스는 영구적이며 상태 점검 활동과 결과에 대한 구조화된 기록을 제공합니다. HeathCheck 커스텀 리소스에는 두 가지 카테고리가 있습니다.
베어메탈
HealthCheck커스텀 리소스(API Version: baremetal.cluster.gke.io/v1): 이러한 리소스는 주기적인 상태 점검에 대한 세부정보를 제공합니다. 이러한 리소스는 클러스터 네임스페이스의 관리자 클러스터에 있습니다. 베어메탈HealthCheck리소스는 상태 점검 크론 작업 및 작업을 만듭니다. 이러한 리소스는 최신 결과로 지속적으로 업데이트됩니다.Anthos
HealthCheck커스텀 리소스(API Version: anthos.gke.io/v1): 이러한 리소스는 상태 점검 측정항목을 보고하는 데 사용됩니다. 이러한 리소스는 각 클러스터의kube-system네임스페이스에 있습니다. 이러한 리소스는 최선의 노력으로 업데이트됩니다. 일시적인 네트워크 오류와 같은 문제로 인해 업데이트가 실패하면 실패가 무시됩니다.
다음 표에는 HealthCheck 카테고리에 생성되는 리소스 유형이 나와 있습니다.
| 베어메탈 HealthChecks | Anthos HealthChecks | 심각도 |
|---|---|---|
|
유형: 기본값 이름: 이름: 이름: 이름: 이름: 이름: 이름: 이름: |
유형: 기본값 이름: 이름: 이름: 이름: 이름: 이름: 이름: 이름: |
심각 |
|
유형: 머신
이름: |
유형: 머신
이름: |
심각 |
|
유형: 네트워크
이름: |
유형: 네트워크
이름: |
심각 |
|
유형: 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-add-ons-add-ons Healthy 48m kube-system bm-system-add-ons-configdrift Healthy 48m kube-system bm-system-default-daemonset Healthy 52m kube-system bm-system-default-deployment Healthy 52m kube-system bm-system-default-node Healthy 52m kube-system bm-system-default-pod Healthy 52m kube-system bm-system-default-poddisruptionbudget Healthy 52m kube-system bm-system-default-resource Healthy 52m kube-system bm-system-default-service Healthy 52m kube-system bm-system-default-statefulset Healthy 57m kube-system bm-system-kubernetes Healthy 57m kube-system bm-system-network Healthy 32m 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은 해당 상태 점검이 설정된 간격으로 실행되도록 예약합니다. CronJob에는 노드에 시큐어 셸(SSH) 연결을 설정하여 상태 점검을 실행하는 ansible-runner 컨테이너도 포함되어 있습니다.
크론 작업에 대한 정보를 가져오려면 다음 안내를 따르세요.
특정 클러스터에 대해 실행된 크론 작업의 목록을 가져옵니다.
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
상태 점검 로그
상태 점검이 실행되면 로그가 생성됩니다. 상태 점검이gkectl diagnose cluster로 실행되거나 주기적인 상태 점검의 일부로 자동으로 실행되는지 여부에 관계없이 로그가 Cloud Logging으로 전송됩니다. 주문형으로 상태 점검을 실행하면 로그 파일이 /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log에 생성됩니다.
로컬에서 로그 보기
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 콘솔에서 로깅 메뉴의 로그 탐색기 페이지로 이동합니다.
쿼리 필드에 다음 기본 쿼리를 입력합니다.
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.*-machine.*"쿼리 결과 창에 노드 머신 상태 점검의 로그가 표시됩니다.
다음은 주기적인 상태 점검에 대한 쿼리 목록입니다.
기본값
resource.type="k8s_container" resource.labels.pod_name=~"bm-system.default-*"노드 머신
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 커스텀 리소스 및 상태 점검 로그를 참조하세요.
주문형 상태 점검
주문형으로 상태 점검을 실행하려면 gkectl diagnose cluster 명령어를 사용합니다. gkectl diagnose cluster를 사용하여 상태 점검을 실행할 때는 다음 규칙이 적용됩니다.
gkectl diagnose cluster명령어로 사용자 클러스터를 검사할 때--kubeconfig플래그로 관리자 클러스터의 kubeconfig 파일 경로를 지정합니다.로그는 관리자 워크스테이션의 클러스터 로그 폴더에 있는 타임스탬프가 지정된 디렉터리 (기본적으로
/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log)에 생성됩니다.상태 점검 로그는 Cloud Logging에도 전송됩니다. 로그에 대한 자세한 내용은 상태 점검 로그를 참조하세요.
구성 드리프트 감지
부가기능 상태 점검이 실행되면 Google Distributed Cloud에서 관리하는 리소스의 예기치 않은 변경사항을 확인합니다. 특히 이 검사는 이러한 리소스의 매니페스트를 평가하여 외부 항목에서 변경했는지 확인합니다. 이러한 확인을 통해 클러스터 상태에 해가 될 수 있는 의도치 않은 변경사항을 미리 경고할 수 있습니다. 또한 중요한 문제 해결 정보를 제공합니다.
확인되는 매니페스트
일부 예외를 제외하고 부가기능 상태 확인은 클러스터의 모든 Google Distributed Cloud 관리 리소스를 검토합니다. 이러한 리소스는 Google Distributed Cloud 소프트웨어에서 설치하고 관리합니다. 이러한 리소스는 수백 개가 있으며 대부분의 매니페스트에서 구성 변경이 있는지 확인합니다. 매니페스트는 다음을 포함하되 이에 국한되지 않는 모든 종류의 리소스에 적용됩니다.
|
|
|
확인되지 않는 매니페스트
설계상 일부 매니페스트는 검토 대상에서 제외됩니다. Google은 개인 정보 보호 및 보안상의 이유로 인증서, 보안 비밀, 서비스 계정과 같은 특정 유형의 리소스를 무시합니다. 또한 부가기능 검사는 일부 리소스와 리소스 필드를 무시합니다. 이러한 리소스와 필드는 변경될 것으로 예상되며 변경사항으로 인해 구성 드리프트 오류가 트리거되지 않도록 하기 위해서입니다. 예를 들어 자동 확장 도구가 이 값을 수정할 수 있으므로 확인은 배포의 replicas 필드를 무시합니다.
검토에서 추가 매니페스트 또는 매니페스트의 일부를 제외하는 방법
일반적으로 Google Distributed Cloud 관리 리소스를 변경하지 않거나 변경사항을 무시하는 것이 좋습니다.
하지만 고유한 케이스 요구사항을 해결하거나 문제를 해결하기 위해 리소스를 수정해야 하는 경우가 있습니다. 이러한 이유로 Fleet의 각 클러스터에 ignore-config-drift ConfigMap이 제공됩니다. 이러한 ConfigMap을 사용하여 평가에서 제외할 리소스와 특정 리소스 필드를 지정합니다.
Google Distributed Cloud는 각 클러스터에 ignore-config-drift ConfigMap을 만듭니다. 이러한 ConfigMap은 관리 (관리자 또는 하이브리드) 클러스터의 상응하는 클러스터 네임스페이스에 있습니다. 예를 들어 두 개의 사용자 클러스터 (user-one 및 user-two)를 관리하는 관리자 클러스터 (admin-one)가 있는 경우 cluster-user-one 네임스페이스의 admin-one 클러스터에서 user-one 클러스터의 ignore-config-drift ConfigMap을 찾을 수 있습니다.
리소스 또는 리소스 필드를 검토에서 제외하려면 다음 단계를 따르세요.
ignore-config-driftConfigMap에data.ignore-resources필드를 추가합니다.이 필드는 JSON 문자열 배열을 사용하며 각 문자열은 리소스와 선택적으로 리소스의 특정 필드를 지정합니다.
리소스와 선택적으로 무시할 특정 필드를 문자열 배열의 JSON 객체로 지정합니다.
리소스 및 필드의 JSON 객체는 다음과 같은 구조를 갖습니다.
{ "Version": "RESOURCE_VERSION", "Kind": "RESOURCE_KIND", "Namespace": "RESOURCE_NAMESPACE", "Name": "RESOURCE_NAME", "Fields": [ "FIELD_1_NAME", "FIELD_2_NAME", ... "FIELD_N_NAME" ] }다음을 바꿉니다.
RESOURCE_VERSION: (선택사항) 리소스의apiVersion값입니다.RESOURCE_KIND: (선택사항) 리소스의kind값입니다.RESOURCE_NAMESPACE: (선택사항) 리소스의metadata.namespace값입니다.RESOURCE_NAME: (선택사항) 리소스의metadata.name값입니다.FIELD_NAME: (선택사항) 무시할 리소스 필드 배열을 지정합니다. 필드를 지정하지 않으면 부가기능 검사에서 리소스의 모든 변경사항을 무시합니다.
JSON 객체의 각 필드는 선택사항이므로 다양한 순열이 허용됩니다. 리소스의 전체 카테고리를 제외하거나 매우 정확하게 특정 리소스에서 특정 필드를 제외할 수 있습니다.
예를 들어 관리 클러스터의
ais배포에서command섹션의 변경사항만 무시하도록 하려면 JSON이 다음과 같이 표시될 수 있습니다.{ "Version": "apps/v1", "Kind": "Deployment", "Namespace": "anthos-identity-service", "Name": "ais", "Fields": [ "command" ] }다음 예와 같이 이 JSON 객체를
config-drift-ignoreConfigMap의ignore-resources에 배열의 문자열 값으로 추가합니다.apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: "2024-09-24T00:39:45Z" name: config-drift-ignore namespace: cluster-example-admin ownerReferences: - apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster name: example-admin ... data: ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]' ...이 ConfigMap 설정 예시를 사용하면 구성 드리프트 오류를 트리거하지 않고도
ais배포에서command필드를 추가, 삭제 또는 수정할 수 있습니다. 그러나 배포의command섹션 외부 필드의 수정사항은 여전히 부가기능 검사에서 감지되어 구성 변경으로 보고됩니다.모든 배포를 제외하려면
ignore-resources값이 다음과 같을 수 있습니다.... data: ignore-resources: '[{"Kind":"Deployment"}]' ...ignore-resources는 JSON 문자열 배열을 허용하므로 여러 제외 패턴을 지정할 수 있습니다. 문제를 해결하거나 클러스터를 실험하는 중에 구성 드리프트 오류를 트리거하고 싶지 않은 경우, 매우 타겟팅된 리소스와 리소스 필드 또는 더 광범위한 리소스 카테고리를 모두 드리프트 감지에서 제외할 수 있는 이 유연성이 유용할 수 있습니다.