如何在Kubernetes准入Webhook中获取容器镜像详情？

针对你遇到的两个核心问题，分别给出具体方案：

一、通过Go客户端拉取镜像的CMD/ENTRYPOINT #

Kubernetes准入请求不会携带镜像的底层元数据，必须主动从镜像仓库拉取。推荐使用go-containerregistry库，它无需依赖Docker daemon，直接与镜像仓库交互，适合Webhook环境。

1. 依赖引入 #

import (
  "fmt"
  "strings"

  "github.com/google/go-containerregistry/pkg/authn"
  "github.com/google/go-containerregistry/pkg/name"
  "github.com/google/go-containerregistry/pkg/v1/remote"
)

2. 核心实现代码 #

以下函数可获取指定镜像的原始CMD和ENTRYPOINT：

func getImageCmdAndEntrypoint(imageRef string) ([]string, []string, error) {
  // 解析镜像引用（如nginx:1.25-alpine）
  ref, err := name.ParseReference(imageRef)
  if err != nil {
    return nil, nil, fmt.Errorf("解析镜像引用失败: %v", err)
  }

  // 处理私有仓库认证（公开镜像可跳过此步骤）
  auth, err := authn.DefaultKeychain.Resolve(ref.Context().Registry)
  if err != nil {
    return nil, nil, fmt.Errorf("获取认证信息失败: %v", err)
  }

  // 仅拉取镜像元数据，不会下载完整镜像层
  img, err := remote.Image(ref, remote.WithAuth(auth))
  if err != nil {
    return nil, nil, fmt.Errorf("拉取镜像失败: %v", err)
  }

  cfg, err := img.ConfigFile()
  if err != nil {
    return nil, nil, fmt.Errorf("获取镜像配置文件失败: %v", err)
  }

  // 返回原始CMD和ENTRYPOINT
  return cfg.Config.Cmd, cfg.Config.Entrypoint, nil
}

3. 动态构建JSONPatch #

拿到原始CMD/ENTRYPOINT后，可动态组合自定义命令。例如，在启动原应用前执行echo test：

// 从准入请求中提取容器镜像地址
image := request.Object.Spec.Containers[0].Image
cmd, entrypoint, err := getImageCmdAndEntrypoint(image)
if err != nil {
  // 处理错误逻辑，比如直接拒绝Pod创建或使用默认命令
}

// 组合原命令：遵循Docker的ENTRYPOINT+CMD逻辑
var originalCmd string
if len(entrypoint) > 0 {
  originalCmd = fmt.Sprintf("%s %s", strings.Join(entrypoint, " "), strings.Join(cmd, " "))
} else {
  originalCmd = strings.Join(cmd, " ")
}

// 构建新的命令
newCommand := []string{"sh", "-c", fmt.Sprintf("echo test ; %s", originalCmd)}

// 生成最终的JSONPatch
patch := []map[string]interface{}{
  {
    "op":    "add",
    "path":  "/spec/containers/0/command",
    "value": newCommand,
  },
}

二、Webhook配置能否获取更多信息 #

结论：Kubernetes准入请求不会额外传递镜像的CMD/ENTRYPOINT元数据，你的当前配置已经覆盖了Pod创建的场景，没有可调整的配置项来让K8s主动传递这类信息。

关于你的Webhook配置说明 #

你的webhook-configuration.yaml配置是合理的，几个关键点说明：

• sideEffects: None：符合MutatingWebhook的无副作用要求，无需修改
• rules：已正确匹配Pod的CREATE操作，覆盖所有API组和v1版本
• 准入请求仅包含Pod对象的核心字段（如spec.containers[*].image），镜像的底层配置不属于Pod API范畴，因此无法通过配置让K8s传递这些信息

注意事项 #

• 权限控制：Webhook所在Pod需要有访问目标镜像仓库的权限（私有仓库需挂载认证Secret或使用ServiceAccount密钥）
• 性能优化：建议对镜像的CMD/ENTRYPOINT做缓存，避免每次准入请求都拉取镜像仓库，减少延迟
• 标签稳定性：尽量使用固定版本标签的镜像（如nginx:1.25-alpine），避免浮动标签（如latest）导致缓存失效或获取到旧配置

内容的提问来源于stack exchange，提问作者Rodion Gorkovenko