Пожалуйста, используйте этот шаблон при сообщении об ошибке и предоставьте как можно больше информации. Невыполнение этого может привести к тому, что ваша ошибка не будет исправлена своевременно. Благодаря! Если проблема связана с безопасностью, сообщите об этом в частном порядке через https://kubernetes.io/security/.
Что произошло : я изменил настройки pod-eviction-timeout
kube-controller-manager на главном узле (чтобы уменьшить время, по истечении которого k8s повторно создаст под в случае сбоя узла). Значение по умолчанию 5 минут, я настроил 30 секунд. С помощью команды sudo docker ps --no-trunc | grep "kube-controller-manager"
я проверил, что модификация была успешно применена:
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"
Я применил базовое развертывание с двумя репликами:
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
Первый модуль создается на первом рабочем узле, второй модуль создается на втором рабочем узле:
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>
Чтобы проверить правильность вытеснения пода, я выключил первый рабочий узел. Примерно через 1 минуту статус первого рабочего узла изменился на NotReady, затем
Мне пришлось подождать +5 минут (что является тайм-аутом удаления модуля по умолчанию), чтобы модуль на выключенном узле был воссоздан на другом узле.
Что вы ожидали :
После того, как статус узла сообщает "NotReady", модуль должен быть воссоздан на другом узле через 30 секунд вместо 5 минут по умолчанию!
Как это воспроизвести (максимально минимально и точно) :
Создайте три узла. Запустите Kubernetes на первом узле ( sudo kubeadm init
), примените сетевой плагин ( kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
), затем присоединитесь к двум другим узлам (например: kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac
).
Добавьте параметр pod-eviction-timeout в Kube Controller Manager на главном узле: 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
(yaml усечен, здесь показана только соответствующая первая часть).
Убедитесь, что настройки применены:
sudo docker ps --no-trunc | grep "kube-controller-manager"
Примените развертывание с двумя репликами, убедитесь, что один модуль создан на первом рабочем узле, а второй - на втором рабочем узле.
Выключите один из узлов и проверьте время, прошедшее между событием, когда узел сообщает «NotReady» и созданный модуль повторно.
Что еще нам нужно знать? :
У меня такая же проблема в среде с несколькими мастерами.
Окружающая среда :
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 Вт, 15 января 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux@ kubernetes / сиг-узел-ошибки
@ kubernetes / сиг-приложения-ошибки
@danielloczi :
@ kubernetes / сиг-узел-ошибки, @ кубернетес / сиг-приложения-ошибки
В ответ на это :
@ kubernetes / сиг-узел-ошибки
@ kubernetes / сиг-приложения-ошибки
Инструкции по взаимодействию со мной с помощью PR-комментариев доступны здесь . Если у вас есть вопросы или предложения, связанные с моим поведением, сообщите о проблеме в репозиторий kubernetes / test-infra .
Я также столкнулся с этой проблемой при тестировании установки меньшего времени ожидания выселения. После того, как я некоторое время копался в этом, я понял, что причина в новом TaintBasedEvictions.
В версии 1.13 функция TaintBasedEvictions повышена до бета-версии и включена по умолчанию, следовательно, taints автоматически добавляются NodeController (или kubelet), а обычная логика для удаления подов с узлов на основе Ready NodeCondition отключена.
Установка для этого флага функции значения false приводит к тому, что поды удаляются, как и ожидалось. У меня не было времени на поиск кода выселения на основе заражения, но я предполагаю, что мы не используем в нем этот флаг тайм-аута выселения.
Подробнее об этом. Если для TaintBasedEvictions установлено значение true, вы можете установить время выселения ваших подов в пределах его спецификации в соответствии с допусками:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-выселения
Значения по умолчанию для них устанавливаются контроллером допуска: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
Эти два флага можно установить через kube-apiserver, и они должны дать тот же эффект.
// 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.
Спасибо за отзыв, Шеф Александр!
Такова ситуация, написали вы. Я проверил стручки и убедился, что стручкам присвоены значения по умолчанию для допуска:
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
Поэтому я просто добавил свои собственные значения в развертывание:
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
После применения развертывания в случае сбоя узла статус узла меняется на «NotReady», а затем поды создаются заново через 2 секунды.
Таким образом, нам больше не нужно иметь дело с таймаутом выселения пода, тайм-аут может быть установлен на основе пода! Круто!
Еще раз спасибо за помощь!
@danielloczi Привет, danielloczi, как решить эту проблему? Я тоже встречаюсь с этой проблемой
@ 323929 Я думаю, что @danielloczi не заботится о параметре pod-eviction-timeout
в kube-controller-manager, но решает его с помощью Taint based Evictions
, Я тестировал с Taint based Evictions
, он работал для меня.
Правильно: я просто начал использовать Taint based Eviction
.
Можно ли сделать его глобальным? Я не хочу включать это для каждой конфигурации пода, особенно потому, что я использую много подготовленных вещей из helm
+1 за возможность настроить его для всего кластера. настройка для каждого модуля или развертывания редко бывает полезной: в большинстве случаев разумное глобальное значение намного удобнее, а текущее значение по умолчанию 5 м для многих случаев является слишком большим.
пожалуйста, повторно откройте этот вопрос.
Я столкнулся с той же проблемой: есть ли способ отключить выселение на основе Taint и что таймаут pod-eviction-timeout работает в глобальном режиме?
Я столкнулся с той же проблемой: есть ли способ отключить выселение на основе Taint и что таймаут pod-eviction-timeout работает в глобальном режиме?
Я думаю, что вы можете настроить глобальное вытеснение подов через apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
Я не пробовал это, но, как я вижу, есть варианты: --default-not-ready-допуск-секунды и --default-unreachable-толерантность-секунды.
Почему эта ошибка была отмечена как закрытая? Похоже, что первоначальная проблема не решена, а только обоснована.
Мне непонятно, почему не работает флаг pod-eviction-timeout
та же проблема
Самый полезный комментарий
Спасибо за отзыв, Шеф Александр!
Такова ситуация, написали вы. Я проверил стручки и убедился, что стручкам присвоены значения по умолчанию для допуска:
Поэтому я просто добавил свои собственные значения в развертывание:
После применения развертывания в случае сбоя узла статус узла меняется на «NotReady», а затем поды создаются заново через 2 секунды.
Таким образом, нам больше не нужно иметь дело с таймаутом выселения пода, тайм-аут может быть установлен на основе пода! Круто!
Еще раз спасибо за помощь!