Je souhaite exécuter une application sur n'importe quel nœud. Il doit toujours avoir au moins une instance par nœud, mais plusieurs instances sont autorisées, principalement lors d'une mise à jour pour éviter les temps d'arrêt de ce pod (et nœud).
Les mises à jour de déploiement de Kubernetes fonctionnent généralement en lançant un nouveau pod, et dès qu'il est disponible, l'ancien est arrêté. C'est parfait, mais dans mon cas, j'ai besoin d'un DaemonSet pour lancer une application spécifique sur tous les nœuds à tout moment. Cependant, lors de la mise à jour de ce DaemonSet, Kubernetes tue un pod un par un (c'est-à-dire nœud par nœud) et puis lance un nouveau pod, ce qui signifie qu'à un moment donné pendant une mise à jour le pod peut ne pas être en cours d'exécution sur un nœud.
Il semble que les DaemonSets soient, par rapport aux déploiements, la bonne façon de le faire, mais je n'ai trouvé aucun moyen d'éviter les temps d'arrêt lors de la mise à jour du DaemonSet. Est-ce qu'il y a un moyen de faire ça? J'ai également pensé à utiliser Deployments et à mettre à jour manuellement un montant de réplique et l'antiPodAffinity pour qu'un seul pod soit déployé par nœud, mais c'est une sorte de piratage.
3 Réponses :
Il y a eu de très longues discussions sur l'ajout de cette fonctionnalité. Vous pouvez les voir ici et ici
En bref, ce n'est pas vraiment possible. Vous pouvez essayer de combiner maxUnavailable: 0 et type: rollingUpdate dans votre updateStrategy mais je ne pense pas que ce soit formellement pris en charge.
Exemple :
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: my-daemonset
labels:
service: my-daemonset
spec:
selector:
matchLabels:
service: my-daemonset
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
template:
metadata:
labels:
service: my-daemonset
spec:
containers:
- name: daemonset-update
image: my-image:latest
Il n'est pas permis de définir maxUnavailable sur 0 à partir d'aujourd'hui avec un DeamonSet.
Il est possible d'effectuer des mises à jour progressives sans temps d'arrêt en utilisant un DeamonSet à partir d'aujourd'hui! Ce dont vous avez besoin est d'avoir au moins 2 nœuds en cours d'exécution sur votre cluster et de définir maxUnavailable sur 1 dans votre configuration DaemonSet.
En supposant la configuration précédente, lorsqu'une mise à jour est envoyée, un premier nœud commencera la mise à jour. Le second attendra la fin du premier. En cas de succès, le second fait de même.
L'inconvénient majeur est que vous devez garder 2 nœuds en cours d'exécution en continu ou prendre des mesures pour générer / tuer un nœud avant / après une mise à jour.
Cool! Je ne peux pas essayer maintenant, mais je le ferai. Pouvez-vous peut-être fournir un lien vers un journal des modifications ou où cela est documenté?
Je n'ai pas de documentation spécifique à lier autre que celle de maxUnavailable. Votre cas d'utilisation était similaire au mien. J'ai vécu quelques choses ces derniers jours et je me retrouve avec ce qui est décrit dans cette réponse.
En supposant que votre application puisse tolérer avoir plus d'un pod par nœud (ce qui semble être le cas), vous pouvez créer un deuxième DaemonSet et supprimer l'original une fois que vous êtes sûr que le nouveau DaemonSet est fonctionnel. Ce processus est un peu plus complexe, mais il vous permet de contrôler le moment où les anciens pods sont supprimés.
Notez que vous vous retrouveriez avec un DaemonSet sous un nom différent. Si cela vous dérange, vous pouvez toujours répéter le processus une fois de plus pour revenir au nom d'origine.
Vous ne savez pas si cela fonctionnerait, puisque j'exécute un serveur http dessus, il devrait donc être réacheminé?
@LucaSteeb, cela fonctionnerait pour OP, mais vos besoins semblent différer un peu de ceux de l'OP, il serait donc préférable de créer votre propre question. Cela dit ... Mettre à niveau signifie remplacer votre pod par une version plus récente. Sans avoir trop d'expérience dans ce domaine et en supposant que votre charge de travail ne puisse pas être transférée dynamiquement vers un autre pod, vous devrez peut-être introduire une logique pour empêcher les anciens pods de se voir attribuer de nouvelles charges de travail une fois les nouveaux en cours d'exécution. De cette façon, une fois que tous les anciens pods auront terminé leurs charges de travail, vous pourrez supprimer le DaemonSet.
Je suis l'OP: P Dans tous les cas, je ne travaille plus sur ce projet, donc pour moi personnellement, cela n'a plus d'importance de toute façon.
Cela a été mis en attente ( github.com/kubernetes/kubernetes/pull/51161 ) . Ce n'est donc pas possible.
Une approche alternative est un déploiement bleu-vert. Exécutez à la fois l'ancien et le nouvel ensemble de démons, puis une fois que vous êtes satisfait qu'aucune restauration ne se produira, vous pouvez supprimer l'ancien ensemble de démons. Vous doubleriez temporairement votre empreinte, comme inconvénient.