My Blog

将 Calico 替换为 Antrea CNI

目录

  1. 将 Calico 替换为 Antrea CNI

    1. 概述

    2. Calico 环境准备

    3. 业务部署

      1. 测试 1

      2. 测试 2

      3. 测试 3

      4. 测试 4

      5. 测试 5

    4. 卸载 calico

    5. 删除后服务访问情况

      1. 测试 1

      2. 测试 2

      3. 测试 3

      4. 测试 4

      5. 测试 5

    6. 卸载 Calico 残留组件

    7. 安装 Antrea

    8. 重启节点上的 Pod

    9. 切换 CNI 后测试

      1. 测试 1

      2. 测试 2

      3. 测试 3

      4. 测试 4

      5. 测试 5

      6. 使用 acnp 替换 NetworkPolicy

概述

在 k8s 中，可能因为前期规划的一些原因使用了开源的 Calico，但使用中发现 Calico 的产品缺陷或者功能，需要更换为其他 CNI，比如 Antrea，本文便讲解下从 Calico 到 Antrea 的整个迁移过程。

Calico 环境准备

本文使用 Calico v3.26.1 版本，安装 yaml 链接如下：

https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

image-20230727192843166

安装完毕后节点状态及 Calico Pod 状态均正常：

image-20230727192937929

业务部署

在环境中我们进行下列几种业务及服务的测试：

  • Deploy1：3 个 Pod，通过 Nodeport 发布到集群外；

  • Statefulset1：3 个 Pod，通过 Service Type ClusterIP 发布；

  • Deploy2：使用自定义 Calico IP Pool 创建命名空间，通过 Nodeport 发布到集群外；

  • 安装 Nginx Ingress Controller：通过 Nodeport 发布到集群外，创建 Ingress 服务，关联 Deploy1；

  • 设置 NetworkPolicy，限制某个 IP 到 Deploy1 的访问

测试 1

发布后通过 NodePort 可以正常访问：

image-20230728145148344

测试 2

测试 3

创建自定义 IPpool，然后关联给 namespace，在该 namespace 下创建 Pod：

测试 4

安装 Nginx Controller：

创建 Ingress：

通过 NodePort 访问正常：

image-20230728161315070

查看 Nginx 上的访问的日志：

测试 5

未创建 NetworkPolicy 之前，Master 节点可以正常访问应用（通过 ClusterIP 访问，NetworkPolicy 无法对 NodePort 来的访问做控制，其源 IP 会被转化为 NodeIP）

创建下列 NetworkPolicy，仅允许 10.0.0.0/8 访问该服务的 80 端口，禁止 Master 10.10.50.65 访问该应用：

之后外部无法访问：

卸载 calico

删除后服务访问情况

测试 1

  • Pod 看着运行正常，实则部分无法访问

  • NodePort 部分无法访问

在 Pod 所在节点访问其他 Pod，会发现通信正常：

如果 Pod 访问同 Worker 上的其他 Pod，部分访问正常：

跨节点访问不正常，提示没有路由，通过路由表查看到丢失到其他 Node 的路由：

Worker 访问 ClusterIP SVC，部分访问正常（这些正常的请求来自本地的 Pod 回应，也就是说在卸载 calico 后，IPtables 并没有立即删除，依然在工作）：

抓到的 IPtables 规则：

Nodeport 部分无法访问（部分来自外部的访问不正常，比如当请求发给本地没有 Pod 的节点时，或者 Worker 横向把流量交给了其他节点上的 Pod，但这时通信有问题导致这部分访问异常）：

测试 2

Worker 访问 ClusterIP SVC，部分访问正常，结果和测试 1 中的一致：

Endpoint 的结果和卸载前一致：

测试 3

通过自定义 IPPool 创建的 Pod 运行正常，

Worker 访问 ClusterIP SVC，部分访问正常，结果和测试 1 中的一致：

Nodeport 部分来自外部的访问不正常，比如当请求发给本地没有 Pod 的节点时，或者 Worker 横向把流量交给了其他节点上的 Pod，但这时通信有问题导致这部分访问异常，结果和测试 1 一致。

测试 4

  • 外部到 Nginx 所在节点时请求才可能正常（Nginx Controller 并不是在所有节点部署的，所以只有访问到 Nginx 所在 Worker 时才能通信）

  • 部分访问异常（Nginx Controller 不会检测后端 Pod 通信情况，可能把流量转发到其他节点的 Pod 上）

测试 5

Network Policy 依然会存在，但因为网络已经无法访问，所以实际上 Network Policy 不会起到任何作用。

卸载 Calico 残留组件

安装 Antrea

应用 antrea.yaml

安装完成后确保 Antrea 相关的 Pod 为 Running：

Antrea 会在 IPtables 中加入下列项：

重启节点上的 Pod

可以通过 drain 一一驱逐节点上的 Pod：

之后 Worker 1 上的 Pod 会在其他节点重建：

之后再 uncordon该节点：

drain 另一个节点：

所有 Pod 在 worker1 上重建，以前通过 Calico IPPool 创建的 Pod 在 Antrea 下会被用默认的 CIDR 创建：

切换 CNI 后测试

测试 1

所有 Pod 及服务运行正常：

外部通过 NodePort 访问应用均正常：

进入 Worker 节点的 Antrea-Agent 容器中，查看流表：

测试 2

访问 Statefulset 均正常：

测试 3

Pod 均运行正常：

测试 4

Ingress Controller 运行正常：

在 Nginx 日志中可以看到外部的访问记录，使用 RR 的形式发送给 Pod：

测试 5

Network Policy 运行正常，10.0.0.0/8 网络仅能访问 Pod 的 TCP 80，ping 之类的操作会被拒绝：

调整此 Network Policy，禁止 10.39.0.1 （Master 节点）访问该服务，再次测试，所有访问都被拒绝：

使用 acnp 替换 NetworkPolicy

因为 Kubernetes 默认的 NetworkPolicy 功能非常弱，所以使用 Antrea 的 ACNP 来进行替换：

应用上述文件后再次进行访问，观察到 web 访问正常，ping 被拒绝：

登陆 Pod 所在节点查看 ACNP 的日志：

这有帮助吗？