如何化解 Kubernetes 网络的复杂性？

本文将以带有两个 Linux 节点的标准 Google Kubernetes Engine（GKE）集群为例，通过跟踪 HTTP 请求被传送到集群服务的整个过程，深度拆解 Kubernetes 网络的复杂性。

当一个人在浏览网页时，他首先单击一个链接，发生了一些事，之后目标页面就被加载出来。这让人不免好奇，从单击链接到页面加载，中间到底发生了什么？

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: hello-world  labels:    app: hello-worldspec:  selector:    matchLabels:      app: hello-world  replicas: 2  template:    metadata:      labels:        app: hello-world    spec:      containers:      - name: hello-world        image: gcr.io/google-samples/node-hello:1.0        imagePullPolicy: Always        ports:        - containerPort: 8080          protocol: TCP
---apiVersion: v1kind: Servicemetadata:  name: hello-worldspec:  selector:    app: hello-world  ports:  - port: 80    targetPort: 8080    protocol: TCP  type: LoadBalancer  externalTrafficPolicy: Cluster

• Node - 10.138.15.0/24
• Cluster - 10.16.0.0/14
• Service - 10.19.240.0/20

已知服务在集群 CIDR 中的虚拟 IP 地址（VIP）是 10.19.240.1。现在，我们可以从负载均衡器开始，深入跟踪请求进入 Kubernetes 集群的整个“旅程”。

Kubernetes 通过本地控制器和 Ingress 控制器提供了很多公开服务的方法，但这里我们还是使用 LoadBalancer 类型的标准 Service 资源。

每个节点都有一个 kube-proxy 容器进程（在 Kubernetes 参考框架中，kube-proxy 容器位于 kube-system 命名空间的 Pod 中），它负责把寻址到集群 Kubernetes 服务对象虚拟 IP 地址的流量转发到相应后端 Pod。kube-proxy 当前支持三种不同的实现方式：

• User space：即用户空间，服务路由是在用户进程空间的 kube-proxy 中进行的，而不是内核网络堆栈。这是kube-proxy 的最初版本，较为稳定，但是效率不太高；
• iptables：这种方式采用 Linux 内核级 Netfilter 规则为 Kubernetes Services 配置所有路由，是大多数平台实现 kube-proxy 的默认模式。当对多个后端 Pod 进行负载均衡时，它使用未加权的循环调度；
• IPVS：IPVS 基于 Netfilter 框架构建，在 Linux 内核中实现了 L4 负载均衡，支持多种负载均衡算法，连接最少，预期延迟最短。它从 Kubernetes v1.11 中开始普遍可用，但需要 Linux 内核加载 IPVS 模块。它也不像 iptables 那样拥有各种 Kubernetes 网络项目的广泛支持。

那么，通过负载均衡器的请求是如何成功建立连接的呢？如果 kube-proxy 在用户空间模式下运行，它实际上是将连接代理到后端 Pod。但是，在 iptables 模式下，kube-proxy 配置了 Netfilter 链，因此该连接被节点的内核直接路由到了后端容器的端点。

在我们的 GKE 集群中，如果登录到其中一个节点并运行 iptables，我们可以看到这些规则。

• KUBE-MARK-MASQ 向发送到 hello-world 服务的包（来自集群网络外部）添加一个 Netfilter 标记。带有此标记的数据包将按照 POSTROUTING 规则进行更改，以使用源网络地址转换（SNAT），并将节点 IP 地址作为其源 IP 地址；
• KUBE-SVC-33X6KPGSXBPETFQV 链适用于所有与 hello-world 服务相关的流量（与源无关），并且对每个服务端点（在本例中为两个 Pod）提供规则。使用哪个端点链是完全随机确定的：
• KUBE-SEP-ALRUKLHE5DT3R34X：如果需要，KUBE-MARK-MASQ 会再次向数据包中添加一个 Netfilter 标记用以 SNAT；DNAT 规则使用 10.16.0.11:8080 端点作为目标来设置目标 NAT
• KUBE-SEP-X7DMMHFVFOT4JLHD：如果需要，KUBE-MARK-MASQ 会再次为数据包添加一个 Netfilter 标记用以 SNAT；DNAT 规则使用 10.16.1.8:8080 端点作为目标来设置目标 NAT
• KUBE-MARK-DROP 向此时尚未启用目标 NAT 的数据包添加 Netfilter 标记。这些数据包将在 KUBE-FIREWALL 链中被丢弃。

因此，Local 策略通常需要与 Kubernetes daemon sets 一起使用，后者会在集群中的每个节点上调度一个 Pod。虽然前者能明显降低请求的平均网络延迟，但它也可能导致服务 Pods 之间的负载不均衡。

以下是是我们获取 HTTP 200 响应代码的方式：

• 容器网络接口（CNI）插件：每个云提供商默认使用与其 VM 网络模型兼容的 CNI 实现。本文以默认设置的 GKE 集群为例，但如果是 Amazon EKS，那会很不一样，因为 AWS VPC CNI 把容器直接放在节点的 VPC 网络上；

• Kubernetes Network Policy：Calico 是实施网络策略最受欢迎的 CNI 插件之一，它在节点上为每个 Pod 创建一个虚拟网络接口，并使用 Netfilter 规则来实施其防火墙规则；

• 尽管大多数情况下仍然使用 Netfilter，但 kube-proxy IPVS 路由模式通常会把服务路由和 NAT 移出 Netfilter 规则；

• 外部负载均衡器或其他可以将流量直接发送到服务节点端口的源将匹配 iptables 中的不同链（KUBE-NODEPORTS）；

• Kubernetes Ingress 控制器可以通过多种方式更改边缘服务路由；

• 诸如 Istio 之类的服务网格可能会绕过 kube-proxy，直接连接服务容器之间的内部路由。

Kubernetes 网络需要大量可移动部件，它非常复杂，但如果开发者对集群中发生的事有基本了解，这会有助于开发者更有效地监控、保护它。