【译】kube-router-8 操作指南

kube-router 的健康检查

kube-router 目前的基本健康检查方式是，每次主循环成功完成后，每个控制器都会向 healthcontroller发送心跳。

健康端口默认为 20244，但可通过启动选项进行更改。健康检查路径为 /healthz.

--health-port=<port number>

如果端口设置为 0（零），HTTP 端点将不可用，但健康控制器仍将运行，并将错过的心跳打印到 kube-router 的 STDERR 中。

如果控制器在控制器同步时间 + 5 秒内没有发送心跳，组件将被标记为不健康。

如果任何正在运行的组件出现故障，整个 kube-router 状态将在 /healthz 端点里标记为失败。

例如，当以下标志启动 kube-router时

--run-router=true
--run-firewall=true
--run-service-proxy=true
--run-loadbalancer=true

如果路由控制器、策略控制器或服务控制器退出主循环，并且没有发布心跳信息
/healthz 端点将返回错误 500，表明 kube-router 不健康。

可观测性

使用指标观察 kube-router

更多信息请参阅 指标文档

观察因网络策略执行而丢弃的流量

由于网络策略强制执行而被拒绝的流量会被 kube-route 使用 iptables NFLOG target
记录在组 100 下。观察 kube 路由器丢弃数据包的最简单方法是在 nflog:100 接口上运行 tcpdump。例如 tcpdump -i nflog:100 -n。您还可以配置 ulogd，以所需的输出格式监控丢弃的数据包。请参阅ulogd 官方文档，了解设置堆栈以记录数据包的配置示例。

Pod 工具箱

当 kube-router 作为一个 Pod 运行在 Kubernetes 集群中时，它还会自动为集群配置一些工具。 这些工具可可用于排除故障，并进一步了解集群网络是如何执行的。

登录

这里有一个在集群中随机节点上快速启动的方法：

KR_POD=$(basename $(kubectl -n kube-system get pods -l k8s-app=kube-router --output name|head -n1))
kubectl -n kube-system exec -it ${KR_POD} bash

如果您想调查某个特定节点，可以使用 kubectl -n kube-system get pods -l k8s-app=kube-router -o wide 查看哪些节点运行哪些pod。

工具和使用

登录后，你会看到一些使用容器中工具的帮助。

例如:

Welcome to kube-router on "node1.zbrbdl"!

可以使用如下工具进行调试:
- ipvsadm | 收集虚拟服务器和真实服务器的信息
IPVS.
          | 栗子:
          |   ## 显示所有选项
          |   ipvsadm --help
          |   ## 列出IPVS使用的服务和端点信息
          |   ipvsadm -ln
          |   ## 显示流量速率信息
          |   ipvsadm -ln --rate
          |   ## 显示汇总流量
          |   ipvsadm -ln --stats

- gobgp   | 获取节点上的BGP信息.
          |
          | 可以使用Tab命令完成功能, 只需输入 "gobgp "就可以看到可           | 用的子命令
          |
          | 默认情况下gobgp职务显示pod运行的所在节点上的bgp信息。                 | 如"node1.zbrbdl". 查询其他节点可以使用类似 "gobgp --host             | node02.mydomain" 的命令。
          | 更多信息请参考: https://github.com/osrg/gobgp/blob/master/docs/sources/cli-command-syntax.md

下面快速查看当前节点上发生了什么:
--- BGP Server Configuration ---
AS:        64512
Router-ID: 10.10.3.2
Listening Port: 179, Addresses: 0.0.0.0, ::

--- BGP Neighbors ---
Peer    AS     Up/Down State       |#Received  Accepted
 64512 2d 01:05:07 Establ      |        1         1

--- BGP Route Info ---
   Network              Next Hop             AS_PATH                  Age        Attrs
*> 10.2.0.0/24          10.10.3.3            4000 400000 300000 40001 2d 01:05:20 [{Origin: i} {LocalPref: 100}]
*> 10.2.1.0/24          10.10.3.2            4000 400000 300000 40001 00:00:36   [{Origin: i}]

--- IPVS Services ---
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.3.0.1:443 rr persistent 10800 mask 0.0.0.0
  -> 10.10.3.2:443                Masq    1      0          0
TCP  10.3.0.10:53 rr
  -> 10.2.0.2:53                  Masq    1      0          0
TCP  10.3.0.15:2379 rr
  -> 10.10.3.3:2379               Masq    1      45         0
TCP  10.3.0.155:2379 rr
  -> 10.10.3.3:2379               Masq    1      0          0
UDP  10.3.0.10:53 rr
  -> 10.2.0.2:53                  Masq    1      0          0

负载均衡分配器

作用

负载均衡分配器控制器会查找 LoadBalancer 类型的服务，并在需要时尝试为其分配地址。控制器默认情况下不会启用任何地址公告功能，因此应将 --advertise-loadbalancer-ip设置为 true 并配置 BGP 对等节点。

负载平衡器类别

默认情况下，控制器会为所有负载平衡器服务分配地址，这些服务的loadBalancerClass 为空或 "default "或 "kube-router "。如果 --loadbalancer-default-class设置为 false，控制器只处理类设置为 "kube-router "的服务。

RBAC 权限

控制器需要一些额外的权限来获取、创建和更新领导者选举的租约，以及更新已分配地址的服务。
栗子:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kube-router
  namespace: kube-system
rules:
  - apiGroups:
      - "coordination.k8s.io"
    resources:
      - leases
    verbs:
      - get
      - create
      - update
  - apiGroups:
      - ""
    resources:
      - services/status
    verbs:
      - update

环境变量

控制器使用环境变量 POD_NAME 作为用于选举领导者的租期标识。使用 kubernetes downward api 将 POD_NAME 设置为 租约标识将与当前领导者匹配的pod 名称。

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    k8s-app: kube-router
    tier: node
  name: kube-router
  namespace: kube-system
spec:
  ...
  template:
    metadata:
      ....
    spec:
        ...
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
...

还可以指定环境变量 POD_NAMESPACE，以设置租约使用的命名空间。
默认情况下，命名空间可以通过 pod 的/var/run/secrets/kubernetes.io/serviceaccount/namespace查找。

在 kubernetes 外部运行

在 pod 外运行控制器时，必须同时设置 POD_NAME 和 POD_NAMESPACE 才能使控制器工作。
每个实例的 POD_NAME 都应是唯一的，因此使用机器的主机名可能是个好主意。
在同一群集中运行的所有实例中，POD_NAMESPACE 必须相同。

注意

外部运行无法指定负载平衡器服务的地址。可以使用externalIP服务来代替。

kube-router 中的 IPv6 / 双协议栈支持

本小节描述了 kube-router 中的 IPv6 / 双协议栈支持的现状、未来计划和通常想法。

Kubernetes 自版本 v1.21 起就支持双协议栈（如 IPv4 和 IPv6）：
IPv4/IPv6 双协议栈文档

kube-router 目前的方法是逐个功能实现双协议栈功能：

• CNI --enable-cni
• Proxy --run-service-proxy
• Router --run-router
• Network policies --run-firewall

现状（2023 年 10 月 7 日）

kube-router 对双协议栈的支持功能已完成。版本 v2.0.0 及以上的 kube-router 已将所有控制器更新，以兼容双协议栈。

重要说明/已知限制等

这是 kube-router 的一个重要版本，因此用户在将其部署到已运行的kube-router 环境时应小心谨慎。据维护者所知，目前还没有发现任何重大错误、在向后兼容性方面存在一些小的缺陷。下面我们将尽可能详细地介绍这些问题。

如何启用双协议栈功能

要启用双协议栈功能，请确保以下内容：

• 设置 kube-router 选项 --enable-ipv4=true（这是默认设置）
• 已设置 kube-router 选项 --enable-ipv6=true
• 你的 Kubernetes 节点的物理接口上有 IPv4 和 IPv6 地址
• 您的 Kubernetes 节点的节点规格中同时包含 IPv4 和 IPv6 地址:

$ kubectl describe node foo
...
Addresses:
  InternalIP:  10.95.0.202
  InternalIP:  2001:1f18:3d5:ed00:d61a:454f:b886:7000
  Hostname:    foo
...

• 为 IPv6 地址添加额外的 -service-cluster-ip-range 和 -service-external-ip-range kube-router 参数。

• 如果使用 --enable-cni=true，请确保 kube-controller-manager 已同时以 IPv4 和 IPv6 集群 CIDR 启动（例如 --enable-cni=true）。
  CIDRs (如 --cluster-cidr=10.242.0.0/16,2001:db8:42:1000::/56)

• 确保以 IPv4 和 IPv6 服务集群 IP 范围启动了 kube-controller-manager 和 kube-apiserver ranges (e.g. –service-cluster-ip-range=10.96.0.0/16,2001:db8:42:1::/112`)

隧道名称更改（可能会造成破坏性更改）

为了同时支持 IPv4 和 IPv6 隧道，我们必须更改当前隧道名称的散列格式。因此，如果您在原地升级 kube-router（即不重启），那么 kube-router 很可能不会清理旧隧道。

这只会在一定程度上影响使用 kube-router 的覆盖功能的用户。例如运行 kube-router 时使用"–enable-overlay “或”–overlay-type=full “或”–overlay-type=subnet"（需要注意的是，这些选项目前默认为开启。

如果您要将 kube-router 从 v2.0.0 之前的版本升级到 v2.0.0，我们建议您升级 kube-router和滚动重启 Kubernetes 机群协同进行，以清理 kube-router 以前版本遗留的任何隧道。

–override-nexthop 的区别

虽然 kube-router 的 v2.X 及以上版本兼容 IPv6，并能同时公布 IPv4 和 IPv6 地址，但它仍然是通过单个 BGP 对等互联来实现的。这种对等关系是通过 kube-router 认定的节点主 IP 地址建立的。这通常是节点的 Kubernetes 元数据（例如，kubectl get node）中列出的第一个内部 IP 地址。除非被 本地地址注解 配置覆盖。

该地址可以是 IPv4 或 IPv6 地址，kube-router 将使用该地址进行对等互联。没有
override-nexthop "的情况下，kube-router 会确保 公式与IP族匹配的IP 或子网。但是，启用 --override-nexthop 后，kube-router 无法控制公示的路由的下一跳的地址或者ip族。相反，下一跳将会被用于与kube-router 对等的 IP 所覆盖。

这会给许多配置带来麻烦，因此不建议在双栈kube 路由器配置中使用--override-nexthop。

启用的 Kubernetes 工作节点之间广告 Pod IP 子网时，问题尤为突出。在启用了kube-router工作节点的集群中，不同kube-router节点之间会相互公示pod IP 子网。使用overlay网络的工作节点会通过 BGP 协议公示感知其邻居。"–override-nexthop "意味着一个地址族将永远无法正常工作。因此，我们不再将 --override-nexthop设置应用于 pod 子网公示。这是 kube-router v1.X 和 v2.x 版本之间的不同功能。

kube-router.io/node.bgp.customimportreject 只能包含单一家族的 IP

由于 GoBGP 的实施限制，注解 kube-router.io/node.bgp.customimportreject允许用户添加规则以拒绝发送到 GoBGP 的特定路由，但只适用于单一 IP 族（如 IPv4 或 IPv6）。在导入BGP策略时试图添加两个不同IP族的ip时会导致BGP错误。

IPv6 和 IPv4 网络策略范围只有在该IP族已启用的情况下才能工作

Kubernetes 中的网络策略允许用户为入口和出口策略指定IPBlock范围。这些块是基于字符串的网络 CIDR，允许用户指定他们希望的任何范围，以允许入口和出口策略。
这些区块是基于字符串的网络 CIDR，允许用户指定他们想要作为入口或出口的任何范围，而使用 Kubernetes pod选择器无法做到。

目前，kube-router 只能在使用
--enable-ipv4=true & --enable-ipv6=true CLI 标志启用的 IP 系列的 CIDR。如果用户为某个 IP 族添加网络策略，如果为未启用的 IP 系列添加网络策略，在 kube-router 日志中看到警告，并且也不会添加防火墙规则。

过时的kube-router.io/pod-cidr

由于 kube-router 已具备双协议栈功能，因此不再使用只能表示单个 pod CIDR 的注解了。单个 pod CIDR 的注解不再有意义。因此，我们将在本版本中宣布废弃
kube-router.io/pod-cidr "注解，转而使用新的 "kube-router.io/pod-cidrs "注解。

新的 kube-router.io/pod-cidrs 注解是一个以逗号分隔的 CIDR 列表，可以字符串形式保存 IPv4 或 IPv6 CIDR。

应该注意的是，在未来某个时候完全删除 kube-router.io/pod-cidr 之前，仍将优先 kube-router.io/pod-cidr ，以便尽可能保持向后兼容。在 "kube-router.io/pod-cidr "完全退役之前，使用旧注解的用户将在他们的 kube-router log 中收到一个警告警告，提醒他们应更改为新注解。

这里建议的操作是，在升级时，将使用 kube-router.io/pod-cidr 的节点转换为新的kube-router.io/pod-cidrs 注解。由于 kube-router 目前只在开始时更新节点注解，而不是在节点更新时.因此在开始时进行是安全的。

如果两个注解都未指定，kube-router 将使用 Kubernetes 节点规范中的 PodCIDRs 字段，该字段由 kube-config.io/pod-cidr 填充。
这个字段是kube-controller-manager “作为其”–allocate-node-cidrs "功能的一部分而填入的。

CNI 现在可接受多个 Pod 范围

kube-router支持双协议栈，也支持 CNI 文件中的多个范围。通过节点配置（如 kube-router.io/pod-cidr）或 .node.Spec.PodCIDRs可将 Pod CIDR 添加到 CNI 配置中，你也可以自定义自己的 CNI 以添加额外的范围或插件。

多个范围的 CNI 配置栗子如下：

{
  "cniVersion": "0.3.0",
  "name": "mynet",
  "plugins": [
    {
      "bridge": "kube-bridge",
      "ipam": {
        "ranges": [
          [
            {
              "subnet": "10.242.0.0/24"
            }
          ],
          [
            {
              "subnet": "2001:db8:42:1000::/64"
            }
          ]
        ],
        "type": "host-local"
      },
      "isDefaultGateway": true,
      "mtu": 9001,
      "name": "kubernetes",
      "type": "bridge"
    }
  ]
}