容器管理建议单机用 Docker Compose，多机用 Kubernetes（K8s）¶

在当今的软件开发与部署领域，容器技术已经成为了不可或缺的一部分。它以其轻量级、隔离性强、可移植性高等优点，极大地改变了应用程序的开发、测试和部署方式。

而在容器管理的工具选择上，Docker Compose 和 Kubernetes（k8s）是当前最为常用的两类工具选择。

本文从适合的场景、管理容器需要考虑的核心问题、技术选型等多个方面进行说明。

k8s-docker-compose

Docker Compose 和 Kubernetes 介绍¶

Docker Compose 是 Docker 官方提供的容器编排工具，用于定义和运行多容器的Docker应用程序。

它通过一个YAML格式的配置文件（通常为docker-compose.yml）来声明式地定义应用的各个服务、网络和存储卷等，使得用户能够使用简单的命令来启动、停止和管理整个应用栈，极大地简化了多容器应用在单机环境下的部署与管理。

Kubernetes 是一个开源的容器编排平台，旨在自动化容器化应用的部署、扩展和管理。

它提供了丰富的功能，如自动部署、自动扩缩容、服务发现、负载均衡、滚动更新和回滚等，能够有效地管理大规模的容器集群，适用于复杂的生产环境和分布式系统。

单机选择 Docker Compose¶

单机适合的场景？¶

开发者本地开发测试场景，快速搭建业务环境便于本地开发调试
业务系统对稳定性要求不高，可以接受一定时间的服务异常的生产环境
使用了较为稳定的云平台（如公有云）的环境

单机管理容器需要考虑哪些问题？¶

1. 资源占用合理，成本可控。

资源使用少，意味着成本相对会低，这对于个人开发者、或者小微等初创企业非常重要。

使用单机运行在早期可以满足业务运行需求，又不需要为高可用集群投入大量成本，即使单机环境运行异常重新拉起来运行即可，故障一段时间对用户和业务影响也在可接受范围。

2. 技术栈简单，易于管理。

在单机上运行和管理容器，使用复杂的集群管理工具会来带资源额外消耗、管理和学习的成本增高。

传统方式可以通过编写 shell 脚本，将一个或多个 docker run 命令封装起来，再写一些逻辑用于容器的启停等管理，但这种方式管理任然比较复杂。

3. 运行环境一致性，便于重建和迁移。

容器技术解决了应用进程的运行环境不一致问题，但是运行和管理容器也需要考虑环境一致性，比如单容器端口映射配置、存储挂载配置、环境变量配置等；以及多容器的访问关系，运行依赖等配置。

使用同一份配置文件来管理可以进行版本控制，团队成员可以基于相同的配置文件在各自的开发环境中搭建出一致的应用栈，避免了“在我机器上能运行”的问题，增强了协作效率。

单机管理容器有哪些推荐？¶

在单机上管理容器目前主流的工具有 Docker Compose 、Podman Compose、Minikube、K3s 等

Docker Compose：是 Docker 官方提供的容器编排工具，用于定义和运行多容器的Docker应用程序。
Podman Compose：Podman 是一个开源的容器运行时，与 Docker 兼容，且使用起来更简单。
Minikube：Minikube 是一个用于本地 Kubernetes 集群的轻量级工具，可以快速启动一个单节点的 Kubernetes 集群，用于本地开发、测试和调试。
K3s：K3s是一个基于 Kubernetes 的轻量级容器集群管理工具，就一个二进制文件，可以快速、轻松地部署 Kubernetes 集群。

对于这4种方案中 Minikube 和 K3s 是基于 Kuberentes 的体系，可以在单机上管理 Kuberentes 集群，若对 Kubernetes 有一定的基础或者要深入学习这两种方案是个不错的选择。

但是，Minikube 构建完整的 Kubernetes 集群需要较多的控制资源，且网络配置复杂，并且在国内由于镜像仓库问题安装和使用困难；

K3s 虽然控制资源消耗不高，但一些基础的网络、DNS、Ingress 等组件任然占用一定的资源，且基于 Kubernetes 集群管理，有较高的学习曲线。

Podman 和 Podman Compose 在产品功能上与 Docker 和 Docker Compose 相似且兼容，目前还在快速发展，期望不久的将来能够成为 Docker 的全面替代。但产品成熟度还有待提升，目前是 CNCF 的沙盒项目。

对比下来 Docker Compose 方案似乎能够相对更好的解决 资源占用合理，成本可控、技术栈简单，易于管理 和 运行环境一致性，便于重建和迁移 的问题，是当前较为合适的选择。

Docker Compose 运行在单机上，不需要额外的复杂组件和大规模的集群管理开销，对系统资源的占用极低。

使用 Docker Compose 只需编写一个简洁的 docker-compose.yml 文件，就能定义应用所需的多个容器服务，包括容器的镜像来源、端口映射、环境变量、依赖关系等。也可以标准化和版本化管理应用部署和运行。

此外，还具有开发与测试友好的优点，在开发过程中，频繁的代码修改和测试是常态。使用 Docker Compose，开发者可以通过简单的命令（如docker-compose up -d --build）实现容器的快速重建和重启，将本地代码目录绑定到容器中，实现实时重载，无需重新构建镜像，大大提高了开发效率。

例如，一个简单的Web应用，包含前端、后端和数据库服务，其docker-compose.yml文件可能如下：

version: '3'
services:
  web:
    image: my-web-image:latest
    ports:
      - "8080:80"
    depends_on:
      - api
  api:
    image: my-api-image:latest
    environment:
      - DB_HOST=db
  db:
    image: my-db-image:latest

开发者可以轻松理解和维护这样的配置文件，快速搭建起开发、测试环境。

藏云阁 Docker Compose Git 仓库版本化管理示例¶

藏云阁技术社区前期基于公有云的虚拟机搭建了应用。考虑到公有云本省的稳定性，结合当前阶段业务对稳定的要求，选择使用 Docker Compose 搭建单机生产环境。

以下是部分的配置文件，保存在 Git 仓库中，可以快速在不同的云平台机器中快速搭建和迁移。

[root@aliyun ~]# tree cncfstack-cloud-services/
.
├── casdoor
│   ├── conf
│   │   └── app.conf
│   ├── docker-compose.yml
│   ├── nginx
│   │   └── casdoor.conf
│   └── README.md
├── gitea
│   ├── app.ini
│   ├── docker-compose.yml
│   ├── nginx
│   │   └── gitea.conf
│   └── README.md
├── it-tools
│   ├── docker-compose.yml
│   ├── nginx
│   │   └── it-tools.conf
│   └── README.md
├── nginx
│   ├── docker-compose.yml
│   ├── nginx
│   │   └── nginx.conf
│   ├── README.md
│   └── ssl
├── postgresql
│   ├── docker-compose.yml
│   ├── README.md
├── redis
│   ├── docker-compose.yml
│   └── README.md
├── umami
│   ├── docker-compose.yml
│   ├── nginx
│   │   └── umami.conf
│   └── README.md

多机场景选择Kubernetes¶

单机运行也存在较多的局限，比如业务运行需要的多机调度、高可用、弹性伸缩、负载均衡、服务发现等等。

多机场景是指有多台服务器可供使用，期望以更好、更高效的方式使用这些机器资源，使其创造更大的价值。

多机适合的场景？¶

对业务连续性较高，需要构建多节点的高可用环境
业务具有高并发特性，需要有一定的弹性伸缩能力和负载均衡能力
业务基于复杂的微服务框架，依赖复杂且庞大，在资源和性能等方面有较高的要求

多机管理容器需要考虑哪些问题？¶

1. 多台机器统一的管理

统一管理多台机器，能够了解机器的信息和状态、机器的资源使用情况，以及能够控制机器上运行的应用程序。

2. 资源池化和分配管理

将多台机器的硬件CPU、GPU、内存、磁盘等硬件资源抽象成一个巨大的资源池，并能够根据业务资源需求灵活分配这些资源。

3. 容器应用的灵活调度

能够将容器用应用在多台机器上根据各种实际情况进行最合理的调度，并能够根据调度结果对容器进行管理。

4. 服务发现、通信、负载均衡与访问能力

应用在多个节点上分散调度后，如何发现服务、如何进行通信、如何进行负载均衡、如何进行访问控制等管理。

5. 资源弹性伸缩

根据业务运行的需求可以高效弹性的进行资源的伸缩，可以满足秒级别的资源动态调整。

多机器管理有哪些选择推荐¶

对于多机容器编排管理， 2015年～2017年间 Kubernetes、Mesos和Docker Swarm 竞争的如火如荼，江湖称容器三剑客。

最终Kubernetes凭借技术优势（如声明式API、微服务支持）、社区生态和云厂商背书胜出，成为容器编排的事实标准，也为后续的 CNCF 基金会奠定了基础。

Kubernetes 能够满足以上需求，并能做的更好。

声明式配置与自动化管理。Kubernetes 通过 YAML/JSON 文件声明应用的期望状态（如Pod副本数、资源需求、网络策略等），系统自动调整实际状态以匹配期望，无需手动干预。
对应用的自动化运维能力。Kubernetes持续监测集群中各个容器的健康状态，一旦发现容器故障，会自动进行重启、迁移等操作，确保应用的不间断运行。
提供了一系列的安全能力。如NetworkPolicy、RBAC、ServiceAccount、TLS加密等。

总结¶

Docker Compose和Kubernetes在容器编排领域都有着各自独特的优势和适用场景。在单机环境下，Docker Compose 凭借其简单易用、轻量级和开发友好的特点，能够快速搭建和管理多容器应用，是开发者进行本地开发和测试的首选工具。而在多机的生产环境中，Kubernetes强大的集群管理、弹性伸缩、网络和存储管理等功能，使其成为管理大规模容器化应用的最佳选择。

在实际应用中，应根据具体的业务需求、规模和技术团队的能力、资源运维成本等方面，合理地评估和选择工具，以充分发挥容器技术的优势，提升应用的开发、部署和运维效率。要避免“过度设计”（如单机强上K8s）或“技术滞后”（如大规模多机仍用手动部署）等问题。