Skip to main content

已知的问题和限制

本节包含了当前 rke2 的已知问题和限制。如果你遇到这里没有记录的 rke2 的问题,请在这里打开一个新问题。

Firewalld 与默认网络冲突#

Firewalld 与 RKE2 的默认 Canal(Calico + Flannel)网络堆栈有冲突。为了避免意外行为,Firewalld 应该在运行 RKE2 的系统上被禁用。

NetworkManager#

NetworkManager 操作默认网络命名空间中的接口的路由表,许多 CNI,包括 RKE2 的默认设置,为连接到容器创建 veth 对。这可能会干扰 CNI 的正确路由能力。因此,如果在启用 NetworkManager 的系统上安装 RKE2,强烈建议将 NetworkManager 配置为忽略 calico/flannel 相关网络接口。为了做到这一点,请在/etc/NetworkManager/conf.d中创建一个名为rke2-canal.conf的配置文件,其内容如下:

[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:flannel*

如果你还没有安装 RKE2,简单的 systemctl reload NetworkManager 就足以安装配置。如果在已经安装了 RKE2 的系统上执行这一配置变更,则需要重启节点以有效应用这一变更。

在一些操作系统中,如 RHEL 8.4,NetworkManager 包括两个额外的服务,称为nm-cloud-setup.servicenm-cloud-setup.timer。这些服务添加了一个路由表,干扰了 CNI 插件的配置。不幸的是,没有任何配置可以避免,正如issue中解释的那样。因此,如果存在这些服务,它们应该被禁用,并且节点必须重新启动。

Selinux 中的 Istio 执行系统默认失败#

这是由于 rke2 的实时内核模块加载,除非容器具有特权,否则在 Selinux 下是不允许的。为了让 Istio 在这些条件下运行,需要两个步骤:

  1. 启用 CNI作为 Istio 安装的一部分。请注意,这个功能在本文写作时仍处于 Alpha 状态。 确保values.cni.cniBinDir=/opt/cni/binvalues.cni.cniConfDir=/etc/cni/net.d
  2. 安装完成后,在 CrashLoopBackoff 中应该有cni-node pod。手动编辑它们的守护程序,在install-cni容器上加入securityContext.privileged: true

这可以通过自定义 overlay 来执行,如下所示:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
components:
cni:
enabled: true
k8s:
overlays:
- apiVersion: "apps/v1"
kind: "DaemonSet"
name: "istio-cni-node"
patches:
- path: spec.template.spec.containers.[name:install-cni].securityContext.privileged
value: true
values:
cni:
image: rancher/mirrored-istio-install-cni:1.9.3
excludeNamespaces:
- istio-system
- kube-system
logLevel: info
cniBinDir: /opt/cni/bin
cniConfDir: /etc/cni/net.d

如果需要,也可以直接通过 Rancher进行。更多关于未执行这些步骤时故障与详细日志的信息,请参见 Issue 504

Control Groups V2#

越来越多的 Linux 发行版开始使用支持 cgroups v2 的内核和用户空间,例如从 Fedora 31 开始。然而,在写这篇文章的时候,RKE2 内置的containerd是 1.3.x 的分叉版本(有 1.4.x 版本的 SELinux 提交),不支持 cgroups v2。 在 RKE2 发布containerdv1.4.x 版本之前,在支持 cgroups v2 的系统上运行它需要一些前期的配置。

假设是基于 systemd 的系统,设置systemd.unified_cgroup_hierarchy=0内核参数将向 systemd 表明它应该以混合(cgroups v1 + v2)方式运行。结合上述情况,设置 systemd.legacy_systemd_cgroup_controller 内核参数将向 systemd 表明它应该以传统(cgroups v1)的方式运行。由于这些参数是内核命令行参数,因此必须在系统引导程序中设置,以便在/sbin/init中作为 PID 1 传递给systemd

参见:

Calico 与 vxlan 封装#

Calico 在使用 vxlan 封装且 vxlan 接口的校验和卸载开启时遇到了一个内核错误。这个问题在calico 项目rke2 项目。我们的临时解决方法是通过应用值来禁用校验和卸载,在calico helm chart中使用 ChecksumOffloadBroken=true 的值。

这个问题已经在 Ubuntu 18.04、Ubuntu 20.04 和 openSUSE Leap 15.3 中被观察到。

Last updated on by kingsd041