Оригинальная ссылка:Объяснение выселения пода Kubernetes
В Kubernetes наиболее важными ресурсами, используемыми подами, являются ЦП, память и дисковый ввод-вывод.Эти ресурсы можно разделить на сжимаемые ресурсы (ЦП) и несжимаемые ресурсы (память, дисковый ввод-вывод). Сжимаемые ресурсы вряд ли приведут к вытеснению пода, поскольку система может ограничить использование ЦП пода путем перераспределения весов, когда загрузка ЦП пода высока. Для несжимаемых ресурсов, если ресурсов недостаточно, невозможно продолжить заявку на ресурсы (память исчерпана), в это время Kubernetes выгонит из ноды определенное количество подов, чтобы убедиться, что на узле достаточно ресурсов. узел. .
Когда несжимаемых ресурсов недостаточно, Kuberneteskubeletдля выселения стручков. Кублет не удаляется случайным образом, у него есть свой набор механизмов выселения, и обход будет проходить кублет каждого вычислительного узла.cAdvisorИндикаторы для мониторинга использования ресурсов узла, давайте подробно разберем каждую ситуацию.
1. Недостаточно ресурсов хранения
Ниже приведены триггеры вытеснения по умолчанию для хранилища узлов с помощью kubelet:
- nodefs.available
- imagefs.available
когдаimagefsКогда использование достигает порога, kubelet попытается удалить неиспользуемые образы, чтобы освободить место на диске.
когдаnodefsКогда сумма достигнет порогового значения, kubelet откажется запускаться на новом узле Pod, а зарегистрированный API-сервер DiskPressurecondition. Затем kubelet попытается удалить смерть POD и контейнеров, чтобы восстановить место на диске, если на этот разnodefsИспользование по-прежнему не опускается ниже порога, и kubelet начинает выселять pod’ы. Начиная с Kubernetes 1.9, kubelet не обращается к QoS пода, когда он вытесняет под, а только ранжирует под в соответствии с использованием nodefs пода и выбирает под с наибольшим использованием для выселения. Таким образом, даже если уровень QoSGuaranteedPod также могут быть исключены на этом этапе (например, nodefs с наибольшим использованием). Если выселение будетDaemonset, kubelet предотвратит перезапуск пода до тех пор, пока использование nodefs не превысит пороговое значение.
Если в поде несколько контейнеров, kubelet будет ранжироваться на основе суммы использования nodefs всех контейнеров в поде. то есть все контейнеры
container_fs_usage_bytesСумма значений индикатора.
Для каштана предполагается работающий на вычислительном узле класс QoS и ряд известных сумм с использованием nodefs Pod:
| Pod Name | Pod QoS | nodefs usage |
|---|---|---|
| A | Best Effort | 800M |
| B | Guaranteed | 1.3G |
| C | Burstable | 1.2G |
| D | Burstable | 700M |
| E | Best Effort | 500M |
| F | Guaranteed | 1G |
Когда использование nodefs превышает пороговое значение, kubelet ранжирует поды на основе их использования nodefs и сначала удаляет наиболее используемые поды. Рейтинги представлены ниже:
| Pod Name | Pod QoS | nodefs usage |
|---|---|---|
| B | Guaranteed | 1.3G |
| C | Burstable | 1.2G |
| F | Guaranteed | 1G |
| A | Best Effort | 800M |
| D | Burstable | 700M |
| E | Best Effort | 500M |
Вы можете видеть, что в этом примере уровень QoS равенGuaranteedПоды выселяются в первую очередь.
2. Недостаточно ресурсов памяти
Ниже приведены условия триггера вытеснения по умолчанию для kubelet для ресурсов памяти узла:
- memory.available<100Mi
Когда использование памяти превысит пороговое значение, kubelet зарегистрирует условие MemoryPressure на сервере API, в это время kubelet не примет новый уровень QoSBest EffortПоды работают на этом узле, и поды удаляются в следующем порядке:
- Превышено ли использование памяти Pod
requestуказанное значение - При сортировке по приоритету поды с более низким приоритетом удаляются первыми.
- Сравните их использование памяти с
requestРазница между указанными значениями.
В этом порядке можно гарантировать, что уровень QoS будетGuaranteedмодулей не будет иметь класс QoSBest EffortPOD был выселен раньше, но нет никакой гарантии, что это не будетBurstableПоды были выселены раньше.
Если в поде несколько контейнеров, kubelet ранжирует сумму использования памяти всеми контейнерами в поде относительно запроса. то есть все контейнеры (
container_memory_usage_bytesзначение индекса иcontainer_resource_requests_memory_bytesразница значений индикаторов).
Продолжая пример, предположим, что вычислительный узел запускает серию модулей с известными уровнями QoS и использованием памяти:
| Pod Name | Pod QoS | Memory requested | Memory limits | Memory usage |
|---|---|---|---|---|
| A | Best Effort | 0 | 0 | 700M |
| B | Guaranteed | 2Gi | 2Gi | 1.9G |
| C | Burstable | 1Gi | 2Gi | 1.8G |
| D | Burstable | 1Gi | 2Gi | 800M |
| E | Best Effort | 0 | 0 | 300M |
| F | Guaranteed | 2Gi | 2Gi | 1G |
Когда использование памяти узла превышает пороговое значение, kubeletrequestиспользование памяти для ранжирования подов. Рейтинги следующие:
| Pod Name | Pod QoS | Memory requested | Memory limits | Memory usage | Относительное использование памяти |
|---|---|---|---|---|---|
| C | Burstable | 1Gi | 2Gi | 1.8G | 800M |
| A | Best Effort | 0 | 0 | 700M | 700M |
| E | Best Effort | 0 | 0 | 300M | 300M |
| B | Guaranteed | 2Gi | 2Gi | 1.9G | -100M |
| D | Burstable | 1Gi | 2Gi | 800M | -200M |
| F | Guaranteed | 2Gi | 2Gi | 1G | -1G |
Вы можете видеть, что в этом примере вы можете видеть, что в этом примере уровень QoSGuaranteedмодулей на уровне QoSBurstableПоды были выселены раньше.
Когда ресурсов памяти недостаточно, Kubelet будет учитывать только использование памяти Requests и Pod при удалении POD, а лимиты учитываться не будут.
3. Node OOM (Out Of Memory)
Потому что каждый кублет по умолчанию10Данные мониторинга cAdvisor собираются каждую секунду, поэтому может возникнуть всплеск использования памяти, прежде чем kubelet вытеснит Pod, чтобы освободить память, что может вызвать убийцу OOM ядра. В это время право на удаление контейнера передается от kubelet к OOM killer ядра, но некую решающую роль по-прежнему будет играть kubelet, который будет устанавливать свой QoS в соответствии с QoS пода.oom_score_adjценность:
| QoS | oom_score_adj |
|---|---|
| Guaranteed | -998 |
| Burstable | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) |
| pod-infra-container | -998 |
| kubelet, docker daemon, systemd service | -999 |
Если узел инициирует событие OOM до того, как kubelet освободит память, вытеснив Pod, убийца OOM примет меры для снижения нагрузки на систему, которая рассчитывается по следующей формуле.oom_scoreЗначение:
Память, используемая контейнером, в процентах от системной памяти + oom_score_adj = oom_score
Убийца ООМ убьетoom_score_adjСтоимость контейнеров, если контейнеров несколькоoom_score_adjТо же значение уничтожит контейнер с наибольшим использованием памяти (фактически потому, что контейнер с наибольшим использованием памяти имеет самое высокое значение oom_score). Для получения дополнительной информации об OOM см.:Ограничение ресурсов памяти Kubernetes на практике.
Предположим, что на узле работает 4 модуля, и каждый модуль имеет только один контейнер. Каждый тип QoSBurstableЗапросы памяти для конфигурации Pod:4Gi, объем памяти узла30Gi. за пакетoom_score_adjЗначения следующие:
| Pod Name | Pod QoS | oom_score_adj |
|---|---|---|
| A | Best Effort | 1000 |
| B | Guaranteed | -998 |
| C | Burstable | 867 (рассчитано по приведенной выше формуле) |
| D | Best Effort | 1000 |
Когда вызывается убийца OOM, он сначала выбираетoom_score_adjКонтейнер с наибольшим значением (1000), вот два контейнераoom_score_adjВсе значения равны 1000, и убийца OOM в конечном итоге выберет контейнер с наибольшим использованием памяти.
4. Резюме
- Поскольку kubelet извлекает данные мониторинга cAdvisor по умолчанию каждые 10 секунд, возможно, что kubelet по-прежнему вытесняет модули, когда использование ресурсов падает ниже порогового значения.
- После того как kubelet вытесняет Pod из узла, Kubernetes переназначает Pod на другой узел с достаточными ресурсами. Но иногда Планировщик переназначает Pod на тот же узел, что и раньше, например, если установлено сходство узлов или Pod работает как Daemonset.
Теперь вы должны понимать принцип и процесс выселения подов kubelet, если вы зададите соответствующие параметры при развертывании вашего приложения и будете знать все возможности, вы сможете лучше контролировать свой кластер.