用于 DevOps 的 Python

第 12 章 容器协调：Kubernetes

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

如果你正在尝试使用 Docker，或者在单台机器上运行一组 Docker 容器就是你所需要的全部，那么 Docker 和 Docker Compose 就能满足你的需求。但是，只要你从数字1 （单机）到数字2 （多机），你就需要开始担心在整个 Network+ 上协调容器的问题了。在生产场景中，这是必然的。您至少需要两台机器才能实现容错/高可用性。

在云计算时代，我们推荐的基础架构扩展方式是 "向外 "扩展（也称为 "横向扩展"），即在整个系统中添加更多实例，而不是老式的 "向上 "扩展（或 "纵向扩展"），即在单个实例中添加更多 CPU 和内存。Docker 协调平台将这些实例或节点作为原始资源（CPU、内存、网络）的来源，然后将其分配给在平台内运行的单个容器。这与我们在第 11 章中提到的使用容器而非传统虚拟机（VM）的优势息息相关：由于容器可以比虚拟机更细粒度地分配资源，因此可以更好地利用可支配的原始资源，从而使基础架构物有所值。

此外，服务器的配置也发生了转变，从为特定目的配置服务器并在每个实例上运行特定软件包（如网络服务器软件、缓存软件、数据库软件），转变为将服务器作为资源分配的通用单元进行配置，并在 Docker 协调平台的协调下在服务器上运行 Docker 容器。将服务器视为 "宠物 "与将其视为 "牲畜 "之间的区别，大家可能并不陌生。在基础设施设计的早期，每台服务器都有明确的功能（如邮件服务器），而且很多时候每种特定功能只有一台服务器。这些服务器有自己的命名方案（格里格记得在网络公司时代使用的是行星系统命名方案），而且需要花费大量时间对它们进行照顾和喂养，因此被称为 "宠物"。当 Puppet、Chef 和 Ansible 等配置管理工具大行其道时，通过在每台服务器上使用相同的安装程序，同时配置多台同类型服务器（例如网络服务器群）变得更加容易。这与云计算的兴起、前面提到的水平可扩展性概念以及对容错和高可用性作为精心设计的系统基础设施的关键属性的更多关注不谋而合。服务器或云实例被认为是 "牛"，是一次性单位，在其总量中具有价值。

容器和无服务器计算时代还带来了另一个称谓--"昆虫"。的确，可以把容器的来来去去看成是一种潜在的短暂存在，就像昙花一现的昆虫。与 Docker 容器相比，功能即服务更是转瞬即逝，其短暂而紧张的生命与调用时间相吻合。

就容器而言，由于其短暂性，很难实现大规模的协调和互操作性。这正是容器编排平台所要满足的需求。过去有多种 Docker 协调平台可供选择，如 Mesosphere 和 Docker Swarm，但如今我们可以肯定地说，Kubernetes 赢得了这场游戏。本章接下来的内容是对 Kubernetes 的简短概述，然后以运行第 11 章中描述的同一应用程序为例，将其从docker-compose 移植到 Kubernetes。我们还将展示如何使用 Kubernetes 软件包管理器 Helm 为监控和仪表盘工具 Prometheus 和 Grafana 安装名为图表的软件包，以及如何自定义这些图表。

Kubernetes 概念简述

要了解 Kubernetes 集群的众多组成部分，最好的起点是Kubernetes 官方文档。

从高层来看，Kubernetes 集群由节点组成，这些节点可以等同于服务器，无论是裸机还是在 Cloud 中运行的虚拟机。节点运行 ...