创建高度可用的群集策略

通过 IBM Cloud® Kubernetes Service 设计标准集群，以实现应用程序的最大可用性和容量。 利用内置功能，提高集群的高可用性，并在集群中的某个组件发生故障时，防止应用程序出现停机。 但是，要想知道你的集群设置必须能支持你的工作负载，这并不是一门精确的科学。 您可能需要测试其他配置并进行相应调整。

高可用性（HA）是 IT 基础设施中的一个核心领域，旨在确保您的应用程序即使在发生部分或全部站点故障后仍能持续运行。 高可用性的主要目的是消除 IT 基础架构中的潜在故障点。 例如，可以通过添加冗余并设置故障转移机制来准备好应对一个系统发生故障的情况。 请参见 IBM Cloud 如何确保高可用性和灾难恢复。

要开始规划和调整集群大小，请在创建集群前查看这些决策点。

决定创建多少个群集

跨多个工作程序节点、专区和集群分布应用程序时，用户不太可能会遇到中断。 内置功能（例如负载均衡和隔离）可在主机、网络或应用程序发生潜在故障时更快恢复。

集群的高可用性
集群的高可用性*
的高可用性* 集群的高可用性* 集群的高可用性

创建集群的数量取决于工作量、公司政策和法规、业务要求、与客户签订的服务级别协议、想要使用的资源以及想要对计算资源做什么。

  • 多个集群：多个集群的管理通常较为复杂，但有助于您实现以下重要目标。

    • 符合要求隔离工作负载的安全策略。
    • 测试应用程序如何在不同版本的 Kubernetes 或其他集群软件（如 Calico）中运行。
    • 为不同地理区域的用户提供更高的性能。
    • 在群集实例级别配置访问权限，而不是在命名空间级别定制和管理多个 RBAC 策略，从而简化用户访问，控制群集内的访问权限。
    • 减少工作节点的数量。 扩展虚拟机的网络带宽约为 1000 Mbps。 如果您需要在集群中部署数百个工作节点，可以将配置拆分为多个节点较少的集群，或者订购裸机节点。
    • 允许更多 服务集成，例如 5,000 多个服务。
    • 为应用程序提供更高的可用性。 与在多区域集群中使用 3 个区域类似，您可以通过在不同区域中部署三个集群，从而为您的应用提供更高的可用性。
    • 通过购买更小型的机器来处理您的工作量，从而降低成本。

  • 具有更多工作节点的一个群集：较少的群集可帮助您减少操作工作量和每个群集的固定资源成本。 您可以在一个集群中添加工作者池，为应用程序和服务组件提供不同类型的计算资源，而不是创建更多集群。 在开发应用程序时，应用程序使用的资源位于同一专区中，或者在多专区中以其他方式密切关联，以便您可以对等待时间、带宽或相关故障进行假设。 不过，当您只有一个集群时，利用命名空间、资源配额和标签来管理集群就显得尤为重要。

确定需要多少个地点

集群既可以在单个位置的工作节点上分发副本，也可以在多个位置的工作节点上分发副本。 这一选择会影响下一节中的群集类型。

将工作负载分布在三个区域，可确保在一个区域不可用的情况下，应用程序的高可用性。 您必须让工作节点均匀分布在所有三个可用性区域，以满足 IBM Cloud 服务级别协议 HA 配置的要求。

专区故障会影响所有物理计算主机和 NFS 存储器。 故障包括电源、散热、联网或存储中断，以及洪水、地震和飓风等自然灾害。 为防止区域故障，您必须在两个不同的区域建立集群，并通过外部负载平衡器实现负载平衡；在多区域位置创建集群，将主服务器分散到各个区域；或者考虑在另一个区域建立第二个集群。

多专区集群

经典 VPC

多区群集可将工作负载分配到多个工作节点和区域，从而为区域故障提供额外保护。 工作节点会自动部署三个副本，分布在多个区域。 如果整个区域发生故障，您的工作负载会被调度到其他区域的工作节点上，从而保护您的应用程序免受故障影响。

每个区域都设置有高可用性负载均衡器，可从特定于区域的 API 端点进行访问。 负载均衡器用于将入局和出局请求路由到区域专区中的集群。 整个区域发生故障的可能性较低。 但是，要应对此故障，可以在不同区域中设置多个集群，并使用外部负载均衡器来连接这些集群。 如果某个区域完全发生故障，另一个区域的集群可以接管该工作负载。

例如，您将多区域群集 部署在一个都会区（如 sydney），三个副本将自动分布在都会区的三个区域（如 au-syd-1、au-syd-2 和 au-syd-3）。 如果一个专区中的资源停止运行，集群工作负载仍会继续在其他专区中运行。

多区域集群需要多种云资源，并且根据应用程序的情况，该集群可能会十分复杂且昂贵。 请检查您是否需要多区域设置，或者是否可以容忍潜在的服务中断。 如果您想搭建一个多区域集群，请确保您的应用和数据可以在其他区域托管，并且您的应用能够处理全球数据复制。

使用负载平衡器连接多个集群

经典 VPC

为了防止主控失效，您可以在一个区域内的不同区域创建多个群集，并用全局负载平衡器将它们连接起来。 如果您必须在经典数据中心配置一个只有一个区域的群集，但仍希望获得多区域可用性的优势，则此选项非常有用。

要使用全局负载平衡器连接多个群集，必须使用公共网络连接设置群集，并且必须通过 Ingress、routes 或 Kubernetes负载平衡器服务 公开您的应用程序。

要在多个群集之间平衡工作负载，必须通过 设置全局负载平衡器 至 Cloud Internet Services (CIS) 将 ALB 或负载平衡器服务的公共 IP 地址添加到域中。 通过添加这些 IP 地址，可以在集群之间路由入局流量。

要使全局负载均衡器检测其中一个集群是否不可用，请考虑向每个 IP 地址添加基于 ping 操作的运行状况检查。 设置此检查后，DNS 提供程序会定期对添加到域的 IP 地址执行 ping 操作。 如果一个 IP 地址变为不可用，那么不会再将流量发送到此 IP 地址。 但是，Kubernetes 不会在可用集群中工作程序节点上自动重新启动不可用集群中的 pod。 如果您希望 Kubernetes 在可用集群中自动重启 Pod，请考虑配置一个多区域集群。

单专区集群

经典

工作节点分布在单个区域内的不同物理主机上。 该选项可防止某些中断，如主站更新期间的中断，而且更易于管理。 但是，如果整个区域发生故障，它也无法保护您的应用程序。 如果后来发现可用性是个问题，在某些地点部署的单区群集可以在以后转换为多区群集。

如果您的集群在创建时将所有工作节点都部署在同一区域内，则经典集群的 Kubernetes 主节点具有高可用性，并为API主服务器、etcd、调度器和控制器管理器分别配置了独立的物理主机，以防范主节点更新期间可能发生的故障。 您可以向单区群集添加额外的工作节点，以提高可用性，并在一个工作节点出现故障时提供保护。

如果一个工作程序节点停止运行，可用工作程序节点上的应用程序实例会继续运行。 Kubernetes 会自动重新安排不可用工作程序节点中的 pod，以确保应用程序的性能和容量。 为确保您的 Pod 在各工作节点上均匀分布，请实现 Pod 亲和性。

选择群组类型

可供您使用的工作程序节点类型模板和隔离级别取决于要使用的容器平台、集群类型、要使用的基础架构提供者以及要创建集群的 IBM Cloud Kubernetes Service 位置。 您可以选择经典、VPC 或 Satellite 群集。 您需要的集群类型取决于您对集群数量和位置所做的决定。

标准集群中工作节点的硬件选项
标准集群中工作节点的硬件选项* 标准
中工作节点的硬件选项

VPC 集群
工作节点作为虚拟服务器实例部署在 VPC 基础设施上。 VPC 是新建集群的推荐基础设施类型。 它默认提供网络隔离功能，并支持 IBM Cloud Kubernetes Service 的最新功能，包括专用主机和“默认安全”功能。
Satellite 集群
工作节点部署在您自己的基础设施上，包括本地硬件或其他云服务提供商（如 AWS、Azure 和 GCP ）中的虚拟机。 当您需要在 IBM Cloud 数据中心之外运行由 IBM Cloud 管理的集群时，请使用 Satellite。
经典集群
工作节点部署在 IBM Cloud 经典基础设施上的虚拟机或裸机上。 如果您需要裸机工作节点、软件定义存储（SDS）实例，或需要连接到现有的传统基础设施资源，请使用“经典”模式。

为群集选择操作系统

您可使用的操作系统取决于您选择的群集类型。

Ubuntu 24
更多信息，请参阅 Ubuntu 24.04 发行说明。 请注意，在 Ubuntu 24 中，NTP 使用 timesyncd，相关命令可能会更新。

要迁移到新的操作系统了吗？ 请参阅 迁移到新版本 Ubuntu。

确定群组命名策略

请考虑为集群提供在帐户中的各资源组和区域中唯一的名称，以避免发生命名冲突。 创建群集后不能重新命名。

决定每个群集有多少个工作节点

您为群集设置的可用性级别会影响 IBM Cloud HA 服务级别协议条款 的覆盖范围。 例如，要获得 SLA 条款规定的完全 HA 覆盖，您必须建立一个多区群集，其中至少有 6 个工作节点，每个区两个工作节点，平均分布在三个区中。

集群中的工作程序节点总数决定了可用于集群中应用程序的计算容量。 您可以在集群中配置多个工作节点，从而在工作节点发生故障时保护您的系统。 工作节点故障可能包括硬件故障（例如电源、散热或网络问题），以及 VM 本身出现的问题。

  • 多区域集群 Classic VPC：计划每个区域至少部署两个工作节点，因此三个区域共计六个节点。 此外，将集群的总容量计划为至少等于总工作负载所需容量的 150%，这样，如果一个专区停止运行，您仍有资源可用于维持工作负载。

  • 单区域集群请确保您的集群中至少有三个工作节点。 此外，需要在集群中提供可容纳 1 个额外节点的 CPU 和内存容量。 如果您的应用所需的资源少于工作节点上可用的资源，您可以将部署到单个工作节点的 Pod 数量限制在一定范围内。

请记住：

  • 您可以试用 群集自动分压器，以确保您始终有足够的工作节点来应对工作负载。
  • Kubernetes 限制了在一个集群中可以拥有的最大工作程序节点数。 有关详细信息，请参阅 “工作节点和Pod配额”部分。

选择工作节点类型

工作节点是在物理硬件上运行的 VM。 工作程序节点类型模板描述了供应工作程序节点时获取的计算资源，例如 CPU、内存和磁盘容量。 相同类型模板的工作程序节点会分组成工作程序节点池。

在选择集群类型时，您已经考虑过工作节点的风味位置和机器类型会如何影响您的决定。 在选择工作节点时，请考虑以下几点。

  • 租用：根据您所需的硬件隔离级别，虚拟工作站节点可设置为多个 IBM 客户共享（多租户）或仅为您专用（单租户）节点。 裸机始终设置为专用。 在决定选择共享节点还是专用节点时，您可能需要咨询法律部门，讨论您的应用环境所需的基础设施隔离程度和合规要求。

    • 共享：物理资源（如 CPU 和内存）在部署到同一台物理硬件上的所有虚拟机之间共享。 要确保每个虚拟机都能独立运行，虚拟机监视器（也称为系统管理程序）会将物理资源分段成隔离的实体，并将其作为专用资源分配给虚拟机（系统管理程序隔离）。 共享节点通常比专用节点更便宜，因为底层硬件的开销由多个客户分担。
    • 专用：所有物理资源仅供您使用。 您可以将多个工作程序节点作为虚拟机部署在同一物理主机上。 与多租户设置类似，系统管理程序也会确保每个工作程序节点在可用物理资源中获得应有的份额。

  • 机器类型：您可以选择多种机器类型。

    • 虚拟机：使用虚拟机可以获得更大的灵活性、更快的配置时间、更多的自动扩展功能和更具成本效益的价格。 您可以将 VM 用于最通用的用例，例如测试和开发环境、编译打包和生产环境、微服务以及业务应用程序。 然而，这在性能上存在取舍。

    • 裸机（物理）服务器：如果您需要针对数据密集型或内存密集型工作负载进行高性能计算，建议考虑使用裸机工作节点构建集群。 由于您可以完全控制工作负载的隔离和资源消耗，因此您可以使用裸机为您的环境实现 HIPAA 和 PCI 合规性。 通过裸机，您可以直接访问机器上的物理资源，例如内存或 CPU。 此设置无需虚拟机系统管理程序将物理资源分配给在主机上运行的虚拟机。 相反，裸机服务器的所有资源都专用于该工作进程，因此您无需担心“嘈杂的邻居”会共享资源或拖慢性能。 物理类型模板的本地存储器大于虚拟类型模板，并且某些类型模板具有 RAID，可提高数据可用性。 工作节点上的本地存储仅用于短期处理，当您更新或重新加载工作节点时，主磁盘和辅助磁盘上的数据将被清除。 提供适用于经典集群和 VPC 裸机配置的裸机工作者。

      裸机工作节点的计费方式因基础设施类型而异。 经典裸机服务器的费用按月结算。 如果您在当月结束前取消经典裸机服务器，则需支付至当月底的费用。 在您订购或取消经典裸机服务器后，相关流程需在您的 IBM Cloud 基础设施账户中手动完成，因此可能需要超过一个工作日才能完成。 VPC 裸机服务器的计费按小时计算，且无最低使用期限要求。

    • SDS 机器：软件定义存储 (SDS) 具有额外的原始磁盘，用于物理本地存储。 与主本地磁盘和辅助本地磁盘不同，这些原始磁盘在工作节点更新或重新加载时不会被擦除。 因为数据与计算节点并存，因此 SDS 机器适合高性能工作负载。 软件定义存储配置仅适用于经典集群，VPC 集群不支持该功能。

      由于您可以完全控制工作负载的隔离和资源消耗，因此您可以使用 SDS 机器为您的环境实现 HIPAA 和 PCI 合规性。

      在下列情况下，通常使用 SDS 机器： * 如果您使用的是 SDS 插件，例如 Portworx，请使用 SDS 机器。 * 如果您的应用程序是 StatefulSet 需要本地存储的，您可以使用 SDS 设备并配置 Kubernetes 本地持久化卷。 * 如果具有需要其他原始本地存储器的定制应用程序。

  • 成本：通常情况下，高负载的工作负载更适合在裸机物理服务器上运行；而对于注重成本效益的测试和开发工作，您可以选择在共享或专用硬件上的虚拟机。

  • 位置：决定要在哪些地点建立群集。 您希望在哪里使用也可能会影响到您需要多少个集群或集群的类型。 例如，如果您知道您需要的地点在蒙特利尔，那么这将有助于缩小您的选择范围。 查看 可用地点。

  • 规模：较大的节点可能比较小的节点更具成本效益，特别是对于那些在高性能机器上处理时能提高效率的工作负载而言。 但是，如果一个大型工作节点发生故障，您需要确保集群具有足够的容量，能够将所有工作负载 Pod 安全地重新调度到集群中的其他工作节点上。 较小的工人节点可以帮助您安全扩展。 了解有关容量的更多信息。

  • GPU：您可以使用 GPU 机器加快计算密集型工作负载（如人工智能、机器学习、推理等）所需的处理时间。

  • 存储：每个 VM 都附带一个用于存储 VM 运行所需信息的磁盘，例如操作系统文件系统、容器运行时以及 kubelet。 工作程序节点上的本地存储器仅用于短期处理，删除、重新装入、替换或更新工作程序节点时将擦除存储磁盘。 此外，经典和 VPC 基础架构在磁盘设置方面有所不同。

    • 经典 VM：经典 VM 有两个连接的磁盘。 主存储磁盘为操作系统文件系统预留了 25 GB 空间，辅助存储磁盘为容器运行时和 kubelet 等数据预留了 100 GB 空间。 为了确保可靠性，主存储卷和辅助存储卷采用本地磁盘，而非存储区域网络（SAN）。 可靠性优势包括在将字节序列化到本地磁盘时可提高吞吐量，以及减少因网络故障而导致的文件系统降级。 辅助磁盘默认处于加密状态。
    • VPC 计算虚拟机：VPC 虚拟机有一个主磁盘，该磁盘是一个通过网络挂载的块存储卷。 存储层未与其他联网层分隔，并且网络和存储流量在同一网络上路由。 主存储磁盘用于存储操作系统文件系统、容器运行时和 kubelet 等数据，并且缺省情况下已加密。 对于 VPC 群集，您还可以在工作节点上配置辅助磁盘。 该可选磁盘已分配到您的账户中，您可以在 VPC 控制台中查看它们。 这些磁盘的费用与每个工人的费用是分开的，在账单上显示为不同的细列项目。 这些二级流量也会计入您账户的配额使用量。 为防止默认 pod 被驱逐，Kubernetes 数据磁盘（经典中为辅助磁盘，VPC 中为主启动磁盘）的 10% 将保留给系统组件。

    在有状态应用程序中，数据在保持应用程序正常启动并运行方面起着重要作用。 请确保您的数据具有高可用性，以便可以从潜在故障中恢复。 在 IBM Cloud Kubernetes Service 中，可以从多个选项中进行选择来持久存储数据。 例如，可以使用 Kubernetes 本机持久卷来供应 NFS 存储器，也可以使用 IBM Cloud 数据库服务来存储数据。 如需了解更多信息，请参阅《 规划高可用性数据 》。

    选择一种配置（或机型），并确保其存储配置能够满足您的工作负载需求。 一些类型模板具有以下磁盘和存储配置的组合。 例如，一些类型模板可能具有一个 SATA 主磁盘以及一个原始 SSD 辅助磁盘。

有关可用风味的列表，请参阅 VPC 风味 或 经典风味。

确定资源的工作节点容量

要充分发挥工作节点的性能，请在设置资源时考虑以下几点：

  • 考虑您的应用程序正在执行的任务：首先将应用程序的大小与一个可用工作节点的容量相匹配。 此外，还应考虑诸如应用是否会加载大尺寸或大量图片等问题，因为这些图片可能会占用工作节点上的本地存储空间。

  • 保持核心力量：每台机器都有一定数量的核心。 根据应用程序的工作负载，为每个核心的 pod 数设置限制，例如 10 个。

  • 避免节点过载：将工作节点的利用率保持在75%左右，以便为可能需要调度的其他Pod预留空间。 如果应用程序需要的资源超过工作程序节点上的可用资源，请使用可以满足这些需求的其他工作程序节点类型模板。 根据应用程序的工作负载，为每个节点的 pod 数设置限制，例如 40 个。

  • 选择服务：在考虑创建多少个群集时，您决定包含多少个服务集成？ 这些集成服务和附加组件可能会启动消耗集群资源并影响集群资源的 Pod。

  • 应用程序副本数：要确定所需的工作程序节点数，您还可以考虑要运行的应用程序副本数。 例如，如果您知道工作负载需要 32 个 CPU 核心，并且计划运行 16 个应用程序副本，那么每个副本 pod 需要 2 个 CPU 核心。 如果希望每个工作程序节点仅运行一个应用程序 pod，那么可以为集群类型订购相应数量的工作程序节点以支持此配置。

  • 为运行时需求留出空间：工作节点必须预留一定量的 CPU 和内存资源，以运行操作系统或容器运行时等所需组件。

    不支持保留容量和保留实例。

选择在群集中创建多少个命名空间

如果您有共享集群的多个团队和项目，请设置多个名称空间。 命名空间是使用 资源配额和 默认限制来划分群集资源的一种方法。 创建新的名称空间时，请确保设置正确的 RBAC 策略来控制访问权。 如需了解更多信息，请参阅《 Kubernetes 》文档中的 “共享带命名空间的集群” 部分。

如果您有一个小型集群、数十个用户以及类似的资源（例如，同一软件的不同版本），那么可能并不需要多个名称空间。 您可以改为使用标签。

在 容器隔离和安全性 中查看有关此决定的安全信息。

为命名空间建立资源请求和限制

为了确保每个团队都拥有在集群中部署服务和运行应用所需的资源，您必须为每个命名空间设置 资源配额。 资源配额决定了部署限制，例如您可以部署的 Kubernetes 资源数量，以及这些资源可消耗的CPU和内存量。 设置配额后，用户必须在其部署中包含资源请求和限制。

创建部署时，还应对其进行限制，确保应用的 Pod 仅部署在资源组合最优的机器上。 例如，您可能希望将数据库应用程序限制为部署到具有大容量本地磁盘存储器的裸机机器，如 md1c.28x512.4x4tb。

让您的应用程序也具有高可用性

根据设计，容器和 pod 的生存时间短，并且可能会意外发生故障。 例如，如果应用程序中发生错误，那么容器或 pod 可能会崩溃。 为了确保应用程序具有高可用性，您必须确保拥有足够的实例来处理工作负载，并预留额外的实例以应对故障情况。 您可以通过设置 自动缩放 来确保有足够的实例。

后续步骤

要继续规划过程，请在 VPC 群集联网 和 Classic 群集联网 之间进行选择。 如果您已准备好开始创建群集，请首先 准备您的账户以创建群集。