Удаление модуля анализа исходного кода Kubernetes

В этой статье в основном рассматривается процесс выполнения пода при его удалении.

задачи kube-apiserver

Обычно мы используем команду kubectl для удаления пода или напрямую вызываем интерфейс, предоставляемый apiserver через протокол http, для удаления пода. Следовательно, источником удаления Pod должен быть apiserver.
В предыдущем анализе kube-apiserver было проанализировано, что архитектура обработки http kube-apiserver использует go-restful. Среди них для удаления вызов естественноDELETEинтерфейс. Метод заключается в следующем (находится вkubernetes/staging/src/k8s.io/apiserver/pkg/endpoints/install.go下的registerResourceHandlers方法)

Конечным обработчиком этого метода являетсяrestfulDeleteResource

restfulDeleteResourceПродолжайте инкапсулировать обработчик и вызовитеDeleteResourceметод.DeleteResourceМетод очень длинный, но финальный вызов все равноDELETEМетоды, как показано ниже

DELETEметод находится вstaging/src/k8s.io/apiserver/pkg/registry/generic/registry/store.goВниз. существуетDELETEметод, самый важныйupdateForGracefulDeletionAndFinalizersметод, основная функция этого метода — изменить некоторую внутреннюю информацию пода, по сути, изменить два поля пода:DeletionTimestampа такжеDeletionGracePeriodSeconds, который вызываетBeforeDeleteметод

С помощью инструмента сравнения также можно обнаружить, что основные изменения поля следующие:

кубелет задачи

Анализируя код kubelet ранее, мы знаем, что kubelet отслеживает изменения apiserver через listwatch.

Как показано на рисунке, после отслеживания соответствующих изменений вызовите соответствующую логику обработки. В то же время кубелет также запускает горутину:statusManager

Метод запуска statusManager вызывается для запуска statusManager до syncLoop.
Способ запуска следующий:

Основная задача – вызватьsyncPodметод. В методе syncPod есть следующий фрагмент кода

Мы обнаружили, что kubelet снова вызывает интерфейс DELETE, почему так? Его еще не удалили? Не волнуйтесь, это основная часть операции DELETE, которую мы хотим проанализировать.

Глубокий анализ

Мы знаем, что если удаление Pod не принудительно удаляется, это фактически элегантное удаление, то есть изящное удаление. По умолчанию это изящное время составляет 30 секунд, т.е.grace-periodвремя. В задании kube-apiserver пройтиupdateForGracefulDeletionAndFinalizersметод установлен для PodDeletionTimestampиDeletionGracePeriodSecondsДва поля, в настоящее время Pod определяется как изящное состояние. Вернитесь к коду и завершите вызовupdateForGracefulDeletionAndFinalizersПосле метода ниже приводится заключение

Очевидно, потому что мы удаляем изящно, поэтомуdeleteImmediatelyПоле ложно, и на этом удаление заканчивается. Он полностью отличается от того, что мы себе представляли?
Все верно, реальная ситуация действительно такова, каждый раз, когда он удаляется, логика обработки аписервера прерывается. Следующий шаг — повторное знакомство с kubelet.
Когда Kubelet вызывает интерфейс удаления apiserver, будет заранее принято решение, и цепочка вызововcanBeDeleted-->PodResourcesAreReclaimed. существуетPodResourcesAreReclaimedВ методе основная задача — определить, были ли полностью закрыты и очищены ресурсы в поде, в том числеcontainers,processes,volumesа такжеcgroup sandboxресурс.

После того, как все ресурсы были очищены, на этот разcanBeDeletedМетод возвращает true, и kubelet вызывает интерфейс удаления API-сервера, чтобы снова удалить Pod. Однако, в отличие от изящного удаления, у этого вызова есть еще одинdeleteOptionsполе

Смысл понять несложно, то есть установить в поле gap-период значение 0, что означает, что на этот раз под принудительно удаляется. Поэтому аписервер снова получит запрос DELETE и продолжит процесс выполнения обработчика DELETE. В отличие от первого раза, на этот раз модуль удаляется принудительно, поэтому будет выполнен весь процесс, и apiserver перейдет к etcd, чтобы удалить окончательную информацию о модуле.

После того, как kubelet получает изменение события, оно преобразуется вREMOVEсобытие, которое завершает окончательную очистку Pod. На этом процесс удаления пода заканчивается.

Суммировать

При изящном удалении подов:
1. Обработчик apiserver выполняется дважды, первый раз в основном для изменения информации о поде и установкиDeletionTimestampиDeletionGracePeriodSecondsинформация, перейдите в базу данных etcd во второй раз, чтобы удалить информацию Pod;
2. Обнаружив, что ресурсы в Pod полностью освобождены, kubelet запускает второе событие удаления, и Pod принудительно удаляется;
3. Операция DELETE kubelet фактически прослушивает событие обновления Pod.После удаления Pod выполняется операция REMOVE;
4. Поток обработки:客户端请求删除Pod-->apiserver更新Pod信息-->kubelet优雅释放Pod资源-->kubelet请求删除Pod-->apiserver删除etcd中Pod信息-->kubelet完成最终Pod的资源清理.