既知の問題および制限事項

このセクションには、SUSE® Rancher Prime: RKE2に関する現在の既知の問題および制限事項が含まれています。ここに文書化されていないSUSE® Rancher Prime: RKE2に関する問題が発生した場合は、新しい問題を こちらに報告してください。

Firewalldはデフォルトのネットワーキングと競合します。

FirewalldはRKE2のデフォルトのCanal（Calico + Flannel）ネットワーキングスタックと競合します。予期しない動作を避けるために、RKE2を実行しているシステムではfirewalldを無効にする必要があります。firewalldを無効にしても、Canalが必要なルールを管理するために使用するカーネルのファイアウォール（iptables/nftables）は削除されません。カスタムファイアウォールルールはCalicoリソースを通じて実装できます。

NetworkManager

NetworkManagerは、RKE2のデフォルトを含む多くのCNIがコンテナへの接続のためにvethペアを作成するデフォルトのネットワーク名前空間内のインターフェースのルーティングテーブルを操作します。これにより、CNIが正しくルーティングする能力に干渉する可能性があります。そのため、NetworkManagerが有効なシステムにRKE2をインストールする場合は、NetworkManagerを構成してcalico/flannel関連のネットワークインターフェースを無視することを強くお勧めします。これを行うには、`/etc/NetworkManager/conf.d`に`rke2-canal.conf`という名前の設定ファイルを作成し、内容を次のようにします：

[keyfile]
unmanaged-devices=interface-name:flannel*;interface-name:cali*;interface-name:tunl*;interface-name:vxlan.calico;interface-name:vxlan-v6.calico;interface-name:wireguard.cali;interface-name:wg-v6.cali

まだRKE2をインストールしていない場合は、構成をインストールするために単純な`systemctl reload NetworkManager`で十分です。すでにRKE2がインストールされているシステムでこの構成変更を行う場合、変更を効果的に適用するためにノードの再起動が必要です。

RHEL 8.4のような一部のオペレーティングシステムでは、NetworkManagerには`nm-cloud-setup.service`と`nm-cloud-setup.timer`という2つの追加サービスが含まれています。 これらのサービスは、CNIプラグインの構成に干渉するルーティングテーブルを追加します。残念ながら、 問題で説明されているように、それを回避するための構成はありません。したがって、これらのサービスが存在する場合は、無効にする必要があります。

NetworkManager-1.30.0-11.el8_4より前では、追加サービスを無効にした後にノードを再起動する必要があります。

Istioは、SELinuxがEnforcingモードのシステムでは、デフォルトで正常に動作しません。

これは、RKE2のジャストインタイムカーネルモジュール読み込みが原因で、コンテナが特権モードでない限り、SELinux下では許可されていません。これらの条件下でIstioを実行するには、2つのステップが必要です：

  1. Istioインストールの一部としてCNIを有効にする。この 機能は、執筆時点でまだアルファ状態であることに注意してください。 `values.cni.cniBinDir=/opt/cni/bin`と`values.cni.cniConfDir=/etc/cni/net.d`を確認してください。

  2. インストールが完了した後、CrashLoopBackoffにある`cni-node`ポッドがあるはずです。それらのデーモンセットを手動で編集して、`securityContext.privileged: true`を`install-cni`コンテナに含めてください。

これは、次のようにカスタムオーバーレイを介して実行できます：

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

これらの手順に従わない場合の詳細なログを伴う正確な失敗に関する詳細情報については、 問題504を参照してください。

vxlanカプセル化を使用したCalico

Calicoは、vxlanカプセル化を使用しているときにカーネルバグに遭遇し、vxlanインターフェースのチェックサムオフロードがオンになっています。この問題は、 calicoプロジェクトおよび rke2プロジェクトで説明されています。私たちが適用している回避策は、 calico helmチャートに値`ChecksumOffloadBroken=true`を適用することによって、デフォルトでチェックサムオフロードを無効にすることです。

この問題は、Ubuntu 18.04、Ubuntu 20.04、およびopenSUSE Leap 15.3で観察されています。

ウィキッド

ウィキッドは、ホストのネットワーク設定をsysctl設定ファイル（例：/etc/sysctl.d/ディレクトリ内）に基づいて構成します。RKE2が`/net/ipv4/conf/all/forwarding`のようなパラメータを1に設定しているにもかかわらず、その設定はウィキッドによってネットワーク設定が再適用されるたびに元に戻される可能性があります（ネットワーク設定を再適用する結果となるイベントがいくつかあり、更新中にrcwickedを再起動します）。したがって、sysctl設定ファイルでipv4（およびデュアルスタックの場合はipv6）転送を有効にすることが非常に重要です。例えば、これらのパラメータを含む`/etc/sysctl.d/90-rke2.conf`という名前のファイルを作成することが推奨されます（デュアルスタックの場合にのみipv6が必要です）：

net.ipv4.conf.all.forwarding=1
net.ipv6.conf.all.forwarding=1

カナルとIP枯渇

これには二つの可能な理由があります：

  1. iptables バイナリがホストにインストールされておらず、hostPortを定義するポッドがあります。ポッドにはIPが与えられますが、その作成はエラーとなり、Kubernetesはそれを再作成しようとし続け、試みるたびに1つのIPを消費します。以下のようなエラーメッセージがcontainerdのログに表示されます。これがエラーを示すログです。

    plugin type="portmap" failed (add): failed to open iptables: exec: "iptables": executable file not found in $PATH

    この問題を解決するには、iptablesまたはxtables-nftパッケージをインストールしてください。

  2. デフォルトでは、Canalは`/var/lib/cni/networks/k8s-pod-network`内の各IPのためにロックファイルを作成することでポッドIPを追跡します。各IPは単一のポッドに属し、ポッドが削除されるとすぐに削除されます。しかし、containerdが実行中のポッドの追跡を失うというまれな事態が発生した場合、ロックファイルが漏れ、CanalはそれらのIPを再利用できなくなります。これが発生すると、IP枯渇エラーが発生する可能性があります。例えば：

    failed to allocate for range 0: no IP addresses available in range set

これを解決する方法は二つあります。未使用のIPをそのディレクトリから手動で削除するか、ノードをドレインし、rke2-killall.shを実行し、RKE2のsystemdサービスを開始し、ノードをアンコルドンします。これらのアクションを実行する必要がある場合は、問題をGitHubで報告し、どのようにトリガーされたかを明記してください。

CISモードのIngress

デフォルトでは、`profile`パラメータで選択されたCISプロファイルでRKE2が実行されると、Ingressに対して制限的なネットワークポリシーが適用されます。これに加えて、`rke2-ingress-nginx`チャートがデフォルトで`hostNetwork: false`を持っているため、ユーザーはIngress URLへのアクセスを許可するために独自のネットワークポリシーを設定する必要があります。以下は、適用された名前空間内の任意のワークロードへのIngressを許可するネットワークポリシーの例です。詳細な設定オプションについては https://kubernetes.io/docs/concepts/services-networking/network-policies/を参照してください。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-to-backends
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          app.kubernetes.io/name: rke2-ingress-nginx
  policyTypes:
  - Ingress

詳細については、 https://github.com/rancher/rke2/issues/3195.のコメントを参照してください。

v1.24.xからv1.25.xへのハードニングされたクラスターのアップグレード

Kubernetesは、Pod Security Standardsを優先するためにv1.25からPodSecurityPolicyを削除しました。PSSについては、 アップストリームのドキュメントで詳しく読むことができます。RKE2の場合、ノードに`profile`フラグが設定されている場合は、いくつかの手動ステップを実行する必要があります。

  1. すべてのノードで、`profile`の値を`cis-1.23`に更新しますが、RKE2の再起動やアップグレードはまだ行わないでください。

  2. 通常通りアップグレードを行ってください。自動アップグレードを使用する場合は、`system-upgrade-controller`ポッドが実行されている名前空間が ポッドセキュリティレベルに従って特権として設定されていることを確認してください。

    apiVersion: v1
kind: Namespace
metadata:
  name: system-upgrade
  labels:
 # This value must be privileged for the controller to run successfully.
 pod-security.kubernetes.io/enforce: privileged
 pod-security.kubernetes.io/enforce-version: v1.25
 # We are setting these to our _desired_ `enforce` level, but note that these below values can be any of the available options.
 pod-security.kubernetes.io/audit: privileged
 pod-security.kubernetes.io/audit-version: v1.25
 pod-security.kubernetes.io/warn: privileged
 pod-security.kubernetes.io/warn-version: v1.25