Кубэ-СНД.Высокая доступность.Обработка ошибок в kuberntes - PullRequest
Новая
       37

Кубэ-СНД.Высокая доступность.Обработка ошибок в kuberntes

0 голосов
/ 27 февраля 2019

У меня есть кластер kubernetes с несколькими узлами.У меня kube-dns работает в 3-х узлах.

Проблема, с которой я столкнулся, заключается в том, что если один из этих 3-х узлов завершает работу, запросы между моими модулями / контейнерами начинают более или менее сбоить 1 из 3 раз.

Это связано с тем, что когда контейнер разрешает имя хоста службы k8s, он вызывает службу kube-dns для разрешения этого имени хоста, а службы kube-dns k8s имеют три конечные точки, но одна из этих трех конечных точек недопустима в качестве узлавнизK8s не обновляет службу, пока не обнаружит, что узел не работает.(В настоящее время у меня установлено 60 секунд).

Есть идеи, как это смягчить?Есть ли какие-либо повторные попытки, которые можно настроить вне приложения?Что-то в контейнере или на уровне k8s.

Спасибо.

1 Ответ

0 голосов
/ 05 марта 2019

Основным участником связи между базовыми ресурсами Kubernetes на конкретном узле и kube-apiserver является kubelet .Его роль может быть определена как агент узла.Следовательно, kubelet играет важную роль в жизненном цикле кластера благодаря основным обязанностям, таким как управление датчиками жизнеспособности и готовности для вложенных объектов, обновление хранилища ETCD для записи метаданных для ресурсов и периодическое обновление собственного состояния работоспособности вkube-apiserver, заданный флагом --node-status-update-frequency в конфигурации kubelet.

- длительность-обновления-частоты-узла-узла Указывает, как часто Kubelet отправляет статус узла мастеру.Примечание: будьте осторожны при изменении константы, она должна работать с nodeMonitorGracePeriod в nodecontroller.(по умолчанию 10 с)

Однако в Kubernetes есть специальный компонент, называемый Контроллер узла .Одна из важнейших ролей контроллера узла - проверка статуса задействованных работников путем контроля соответствующего пульса с kubelet.Есть некоторые конкретные флаги, которые описывают это поведение, и по умолчанию эти флаги были включены в kube-controller-manager конфигурация:

  • --node-monitor-period - Проверьте статус kubelet с помощьюуказанный интервал времени (значение по умолчанию 5 с);
  • --node-monitor-grace-period - время, в течение которого диспетчер контроллера Kubernetes рассматривает исправное состояние Kubelet (значение по умолчанию 40 с);
  • --pod-eviction-timeout - время отсрочкиудаление модулей на сбойных узлах (значение по умолчанию 5 м).

Всякий раз, когда вы хотите уменьшить отказ DNS-модулей, в случае отказа узла, вы должны рассмотреть эти варианты.Вы также можете взглянуть на Горизонтальный автоскалер DNS , чтобы выровнять стабильное количество реплик для модулей DNS, однако это приводит к реализации некоторой дополнительной логической структуры, которая может потреблять больше вычислительных ресурсов в ядре кластера.

...