mcpField
K
k8s-kaniko-job

k8s-kaniko-job

github.com/labring云与 DevOps83374 次安装4 周前更新
代码仓库

关于 k8s-kaniko-job

k8s-kaniko-job 是一项技能，可在没有 Docker 守护进程的 Kubernetes 命名空间中构建 linux/amd64 镜像。它打包构建上下文，通过 Kaniko Job 执行构建，并返回镜像摘要和引用。

主要功能

  1. 01在 Kubernetes 中使用 Kaniko 构建镜像
  2. 02通过 VersityGW S3 传递构建上下文
  3. 03依据运行时设置配置构建
  4. 04返回镜像摘要和镜像引用
  5. 05生成脱敏的 Job 清单

适用场景

  1. 01在没有 Docker 守护进程时构建镜像
  2. 02向 GHCR 发布带标签的镜像
  3. 03检查生成的 Job 结构

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/labring/sealos-skills --skill k8s-kaniko-job

安装后在 Claude Code 中输入/k8s-kaniko-job确认已加载。

附带文件scripts/kaniko-build.pyscripts/test_kaniko_build.py

详细介绍

K8s Kaniko Job

当不存在 Docker 守护进程时，在 Kubernetes 命名空间内构建 linux/amd64 镜像。一个脚本负责整个流程——不要自行编写 Job 或 Secret：

python3 scripts/kaniko-build.py --image ghcr.io/<owner>/<repo>:<tag> \
  [--context <dir>] [--dockerfile <path-relative-to-context>] \
  [--build-arg KEY=value ...]

根据此技能的目录解析 scripts/。从项目工作区运行脚本，以便它找到 .sealos/build-runtime.json。

工作原理

tar the context (excludes .git/.sealos/.versitygw-*)
  → DevBox-local VersityGW S3 store (POSIX dir, served on port 1319)
  → Kaniko Job in the current namespace pulls s3://... via the
    Job-reachable endpoint from .sealos/build-runtime.json
  → pushes the tagged image to ghcr.io with a build-only registry Secret
  → digest captured from the pod termination message

所有配置都会按顺序自动解析：CLI 标志 → .sealos/build-runtime.json（由控制平面写入：Job 可访问的 s3Endpoint、S3 secretKeyRef、构建期限）→ DevBox 运行时环境变量（KANIKO_CONTEXT_POSIX_DIR、S3_ENDPOINT、SEALOS_DEVBOX_JWT_SECRET 等）→ 默认值。Job 的 backoffLimit 为 0，活动期限上限为 1800s，ttlSecondsAfterFinished 为 3600，并使用当前 ServiceAccount。

前提条件

  • kubectl 已指向沙盒命名空间（注入的 kubeconfig；脚本不会选择区域、工作区或其他命名空间）。
  • 具有 write:packages 范围的 GITHUB_TOKEN。目标镜像所有者必须与令牌的登录名一致（转换为小写）：ghcr.io/<login>/<repo>:<tag>。使用提交 SHA 或时间戳作为标签，绝不要使用 latest。
  • 具有创建 Job/Secret 以及读取 Pod/日志权限的命名空间权限。
  • 构建上下文中有 Dockerfile（如果缺少，请先编写——规则见 ../use-sealos/references/build.md §1；该文件中的 buildx/registry 部分不适用于此处）。

查看结果

成功时，stdout 会输出包含 digest 和 image_ref 的 JSON（ghcr.io/<owner>/<repo>@sha256:...）。在部署清单中优先使用 image_ref——摘要固定可避免标签变更带来的影响。如果 digest 为 null（少见：终止消息丢失），则回退到 image 中的标签引用。

pull 会报告下游拉取行为：

  • anonymous — 软件包是公开的；不需要拉取 Secret。

  • private — GHCR 软件包默认是私有的。在命名空间中创建拉取 Secret，并在工作负载中引用它（imagePullSecrets: [{name: <app>-pull}]，固定字面值名称）：

    kubectl create secret docker-registry <app>-pull \
  --docker-server=ghcr.io --docker-username=<login> \
  --docker-password="$GITHUB_TOKEN" \
  --dry-run=client -o yaml | kubectl apply -f -

  • indeterminate — 监视第一个 Pod 的拉取情况进行验证；如果出现 ErrImagePull，则添加拉取 Secret。

故障排查

脚本失败时会报告 Job 和命名空间，但不会回显原始 Pod 日志或 Kubernetes 错误文本，因为其中可能包含凭据。直接检查指定的 Job 和 Pod，然后仅总结已脱敏的发现。

症状原因 → 解决方法
Job Pod 在拉取执行器镜像时出现 ImagePullBackOff集群无法拉取 gcr.io/kaniko-project/executor → 报告此问题；没有本地回退方案
Kaniko 日志：error uploading context / S3 连接被拒绝Job 无法连接 VersityGW 端点 → 检查 .sealos/build-runtime.json.s3Endpoint；绝不要将 Job 指向 127.0.0.1
Kaniko 日志：推送时出现 401/403令牌范围或所有者不匹配 → 脚本会在创建 Job 前验证两者；私下检查令牌和镜像所有者
Dockerfile 构建错误在工作区修复 Dockerfile 并重新运行；每次运行都会创建新的 Job
Job 超过期限构建耗时过长 → 精简上下文（.dockerignore），使用更小的基础镜像

仅用于构建的 Secret（use-sealos-ghcr-auth-*）是命名空间本地资源，且没有 TTL；Job 本身会在一小时后被垃圾回收。除非用户提出要求，否则将清理工作留给沙盒拆除流程。

绝不要打印 GITHUB_TOKEN、S3 凭据或 Secret 载荷。绝不要通过 --build-arg 传递 Secret——构建参数在 Job 规格中可见。--render-only 会打印经过脱敏的模拟 Job 清单供结构检查；它不会泄露运行时契约或构建参数中的值。

评论

支持 Markdown