Tengo una implementación con 2 réplicas. Me gustaría especificar que, cuando sea posible, se debe equilibrar la carga de los pods entre tantos nodos/nombres de host. Hasta ahora, tengo las siguientes especificaciones:
apiVersion: apps/v1 kind: Deployment metadata: name: topspin-apollo-backend-staging-dep labels: app: topspin-apollo-backend env: staging spec: replicas: 2 selector: matchLabels: app: topspin-apollo-backend env: staging template: metadata: labels: app: topspin-apollo-backend env: staging spec: containers: - name: topspin-apollo-backend image: rwu1997/topspin-apollo-backend:latest imagePullPolicy: Always envFrom: - secretRef: name: topspin-apollo-backend-staging-secrets ports: - containerPort: 8000 imagePullSecrets: - name: regcred affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: topspin-apollo-backend env: staging topologyKey: "kubernetes.io/hostname" Si kubectl apply esta implementación desde cero, k8s programa correctamente un pod en cada uno de los 2 nodos del clúster (A y B). Si elimino uno de los nodos B, el pod correspondiente se vuelve a programar en el último nodo A restante (como se esperaba).
Cuando vuelvo a agregar otro nodo C al clúster, los dos pods permanecen programados en el nodo A. Esto es lo esperado, hasta donde yo sé.
¿Hay alguna manera de activar el programador para volver a equilibrar los 2 pods entre el nodo A y C?
kubectl scale --replicas=4 , tengo dos pods adicionales programados en el nodo C, luego kubectl scale --replicas=2 , pero parece eliminar los 2 pods programados más recientemente (en lugar de priorizar el pod anti- afinidad).
Un método que funciona es kubectl delete the deployment y luego kubectl apply , pero esto introduce tiempo de inactividad.
Otro método es kubectl scale --replicas=1 , luego kubectl scale --replicas=2 , pero es menos que ideal ya que solo existe 1 réplica por un período de tiempo.
Creo que necesitas usar descheduler . Junto con algunos otros casos de uso, una cosa en la que ayuda son los escenarios en los que los requisitos de afinidad de pod/nodo ya no se cumplen debido a cambios en el clúster.
El desprogramador se puede ejecutar como un Trabajo o CronJob dentro de un clúster k8s. Admite algunas estrategias y, en su caso, la estrategia RemoveDuplicates debería ser útil. Es bastante sencillo de usar. Eche un vistazo a los documentos y la configuración de ejemplohttps://github.com/kubernetes-sigs/descheduler#removeduplicates
También me enfrenté a este escenario, incluido uno más en el que a veces quiero mover el único pod a otro nodo (debido a la necesidad de recursos). Normalmente sigo esto-
kubectl cordon <NODE> #delete pod on this NODE kubectl delete pod <pod name> # once the pod is created on another node. kubectl uncrodon <NODE>Para pods individuales, escalamos la implementación después del cordón de NODE para evitar cualquier tiempo de inactividad para ese servicio. puedes probar esto