确保使用网络钩子时控制平面的稳定性


准入网络钩子或 Kubernetes 中的网络钩子是准入控制器的一种,可在 Kubernetes 集群中使用它来在请求持久化之前验证或改变对控制平面的请求。第三方应用通常使用在系统关键资源和命名空间上运行的网络钩子。错误配置的网络钩子可能会影响控制平面性能和可靠性。例如,第三方应用创建的错误配置的网络钩子可能会阻止 GKE 在代管式 kube-system 命名空间中创建和修改资源,这可能会降低集群的功能。

Google Kubernetes Engine (GKE) 会监控集群,并使用 Recommender 服务来提供有关如何优化平台使用的指导。为了帮助您确保集群保持稳定和高性能,请参阅 GKE 针对以下场景的建议:

  • 运行但没有端点的网络钩子。
  • 在对系统关键资源和命名空间进行操作时被视为不安全的网络钩子。

通过本指南,您可以查看有关如何检查可能配置错误的网络钩子的说明并在必要时进行更新。

如需详细了解如何管理分析洞见和 Recommender 建议,请参阅利用分析洞见和建议优化 GKE 使用

识别可能会影响集群的错误配置网络钩子

如需获得可能会影响集群性能和稳定性的网络钩子的数据分析,请按照说明查看数据分析和建议。您可以通过以下方式获取数据分析:

  • 使用 Google Cloud 控制台。
  • 使用 Google Cloud CLI 或 Recommender API 并使用 K8S_ADMISSION_WEBHOOK_UNSAFEK8S_ADMISSION_WEBHOOK_UNAVAILABLE 子类型进行过滤。

通过数据分析确定网络钩子后,请按照说明排查检测到的网络钩子问题

GKE 检测到错误配置的网络钩子时

如果集群满足以下任一条件,GKE 会生成数据分析和建议:

排查检测到的网络钩子的问题

以下部分指导您对 GKE 检测到可能配置错误的 Webhook 进行问题排查。

实现说明并且正确配置网络钩子后,建议将在 24 小时内解决,并且不再显示在控制台中。如果自您实施建议后不到 24 小时,您可以将建议标记为已解决。如果您不想实施此建议,则可以忽略

网络钩子报告没有可用的端点

如果网络钩子报告其没有可用端点,则表示正在支持该网络钩子端点的 Service 具有一个或多个未运行的 Pod。如需使网络钩子端点可用,请按照说明查找支持此网络钩子端点的服务的 Pod 并排查问题:

  1. 查看数据分析和建议,一次选择一个数据分析进行问题排查。GKE 为每个集群生成一个见解,该见解列出了一个或多个具有必须调查的损坏端点的网络钩子。对于每个网络钩子,洞察力还说明服务名称、损坏的端点以及上次调用端点的时间。

  2. 查找与网络钩子关联的 Service 的服务 Pod:

    控制台

    在数据分析的边栏面板中,查看错误配置的网络钩子表。点击 Service 的名称。

    kubectl

    运行以下命令以描述 Service:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
    

    SERVICE_NAMESERVICE_NAMESPACE 分别替换为服务的名称和命名空间。

    如果您找不到网络钩子中列出的 Service 名称,则端点不可用可能是由于配置中列出的名称和 Service 的实际名称不匹配。如需修复端点可用性,请更新网络钩子配置中的服务名称以匹配正确的服务对象。

  3. 检查此 Service 的服务 Pod:

    控制台

    Service 详情服务 Pod 下,查看支持此 Service 的 Pod 列表。

    kubectl

    通过列出 Deployment 或 Pod 来识别哪些 Pod 未运行:

    kubectl get deployment -n SERVICE_NAMESPACE
    

    或者,运行以下命令:

    kubectl get pods -n SERVICE_NAMESPACE -o wide
    

    对于任何未运行的 Pod,请检查 Pod 日志以查看 Pod 未运行的原因。如需了解 Pod 的常见问题,请参阅已部署工作负载的问题排查

被视为不安全的网络钩子

如果网络钩子拦截系统管理的命名空间中的任何资源或某些类型的资源,GKE 会认为这种情况不安全,并建议您更新网络钩子以避免拦截这些资源。

  1. 按照说明查看数据分析和建议,一次选择一个数据分析进行问题排查。GKE 仅为每个集群生成一个数据分析,并且此数据分析列出了一个或多个网络钩子配置,每个配置列出一个或多个网络钩子。对于列出的每个网络钩子配置,数据分析会说明配置被标记的原因。
  2. 检查网络钩子配置:

    控制台

    在数据分析的边栏面板中,请查看该表。每一行中都是网络钩子配置的名称,以及此配置被标记的原因。

    如需检查每项配置,请点击名称以在 GKE 对象浏览器信息中心内导航到此配置。

    kubectl

    运行以下 kubectl 命令以获取网络钩子配置,并将 CONFIGURATION_NAME 替换为网络钩子配置的名称:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
    

    如果此命令未返回任何内容,请再次运行该命令,将 validatingwebhookconfigurations 替换为 mutatingwebhookconfigurations

    webhooks 部分中列出了一个或多个网络钩子。

  3. 根据网络钩子标记的原因,修改配置:

    排除 kube-system 和 kube-node-lease 命名空间

    如果 scope*,则会标记网络钩子。或者,如果范围是 Namespaced 且满足以下任一条件,则系统会标记网络钩子:

    • operator 条件为 NotInvalues 省略了 kube-systemkube-node-lease,如以下示例所示:

      webhooks:
      - admissionReviewVersions:
        ...
        namespaceSelector:
          matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: NotIn
            values:
            - blue-system
        objectSelector: {}
        rules:
        - apiGroups:
          ...
          scope: '*'
        sideEffects: None
        timeoutSeconds: 3
      

      确保将 scope 设置为 Namespaced 而不是 *,这样网络钩子只能在特定命名空间中运行。此外,请确保如果 operatorNotIn,则在 values 中添加 kube-systemkube-node-lease(在此示例中,使用 blue-system)。

    • operator 条件为 Invalues 包含 kube-systemkube-node-lease,如以下示例所示:

      namespaceSelector:
          matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: In
            values:
            - blue-system
            - kube-system
            - kube-node-lease
      

      确保将 scope 设置为 Namespaced 而不是 *,这样网络钩子只能在特定命名空间中运行。确保如果 operatorIn,则 values 中不包含 kube-systemkube-node-lease。在此示例中,由于 operatorIn,因此 values 中应仅包含 blue-system

    排除匹配的资源

    如果资源下列出了 nodestokenreviewssubjectaccessreviewscertificatesigningrequests,则也会标记网络钩子,如以下示例所示:

    - admissionReviewVersions:
    ...
      resources:
      - 'pods'
      - 'nodes'
      - 'tokenreviews'
      - 'subjectacessreviews'
      - 'certificatesigningrequests'
      scope: '*'
    sideEffects: None
    timeoutSeconds: 3
    

    从资源部分中移除 nodestokenreviewssubjectaccessreviewscertificatesigningrequests。 您可以在 resources 中保留 pods

后续步骤