この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。

基本ネットワークオプション

このページでは、K3sのネットワーク構成オプション、Flannelの構成または置き換え、IPv6またはデュアルスタックの設定について説明します。

Flannelオプション

Flannelは、Kubernetesコンテナネットワークインターフェース（CNI）を実装する軽量のレイヤー3ネットワークファブリックのプロバイダーです。一般的にCNIプラグインと呼ばれるものです。

  • Flannelオプションはサーバーノードでのみ設定でき、クラスター内のすべてのサーバーで同一でなければなりません。

  • Flannelのデフォルトバックエンドは`vxlan`です。暗号化を有効にするには、`wireguard-native`バックエンドを使用してください。

  • Raspberry Piで最近のUbuntuバージョンを使用する場合、`vxlan`追加の準備が必要です。

  • `wireguard-native`をFlannelバックエンドとして使用するには、一部のLinux配布パッケージで追加のモジュールが必要な場合があります。詳細については、https://www.wireguard.com/install/[WireGuardインストールガイド]をご覧ください。 WireGuardのインストール手順により、オペレーティングシステムに適したカーネルモジュールがインストールされます。 WireGuard Flannelバックエンドを使用する前に、すべてのノード（サーバーとエージェントの両方）でWireGuardカーネルモジュールが利用可能であることを確認する必要があります。

CLIフラグと値 説明

--flannel-ipv6-masq

IPv6トラフィックにマスカレードルールを適用します（IPv4のデフォルト）。デュアルスタックまたはIPv6専用クラスターにのみ適用されます。`none`以外のすべてのFlannelバックエンドと互換性があります。

--flannel-external-ip

内部IPの代わりに、Flannelトラフィックの宛先としてノードの外部IPアドレスを使用します。--node-external-ipがノードに設定されている場合にのみ適用されます。

--flannel-backend=vxlan

VXLANを使用してパケットをカプセル化します。Raspberry Piに追加のカーネルモジュールが必要な場合があります。

--flannel-backend=host-gw

ノードIPを介してポッドサブネットへのIPルートを使用します。クラスター内のすべてのノード間で直接レイヤー2接続が必要です。

--flannel-backend=wireguard-native

WireGuardを使用してネットワークトラフィックをカプセル化および暗号化します。追加のカーネルモジュールが必要な場合があります。

--flannel-backend=ipsec

ネットワークトラフィックを暗号化するために、`swanctl`バイナリを介してstrongSwan IPSecを使用します。（非推奨；v1.27.0で削除されます）

--flannel-backend=none

Flannelを完全に無効にします。
バージョンゲート

K3sは2022-12リリース（v1.26.0+k3s1、v1.25.5+k3s1、v1.24.9+k3s1、v1.23.15+k3s1）以降、strongSwan `swanctl`および`charon`バイナリを含まなくなりました。`ipsec`バックエンドを使用する場合は、これらのリリースをインストールまたはアップグレードする前に、ノードに正しいパッケージをインストールしてください。

`wireguard`または`ipsec`から`wireguard-native`への移行

レガシー`wireguard`バックエンドは、ホストに`wg`ツールのインストールを必要とします。このバックエンドはK3s v1.26以降では利用できず、カーネルと直接インターフェースする`wireguard-native`バックエンドに置き換えられます。

レガシー`ipsec`バックエンドは、ホストに`swanctl`および`charon`バイナリのインストールを必要とします。このバックエンドはK3s v1.27以降では利用できず、`wireguard-native`バックエンドに置き換えられます。

ユーザーができるだけ早く新しいバックエンドに移行することをお勧めします。移行には、ノードが新しい設定で起動する間、短期間のダウンタイムが必要です。次の2つのステップに従ってください：

  1. すべてのサーバーノードでK3sの設定を更新します。設定ファイルを使用する場合、`/etc/rancher/k3s/config.yaml`には`flannel-backend: wireguard-native`を含める必要があり、`flannel-backend: wireguard`や`flannel-backend: ipsec`は含めないでください。systemdユニット内でCLIフラグを使用してK3sを設定している場合、同等のフラグを変更する必要があります。

  2. すべてのノードを再起動します。サーバーから始めてください。

Flannelエージェントオプション

これらのオプションは各エージェントに利用可能で、そのノードで実行されているFlannelインスタンスに特有です。

CLI Flag 説明

`--flannel-iface`の値

デフォルトのFlannelインターフェースを上書きします。

`--flannel-conf`の値

デフォルトのFlannel設定ファイルを上書きします。

`--flannel-cni-conf`の値

デフォルトのFlannel CNI設定ファイルを上書きします。

カスタムCNI

--flannel-backend=none`を使用してK3sを起動し、選択したCNIをインストールします。ほとんどのCNIプラグインには独自のネットワークポリシーエンジンが付属しているため、競合を避けるために--disable-network-policy`も設定することをお勧めします。考慮すべき重要な情報：

  • カナル

  • Calico

  • Cilium

カナルドキュメントのウェブサイトを訪問してください。カナルをインストールする手順に従ってください。IP転送が`container_settings`セクションで許可されるようにカナルYAMLを修正します。例えば：

"container_settings": {
  "allow_ip_forwarding": true
}

カナルYAMLを適用します。

ホストで次のコマンドを実行して設定が適用されたことを確認してください：

cat /etc/cni/net.d/10-canal.conflist

IPフォワーディングがtrueに設定されていることが確認できるはずです。

Calico CNIプラグインガイドに従ってください。IPフォワーディングが許可されるようにCalico YAMLを`container_settings`セクションで修正してください。例えば：

"container_settings": {
  "allow_ip_forwarding": true
}

Calico YAMLを適用してください。

ホストで次のコマンドを実行して設定が適用されたことを確認してください：

cat /etc/cni/net.d/10-calico.conflist

IPフォワーディングがtrueに設定されていることが確認できるはずです。

k3s-killall.sh`または`k3s-uninstall.sh`を実行する前に、`cilium_host、cilium_net、`cilium_vxlan`インターフェースを手動で削除する必要があります。これを行わないと、K3sが停止したときにホストへのネットワーク接続を失う可能性があります。

ip link delete cilium_host
ip link delete cilium_net
ip link delete cilium_vxlan

さらに、ciliumのiptablesルールを削除する必要があります：

iptables-save | grep -iv cilium | iptables-restore
ip6tables-save | grep -iv cilium | ip6tables-restore

コントロールプレーンエグレスセレクタの設定

K3sエージェントとサーバーは、コントロールプレーン（apiserver）とエージェント（kubeletおよびcontainerd）コンポーネント間の双方向通信をカプセル化するために使用されるWebSocketトンネルをノード間で維持します。 これにより、エージェントはkubeletおよびコンテナランタイムのストリーミングポートを外部接続に公開することなく動作でき、コントロールプレーンはエージェントが無効な状態でクラスターサービスに接続できます。 この機能は、他のKubernetesディストリビューションで一般的に使用されるhttps://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/[Konnectivity]サービスに相当し、apiserverのエグレスセレクタ設定を介して管理されます。

デフォルトモードは`agent`です。`pod`または`cluster`モードは、flannelおよびkube-proxyがない場合にクラスターサービスエンドポイントへのアクセスをapiserverに提供するために、エージェントレスサーバーを実行する際に推奨されます。

エグレスセレクタモードは、`--egress-selector-mode`フラグを介してサーバーで構成でき、4つのモードを提供します：

  • disabled:apiserverはkubeletやクラスターエンドポイントと通信するためにエージェントトンネルを使用しません。 このモードでは、サーバーがkubelet、CNI、およびkube-proxyを実行し、エージェントに直接接続できる必要があります。そうでないと、apiserverはサービスエンドポイントにアクセスしたり、`kubectl exec`や`kubectl logs`を実行したりできません。

  • agent（デフォルト）：apiserverはエージェントトンネルを使用してkubeletと通信します。 このモードでは、サーバーがkubelet、CNI、およびkube-proxyを実行する必要があります。そうしないと、apiserverはサービスエンドポイントにアクセスできません。

  • pod:apiserverはエージェントトンネルを使用してkubeletおよびサービスエンドポイントと通信し、ノードとエンドポイントを監視することで、エンドポイント接続を正しいエージェントにルーティングします。
    注意:このモードは、独自のIPAMを使用し、ノードのPodCIDR割り当てを尊重しないCNIを使用している場合には機能しません。代わりに`cluster`または`agent`モードをこれらのCNIと一緒に使用する必要があります。

  • cluster:apiserverはエージェントトンネルを使用してkubeletおよびサービスエンドポイントと通信し、ポッドとエンドポイントを監視することで、エンドポイント接続を正しいエージェントにルーティングします。このモードは、異なるクラスター構成間でのポータビリティが最も高いですが、オーバーヘッドが増加します。

デュアルスタック（IPv4 + IPv6）ネットワーキング

バージョンゲート

実験的なサポートはhttps://github.com/k3s-io/k3s/releases/tag/v1.21.0%2Bk3s1[v1.21.0+k3s1]から利用可能です。
安定したサポートはhttps://github.com/k3s-io/k3s/releases/tag/v1.23.7%2Bk3s1[v1.23.7+k3s1]から利用可能です。
既知の問題

1.27以前では、Kubernetes 問題 #111695により、デュアルスタック環境でクラスターのトラフィックにプライマリネットワークインタフェースを使用していない場合、KubeletがノードのIPv6アドレスを無視します。このバグを回避するには、1.27以降を使用するか、K3sサーバーとエージェントの両方に次のフラグを追加してください：

--kubelet-arg="node-ip=0.0.0.0" # To proritize IPv4 traffic
#OR
--kubelet-arg="node-ip=::" # To proritize IPv6 traffic

クラスターが最初に作成されるときにデュアルスタックネットワーキングを構成する必要があります。IPv4専用として起動された既存のクラスターでは有効にできません。

K3sでデュアルスタックを有効にするには、すべてのサーバーノードに有効なデュアルスタック`cluster-cidr`と`service-cidr`を提供する必要があります。これは有効な構成の例です：

--cluster-cidr=10.42.0.0/16,2001:db8:42::/56 --service-cidr=10.43.0.0/16,2001:db8:43::/112

有効な`cluster-cidr`および`service-cidr`の値を構成できますが、上記のマスクが推奨されますのでご注意ください。`cluster-cidr`マスクを変更する場合は、計画されたノードごとのポッド数と総ノード数に一致するように`node-cidr-mask-size-ipv4`および`node-cidr-mask-size-ipv6`の値も変更する必要があります。サポートされている最大の`service-cidr`マスクは、IPv4の場合は/12、IPv6の場合は/112です。パブリッククラウドにデプロイする場合は、IPv6トラフィックを許可することを忘れないでください。

公開ルーティングされていないIPv6アドレス、例えばULA範囲のアドレスを使用する場合、デフォルトのポッドは送信トラフィックにポッドのIPv6アドレスを使用するため、IPv6 NATを有効にするために`--flannel-ipv6-masq`オプションを追加することをお勧めします。 ただし、公開ルーティングされたIPv6アドレスが使用される場合は、それらのアドレスがクラスターにルーティングされることを確認する必要があります。そうでないと、ポッドは自分のIPv6アドレスから発信されたパケットに対する応答を受け取ることができません。K3sの範囲外では、どのノードでどのアドレスが使用されているかを外部ルーティングインフラに自動的に通知することはできませんが、クラスターのメンバーはポッドトラフィックを正しく転送できるため、ルートをクラスターに属する任意のノードに向けることができます。

カスタムCNIプラグインを使用している場合、つまりFlannel以外のCNIプラグインを使用している場合は、追加の設定が必要になることがあります。プラグインのデュアルスタックドキュメントを参照し、ネットワークポリシーが有効にできるかどうかを確認してください。

既知の問題

IPv6をプライマリファミリーとしてcluster-cidrとservice-cidrを定義する際には、すべてのクラスターのメンバーのnode-ipを明示的に設定し、ノードの希望するIPv6アドレスを最初のアドレスとして配置する必要があります。デフォルトでは、kubeletは常にIPv4をプライマリアドレスファミリーとして使用します。

シングルスタックIPv6ネットワーキング

バージョンゲート

v1.22.9+k3s1から利用可能
既知の問題

IPv6のデフォルトルートがルーター広告（RA）によって設定されている場合、sysctl `net.ipv6.conf.all.accept_ra=2`を設定する必要があります。そうしないと、ノードはデフォルトルートが期限切れになるとそれを削除します。RAを受け入れることは、https://github.com/kubernetes/kubernetes/issues/91507[中間者攻撃]のリスクを高める可能性があることに注意してください。

シングルスタックIPv6クラスター（IPv4のないクラスター）は、--cluster-cidr`および--service-cidr`フラグを使用してK3sでサポートされています。これは有効な設定の例です。

--cluster-cidr=2001:db8:42::/56 --service-cidr=2001:db8:43::/112

公開ルーティングされていないIPv6アドレス、例えばULA範囲のアドレスを使用する場合、デフォルトのポッドは送信トラフィックにポッドのIPv6アドレスを使用するため、IPv6 NATを有効にするために`--flannel-ipv6-masq`オプションを追加することをお勧めします。

ホスト名のないノード

Linodeなどの一部のクラウドプロバイダーは、ホスト名として"localhost"を持つマシンを作成し、他のプロバイダーはホスト名が全く設定されていない場合があります。これにより、ドメイン名解決に問題が生じる可能性があります。K3sを`--node-name`フラグまたは`K3S_NODE_NAME`環境変数で実行すると、ノード名が渡され、この問題が解決されます。