Static Pod は、APIサーバーによる監視を受けることなく、特定のノード上のkubeletデーモンによって直接管理されます。 コントロールプレーンによって管理されるPod(たとえばDeployment)とは異なり、kubeletが各Static Podを監視し、障害が発生した場合には再起動します。
Static Podは、常に特定のノード上の1つのkubeletに紐付けられます。
Static Podの主な用途は、セルフホスト型のコントロールプレーンを実行することです。
言い換えると、kubeletを使用して個々のコントロールプレーンコンポーネントを管理することです。
たとえば、kubeadmはStatic Podを使用して、コントロールプレーンのノード上でkube-apiserver、kube-controller-manager、kube-scheduler、etcdを実行します。
kube-system名前空間内でkubernetes.io/config.mirrorアノテーションによって識別できます。kubeletは、各Static Podに対応するミラーPodを、Kubernetes APIサーバー上に自動的に作成しようとします。 これにより、ノード上で実行されているPodはAPIサーバー上で参照できるようになりますが、APIサーバーから制御することはできません。 Pod名には、先頭にハイフンを付けたノードのホスト名がサフィックスとして付加されます。
kubeletは、Static PodからラベルをミラーPodへ伝播します。 これらのラベルは、セレクターを通じて通常どおり使用できます。
kubectlを使用してAPIサーバーからミラーPodを削除しようとしても、kubeletはStatic Podを削除 しません。
kubeletはミラーPodを再作成します。
Static Podのspecは、ServiceAccount、ConfigMap、Secretなどの他のAPIオブジェクトを参照できません。
Static Podは、エフェメラルコンテナをサポートしていません。
クラスター化されたKubernetesを実行していて、すべてのノードでPodを実行するためにStatic Podを使用している場合は、代わりにDaemonSetを使用するべきでしょう。
Static Podはコントロールプレーンによって管理されないため、Kubernetesの標準的な仕組みを使用してロールアウト、ロールバック、スケールを行うことはできません。 DaemonSetはこれらの機能を提供しており、ノードレベルのワークロードを実行するための推奨される方法です。
Static Podは、APIサーバーが利用可能になる前にkubeletによって起動されるため、コントロールプレーンコンポーネントのブートストラップに適しています。 DaemonSetは、稼働中のコントロールプレーンを必要とします。