Блог

Я пытаюсь лучше понять «под капотом», как работает процесс планирования и создания модуля Kubernetes, в отношении взаимодействия между kubelet и kube-apiserver .

Я понимаю, что планировщик Kubernetes выбирает узел для выделения нового модуля и уведомляет об этом сервер API. Однако мне неясно, как сервер API уведомляет kubelet соответствующий узел о запуске модуля. Существует ли процесс опроса kubelet , который запрашивает изменения у сервера API? Или существует взаимодействие типа прослушиватель событий / обратный вызов?

Если кто-нибудь знает ответ или может указать мне в направлении какой-либо документации, я был бы очень признателен!

У Alibaba был действительно проницательный пост в блоге о внутренней работе планировщика. Из блога:

Планировщик в основном работает следующим образом:

• Планировщик поддерживает запланированную очередь и прослушивает сервер APIServer.
• Когда мы создаем модуль, мы сначала записываем метаданные модуля в etcd через сервер APIServer.
• Планировщик прослушивает статус модуля через информер. При добавлении нового модуля модуль добавляется в очередь.
• Основной процесс непрерывно извлекает модули из очереди и назначает узлы для модулей.
• Процесс планирования состоит из двух этапов: фильтруйте соответствующие узлы и расставляйте приоритеты для этих узлов на основе конфигурации модуля Pod (например, по таким показателям, как использование ресурсов и привязка), чтобы оценить узлы и выбрать узел с наибольшим количеством баллов.
• После успешного назначения узла вызовите интерфейс модуля привязки apiServer и установите pod.Spec.nodeName для назначенного модуля.
• Kubelet на узле также прослушивает сервер ApiServer. Если он обнаруживает, что новый модуль запланирован для этого узла, для запуска контейнера вызывается локальный dockerDaemon.
• Если планировщику не удается запланировать модуль, если приоритет и вытеснение включены, сначала делается попытка вытеснения, модули с низким приоритетом на узле удаляются, а модули, которые должны быть запланированы, будут запланированы на узел. Если выгрузка не включена или попытка выгрузки завершается неудачей, соответствующая информация будет записана в журналы, а модули будут добавлены в конец очереди.

При опросе Kubelet: на самом деле сервер API поддерживает режим «просмотра», который использует протокол WebSocket. Таким образом, Kubelet уведомляется о любом изменении модулей с именем хоста, равным имени хоста Kubelet.

Ответ без ссылки на исходный код, но я уверен kubelet , что это работает так:

• список модулей https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#list-pod-v1-core
• поместите a watch в список
• модули grep в PodScheduled состоянии
• модули grep, где spec.nodeName==$hostname
• повторять при каждом событии просмотра

 Query Parameters
...
watch   Watch for changes to the described resources and return them as a stream of add, update, and remove notifications. Specify resourceVersion.
  

Функциональность просмотра унаследована от etcd (базы данных за сервером API): https://etcd.io/docs/v3.2.17/learning/api /. См . Watch streams :

 Watches are long running requests and use gRPC streams to stream event data.
  

Итак, это своего рода длительный опрос.