Les Pods statiques sont gérés directement par le démon kubelet sur un nœud donné, sans que le serveur d'API les observe. Contrairement aux Pods gérés par le plan de contrôle (par exemple, par un Deployment), c'est le kubelet qui surveille chaque Pod statique et le redémarre en cas d'échec.
Les Pods statiques sont toujours liés à un seul kubelet, sur un nœud précis.
Les Pods statiques servent principalement à exécuter un plan de contrôle auto-hébergé,
c'est-à-dire à utiliser le kubelet pour superviser chacun des
composants du plan de contrôle.
Par exemple, kubeadm utilise des Pods statiques pour exécuter
kube-apiserver, kube-controller-manager, kube-scheduler et etcd sur les nœuds du plan de contrôle.
kube-system grâce à l'annotation kubernetes.io/config.mirror.Le kubelet essaie automatiquement de créer un Pod miroir sur le serveur d'API Kubernetes pour chaque Pod statique. Les Pods qui s'exécutent sur un nœud sont donc visibles sur le serveur d'API, mais ne peuvent pas être contrôlés depuis celui-ci. Le nom de chaque Pod miroir est suivi d'un tiret et du nom d'hôte du nœud.
Le kubelet reporte les labels du Pod statique sur le Pod miroir. Vous pouvez utiliser ces labels dans des sélecteurs, comme pour n'importe quel Pod.
Si vous tentez de supprimer le Pod miroir du serveur d'API avec kubectl,
le kubelet ne supprime pas le Pod statique : il recrée le Pod miroir.
La spécification d'un Pod statique ne peut pas faire référence à d'autres objets de l'API, comme un ServiceAccount, une ConfigMap ou un Secret.
Les Pods statiques ne prennent pas en charge les conteneurs éphémères.
Si vous exploitez un cluster Kubernetes et que vous vous servez de Pods statiques pour exécuter un Pod sur chaque nœud, il est sans doute préférable d'utiliser un DaemonSet.
Les Pods statiques ne sont pas gérés par le plan de contrôle : il n'est donc pas possible de les déployer progressivement, de revenir à une version précédente ni de les mettre à l'échelle avec les mécanismes standard de Kubernetes. Les DaemonSets offrent ces fonctionnalités et constituent l'approche recommandée pour exécuter des charges de travail au niveau des nœuds.
Les Pods statiques sont démarrés par le kubelet avant que le serveur d'API soit disponible, ce qui les rend adaptés à l'amorçage des composants du plan de contrôle. Les DaemonSets, eux, nécessitent un plan de contrôle opérationnel.