1.3　深入了解Kubernetes架构

Kubernetes有非常宏大的目标，它致力于管理并简化跨环境和云提供商的分布式系统的编排、部署和管理。它提供了许多功能和服务，这些功能和服务应当适应于各种情境，并不断衍化和保持足够简单以供大部分用户使用。这是一个艰巨的任务。Kubernetes通过清晰的排布、高水平的设计和成熟的架构来实现这一点，该架构同时促进了系统的扩展性和灵活性。Kubernetes的许多部分仍是硬编码或环境敏感的，但它们会被逐渐分解为插件，并保持内核的通用性和概括性。在本节中，将对Kubernetes层层解剖，首先介绍各种分布式系统设计模式以及Kubernetes如何对其进行支持；然后介绍Kubernetes外层，即它的API集；接下来会介绍组成Kubernetes的实际组件；最后，对源代码树进行简要介绍，以对Kubernetes的结构进行进一步了解。

在本节的最后，读者将对Kubernetes的架构、执行以及其部分设计决策有深入的理解。

分布式系统设计模式

用托尔斯泰在《安娜·卡列尼娜》中的一句话来形容幸福的家庭（工作的分布式系统）都是相似的。这意味着，所有设计良好的分布式系统都必须遵循最佳实践和原则，以使其功能正常运行。Kubernetes不仅是一个管理系统，它同时还可应用这些最佳实践为开发者和管理员提供高水平的服务。下面将介绍几种设计模式。

1．边车模式

边车模式除主应用容器之外，还在Pod中共同定位另一个容器。应用容器并不知道边车容器，只是单纯执行自己的任务。中央日志代理（Central Logging Agent）就是一个很好的例子。主容器只将日志记录到stdout，但边车容器会将所有日志发送到一个中央日志服务，这些日志将在此处聚合整个系统的日志。使用边车容器相较于将中央日志添加到主应用容器有巨大的优势，应用不再受到中央日志的负担，如果要升级或更改中央日志记录策略或切换到新的提供商，只需更新并部署边车容器，应用容器并没有任何改变，因此不会由于意外情况而遭到破坏。

2．外交官模式

外交官模式是指将远程服务当作本地服务，并使其强制执行部分策略。外交官模式的一个很好的例子是，如果有一个Redis集群，该集群中一个主机用于编写，其余副本用于读取，则本地外交官容器可作为代理，并将Redis暴露给本地主机上的主应用容器。主应用容器简单地连接到localhost:6379（Redis缺省端口）上的Redis，但是它其实只是连接到在相同Pod中运行的外交官容器，该容器过滤请求，将编写请求发送到真正的Redis主机，并将读取请求随机发送到其中一个读取副本上，与挎斗模式类似，主应用在这期间并不了解运行过程。当测试真正的本地Redis集群时，这会有很大的帮助。此外，如果Redis集群配置发生改变，则只需要修改外交官容器，主应用同样不了解这一运行过程。

3．适配器模式

适配器模式是关于主应用容器的标准化输出。逐步推出的服务可能会面临如下问题：服务可能会生成不符合先前版本的格式报表，而其他使用该输出的服务和应用还未升级。适配器容器可以与新的应用容器共同部署在同一Pod上，并将其输出与旧版本相匹配，直到所有的用户都被升级。适配器容器与主应用程序容器共享文件系统，以此监控本地文件系统，每当新应用写入某个文件时，适配器容器将立即进行适配。

4．多节点模式

单节点模式都是直接由Kubernetes通过Pod直接进行支持的。而多节点模式并不被直接支持，例如负责人选举、工作队列和分散收集等，但使用标准接口组合Pod可实现Kubernetes支持。