云原生 Contrail 网络中的 NodePort 服务支持
瞻博网络在使用云原生 Contrail® 网络™版本 22.1 或更高版本的环境中支持 Kubernetes NodePort 服务。
在 Kubernetes 中，服务是一种抽象，它定义了一组逻辑的 Pod 和策略，您可以通过这些策略访问它们。根据服务定义中的对象选择 LabelSelector 实现服务的 Pod 集。NodePort 服务在静态端口的每个节点的 IP 上公开服务。它将每个节点上的静态端口与容器上应用程序的端口映射。
在 Contrail 网络中，Kubernetes NodePort 服务是使用 InstanceIP 资源和资源 FloatingIP 实现的，这两者都与服务类似 ClusterIP 。
Kubernetes 提供了一个扁平的网络模型，在这个模型中，所有 Pod 都可以相互通信。添加了网络策略以在 Pod 之间提供安全性。与 Kubernetes 集成的 Contrail 网络增加了额外的网络功能，包括多租户、网络隔离、使用网络策略的微分段以及负载平衡。
下表列出了 Kubernetes 概念与 Contrail 网络资源之间的映射。
| Kubernetes 概念 | Contrail 网络资源 |
|---|---|
| 命名 空间 | 共享或单个项目 |
| Pod | 虚拟机 |
| 服务 | 等价多路径 （ECMP） 负载均衡器 |
| 入口 | 用于 URL 的 HAProxy LoadBalancer |
| 网络策略 | Contrail 安全性 |
Contrail 网络负载均衡器对象
图 1 和以下列表描述了 Contrail 网络中的负载平衡器对象。
- Contrail 网络中的每个服务都由一个负载均衡器对象表示。
- 对于每个服务端口，将为同一服务负载均衡器创建一个侦听器对象。
- 对于每个侦听器，都有一个池对象。
- 池包含成员。根据后端 Pod 的数量，一个池可能有多个成员。
- 池中的每个成员对象都映射到其中一个后端 Pod。
- 侦
contrail-kube-manager听kube-apiserverKubernetes 服务。创建服务时，将创建类型为负载均衡器loadbalancer_providernative对象。 - 负载均衡器有一个虚拟 IP 地址 （VIP），该地址与服务 IP 地址相同。
- 服务 IP/VIP 地址链接到每个后端 Pod 的接口。这是通过 ECMP 负载平衡器驱动程序完成的。
- 从服务 IP 地址到多个后端 Pod 接口的链接会在 Contrail 网络中创建 ECMP 下一跃点。流量从源 Pod 直接负载平衡到其中一个后端 Pod。
- 继续
contrail-kube-manager侦kube-apiserver听任何更改。根据端点中的 Pod 列表，contrail-kube-manager了解最新的后端 Pod 并更新池中的成员。
Contrail 网络中的 NodePort 服务
控制器服务在 中 kube-manager实现。这是 kube-manager Kubernetes 核心资源（如服务和）和扩展的 Contrail 资源（如 VirtualNetwork 和 RoutingInstance）之间的接口。此控制器服务监视通过资源终结点的事件。终结点接收与其服务相关的任何更改的事件。端点还会收到与服务选择器匹配的创建和删除的 Pod 的事件。控制器服务处理创建所需的 Contrail 资源：参见 图 2。
InstanceIP与ServiceNetworkFloatingIP资源和关联的资源VirtualMachineInterfaces
当用户创建服务时，Kubernetes 会自动创建一个关联的端点，这允许控制器服务接收新请求。
创建节点端口服务的工作流程
图 3 和以下步骤详细介绍了创建 NodePort 服务时的工作流。
- 创建节点端口服务时，
InstanceIP将创建 （IIP）。资源InstanceIP指定属于引用的虚拟网络的子网的固定 IP 地址及其特征。 - 端点连接到 NodePort 服务后，即创建 。
FloatingIPkube-manager用于创建连接到服务的终结点的监视。 - 创建新终结点后，
kube-manager会在子网中ServiceVirtualNetwork创建一个InstanceIP终结点。然后创建一个kube-managerFloatingIP使用 作为InstanceIP父级。 - 资源
FloatingIP指定不属于特定VirtualMachineInterface（VMI） 的特殊类型的 IP 地址。这是FloatingIP从单独的VirtualNetwork子网分配的，可以与多个 VMI 关联。与多个 VMI 关联时，发往 的FloatingIP流量使用 ECMP 在所有 VMI 之间分配。
有关 VMI 的说明：
- VMI 会随着容器和标签的添加和删除而动态更新。
- VMI 表示虚拟网络中的接口（端口），可能有相应的虚拟机，也可能没有对应的虚拟机。
- VMI 至少具有 MAC 地址和 IP 地址。
有关虚拟机的说明：
- VM 资源表示计算容器。例如虚拟机、裸机、Pod 或容器。
- 每个 VM 都可以与同一租户网络上的其他 VM 通信，但须遵守策略限制。
- 由于租户网络是隔离的，除非策略明确允许，否则一个租户中的 VM 无法与另一个租户中的 VM 通信。
Kubernetes Probes 和 Kubernetes NodePort Service
在每个 kubelet节点上运行的代理需要对 Pod 的可访问性，以便进行活动性和就绪情况探测。在 IP 交换矩阵网络和 Pod 网络之间创建 Contrail 网络策略，以提供节点和 Pod 之间的可访问性。每当创建 Pod 网络时，都会将网络策略附加到 Pod 网络，以提供节点和 Pod 之间的可访问性。因此，节点中的任何进程都可以访问 Pod。
Kubernetes NodePort 服务基于节点对 Pod 的可访问性。由于 Contrail 网络通过 Contrail 网络策略在节点和 Pod 之间提供连接，因此支持 NodePort。
节点端口服务支持两种类型的流量：
- 东西向
- 结构到 Pod
节点端口服务端口映射
Kubernetes NodePort 服务的端口映射位于 YAML 文件的资源中 FloatingIp 。在 中 FloatingIp，端口将添加到 "floatingIpPortMappings"中。
如果服务中未提及 ， targetPort 则将该 port 值指定为默认值。
包含端口详细信息的节点端口服务的 YAML 文件示例 spec ：
spec:
clusterIP: 10.100.13.106
clusterIPs:
- 10.100.13.106
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
run: my-nginx
sessionAffinity: None
对于上面的示例 spec YAML， "floatingIpPortMappings" 在资源中创建 FloatingIp ：
示例 "floatingIpPortMappings" YAML：
"floatingIpPortMappings": {
"portMappings": [
{
"srcPort": 80,
"dstPort": 80,
"protocol": "TCP"
}
]
}
示例：节点端口服务请求旅程
让我们跟随 NodePort 服务请求从请求到达节点端口到服务请求到达后端 Pod 的旅程。
节点端口服务依赖于 kubeproxy。Kubernetes 网络代理 （kube-proxy） 是在每个节点上运行的守护程序。它反映群集中定义的服务，并管理规则以将请求负载均衡到服务的后端 Pod。
在以下示例中，将创建 NodePort 服务 apple-service 并关联其终结点。
user@domain ~ % kubectl describe svc apple-service Name: apple-service Namespace: default Labels: <none> Annotations: <none> Selector: app=apple Type: NodePort IP Families: <none> IP: 10.105.135.144 IPs: 10.105.135.144 Port: <unset> 5678/TCP TargetPort: 5678/TCP NodePort: <unset> 31050/TCP Endpoints: 10.244.0.4:5678 Session Affinity: None External Traffic Policy: Cluster Events: <none> user@domain ~ % kubectl get endpoints apple-service NAME ENDPOINTS AGE apple-service 10.244.0.4:5678 2d18h
每次创建、删除服务或修改终结点时，都会 kube-proxy 更新 iptables 群集每个节点上的规则。查看链以了解 iptables 和跟踪请求的旅程。
首先，KUBE-NODEPORTS 链考虑了类型为的服务 NodePort数据包。
$ sudo iptables -L KUBE-NODEPORTS -t nat
Chain KUBE-NODEPORTS (1 references)
target prot opt source destination
KUBE-MARK-MASQ tcp -- anywhere anywhere /* default/apple-service */ tcp dpt:31050
KUBE-SVC-Y4TE457BRBWMNDKG tcp -- anywhere anywhere /* default/apple-service */ tcp dpt:31050
每个进入端口 31050 的数据包首先由 KUBE-MARK-MASQ 处理，它用一个值标记 0x4000 数据包。
接下来，数据包由 KUBE-SVC-Y4TE457BRBWMNDKG 链（在上面的 KUBE-NODEPORTS 链中引用）处理。如果我们仔细看一下，我们可以看到其他iptables链：
$ sudo iptables -L KUBE-SVC-Y4TE457BRBWMNDKG -t nat
Chain KUBE-SVC-Y4TE457BRBWMNDKG (2 references)
target prot opt source destination
KUBE-SEP-LCGKUEHRD52LOEFX all -- anywhere anywhere /* default/apple-service */
检查 KUBE-SEP-LCGKUEHRD52LOEFX 链，查看它们是否定义了到运行 apple-service 应用程序的后端 Pod 之一的路由。
$ sudo iptables -L KUBE-SEP-LCGKUEHRD52LOEFX -t nat Chain KUBE-SEP-LCGKUEHRD52LOEFX (1 references) target prot opt source destination KUBE-MARK-MASQ all -- 10.244.0.4 anywhere /* default/apple-service */ DNAT tcp -- anywhere anywhere /* default/apple-service */ tcp to:10.244.0.4:5678
这样就完成了 NodePort 服务请求从请求到达节点端口到服务请求到达后端 Pod 的旅程。
外部流量策略中的本地选项限制
设置为 as Local 的 externalTrafficPolicy NodePort 服务在 Contrail 网络版本 22.1 中不受支持。
表示 externalTrafficPolicy 此服务是希望将外部流量路由到节点本地终结点还是群集范围的终结点。
Local保留客户端源 IP 地址，并避免节点端口类型服务的第二个跃点。Cluster遮盖客户端源 IP 地址，并可能导致到另一个节点的第二个跃点。
Cluster 是 的 externalTrafficPolicy默认值。
更新或删除服务，或者从服务中移除容器
- 服务更新 - 可以更改任何可修改的字段，但
Name不包括 和Namespace。例如，可以通过更改Type服务 YAML 定义中的字段来更改为ClusterIp节点端口服务。 - 删除服务 - 可以使用以下命令删除服务（无论 如何
Type）：kubectl delete -n <name_space> <service_name> - 从服务中移除容器 - 这可以通过更改
Labels服务或容器上的 和Selector来实现。