本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes v1.26:Kubelet 凭据提供程序的 GA 支持

Kubernetes v1.26 引入了对 Kubelet 凭证提供程序插件的正式发布(GA)支持,提供了一个可扩展的插件框架,用于为任何容器镜像仓库动态获取凭证。

背景

Kubernetes 支持为容器仓库服务动态获取凭证。在 Kubernetes v1.20 之前,此功能被编译到 kubelet 中,并且仅适用于 Amazon Elastic Container Registry、Azure Container Registry 和 Google Cloud Container Registry。

Figure 1: Kubelet built-in credential provider support for Amazon Elastic Container Registry, Azure Container Registry, and Google Cloud Container Registry.

图 1:Kubelet 对 Amazon Elastic Container Registry、Azure Container Registry 和 Google Cloud Container Registry 的内置凭证提供程序支持。

Kubernetes v1.20 引入了对 kubelet 凭证提供程序插件的 Alpha 支持,它为 kubelet 提供了一种机制,可以为任意容器仓库动态进行身份验证和拉取镜像——无论是公共仓库、托管服务,甚至是自托管的仓库。在 Kubernetes v1.26 中,此功能现已正式发布。

Figure 2: Kubelet credential provider overview

图 2:Kubelet 凭证提供程序概述

为什么它很重要?

在 Kubernetes v1.20 之前,如果你想为除 ACR(Azure 容器仓库)、ECR(弹性容器仓库)或 GCR(Google 容器仓库)之外的镜像仓库动态获取凭证,你需要修改 kubelet 代码。新的插件机制可以在任何集群中使用,并让你在无需对 Kubernetes 本身进行任何更改的情况下对新仓库进行身份验证。任何云提供商或供应商都可以发布一个插件,让你通过其镜像仓库进行身份验证。

工作原理

kubelet 和 exec 插件二进制文件通过 stdio(标准输入、标准输出和标准错误)进行通信,发送和接收 json 序列化的、带 API 版本的类型。如果启用了 exec 插件,并且 kubelet 需要为与插件匹配的镜像获取身份验证信息,kubelet 将执行插件二进制文件,通过标准输入传递 CredentialProviderRequest API。然后,exec 插件与容器仓库通信以动态获取凭证,并通过标准输出将凭证以 CredentialProviderResponse API 的编码响应形式返回给 kubelet。

Figure 3: Kubelet credential provider plugin flow

图 3:Kubelet 凭证提供程序插件流程

在从 kubelet 接收凭证后,插件还可以指示凭证可以被缓存多长时间,以防止 kubelet 对同一仓库的后续镜像拉取请求不必要地执行插件。在插件未指定缓存持续时间的情况下,可以由 kubelet 指定默认缓存持续时间(更多细节如下)。

{
  "apiVersion": "kubelet.k8s.io/v1",
  "kind": "CredentialProviderResponse",
  "auth": {
    "cacheDuration": "6h",
    "private-registry.io/my-app": {
      "username": "exampleuser",
      "password": "token12345"
    }
  }
}

此外,插件可以指定缓存凭证的有效范围。这是通过 CredentialProviderResponse 中的 cacheKeyType 字段指定的。当值为 Image 时,kubelet 仅将缓存的凭证用于与第一个请求的镜像完全匹配的未来镜像拉取。当值为 Registry 时,kubelet 将为所有后续发往同一仓库主机但使用不同路径的镜像拉取使用缓存的凭证(例如,gcr.io/foo/bargcr.io/bar/foo 指的是来自同一仓库的不同镜像)。最后,当值为 Global 时,kubelet 将为所有与插件匹配的镜像使用返回的凭证,包括可以映射到不同仓库主机的镜像(例如,gcr.io vs registry.k8s.io(以前是 k8s.gcr.io))。插件实现必须提供 cacheKeyType 字段。

{
  "apiVersion": "kubelet.k8s.io/v1",
  "kind": "CredentialProviderResponse",
  "auth": {
    "cacheKeyType": "Registry",
    "private-registry.io/my-app": {
      "username": "exampleuser",
      "password": "token12345"
    }
  }
}

使用 kubelet 凭证提供程序

你可以通过在每个节点上将 exec 插件安装到 kubelet 可访问的本地目录中来配置凭证提供程序。然后你为 kubelet 设置两个命令行参数:

  • --image-credential-provider-config:凭证提供程序插件配置文件的路径。
  • --image-credential-provider-bin-dir:凭证提供程序插件二进制文件所在目录的路径。

kubelet 读取传入 --image-credential-provider-config 的配置文件,以确定应为 Pod 使用的容器镜像调用哪个 exec 插件。请注意,每个 *provider* 的名称必须与 --image-credential-provider-bin-dir 指定的本地目录中的二进制文件名称匹配,否则 kubelet 无法定位要调用的插件的路径。

kind: CredentialProviderConfig
apiVersion: kubelet.config.k8s.io/v1
providers:
- name: auth-provider-gcp
  apiVersion: credentialprovider.kubelet.k8s.io/v1
  matchImages:
  - "container.cloud.google.com"
  - "gcr.io"
  - "*.gcr.io"
  - "*.pkg.dev"
  args:
  - get-credentials
  - --v=3
  defaultCacheDuration: 1m

以下是 Kubernetes 项目如何使用 kubelet 凭证提供程序进行端到端测试的概述。

Figure 4: Kubelet credential provider configuration used for Kubernetes e2e testing

图 4:用于 Kubernetes e2e 测试的 Kubelet 凭证提供程序配置

有关更多配置详细信息,请参阅 Kubelet 凭证提供程序

参与其中

如果你想报告 Kubelet 凭证提供程序的错误或有功能请求,请加入 SIG Node。你可以通过以下方式联系我们: