Comment puis-je distribuer un déploiement sur plusieurs nœuds?
J'ai un déploiement Kubernetes qui ressemble à quelque chose comme ceci (noms remplacés et autres choses par '....'):
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "3"
kubernetes.io/change-cause: kubectl replace deployment ....
-f - --record
creationTimestamp: 2016-08-20T03:46:28Z
generation: 8
labels:
app: ....
name: ....
namespace: default
resourceVersion: "369219"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/....
uid: aceb2a9e-6688-11e6-b5fc-42010af000c1
spec:
replicas: 2
selector:
matchLabels:
app: ....
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
creationTimestamp: null
labels:
app: ....
spec:
containers:
- image: gcr.io/..../....:0.2.1
imagePullPolicy: IfNotPresent
name: ....
ports:
- containerPort: 8080
protocol: TCP
resources:
requests:
cpu: "0"
terminationMessagePath: /dev/termination-log
dnsPolicy: ClusterFirst
restartPolicy: Always
securityContext: {}
terminationGracePeriodSeconds: 30
status:
availableReplicas: 2
observedGeneration: 8
replicas: 2
updatedReplicas: 2
Le problème que j'observe est que Kubernetes place les deux répliques (dans le déploiement, j'en ai demandé deux) sur le même nœud. Si ce nœud tombe en panne, je perds les deux conteneurs et le service passe en mode hors connexion.
Ce que je souhaite, c'est que Kubernetes veille à ce qu'il ne double pas les conteneurs sur le même nœud où les conteneurs sont du même type - cela ne consomme que des ressources et ne fournit aucune redondance. J'ai parcouru la documentation sur les déploiements, les jeux de réplicas, les nœuds, etc., mais je n'ai trouvé aucune option me permettant de dire à Kubernetes de le faire.
Existe-t-il un moyen de dire à Kubernetes combien de redondance est nécessaire sur les nœuds pour un conteneur?
EDIT: Je ne suis pas sûr que les étiquettes vont fonctionner; les étiquettes limitent le lieu d'exécution d'un nœud afin qu'il ait accès aux ressources locales (SSD), etc. Tout ce que je veux faire, c'est éviter tout temps mort si un nœud est mis hors ligne.
Je pense que vous recherchez les sélecteurs Affinity/Anti-Affinity.
Affinity sert à la co-localisation de pods. Je souhaite donc que mon site Web tente de planifier sur le même hôte que mon cache, par exemple. Par contre, l'anti-affinité est l'inverse: ne planifiez pas sur un hôte conformément à un ensemble de règles.
Donc, pour ce que vous faites, je regarderais de plus près ces deux liens: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#never-co-located -in-the-same-node
https://kubernetes.io/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure
Si vous créez un service pour ce déploiement, avant créant ledit déploiement, Kubernetes répartira vos pods sur plusieurs nœuds. Ce comportement provient du planificateur. Il est fourni de manière optimale, à condition que vous disposiez de suffisamment de ressources sur les deux nœuds.
Dans la documentation Kubernetes ( Gestion des ressources ):
il est préférable de spécifier d'abord le service, car cela permettra au planificateur de répartir les modules associés au service tels qu'ils sont créés par le ou les contrôleurs, tels que Déploiement.
Autres informations: Meilleures pratiques de configuration - Service .
Je suis d'accord avec Antoine Cotten pour utiliser un service pour votre déploiement. Un service maintient toujours un service en place en créant un nouveau pod si, pour une raison quelconque, un pod est en train de mourir dans un nœud donné. Toutefois, si vous souhaitez simplement répartir un déploiement entre tous les nœuds, vous pouvez utiliser pod anti affinity dans votre fichier manifeste de pod. Je mets un exemple sur ma page gitlab que vous pouvez également trouver dans Kubernetes Blog . Pour votre commodité, je donne l'exemple ici aussi.
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: kubernetes.io/hostname
containers:
- name: nginx
image: gcr.io/google_containers/nginx-slim:0.8
ports:
- containerPort: 80
Dans cet exemple, chaque déploiement a une étiquette qui est app et la valeur de cette étiquette est nginx. Dans les spécifications de pod, vous avez podAntiAffinity qui limite le fait d'avoir deux mêmes pods (label app: nginx) dans un noeud. Vous pouvez également utiliser podAffinity si vous souhaitez placer plusieurs déploiements dans un nœud.
Si un nœud tombe en panne, tous les pods qui y sont exécutés seraient automatiquement redémarrés sur un autre nœud.
Si vous commencez à spécifier exactement où vous voulez qu'ils s'exécutent, vous perdez en fait la capacité de Kubernetes de les replanifier sur un autre noeud.
La pratique habituelle est donc simplement de laisser Kubernetes agir.
Si, toutefois, vous avez des exigences valides pour exécuter un pod sur un nœud spécifique, en raison des exigences relatives à certains types de volumes locaux, etc., lisez ce qui suit:
Peut-être qu'une DaemonSet fonctionnera mieux. J'utilise DaemonStets avec nodeSelector pour exécuter des pods sur des nœuds spécifiques et éviter la duplication.