随着数据中心遍布全球,用户越来越多地寻求跨区域或集群传播其应用或服务的方法。这种需求由多种用例驱动:实现多集群负载均衡,避免单集群故障造成巨大损失;通过可访问和使用多集群的混合云解决方案避免提供商锁定。
Red Hat 一直在研究 Kubernetes Multicluster Special Interest Group(SIG)和 Federation Working Group,近日发布在 OpenShift 3.11 上的 Kubernetes Federation V2 预览版本,旨在允许用户通过单一 API 将服务和工作负载部署到多个集群。
目的
Red Hat 对多集群问题的探索出于用户需求推动,其用例包括:
将应用程序、服务和策略分发到多集群;
应用程序和服务迁移及其在集群之间的存储;
应用程序和服务的灾难恢复。
为了满足这些需求并尽可能获取广泛受众,Red Hat 在设计时考虑了模块化,这意味着已经添加接受个别特殊用例的能力,并且改变系统行为,可用于自定义资源。
Federation V2 简介
Federation V2 是 Kubernetes 运营商利用自定义资源定义,提供管理 Kubernetes Cluster Registry 跟踪的多个 Kubernetes 集群应用和服务工具。Federation 允许用户将工作负载部署到集群注册表,使用有关工作负载信息对 DNS 进行编程,并动态调整部署工作负载的不同集群副本。随着 Federation 的成熟,Red Hat 也打算添加处理存储、工作负载等功能。
Federation 概念
从根本上说,Federation 必须配置两种类型信息:
Federation 要处理的 API 类型信息
Federation 目标分发集群资源
对于 Federation 处理的每种 API 类型,声明状态的不同部分存在于不同的 API 资源中:
“template”类型包含资源的基本规范;
“placement”类型包含资源应分发到的集群规范;
可选“overrides”类型包含在某些集群中更改模板资源的规范;
Propagation 是指资源如何分配到目标集群,目前存在主动协调方法。其中,Federation 运行控制器,该控制器主动将资源推送到目标集群。Scheduling 是指决策能力,可以决定工作负载如何在不同集群中传播,类似于人为操作。
最后,部署在多个集群中的应用程序和服务经常需要将外部请求路由到其中一个服务集群的 DNS 记录,Federation 的 DNS 功能为服务或入口的每个端点维护 DNS 条目。
示例
本示例展示使用 Deployment 资源的情况,此示例描述了分布在两个集群上的 Deployment 资源,其中一个集群是 3 副本,另一个集群是 5 副本。
Deployment 的基本定义位于 FederatedDeployment 中:
具有相同名称的 FederatedDeploymentPlacement 资源包含有关 Deployment 应存在的集群信息:
FederatedDeploymentOverrides 同名资源包含有关如何在某些集群中区分副本的信息:
此时,只能覆盖给定 Federation 类型的单个字段(在“Deployments”情况下是“replicas”字段)。 如果必须在成员集群初始创建目标资源时进行应用覆盖,则应在 Template 资源之前创建 Override 资源。
未来
Red Hat 在 Kubernetes 社区的下一步改进由 Federation 开发者预览版收到的反馈驱动,如果你对该功能感兴趣并希望 Federation 在某些部分进行改进,可以在社区中进行反馈。
参考链接:https://blog.openshift.com/kubernetes-federation-v2-on-openshift-3-11/
评论