Kubernetes多租户隔离利器-Calico

最新推荐文章于 2024-08-29 15:31:27 发布

congxia1948

最新推荐文章于 2024-08-29 15:31:27 发布

阅读量467

点赞数

文章标签：大数据人工智能运维

本文介绍了一个数据中心网络方案Calico，包括其优势、架构、性能分析、工作原理，以及分析了生态云Kubernetes版应用引擎在Calico中的policy设置策略。

背景

小米生态云旨在为小米生态链企业及合作伙伴提供云计算、大数据、人工智能、安全及合规等一站式云服务和整体解决方案。生态云上有一款基于Kubernetes研发的新版应用引擎已经为几十家企业提供服务，每家企业的数据保护最为重要，为此我们探讨了诸多方案的可行性，最终使用Calico网络方案。

Calico简介

Calico是纯3层的数据中心网络方案，它是目前Kubernetes networkpolicy概念的最佳实现方案之一，利用虚拟路由代理虚拟交换，每一台虚拟路由通过BGP协议传播可达信息（路由）到剩余数据中心。

Calico优势

1. 支持Kubernetes networkpolicy概念

2. 容器间网络三层隔离，无需要担心arp风暴

3. 自由控制的policy规则

4. 网络拓扑直观易懂，扩展性强

5. 通过iptables和kernel包转发，效率高，损耗低

Calico架构图

Calico包括如下重要组件：Felix，Etcd，BGP Client，BGP Route Reflector。Felix 、BGPClient 部署在node节点，BGPRouteReflector部署在Master，下面分别说明一下这些组件。

Felix： 主要负责路由配置以及ACLS规则的配置以及下发，它存在在每个node节点上。

Etcd： 分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性，一般与Kubernetes共用。

BGP Client(BIRD)： 负责把Felix在各node上设置的路由信息广播到Calico网络( 通过BGP协议)。

BGP Route Reflector： 集中式的路由分发。

Calico原理

如下图所示：原网络通过路由表和iptables，再经过数据中心路由，最终到达目地网络路由，最后分配到目地容器。

Kubernetes版应用引擎的设置策略

因为企业用户会在Kubernetes版应用引擎中建立多个namespace，故不能使用基于namespace的policy策略，我们使用label的方式进行policy的自定义。

以A公司为例子：

实验环境所用的3个namespace是：ami-a、ami-b、bmi三个

1. 新建namespace并打标签org=ami、org=bmi


kubectl create -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: ami-a
labels:
org: org-ami #为namespace ami-a打org=ami
EOF
kubectl create -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: ami-b
labels:
org: org-ami #为namespace ami-b 打org=ami
EOF
kubectl create -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: bmi
labels:
org: org-bmi #为namespace bmi 打org=bmi
EOF

2.Calico默认策略是相同子网的pod互相访问是通的，不管namespace是否相同。

为此我们需要先建一个全局策略来禁业pod IP访问。然后再单独为ami和bmi建立policy。

（1）全局禁业策略如下：


kubectl create -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: ami-a
labels:
org: org-ami #为namespace ami-a打org=ami
EOF
kubectl create -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: ami-b
labels:
org: org-ami #为namespace ami-b 打org=ami
EOF
kubectl create -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
name: bmi
labels:
org: org-bmi #为namespace bmi 打org=bmi
EOF

（2）单独为ami和bmi创建策略如下：


calicoctl create -f - <<EOF
- apiVersion: v1
kind: policy
metadata:
name: ami.allow-access-from-same-rog
spec:
egress:
- action: allow
destination:
selector: k8s_ns/label/org == 'org-ami' #允许label org=ami的出口互相访问source:
selector: k8s_ns/label/org == 'org-ami'ingress:
- action: allow
destination: {}
source:
selector: k8s_ns/label/org == 'org-ami' #允许label org=ami的入口互相访问order: 800selector: k8s_ns/label/org == 'org-ami'
EOF
calicoctl create -f - <<EOF
- apiVersion: v1
kind: policy
metadata:
name: bmi.allow-access-from-same-rog
spec:
egress:
- action: allow
destination:
selector: k8s_ns/label/org == 'org-bmi' #允许label org=bmi的出口互相访问source:
selector: k8s_ns/label/org == 'org-bmi'ingress:
- action: allow
destination: {}
source:
selector: k8s_ns/label/org == 'org-bmi' #允许label org=bmi的入口互相访问order: 800selector: k8s_ns/label/org == 'org-bmi'
EOF

order越小代表执行策略越靠前，Calico执行的是聚合策略。

通过这样的配置即使namespace不同，但只要label相同，网络就会互通，我们为每家企业提供不同的label，这样就达到我们目地。

3.让我们来验证一下

（1）我们新建了三个namespace别分是：

ami-a label org-ami

ami-b label org-ami

bmi label org-bmi

两个ami label相同，bmi单独一个label。

建立完成后，使用命令kubectl get namespace ns -o yaml 分别看下建立后的namespace label。