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

ネットワークサービス

このページでは、CoreDNS、Traefik Ingressコントローラー、Network Policyコントローラー、およびServiceLBロードバランサーコントローラーがK3s内でどのように機能するかを説明します。

Flannelの設定オプションとバックエンドの選択、または独自のCNIを設定する方法については、Installation Network Optionsページを参照してください。

K3sのために開放する必要があるポートに関する情報は、Networking Requirementsを参照してください。

CoreDNS

CoreDNSは、サーバーの起動時に自動的にデプロイされます。これを無効にするには、クラスター内のすべてのサーバーを`--disable=coredns`オプションで設定してください。

CoreDNSをインストールしない場合は、自分でクラスターDNSプロバイダーをインストールする必要があります。

Traefik Ingress Controller

Traefikは、マイクロサービスを簡単にデプロイするために作られた現代的なHTTPリバースプロキシおよびロードバランサーです。アプリケーションの設計、デプロイ、および実行中のネットワークの複雑さを簡素化します。

Traefik Ingressコントローラーは、ポート80と443を使用するLoadBalancerサービスをデプロイし、管理するIngressリソースのステータスにLoadBalancerサービスの外部IPを表示します。

デフォルトでは、ServiceLBはクラスター内のすべてのノードを使用してTraefik LoadBalancerサービスをホストします。つまり、ポート80と443は他のHostPortまたはNodePortポッドで使用できず、IngressリソースのステータスにはすべてのクラスターのメンバーのノードIPが表示されます。

Traefikによって使用されるノードを制限し、さらにIngressステータスに表示されるノードIPを制限するには、以下のControlling ServiceLB Node Selectionセクションの指示に従い、ServiceLBが実行されるノードを限定するか、いくつかのノードをLoadBalancerプールに追加し、Traefik HelmChartConfigで一致するラベルを設定してそのプールにTraefikサービスを限定してください。

Traefikは、サーバーを起動するときにデフォルトでデプロイされます。デフォルトのチャート値は`/var/lib/rancher/k3s/server/manifests/traefik.yaml`にありますが、このファイルは手動で編集しないでください。K3sは起動時にデフォルトでファイルを置き換えます。代わりに、`/var/lib/rancher/k3s/server/manifests`に追加の`HelmChartConfig`マニフェストを作成してTraefikをカスタマイズする必要があります。詳細と例については、Customizing Packaged Components with HelmChartConfigを参照してください。可能な設定値に関する詳細情報は、K3sのバージョンに含まれるhttps://github.com/k3s-io/k3s-charts/tree/main/charts/traefik[Traefik Helm Chart]の`values.yaml`を参照してください。

クラスターからTraefikを削除するには、すべてのサーバーを`--disable=traefik`フラグで起動してください。詳細については、パッケージコンポーネントの管理を参照してください。

K3sに含まれるTraefikの特定のバージョンの詳細については、あなたのバージョンのリリースノートを参照してください。

  • 1.32以降のK3sバージョンには、Traefik v3が含まれています。Traefik v2の既存のインストールは、K3sがアップグレードされると自動的にv3にアップグレードされます。 Traefik v3はv2の設定と互換性があるはずです。詳細については、上流のhttps://doc.traefik.io/traefik/migrate/v2-to-v3/[v2からv3への移行]ドキュメントを参照してください。

  • K3sバージョン1.21から1.31には、Traefik v2が含まれています。ただし、Traefik v1の既存のインストールが見つかった場合、Traefikはv2にアップグレードされていません。

  • K3sバージョン1.20およびそれ以前には、Traefik v1が含まれています。

ネットワークポリシーコントローラー

K3sには、組み込みのネットワークポリシーコントローラーが含まれています。基盤となる実装は、https://github.com/cloudnativelabs/kube-router[kube-routerの]ネットポリシーコントローラーライブラリ（他のkube-router機能は存在しません）であり、https://github.com/k3s-io/k3s/tree/main/pkg/agent/netpol[こちら]で見つけることができます。

これを無効にするには、各サーバーを`--disable-network-policy`フラグで起動してください。

K3sの設定がネットワークポリシーコントローラーを無効にするように変更されても、ネットワークポリシーiptablesルールは削除されません。ネットワークポリシーコントローラーを無効にした後に設定されたkube-routerネットワークポリシールールをクリーンアップするには、`k3s-killall.sh`スクリプトを使用するか、`iptables-save`と`iptables-restore`を使用してクリーンアップしてください。これらの手順は、クラスター内のすべてのノードで手動で実行する必要があります。

iptables-save | grep -v KUBE-ROUTER | iptables-restore
ip6tables-save | grep -v KUBE-ROUTER | ip6tables-restore

サービスロードバランサー

任意のLoadBalancerコントローラーをあなたのK3sクラスターにデプロイできます。デフォルトでは、K3sは利用可能なホストポートを使用するhttps://github.com/k3s-io/klipper-lb[ServiceLB]（以前のKlipper LoadBalancer）として知られるロードバランサーを提供します。

アップストリームのKubernetesでは、LoadBalancerタイプのサービスを作成することができますが、デフォルトのロードバランサー実装は含まれていないため、これらのサービスは1つがインストールされるまで`pending`のままになります。多くのホスティングサービスは、外部ロードバランサー実装を提供するために、Amazon EC2やMicrosoft Azureなどのクラウドプロバイダーを必要とします。対照的に、K3sのServiceLBは、クラウドプロバイダーや追加の設定なしでLoadBalancerサービスを使用することを可能にします。

ServiceLBの動作

ServiceLBコントローラーは、https://kubernetes.io/docs/concepts/services-networking/service/[Services]の`spec.type`フィールドが`LoadBalancer`に設定されているKubernetesを監視します。

各LoadBalancerサービスに対して、DaemonSetが`kube-system`ネームスペースに作成されます。このDaemonSetは、各ノードに`svc-`プレフィックスを持つServiceLBポッドを作成します。これらのポッドは、サービスポートを使用してhostPortを活用するため、そのポートが利用可能なノードにのみデプロイされます。そのポートが利用可能なノードがない場合、LBはPendingのままになります。異なるポートを使用する限り、同じノード上に複数のサービスを公開することが可能であることに注意してください。

ServiceLBポッドが外部IPが設定されたノードで実行されると、ノードの外部IPがサービスの`status.loadBalancer.ingress`アドレスリストに`ipMode: VIP`で追加されます。そうでない場合、ノードの内部IPが使用されます。

外部IPへのトラフィックがネットワークアドレス変換 (NAT)の対象となる場合（例えば、ノードのパブリックIPを外部IPとして使用するパブリッククラウドで）、トラフィックはhostPortを介してServiceLBポッドにルーティングされます。ポッドはiptablesを使用して、サービスのClusterIPアドレスとポートにトラフィックを転送します。トラフィックがNATの対象でなく、LoadBalancerアドレスと一致する宛先アドレスで到着した場合、トラフィックは（通常はkube-proxyのiptablesチェーンまたはipvsによって）インターセプトされ、サービスのClusterIPアドレスとポートに転送されます。

使用方法

K3sでhttps://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer[LoadBalancerタイプのサービス]を作成します。

既知の問題

外部トラフィックがNATを使用してノードに到達し（例：パブリッククラウドで）、クライアントのソースIP保持などの目的で`externalTrafficPolicy=local`が必要な場合、ノードのいずれかに対してk3s設定`node-external-ip`を定義しないでください。そうしないと正しく機能しません。

ServiceLBノード選択の制御

1つ以上のノードに`svccontroller.k3s.cattle.io/enablelb=true`ラベルを追加すると、ServiceLBコントローラーは許可リストモードに切り替わり、ラベルを持つノードのみがLoadBalancerポッドをホストする資格を持ちます。ラベルが付けられていないノードは、ServiceLBによる使用から除外されます。

デフォルトでは、ノードにはラベルが付けられていません。すべてのノードがラベルなしのままである限り、ポートが利用可能なすべてのノードがServiceLBによって使用されます。

ServiceLBノードプールの作成

LoadBalancerのポッドをホストする特定のノードのサブセットを選択するには、目的のノードに`enablelb`ラベルを追加し、ノードとサービスに一致する`lbpool`ラベル値を設定します。次に例を示します。

  1. ノードAとノードBに`svccontroller.k3s.cattle.io/lbpool=pool1`と`svccontroller.k3s.cattle.io/enablelb=true`のラベルを付けます。

  2. ノードCとノードDに`svccontroller.k3s.cattle.io/lbpool=pool2`と`svccontroller.k3s.cattle.io/enablelb=true`のラベルを付けます。

  3. ポート443で`svccontroller.k3s.cattle.io/lbpool=pool1`ラベルを持つLoadBalancerサービスを1つ作成します。このサービスのDaemonSetは、ノードAとノードBにのみポッドをデプロイします。

  4. ポート443で`svccontroller.k3s.cattle.io/lbpool=pool2`ラベルを持つ別のLoadBalancerサービスを作成します。DaemonSetはノードCとノードDにのみポッドをデプロイします。

ServiceLBの無効化

ServiceLBを無効にするには、クラスター内のすべてのサーバーを`--disable=servicelb`フラグで構成します。

これは、MetalLBなどの別のLBを実行したい場合に必要です。

外部クラウドコントローラーマネージャーのデプロイ

K3sは、次のことを行う埋め込みクラウドコントローラーマネージャー（CCM）を提供します：

  • サービスロードバランサー LoadBalancerコントローラーをホストします。

  • `node.cloudprovider.kubernetes.io/uninitialized`汚染をクリアします。

  • --node-ip、--node-external-ip、--node-internal-dns、および`--node-external-dns`フラグに基づいてノードアドレスフィールドを設定します。

外部CCMをデプロイする前に、埋め込みCCMを無効にするために、すべてのK3sサーバーを`--disable-cloud-controller`フラグで起動する必要があります。外部CCMを使用する場合、ノードアドレスはK3sフラグ値の代わりにクラウドプロバイダーのインスタンスメタデータAPIによって提供されます。

ビルトインCCMを無効にし、外部の代替品をデプロイして適切に構成しない場合、ノードは汚染されたままでスケジュールできなくなります。