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