現在表示しているのは、次のバージョン向けのドキュメントです。Kubernetesバージョン: v1.29
Kubernetes v1.29 のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: 最新バージョン
コンテナランタイム
クラスター内の各ノードがPodを実行できるようにするため、コンテナランタイムをインストールする必要があります。 このページでは、ノードをセットアップするための概要と関連する作業について説明します。
Kubernetes 1.29においては、Container Runtime Interface (CRI)に準拠したランタイムを使用する必要があります。
詳しくはサポートするCRIのバージョンをご覧ください。
このページではいくつかの一般的なコンテナランタイムをKubernetesで使用する方法の概要を説明します。
v1.24以前のKubernetesリリースでは、 dockershim という名前のコンポーネントを使用したDocker Engineとの直接の統合が含まれていました。 この特別な直接統合は、もはやKubernetesの一部ではありません(この削除はv1.20リリースの一部として発表されています)。 dockershimの廃止がどのような影響を与えるかについては、dockershim削除の影響範囲を確認する をご覧ください。 dockershimからの移行について知りたい場合、dockershimからの移行を参照してください。
v1.29以外のバージョンのKubernetesを実行している場合、そのバージョンのドキュメントを確認してください。
インストールと設定の必須要件
以下の手順では、全コンテナランタイムに共通の設定をLinux上のKubernetesノードに適用します。
特定の設定が不要であることが分かっている場合、手順をスキップして頂いて構いません。
詳細については、Network Plugin Requirementsまたは、特定のコンテナランタイムのドキュメントを参照してください。
IPv4フォワーディングを有効化し、iptablesからブリッジされたトラフィックを見えるようにする
以下のコマンドを実行します。
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
# この構成に必要なカーネルパラメーター、再起動しても値は永続します
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF
# 再起動せずにカーネルパラメーターを適用
sudo sysctl --system
以下のコマンドを実行してbr_netfilter
とoverlay
モジュールが読み込まれていることを確認してください。
lsmod | grep br_netfilter
lsmod | grep overlay
以下のコマンドを実行して、net.bridge.bridge-nf-call-iptables
、net.bridge.bridge-nf-call-ip6tables
、net.ipv4.ip_forward
カーネルパラメーターが1に設定されていることを確認します。
sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward
cgroupドライバー
Linuxでは、プロセスに割り当てられるリソースを制約するためにcgroupが使用されます。
kubeletと基盤となるコンテナランタイムは、コンテナのリソース管理を実施し、CPU/メモリーの要求や制限などのリソースを設定するため、cgroupとインターフェースする必要があります。 cgroupとインターフェースするために、kubeletおよびコンテナランタイムはcgroupドライバーを使用する必要があります。 この際、kubeletとコンテナランタイムが同一のcgroupドライバーを使用し、同一の設定を適用することが不可欠となります。
利用可能なcgroupドライバーは以下の2つです。
cgroupfsドライバー
cgroupfs
ドライバーは、kubeletのデフォルトのcgroupドライバーです。
cgroupfs
ドライバーを使用すると、kubeletとコンテナランタイムはcgroupファイルシステムと直接インターフェースし、cgroupを設定します。
systemdがinitシステムである場合、cgroupfs
ドライバーは推奨されません。
なぜなら、systemdはシステム上のcgroupマネージャーが単一であると想定しているからです。
また、cgroup v2を使用している場合は、cgroupfs
の代わりにsystemd
cgroupドライバーを使用してください。
systemd cgroupドライバー
Linuxディストリビューションのinitシステムにsystemdが選択されている場合、 initプロセスはルートcgroupを生成・消費し、cgroupマネージャーとして動作します。
systemdはcgroupと密接に連携しており、systemdユニットごとにcgroupを割り当てます。
その結果、initシステムにsystemd
を使用した状態でcgroupfs
ドライバーを使用すると、
システムには2つの異なるcgroupマネージャーが存在することになります。
2つのcgroupマネージャーが存在することで、システムで利用可能なリソースおよび使用中のリソースに、2つの異なる見え方が与えられることになります。
特定の場合において、kubeletとコンテナランタイムにcgroupfs
を、残りのプロセスにsystemd
を使用するように設定されたノードが高負荷時に不安定になることがあります。
このような不安定性を緩和するためのアプローチは、systemdがinitシステムに採用されている場合にkubeletとコンテナランタイムのcgroupドライバーとしてsystemd
を使用することです。
cgroupドライバーにsystemd
を設定するには、以下のようにKubeletConfiguration
のcgroupDriver
オプションを編集してsystemd
を設定します。
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
kubelet用のcgroupドライバーとしてsystemd
を設定する場合、コンテナランタイムのcgroupドライバーにもsystemd
を設定する必要があります。
具体的な手順については、以下のリンクなどの、お使いのコンテナランタイムのドキュメントを参照してください。
クラスターに参加したノードのcgroupドライバーを変更するのはデリケートな操作です。 kubeletが特定のcgroupドライバーのセマンティクスを使用してPodを作成していた場合、 コンテナランタイムを別のcgroupドライバーに変更すると、そのような既存のPodに対してPodサンドボックスを再作成しようとしたときにエラーが発生することがあります。 kubeletを再起動してもこのようなエラーは解決しない可能性があります。
もしあなたが適切な自動化の手段を持っているのであれば、更新された設定を使用してノードを別のノードに置き換えるか、自動化を使用して再インストールを行ってください。
kubeadmで管理されたクラスターでのsystemd
ドライバーへの移行
既存のkubeadm管理クラスターでsystemd
cgroupドライバーに移行したい場合は、cgroupドライバーの設定に従ってください。
サポートするCRIのバージョン
コンテナランタイムは、Container Runtime Interfaceのv1alpha2以上をサポートする必要があります。
Kubernetes 1.29は、デフォルトでCRI APIのv1を使用します。 コンテナランタイムがv1 APIをサポートしていない場合、kubeletは代わりに(非推奨の)v1alpha2 APIにフォールバックします。
コンテナランタイム
containerd
このセクションでは、CRIランタイムとしてcontainerdを使用するために必要な手順の概要を説明します。
以下のコマンドを使用して、システムにcontainerdをインストールします:
まずはcontainerdの使用を開始するの指示に従ってください。有効なconfig.toml
設定ファイルを作成したら、このステップに戻ります。
このファイルはパス/etc/containerd/config.toml
にあります。
このファイルはC:\Program Files\containerd\config.toml
にあります。
Linuxでは、containerd用のデフォルトのCRIソケットは/run/containerd/containerd.sock
です。
Windowsでは、デフォルトのCRIエンドポイントはnpipe://./pipe/containerd-containerd
です。
systemd
cgroupドライバーを構成する
/etc/containerd/config.toml
内でrunc
がsystemd
cgroupドライバーを使うようにするには、次のように設定します。
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
cgroup v2を使用する場合はsystemd
cgroupドライバーの利用を推奨します。
パッケージ(RPMや.deb
など)からcontainerdをインストールした場合、
CRI統合プラグインがデフォルトで無効になっていることがあります。
Kubernetesでcontainerdを使用するには、CRIサポートを有効にする必要があります。
/etc/containerd/config.toml
内のdisabled_plugins
リストにcri
が含まれていないことを確認してください。
このファイルを変更した場合、containerd
も再起動してください。
クラスターの初回構築後、またはCNIをインストールした後にコンテナのクラッシュループが発生した場合、
パッケージと共に提供されるcontainerdの設定に互換性のないパラメーターが含まれている可能性があります。
get-started.mdにあるように、
containerd config default > /etc/containerd/config.toml
でcontainerdの設定をリセットした上で、
上記の設定パラメーターを使用することを検討してください。
この変更を適用した場合、必ずcontainerdを再起動してください。
sudo systemctl restart containerd
kubeadmを使用している場合、手動でkubelet cgroupドライバーの設定を行ってください。
サンドボックス(pause)イメージの上書き
containerdの設定で以下の設定をすることで、サンドボックスのイメージを上書きすることができます。
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.2"
この場合も、設定ファイルの更新後にsystemctl restart containerd
を実行してcontainerd
も再起動する必要があるでしょう。
CRI-O
本セクションでは、コンテナランタイムとしてCRI-Oをインストールするために必要な手順を説明します。
CRI-Oをインストールするには、CRI-Oのインストール手順に従ってください。
cgroupドライバー
CRI-Oはデフォルトでsystemd cgroupドライバーを使用し、おそらく問題なく動作します。
cgroupfs
cgroupドライバーに切り替えるには、/etc/crio/crio.conf
を編集するか、
/etc/crio/crio.conf.d/02-cgroup-manager.conf
にドロップイン設定ファイルを置いて、以下のような設定を記述してください。
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
上記でconmon_cgroup
も変更されていることに注意してください。
CRI-Oでcgroupfs
を使用する場合、ここにはpod
という値を設定する必要があります。
一般に、kubeletのcgroupドライバーの設定(通常はkubeadmによって行われます)とCRI-Oの設定は一致させる必要があります。
CRI-Oの場合、CRIソケットはデフォルトで/var/run/crio/crio.sock
となります。
サンドボックス(pause)イメージの上書き
CRI-Oの設定において、以下の値を設定することができます。
[crio.image]
pause_image="registry.k8s.io/pause:3.6"
このオプションはライブ設定リロードによる変更の適用に対応しています。
systemctl reload crio
またはcrio
プロセスにSIGHUP
を送信することで変更を適用できます。
Docker Engine
cri-dockerd
アダプターを使用することを想定しています。
-
各ノードに、使用しているLinuxディストリビューション用のDockerをDocker Engineのインストールに従ってインストールします。
-
cri-dockerd
をリポジトリ内の指示に従ってインストールします。
cri-dockerd
の場合、CRIソケットはデフォルトで/run/cri-dockerd.sock
になります。
Mirantis Container Runtime
Mirantis Container Runtime(MCR)は、 以前はDocker Enterprise Editionとして知られていた、商業的に利用可能なコンテナランタイムです。
MCRに含まれるオープンソースのcri-dockerd
コンポーネントを使用することで、
Mirantis Container RuntimeをKubernetesで使用することができます。
Mirantis Container Runtimeのインストール方法について知るには、MCRデプロイガイドを参照してください。
CRIソケットのパスを見つけるには、systemdのcri-docker.socket
という名前のユニットを確認してください。
サンドボックス(pause)イメージを上書きする
cri-dockerd
アダプターは、Podインフラコンテナ("pause image")として使用するコンテナイメージを指定するためのコマンドライン引数を受け付けます。
使用するコマンドライン引数は --pod-infra-container-image
です。
次の項目
コンテナランタイムに加えて、クラスターには動作するネットワークプラグインが必要です。
このページの項目は、Kubernetesが必要とする機能を提供するサードパーティー製品またはプロジェクトです。Kubernetesプロジェクトの作者は、それらのサードパーティー製品またはプロジェクトに責任を負いません。詳しくは、CNCFウェブサイトのガイドラインをご覧ください。第三者のリンクを追加するような変更を提案する前に、コンテンツガイドを読むべきです。