Tungsten Fabric SDN — 与 Kubernetes 的资源映射

Tungsten Fabric SDN — 与 Kubernetes 的资源映射

目录

文章目录

​​目录​​​​Kubernetes to Contrail Object Mapping​​​​K8s Namespace mapping to TF Shared or single project（multi-tenancy，多租户增强）​​

​​K8s Namespace mapping to TF Shared Project​​​​K8s Namespace mapping to TF Single Project​​

​​K8s Pod mapping to TF VRF Virtual Interface IP（network isolation，网络隔离增强）​​

​​Default Mode（Non-Isolated Namespaces）​​​​Isolation Mode（Isolated Namespaces）​​​​Custom Isolation Mode​​​​操作示例：验证路由隔离是否有效​​

​​K8s Service mapping to TF ECMP-based native LoadBalancer（load-balancing，负载均衡增强）​​

​​TF ClusterIP Service​​

​​TF Native Load Balancer​​​​TF Floating IP NAT​​​​使用示例​​

​​TF Loadbalancer Service​​

​​使用示例​​

​​NodePort Service（kube-proxy iptables NAT）​​

​​使用示例​​

​​K8s Ingress mapping to TF HAProxy L7 LoadBalancer（外部网络接入增强）​​​​K8s Network Policy mapping to TF Security group（micro-segmentation）​​

Kubernetes to Contrail Object Mapping

contrail-kube-manager 会 Watch 这些 K8s resource 的变更，并转发到 TF API 请求。

K8s Namespace mapping to TF Shared or single project（multi-tenancy，多租户增强）

K8s Namespace 可以映射到 TF Shared Project 或 TF Single Project。

K8s Namespace mapping to TF Shared Project（TF Single Tenant，单租户集成模式）：TF 对应 K8s Cluster 只有一个 Tenant。K8s Namespace 映射为 TF VN。K8s Namespace mapping to TF Single Project（TF Multi Tenant，多租户集成模式）：TF 对应 K8s Cluster 有多个 Tenants。K8s Namespace 映射为 TF Project。

K8s Namespace mapping to TF Shared Project

可以通过修改 kube-manager 的配置文件 /etc/contrail/contrail-kubernetes.conf 中的配置项 [KUBERNETES].cluster_project 来指定实施 “单租户集成模式”。例如：

[KUBERNETES]cluster_project = {'domain': 'default-domain', 'project': 'kubernetes'}...

单租户集成模式中，所有的 non-Isolated network 都会共享默认的 cluster-network VN VRF；所有的 Isolated network 都具有独立的 VN VRF。

K8s Namespace mapping to TF Single Project

默认的，contrail-ansible-deployer 会实施 “多租户集成模式”。初始状态下，存在 5 个 TF Projects 对应 5 个 K8s Namespaces。之后再新建一个 K8s Namespace 就会同时创建一个 TF Project。

每个对应 K8s Namespace 的 TF Project 下都包含了 2 个 VNs：k8s-{vn_name}-service-network 和 k8s-{vn_name}-pod-network，并且绑定了相应的 IPAM 和 Network Policies。分别用于 Pod 和 Service 资源。

默认情况下，除了 k8s-{vn_name}-pod-network 之外，其他的 VN 是无法连接到 k8s-{vn_name}-service-network 的，这由 TF Network Policy 来进行控制。

k8s-default Project 存放了大量可以被 Shared 的资源，例如：IPAM、Network Policy、Security group 等等。

3 个 TF IPAM：k8s-pod-ipam、k8s-service-ipam 和 k8s-ip-fabric-ipam，分别作为 K8s Pods、Services、Underlay（IP Fabric）的 Subnet IP Pool。3 条 Network Policies：k8s-default-service-np、k8s-default-ip-fabric-np 和 k8s-default-pod-service-np。

k8s-default-service-np 允许指定的 VN 可以访问 K8s service VN。k8s-default-pod-service-np 允许指定的 Pod VN 可以访问 K8s service VN。k8s-default-ip-fabric-np 允许指定的 VN 可以访问 K8s underlay（IP Fabric）VN。

1 条 Security Group：允许 Pod VIF 的所有 Ingress/Egress 流量。

K8s Pod mapping to TF VRF Virtual Interface IP（network isolation，网络隔离增强）

创建一个 K8s Pod 就会在相应的 TF VN 中创建一个 VIF，并挂载到 Pod 所处的 Linux Network Namespace。

Kubernetes 的基本网络模型是一个扁平的网络（Flat networking），通过 K8s Network policy 来提供 Pod-to-Pod 的安全访问控制。但 K8s Flat networking 并没有实现真正的多租户隔离，这意味着任何 Namespace 中的 Pod 都可以与任何 Other Namespace 中的 Pods 进行通信。换句话说，如果 Target Pod 的 Domain Name 或 IP address 已知，则无法阻止从一个 Namespace 中的 Pod 到 Other Namespace 中的 Pods 的通信。

可见，Kubernetes 的基本网络模型并不适用于对安全隔离性要求高的场景。针对这一需求，TF 除了为 K8s 提供 CNI 标准强制要求的 Flat Networking（Non-Isolated 网络模型）之外，还为 K8s 提供了 Network isolation 网络增强功能。

Default Mode（Non-Isolated Namespaces）

为了保持 K8s 基本的 Flat Networking（扁平网络）模型，TF 默认提供了 Non-Isolated Namespaces（非隔离命名空间）模式。

TF 为 K8s Cluster 预配置了 2 个 Default VN（虚拟网络）：k8s-default-pod-network 和 k8s-default-service-network。它们分别为所有 Non-Isolated Namespaces 中的 Pods 或 Services 提供网络。使得所有的 Non-Isolated Namespaces 中的 Pods 或 Services 处于一个扁平的网络中的（包括 Default Namespace），可以跨越不同的 Namespace 互联互通。

从 TF 的角度看，这些 Non-Isolated Namespaces 对应的 Projects 共享了 2 个 Public VRF：

k8s-default-pod-network: the pod virtual network/VRF table, with the default subnet 10.32.0.0/12k8s-default-service-network: the service virtual network /VRF table, with a default subnet 10.96.0.0/12

也就是说，当你新建一个（默认）Non-Isolated Namespace 时，TF 会自动为该 Project 授权这 2 个 Default VN/VRF。

NOTE：无论是 Non-Isolated Namespace 还是 Isolated Namespace 中，每个 TF virtual network 都具有独立的 VRF，所以两个不同的 virtual network 需要互通时，依旧需要配置相应的 Network Policy。例如：k8s-default-pod-network 和 k8s-default-service-network 之间就是通过 Network Policy 来实现互通的。

NOTE：kube-system namespace 是一个特殊的 underlay 网络，不在 K8s Cluster 范围内，也就是说不属于 TF 管理。

Isolation Mode（Isolated Namespaces）

Isolated Namespace 拥有独立隔离的 Pod 和 Service VN/VRF。也就是说：

Isolated Namespace 中的 Pod 只能与同一个 Namespace 中的其他 Pods 互通，无法访问 other Namespaces 中的 Pods，但可以访问 non-Isolated Namespaces 中的 Services。创建一个 Isolated Namespace 如下。

apiVersion: v1kind: Namespace metadata: annotations: "opencontrail.org/isolation" : "true" # The value of true indicates this is an isolated namespace. name: ns-isolated

Isolated Namespace 中的 Service（k8s service-ip）只能与同一个 Namespace 中的其他 Pods 互通，other Namespace 中的 Pods 无法访问 Isolated Namespace 中的 Service。根据需求，如果 Isolated Namespace 中的 Service 需要被 other Namespace 中的 Pods 访问到，则可以配置 disabling service isolation。此时 other Namespace 的 Pods 可以范围该 Service，同时 Isolated Namespace 中的 Pods 依旧是隔离的。

apiVersion: v1kind: Namespace metadata: annotations: "opencontrail.org/isolation" : "true" # The value of true indicates this is an isolated namespace. "opencontrail.org/isolation.service": "false" name: ns-isolated

从 YAML 可以看出，contrail-kube-manager 对 K8s resources 进行了扩展。新建一个 Namespace 时，contrail-kube-manager 会 Watch K8s API Server 并读取到 opencontrail.org/isolation 注释，然后根据 Namespace 的隔离类型来进行相应的处理。当 isolation 为 true，TF 就会使用相应的 VRF 来创建该 Namespace 映射的 Project。

举例说明：假设现在具有 3 个 Namespace： default、ns-non-isolated、ns-isolated，并在每个 Namespace 中创建了 VN vn-left-1。那么你将会看见以下 VNs/VRFs，它们的隔离关系如图所示。

default-domain:k8s-default:k8s-default-pod-networkdefault-domain:k8s-default:k8s-default-service-networkdefault-domain:k8s-default:k8s-vn-left-1-pod-networkdefault-domain:k8s-ns-non-isolated:k8s-vn-left-1-pod-networkdefault-domain:k8s-ns-isolated:k8s-ns-isolated-pod-networkdefault-domain:k8s-ns-isolated:k8s-ns-isolated-service-networkdefault-domain:k8s-ns-isolated:k8s-vn-left-1-pod-network

NOTE：Isolated Namespaces Mode 下，如果两个 Namespaces 需要互通时，则可以对 Namespace 下属的 VN 配置相应的 Network Policy。

Custom Isolation Mode

该模式中，用户可以通过修改 Application YAML annotations 来自定义自己的 Namespace 中所使用的 Virtual Network。例如：

annotations: { "opencontrail.org/network" : '{"domain":"default-domain", "project": "k8s-default", "name":"k8s-blue-net-pod-network"}'}

如果该 annotations 配置 Pod YAML 上，则指定 Pod 启动在指定 Namespace 的 Virtual network 上。如果该 annotations 配置 Namespace YAML 上，则该 Namespace 中的所有 Pods 都启动在 Virtual network 上。

操作示例：验证路由隔离是否有效

新建 non-Isolated Namespace

$ cat ns-non-isolated.yamlapiVersion: v1kind: Namespacemetadata: name: ns-non-isolated

新建 Isolated Namespace

$ cat ns-isolated.yamlapiVersion: v1kind: Namespacemetadata: annotations: "opencontrail.org/isolation": "true" name: ns-isolated

创建 Pods

$ kubectl apply -f pod-busybox.yaml -n default$ kubectl apply -f pod-busybox.yaml -n ns-non-isolated$ kubectl apply -f pod-busybox.yaml -n ns-isolated$ kubectl get pods -A -o wide | grep busyboxdefault busybox 1/1 Running 0 39s 10.47.255.248 worker02ns-isolated busybox 1/1 Running 0 3m38s 10.47.255.250 worker02ns-non-isolated busybox 1/1 Running 0 2m5s 10.47.255.249 worker01

对比验证 Pods 之间的网络隔离性

# 验证 Isolated 和 non-Isolated 之间的隔离性kubectl exec -it -n ns-isolated busybox -- ping 10.47.255.249# 验证 Default 和 Isolated 之间的隔离性kubectl exec -it -n default busybox -- ping 10.47.255.250# 验证 Default 和 non-Isolated 之间的隔离性kubectl exec -it -n default busybox -- ping 10.47.255.249

K8s Service mapping to TF ECMP-based native LoadBalancer（load-balancing，负载均衡增强）

K8s Service 支持以下 4 种模式，还支持使用 ExternalIP。

ClusterIPNodePortLoadBalancerExternalName

而 TF 则主要支持了其中必要的 2 种模式，以及 ExternalIP。

TF ClusterIPTF LoadBalancer

TF ClusterIP Service

TF ClusterIP Service 通过 ECMP 和 NAT 技术，实现了在 Service 和 Pods 之间进行 L4 负载均衡转发。

TF Native Load Balancer

新建一个 K8s ClusterIP Service 时，TF 会从同步新建一个 TF Load Balancer，LB Provider Type 为 Native，底层实现为 vRouter ECMP。所以也称为 TF Native Load Balancer。

并且 TF 还会从相应的 Service VN 的 Subnet Pool 分配一个 IP 作为 LB VIP，也就是 ClusterIP。

TF Floating IP NAT

在有了 TF Native LB VIP 作为 Front-end IP 之后，还需要将流量转发到 Backend IPs（Pods），TF 使用 NAT 技术来实现这一功能，而不是引入一个重型的 HAProxy-like 负载均衡器。

同时，由于 TF Floating IP 本身就具有 NAT 的功能特性，所以就可以直接使用 TF Floating IP 来完成这项工作。

另外，由于 ClusterIP Service 只能在 K8s Cluster Internal 被访问，所以针对 ClusterIP Service 的 FIP 实际上是一个 Inter-FIP。直接从相应的 Service VN 中的 FIP Pool 分配的，而不需要从 Public VN 中分配。

使用示例

创建 ClusterIP Service。

$ cat nginx-deployment-clusterip-service.yaml---apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2kind: Deploymentmetadata: name: nginx-deployment-clusterip-servicespec: strategy: type: Recreate selector: matchLabels: app: nginx replicas: 2 # tells deployment to run 1 pods matching the template template: # create pods using pod definition in this template metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80---apiVersion: v1kind: Servicemetadata: name: nginx-deployment-clusterip-service namespace: default labels: app: nginxspec: ports: - name: port: 80 protocol: TCP targetPort: 80 selector: app: nginx $ kubectl get pods -A -o wide | grep nginxdefault nginx-56db997f77-9qxwd 1/1 Running 0 15m 10.47.255.246 worker01 default nginx-56db997f77-thpxd 1/1 Running 0 15m 10.47.255.247 worker02 $ kubectl describe service -n default nginxName: nginxNamespace: defaultLabels: app=nginxAnnotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx","namespace":"default"},"spec":{"p...Selector: app=nginxType: ClusterIPIP: 10.97.137.130Port: 80/TCPTargetPort: 80/TCPEndpoints: 10.47.255.246:80,10.47.255.247:80Session Affinity: NoneEvents:

TF Loadbalancer Service

TF Loadbalancer Service 的实现方式是在 TF ClusterIP Service（Native LB + Inter-FIP NAT）的基础之上，再叠加了一个 External FIP NAT。因为 Loadbalancer Service 相对于 ClusterIP Sercice 而言，是提供给 External Network 访问的。

ClusterIP Service as a Cluster Internal LB VIPLoadbalancer Service as a Cluster External Floating VIP

可见，对于 Loadbalancer Service 而言拥有 3 个关键 IP：

TF Native LB IP：从 Service VN Subnet Pool 分配，作为内部 L3-4 负载均衡 VIP。Inter-FIP：从 Service VN FIP Pool 分配，作为内部 L3-4 NAT Front-end IP。Ext-FIP：从 Public VN FIP Pool（Namespace FIP Pool 或 Global FIP Pool）分配，作为外部 L3-4 NAT Front-end IP。

相对的，Loadbalancer Service 中也存在着 2 种类型的 ECMP：

Internal ECMP：Cluster IP 和 Pod IPs 之间的 ECMPExternal ECMP：External VIP 和 Cluster IPs（跨节点）之间的 ECMP。

使用示例

新建 Loadbalancer Service

$ vi service-web-lb.yamlapiVersion: v1kind: Servicemetadata: name: service-web-lb spec: ports: - port: 8888 targetPort: 80 selector: app: webserver type:

NodePort Service（kube-proxy iptables NAT）

NodePort Service 依赖原生的 kube-proxy iptables NAT 技术来实现，在 TF 的场景中，通常没必要使用到。

使用示例

创建 Nginx Deployment NodePort Service。

$ cat nginx-deployment-nodeport-service.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment-nodeport-service labels: name: nginxspec: replicas: 1 selector: matchLabels: name: nginx template: metadata: labels: name: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80---apiVersion: v1kind: Servicemetadata: name: nginx-deployment-nodeport-service labels: name: nginxspec: type: NodePort ports: - port: 80 nodePort: 30080 name: selector: name: nginx $ kubectl get pods -A -o wide | grep nodeportdefault nginx-deployment-nodeport-service-69f7cb4f44-pjm9r 1/1 Running 0 30s 10.47.255.247 worker02$ kubectl describe service -n default nginx-deployment-nodeport-serviceName: nginx-deployment-nodeport-serviceNamespace: defaultLabels: name=nginxAnnotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"name":"nginx"},"name":"nginx-deployment-nodeport-service","nam...Selector: name=nginxType: NodePortIP: 10.98.140.244Port: 80/TCPTargetPort: 80/TCPNodePort: 30080/TCPEndpoints: 10.47.255.247:80Session Affinity: NoneExternal Traffic Policy: ClusterEvents: # worker02$ curl Ingress mapping to TF HAProxy L7 LoadBalancer（外部网络接入增强）

TF 提供了基于 HAProxy 的 Ingress 实现，创建 K8s Ingress 就会创建一个 TF HAProxy LoadBalancer。

其中，由 contrail-svc-monitor 执行具体的 LBaaS 任务。contrail-svc-monitor 作为 TF 内部组件（e.g. Config Node）与外部组件（e.g. Loadbalancer Provider、OpenStack API）之间进行交互的桥梁。

K8s Network Policy mapping to TF Security group（micro-segmentation）

TF Security Group 可以通过限制 Protocol、Ports 等参数来管理任意 Pods 之间、以及 Pod 与 Service 之间的访问控制，当新建一个 K8s Network Policy 就会创建一个 TF Security Group。

TF Security Group 会被转化为具体的 TF Firewall Rules。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。