En esta página, se muestra cómo resolver problemas con el programador de Kubernetes (kube-scheduler) para Google Distributed Cloud.
Kubernetes siempre programa Pods en el mismo conjunto de nodos.
Este error se puede observar de varias maneras:
Uso desequilibrado del clúster Puedes inspeccionar el uso del clúster para cada nodo con el comando
kubectl top nodes. En el siguiente resultado de ejemplo exagerado, se muestra un uso pronunciado en ciertos nodos:NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% XXX.gke.internal 222m 101% 3237Mi 61% YYY.gke.internal 91m 0% 2217Mi 0% ZZZ.gke.internal 512m 0% 8214Mi 0%Demasiadas solicitudes. Si programas muchos Pods a la vez en el mismo nodo y esos Pods realizan solicitudes HTTP, es posible que el nodo tenga un límite de frecuencia. El error común que muestra el servidor en esta situación es
429 Too Many Requests.Servicio no disponible. Por ejemplo, un servidor web alojado en un nodo con una carga alta podría responder a todas las solicitudes con errores
503 Service Unavailablehasta que tenga una carga más ligera.
Para verificar si tienes Pods que siempre se programan en los mismos nodos, sigue estos pasos:
Ejecuta el siguiente comando
kubectlpara ver el estado de los pods:kubectl get pods -o wide -n defaultPara ver la distribución de Pods entre los nodos, revisa la columna
NODEen el resultado. En el siguiente resultado de ejemplo, todos los Pods se programan en el mismo nodo:NAME READY STATUS RESTARTS AGE IP NODE nginx-deployment-84c6674589-cxp55 1/1 Running 0 55s 10.20.152.138 10.128.224.44 nginx-deployment-84c6674589-hzmnn 1/1 Running 0 55s 10.20.155.70 10.128.226.44 nginx-deployment-84c6674589-vq4l2 1/1 Running 0 55s 10.20.225.7 10.128.226.44
Los Pods tienen varias funciones que te permiten ajustar su comportamiento de programación. Estas funciones incluyen restricciones de propagación de topología y reglas antiafinidad. Puedes usar una de estas funciones o combinarlas. kube-scheduler une los requisitos que definas con la conjunción Y.
Los registros del programador no se capturan en el nivel de verbosidad de registro predeterminado. Si necesitas los registros del programador para solucionar problemas, sigue estos pasos para capturarlos:
Aumenta el nivel de verbosidad de los registros:
Edita el Deployment
kube-scheduler:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit deployment kube-scheduler \ -n USER_CLUSTER_NAMESPACEAgrega la marca
--v=5en la secciónspec.containers.command:containers: - command: - kube-scheduler - --profiling=false - --kubeconfig=/etc/kubernetes/scheduler.conf - --leader-elect=true - --v=5
Cuando termines de solucionar el problema, restablece el nivel de verbosidad al nivel predeterminado:
Edita el Deployment
kube-scheduler:kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit deployment kube-scheduler \ -n USER_CLUSTER_NAMESPACEVuelve a establecer el nivel de verbosidad en el valor predeterminado:
containers: - command: - kube-scheduler - --profiling=false - --kubeconfig=/etc/kubernetes/scheduler.conf - --leader-elect=true
Restricciones de distribución de topología
Las restricciones de distribución de topología se pueden usar para distribuir Pods de manera uniforme entre los nodos según su zones, regions, node o cualquier otra topología definida por el usuario.
En el siguiente manifiesto de ejemplo, se muestra una implementación que distribuye las réplicas de forma uniforme entre todos los nodos programables con restricciones de propagación de topología:
apiVersion: apps/v1
kind: Deployment
metadata:
name: topology-spread-deployment
labels:
app: myapp
spec:
replicas: 30
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
topologySpreadConstraints:
- maxSkew: 1 # Default. Spreads evenly. Maximum difference in scheduled Pods per Node.
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule # Default. Alternatively can be ScheduleAnyway
labelSelector:
matchLabels:
app: myapp
matchLabelKeys: # beta in 1.27
- pod-template-hash
containers:
# pause is a lightweight container that simply sleeps
- name: pause
image: registry.k8s.io/pause:3.2
Se aplican las siguientes consideraciones cuando se usan restricciones de propagación de topología:
- El
labels.app: myappde un Pod coincide con ellabelSelectorde la restricción. topologyKeyespecificakubernetes.io/hostname. Esta etiqueta se adjunta automáticamente a todos los nodos y se propaga con el nombre de host del nodo.matchLabelKeysevita que los lanzamientos de nuevas implementaciones consideren Pods de revisiones anteriores cuando se calcula dónde programar un Pod. La etiquetapod-template-hashse completa automáticamente con una implementación.
Antiafinidad de pods
La antiafinidad de Pods te permite definir restricciones para las que los Pods se pueden ubicar en el mismo nodo.
En el siguiente manifiesto de ejemplo, se muestra una implementación que usa la antiafinidad para limitar las réplicas a un pod por nodo:
apiVersion: apps/v1
kind: Deployment
metadata:
name: pod-affinity-deployment
labels:
app: myapp
spec:
replicas: 30
selector:
matchLabels:
app: myapp
template:
metadata:
name: with-pod-affinity
labels:
app: myapp
spec:
affinity:
podAntiAffinity:
# requiredDuringSchedulingIgnoredDuringExecution
# prevents Pod from being scheduled on a Node if it
# does not meet criteria.
# Alternatively can use 'preferred' with a weight
# rather than 'required'.
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- myapp
# Your nodes might be configured with other keys
# to use as `topologyKey`. `kubernetes.io/region`
# and `kubernetes.io/zone` are common.
topologyKey: kubernetes.io/hostname
containers:
# pause is a lightweight container that simply sleeps
- name: pause
image: registry.k8s.io/pause:3.2
En este ejemplo de implementación, se especifican 30 réplicas, pero solo se expande a la cantidad de nodos disponibles en tu clúster.
Se aplican las siguientes consideraciones cuando se usa la antiafinidad de Pods:
- El
labels.app: myappde un Pod coincide con ellabelSelectorde la restricción. topologyKeyespecificakubernetes.io/hostname. Esta etiqueta se adjunta automáticamente a todos los nodos y se propaga con el nombre de host del nodo. Puedes usar otras etiquetas si tu clúster las admite, comoregionozone.
Imágenes de contenedor preextraidas
A falta de otras restricciones, de forma predeterminada, kube-scheduler prefiere programar Pods en nodos que ya tienen la imagen del contenedor descargada. Este comportamiento puede ser de interés en clústeres más pequeños sin otras configuraciones de programación en las que sería posible descargar las imágenes en todos los nodos. Sin embargo, recurrir a este concepto debe considerarse como un último recurso. Una mejor solución es usar nodeSelector, restricciones de distribución de topología o afinidad o antiafinidad. Para obtener más información, consulta Asigna Pods a nodos.
Si quieres asegurarte de que las imágenes de contenedor se extraigan previamente en todos los nodos, puedes usar un DaemonSet como en el siguiente ejemplo:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: prepulled-images
spec:
selector:
matchLabels:
name: prepulled-images
template:
metadata:
labels:
name: prepulled-images
spec:
initContainers:
- name: prepulled-image
image: IMAGE
# Use a command the terminates immediately
command: ["sh", "-c", "'true'"]
containers:
# pause is a lightweight container that simply sleeps
- name: pause
image: registry.k8s.io/pause:3.2
Después de que el Pod sea Running en todos los nodos, vuelve a implementar los Pods para ver si los contenedores ahora se distribuyen de manera uniforme entre los nodos.