Почему стручки Kubernetes терпят неудачу случайно, когда их пределы перекрываются?

Question

У меня есть одноузловой кластер Kubernetes, который показывает 10Gi, 3 CPU как доступные (всего 16 Gi, 4CPU) для запуска модулей после запуска кластера. Я пробую два разных сценария ios, затем:

Scenario-1. 
   Running 3 pods individually with configs(Request,Limit) as: 
   Pod-A: (1 Gi,3.3Gi) and (1 cpu,1 cpu)
   Pod-B: (1 Gi,3.3Gi) and (1 cpu,1 cpu)
   Pod-C: (1 Gi,3.3Gi) and (1 cpu,1 cpu)

В этом сценарии приложения отлично вставляются в соответствующие модули и работают нормально, как и ожидалось.

Scenario-2. 
   Running 3 pods individually with configs(Request,Limit) as: 
   Pod-A: (1 Gi,10 Gi) and (1 cpu,3 cpu)
   Pod-B: (1 Gi,10 Gi) and (1 cpu,3 cpu)
   Pod-C: (1 Gi,10 Gi) and (1 cpu,3 cpu)

Во втором В этом сценарии приложения вставляются в соответствующие модули, но происходит сбой случайным образом после того, как какая-либо из этих нагрузок оказывается под какой-либо нагрузкой, то есть, когда Pod-A выходит из строя, иногда Pod-2 или Pod-3. В любой момент времени я не могу запустить все три модуля вместе.

Единственное событие, которое я вижу в неисправном модуле, - это как показано ниже

"The warning which is available in node logs says "Warning CheckLimitsForResolvConf 1m (x32 over 15m) kubelet, xxx.net Resolv.conf file '/etc/resolv.conf' contains search line consisting of more than 3 domains! .".

Имея только эту информацию в журналах, я не могу выяснить фактическую причину случайного сбоя модулей.

Может кто-нибудь помочь мне понять, есть ли что-нибудь что-то не так с конфигами или мне чего-то не хватает?

Спасибо

Answer 1

При создании Pod планировщик Kubernetes выбирает узел для запуска Pod. Каждый узел имеет максимальную емкость для каждого из типов ресурсов: объем процессора и памяти, которые он может предоставить для модулей. Планировщик гарантирует, что для каждого типа ресурса сумма запросов ресурсов запланированных Контейнеров меньше, чем емкость узла.

Примечание Хотя фактическое использование памяти или ресурсов ЦП на узлах очень низкое, планировщик по-прежнему отказывается разместить Pod на узле, если проверка емкости не удалась . Это защищает от нехватки ресурсов на узле, когда использование ресурса в дальнейшем увеличивается, например, во время ежедневного пика частоты запросов.

Таким образом, после планирования Если контейнер превышает свой запрос памяти, он вероятно, что его Pod будет удален всякий раз, когда узлу не хватит памяти

См. Стандартные значения порога принудительного изгнания .

Кублет имеет следующий жесткий по умолчанию порог изгнания:

memory.available<100Mi
nodefs.available<10%
nodefs.inodesFree<5%
imagefs.available<15%

Вы должны отслеживать свои условия узла во время загрузки.

kubelet отображает один или несколько сигналов выселения в соответствующее состояние узла.

Если порог жесткого выселения был достигнут или порог мягкого выселения был достигнут независимо от связанного с ним периода отсрочки, кублет сообщает о состоянии, которое отражает, что узел находится под давлением, то есть MemoryPressure или DiskPressure