
d3fk/kubectl管理Kubernetes集群。
可用于CI/CD流程,或直接作为主要的Kubectl命令行工具(可通过更改标签指定版本)。
对于Flatcar Container Linux等精简/不可变Linux发行版,此容器尤为便捷,可利用Docker镜像的不可变性,无需依赖包管理器...详见提示:快速设置
获取d3fk/kubectl镜像的最佳方式是从Docker Hub Registry拉取预构建镜像。
该镜像通过Docker Hub的“自动化构建”功能从代码仓库构建为多架构镜像。
镜像名称 d3fk/kubectl
sh$ docker pull d3fk/kubectl:latest
Docker Hub仓库:[***]
。这些镜像版本固定,不会更改,通过代码仓库“releases”部分的代码由Docker Hub自动化构建,且稳定不再重建:
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文件对当前用户可访问,可在终端中复制粘贴以下命令进行快速本地设置:
shalias 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等)。
此容器最初用于K8s CronJob,以定期触发特定部署的强制滚动更新,使相关伸缩应用通过定期重启Pod获得新容器,提升稳定性且无 downtime。
为便于说明和测试,模板YAML文件位于代码仓库的k8s目录。
可通过补丁更新目标部署或使用kubectl rollout restart触发Pod滚动更新,需定义滚动更新策略以确保触发预期行为,例如:
yamlspec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: max***: 1 # 每次可添加的Pod数量 maxUnavailable: 1 # 滚动更新期间不可用的Pod数量
完整的模板部署文件见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文件:rbac-rupdate.yaml,请根据需求调整权限和命名空间。
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目录中的rolling-update-cronjob.yaml作为CronJob模板(测试时每分钟触发一次Job,需根据需求调整Cron配置)。
该模板CronJob使用之前创建的ConfigMap“kubeconfig”加载kubectl配置(可根据需求修改)。编辑CronJob文件中的目标部署名称后,即可创建K8s CronJob:
sh$ kubectl create -f rolling-update-cronjob.yaml
之后K8s将根据CronJob配置定期执行滚动更新。
GitHub代码仓库的内容采用MIT许可证
manifest unknown 错误
TLS 证书验证失败
DNS 解析超时
410 错误:版本过低
402 错误:流量耗尽
身份认证失败错误
429 限流错误
凭证保存错误
来自真实用户的反馈,见证轩辕镜像的优质服务