Есть несколько способов решить эту проблему, в зависимости от типа ваших рабочих нагрузок.
Самый простой - просто масштабировать ваши узлы, но это может оказаться бесполезным при утечке памяти. Даже если сейчас это не влияет на вас, вы всегда должны учитывать возможность утечки памяти, поэтому рекомендуется всегда вводить ограничения памяти для POD и пространств имен.
Масштабируйте кластер
если у вас работает много модулей, и некоторые из них не намного больше других, было бы полезно масштабировать кластер по горизонтали, таким образом количество работающих модулей на узлы уменьшится, и предупреждение NodeUnderMemoryPressure должно исчезнуть.
если вы используете несколько POD или некоторые из них способны самостоятельно причинить вред кластеру, то единственный вариант - масштабировать узлы по вертикали, добавляя новый пул узлов с экземплярами Compute Engine, имеющими больше памяти, и, возможно, удалить старый.
если ваша рабочая нагрузка правильная и у вас страдает память, потому что в определенный момент дня вы получаете в 100 раз больше обычного трафика и вы создаете больше модулей для поддержки этого трафика, вам следует подумать об использовании Autoscaler.
Проверить утечки памяти
С другой стороны, если это не «здоровая» ситуация, и у вас есть модули, потребляющие намного больше ОЗУ, чем ожидалось, вам следует последовать совету grizzthedj и понять, почему ваши POD потребляют так много, и, возможно, проверить, затронуты ли некоторые из ваших контейнеров. утечкой памяти и в этом случае масштабировать объем оперативной памяти бесполезен, так как в какой-то момент она все равно закончится.
Поэтому начните понимать, какие POD потребляют слишком много, а затем выясните, почему у них такое поведение, если вы не хотите использовать Prometeus просто войдите в контейнер по SSH и проверьте с помощью классических команд Linux.
Ограничьте объем оперативной памяти, потребляемой POD
Чтобы этого не произошло в будущем, я советую вам при написании файла YAML всегда ограничить объем оперативной памяти, которую они могут использовать, таким образом вы будете контролировать их, и вы будете уверены, что нет риска, который они вызывают "агент узла" Kubernetes откажет из-за нехватки памяти.
Также подумайте об ограничении ЦП и введении минимальных требований к ОЗУ и ЦП для POD, чтобы помочь планировщику правильно планировать POD, чтобы избежать NodeUnderMemoryPressure при высокой рабочей нагрузке.
person
GalloCedrone
schedule
17.01.2018
