계층적 워크로드 관찰

계층 구조 컨트롤러는 클러스터에서 계층 및 추상 네임스페이스를 모두 사용하여 워크로드에 대한 향상된 관측 가능성을 제공합니다. 클러스터의 트리 라벨을 pod에 전파하여 다음을 포함한 Kubernetes 라벨을 수집할 수 있는 모든 시스템에서 사용할 수 있게 함으로써 이 작업을 수행할 수 있습니다.

예를 들어 네임스페이스 상속 예시 저장소의 네임스페이스에서 실행되는 워크로드를 가정해 보겠습니다. 네임스페이스 상속 예시 저장소의 아키텍처는 다음과 같습니다.

├── namespaces # Namespace directory
│   ├── eng # Namespace directory
│   │   ├── analytics # Abstract namespace directory
│   │   └── gamestore # Abstract namespace directory
│   ├── rnd # Namespace directory
│   │   ├── incubator-1 # Abstract namespace directory
│   │   └── incubator-2 # Abstract namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

계층 구조 컨트롤러를 사용하면 eng, rnd, 기타 추상 네임스페이스의 하위 요소인 모든 워크로드에서 생성된 pod, 로그, 사용량 측정을 선택할 수 있습니다. 여기에는 Git 저장소에 있는 네임스페이스의 워크로드(예: gamestore)뿐만 아니라 이러한 네임스페이스의 하위 요소를 만들 수 있는 모든 계층 구조 컨트롤러 하위 네임스페이스도 포함됩니다.

계층적 관측 가능성 사용 설정

계층적 관측 가능성은 계층적 컨트롤러에서 제공됩니다. 계층적 관측 가능성을 사용 설정하려면 다음 안내를 따르세요.

  1. 계층 구조 컨트롤러 설치

  2. ConfigManagement Operator 구성 파일의 spec.hierarchyController 객체에서 enablePodTreeLabels 값을 true로 설정합니다.

    # config-management.yaml

apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  hierarchyController:
    enabled: true
    # Set to true to enable hierarchical observability:
    enablePodTreeLabels: true
  # ...other fields...

  3. 구성을 적용합니다.

    kubectl apply -f config-management.yaml

    약 1분 후 클러스터에서 계층 구조 컨트롤러와 계층적 관측 가능성을 사용할 수 있습니다.

계층적 관측 가능성을 사용 설정하면 계층적 컨트롤러가 허용 웹훅 변형을 설치하여 pod에 트리 라벨을 추가합니다. 이 웹훅이 제대로 작동하는지 확인하려면 다음 안내를 따르세요.

  1. 다음과 같은 네임스페이스에서 워크로드를 시작합니다.

    kubectl run websvr --image=nginx --namespace default --generator=run-pod/v1

  2. pod를 검사하고 default.tree.hnc.x-k8s.io/depth 라벨이 포함되어 있는지 확인합니다.

    kubectl describe pod --namespace default websvr

    출력:

    Name:         websvr
Namespace:    default
# ...other fields...
Labels:       default.tree.hnc.x-k8s.io/depth=0 # This is the Pod tree label
              # ...other labels...
# ...other fields...

  3. 워크로드를 삭제합니다.

    kubectl delete pod --namespace default websvr

기존 pod는 pod 트리 라벨을 수신하지 않습니다. 이러한 라벨은 새 pod에만 추가됩니다. 자세한 내용은 이 문서의 뒷부분에 나오는 제한사항을 참조하세요.

계층적 워크로드 관측 가능성 사용

pod 트리 라벨이 사용 설정되면 클러스터 및 다른 Google Cloud 제품 모두에서 계층적 워크로드 관측 가능성을 개선하는 데 사용될 수 있습니다.

계층 구조별 포드 쿼리

라벨 선택기가 포함된 모든 Kubernetes 작업을 사용하여 pod 트리 라벨을 쿼리할 수 있습니다. 예를 들어 default 네임스페이스의 하위 요소에서 실행 중인 모든 네임스페이스의 모든 pod를 보려면 다음 쿼리를 사용합니다.

kubectl get pods --all-namespaces -l default.tree.hnc.x-k8s.io/depth

설치를 확인하기 위해 만든 샘플 워크로드를 기반으로 한 출력:

NAMESPACE   NAME     READY   STATUS    RESTARTS   AGE
default     websvr   1/1     Running   0          70s

계층 구조별 Cloud Logging 쿼리

Cloud Logging은 Kubernetes와 약간 다른 형식의 라벨을 지원합니다. 예를 들어 Kubernetes 라벨 default.tree.hnc.x-k8s.io/depth를 검색하는 대신 default 네임스페이스의 하위 요소에서 실행되는 모든 워크로드를 검색하기 위해 Cloud Logging은 Google Cloud Console에서 다음과 비슷한 쿼리를 예상합니다.

resource.type="k8s_container" labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=""

또는 Google Cloud CLI에서 비슷한 필터를 사용할 수 있습니다.

gcloud logging read "resource.type=k8s_container AND labels.k8s-pod/default_tree_hnc_x-k8s_io/depth!=''"

계층 구조별 GKE 사용량 측정 쿼리

pod 트리 라벨을 사용하여 GKE 사용량 측정에서 네임스페이스 트리로의 요청 및 사용량을 파악할 수 있습니다. 계층적 사용량 측정을 사용 설정하려면 다음 안내를 따르세요.

  1. 클러스터에서 일반 GKE 사용량 측정을 사용 설정합니다.

  2. 데이터가 BigQuery로 수집되고 있는지 확인합니다. Google Cloud Console에서 BigQuery로 이동합니다.

    BigQuery로 이동

  3. gke_cluster_resource_consumption를 찾습니다.

  4. GKE 클러스터 사용량 측정을 사용 설정하기 위한 기본 요건 섹션을 따라 GKE 사용량 측정을 시각화할 수 있습니다.

  5. Looker Studio를 열고 빈 보고서를 클릭한 다음 BigQuery를 데이터 소스로 선택합니다.

  6. 커스텀 쿼리를 선택하고 프로젝트 ID를 검색합니다. 오른쪽 텍스트 상자에 맞춤설정된 쿼리를 입력합니다. 커스텀 쿼리의 예시는 다음 섹션을 참조하세요.

예: 모든 하위 트리의 총 사용량

이 쿼리는 모든 하위 항목을 포함한 클러스터의 모든 일반, 추상, 계층별 네임스페이스의 사용량을 반환합니다.

SELECT
  REGEXP_EXTRACT(label.key, r"^[a-zA-Z0-9\-]+") as subtree,
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  regexp_contains(label.key, "tree.hnc.x-k8s.io/depth")
GROUP BY
  subtree,
  resource_name,
  usage.unit
ORDER BY
  resource_name ASC,
  subtree ASC

부분 샘플 출력:

subtree resource_name 단위 usage_amount
a CPU 초 0.09
a1 CPU 초 0.09
a2 CPU 초 0
a 메모리 byte-seconds 6,315,303,690,240
a1 메모리 byte-seconds 1,355,268,587,520
a2 메모리 byte-seconds 4,960,035,102,720

이 예시에서 네임스페이스 a에 표시된 사용량에는 하위 네임스페이스 a1 및 a2의 사용량도 함께 표시됩니다.

예: 단일 하위 트리 사용량

이 쿼리는 a 네임스페이스 및 모든 하위 네임스페이스의 총 사용량을 표시합니다.

SELECT
  resource_name,
  usage.unit,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  resource_name,
  usage.unit

네임스페이스 a의 샘플 출력:

resource_name 단위 usage_amount
CPU 초 0.09
메모리 byte-seconds 6,315,303,690,240

예: 하위 트리의 모든 네임스페이스 사용량

이 쿼리는 지정된 하위 트리에 있는 모든 네임스페이스의 개별 사용량을 표시합니다.

SELECT
  namespace,
  resource_name,
  SUM(usage.amount) AS usage_amount
FROM
  `PROJECT_NAME.DATASET_NAME.TABLE_NAME`,
  UNNEST(labels) AS label
WHERE
  label.key="SUBTREE_NAME.tree.hnc.x-k8s.io/depth"
GROUP BY
  namespace,
  resource_name

네임스페이스 a의 샘플 출력:

네임스페이스 resource_name usage_amount
a2 메모리 4,960,035,102,720
a1 메모리 1,355,268,587,520
a2 CPU 0
a1 CPU 0.09

네임스페이스 a 자체에는 사용량이 포함되지 않으므로 이 쿼리의 결과에 나열되지 않습니다.

계층적 모니터링 제한사항

계층적 모니터링의 제한사항은 다음과 같습니다.

계층 구조 변경사항이 무시됨

pod 트리 라벨은 생성될 때 pod에 추가되며 pod 실행이 시작된 후에는 수정되지 않습니다. 즉, 계층적 모니터링이 사용 설정되기 전에 시작된 pod에는 pod 트리 라벨이 수신되지 않습니다.

또한 계층 구조 컨트롤러를 사용하여 네임스페이스의 상위 요소를 변경할 때와 같이 pod가 시작된 후 계층 구조가 변경되는 모든 pod는 해당 라벨이 업데이트되지 않습니다. 계층 구조 수정은 일반적으로 매우 드물지만 이러한 상황이 발생하여 문제가 생기는 경우 계층 구조를 수정한 후에 영향을 받은 모든 Pod를 다시 시작해야 합니다.

라벨을 적용할 수 없더라도 pod가 계속 생성됨

계층적 모니터링은 kube-system 또는 hnc-system과 같은 주요 시스템 네임스페이스에서 실행되는 pod에는 적용되지 않습니다. 하지만 웹훅 구성 자체로는 이러한 네임스페이스를 제외할 방법이 없습니다. 따라서 계층 구조 컨트롤러에 문제가 발생하면 모든 네임스페이스의 pod 생성에 영향을 미칠 수 있습니다.

그 결과, 클러스터 전체의 중단 위험을 감수하지 않고 계층 구조 컨트롤러가 2초 내에 pod를 처리할 수 없으면 웹훅이 실패하며 라벨 없이 pod를 만들 수 있습니다. 이러한 웹훅 실패는 podlabel.hierarchycontroller.configmanagement.gke.io 허용 웹훅 변형의 실패를 찾아 Kubernetes API 서버를 통해 모니터링할 수 있습니다.

다음 단계