深入了解Cilium多集群

最新推荐文章于 2024-08-07 09:30:06 发布

weixin_38754564

最新推荐文章于 2024-08-07 09:30:06 发布

阅读量829

点赞数

640?wx_fmt=jpeg

作者：Cilium
译者：陆培尔
审校：孙海洲
原文链接：http://www.servicemesher.com/blog/envoy-feature-explain-outlier-detection/

本文是对ClusterMesh（Cilium的多集群实现）的深入研究。简而言之，ClusterMesh 提供：

多集群功能以层为单位构建，您可以选择使用所有层，也可以仅选择和使用所需的层。

用例

在深入研究实现细节之前，让我们回顾一下连接多个Kubernetes集群的一些用例。

用例：高可用性

对于大多数人来说，高可用性是最明显的用例。此用例包括在多个区域（regions）或可用区（availability zones）中运行Kubernetes集群，并在每个集群中运行相同服务的副本。一旦失败，请求可以故障转移到其他集群。此用例中涵盖的故障情形主要不是整个区域或故障域的完全不可用。更可能的情况是一个集群中资源暂时不可用或配置错误导致无法在一个集群中运行或扩展特定服务。

用例：共享服务

基于Kubernetes的平台的最初趋势是构建大型多租户Kubernetes集群。为每个租户构建单个集群或为不同类别的服务构建集群越来越普遍，例如，不同级别的安全敏感度。

但是，某些服务（如密钥管理，日志记录，监控或DNS）通常仍在所有集群之间共享。这避免了在每个租户集群中维护这些服务的操作开销。

此模型的主要动机是租户集群之间的隔离，为了维持该目标，租户集群连接到共享服务集群但未连接到其他租户集群。

用例：拆分有状态和无状态服务

运行有状态或无状态服务的操作复杂性是非常不同的。无状态服务易于扩展，迁移和升级。完全使用无状态服务运行集群可使集群保持灵活和敏捷。从一个云提供商迁移到另一个云提供商非常简单。

有状态服务可能会引入潜在的复杂依赖链。迁移服务通常涉及存储迁移。

为无状态和有状态分别运行独立的集群允许将依赖复杂性隔离到较少数量的集群，并使无状态集群依赖性保持自由。

控制平面

要求

架构

控制平面基于etcd并尽可能保持简约：

Pod IP 路由

pod IP路由是多集群能力的基础。它允许跨集群的pod通过其pod IP相互联系。Cilium可以在多种模式下运行以执行pod IP路由。所有这些模式都能够执行多集群pod IP路由。

隧道模式

隧道模式将pod中发出的所有网络数据包封装在所谓的封包头中。封包头可以包含VXLAN或Geneve帧。然后通过标准UDP包头传输该封装帧。该概念类似于VPN隧道。

直接路由模式

在直接路由模式中，所有网络数据包都直接路由到网络。这要求网络能够路由pod IP。可以使用多个选项实现跨节点传播pod IP路由信息：

当网络不再理解pod IP时，网络数据包地址需要伪装。

混合路由模式

混合路由模式允许在可用时使用直接路由，这通常在本地集群或同一VPC中的其他集群中，而当跨越VPC或云提供商时可以回退到隧道模式。这可以限制操作复杂性并且允许仅在需要时支付优化成本。

服务发现

Cilium的多集群模型的服务发现是使用标准的Kubernetes services 构建的，旨在对现有的Kubernetes应用程序部署完全透明：

apiVersion: v1   kind: Service   metadata:     name: rebel-base     annotations:       io.cilium/global-service: "true"   spec:     type: ClusterIP     ports:     - port: 80     selector:       name: rebel-base
   metadata:
     name: rebel-base
     annotations:
       io.cilium/global-service: "true"
   spec:
     type: ClusterIP
     ports:
     - port: 80
     selector:
       name: rebel-base

从frontend-1到ClusterIP 30.1.1.1的所有流量将自动负载均衡到集群1 的后端pod IP[10.0.0.1,10.0.0.2]以及集群2的后端pod IP[20.0.0.1,20.0.0.2]。每个集群将执行本地后端实例的运行状况检查，并在容器创建，销毁或变得不健康时通知其他集群。

透明加密

Cilium 1.4中引入的透明加密与多集群兼容。确保使用公共密钥配置所有集群中的所有节点，如此节点之间的所有通信都会自动加密。

多集群的网络策略

简单版本是您从单个集群中熟悉的策略实施将简单地扩展并跨集群工作。由于策略是使用pod标签指定的，因此允许frontend与backend通信的策略将应用于集群流量，就像流量跨越集群一样。

Cilium不会跨集群自动传播NetworkPolicy或CiliumNetworkPolicy。用户有责任将策略导入所有集群。这是有意为之，因为这意味着每个集群都可以决定是否允许集群接收来自远程集群的通信或者发出到远程集群的通信。

允许特定集群的交叉路径

可以仅建立适用于特定集群中的pod的策略。集群名称由Cilium表示为每个pod上的标签，允许匹配的集群名称可以是endpointSelector或者是由toEndpoints和fromEndpoints构造的matchLabels标签：

apiVersion: "cilium.io/v2"kind: CiliumNetworkPolicymetadata:  name: "allow-cross-cluster"  description: "Allow x-wing in cluster1 to contact rebel-base in cluster2"spec:  endpointSelector:    matchLabels:      name: x-wing      io.cilium.k8s.policy.cluster: cluster1  egress:  - toEndpoints:    - matchLabels:        name: rebel-base        io.cilium.k8s.policy.cluster: cluster2
metadata:
  name: "allow-cross-cluster"
  description: "Allow x-wing in cluster1 to contact rebel-base in cluster2"
spec:
  endpointSelector:
    matchLabels:
      name: x-wing
      io.cilium.k8s.policy.cluster: cluster1
  egress:
  - toEndpoints:
    - matchLabels:
        name: rebel-base
        io.cilium.k8s.policy.cluster: cluster2

上面的示例策略将允许cluster1中的x-wing与cluster2中的rebel-base对话。除非存在将通信列入白名单的附加策略，否则x-wing将无法与本地集群中的rebel-base通信。