Utilice esta plantilla cuando informe un error y proporcione la mayor cantidad de información posible. Si no lo hace, es posible que su error no se solucione de manera oportuna. ¡Gracias! Si el asunto está relacionado con la seguridad, infórmelo de forma privada a través de https://kubernetes.io/security/
Qué sucedió : modifiqué la configuración pod-eviction-timeout
de kube-controller-manager en el nodo maestro (para disminuir la cantidad de tiempo antes de que k8s vuelva a crear un pod en caso de falla del nodo). El valor predeterminado es de 5 minutos, configuré 30 segundos. Usando el comando sudo docker ps --no-trunc | grep "kube-controller-manager"
, verifiqué que la modificación se haya aplicado correctamente:
kubeadmin<strong i="10">@nodetest21</strong>:~$ sudo docker ps --no-trunc | grep "kube-controller-manager"
387261c61ee9cebce50de2540e90b89e2bc710b4126a0c066ef41f0a1fb7cf38 sha256:0482f640093306a4de7073fde478cf3ca877b6fcc2c4957624dddb2d304daef5 "kube-controller-manager --address=127.0.0.1 --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --client-ca-file=/etc/kubernetes/pki/ca.crt --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --use-service-account-credentials=true --pod-eviction-timeout=30s"
Apliqué una implementación básica con dos réplicas:
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: busybox
template:
metadata:
labels:
app: busybox
spec:
containers:
- image: busybox
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
name: busybox
restartPolicy: Always
El primer pod creado en el primer nodo trabajador, el segundo pod creado en el segundo nodo trabajador:
NAME STATUS ROLES AGE VERSION
nodetest21 Ready master 34m v1.13.3
nodetest22 Ready <none> 31m v1.13.3
nodetest23 Ready <none> 30m v1.13.3
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
default busybox-74b487c57b-5s6g7 1/1 Running 0 13s 10.44.0.2 nodetest22 <none> <none>
default busybox-74b487c57b-6zdvv 1/1 Running 0 13s 10.36.0.1 nodetest23 <none> <none>
kube-system coredns-86c58d9df4-gmcjd 1/1 Running 0 34m 10.32.0.2 nodetest21 <none> <none>
kube-system coredns-86c58d9df4-wpffr 1/1 Running 0 34m 10.32.0.3 nodetest21 <none> <none>
kube-system etcd-nodetest21 1/1 Running 0 33m 10.0.1.4 nodetest21 <none> <none>
kube-system kube-apiserver-nodetest21 1/1 Running 0 33m 10.0.1.4 nodetest21 <none> <none>
kube-system kube-controller-manager-nodetest21 1/1 Running 0 20m 10.0.1.4 nodetest21 <none> <none>
kube-system kube-proxy-6mcn8 1/1 Running 1 31m 10.0.1.5 nodetest22 <none> <none>
kube-system kube-proxy-dhdqj 1/1 Running 0 30m 10.0.1.6 nodetest23 <none> <none>
kube-system kube-proxy-vqjg8 1/1 Running 0 34m 10.0.1.4 nodetest21 <none> <none>
kube-system kube-scheduler-nodetest21 1/1 Running 1 33m 10.0.1.4 nodetest21 <none> <none>
kube-system weave-net-9qls7 2/2 Running 3 31m 10.0.1.5 nodetest22 <none> <none>
kube-system weave-net-h2cb6 2/2 Running 0 33m 10.0.1.4 nodetest21 <none> <none>
kube-system weave-net-vkb62 2/2 Running 0 30m 10.0.1.6 nodetest23 <none> <none>
Para probar el desalojo correcto de la vaina, apago el primer nodo trabajador. Después de ~ 1 min, el estado del primer nodo trabajador cambió a "NotReady", luego
Tuve que esperar +5 minutos (que es el tiempo de espera de desalojo predeterminado del pod) para que el pod en el nodo apagado se vuelva a crear en el otro nodo.
Qué esperabas que sucediera :
Después de que el estado del nodo informe "NotReady", el pod debe volver a crearse en el otro nodo después de 30 segundos en lugar de los 5 minutos predeterminados.
Cómo reproducirlo (de la forma más mínima y precisa posible) :
Crea tres nodos. Inicie Kubernetes en el primer nodo ( sudo kubeadm init
), aplique el complemento de red ( kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
), luego únase a los otros dos nodos (como: kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac
).
Agregue el parámetro pod-eviction-timeout a Kube Controller Manager en el nodo principal: sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml
:
apiVersion: v1
kind: Pod
metadata:
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
creationTimestamp: null
labels:
component: kube-controller-manager
tier: control-plane
name: kube-controller-manager
namespace: kube-system
spec:
containers:
- command:
- kube-controller-manager
- --address=127.0.0.1
- --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
- --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
- --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
- --controllers=*,bootstrapsigner,tokencleaner
- --kubeconfig=/etc/kubernetes/controller-manager.conf
- --leader-elect=true
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
- --root-ca-file=/etc/kubernetes/pki/ca.crt
- --service-account-private-key-file=/etc/kubernetes/pki/sa.key
- --use-service-account-credentials=true
- --pod-eviction-timeout=30s
(el yaml está truncado, aquí solo se muestra la primera parte relacionada).
Compruebe que se aplique la configuración:
sudo docker ps --no-trunc | grep "kube-controller-manager"
Aplique una implementación con dos réplicas, verifique que se cree un pod en el primer nodo trabajador y el segundo en el segundo nodo trabajador.
Apague uno de los nodos y verifique el tiempo transcurrido entre el evento, cuando el nodo informa "NotReady" y el pod se vuelve a crear.
¿Algo más que necesitemos saber? :
También experimento el mismo problema en un entorno multimaestro.
Medio ambiente :
kubectl version
): v1.13.3cat /etc/os-release
): NAME = "Ubuntu" VERSION = "16.04.5 LTS (Xenial Xerus)"uname -a
): Linux nodetest21 4.15.0-1037-azure # 39 ~ 16.04.1-Ubuntu SMP Mar 15 de enero 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux@ kubernetes / sig-node-bugs
@ kubernetes / sig-apps-bugs
@danielloczi : Reiterando las menciones para activar una notificación:
@ kubernetes / sig-node-bugs, @ kubernetes / sig-apps-bugs
En respuesta a esto :
@ kubernetes / sig-node-bugs
@ kubernetes / sig-apps-bugs
Las instrucciones para interactuar conmigo usando comentarios de relaciones públicas están disponibles aquí . Si tiene preguntas o sugerencias relacionadas con mi comportamiento, presente un problema en el repositorio de kubernetes / test-infra .
También encontré este problema al probar la configuración del tiempo de espera de desalojo más bajo. Después de hurgar en esto durante algún tiempo, descubrí que la causa es el nuevo TaintBasedEvictions.
En la versión 1.13, la función TaintBasedEvictions se promueve a beta y se habilita de forma predeterminada, por lo tanto, NodeController (o kubelet) agrega automáticamente las taints y la lógica normal para desalojar pods de nodos basados en Ready NodeCondition está deshabilitada.
Establecer el indicador de función para esto en falso hace que los pods se desalojen como se esperaba. No me he tomado el tiempo de buscar en el código de desalojo basado en la corrupción, pero supongo que no estamos utilizando esta marca de tiempo de espera de desalojo en él.
Mirando esto más. Con TaintBasedEvictions establecido en verdadero, puede establecer el tiempo de desalojo de sus pods dentro de sus especificaciones bajo tolerancias:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-evictions
Los valores predeterminados de estos los establece un controlador de admisión: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
Esas dos banderas se pueden configurar a través de kube-apiserver y deberían lograr el mismo efecto.
// Controller will not proactively sync node health, but will monitor node
// health signal updated from kubelet. There are 2 kinds of node healthiness
// signals: NodeStatus and NodeLease. NodeLease signal is generated only when
// NodeLease feature is enabled. If it doesn't receive update for this amount
// of time, it will start posting "NodeReady==ConditionUnknown". The amount of
// time before which Controller start evicting pods is controlled via flag
// 'pod-eviction-timeout'.
// Note: be cautious when changing the constant, it must work with
// nodeStatusUpdateFrequency in kubelet and renewInterval in NodeLease
// controller. The node health signal update frequency is the minimal of the
// two.
// There are several constraints:
// 1. nodeMonitorGracePeriod must be N times more than the node health signal
// update frequency, where N means number of retries allowed for kubelet to
// post node status/lease. It is pointless to make nodeMonitorGracePeriod
// be less than the node health signal update frequency, since there will
// only be fresh values from Kubelet at an interval of node health signal
// update frequency. The constant must be less than podEvictionTimeout.
// 2. nodeMonitorGracePeriod can't be too large for user experience - larger
// value takes longer for user to see up-to-date node health.
¡Gracias por sus comentarios ChiefAlexander!
Esa es la situación, escribiste. Revisé los pods y me aseguré de que existen los valores predeterminados asignados al pod para la tolerancia:
kubectl describe pod busybox-74b487c57b-95b6n | grep -i toleration -A 2
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Así que simplemente agregué mis propios valores a la implementación:
apiVersion: apps/v1
kind: Deployment
metadata:
name: busybox
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: busybox
template:
metadata:
labels:
app: busybox
spec:
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 2
- key: "node.kubernetes.io/not-ready"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 2
containers:
- image: busybox
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
name: busybox
restartPolicy: Always
Después de aplicar la implementación en caso de falla del nodo, el estado del nodo cambia a "NotReady", luego los pods se vuelven a crear después de 2 segundos.
Por lo tanto, ya no tenemos que lidiar con el tiempo de espera de desalojo de pod, ¡el tiempo de espera se puede establecer en base a Pod! ¡Frio!
¡De nuevo, gracias por tu ayuda!
@danielloczi Hola danielloczi, ¿Cómo solucionas este problema? También me encuentro con este problema
@ 323929 Creo que a @danielloczi no le importa el parámetro pod-eviction-timeout
en kube-controller-manager, pero lo resuelve usando Taint based Evictions
, probé con Taint based Evictions
, funcionó para mi.
Así es: simplemente comencé a usar Taint based Eviction
.
¿Es posible hacerlo global? No quiero habilitar eso para cada configuración de pod, especialmente porque uso muchas cosas preparadas de helm
+1 por tener la posibilidad de configurarlo por todo el cluster. El ajuste por módulo o por implementación rara vez es útil: en la mayoría de los casos, un valor global sensato es mucho más conveniente y el valor predeterminado actual de 5 m es demasiado largo para muchos casos.
por favor, vuelva a abrir este problema.
Estoy enfrentando este mismo problema, ¿hay alguna manera de inhabilitar los desalojos basados en Taint y que el tiempo de espera de desalojo de pod funcione en modo global?
Estoy enfrentando este mismo problema, ¿hay alguna manera de inhabilitar los desalojos basados en Taint y que el tiempo de espera de desalojo de pod funcione en modo global?
Creo que puede configurar el desalojo global de pod a través de apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
No probé esto, pero como puedo ver, hay opciones: --default-not-ready-toleration-seconds y --default-unreachable-toleration-seconds.
¿Por qué se marcó este error como cerrado? Parece que el problema original no está resuelto, solo funciona.
No me queda claro por qué la marca de tiempo de espera de desalojo de pod no funciona
mismo problema
Comentario más útil
¡Gracias por sus comentarios ChiefAlexander!
Esa es la situación, escribiste. Revisé los pods y me aseguré de que existen los valores predeterminados asignados al pod para la tolerancia:
Así que simplemente agregué mis propios valores a la implementación:
Después de aplicar la implementación en caso de falla del nodo, el estado del nodo cambia a "NotReady", luego los pods se vuelven a crear después de 2 segundos.
Por lo tanto, ya no tenemos que lidiar con el tiempo de espera de desalojo de pod, ¡el tiempo de espera se puede establecer en base a Pod! ¡Frio!
¡De nuevo, gracias por tu ayuda!