d3fk/kubectl

基于scratch的轻量级kubectl容器 (Angatar> d3fk/kubectl)

一款超轻量级容器，仅包含Kubectl官方二进制文件和默认非root用户，大小约44MB（压缩后）。该镜像基于scratch构建（通过Alpine镜像从googleapis下载二进制文件，直接复制到scratch），自v1.25起在Docker Hub以“自动化构建”方式构建为多架构镜像，每日更新最新版本。此容器非常适合从任何环境（如简单Docker容器或其他K8s Pod、Job、CronJob等）管理Kubernetes集群。

可用于CI/CD流程，或直接作为主要的Kubectl命令行工具（可通过更改标签指定版本）。

对于Flatcar Container Linux等精简/不可变Linux发行版，此容器尤为便捷，可利用Docker镜像的不可变性，无需依赖包管理器...详见提示：快速设置

获取镜像 (d3fk/kubectl)

获取d3fk/kubectl镜像的最佳方式是从Docker Hub Registry拉取预构建镜像。

该镜像通过Docker Hub的“自动化构建”功能从https://github.com/Angatar/kubectl%E6%9E%84%E5%BB%BA%E4%B8%BA%E5%A4%9A%E6%9E%B6%E6%9E%84%E9%95%9C%E5%83%8F%E3%80%82

镜像名称 d3fk/kubectl

sh
$ docker pull d3fk/kubectl:latest

Docker Hub仓库：https://hub.docker.com/r/d3fk/kubectl/

d3fk/kubectl的Kubectl版本为最新稳定版

Docker Hub上的d3fk/kubectl:latest多架构镜像通过每日自动化构建更新，确保使用该镜像时能获取到发布后24小时内的最新稳定版Kubectl。最新稳定版对应Kubernetes的最新发布版本，可通过此处查看。

作为多架构镜像，它支持大多数架构：

• linux/amd64
• linux/386
• linux/arm/v6
• linux/arm/v7
• linux/arm64/v8
• linux/ppc64le
• linux/s390x

因此，甚至可在树莓派上使用此容器管理K8s集群。

历史Kubectl版本

若需使用历史版本或固定版本的Kubectl，Docker Hub也提供以下标签镜像（自d3fk/kubectl:v1.25起为多架构镜像）。这些镜像版本固定，不会更改，通过代码仓库“releases”部分的代码由Docker Hub自动化构建，且稳定不再重建：

• 版本1.30.4：d3fk/kubectl:v1.30
• 版本1.29.5：d3fk/kubectl:v1.29
• 版本1.28.10：d3fk/kubectl:v1.28
• 版本1.27.5：d3fk/kubectl:v1.27
• 版本1.26.8：d3fk/kubectl:v1.26
• 版本1.25.5：d3fk/kubectl:v1.25
• 版本1.24.8：d3fk/kubectl:v1.24
• 版本1.23.6：d3fk/kubectl:v1.23
• 版本1.22.6：d3fk/kubectl:v1.22
• 版本1.21.4：d3fk/kubectl:v1.21
• 版本1.20.8：d3fk/kubectl:v1.20
• 版本1.19.5：d3fk/kubectl:v1.19
• 版本1.18.2：d3fk/kubectl:v1.18
• 版本1.17.5：d3fk/kubectl:v1.17
• 版本1.16.9：d3fk/kubectl:v1.16

基本使用

sh
$ docker run --rm d3fk/kubectl

此命令将显示所有可用的kubectl命令列表

默认用户

从v1.31版本开始，d3fk/kubectl容器镜像包含默认非root用户kubectl，UID为6009，以遵循Docker最佳实践。选择此UID是为了减少与本地文件系统现有用户的冲突（如访问配置文件、挂载卷等）。

若使用v1.31以下版本，此非root用户设置通常不会影响常规使用，除非处理具有特定读取权限限制的文件或目录。如遇此类情况，可通过--user选项将容器用户设置为自己的UID，以模拟本地运行kubectl的行为。

配置

要连接远程集群，需加载自定义配置。

sh
$ docker run --rm --name kubectl -v /path/to/your/kube/config:/.kube/config d3fk/kubectl

例如，列出集群中的Pod：

sh
$ docker run --rm --name kubectl -v $HOME/.kube/config:/.kube/config d3fk/kubectl get pods

若需使用YAML文件、创建ConfigMap或处理其他文件，d3fk/kubectl容器中已设置工作目录/files。可将文件挂载到此路径并在容器内使用。

例如，从当前目录的deployment.yaml创建部署：

sh
$ docker run --rm --name kubectl \
             -v $(pwd):/files \
             -v $HOME/.kube/config:/.kube/config \
             d3fk/kubectl create -f deployment.yaml

若需与K8s组件进行终端交互，需在docker run命令中添加-ti选项。

例如，进入Pod内的容器shell进行调试或检查：

sh
$ docker run -ti --rm --name kubectl \
             -v $(pwd):/files \
             -v $HOME/.kube/config:/.kube/config \
             d3fk/kubectl exec -ti deployment/examplebashpod -- bash

提示：

处理有限访问权限

若操作具有访问权限限制的文件或目录，可使用--user选项将当前用户设为容器默认用户。

可通过$(id -u)和$(id -g)动态将当前用户的UID和GID纳入运行命令：

例如：

sh
$ docker run -ti --rm --name kubectl \
             --user $(id -u):$(id -g) \
             -v $(pwd):/files \
             -v $HOME/.kube/config:/.kube/config \
             d3fk/kubectl apply -f deployment.yaml

快速设置

为shell创建命令别名，可将此Docker容器当作系统$PATH中的kubectl二进制文件使用。

若$HOME/.kube/config文件对当前用户可访问，可在终端中复制粘贴以下命令进行快速本地设置：

sh
alias k='docker run --rm -ti --user $(id -u):$(id -g) -v $(pwd):/files -v $HOME/.kube/config:/.kube/config d3fk/kubectl'

之后即可像以下方式简单运行d3fk/kubectl命令：

sh
$ k get pods

由于别名仅在当前终端会话中生效，若需在未来会话中使用，需将别名添加到shell启动脚本（如.bashrc、.shrc、.rc等）。

在Kubernetes中使用

此容器最初用于K8s CronJob，以定期触发特定部署的强制滚动更新，使相关伸缩应用通过定期重启Pod获得新容器，提升稳定性且无 downtime。

为便于说明和测试，模板YAML文件位于代码仓库的https://github.com/Angatar/kubectl/blob/master/k8s/%E3%80%82

可通过补丁更新目标部署或使用kubectl rollout restart触发Pod滚动更新，需定义滚动更新策略以确保触发预期行为，例如：

yaml
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1 # 每次可添加的Pod数量
      maxUnavailable: 1 # 滚动更新期间不可用的Pod数量

完整的模板部署文件见k8s目录：https://github.com/Angatar/kubectl/blob/master/k8s/test-deployment.yaml

默认K8s RBAC规则不允许从其他Pod执行补丁或rollout操作。因此需创建具有所需权限（如“get”和“patch”）的RBAC Role和RoleBinding。

为便于测试，我们在专用命名空间“r-updated”中操作，确保不影响默认命名空间，且仅应用于需定期滚动更新的目标部署（CronJob、目标部署及专用RBAC规则需在同一命名空间）。若使用现有命名空间，需编辑部署、RBAC、ConfigMap和CronJob模板中的命名空间行；否则，创建“r-updated”命名空间：

sh
$ kubectl create namespace r-updated

k8s目录中提供了包含所需RBAC Role和RoleBinding的模板YAML文件：https://github.com/Angatar/kubectl/blob/master/k8s/rbac-rupdate.yaml%EF%BC%8C%E8%AF%B7%E6%A0%B9%E6%8D%AE%E9%9C%80%E6%B1%82%E8%B0%83%E6%95%B4%E6%9D%83%E9%99%90%E5%92%8C%E5%91%BD%E5%90%8D%E7%A9%BA%E9%97%B4%E3%80%82

sh
$ kubectl create -f rbac-rupdate.yaml

可通过以下命令从.kube/config文件创建供Pod/Job/CronJob使用的ConfigMap（假设配置文件位于$HOME/.kube）：

sh
$ kubectl create configmap kubeconfig --namespace r-updated --from-file $HOME/.kube

可使用代码仓库k8s目录中的https://github.com/Angatar/kubectl/blob/master/k8s/rolling-update-cronjob.yaml%E4%BD%9C%E4%B8%BACronJob%E6%A8%A1%E6%9D%BF%EF%BC%88%E6%B5%8B%E8%AF%95%E6%97%B6%E6%AF%8F%E5%88%86%E9%92%9F%E8%A7%A6%E5%8F%91%E4%B8%80%E6%AC%A1Job%EF%BC%8C%E9%9C%80%E6%A0%B9%E6%8D%AE%E9%9C%80%E6%B1%82%E8%B0%83%E6%95%B4Cron%E9%85%8D%E7%BD%AE%EF%BC%89%E3%80%82

该模板CronJob使用之前创建的ConfigMap“kubeconfig”加载kubectl配置（可根据需求修改）。编辑CronJob文件中的目标部署名称后，即可创建K8s CronJob：

sh
$ kubectl create -f rolling-update-cronjob.yaml

之后K8s将根据CronJob配置定期执行滚动更新。

许可证

https://github.com/Angatar/kubectl%E7%9A%84%E5%86%85%E5%AE%B9%E9%87%87%E7%94%A8**MIT**%E8%AE%B8%E5%8F%AF%E8%AF%81!%5BGitHub license](https://github.com/Angatar/kubectl/blob/master/LICENSE)%E3%80%82

关于kubectl的许可证信息，请访问 https://github.com/kubernetes/kubectl%E3%80%82

对Helm感兴趣？

若正在使用Kubectl，可能也会发现https://hub.docker.com/r/d3fk/helm/%E5%AE%B9%E5%99%A8%E6%9C%89%E7%94%A8%E3%80%82%E5%AE%83%E9%87%87%E7%94%A8%E7%B1%BB%E4%BC%BC%E7%9A%84%E8%BD%BB%E9%87%8F%E7%BA%A7%E3%80%81%E6%9E%81%E7%AE%80%E5%AE%B9%E5%99%A8%E6%96%B9%E6%A1%88%EF%BC%8C%E7%94%A8%E4%BA%8E%E5%9C%A8Kubernetes%E9%9B%86%E7%BE%A4%E4%B8%AD%E9%83%A8%E7%BD%B2Helm Chart。

更多详情和使用说明，请查看https://github.com/Angatar/helm%E6%88%96https://hub.docker.com/r/d3fk/helm/%E3%80%82