从云到地球：如何在任何环境中创建生产级Kubernetes

对所有人都好！ 好了， 我们下一个Devops课程的时机已经到了。 可能这是最稳定和参考性的课程之一，但同时在学生方面也是最多样化的，因为没有一个团队看起来像另一个团队一样：一个开发人员几乎是完全的，然后是下一个工程师，然后是管理员，依此类推。 而且这也意味着是时候来寻找有趣和有用的材料以及在线会议的时候了。



本文包含有关在本地数据中心或外围位置（边缘位置）启动生产级Kubernetes集群的建议。
生产等级是什么意思？

• 安全安装
• 部署管理是通过重复和记录的过程执行的；
• 工作是可预测的和一致的；
• 进行更新和调整是安全的；
• 为了检测和诊断错误以及缺乏资源，需要进行日志记录和监视。
• 考虑到可用资源，包括对资金，物理空间，电源等的限制，该服务具有足够的“高可用性”。
• 如果发生故障，可以使用恢复过程，对其进行记录并进行测试以供使用。

简而言之，生产级意味着可以预见错误并为恢复做好准备，同时减少问题和延迟。



这篇文章是关于在虚拟机管理程序或裸机平台上Kubernetes的本地部署，因为与主要公共云的增加相比，支持资源的数量有限。 但是，如果预算限制了所选资源，则其中一些建议可能对公共云很有用。

部署单裸金属裸机Minikube可能是一个简单且便宜的过程，但它不是生产级的。 相反，尽管不太可能需要Borg，但您无法在离线商店，分支机构或外围位置达到Borg的Google级别。

本文介绍了即使在资源有限的情况下也可以实现生产级Kubernetes部署的技巧。

Kubernetes集群中的重要组件

在深入研究细节之前，了解Kubernetes的总体架构很重要。
Kubernetes集群是一个基于控制平面和集群工作节点的体系结构的高度分布式系统，如下所示：



通常，API服务器，控制器管理器和调度程序的组件位于控制级节点（称为主节点）的多个实例中。 主节点通常还包括etcd，但是有大型且高度可访问的脚本要求在独立主机上运行etcd。 组件可以作为容器运行，并且可以选择在Kubernetes的监督下作为静态壁炉运行。

这些组件的冗余实例用于高可用性。 冗余的重要性和所需级别可能会有所不同。

组成部分	的角色	损失后果	推荐实例
等	维护所有Kubernetes对象的状态	灾难性的存储损失。 损失最多= Kubernetes失去了控制级别，API Server依赖于etcd，不需要仲裁的只读API调用（例如已经创建的工作负载）可以继续工作。	奇数，3+
API服务器	提供供内部和外部使用的API	无法停止，启动和更新新的Pod。 调度程序和控制器管理器取决于API服务器。 如果加载不依赖于API调用（运算符，自定义控制器，CRD等），则会继续加载	2+
库伯调度器	将Pod放置在节点上	不能在各个Pod之间放置Pod或对其进行优先排序。	2+
kube-controller-manager	控制许多控制器	负责状态停止的主控制循环。 云提供商的树内集成中断。	2+
云控制器经理（CCM）	树外云提供商集成	云提供商集成中断	1个
附加内容（例如DNS）	不同的	不同的	取决于附加组件（例如2+用于DNS）

这些组件的风险包括硬件故障，软件错误，错误更新，人为错误，网络中断和导致资源耗尽的系统过载。 冗余可以减少这些危害的影响。 此外，由于虚拟机管理程序平台的功能（资源计划，高可用性），您可以使用Linux操作系统，Kubernetes和容器运行时来将结果相乘。

API Server使用多个负载平衡器实例来实现可伸缩性和可用性。 负载平衡器是实现高可用性的重要组件。 在没有平衡器的情况下，DNS API服务器的多个A记录可以用作备用记录。

选择领导者而不是使用负载均衡器的过程涉及到kube-scheduler和kube-controller-manager。 由于cloud-controller-manager用于某些类型的托管基础​​架构，其实现可能会有所不同，因此我们将不讨论它们-我们仅表示它们是管理级别的组成部分。

Kubernetes上运行的Pod由kubelet代理管理。 每个worker实例都运行一个kubelet代理和一个与CRI兼容的容器启动环境。 Kubernetes本身旨在监视工作节点故障并从中恢复。 但是对于关键的负载功能，虚拟机管理程序资源管理和负载隔离，可以使用它来提高可访问性并提高其工作的可预测性。

等

etcd是所有Kubernetes对象的持久存储。 在部署生产级Kubernetes时，etcd群集的可用性和可恢复性应该是头等大事。

如果允许的话，由五个节点组成的etcd集群是最佳选择。 怎么了 因为您可以服务一个，并且同时承受失败。 对于生产级服务，即使只有一个主机管理程序可用，我们也建议最少由三个节点组成的集群。 除了覆盖多个访问区域的超大型安装之外，也不建议使用七个以上的节点。

托管etcd群集节点的最低建议是2GB RAM和8GB SSD硬盘。 通常，8GB的RAM和20GB的硬盘空间就足够了。 磁盘性能会影响故障后节点的恢复时间。 查看详细信息。

在特殊情况下，请考虑几个etcd集群

对于非常大的Kubernetes集群，请考虑对Kubernetes事件使用单独的etcd集群，以便太多事件不会影响核心的Kubernetes API服务。 使用Flannel网络时，配置保存在etcd中，版本要求可能与Kubernetes不同。 这会使etcd的备份变得复杂，因此我们建议使用专门用于法兰绒的单独etcd群集。

单主机部署

可访问性风险列表包括硬件，软件和人为因素。 如果限于一台主机，则使用冗余存储，纠错内存和双电源可以改善针对硬件故障的保护。 在物理主机上运行虚拟机监控程序可让您使用冗余软件组件，并增加与部署，更新和监视资源使用情况相关的运营优势。 即使在压力很大的情况下，行为仍可重复且可预测。 例如，即使您只允许从主服务启动单调，也应保护它们免于过载和资源耗尽，从而与应用程序的工作量竞争。 与Linux调度程序，cgroup，Kubernetes标志等中的优先级相比，虚拟机管理程序可以更高效，更易于使用。

如果主机资源允许，您可以部署三个etcd虚拟机。 每个VM必须由单独的物理存储设备支持，或使用冗余（镜像，RAID等）使用单独的存储部分。
如果您唯一的主机具有足够的资源来执行此任务，则服务器API，调度程序和控制器管理器的双冗余实例将是下一个升级。

单主机部署选项，从最不适合生产到最适合

型式	特点	结果
最低装备	Singleton etcd和主组件。	家庭实验室，不是所有生产级别。 多个单点故障（SPOF）。 恢复速度很慢，当存储丢失时，它完全不存在。
改善存储冗余	etcd单例和主组件，etcd存储是冗余的。	至少，您可以从存储设备故障中恢复。
管理级别冗余	没有虚拟机管理程序，静态Pod中有多个托管级别组件的实例。	已经出现了针对软件错误的防护措施，但是操作系统和容器启动环境仍然是灾难性的更新，具有相同的故障点。
添加虚拟机监控程序	在VM中运行三个冗余的受管级别实例。	可以防止软件错误和人为错误，并在安装，资源管理，监视和安全方面具有操作优势。 操作系统更新和容器启动环境的破坏性较小。 管理程序是唯一的单点故障。

双主机部署

对于两台主机，etcd的存储问题类似于单主机选项-您需要冗余。 最好运行三个encd实例。 看起来似乎不太直观，但是最好将所有etcd节点集中在一个主机上。 您不会通过在两台主机之间将它们除以2 + 1来提高可靠性-丢失具有大多数encd实例的节点将导致故障，无论它是2还是3的多数。如果主机不同，请将整个etcd群集放在更可靠的群集上。

建议您运行冗余API服务器，kube调度程序和kube-controller-managers。 它们应该在主机之间共享，以最大程度地减少容器启动环境，操作系统和硬件中发生故障的风险。

在物理主机上启动虚拟机监控程序层将使您能够使用冗余程序组件，从而提供资源管理。 它还具有定期维护的操作优势。

从最不适合生产到最适合生产的两个主机的部署选项

型式	特点	结果
最低装备	两台主机，无冗余存储。 Singleton etcd和主组件在同一主机上。	etcd-单点故障，在其他主服务上运行两个失败。 两个主机之间的共享会增加管理层故障的风险。 通过在一台主机上运行托管层而在另一台主机上运行应用程序工作负载来隔离资源的潜在好处。 如果存储丢失，将无法恢复。
改善存储冗余	Singleton etcd和master组件在同一主机上，etcd存储冗余。	至少，您可以从存储设备故障中恢复。
管理级别冗余	没有虚拟机管理程序，静态Pod中有多个托管级别组件的实例。 一台主机上的etcd集群，其他托管级别的组件是分开的。	在没有etcd的情况下，主机上的硬件故障，更新固件，操作系统和容器启动环境的损害较小。
向两个主机添加虚拟机监控程序	虚拟机中运行着三个冗余的管理级组件，一台主机上的etcd群集中，管理级组件是分开的。 应用程序工作负载可以驻留在两个VM节点上。	改进的应用程序负载隔离。 对操作系统和容器启动环境的更新破坏性较小。 如果虚拟机管理程序支持VM迁移，则硬件/固件的计划维护将无损。

部署到三台（或更多）主机

过渡到毫不妥协的生产级服务。 我们建议在三台主机之间拆分etcd。 一种硬件故障将减少可能的应用程序工作量，但不会导致完全的服务中断。

大型群集将需要更多实例。

启动虚拟机监控程序层可带来运营优势并改善应用程序工作负载的隔离。 这超出了本文的范围，但是在三台或更多台主机的级别上，可能会提供改进的功能（群集冗余共享存储，具有动态负载平衡器的资源管理，具有实时迁移和故障转移的自动状态监视）。

从最不适合生产到最适合生产的三个（或更多）主机的部署选项

型式	特点	结果
最低要求	三位主持人。 每个节点上的实例etcd。 在每个节点上掌握组件。	丢失节点会降低性能，但不会导致Kubernetes的故障。 恢复的可能性仍然存在。
向主机添加虚拟机监控程序	在etcd的三个主机上的虚拟机中，API服务器，调度程序和控制器管理器正在运行。 工作负载正在每个主机上的VM中运行。	增强了针对操作系统错误/容器/软件启动环境和人为错误的保护。 安装，升级，资源管理，监视和安全性的运营优势。

配置Kubernetes

必须保护主节点和工作节点免受过载和资源消耗。 系统管理程序功能可用于隔离关键组件并保留资源。 还有Kubernetes配置设置可以减慢诸如API调用速度之类的速度。 一些安装工具包和商业发行版可以解决这个问题，但是如果您自己部署Kubernetes，则默认设置可能不合适，尤其是对于较小的资源或太大的集群。

受管理级别的资源消耗与炉膛数量和炉膛流出速率相关。 大型和小型集群都将从修改后的kube-apiserver请求和内存减慢设置中受益。

应基于每个节点的合理支持的负载密度在工作节点上配置节点可分配的节点。 可以创建命名空间，以将工作节点的群集拆分为多个虚拟群集，这些群集具有CPU和内存的配额 。

安全性

每个Kubernetes集群都有一个根证书颁发机构（CA）。 必须生成并安装Controller Manager，API Server，Scheduler，kubelet客户端，kube-proxy和管理员证书。 如果您使用安装工具或发行版，则可能不必自己处理。 此处描述了手动过程。 如果您扩展或替换节点，则应该准备重新安装证书。

由于Kubernetes由API完全管理，因此必须控制和限制有权访问群集的人员的列表。 本文档中讨论了加密和身份验证选项。

Kubernetes应用程序工作负载基于容器映像。 您需要这些图像的来源和内容是可靠的。 几乎总是，这意味着您将在本地存储库中托管容器映像。 使用来自公共Internet的图像可能会导致可靠性和安全性问题。 您必须选择一个存储库，该存储库支持对图像进行签名，扫描安全性，控制对发送和下载图像的访问以及日志记录活动。

必须配置进程以支持主机，系统管理程序，OS6，Kubernetes和其他相关固件更新的使用。 版本监视对于支持审核是必需的。

建议：

• 增强托管级别组件的默认安全设置（例如， 阻止工作程序节点 ）；
• 使用壁炉安全政策 ;
• 考虑一下可用于您的网络解决方案的NetworkPolicy集成，包括跟踪，监视和故障排除；
• 使用RBAC做出授权决定；
• 考虑物理安全性，尤其是在部署到可能被忽略的外围或远程位置时。 添加存储加密以限制设备被盗的后果，并防止连接恶意设备（例如USB密钥）；
• 保护云提供商的文本凭据（访问密钥，令牌，密码等）。

Kubernetes 秘密对象适用于存储少量敏感数据。 它们存储在etcd中。 它们可以安全地用于存储Kubernetes API的凭据，但是有时工作负载或扩展集群本身需要更完整的解决方案。 如果您需要的不仅仅是内置机密对象，HashiCorp Vault项目就是一个受欢迎的解决方案。

灾难恢复和备份



通过使用多个主机和VM来实现冗余有助于减少某些类型的故障。 但是，诸如自然灾害，错误更新，黑客攻击，软件错误或人为错误之类的情况仍然可能导致崩溃。

生产部署的关键部分是对未来恢复的期望。

还需要注意的是，如果您需要在多个站点进行大规模复制部署，则可以重复使用您在恢复过程的设计，文档和自动化方面的部分投资。

在灾难恢复的要素中，值得注意的是备份（可能还有副本），替换，计划的过程，将执行此过程的人员以及定期培训。 Chaos Engineering的频繁测试练习和原理可以用来测试您的准备情况。

由于可用性要求，即使Internet崩溃，您可能也必须存储OS，Kubernetes组件和容器映像的本地副本才能进行恢复。 在“物理隔离”情况下部署替换主机和节点的能力提高了安全性并提高了部署速度。

所有Kubernetes对象都存储在etcd中。 在紧急情况下（例如，当所有主节点丢失时），定期备份etcd集群数据是恢复Kubernetes集群的重要元素。

etcd etcd . Kubernetes . , Kubernetes.

, Kubernetes etcd , - . , .

etcd. , , , , /. , . :

• : CA, API Server, Apiserver-kubelet-client, ServiceAccount, “Front proxy”, Front proxy;
• DNS;
• IP/;
• ;
• kubeconfig;
• LDAP ;
• .

Anti-affinity . , . , Kubernetes , . , , - . , .

stateful-, — Kubernetes (, SQL ). , , Kubernetes, roadmap feature request , , , Container Storage Interface (CSI). , - , , . , Kubernetes , , , Kubernetes .

stateful- (, Cassandra) , , . - Kubernetes ( -) .



( ) , , . , , .

, (, Ansible , BOSH , Chef , Juju , kubeadm , Puppet .). , . , , , , , , . , Git, .



, , — . 2 , — . — , .





— . - , Airbus A320 — . , . , .

, . , , , . Kubernetes , - , , (, FedEx, Amazon).

production-grade Kubernetes . . , , , , . , (, Kubernetes self-hosting，而不是静态炉膛）。如果有足够的兴趣，也许应该在以下文章中讨论它们。此外，由于Kubernetes改进的速度很高，如果您的搜索引擎在2019年以后找到这篇文章，则其中的某些材料可能已经过时了。

结束

至于随时恭候您的问题和意见，在这里，你可以去开房，以亚历山大·季托夫。