观察分层工作负载

Hierarchy Controller 可让您通过使用集群中的分层和抽象命名空间，更好地观测您的工作负载。为了实现此目的，Hierarchy Controller 将集群的树标签传播到 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. 安装 Hierarchy Controller.

  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

    大约一分钟后，层次结构控制器和分层可观测性将在您的集群上实现。

启用分层可观测性后，Hierarchy Controller 会安装变更准入 webhook，以将树标签添加到 Pod。如需验证此 Webhook 是否正常运行，请执行以下操作：

  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 产品中分层工作负载的可观测性。

按层次结构查询 Pod

包含标签选择器的任何 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 支持的标签格式略有不同。例如，如需搜索在 default 命名空间的后代中运行的任何工作负载，而不是搜索 Kubernetes 标签 default.tree.hnc.x-k8s.io/depth，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 控制台中，转到 BigQuery。

    转到 BigQuery

  3. 查找 gke_cluster_resource_consumption。

  4. 按照启用 GKE 集群用量计量的前提条件部分，启用 GKE 用量计量可视化。

  5. 打开 Looker 数据洞察，点击空白报告，然后选择 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 资源名称 单位 usage_amount
a CPU 秒 0.09
a1 CPU 秒 0.09
a2 CPU 秒 0
a memory byte-seconds 6,315,303,690,240
a1 memory byte-seconds 1,355,268,587,520
a2 memory 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 的示例输出：

资源名称 单位 usage_amount
CPU 秒 0.09
memory 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 的示例输出：

命名空间 资源名称 usage_amount
a2 memory 4,960,035,102,720
a1 memory 1,355,268,587,520
a2 CPU 0
a1 CPU 0.09

命名空间 a 本身不包含任何用量，因此它未列在此查询的结果中。

分层监控的限制

以下是分层监控方面的限制。

系统会忽略对层次结构的更改

Pod 树标签在创建后会添加到 Pod，并且在 Pod 开始运行后不会修改。这意味着，在启用分层监控之前启动的 Pod 不会收到 Pod 树标签。

此外，启动后更改了层次结构（例如，使用层次结构控制器更改命名空间的父级）的任何 Pod 都不会更新其标签。虽然修改层次结构的情况通常很少见，但如果出现这种情况并导致问题，请务必在修改层次结构后重启所有受影响的 Pod。

即使无法应用标签，系统仍会创建 Pod

分层监控不适用于在重要的系统命名空间（例如 kube-system 或 hnc-system）中运行的 Pod。但是，Webhook 配置本身无法排除这些命名空间。因此，如果层次结构控制器出现问题，则在所有命名空间中创建 Pod 的操作可能都会受到影响。

因此，如果层次结构控制器无法在两秒内处理 Pod，则 Webhook 会失败并允许在没有标签的情况下创建 Pod，而不是让集群范围的服务面临中断的风险。您可以通过 Kubernetes API 服务器来监控此类 webhook 失败情况，具体方法是查找 podlabel.hierarchycontroller.configmanagement.gke.io 变更准入 webhook 失败情况。

后续步骤