资讯动态

Docker Compose 一键上 Kubernetes:docker-ce 中 Compose on Kubernetes 完整实战指南

发布时间:2026/10/13 7:07:13 来源:尧图企业网站定制
容器运行时云原生【免费下载链接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:项目地址https://gitcode.com/gh_mirrors/do/docker-ce点击查看免费下载本文围绕 docker-ce 仓库中 vendored 的 Compose on Kubernetes 组件README系统讲解如何用docker stack deploy直接把 Docker Compose 文件部署到 Kubernetes 集群。你将掌握安装检查、stack 部署/删除、底层 Stack 自定义资源CRD与 API 版本机制、调试构建流程以及在生产集群AKS/GKE/Microk8s/Minikube上的部署思路。什么是 Compose on KubernetesCompose on Kubernetes 是 Docker 官方提供的一个 Kubernetes 组件其核心能力正如其 README 开篇所述允许你直接使用 Docker Compose 文件在 Kubernetes 集群上部署应用栈Stack。在 docker-ce 仓库中它作为 CLI 的 vendored 依赖存在于components/cli/vendor/github.com/docker/compose-on-kubernetes/目录下其中包含两大部分API 定义api/目录Stack 这一自定义资源的类型定义、注册逻辑、客户端 clientset/informer/lister以及分组compose.docker.com下的多个 API 版本文档README.md面向用户和开发者的使用与调试指南即本文展开的核心内容。该组件随 Docker Desktop 和 Docker Enterprise 内置分发。使用场景很明确团队里已经有成熟的docker-compose.yml又想迁移到 Kubernetes 平台时无需重写为 Deployment/Service 等一大堆 YAML直接用 Docker 原生的 stack 命令就能完成部署。说明当前 docker-ce 仓库对该组件的角色是随 CLI 一并分发、供docker stack deploy --orchestratorkubernetes调用本仓库并未包含 compose-on-kubernetes 的 controller 实现源码controller 侧运行于 Docker Desktop/Enterprise 的 Kubernetes 集群内。快速开始在 Docker Desktop 上启用与部署1. 环境准备与启用Compose on Kubernetes 预装在 Docker Desktop 与 Docker Enterprise 中。在 Docker Desktop 上你需要在设置中激活 Kubernetes才能使用该功能。2. 检查组件是否已安装组件是否可用可以通过查询 API 是否暴露来判断。执行$ kubectl api-versions | grep compose compose.docker.com/v1beta1 compose.docker.com/v1beta2compose.docker.com就是 Compose on Kubernetes 注册的 API 分组group。当前仓库的 API 注册代码中该分组名定义为GroupName compose.docker.com见 register.go版本包括v1beta1、v1beta2此外 API 目录下还有较新的v1alpha3版本。3. 部署一个 Stack准备一个 Compose 文件README 中的完整示例定义了三服务应用hellokubeversion: 3.3 services: db: build: db image: dockersamples/k8s-wordsmith-db words: build: words image: dockersamples/k8s-wordsmith-api deploy: replicas: 5 web: build: web image: dockersamples/k8s-wordsmith-web ports: - 33000:80用 Docker CLI 指定 Kubernetes 编排器部署$ docker stack deploy --orchestratorkubernetes -c docker-compose.yml hellokube这里的关键参数是--orchestratorkubernetes它告诉 Docker CLI 本次 stack 操作走 Kubernetes 路径。示例中words服务通过deploy.replicas: 5声明 5 个副本web服务通过ports将容器 80 端口发布到宿主机的 33000 端口——这些 Compose 语义都会在部署时被映射为 Kubernetes 的 Deployment、Service 等对象。部署完成后 CLI 会输出 Waiting for the stack to be stable and running...并通过 watch 机制持续跟踪状态详见下文部署状态监控一节。4. 移除 Stack删除整个 stack连同其 Kubernetes 资源$ docker stack rm --orchestratorkubernetes hellokube删除时Stack 对象的子资源由 Compose 的 file-based secrets/configs 生成的 Secret/ConfigMap 等会通过 Kubernetes 的 OwnerReference 级联清理其实现见 stack.go 中的configMapChildResource/secretChildResource类型。从源码看实现原理docker-ce 仓库中保留了完整的 CLI 集成源码可以帮你理解Compose 文件是如何变成 Kubernetes 资源的。Stack 自定义资源CRDStack 是该方案的核心自定义资源。以v1beta2版本为例stack.go其结构为StackSpec包含Services服务配置列表、Secrets、Configs三个部分StackStatus记录部署阶段Phase与可读信息Message。其中ServiceConfig几乎完整覆盖了 Compose 服务的常用字段Image、Command、Entrypoint、Environment、Ports、Volumes、HealthCheck、Deploy副本数/更新策略/资源限制/重启策略/放置约束、Privileged、Tmpfs、WorkingDir等见 stack.go。Stack 的Status.Phase定义了四种生命周期状态stack.goPhase含义AvailableStack 可用部署完成Progressing部署进行中Failure某个成员创建/删除失败ReconciliationPending尚未被 controller 调谐reconcile此外v1beta2还定义了ComposeFile保存 stack 原始 compose 文件内容、Scale服务期望/当前副本数映射等辅助类型见 composefile_stack_types.go 与 scale.go。API 版本协商与自动选择不同 Kubernetes 集群上安装的 compose 组件版本不同CLI 需要先探测集群支持的 Stack API 版本。在 client.go 中Factory.Stacks()通过 Kubernetes Discovery 客户端获取compose.docker.com组的 API 版本然后按v1beta1 → v1beta2 → v1alpha3选择对应的客户端实现。三个版本的能力差异在 convert.go 中有明确定义v1beta1仅保存完整 Compose 文件文本Spec.ComposeFilecompose 版本上限为3.5见 parsing.gov1beta2结构化存储StackSpecv1alpha3额外支持pull secretsx-kubernetes.pull_secret、pull policiesx-kubernetes.pull_policy、stack 内负载均衡x-kubernetes.internal_service_type。如果 Compose 文件使用了高版本特性而集群 API 版本过低CLI 会直接报错提示请使用 v1alpha3 或更高版本。版本化转换从 Compose 到 StackfromComposeServiceConfigconvert.go是Compose 模型 → Stack API 模型的核心转换函数它完成的关键映射包括Compose 的deploy.resources.limits/reservations→ResourcesCPU 以 NanoCPUs、内存以字节表示Compose 的deploy.restart_policy→RestartPolicyCompose 的deploy.placement.constraints→Placement其中 Swarm 风格的约束node.platform.os、node.platform.arch、node.hostname、node.labels.xxx会被解析为 Kubernetes 的节点选择器convert.goCompose 的ports、secrets、configs、volumes、healthcheck等均映射到对应的 Stack 结构。值得注意的是x-kubernetes扩展字段Compose 文件可以在 service 上声明x-kubernetes.pull_secret、x-kubernetes.pull_policy和x-kubernetes.internal_service_type可选值为ClusterIP/Headless空值表示自动这些是 Compose on Kubernetes 特有的 Kubernetes 增强能力convert.go。标签体系如何识别 stack 与 serviceKubernetes 对象依靠 label selector 被关联回各自的 stack。仓库中定义的三个标签labels.go为标签键用途com.docker.service.name服务名com.docker.stack.namespaceStack 名com.docker.service.id服务唯一 ID格式为stack名-服务名SelectorForStack()会据此生成形如com.docker.stack.namespacehellokube,com.docker.service.name in (words,web)的 label selector用于按 stack 过滤 Pod、Service 等资源labels.go。部署流程与冲突检测RunDeploydeploy.go描述了docker stack deploy走 Kubernetes 路径的完整流程创建 compose 客户端从StackClient将 Compose 模型转换为 Stack 对象将 file-based 的 Composeconfigs/secrets转换为 KubernetesConfigMap/Secret见 stack.go冲突检测检查 stack 中声明的服务名是否已存在于集群。若同名 Service 已存在但缺少com.docker.stack.namespace标签或标签值不同则判定冲突并报错避免误覆盖其他 stack 或手工创建的资源。该逻辑在 stackclient.go 的verify函数中实现v1beta2及以上版本则由服务端处理客户端无需检查调用CreateOrUpdate创建或更新 Stack 对象并通过 OwnerReference 将子资源挂到 Stack 名下stackclient.go输出 Waiting for the stack to be stable and running... 并启动 watcher 等待就绪。部署状态监控部署后 CLI 会同时监听两类对象watcher.goStack 对象一旦 Stack 的Phase变为Failure立即报错并携带MessagePod 状态统计每个服务下 Pod 的 ready / pending / failed / unknown 数量实时刷新到终端。输出分两种模式终端交互模式下用 ANSI 控制码原地刷新每行状态非终端管道/CI模式下只输出状态变化格式如words: Ready [pod status: 3/5 ready, 0/5 pending, 2/5 failed]deploy.go。待全部服务就绪后输出Stack hellokube is stable and running。命名空间与 kubeconfigKubernetes 集成支持--namespace与--kubeconfig两个 flag见 cli.go并兼容 Docker context 与 kubectl 上下文当设置了 Docker 当前 context 时优先从 context 读取 Kubernetes 配置否则回退到KUBECONFIG环境变量或默认的~/.kube/configconfig.go。stack ls还支持--all-namespaces列出所有命名空间下的 stack。开发与调试 Compose on Kubernetes如果要在 Docker Desktop 上对 compose 组件API server 与 controller做二次开发或调试README 提供了完整流程。前置条件makeDocker DesktopMac 或 Windows引擎版本18.09 及以上设置环境变量DOCKER_BUILDKIT1启用 BuildKit在 Docker Desktop 设置中启用 Kubernetes实时调试场景还需要支持Delve API version 2远程调试能力的调试器GoLand 已预配置好 run-config安装调试版镜像带调试符号$ make -f debug.Makefile install-debug-images该命令会构建带调试符号的镜像运行调试安装器在docker命名空间中安装 API server 与 Compose controller 的调试版创建两个调试用LoadBalancer服务此模式下不使用用 kubectl 验证安装结果$ kubectl get all -n docker NAME READY STATUS RESTARTS AGE pod/compose-7c4dfcff76-jgwst 1/1 Running 0 59s pod/compose-api-759f8dbb4b-2z5n2 2/2 Running 0 59s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/compose-api ClusterIP 10.98.42.151 none 443/TCP 59s service/compose-api-server-remote-debug LoadBalancer 10.101.198.179 localhost 40001:31693/TCP 59s service/compose-controller-remote-debug LoadBalancer 10.101.158.160 localhost 40000:31167/TCP 59s NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/compose 1 1 1 1 59s deployment.apps/compose-api 1 1 1 1 59s NAME DESIRED CURRENT READY AGE replicaset.apps/compose-7c4dfcff76 1 1 1 59s replicaset.apps/compose-api-759f8dbb4b 1 1 1 59s此时docker命名空间下有两个 Deploymentcomposecontroller与compose-apiAPI server。用kubectl describe deployment查看镜像应能看到镜像名为*-debug:latest。安装实时调试版Live Debugging$ make -f debug.Makefile install-live-debug-images与上一个命令的区别是构建带调试符号的镜像将镜像 entrypoint 改为启动Delve server运行调试安装器在docker命名空间安装 API server 与 Compose controller 的调试版创建两个调试用LoadBalancer服务localhost:40000→ Compose controllerlocalhost:40001→ API serverAPI server 与 Compose controller 只有在调试器 attach 之后才会启动连接调试器有两种方式使用 GoLand选择仓库.idea中的Debug all配置打上断点后启动调试器使用任意兼容 Delve 的调试器指向localhost:40000与localhost:40001。用终端的话先执行dlv connect localhost:40000然后输入continue并回车。用kubectl get all -n docker可确认组件已安装。验证 API server 是否启动查看其日志$ kubectl logs -f -n docker deployment.apps/compose-api compose API server listening at: [::]:40000 ERROR: logging before flag.Parse: I1207 15:25:13.760739 11 plugins.go:158] Loaded 2 mutating admission controller(s) successfully in the following order: NamespaceLifecycle,MutatingAdmissionWebhook. ERROR: logging before flag.Parse: I1207 15:25:13.763211 11 plugins.go:161] Loaded 1 validating admission controller(s) successfully in the following order: ValidatingAdmissionWebhook. ERROR: logging before flag.Parse: W1207 15:25:13.767429 11 client_config.go:552] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work. ERROR: logging before flag.Parse: W1207 15:25:13.851500 11 genericapiserver.go:319] Skipping API compose.docker.com/storage because it has no resources. ERROR: logging before flag.Parse: I1207 15:25:13.998154 11 serve.go:116] Serving securely on [::]:9443日志中的ERROR:前缀来自 kube-apiserver 组件在flag.Parse之前的标准输出行为属于正常现象。Skipping API compose.docker.com/storage表示该 group 下没有资源会被注册。最后一行Serving securely on [::]:9443表示 API server 已就绪。验证 Compose controller 是否启动查看其日志kubectl logs -f -n docker deployment.apps/compose API server listening at: [::]:40000 Version: v0.4.16-dirty Git commit: b2e3a6b-dirty OS/Arch: linux/amd64 Built: Fri Dec 7 15:18:13 2018 time2018-12-07T15:25:19Z levelinfo msgController readycontroller 打印版本、Git commit、构建信息最后输出Controller ready表示调谐循环reconcile loop已就绪——从这一刻起它开始监听 Stack 对象并驱动其下 Deployment/Service/Pod 的创建。恢复默认版本调试完成后需要恢复默认的 Compose on Kubernetes只需重启 Kubernetes 集群——在 Docker Desktop 设置中先停用再启用 Kubernetes或直接重启 Docker Desktop。更多细节可参考原项目的 contributing 与 debugging 指南。在云端与本地集群上部署除 Docker Desktop 自带外Compose on Kubernetes 也可以安装到其他 Kubernetes 发行版。原项目提供了四份部署指南说明本仓库仅 vendored 了 README具体指南文件位于上游项目的 docs 目录未随仓库分发Azure AKS在 Azure 托管的 Kubernetes 服务上安装组件并启用 stack 部署GKE在 Google Kubernetes Engine 上安装Microk8s在轻量级、本地化的 Microk8s 上安装适合开发与边缘场景Minikube在本地单节点 Minikube 上安装适合无 Docker Desktop 环境如 Linux下的本地体验。这些环境安装完 compose 组件后使用方法与本篇一致先kubectl api-versions | grep compose确认 API 就绪再用docker stack deploy --orchestratorkubernetes部署。局限与适用范围结合仓库源码使用前应了解以下几点编排器选择是显式的必须为 stack 命令显式指定--orchestratorkubernetes或通过配置全局设置若未指定CLI 会报错no orchestrator specified: use either kubernetes or swarmcmd.go。当同时使用 swarm 与 Kubernetes 编排器时CLI 还会校验 Docker daemon 主机与 Kubernetes API 主机是否匹配避免在错误的集群上部署cli.go。Compose 功能子集并非所有 Compose 指令都会被转换。CLI 会对不支持的字段给出告警v1beta1版本仅接受 compose schema 3.5 及以下。高版本独有的 Kubernetes 增强pull secret、pull policy、stack 内负载均衡仅在v1alpha3可用。文档对应版本README 示例使用version: 3.3与 Docker Desktop 18.09 环境当前 docker-ce 仓库对应时代的 CLI 集成即基于上述源码实现后续版本的功能差异请以你所使用的 Docker Desktop/Enterprise 版本为准。参考资源组件 README本文依据components/cli/vendor/github.com/docker/compose-on-kubernetes/README.mdStack 类型定义v1beta2api/compose/v1beta2/stack.goStack 类型定义v1alpha3含x-kubernetes扩展api/compose/v1alpha3/stack.go标签体系api/labels/labels.goCLI 部署流程cli/command/stack/kubernetes/deploy.goCompose → Stack 转换cli/command/stack/kubernetes/convert.goStack 客户端与冲突检测cli/command/stack/kubernetes/stackclient.go部署状态监控cli/command/stack/kubernetes/watcher.goAPI 版本发现与选择cli/command/stack/kubernetes/client.go赞分享容器运行时云原生【免费下载链接】docker-ce:warning: This repository is deprecated and will be archived (Docker CE itself is NOT deprecated) see the https://github.com/docker/docker-ce/blob/master/README.md :warning:项目地址https://gitcode.com/gh_mirrors/do/docker-ce点击查看免费下载相关推荐在Amazon EKS上部署Docker Compose on Kubernetes全指南在Amazon EKS上部署Docker Compose on Kubernetes全指南 前言 Docker Compose on Kubernetes项目将终极指南5个SystemInformer系统监控技巧让你成为Windows系统安全专家终极指南5个SystemInformer系统监控技巧让你成为Windows系统安全专家 SystemInformer前身为Process Hacker是一桌面应用调试器应用安全驱动开发用 Docker Compose 一键部署 hug MongoDB 微服务完整实战指南用 Docker Compose 一键部署 hug MongoDB 微服务完整实战指南 导读 本指南围绕 hug 仓库中 examples/docker_后端上一篇Vue Table 响应式配置类型解析TableOptionsWithReactiveData 的原理与实战下一篇如何用TypePHP开发Android原生应用NDK集成完整教程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑