Kubernetes中的升级和失败域

Question

背景

我原计划使用Service Fabric（内部部署）进行服务和容器编排。但是，由于内部讨论，我正在给Kubernetes看一看。主要是因为它非常受欢迎。

Service Fabric具有称为“升级域”和“失败域”的概念。 A＆＃34;域名＆＃34;是一组主机节点。

在推出应用程序服务或容器更新时使用升级域。 Service Fabric通过一次只删除一个升级域来确保升级服务/容器仍然可用。 （更新Service Fabric群集软件本身时也会使用这些。）

失败域以类似的方式工作。我们的想法是创建故障域以与硬件故障组保持一致。 Service Fabric确保在每个故障域中都运行服务/容器实例。 （以便在硬件故障期间允许正常运行时间。）

问题

当我查看文档并听取Kubernetes上的播客时，我没有看到任何这些概念。它似乎只是托管容器（Pods）。我听过一些关于＆＃34;调度＆＃34;和＆＃34;标签＆＃34;。但它似乎只是手动配置pod的方式。

是否在Kubernetes中手动完成应用程序升级和容错？ （可能通过安排和/或标签）

或者是否有我缺少的功能？

Answer 1

  

A＆＃34;域名＆＃34;是一组主机节点。

不是那么简单，如果你说 ＆＃34; A＆＃39;域＆＃39;那就更准确了。是资源的逻辑分组＆＃34;。

要正确理解它，您必须首先了解大多数组件。我首先推荐这些读数：

• this docs中的虚拟机域。
• this docs
中的Service Fabric域

然后，我们可以从中获取一些观点：

• 节点不是虚拟机，节点在azure虚拟机之上运行。

  它们通常具有1：1映射，但在某些情况下，您可以使用5：1节点/ VM 映射，例如安装本地开发群集时。

  < / LI>

• Azure虚拟机具有更新域和故障域，服务结构节点具有升级域和故障域

  尽管他们看起来一样，但他们有不同之处：

  错误域名

  • VM Fault Domains是用于物理部署的隔离插槽，这意味着：电源，网络，磁盘等......它们受地区限制。
  • SF Fault Domains是用于应用程序部署的逻辑节点插槽，这意味着，当SF将应用程序部署到节点时，它将分布在不同的故障域上，以使它们可靠，大多数时候FD将映射到VM Fault Domains，但在复杂场景中，您可以将其映射到任何内容，例如，您可以将整个区域映射到单个SF FD。

  更新\升级域名

  • VM更新域是关于操作系统\硬件补丁和更新，单独的更新域将单独处理而不是同时更新，因此，当需要更新操作系统来关闭虚拟机时，他们将更新域按域名。较新的更新域数意味着更新期间将放下更多的计算机。
  • SF升级域使用类似的VM更新域方法，但重点关注服务和集群升级本身，一次关闭每个UD的UD，并在前一个UD成功时转移到下一个UD。
  • 在这两种情况下，您都可以将Update \ Upgrade调整为在升级期间可以放下vm \ nodes \ services的实例数（％）。因此，例如，如果您的服务在具有5个UD的群集上有100个实例，则SF将在时间更新20个服务，如果您将UD的数量增加到10，例如，实例数量将减少到10个实例，但是部署应用程序的时间将以相同的比例增加。

基于此，你可以看到FD＆amp;作为可靠部署插槽的矩阵，尽可能多地增加可靠性（通过权衡，例如所需的更新时间）。以下示例取自SF docs：

Service Fabric，开箱即用尝试将您的服务实例放在不同的FD \ UD上，这意味着，如果可能的话，它们将位于不同的FD \ UD上，否则它将找到另一个具有最少实例数的实例正在部署的服务。

关于Kubernetes：

在Kubernetes上，这些功能并非开箱即用，k8s具有zones的概念，但根据文档，它们受区域限制，不能跨越区域。

  

Kubernetes将自动将pod分布在复制控制器或服务中，跨越单区域群集中的节点（以减少故障的影响）。对于多区域群集，此扩展行为跨区域扩展（以减少区域故障的影响）。这是通过SelectorSpreadPriority实现的。

     

这是尽力而为的布局，因此如果群集中的区域是异构的（例如，不同数量的节点，不同类型的节点或不同的pod资源要求），这可能会阻止您的Pod跨区域的均等传播。如果需要，您可以使用同质区域（相同数量和类型的节点）来减少不均匀传播的可能性。

与FD不同，但是是一个非常相似的概念。

要获得与SF类似的结果，将需要跨区域部署群集或将节点映射到VM FD \ UD，以便它们在SF上充当节点。将标签添加到节点以标识这些域。您还需要在不同FD上的节点上创建NodeType标签，以便您可以用于在分隔节点上部署pod。

例如：

• Node01 ：FD01：NodeType = FrontEnd
• Node02 ：FD02：NodeType = FrontEnd
• Node03 ：FD03：NodeType = FrontEnd
• Node04 ：FD01：NodeType = BackEnd
• Node05 ：FD02：NodeType = BackEnd

部署应用程序时，您应该使用affinity功能将POD分配给节点，在这种情况下，您的服务将具有：

• 所需亲和力至 NodeType = FrontEnd
• 首选AntiAfinity 至 ContainerName = [本身]

使用这些设置，使用亲和力和反亲和力k8s将尝试将容器的副本\实例放置在不同的节点上，并且节点将已经由由NoteType标签分隔的FD \区域分隔，然后k8s将像SF那样处理滚动更新。

由于首选反关联规则，k8s会尽力平衡这些节点，如果没有有效的节点可用，它将开始在已包含相同容器实例的节点上添加更多实例，

<强>结论

这是一项额外的工作，但与目前在其他解决方案上使用的内容没有多大差别。 这里主要关注的是在FD \ Zones上配置节点，将节点放在右侧FD上后，其余节点将顺利运行。

在SF上，当您在Azure上部署群集时，您不必担心这一点，但如果您从头开始执行此操作，则需要做大工作，甚至比k8更大。

注意：如果您使用AKS，它将跨可用性集分配节点（设置指定VM故障域和更新域）。目前，根据this post，AKS不为您提供区域分发，因此如果您需要这种分发级别，则必须从头开始。

Answer 2

来自文档1，2，3：

• 流程健康检查 最简单的健康检查形式只是过程级健康检查。如果容器进程仍在运行，Kubelet会不断询问Docker守护程序，如果没有，则重新启动容器进程。在目前为止运行的所有Kubernetes示例中，实际上已经启用了此运行状况检查。它适用于在Kubernetes

中运行的每个容器

• Kubernetes支持用户实施的应用程序运行状况检查。这些检查由Kubelet执行，以确保您的应用程序正确运行，以获得您提供的“正确”定义。

目前，您可以选择三种类型的应用程序运行状况检查：

1. HTTP运行状况检查 - Kubelet将调用Web挂钩。如果它返回200到399之间，则认为是成功，否则失败。请参阅此处的健康检查示例。
2. Container Exec - Kubelet将在容器内执行命令。如果它以状态0退出，则认为是成功的。请参阅此处的健康检查示例。

3. TCP套接字 - Kubelet将尝试打开容器的套接字。如果它可以建立连接，则容器被认为是健康的，如果它不能被认为是失败的话。 在所有情况下，如果Kubelet发现故障，则重新启动容器。

   • 节点运行状况检查

如果[节点]的就绪状态的状态为“未知”或“假”超过pod-eviction-timeout，则会将参数传递给kube-controller-manager和所有Pods on节点控制器计划将节点删除。默认逐出超时持续时间为五分钟。在某些情况下，当节点无法访问时，apiserver无法与其上的kubelet通信。删除pod的决定无法传送到kubelet，直到它与apiserver重新建立通信。与此同时，计划删除的pod可能会继续在分区节点上运行

• 应用程序升级

用户希望应用程序始终可用，并且开发人员应该每天多次部署新版本的应用程序。在Kubernetes中，这是通过滚动更新完成的。滚动更新允许通过使用新的实例逐步更新Pods实例来实现部署的更新，从而实现零停机。新的Pod将在具有可用资源的节点上进行安排。

Answer 3

这些抽象目前不存在于kubernetes中，尽管通常可以以自动方式实现所需的行为。

kubernetes的元模型涉及代理（称为控制器和操作员）持续监视集群上的事件和配置，并逐渐将集群状态与Controller的声明性配置进行协调。突然丢失节点托管Pod将导致从服务和ReplicationControllers中删除与丢失的Pod相对应的IP，以便那些Pod在其他节点上启动新版本，从而确保满足协同和反调度约束。

同样，应用程序升级通常是通过更改部署来实现的，这会导致新的Pod被调度，旧的Pod将以自动，渐进的方式进行计划。

现在可以使用CustomResourceDefinitions进行自定义声明配置，因此该模型是可扩展的。底层原语和机器可供有人引入由自定义操作员管理的顶级声明性抽象，如FailureDomains和UpgradeDomains。

kube生态系统如此巨大，移动得如此之快，以至于这样的事情很可能会出现，竞争对手的概念也可能会遇到这种情况。

考虑采用的工厂所有者的底线是Kubernetes仍然是一个工具世界。有大量的工具，以及类似的大量未完成的产品。