Kubernetes 网络介绍（二）

The Kubelet

Kubelet 是在集群中的每个工作节点上运行的单个二进制文件。在较高级别上，Kubelet 负责管理调度到节点的任何 Pod，并为节点及其上的 Pod 提供状态更新。然而，Kubelet 主要充当节点上其他软件的协调器。 Kubelet 管理容器网络实现（通过 CNI）和容器运行时（通过 CRI）。

从技术上讲，某些集群在受限工作节点上运行 API 服务器和 etcd。这种设置可以允许使用与典型工作负载相同的自动化方式来管理控制平面组件，但会暴露额外的故障模式和安全漏洞。

当控制器（或用户）在 Kubernetes API 中创建 pod 时，它最初仅作为 pod API 对象存在。 Kubernetes 调度程序会监视此类 pod，并尝试选择一个有效的节点来将该 pod 调度到其中。这种调度有几个限制。我们的 Pod 及其 CPU/内存请求不得超过节点上剩余的未请求的 CPU/内存。有许多选择选项可用，例如对标记节点或节点上其他标记的 pod 或污点的亲和力/反亲和力。假设调度程序找到一个满足 pod 所有约束的节点，调度程序会将该节点的名称写入 pod 的 nodeName 字段。假设 Kubernetes 将 pod 调度到节点 1：

apiVersion: v1 
kind: Pod 
metadata: 
  name: example 
spec: 
  nodeName: "node-1" 
  containers: 
  - name: example 
    image: example:1.0 

Node-1 上的 Kubelet 监视安排给它的所有 Pod。等效的 kubectl 命令为 kubectl get pods -w --field-selector spec.nodeName=node-1。当 Kubelet 观察到我们的 pod 存在但不在节点上时，它就会创建它。我们将跳过 CRI 细节和容器本身的创建。一旦容器存在，Kubelet 就会向 CNI 发出 ADD 调用，告诉 CNI 插件创建 pod 网络。我们将在下一节中介绍接口和插件。

Pod Readiness And Probes

Pod 就绪情况是 Pod 是否准备好为流量提供服务的附加指示。

Pod 准备情况决定 Pod 地址是否显示在来自外部源的 Endpoints 对象中。其他管理 Pod 的 Kubernetes 资源（例如部署）会在决策时考虑 Pod 的准备情况，例如在滚动更新期间推进。在滚动部署期间，新的 Pod 已准备就绪，但由于某种原因，服务、网络策略或负载均衡器尚未为新的 Pod 准备好。这可能会导致服务中断或后端容量损失。应该注意的是，如果 pod 规范确实包含任何类型的探针，Kubernetes 默认对所有三种类型都成功。用户可以在 pod 规范中指定 pod 准备情况检查。从那里，Kubelet 执行指定的检查并根据成功或失败更新 pod 状态。

探针影响 Pod 的 .Status.Phase 字段。以下是 Pod 阶段及其描述的列表：

Pending

Pod 已被集群接受，但一个或多个容器尚未设置并准备好运行。这包括 Pod 等待调度的时间以及通过网络下载容器镜像所花费的时间。

Running

Pod已被调度到节点，所有容器也已创建。至少有一个容器仍在运行或者正在启动或重新启动。请注意，某些容器可能处于失败状态，例如处于 CrashLoopBackoff 状态。

Succeeded

Pod 中的所有容器已成功终止，并且不会重新启动。

Failed

Pod 中的所有容器均已终止，并且至少有一个容器因故障而终止。也就是说，容器要么以非零状态退出，要么被系统终止。

Unknown

由于某种原因，无法确定 Pod 的状态。此阶段通常是由于与 pod 应该运行的 Kubelet 通信时出现错误而发生的。

Kubelet 对 pod 中的各个容器执行多种类型的健康检查：活性探针(livenessProbe)、就绪探针(readinessProbe) 和启动探针 (startupProbe)。 Kubelet（以及节点本身）必须能够连接到该节点上运行的所有容器，以便执行任何 HTTP 运行状况检查。

每个探测都有以下三个结果之一：

Success

容器通过了诊断。

Failure

容器诊断失败。

Unknown

诊断失败，因此不应采取任何措施。

探针可以是 exec 探针（尝试在容器内执行二进制文件）、TCP 探针或 HTTP 探针。如果探测失败的次数超过 failureThreshold 次数，Kubernetes 将认为检查失败。其效果取决于探头的类型。

当容器的就绪性探测失败时，Kubelet 不会终止它。相反，Kubelet 会将失败写入 pod 的状态。

如果活性探测失败，Kubelet 将终止容器。如果误用或配置错误，活性探针很容易导致意外故障。活性探针的预期用例是让 Kubelet 知道何时重新启动容器。然而，作为人类，我们很快就会了解到，如果“出现问题，请重新启动”是一种危险的策略。例如，假设我们创建一个加载 Web 应用程序主页的活性探测器。此外，假设系统中容器代码之外的某些更改导致主页返回 404 或 500 错误。导致这种情况的常见原因有很多，例如后端数据库故障、所需的服务故障或暴露错误的功能标志更改。在任何这些场景中，活性探针都会重新启动容器。充其量，这也是无济于事的。重新启动容器不会解决系统其他地方的问题，并且可能很快使问题恶化。 Kubernetes 具有容器重新启动退避 (CrashLoopBackoff)，这会增加重新启动失败容器的延迟。如果有足够多的 pod 或足够快的故障，应用程序可能会从主页出现错误变成硬停机。根据应用程序的不同，Pod 也可能在重新启动时丢失缓存数据；在假设的降级期间，获取数据可能会很费力或无法获取。因此，请谨慎使用活性探针。当 Pod 使用它们时，它们仅依赖于它们正在测试的容器，没有其他依赖项。许多工程师都有特定的健康检查端点，它们提供最低限度的标准验证，例如“PHP 正在运行并为我的 API 提供服务”。启动探针可以在活跃探针生效之前提供一个宽限期。 在启动探测成功之前，活性探测不会终止容器。一个示例用例是允许容器花费许多分钟来启动，但如果容器在启动后变得不健康，则快速终止容器。

在示例 4-1 中，我们的 Golang Web 服务器有一个活性探针，它在端口 8080 上对路径 /healthz 执行 HTTP GET，而就绪探针在同一端口上使用 / 。

例 4-1。 Golang 最小网络服务器的 Kubernetes podspec

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: go-web
spec:
  containers:
  - name: go-web
    image: go-web:v0.0.1
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

此状态不会影响 pod 本身，但其他 Kubernetes 机制会对其做出反应。一个重要的例子是 ReplicaSets（以及扩展的部署）。失败的就绪性探测会导致 ReplicaSet 控制器将 Pod 计为未就绪，从而在太多新 Pod 不健康时导致部署停止。 Endpoints/EndpointSlice 控制器也会对失败的就绪探针做出反应。如果 Pod 的就绪性探测失败，则该 Pod 的 IP 地址将不会出现在端点对象中，并且服务不会将流量路由到它。我们将在后续更多地讨论服务和端点。

startupProbe 将通知 Kubelet 容器内的应用程序是否启动。该调查优先于其他调查。如果 pod 规范中定义了startupProbe，则所有其他探针都会被禁用。一旦startupProbe成功，Kubelet将开始运行其他探测器。但如果启动探测失败，Kubelet 将终止容器，容器执行其重启策略。与其他探针一样，如果startupProbe 不存在，则默认状态为成功。

探头可配置选项：

initialDelaySeconds

容器启动后、启动活动或就绪探测之前的秒数。默认0；最低 0。

periodSeconds

执行探测的频率。默认10；最少 1

timeoutSeconds

探测超时后的秒数。默认1；最少 1。

successThreshold

失败后探测成功的最小连续成功次数。默认1；对于活性和启动探针必须为 1；最少 1。

failureThreshold

当探测失败时，Kubernetes 会尝试多次然后放弃。在活性探针的情况下放弃意味着容器将重新启动。对于就绪性探测，Pod 将被标记为“未就绪”。默认3；最少 1。

应用程序开发人员还可以使用就绪门来帮助确定 Pod 内的应用程序何时准备就绪。自 Kubernetes 1.14 起可用且稳定，要使用就绪门，清单编写者将在 pod 规范中添加就绪门，以指定 Kubelet 评估 pod 就绪情况的附加条件列表。这是在 pod 规范中准备就绪门的 ConditionType 属性中完成的。条件类型是 Pod 条件列表中具有匹配类型的条件。就绪门由 pod 的 status.condition 字段的当前状态控制，如果 Kubelet 在 pod 的 status.conditions 字段中找不到这样的条件，则该条件的状态默认为 False。

正如您在以下示例中看到的，feature-Y 就绪门为 true，而 feature-X 为 false，因此 pod 的状态最终为 false：

kind: Pod
spec:
  readinessGates:
  - conditionType: www.example.com/feature-X
  - conditionType: www.example.com/feature-Y
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2021-04-25T00:00:00Z
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: 2021-04-25T00:00:00Z
    status: "False"
    type: www.example.com/feature-X
  - lastProbeTime: null
    lastTransitionTime: 2021-04-25T00:00:00Z
    status: "True"
    type: www.example.com/feature-Y
  containerStatuses:
  - containerID: docker://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    ready: true

AWS ALB 等负载均衡器可以在向 Pod 发送流量之前使用就绪门作为 Pod 生命周期的一部分。

Kubelet 必须能够连接到 Kubernetes API 服务器。在图 4-5 中，我们可以看到集群中所有组件建立的所有连接：

CNI

Kubelet 中的网络插件，使网络能够获取 Pod 和服务的 IP。

gRPC

用于从 API 服务器到 etcd 进行通信的 API。

Kubelet

所有 Kubernetes 节点都有一个 Kubelet，可确保分配给它的任何 pod 都在运行并配置为所需状态。

Cri

gRPC API 在 Kubelet 中编译，允许 Kubelet 使用 gRPC API 与容器运行时对话。容器运行时提供者必须使其适应 CRI API，以允许 Kubelet 使用 OCI 标准 (runC) 与容器对话。 CRI 由协议缓冲区、gRPC API 和库组成。

Figure 4-5. 集群组件之间的数据流

Pod 和 Kubelet 之间的通信通过 CNI 实现。在下一节中，我们将通过几个流行的 CNI 项目的示例来讨论 CNI 规范。

CNI 规范

CNI 规范本身非常简单。根据规范，CNI 插件必须支持四种操作：

Add

网络中添加容器。

DEL

从网络中删除容器。

CHECK

如果容器的网络出现问题，则返回错误。

VERSION

报告有关插件的版本信息。

在图 4-6 中，我们可以看到 Kubernetes（或运行时，CNI 项目指的是容器编排器）如何通过执行二进制文件来调用 CNI 插件操作。 Kubernetes 将 JSON 格式的命令的任何配置提供给 stdin，并通过 stdout 接收 JSON 格式的命令输出。 CNI 插件通常具有非常简单的二进制文件，它们充当 Kubernetes 调用的包装器，而二进制文件则对持久后端进行 HTTP 或 RPC API 调用。基于频繁启动 Windows 进程时的性能问题，CNI 维护人员已经讨论过将其更改为 HTTP 或 RPC 模型。

Kubernetes 一次仅使用一个 CNI 插件，尽管 CNI 规范允许多插件设置（即为一个容器分配多个 IP 地址）。 Multus 是一个 CNI 插件，它通过充当多个 CNI 插件的扇出来解决 Kubernetes 中的这一限制。

图 4-6。 CNI配置

CNI 插件

CNI 插件有两个主要职责：为 Pod 分配唯一的 IP 地址，并确保 Kubernetes 中存在到每个 Pod IP 地址的路由。这些职责意味着集群所在的总体网络决定了 CNI 插件的行为。例如，如果 IP 地址太少或者无法将足够的 IP 地址附加到节点，集群管理员将需要使用支持覆盖网络的 CNI 插件。硬件堆栈或使用的云提供商通常决定哪些 CNI 选项合适。后续将讨论主要的云平台以及网络设计如何影响 CNI 选择。

要使用 CNI，请将 --network-plugin=cni 添加到 Kubelet 的启动参数中。默认情况下，Kubelet 从目录 /etc/cni/net.d/ 读取 CNI 配置，并期望在 /opt/cni/bin/ 中找到 CNI 二进制文件。管理员可以使用 --cni-config-dir= <directory>覆盖配置位置，并使用 --cni-bin-dir= <directory>覆盖 CNI 二进制目录。

CNI 网络模型有两大类：扁平网络和覆盖网络。在扁平网络中，CNI 驱动程序使用集群网络中的 IP 地址，这通常需要许多 IP 地址可供集群使用。在覆盖网络中，CNI 驱动程序在 Kubernetes 内创建辅助网络，该网络使用集群的网络（称为底层网络）来发送数据包。覆盖网络在集群内创建虚拟网络。在覆盖网络中，CNI 插件封装数据包。覆盖网络增加了相当大的复杂性，并且不允许集群网络上的主机直接连接到 Pod。然而，覆盖网络允许集群网络变得更小，因为只有节点必须在该网络上分配 IP 地址。 CNI 插件通常还需要一种在节点之间通信状态的方法。插件采用非常不同的方法，例如将数据存储在 Kubernetes API 中的专用数据库中。

CNI插件还负责调用IPAM插件进行IP寻址。

IPAM 接口

CNI 规范有第二个接口，即 IP 地址管理 (IPAM) 接口，以减少 CNI 插件中 IP 分配代码的重复。 IPAM 插件必须确定并输出接口 IP 地址、网关和路由，如示例 4-2 所示。 IPAM 接口与 CNI 类似：一个二进制文件，其中包含标准输入的 JSON 输入和标准输出的 JSON 输出。

例 4-2。 IPAM 插件输出示例，来自 CNI 0.4 规范文档

{
  "cniVersion": "0.4.0",
  "ips": [
    {
      "version": "<4-or-6>",
      "address": "<ip-and-prefix-in-CIDR>",
      "gateway": "<ip-address-of-the-gateway>"  // Optional
    },
    // ... more IP configurations
  ],
  "routes": [
    {
      "dst": "<ip-and-prefix-in-cidr>",
      "gw": "<ip-of-next-hop>"  // Optional
    },
    // ... more routes
  ],
  "dns": {
    "nameservers": <list-of-nameservers>,  // Optional
    "domain": <name-of-local-domain>,  // Optional
    "search": <list-of-search-domains>,  // Optional
    "options": <list-of-options>  // Optional
  }
}

现在，我们将回顾集群管理员在部署 CNI 时可供选择的几个选项。

流行的 CNI 插件

Cilium 是开源软件，用于透明地保护应用程序容器之间的网络连接。 Cilium 是 L7/HTTP 感知的 CNI，可以使用与网络寻址分离的基于身份的安全模型在 L3-L7 上实施网络策略。Linux 技术 eBPF 为 Cilium 提供了动力。在后面，我们将深入研究网络策略对象；现在知道它们实际上是 Pod 级防火墙。

Flannel 专注于网络，是一种简单易用的方法来配置专为 Kubernetes 设计的第 3 层网络结构。如果集群需要网络策略等功能，管理员必须部署其他 CNI，例如 Calico。 Flannel 使用 Kubernetes 集群现有的 etcd 来存储其状态信息，以避免提供专用的数据存储。根据 Calico 的说法，它“将灵活的网络功能与随处运行的安全实施相结合，提供具有本机 Linux 内核性能和真正的云本机可扩展性的解决方案。” Calico 不使用覆盖网络。相反，Calico 配置使用 BGP 路由协议在主机之间路由数据包的第 3 层网络。 Calico 还可以与服务网格 Istio 集成，在服务网格和网络基础设施层解释和实施集群内工作负载的策略。

表 4-2 简要概述了可供选择的主要 CNI 插件。

表 4-2。主要 CNI 插件简要概述

让我们部署 Cilium 以使用示例 4-3 中的 Golang Web 服务器进行测试。我们需要一个 Kubernetes 集群来部署 Cilium。我们发现部署集群进行本地测试的最简单方法之一是 KIND，它代表 Docker 中的 Kubernetes。它将允许我们使用 YAML 配置文件创建一个集群，然后使用 Helm 将 Cilium 部署到该集群。

例 4-3。 Cilium 本地部署的 KIND 配置

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
  - role: worker
networking:
  disableDefaultCNI: true

1. 指定我们正在配置 KIND 集群
2. KIND配置的版本
3. 集群中的节点列表
4. 1个控制平面节点
5. 工作节点1
6. 工作节点2
7. 工作节点3
8. KIND 网络配置选项
9. 禁用默认网络选项，以便我们可以部署 Cilium

通过 KIND 集群配置 YAML，我们可以通过以下命令使用 KIND 创建该集群。如果这是您第一次运行它，则需要一些时间来下载工作和控制平面所有 Docker 镜像：

$ kind create cluster --config=kind-config.yaml Creating cluster "kind" ...

✓ Ensuring node image (kindest/node:v1.18.

2) Preparing nodes
✓ Writing configuration Starting control-plane Installing StorageClass Joining worker nodes Set kubectl context to "kind-kind" You can now use your cluster with: kubectl cluster-info --context kind-kind Have a question, bug, or feature request?

Let us know! https://kind.sigs.k8s.io/#community ߙ⊨/---
Always verify that the cluster is up and running with kubectl. $ kubectl cluster-info --context kind-kind Kubernetes master -> control plane is running at https://127.0.0.1:59511 KubeDNS is running at https://127.0.0.1:59511/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump.'

现在我们的集群已在本地运行，我们可以开始使用 Kubernetes 部署工具 Helm 安装 Cilium。根据其文档，Helm 是安装 Cilium 的首选方式。首先，我们需要添加 Cilium 的 Helm 存储库。或者，您可以下载 Cilium 的 Docker 镜像，最后指示 KIND 将 Cilium 镜像加载到集群中：

$ helm repo add cilium https://helm.cilium.io/
# Pre-pulling and loading container images is optional.

$ docker pull cilium/cilium:v1.9.1 
kind load docker-image cilium/cilium:v1.9.1 

现在 Cilium 的先决条件已经完成，我们可以使用 Helm 将其安装到集群中。 Cilium 有很多配置选项，Helm 通过 --set NAME_VAR=VAR 来配置选项：

$ helm install cilium cilium/cilium --version 1.10.1  --namespace kube-system NAME: Cilium LAST DEPLOYED: Fri Jan 1 15:39:59 2021 NAMESPACE: kube-system STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: You have successfully installed Cilium with Hubble. Your release version is 1.10.1. For any further help, visit https://docs.cilium.io/en/v1.10/gettinghelp/

Cilium 在集群中安装了几个部分：代理、客户端、操作员和 cilium-cni 插件：

Agent

Cilium 代理 cilium-agent 在集群中的每个节点上运行。该代理通过 Kubernetes API 接受配置，这些 API 描述了网络、服务负载平衡、网络策略以及可见性和监控要求。

Client (Cli)

Cilium CLI 客户端 (Cilium) 是与 Cilium 代理一起安装的命令行工具。它与同一节点上的 REST API 交互。 CLI 允许开发人员检查本地代理的状态和状况。它还提供了访问 eBPF 映射以直接验证其状态的工具。

Operator

操作员负责管理集群中的职责，该职责应按集群而不是按节点处理。

Cni Plugin

CNI 插件 (cilium-cni) 与节点的 Cilium API 交互，触发配置以提供网络、负载平衡和网络策略 pod。

我们可以使用 kubectl -n kube-system get pods --watch 命令观察集群中部署的所有这些组件：

$ kubectl -n kube-system get pods --watch

 NAME   | READY   | STATUS            |
|--------------------------------------------------|---------|-------------------|
| cilium-65kvp                                     | 0/1     | Init:0/2          |
| cilium-node-init-485lj                           | 0/1     | ContainerCreating |
| cilium-node-init-79g68                           | 1/1     | Running           |
| cilium-node-init-gfdl8                           | 1/1     | Running           |
| cilium-node-init-jz8qc                           | 1/1     | Running           |
| cilium-operator-5b64c54cd-cgr2b                  | 0/1     | ContainerCreating |
| cilium-operator-5b64c54cd-tblbz                  | 0/1     | ContainerCreating |
| cilium-pg6v8                                     | 0/1     | Init:0/2          |
| cilium-rsnqk                                     | 0/1     | Init:0/2          |
| cilium-vfhrs                                     | 0/1     | Init:0/2          |
| coredns-66bff467f8-dqzql                         | 0/1     | Pending           |
| coredns-66bff467f8-r5nl6                         | 0/1     | Pending           |
| etcd-kind-control-plane                          | 1/1     | Running           |
| kube-apiserver-kind-control-plane                | 1/1     | Running           |
| kube-controller-manager-kind-control-plane       | 1/1     | Running           |

| kube-proxy-k5zc2                  | 1/1   | Running   |
|-----------------------------------|-------|-----------|
| kube-proxy-qzhvq                  | 1/1   | Running   |
| kube-proxy-v54p4                  | 1/1   | Running   |
| kube-proxy-xb9tr                  | 1/1   | Running   |
| kube-scheduler-kind-control-plane | 1/1   | Running   |
| cilium-operator-5b64c54cd-tblbz   | 1/1   | Running   |

现在我们已经部署了 Cilium，我们可以运行 Cilium 连接检查以确保它正确运行：

$ kubectl create ns cilium-test
namespace/cilium-test created

$ kubectl apply -n cilium-test -f 
https://raw.githubusercontent.com/strongjz/advanced_networking_code_examples/master/chapter-4/connectivity-check.yaml

deployment.apps/echo-a created
deployment.apps/echo-b created
deployment.apps/echo-b-host created
deployment.apps/pod-to-a created
deployment.apps/pod-to-external-1111 created
deployment.apps/pod-to-a-denied-cnp created
deployment.apps/pod-to-a-allowed-cnp created
deployment.apps/pod-to-external-fqdn-allow-google-cnp created
deployment.apps/pod-to-b-multi-node-clusterip created
deployment.apps/pod-to-b-multi-node-headless created
deployment.apps/host-to-b-multi-node-clusterip created
deployment.apps/host-to-b-multi-node-headless created
deployment.apps/pod-to-b-multi-node-nodeport created
deployment.apps/pod-to-b-intra-node-nodeport created
service/echo-a created
service/echo-b created
service/echo-b-headless created
service/echo-b-host-headless created
ciliumnetworkpolicy.cilium.io/pod-to-a-denied-cnp created
ciliumnetworkpolicy.cilium.io/pod-to-a-allowed-cnp created
ciliumnetworkpolicy.cilium.io/pod-to-external-fqdn-allow-google-cnp created

连接测试将部署一系列使用各种连接路径的 Kubernetes 部署。连接路径有或没有服务负载平衡以及各种网络策略组合。 Pod 名称表示连接变体，就绪性和活跃度门表示测试的成功或失败：

$ kubectl get pods -n cilium-test -w
NAME                                   READY   STATUS
--------------------------------------|--------|---------
echo-a-57cbbd9b8b-szn94               1/1     Running
echo-b-6db5fc8ff8-wkcr6              1/1     Running
echo-b-host-76d89978c-dsjm8           1/1     Running
host-to-b-multi-node-clusterip-fd6868749-7zkcr  1/1     Running

host-to-b-multi-node-headless-54fbc4659f-z4rtd  1/1     Running
pod-to-a-648fd74787-x27hc                     1/1     Running
pod-to-a-allowed-cnp-7776c879f-6rq7z          1/1     Running
pod-to-a-denied-cnp-b5ff897c7-qp5kp           1/1     Running
pod-to-b-intra-node-nodeport-6546644d59-qkmck  1/1     Running
pod-to-b-multi-node-clusterip-7d54c74c5f-4j7pm 1/1     Running
pod-to-b-multi-node-headless-76db68d547-fhlz7  1/1     Running
pod-to-b-multi-node-nodeport-7496df84d7-5z872  1/1     Running
pod-to-external-1111-6d4f9d9645-kfl4x          1/1     Running
pod-to-external-fqdn-allow-google-cnp-5bc496897c-bnlqs 1/1     Running

现在 Cilium 管理集群的网络，我们将在本系列后面使用它来概述 NetworkPolicy。并非所有 CNI 插件都支持 NetworkPolicy，因此在决定使用哪个插件时，这是一个重要的细节。