Когда вы создаете Azure Kubernetes Service кластер (AKS), вы можете указать сервис Log Analytics для логирования и мониторинга ресурсов внутри кластера: подов, сервисов и т.д. Эта штука устанавливает агент Log Analytics (там будет несколько подов и сопуствующие ресурсы типа config maps), которые потом будут отправлять вывод stdout и stderr в Log Analytics.

К сожалению, схема этих логов достаточно сложная, из-за того, что лог связан с контейнером, а не с подом, и очень тяжело понять, к какому поду относится лог.

Я использую 'boky/postfix' образ для отправки электронной почты со своего Kubernetes-кластера. Недавно система сканирования сообщила о наличии уязвимости в пакете 'py3-setuptools', которую можно закрыть, обновив пакет до последней версии.

Как обычно, я иду в свой кастомный Dockerfile и обновляю свою строку для принудительного обновления пакета...

Работая с большим количеством разных приложений в контейнерах, особенно если не сам их билдишь, не всегда в курсе, что именно за базовая операционная система используется.

Ниже вот команды, как можно это быстренько посмотреть из консоли (будет работать почти для всех дистрибутивов, на самом деле):

Если ваш Kubernetes кластер Azure AKS уже достаточно старый, особенно в DEV-окружениях, он обязательно когда-нибудь начнет заполнять дисковое пространство, приближаясь к критическим цифрам. Дело в том, что AKS хранит образы контейнеров на диске.

Я не смог найти, как часто AKS запускает какой-то свой процесс очистки (но он это делает, конечно же). Однако, в моем случае, в какой-то момент времени, потребление диска достигло 80% и не хотело останавливаться. Ниже описываю, как можно запустить процесс очистки вручную.

Z - это Zabbix

Мониторинг - это очень большая часть процесса экспуатации ПО и инфраструктуры, а также, в моем случае, DevOps процесса - сборки, доставки и эксплуатации. Это один из тех трех слонов, на которых основана эксплуатация, я бы сказал.

Возвращаясь на землю, Azure Cloud - классная платформа, с кучей фишек и возможностей (и ограничений :-)), но тем не менее, у нее нет "настоящего" решения для мониторинга. Ни для виртуальных машин, ни для других ресурсов. Можно возразить - есть OMS и Azure Monitor, но я сталкивался с кучей проблем и ограничений в попытках настроить их, что решил, что самое лучшее - разработать велосипед свое собственное решение, которое будет отвечать моим запросам.

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

Когда вы строите свою инфраструктуру в облаке Azure, используя IaaC (Infrastructure as a Code) подход, иногда вам придется некоторые ваши виртуалки переразворачивать. От этого никуда не денешься, учитывая, в общем-то, специфику облака: что-то не работает? - передеплой. И вот иногда бывает так, что сталкиваешься с проблей переразвертывания, когда парни из Microsoft обновляют образы для виртуалок новыми версиями систем. Например - SQL server 2014 уже не поставляется с SP1. В итоге вам надо как-то быстро найти список новых ID для образов, чтобы обновить свои ARM или Powershell-скрипты.

Я написал небольшой скрипт, который поможет в этом.