Docker 系列完结

# 200.Docker 系列完结

经过这 3~5 天的学习，相信大家都对 Docker 有了一定的了解，希望同学们在学习的过程中一定要动手做一遍，融会贯通。

但技术学习，永无止境。下一步，我们可以开始学习 K8s 了。在介绍它之前，我们先介绍下微服务架构。

本文很多内容参考了阮一峰老师的博客：白话多集群：工具和应用助手 (opens new window)

Docker 出现后，大大简化了软件部署，变成只需运行容器镜像。很自然地，开发者就开始考虑，能不能把单体的巨型软件，拆分成为多个组件（即多个容器）部署？

早期的企业级大型应用，通常都是一个巨大的单体软件（monolithic），包含不同功能的多个组件。哪怕只修改一个组件，也需要把整个软件重新部署一次。

现在的实践则是，把较大的功能组件拆分出来，每一个组件都是一个独立的服务，作为一个 Docker 容器单独发布和部署。

于是，单体软件就变成了多个 Docker 容器组成的软件系统，这就是现在流行的"微服务架构"（microservices） 。软件包含多个微服务，每个微服务对应一个 Docker 容器。

微服务意味着，每次发布都涉及大量不同的容器，管理它们就成了一种挑战。容器管理工具就应运而生。

各种容器管理工具之中，名气最大的非 Kubernetes (opens new window) 莫属。

它是谷歌开发的一款开源软件，因为词首K和词尾s之间有8个字符，所以常常写成 K8s。它已经成为事实上的容器管理标准。

具体来说，它主要有以下功能：

（1）统一的硬件接口。开发者不必关注底层的硬件细节，不管底层服务器有什么差异，都被抽象成统一的操作接口。

（2）自动扩展。它可以根据软件负载情况，快速完成水平扩展。

（3）高可用。当某个容器失败时，它会自动重启或替换掉该容器，保证流量流向可用的节点。

（4）其他功能。它还具有服务发现、负载均衡、资源监控等大量相关功能，同时带有庞大的插件和扩展，以及活跃的社区。

Kubernetes 的底层就是一组服务器，上面运行着许多容器。每个 Kubernetes 实例，就被称为一个集群（cluster） 。

普通的软件应用，只要一个集群就够了。但是，出于下面提到的原因，企业级应用往往需要部署在多个集群。

‍

多集群（multi cluster）可以在同一个机房，也可以在不同机房。实际应用中往往是后者，即分布在不同机房，这时如果集群来自不同的云服务商，或者是不同性质的云，就称为"多云"（multicloud）。

多集群的主要考虑如下：

（1）容灾。如果一个集群出问题，那么还有另一个集群，可以保证可用。

（2）隔离。集群之间可以做到非常强的物理隔离，从而实现上层用户（租户）的隔离。

（3）灵活性。多云有助于减少供应商锁定，可以根据需求选择最合适的基础设施和服务。

（4）合规性。不同地区可能有不同的监管要求，多集群可以为每个集群实施更精细的安全策略和访问控制。

多集群虽然有上一节的好处，但是复杂性也随之加倍，为使用者带来了许多挑战：

（1）配置和管理复杂性。所有集群需要一致的配置和部署，尽量消除差异。

（2）网络连接和延迟。如何保证不同地理位置的集群，有安全可靠的连接，同时最大限度地减少延迟。

（3）服务发现和负载均衡。某个服务如何发现不同集群中的其他服务，以及如何让不同集群负载均衡。

（4）监控。所有集群的指标和日志，最好汇集在一起，便于集中式监控。

（5）安全和访问控制。多集群的安全策略、访问控制、凭证管理都变得更加复杂，需要仔细规则和逐一设置。

为了解决上面的挑战，就诞生了专门的多集群管理工具，比如 Argo CD、Rancher Fleet、Karmada 等。

它们可以看作是开发者与 Kubernetes 之间的中间层，解决集群管理的复杂性。

问题是，要使用它们，必须先学会 Kubernetes，再去学习这些工具本身。这是巨大的学习成本，所以多集群工具不是针对应用开发者，而是针对集群管理员。

现实中，多集群是高度专业的领域，其他领域的开发者根本看不懂。开发者完成软件开发后，会把应用交给集群管理员，让后者去部署。

这对双方都很麻烦。一方面，开发者不能决定部署策略，也不了解底层资源，许多情况下可能不得不接触容器管理。另一方面，集群管理员会被迫介入应用层，一旦发生底层资源的调整，还需要通知开发者，让其参与进来保证应用的运行。

‍（未完待续....） ‍

上次更新: 2025/6/3 17:50:46