是什么？

这是一个 Docker 容器，旨在在 Kubernetes 集群内运行，用于收集带有指定标签的 config map，并将包含的文件存储在本地文件夹中。它还可以在 configmap 更改后向指定 URL 发送 HTTP 请求。其主要目标是作为 sidecar 容器运行，为应用程序提供来自集群的信息。

为什么？

这是我们将 configmap 或 secret 中的文件提供给服务并在运行时保持其更新的简单方法。

如何使用？

在单个 pod 中使用共享卷运行此仓库创建的容器和您的应用程序。指定应监控的标签以及文件的存储位置。通过添加额外的环境变量，容器可以向指定 URL 发送 HTTP 请求。

镜像位置？

镜像可在以下位置获取：

• https://hub.docker.com/r/kiwigrid/k8s-sidecar
• quay.io/kiwigrid/k8s-sidecar
• https://github.com/orgs/kiwigrid/packages/container/package/k8s-sidecar

所有镜像均为相同的多架构镜像，支持 amd64、arm64 和 arm/v7。

不再支持 ppc64le 和 s390x

在 v2.x 版本中，我们已停止支持 ppc64le 和 s390x 架构。如果您仍需要这些架构，请联系我们。一种可能的解决方案是使用原生运行器而非 qemu 设置专门的构建任务。

健康端点

sidecar 在端口 8080（或由 HEALTH_PORT 配置）上提供 /healthz 健康端点，可用于 Kubernetes 就绪探针和存活探针。该端点兼容 IPv4 和 IPv6（双栈）。

就绪探针

仅当所有配置资源（ConfigMap 和/或 Secret）的初始同步完成后，端点才会返回 HTTP 200 OK。在此之前，它将返回 HTTP 503 Service Unavailable。这可确保主应用容器在其配置完全可用前不会启动或接收流量。

就绪探针配置示例：

readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 20
periodSeconds: 5

存活探针

该端点也可用作存活探针，检查以下两个条件：

1. Kubernetes API 连接：验证 sidecar 在过去 60 秒内已成功连接 Kubernetes API。
2. 监视线程：确保所有内部监视线程（用于 ConfigMap 和 Secret）正常运行。

如果任何检查失败，端点将返回 HTTP 503 Service Unavailable，指示 Kubernetes 重启容器。

存活探针配置示例：

livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 35
periodSeconds: 10

CI 和发布工作流

本仓库使用三个主要的 GitHub Actions 工作流：

1. 构建和测试（.github/workflows/build_and_test.yaml）

目的： 在本地 kind 集群上对 sidecar 进行端到端测试。

• 触发器：
  • pull_request
  • workflow_dispatch
• 功能：
  • 构建 sidecar 的本地 Docker 镜像（不推送到任何 registry）。
  • 构建虚拟服务器镜像。
  • 将两个镜像加载到 kind 集群中。
  • 针对多个 Kubernetes 版本（矩阵）运行综合测试套件。

此工作流不会创建标签、发布版本或将镜像推送到 registry。

2. 发布（.github/workflows/release.yaml）

目的： 构建和发布镜像并创建 GitHub 发布版本。

• 触发器：
  • 推送到 master 分支且修改了以下文件：
    • src/**
    • Dockerfile
• 版本控制与标签：
  • 使用 https://github.com/anothrNick/github-tag-action%E3%80%82
  • 默认情况下，每次符合条件的推送会更新补丁版本（例如 2.1.3 → 2.1.4）。
  • 可通过提交消息令牌覆盖版本更新行为：
    • #minor → 次要版本更新
    • #major → 主要版本更新
    • #none → 不更新版本，不构建，不发布
• 保护条件：
  • 所有构建/推送镜像或创建发布的步骤仅在标签操作报告真实更新时运行（part != '' && part != 'none'）。
• 创建新标签时的操作：
  • 为 sidecar 构建多架构镜像。
  • 将镜像推送到：
    • docker.io/kiwigrid/k8s-sidecar
    • quay.io/kiwigrid/k8s-sidecar
    • ghcr.io/kiwigrid/k8s-sidecar
  • 标签：<version> 和 latest。
  • 构建变更日志。
  • 为新标签创建 GitHub 发布版本。

这可确保：

• 仅 src/** 或 Dockerfile 中的代码变更会生成新镜像。
• 现有标签不会重新构建，保持不可变。
• 仅 CI 或仅文档的变更不会触发发布。

3. 发布工作流测试（.github/workflows/release_test.yaml）

目的： 手动测试发布工作流逻辑（标签、变更日志、镜像构建），不影响真实生产标签。

• 触发器：
  • workflow_dispatch（仅手动运行）。
• 标签行为：
  • 使用 github-tag-action，配置如下：
    • DEFAULT_BUMP: patch
    • DRY_RUN: true
  • 这意味着：
    • 始终模拟版本更新。
    • 不会向仓库推送真实标签。
• 保护条件：
  • 所有类发布步骤仅在标签操作报告真实更新时运行（part != '' && part != 'none'），与生产工作流一致。
• 功能：
  • 构建并推送标签为 <version>-testing 的测试镜像到 registry。
  • 构建变更日志。
  • 创建标签名为 <version>-testing 的草稿 GitHub 发布版本。

此工作流供维护者以安全方式验证发布流水线的变更（标签、变更日志生成、镜像构建），同时保持生产标签不可变。