Utilizando la Anti afinidad de pods para forzar solo 1 pod por nodo.
Estoy tratando de lograr que mi implementación solo despliegue réplicas en nodos que no estén ejecutando RabbitMQ (esto funciona) y que tampoco tengan ya la cápsula que estoy desplegando (no funciona).
No puedo lograr que esto funcione. Por ejemplo, si tengo 3 nodos (2 con la etiqueta app.kubernetes.io/part-of=rabbitmq), entonces las 2 réplicas se despliegan en el nodo restante. Es como si los despliegues no tuvieran en cuenta sus propias cápsulas creadas al determinar la anti-afinidad. Mi estado deseado es que solo se despliegue 1 cápsula y que la otra no se programe.
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-scraper
namespace: scrapers
labels:
k8s-app: test-scraper-deployment
spec:
replicas: 2
selector:
matchLabels:
app: testscraper
template:
metadata:
labels:
app: testscraper
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app.kubernetes.io/part-of
operator: In
values:
- rabbitmq
- key: app
operator: In
values:
- testscraper
namespaces: [scrapers, rabbitmq]
topologyKey: "kubernetes.io/hostname"
containers:
- name: test-scraper
image: #######:latest
davy.ai
Parece que la regla de anti-afinidad actual definida en la sección
affinity
de la especificación del despliegue no es suficiente para evitar la programación de pods en nodos que ya tienen un pod con las mismas etiquetas.Una posible solución para lograr el comportamiento deseado es usar la regla
podAffinity
en lugar depodAntiAffinity
, con una combinación de las reglasrequiredDuringSchedulingIgnoredDuringExecution
ypreferredDuringSchedulingIgnoredDuringExecution
.Aquí tienes un ejemplo de especificación de despliegue que implementa este enfoque:
Esta especificación define una regla
podAffinity
que requiere que los nodos tengan un pod con las etiquetasapp.kubernetes.io/part-of=rabbitmq
para ser ignorados al programar nuevos pods. Además, define una reglapreferredDuringSchedulingIgnoredDuringExecution
que prefiere los nodos que no tienen un pod con las etiquetasapp=testscraper
, pero aún permite la programación en nodos que ya tienen un pod con las mismas etiquetas si no hay otros nodos disponibles.Ten en cuenta que este enfoque no siempre dará lugar al comportamiento deseado si no hay suficientes nodos disponibles que cumplan con las reglas de afinidad. Además, es importante asegurarse de que las etiquetas utilizadas para las reglas de afinidad estén presentes y sean correctas en los nodos y pods relevantes.