教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载本文以 practice/federation.md 为核心骨架结合本仓库 concepts/multicluster.md 与images/目录下的架构图系统讲解 Kubernetes 集群联邦Cluster Federation的演进脉络、KubeFedFederation v2的核心 API 组与 CRD 机制、跨集群服务发现与 DNS 解析流程以及 ReplicaSchedulingPreference 副本编排策略。读完本文你将理解为什么需要多集群、如何确定集群数量、KubeFed 如何通过 Template/Placement/Override 三大构件联邦任意资源并能直接套用文中的 YAML 配置示例搭建自己的联邦服务与跨集群 DNS。为什么要使用集群联邦Kubernetes 从 1.8 版本起就声称单集群最多可支持 5000 个节点和 15 万个 Pod但很少有公司会部署如此庞大的单集群。在实际场景中我们常因低延迟、故障隔离、可伸缩性或混合云等原因部署多个集群又希望将它们统一管理这时就需要集群联邦Federation。Federation 使管理多个集群变得简单它通过两个主要构建模块实现跨集群同步资源Federation 提供在多个集群中保持资源同步的能力。例如可以保证同一个 Deployment 在多个集群中存在。跨集群服务发现Federation 提供自动配置 DNS 服务以及在所有集群后端上进行负载均衡的能力。例如可以提供一个全局 VIP 或 DNS 记录通过它可以访问多个集群后端。Federation 还可以提供一些其它用例高可用通过在集群间分布负载并自动配置 DNS 服务和负载均衡federation 最大限度地减少集群故障的影响。避免厂商锁定通过更简单的跨集群应用迁移方式federation 可以防止集群厂商锁定。需要明确的是Federation 对于单个集群没有用处。基于下面这些原因你可能需要多个集群低延迟通过在多个区域部署集群可以最大限度减少区域近端用户的延迟。故障隔离拥有多个小集群可能比单个大集群更利于故障隔离例如在云服务提供商的不同可用区中部署多个集群。可伸缩性单个集群有可伸缩性限制对大多数用户这不是典型场景更多细节可参考 Kubernetes 社区的 SIG Scalability goals 文档。混合云你可以在不同的云服务提供商或本地数据中心中拥有多个集群。本仓库 concepts/multicluster.md 对多集群管理做了同样的归纳多集群是在多个 Kubernetes 集群上或跨集群部署应用的策略目的是提高可用性、隔离性和可扩展性同时有助于遵守不同地域或认证的法规要求并可提升软件交付的速度与安全性例如让单个开发团队将应用部署到隔离集群中并有选择地暴露哪些服务可用于测试和发布。警告虽然 federation 有很多吸引人的使用案例但也有一些注意事项增加网络带宽和成本federation 控制平面会监控所有集群以确保当前状态符合预期。如果集群运行在云服务提供商的不同区域或不同的云服务提供商上这将导致明显的网络成本增加。减少跨集群隔离federation 控制平面中的 bug 可能影响所有集群。通过在 federation 中实现最少的逻辑可以缓解这种情况——只要有可能它就将尽力把工作委托给 Kubernetes 集群中的控制平面。这种设计和实现在安全性及避免多集群停止运行上也有考量。成熟度federation 项目相对较新并非所有资源都可用许多仍处于 alpha 状态。混合云能力Kubernetes 集群 federation 可以包含运行在不同云服务提供商例如 Google Cloud、AWS及本地例如在 OpenStack 上的集群。你只需要按需在合适的云服务提供商或地点创建集群然后向 Federation API Server 注册每个集群的 API endpoint 和凭据即可。此后你的 API 资源就可以跨越不同的集群和云服务提供商。单个集群范围与集群数量规划在诸如 Google Compute Engine 或 Amazon Web Services 等 IaaS 服务提供商中虚拟机存在于区域Zone或可用区Availability Zone上。官方建议 Kubernetes 集群中的所有虚拟机应位于相同的可用区因为与拥有单个全局 Kubernetes 集群相比单点故障更少与跨可用区集群相比推测单区域集群的可用性属性更容易Kubernetes 开发者在设计系统时例如对延迟、带宽或相关故障进行假设会假设所有机器位于一个单一数据中心或以其它方式紧密连接。在每个可用区同时拥有多个集群也是可以的但总体上少一点更好。选择较少集群的理由是某些情况下在一个集群中拥有更多节点可以改进 Pod 的装箱打包减少资源碎片减少运维开销尽管随着运维工具和流程的成熟这一优势已逐渐减少减少每个集群固定资源成本的开销例如 apiserver 虚拟机但对于大中型集群的整体集群成本来说占比很小。拥有多个集群的原因则包括严格的安全策略要求将一类工作与另一类工作隔离可参见分区集群 Partitioning Clusters 的思路对新的 Kubernetes 发行版或其它集群软件进行灰度测试。选择正确的集群数量Kubernetes 集群数量的选择可能是一个相对静态的决策只是偶尔需要重新设定相比之下集群的节点数量和 service 的 pod 数量会依据负载情况和增长经常变化。要选择集群数量可遵循以下三步确定区域数量R首先确定使用哪些区域以便为所有终端用户提供足够低的延迟来运行 Kubernetes 服务。如果使用内容分发网络CDN则 CDN 托管内容的时延要求不需要考虑。法律问题也可能影响这一选择。例如拥有全球客户群的公司可能会决定在美国、欧盟、亚太和南亚地区拥有集群。确定可容忍的不可用集群数U决定在整体仍然可用的前提下可以同时有多少集群不可用。如果你不能确定那么 1 是一个不错的选择。计算集群数量如果在集群故障时允许负载均衡将流量引导到任何区域则至少需要有比R或U 1更大的集群数量如果不行例如希望在集群故障时对所有用户确保低延迟则需要数量为R * (U 1)的集群R个区域每个区域中有U 1个集群。无论如何请尝试将每个集群放在不同的区域中。最后如果你的任何集群需要比 Kubernetes 集群最大建议节点数更多的节点那么你可能需要更多集群——Kubernetes v1.3 支持最多 1000 个节点的集群v1.8 支持最多 5000 个节点的集群。Kubernetes 集群联邦的演进从 Federation v1 到 v2Kubernetes 集群联邦的演进由 SIG Multicluster 推动Federation 是 Kubernetes 的一个子项目。该项目最初选择重用 Kubernetes API以消除现有 Kubernetes 用户的任何附加使用复杂性但这种方式最终被证明行不通原因包括在集群层面重新实施 Kubernetes API 的困难因为 Federation 的特定扩展存储在注释annotation中由于 Kubernetes API 的 1:1 仿真Federation 类型、放置placement和调节reconciliation的灵活性有限没有固定的 GA 路径API 成熟度普遍混乱——例如 Deployment 在 Kubernetes 中是 GA但在 Federation v1 中甚至不是 Beta。随着 Federation 特定的 API 架构和社区的努力这些想法进一步发展演进出Federation v2。请注意Federation V1 版本已经归档不再维护和更新官方也不再推荐继续使用。要了解 Federation v2 的更多资料可关注 kubefed 项目Kubernetes SIGs 下的 KubeFed 仓库。将任意资源联合起来联邦的主要目标之一是能够定义 API 和 API 组其中包含联邦任何给定 Kubernetes 资源所需的基本原则。这一点至关重要因为 CRDCustomResourceDefinition已经成为扩展 Kubernetes API 的主流方式。Multicluster SIG 得出了 Federation API 和 API 组的共同定义即一种将规范的Kubernetes API 资源分配到不同集群的机制。最简单的分布形式可以想象为这种规范的 Kubernetes API 资源在联邦集群中的简单传播。除了这种简单传播之外有心的读者自然可以看出更复杂的机制。在定义 Federation API 构建模块的历程中最早期的目标演化为能够创建一个简单的联邦也就是任何 Kubernetes 资源或 CRD 的简单传播几乎不需要编写代码。随后核心 API 组进一步定义了构件即每个给定的 Kubernetes 资源对应一个Template资源、一个Placement资源和一个Override资源一个TypeConfig用于指定给定资源的同步或不同步以及执行同步的相关控制器。更进一步的架构还支持分层行为更高级别的 Federation API 消耗这些核心构件而用户能够消耗整个或部分 API 和相关控制器。最后这种架构还允许用户编写额外的控制器或用自己的控制器替换现有的参考控制器reference controller以执行所需的行为。轻松地联合任意 Kubernetes 资源加上解耦的 API分为构件 API、更高层次的 API 和可能的用户预期类型使得不同的用户可以消费部分 API 并编写控制器组成特定解决方案——这为 Federation v2 提供了令人信服的案例。联邦服务与跨集群服务发现Kubernetes 服务在构建微服务架构时非常有用。人们明显希望跨越集群、可用区、区域和云的边界来部署服务。跨集群服务提供了地理分布实现混合云和多云场景并提高了超越单一集群部署的高可用性水平。希望其服务跨越一个或多个可能是远程集群的客户需要在集群内外以一致的方式提供服务。Federated Service 的核心包含四部分一个 TemplateKubernetes 服务的定义、一个 Placement部署到哪个集群、一个 Override在特定集群中的可选变化和一个 ServiceDNSRecord指定如何发现它的细节。注意联邦服务必须是LoadBalancer 类型以便它可以跨集群发现。Pod 如何发现联邦服务默认情况下Kubernetes 集群预先配置了集群本地 DNS 服务器以及智能构建的 DNS 搜索路径它们共同确保了由 pod 内部运行的软件发出的myservice、myservice.mynamespace或some-other-service.other-namespace等 DNS 查询会自动扩展并正确解析到本地集群中运行的服务的相应 IP。随着联邦服务和跨集群服务发现的引入这个概念被扩展到全局——覆盖你的集群联邦中所有集群中运行的 Kubernetes 服务。为了利用这个扩展的范围需要使用一个稍微不同的 DNS 名称例如myservice.mynamespace.myfederation来解析联邦服务。使用不同的 DNS 名还可以避免现有的应用意外地穿越区域网络而产生不必要的网络费用或延迟。让我们看一个使用名为 nginx 的服务的例子在us-central1-a可用区的集群中的一个 pod 需要联系 nginx 服务。它现在可以使用服务的联邦 DNS 名nginx.mynamespace.myfederation而不是传统的集群本地 DNS 名nginx.mynamespace自动扩展为nginx.mynamespace.svc.cluster.local。该名字会被自动扩展并解析到离 nginx 服务最近的健康 shard。如果本地集群中存在健康 shard那么该服务的集群本地 IP 地址将被返回通过集群本地 DNS这完全等同于非联邦服务解析。如果服务在本地集群中不存在或者存在但没有健康的后端 podDNS 查询会自动扩展到nginx.mynamespace.myfederation.svc.us-central1-a.example.com。在幕后这会找到离我们的可用区最近的一个 shard 的外部 IP。这个扩展由集群本地 DNS 服务器自动执行它返回相关的 CNAME 记录从而触发对 DNS 记录层次结构的遍历最终找到附近联邦服务的一个外部 IP。也可以通过明确指定适当的 DNS 名称而不是依赖自动 DNS 扩展将目标锁定在 pod 本地以外的可用性区域和地区的服务 shard。例如nginx.mynamespace.myfederation.svc.europe-west1.example.com将解析到欧洲所有当前健康的服务 shard——即使发布查询的 pod 位于美国也不管美国是否有健康的服务 shard。这对远程监控和其他类似应用很有用。从联邦集群之外的其他客户端发现联邦服务对于外部客户端目前还不能实现上述自动 DNS 扩展。外部客户需要指定联邦服务的完全限定 DNS 名称无论是区域、可用区还是全局名称。为了方便起见通常建议在服务中手动配置额外的静态 CNAME 记录例如短名称CNAMEeu.nginx.acme.comnginx.mynamespace.myfederation.svc.europe-west1.example.comus.nginx.acme.comnginx.mynamespace.myfederation.svc.us-central1.example.comnginx.acme.comnginx.mynamespace.myfederation.svc.example.com这样一来客户就可以始终使用左侧的短名称并自动路由到离他们位置最近的健康 shard。所有所需的故障转移都由 Kubernetes 集群联邦自动处理。架构概览KubeFedFederation v2Kubernetes Cluster Federation 又名KubeFed 或 Federation v2。v2 架构在 Federation v1 基础之上简化了扩展 Federated API 的过程并加强了跨集群服务发现与编排的功能。KubeFed 在设计之初有两个最重要的核心理念Modularization模块化与Customizable定制化这两个理念希望 KubeFed 能够跟随 Kubernetes 生态发展并持续保持相容性与扩展性。由于 Federation 试图解决一系列复杂的问题因此需要将这些问题的不同部分分解开来。下图展示了集群联邦的整体架构上图展示的集群联邦过程包括四个步骤配置需要联邦的集群配置需要在集群中传播的 API 资源配置 API 资源如何分配到不同的集群对集群中 DNS 记录注册。相较于 v1v2 在组件上最大的改变是将 API Server 移除并通过 CRD 机制来完成 Federated Resources 的扩充。KubeFed Controller 管理这些 CRD并实现同步资源、跨集群编排等功能。目前 KubeFed 通过 CRD 方式新增了四种 API 群组来实现联邦机制的核心功能API Group用途core.kubefed.k8s.io集群组态、联邦资源组态、KubeFed Controller 设定档等。types.kubefed.k8s.io被联邦的 Kubernetes API 资源。scheduling.kubefed.k8s.io副本编排策略。multiclusterdns.kubefed.k8s.io跨集群服务发现设定。在这些核心功能中我们必须先了解一些 KubeFed 提出的基础概念才能更清楚 KubeFed 是如何运作的。Cluster Configuration集群配置Cluster Configuration 用来定义哪些 Kubernetes 集群要被联邦。可通过kubefedctl join/unjoin来加入/删除集群。当成功加入时会建立一个KubeFedCluster组件来储存集群相关信息如 API Endpoint、CA Bundle 等。这些信息会被 KubeFed Controller 用于存取不同 Kubernetes 集群以确保能够建立 Kubernetes API 资源其工作方式如下图所示在 Federation 中会区分Host 与 Member两种类型集群Host用于提供 KubeFed API 与控制平面的集群。Member通过 KubeFed API 注册的集群并提供相关身份凭证来让 KubeFed Controller 能够存取集群。Host 集群也可以作为 Member 被加入。Type Configuration类型配置Type Configuration 定义了哪些 Kubernetes API 资源要被用于联邦管理。比如说想将 ConfigMap 资源通过联邦机制建立在不同集群上时就必须先在 Federation Host 集群中通过 CRD 建立新资源FederatedConfigMap接着再建立名称为configmaps的 Type ConfigurationFederatedTypeConfig资源描述 ConfigMap 要被 FederatedConfigMap 所管理。这样 KubeFed Controllers 才能知道如何建立 Federated 资源。以下为简单范例apiVersion: core.kubefed.k8s.io/v1beta1 kind: FederatedTypeConfig metadata: name: configmaps namespace: kube-federation-system spec: federatedType: group: types.kubefed.k8s.io kind: FederatedConfigMap pluralName: federatedconfigmaps scope: Namespaced version: v1beta1 propagation: Enabled targetType: kind: ConfigMap pluralName: configmaps scope: Namespaced version: v1若想新增 CRD 的 Federated API可通过kubefedctl enable res指令来建立示例如下$ kubefedctl enable etcdclusters $ kubectl api-resources | grep etcd etcdclusters etcd etcd.database.coreos.com true EtcdCluster federatedetcdclusters fetcd types.kubefed.k8s.io true FederatedEtcdCluster $ kubectl -n kube-federation-system get federatedtypeconfigs | grep etcd etcdclusters.etcd.database.coreos.com 3m16s可以看到kubefedctl enable一次完成了两件事为原生 CRD如 etcdclusters生成对应的 Federated 类型federatedetcdclusters并在kube-federation-system命名空间生成对应的 FederatedTypeConfig。一个 Federated 资源一般都会具备三个主要功能这些信息能够在 spec 中由使用者自行定义如下范例apiVersion: types.kubefed.k8s.io/v1beta1 kind: FederatedDeployment metadata: name: test-deployment namespace: test-namespace spec: template: # 定义 Deployment 的所有内容可理解成 Deployment 与 Pod 之间的关联。 metadata: labels: app: nginx spec: ... placement: clusters: - name: cluster2 - name: cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: spec.replicas value: 5Placement定义 Federated 资源要分散到哪些集群上若没有该字段则不会分散到任何集群中。如 FederatedDeployment 的spec.placement定义了两个集群时这些集群将被同步建立相同的 Deployment。另外也支持用spec.placement.clusterSelector的方式选择要放置的集群。Override定义修改指定集群的 Federated 资源中spec.template的内容。例如将 FederatedDeployment 部署到不同公有云上的集群时就能通过spec.overrides来调整 Volume 或副本数。注意目前Override 不支持 ListArray。比如说无法修改spec.template.spec.containers[0].image。Scheduling副本编排KubeFed 提供了一种自动化机制来将工作负载实例分散到不同的集群中这能够基于总副本数与集群的定义策略将 Deployment 或 ReplicaSet 资源进行编排。编排策略是通过建立ReplicaSchedulingPreferenceRSP文件再由 KubeFed RSP Controller 监听与撷取 RSP 内容将工作负载实例建立到指定的集群上。这是基于用户给出的高级用户偏好这些偏好包括加权分布的语义分布副本的限制最小和最大允许动态重新分配副本的语义——以防某些副本 Pod 仍然没有被调度到某些集群上例如由于该集群资源不足。以下为一个 RSP 范例。假设有三个集群被联邦名称分别为ap-northeast、us-east与us-westapiVersion: scheduling.kubefed.k8s.io/v1alpha1 kind: ReplicaSchedulingPreference metadata: name: test-deployment namespace: test-ns spec: targetKind: FederatedDeployment totalReplicas: 15 clusters: *: weight: 2 maxReplicas: 12 ap-northeast: minReplicas: 1 maxReplicas: 3 weight: 1该配置示意如下当该范例建立后RSP Controller 会收到资源并匹配对应 namespace/name 的 FederatedDeployment 与 FederatedReplicaSet 是否存在若存在会根据设定的策略计算出每个集群预期的副本数之后覆写 Federated 资源中的spec.overrides内容以修改每个集群的副本数最后再由 KubeFed Sync Controller 同步至每个集群的 Deployment。以上面为例结果会是ap-northeast 集群拥有 3 个 Podus-east 与 us-west 分别拥有 6 个 Pod15 个副本按权重 2:2:1 分配同时受 maxReplicas 12/3 约束ap-northeast 因 maxReplicas: 3 而封顶在 3 个。注意若spec.clusters未定义则预设为{*:{Weight: 1}}若有定义spec.replicas的 overrides副本数以 RSP 为优先考量分配的计算机制可以参考 KubeFed 源码中的kubefed/pkg/controller/util/planner/planner.goPlanner 实现了权重分配、min/max 约束与动态再平衡算法。Multi-cluster DNS多集群 DNSKubeFed 提供了一组 API 资源以及 Controllers来实现跨集群 Service/Ingress 的 DNS records 自动产生机制并结合ExternalDNS来同步更新至 DNS 服务供应商。以下为简单例子apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1 kind: Domain metadata: name: test namespace: kube-federation-system domain: k8s.example.com --- apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1 kind: ServiceDNSRecord metadata: name: nginx namespace: development spec: domainRef: test recordTTL: 300假设已建立一个名称为 nginx 的 FederatedDeployment放到 development namespace 中并且也建立了对应的 FederatedService 提供 LoadBalancer。当建立上述 Domain 与 ServiceDNSRecord 后完整的 DNS 产生链路如下Service DNS Controller依据 ServiceDNSRecord 文件内容收集不同集群的 Service 信息并将这些信息更新至 ServiceDNSRecord 的状态status中DNS Endpoint Controller依据该 ServiceDNSRecord 的状态内容建立一个 DNSEndpoint 文件并产生 DNS records 资源最后由ExternalDNS同步更新 DNS records 至 DNS 供应商。下图是 Service DNS 建立的架构若是 Ingress 的话会由IngressDNSRecord文件取代并由Ingress DNS Controller收集信息。总结KubeFed 的核心设计要点回顾整篇文章KubeFedFederation v2的核心设计可以归纳为以下几点模块化与定制化API 被拆分为核心构件Template / Placement / Override / TypeConfig、更高级别的联邦 API 与用户自定义类型用户既可以消费部分 API也可以编写自己的控制器替换参考控制器。CRD 优先v2 移除了独立的 Federation API Server全部能力通过四组 CRD APIcore / types / scheduling / multiclusterdns承载与 Kubernetes 生态的扩展方式保持一致。三层同步链路用户定义 Federated 资源 → KubeFed ControllersSync / RSP / DNS计算与编排 → 同步到各 Member 集群的 Kubernetes 原生资源同时通过 KubeFedCluster 保存的 Endpoint 与 CA Bundle 与各集群交互。跨集群服务发现通过myfederation域的 DNS 名称、自动 DNS 扩展与层次化 CNAME 遍历让 Pod 与外部客户端都能就近访问健康 shard实现地理分布、混合云与高可用。如果你希望进一步了解多集群管理的整体背景包括kubectl config的多集群访问配置可参阅本仓库的 concepts/multicluster.md联邦架构图与运行示意图均可在 images/ 目录中找到如 federation-concepts.png、sync-controller.png、kubefed-rsp.png、kubefed-service-dns.png。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Kubernetes 多集群管理与集群联邦KubeFed实战指南Kubernetes 多集群管理与集群联邦KubeFed实战指南 随着业务规模扩大与合规要求趋严单集群在可用性、隔离性、地域延迟与多云部署上的瓶颈愈发明显教程云原生容器编排tls-client配置指南自定义浏览器指纹的完整步骤tls client配置指南自定义浏览器指纹的完整步骤 tls client是一款类似net/http.Client的HTTP客户端工具它允许用户选择特定的2025终极指南Kubernetes多集群联邦(Kubefed)实战手册2025终极指南Kubernetes多集群联邦 Kubefed 实战手册 在当今云原生时代企业常常需要管理分布在多个环境的Kubernetes集群。Kube创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考