詳細オプション / 設定

デフォルトでは、K3sはサーバーとエージェントの両方に対して単一の静的トークンを使用します。注意して、このトークンはクラスターが作成された後にローテーションできます。 エージェントの参加にのみ使用できる2番目の静的トークンを有効にすることも可能であり、また自動的に期限切れになる一時的な`kubeadm`スタイルの参加トークンを作成することもできます。 詳細については、`k3s token`コマンドのドキュメントを参照してください。

K3s を HTTP プロキシを介してのみ外部接続が可能な環境で実行している場合、K3s systemd サービスでプロキシ設定を構成できます。これらのプロキシ設定は K3s で使用され、組み込みの containerd と kubelet に渡されます。

K3s インストールスクリプトは、現在のシェルから HTTP_PROXY、HTTPS_PROXY、NO_PROXY、および CONTAINERD_HTTP_PROXY、CONTAINERD_HTTPS_PROXY、CONTAINERD_NO_PROXY 変数を自動的に取得し、通常は次のように systemd サービスの環境ファイルに書き込みます：

もちろん、これらのファイルを編集してプロキシを構成することもできます。

K3s は、クラスター内部の Pod およびサービス IP 範囲とクラスター DNS ドメインを NO_PROXY エントリのリストに自動的に追加します。Kubernetes ノード自体（つまり、ノードのパブリックおよびプライベート IP）が NO_PROXY リストに含まれているか、ノードがプロキシを介して到達可能であることを確認する必要があります。

K3s および Kubelet に影響を与えずに containerd のプロキシ設定を構成したい場合は、変数の前に CONTAINERD_ を付けることができます：

K3s には containerd が含まれており、業界標準のコンテナランタイムとしてデフォルト設定されています。 Kubernetes 1.24以降、Kubeletはdockershimを含まなくなりました。これは、kubeletがdockerdと通信するためのコンポーネントです。 K3s 1.24以降はhttps://github.com/Mirantis/cri-dockerd[cri-dockerd]を含んでおり、これにより以前のK3sリリースからのシームレスなアップグレードが可能で、Dockerコンテナランタイムを引き続き使用できます。

containerdの代わりにDockerを使用するには：

etcdctlは、etcdサーバーと対話するためのCLIを提供します。K3sはetcdctlをバンドルしていません。

K3sの組み込みetcdと対話するためにetcdctlを使用したい場合は、https://etcd.io/docs/latest/install/[公式ドキュメント]を使用してetcdctlをインストールしてください。

その後、K3sが管理する証明書とキーを使用して認証するようにetcdctlを設定することで使用できます。

K3sは、現在のクラスターおよびノードの設定に特有の値を使用して、containerdの設定ファイルを`/var/lib/rancher/k3s/agent/etc/containerd/config.toml`に生成します。

高度なカスタマイズのために、同じディレクトリにcontainerdの設定テンプレートを作成できます。

Containerd 2.0 は以前の設定バージョンと後方互換性があり、config-v3.toml.tmpl が見つからない場合、k3s は config.toml.tmpl からレガシー バージョン 2 の設定を引き続きレンダリングします。

テンプレートファイルは、https://pkg.go.dev/text/template[text/template] ライブラリを使用して containerd 設定にレンダリングされます。 デフォルトのテンプレート内容については、https://github.com/k3s-io/k3s/blob/main/pkg/agent/templates/templates.go[templates.go] の ContainerdConfigTemplateV3 と ContainerdConfigTemplate を参照してください。 テンプレートは、https://github.com/k3s-io/k3s/blob/main/pkg/agent/templates/templates.go#L22-L33[ContainerdConfig] 構造体をドット値（データ引数）として実行されます。

K3s は、K3s が起動する際に存在する場合、代替コンテナランタイムを自動的に検出します。サポートされているコンテナランタイムは次のとおりです：

K3s は、コンテナランタイムの実行可能ファイルを検索するためにサービスの PATH 環境変数を使用します。 インストールされたコンテナランタイムが K3s によって検出されない場合は、一般的に次のようなシステムパスに存在することを確認してください：
/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin

`--disable-agent`フラグで起動すると、サーバーはkubelet、コンテナランタイム、またはCNIを実行しません。クラスタ内にノードリソースを登録せず、`kubectl get nodes`の出力に表示されません。 kubeletをホストしないため、ポッドを実行したり、クラスタノードを列挙することに依存するオペレーターによって管理されたりすることはできません。これには、組み込みのetcdコントローラーやシステムアップグレードコントローラーが含まれます。

エージェントレスサーバーを実行することは、管理者のオーバーヘッドが増加する代わりに、エージェントやワークロードによる制御プレーンノードの発見を隠す場合に有利です。

デフォルトでは、エージェントレスサーバーのapiserverは、クラスタ内で実行されている入場Webhookや集約されたapiservicesへの外部接続を行うことができません。これを解決するには、`--egress-selector-mode`サーバーフラグを`pod`または`cluster`に設定します。既存のクラスタでこのフラグを変更する場合は、オプションを有効にするためにクラスタ内のすべてのノードを再起動する必要があります。

ルートレスモードでは、K3sサーバーを特権のないユーザーとして実行できるため、ホスト上の実際のルートを潜在的なコンテナブレイクアウト攻撃から保護します。

ルートレスKubernetesについて詳しくはhttps://rootlesscontaine.rs/をご覧ください。

K3sエージェントは、--node-label`および--node-taint`のオプションで構成でき、これによりkubeletにラベルとテイントが追加されます。これらの2つのオプションは、登録時にのみラベルおよび/またはテイントを追加するため、ノードがクラスターに最初に参加する際にのみ設定できます。

現在のKubernetesのすべてのバージョンは、`kubernetes.io`および`k8s.io`のプレフィックスを持つラベルでノードが登録されることを制限しており、特に`kubernetes.io/role`ラベルを含みます。許可されていないラベルでノードを起動しようとすると、K3sは起動に失敗します。Kubernetesの著者によると：

詳細については、https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/279-limit-node-access/README.md#proposal[SIG-Auth KEP 279]を参照してください。

ノード登録後にノードのラベルやテイントを変更したり、予約されたラベルを追加したりする場合は、`kubectl`を使用する必要があります。https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/[テイント]およびhttps://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node[ノードラベル]を追加する方法の詳細については、公式のKubernetesドキュメントを参照してください。

インストールスクリプトは、OSがsystemdまたはopenrcを使用しているかを自動検出し、インストールプロセスの一部としてサービスを有効にして開始します。

自動起動とサービス有効化を無効にするインストールスクリプトの例：

DockerでK3sを実行する方法はいくつかあります：

SELinuxがデフォルトで有効になっているシステム（CentOSなど）にK3sをインストールする場合、適切なSELinuxポリシーがインストールされていることを確認する必要があります。

K3s用のhttps://documentation.suse.com/cloudnative/rancher-manager/latest/en/observability/logging/logging-helm-chart-options.html[Rancher logging]は、Rancherを使用せずにインストールできます。これを行うには、以下の手順を実行してください：

ネットワークポリシーによってドロップされたパケットはログに記録できます。パケットはiptables NFLOGアクションに送信され、パケットの詳細が表示されます。それには、それをブロックしたネットワークポリシーも含まれます。

トラフィックが多い場合、ログメッセージの数は非常に多くなる可能性があります。ポリシーごとにログレートを制御するには、次のアノテーションを該当するネットワークポリシーに追加して、`limit`および`limit-burst`のiptablesパラメータを設定します：

デフォルト値は`limit=10/minute`と`limit-burst=10`です。これらのフィールドの形式と可能な値についての詳細は、https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-7.html#:~:text=restrict%20the%20rate%20of%20matches[iptablesマニュアル]を確認してください。

NFLOGパケットをログエントリに変換するには、ulogd2をインストールし、[log1]`を`group=100`で読み取るように設定します。次に、新しい設定が適用されるようにulogd2サービスを再起動します。 パケットがネットワークポリシールールによってブロックされると、/var/log/ulog/syslogemu.log`にログメッセージが表示されます。

NFLOGネットリンクソケットに送信されたパケットは、tcpdumpやtsharkなどのコマンドラインツールを使用して読み取ることもできます：

より簡単に入手できるtcpdumpは、パケットをブロックしたネットワークポリシーの名前を表示しません。代わりにwiresharkのtsharkコマンドを使用して、ポリシー名が含まれる`nflog.prefix`フィールドを含む完全なNFLOGパケットヘッダーを表示してください。

ドロップされたパケットのネットワークポリシーロギングは、https://github.com/k3s-io/k3s/issues/8008[空の`podSelector`を持つポリシー]をサポートしていません。診断または監査の目的でドロップされたパケットのログに依存する場合は、影響を受けたポッドに一致するポッドセレクターがポリシーに含まれていることを確認してください。