Containerization
Containerization
Контейнеризация
Общая информация
Сравнение контейнеров и виртуальных машин | Atlassian
О микросервисной архитектуре простыми словами
Kubernetes и другие оркестраторы / Хабр
Container vs Virtual machine
Контейнеры и виртуальные машины — очень похожие между собой технологии виртуализации ресурсов. Виртуализация — это процесс, при котором один системный ресурс, такой как оперативная память, ЦП, диск или сеть, может быть виртуализирован и представлен в виде множества ресурсов. (т.е. может быть изолирован внутри нужной нам среды) . Основное различие контейнеров и виртуальных машин заключается в том, что концептуально Виртуальная машина требует установку операционной системы и подготовку среды,т.к в отличии от контейнера это не требуется, достаточно гостевой ОС
Container
Контейнеры — это легкие программные пакеты, содержащие все зависимости, необходимые для запуска автономного программного приложения. К этим зависимостям относятся системные библиотеки, сторонние пакеты кода и другие приложения уровня операционной системы. Зависимости, входящие в контейнер, находятся на уровнях стека выше уровня операционной системы.
Плюсы:
Скорость итерации
Поскольку контейнеры не требуют много ресурсов и включают в себя только программное обеспечение верхнего уровня, их можно быстро модифицировать и итеративно менять.
Надежная экосистема
В большинстве систем контейнерных сред выполнения существует общедоступный размещенный репозиторий готовых контейнеров. Такие репозитории контейнеров содержат множество популярных программных приложений, таких как базы данных или системы обмена сообщениями, которые можно мгновенно загрузить и выполнить, чтобы сэкономить время команды разработчиков.
Минусы:
Уязвимость общего узла
Поскольку все контейнеры используют одну и ту же опорную аппаратную систему, находящуюся ниже уровня операционной системы, эксплойт в одном контейнере может вырваться на свободу и повлиять на общие аппаратные ресурсы. Большинство популярных контейнерных сред выполнения предлагают публичные репозитории готовых контейнеров. Использование таких публичных образов сопряжено с угрозой безопасности, поскольку они могут содержать эксплойты или уязвимости, которыми могут воспользоваться злоумышленники.
Проблема масштабировании
При масштабировании микро сервисной архитектуры встает вопрос правильного построения процессов DevOps оптимизации, что требует дополнительных вложений, а также сложности самого масштабирования из-за количества контейнеров, что является основополагающей концепцией микро сервисной архитектуры
Virtual Machine
Виртуальные машины — это тяжелые программные пакеты, которые обеспечивают полную эмуляцию низкоуровневых аппаратных устройств, таких как ЦП, дисковые и сетевые устройства. Виртуальная машина также может включать дополнительный программный стек для запуска на эмулируемых аппаратных средствах. Такой пакеты аппаратных и программных средств представляет собой полнофункциональный снимок вычислительной системы.
Существует множество способов Виртуализации, от разных компаний и сред, где применяются виртуальные машины в коммерческих проектах или с открытым исходным кодом. За запуск Виртуальной машины отвечает программная среда, ее можно установить на сервер для использование аппаратных ресурсов и запуска виртуальных машин. Такой программный комплекс называется Гипервизор.
Также существуют и способы запуска виртуальных машин внутри частных операционных систем таких, как Windows или Linux, в этом случае программная среда является обычным приложением
Принцип работы гипервизора похож на запуск операционной системы:
Инициализация гипервизора
После запуска сервера, программная среда полностью берет под контроль все ресурсы CPU, RAM, Сеть, Диски и даже GPU.
Эмуляция оборудования
Гипервизор создает виртуальную, полностью копирующую принцип работы, версию оборудования и архитектуры для процессора(vCPU), Виртуальной памяти, Виртуальных дисков сети
Запуск Виртуальной Машины
В первую очередь создается образ виртуальной машины, это некий файл, со своим форматом (Часто для каждого Гипервизора имеется свой проприетарный формат), который будет хранить всю информацию нашей воссозданной, эмулированной среды, это файлы, разделы, надстройки загрузчика, конфигурации итд.
Далее после указания какую среду мы хотим воссоздать, Гипервизора запускает Виртуальную машину выделив набор инструкция и количество ядер для CPU ,RAM и обязательно создав виртуальный сетевой адаптер.
Управление
Посредством API или других GUI интерфейсов, Гипервизор предоставляет возможность управлять и устанавливать внутри виртуальной машины нужную нам операционную систему
*Принцип работы Виртуальной машины — это полностью изолированная среда, где гипервизора никаким образом не понимает, что происходит внутри Виртуальной машины, он может управлять и производить мониторинг только лишь ресурсами системы
Плюсы
Полная защита путем изоляции
Виртуальные машины работают изолированно как полностью автономные системы. Это означает, что они защищены от любых эксплойтов или помех со стороны других виртуальных машин на общем узле. Если отдельная виртуальная машина пострадает от эксплойта, она будет изолирована и не сможет повредить соседние виртуальные машины.
Интерактивная разработка
Контейнеры обычно представляют собой статические определения ожидаемой конфигурации и зависимостей, необходимых для запуска контейнера. Виртуальные машины более динамичны и могут дорабатываться в интерактивном режиме. После указания базовых аппаратных характеристик виртуальную машину можно рассматривать как компьютер без операционной среды. Можно вручную установить программное обеспечение на виртуальную машину и сделать снимок состояния для фиксации текущей конфигурации. Снимки виртуальной машины можно использовать для ее восстановления до конкретного момента времени или для запуска дополнительных виртуальных машин с такой конфигурацией.
Минусы
Скорость итерации
Создание и воспроизведение виртуальных машин занимает много времени, поскольку они охватывают полный системный стек. Любые изменения снимка состояния виртуальной машины могут потребовать значительного времени на воспроизведение и проверку работоспособности.
Стоимость занимаемого хранилища
Виртуальные машины могут занимать много места в хранилище, быстро вырастая до нескольких гигабайтов в объеме. Это может привести к нехватке дискового пространства на компьютере, где размещаются виртуальные машины.
Микросервисы
То, как организован код, называется архитектурой программного обеспечения — она бывает монолитной или микросервисной. Выбор архитектуры зависит от проекта: в больших проектах разработчики, как правило, выбирают микросервисы
Микросервисная архитектура ― это подход к разработке программного обеспечения, при котором систему разделяют на небольшие независимые сервисы. Каждый выполняет определенную функцию и взаимодействует с другими сервисами через API.
Монолитная архитектура ― традиционный подход к разработке программного обеспечения. Приложение представляет собой модуль, в котором объединены все компоненты. Управление интерфейсом, бизнес-логикой и базой данных осуществляется в одном месте.
Монолитная архитектура кажется более простой и понятной. Но, когда продукт разрастается, поддерживать такую архитектуру становится сложно.
Микросервис ― это небольшой автономный компонент системы. Его можно разработать и развернуть независимо от других компонентов. Каждый модуль отвечает за конкретную функцию (или очень ограниченный их набор). Система может быть распределенной. Это значит, что микросервисы могут работать на разных серверах и связываться друг с другом.
API ― это набор правил и команд, который позволяет разным программам взаимодействовать друг с другом.
В микросервисной архитектуре API — набор универсальных «ручек» - url’ов, доступ к которым можно предоставить каждому. Если надо, чтобы один из микросервисов что-то сделал, то можно просто «дернуть ручку» и получить ответ. При этом не надо знать, как сервис будет выполнять задачу. Стоит отметить, что микросервисы могут общаться между собой не только с помощью API, также они могут обмениваться информацией через брокеры/менеджеры очередей (Kafka, IBM MQ, RabbitMQ), SOAP, RPC-методы (GRPC).
Пример HTTP - Api
API-шлюзы (API Gateways)
Представим, что вы хотите попасть в здание, но, чтобы войти, нужно пройти через охранника. Он проверяет вашу личность, разрешает войти и подсказывает, как сориентироваться внутри здания. В мире компьютерных программ эти функции выполняют API-шлюзы (API Gateways). Они — проводники между разными частями сервиса. Когда одна часть программы хочет отправить запрос другой, она делает это через шлюз.
API Gateway проверяет, имеет ли программа право делать то, что она запрашивает. Это как проверка вашего паспорта охранником. Если всё в порядке, он направит программу туда, куда нужно, ― как охранник, направляющий вас в нужное место.
Шлюз может сохранять некоторые ответы, чтобы не запрашивать их каждый раз заново. Это как если бы охранник помнил, что вы уже были тут раньше и сразу вас пропускал.
Так же шлюз в контурах больших компаний выполняет роль прослойки между внешним интернетом и внутренними “чувствительными” системами банка, или может находиться между разными сетевыми сегментами компании.
Иногда шлюзы создают для перевода из сетевого взаимодействия в другое, например из Kafka в HTTP, из HTTP в Kafka (чаще всего в обе стороны). В подавляющем большинстве случаев совмещается с другими функциями шлюзов.
Так что API Gateway ― это такой контрольно-пропускной пункт для взаимодействия разных частей программы между собой. Он проверяет уровни доступа и направляет запрос в нужную сторону.
Базы данных
База данных ― это виртуальное хранилище информации. Вместо того чтобы держать данные в отдельных файлах или таблицах, их помещают в единую базу. Так намного быстрее и удобнее искать информацию.
Чаще всего база данных выглядит как набор таблиц, где каждая представляет определённый тип данных, например информацию о пользователях приложения. Каждая строка таблицы представляет отдельную запись, а столбцы определяют различные атрибуты, например пол и возраст. С помощью специальных запросов можно извлекать, обновлять, добавлять или удалять данные из таблиц.
Ещё встречаются нереляционные базы данных — их называют NoSQL (то есть не связанные с языком SQL). В них представление информации не привязано к табличному виду.
Микросервисы используют базы данных для хранения информации. При этом у каждого сервиса она может быть своя. Например, в интернет-магазине один микросервис отвечает за то, чтобы заносить данные новых пользователей в базу, а другой ― подгружает данные о товарах из своей базы по мере обновления страницы.
Мониторинг
Системы мониторинга анализируют состояние каждого микросервиса для поддержания работоспособности всего приложения. Каждый микросервис записывает логи — файлы, которые содержат информацию о его работе. Это могут быть сообщения о событиях, ошибках, запросах и других важных моментах.
С помощью этого можно автоматически собирать метрики для оценки производительности микросервисов. Все полученные данные сохраняются, чтобы потом можно было проанализировать аномалии и тренды.
Конфигурация
Конфигурация в микросервисах — централизованный способ изменения параметров, которые влияют на работу всей системы. Поскольку микросервисы разрабатывают независимо друг от друга, важно иметь возможность менять конфигурацию не только отдельных сервисов, но и сразу всех компонентов без перезапуска.
Контейнеризация
Для развертывания и масштабирования микросервисов использую контейнеры и системы оркестрации. Чаще всего разработчики выбирают для этого популярные Docker и Kubernetes.
С помощью контейнеров можно упаковать микросервисы со всем необходимым для переноса на сервер. Если надо будет переехать, то разработчикам не придётся собирать всё снова. Это и делает микросервисы переносимыми. Ещё контейнеры отвечают за изоляцию, предотвращая влияние сервисов друг на друга.
Микросервисы vs Монолит
Монолитная
Преимущества
Простота разработки. Все компоненты приложения находятся в одном месте, что делает процесс разработки простым и прозрачным.
Простота развертывания. Развёртывание монолитного приложения проще, так как для этого не требуется управления большим количеством микросервисов.
Меньшие затраты на инфраструктуру. Монолиты часто требуют меньше инфраструктуры для развертывания и поддержки, что помогает сократить затраты на разработку.
Уменьшенная зависимость от сети. Поскольку все части приложения работают в пределах одного процесса, нет необходимости в постоянном взаимодействии по сети.
Недостатки
Сложность масштабирования. Монолиты могут столкнуться с трудностями в масштабировании, особенно если определенные части приложения требуют больше ресурсов.
Взаимозависимость компонентов. Если одна часть монолита требует изменений, это может повлиять на всю систему, что затрудняет внесение изменений.
Сложность поддержки. Большие проекты тяжело поддерживать и понимать, как работают все их компоненты.
Ограниченная гибкость. Изменения в одной части монолита могут затронуть другие, что может сделать систему менее гибкой и податливой к изменениям.
Ограниченность стека. Монолиты обычно используют единый стек технологий, что ограничивает возможности использования различных технологий для разных компонентов.
Микросервисная
Преимущества
Гибкость. Микросервисы позволяют разрабатывать, изменять и масштабировать отдельные части приложения независимо от других. Это делает систему более гибкой.
Масштабируемость. Каждый микросервис можно масштабировать отдельно от всей системы. Сложность проекта растет вместе с увеличением нагрузки.
Изоляция ошибок. Проблемы в одном микросервисе редко влияют на остальные, а значит, искать и устранять ошибки становится проще.
Свобода стека. Для каждого микросервиса можно выбрать свой стек технологий и язык программирования. Это дает больше свободы разработчикам.
Недостатки
Сложность управления. Чем больше микросервисов в проекте, тем сложнее ими управлять. Для этого нужны дополнительные инструменты и специалисты.
Зависимость от сети. Микросервисы общаются друг с другом по сети, это может вызывать задержки и проблемы с производительностью.
Затраты на развертывание и инфраструктуру. Развёртывание и поддержка инфраструктуры для микросервисов обходится дороже.
Docker (На будущее)
Контейнеры — это не новая технология, а старая теоретическая концепция. Ещё несколько десятков лет назад в Unix-системах существовала команда chroot, обеспечивающая простейшую форму изоляции части файловой системы. Позднее появились более мощные инструменты, такие как LXC (Linux Containers) — технология на уровне ядра Linux, обеспечивающая контейнеризацию через контроль ресурсов (cgroups) и пространства имён (namespaces). Однако в 2013 году появилась Docker, который занял своё место как одно из главных направлений развития ИТ-индустрии. Он быстро стал стандартом де-факто в DevOps и CI/CD, благодаря своей концептуальной простоте, удобству и надёжности в использовании.
Docker (Docker daemon), ответственный за создание, запуск и контроль работы контейнеров, а также за создание и хранение образов. Контейнеры и образы представлены в правой части диаграммы.
Демон Docker запускается командой docker daemon, обычно об этом заботится операционная система хоста;
Клиент Docker, используется для диалога с демоном Docker по протоколу HTTP. По умолчанию это соединение устанавливается через сокет домена Unix,
Реестры Docker используются для хранения и распространения образов. Реестром, выбираемым по умолчанию, является Docker Hub.
Docker-контейнер предназначен для запуска только одного основного (родительского) процесса. Это значит:
Контейнер "живет" только до тех пор, пока работает главный процесс, запущенный внутри него
Основы работы с Docker
В рамках нашей с вами работы нам не нужно углубляться в работу архитектуры Docker, стоит лишь запомнить, что движок Docker (Docker engine) состоит из трех основных компонентов:
Docker Daemon(dockerd) – фоновый процесс, который управляет контейнерами
Docker cli – Командная строка, для управления docker
REST API - Интерфейс, через который клиенты (например, CLI или сторонние приложения) взаимодействуют с демоном.
Docker не предполагает предустановленную версию в популярных операционных системах типа Debian или centOS, есть специальные операционные системы, которые предполагают установку Docker при уже установки самой системы, часто модифицированной версии, обычно такие ОС используются внутри разработки для более легкого и быстрого развертывания приложения, часто это касается DevOps инженеров и выбранного им способа и реализации концепции ci/cd.Например RancherOS, BalenaOS итд.
Основные команды docker cli
По умолчанию docker cli работает только от прав суперпользователя.
Мы разберем 4 основные части работы в Docker cli:
Запуск контейнеров
Просмотр контейнеров
Просмотр логов
Просмотр образов
Для запуска команд из окна терминала используйте следующий синтаксис
docker [OBJECT] [COMMAND] [OPTIONS] [ARGS...]
Запуск контейнеров
Docker run hello-world
Для настройки среды и запуска контейнера и настройки его используются дополнительные аргументы, рассмотрим основные из них:
-it интерактивный режим
-d запуск контейнера в фоновом режиме
- p проброс портов docker run nginx
:
docker run -d -p 8080:80 nginx
--name назначение имени контейнеру
docker exec — она используется для передачи и выполнения команд в уже работающем контейнере.
Просмотр контейнеров
docker ps – показывает состояние только работающих контейнеров со статусом up
docker ps -all показывает все контейнеры со статусом Остановлен(exited) завершенные (Created,dead) и запущен(UP)
Поля:
container id – сгенерированный при запуске уникальный айди контейнера предназначенный для идентификации контейнера в системе
image образ контейнера и названия реестра откуда взят контейнер
command – команда,последняя,которая выполняет 1 команду для запуска контейнера
created – время создания контейнера
port – проброшенные порты из оверлея docker к системе хоста
names – имя контейнера,оно может быть указано при сборке образа или запуске контейнера,а также при не указании его оно генерируется автоматически
Просмотр логов
Для просмотра лока контейнеров используется команда docker logs (имя или id контейнера)
Чтобы вывести логи в реальном времени добавляется флаг -f
Просмотр образов
docker image ls или docker image – позволяет просматривать состояния всех контейнеров на данном хосте
REPOSITORY — название образа и реестр, откуда он взят;
TAG — версия или метка образа;
IMAGE ID — уникальный идентификатор образа;
CREATED — время создания образа;
SIZE — размер образа.
Kubernetes (На редактуре)
Основы Kubernetes / Хабр
K8S для начинающих. Первая часть
Проверки работоспособности в Kubernetes
Обзор Lens — IDE для Kubernetes / Хабр
В данном разделе будет основная теория для понимания что такое Kubernetes и как с ним взаимодействовать как инженер НТ. Здесь не будет подробной информации по установке и настройке кластеров Kuber с 0, и сборки собственного контейнера - это работа DevOps и разработчиков.
Мы рассмотрим:
Основные понятия
Консольные команды
Для перезапуска
Для просмотра состояния
Пробы
Ресурсы
Изменение конфигов
Анализ производительности и ошибки
Дополнительно, на что стоит обращать внимание при работе с Kubernetes
Основные понятия
Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.
Проект преследует две цели. Если вы пользуетесь контейнерами Docker, возникает следующий вопрос о том, как масштабировать и запускать контейнеры сразу на большом количестве хостов Docker, а также как выполнять их балансировку. В проекте предлагается высокоуровневый API, определяющее логическое группирование контейнеров, позволяющее определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение.
Составляющие
Nodes (node.md): Нода это машина/сервер в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod'ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединенный набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label'ы это пары ключ/значение которые прикрепляются к объектам, например pod'ам. Label'ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.
Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределенным хранилищем. Приведенная схема показывает желаемое, в конечном итоге, состояние, хотя всё ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.
Нода Kubernetes
При взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. Конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров.
Kubelet
Kubelet управляет pod'ами их контейнерами, образами, разделами, etc.
Kube-Proxy
Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.
Компоненты управления Kubernetes
Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.
etcd
Состояние мастера хранится в экземпляре etcd. Это обеспечивает надежное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.
Kubernetes API Server
Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).
Scheduler
Scheduler привязывает не запущенные pod'ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler'ов и пользовательских scheduler'ов.
Kubernetes Controller Manager Server
Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller.
Виды контроллеров:
Deployments - контроллер, который управляет состоянием развертывания подов, которое описывается в манифесте, следит за удалением и созданием экземпляров подов. Управляет контроллерами ReplicaSet.
ReplicaSet - гарантирует, что определенное количество экземпляров подов всегда будет запущено в кластере.
StatefulSets - так же как и Deployments, управляет развертыванием и масштабированием набора подов, но сохраняет набор идентификаторов и состояние для каждого пода.
DaemonSet - гарантирует, что на каждом узле кластера будет присутствовать экземпляр пода.
Jobs - создает определенное количество подов и смотрит, пока они успешно не завершат работу. Если под завершился с ошибкой, повторяет создание, которое мы описали определенное количество раз. Если под успешно отработал, записывает это в свой журнал.
CronJob - запускает контроллеры Jobs по определенному расписанию.
ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.
Namespace или пространство имен — это абстрактный объект, который логически разграничивает и изолирует ресурсы между подами. Вы можете рассматривать пространство имен как внутренний виртуальный кластер, который поможет вам изолировать проекты или пользователей между собой, применить разные политики квот на свои проекты или выдать права доступа только на определенную область.
Kubectl (консольные команды) + теория
Синтаксис
Для запуска команд из окна терминала используйте следующий синтаксис :
kubectl [command] [TYPE] [NAME] [flags]
где command, TYPE, NAME, и flags являются:
command: Указывает операцию, которую вы хотите выполнить над одним или несколькими ресурсами, например create, get, describe, delete.
TYPE: Указывает тип ресурса . Типы ресурсов нечувствительны к регистру, и вы можете указать единственное, множественное число или сокращенную форму. Например, следующие команды выдают одинаковый вывод:
kubectl get pod pod1
kubectl get pods pod1
kubectl get po pod1
NAME: Указывает имя ресурса. Имена чувствительны к регистру. Если имя пропущено, отображаются сведения обо всех ресурсах, например kubectl get pods.
При выполнении операции над несколькими ресурсами вы можете указать каждый ресурс по типу и имени или указать один или несколько файлов:
Чтобы указать ресурсы по типу и названию:
Чтобы сгруппировать ресурсы, если они все одного типа: TYPE1 name1 name2 name<#>.
Пример: kubectl get pod example-pod1 example-pod2
Чтобы указать несколько типов ресурсов по отдельности: TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>.
Пример: kubectl get pod/example-pod1 replicationcontroller/example-rc1
Чтобы указать ресурсы с одним или несколькими файлами:-f file1 -f file2 -f file<#>
Используйте YAML вместо JSON , поскольку YAML, как правило, более удобен для пользователя, особенно для файлов конфигурации.
Пример:kubectl get -f ./pod.yaml
flags: Указывает необязательные флаги. Например, вы можете использовать флаги -s или --server для указания адреса и порта сервера API Kubernetes.
Интересующие нас команды:
Важное замечание: ко всем командам, выводящим какую-либо информацию на экран, применим обычный линуксовый grep, например: “kubectl get pods | grep “kafka” - означает вывести на экран список под, которые в имени/описание имеют слово Kafka.
Примеры команд и их вывод:
get
kubectl get nodes - отображает список существующих нод, их статус и роли.
kubectl get pods - отображает список существующих подов, их готовность, статус, кол-во рестартов и время жизни.
kubectl get pods - по сути повторяет вывод предыдущей команды + дополнительная информация о том, на каких нодах развернуты поды, IP и другое нас не интересующее.
Расшифровка:
Nodes
logs
kubectl logs “имя пода”- команда для получения логов с пода, имя пода можно получить с помощью kubectl get pods.
rollout
kubectl rollout restart deployment- перезапуск всех деплойментов. По сути перезапуск всех под в дефолтном namespace.
kubectl rollout restart deployment “имя деплоймента” - перезапуск конкретного деплоймента. По сути перезапуск всех под, у которых имя начинается с указанного деплоймента.
top
kubectl top node - вывод на экран текущей утилизации списка нод.
kubectl top pod - вывод на экран текущей утилизации списка под.
Пробы
Проверка работоспособности kubelet поддерживает три типа проверок работоспособности:
Проба запуска (startup).
Проба работоспособности (liveness).
Проба готовности (readiness).
Проба запуска (startup)
Приложения с инфраструктурой и устаревшие приложения дольше запускаются при первой инициализации. В этом случае мы используем тот же метод проверки (команда, HTTP-запрос или проверка TCP), что и для остальных проб, но увеличиваем порог ожидания в секундах, чтобы приложение успело запуститься.
Проба работоспособности (liveness)
Проба работоспособности проверяет, выполняется контейнер или нет.
Если проба не находит живой контейнер, автоматически выполняется политика перезапуска контейнера.
Проба готовности (readiness)
Проба готовности проверяет, готово ли приложение обслуживать запросы.
Если не готово, IP pod’а удаляется из списка конечных точек сервиса.
Ресурсы
В Kubernetes, ресурсы подов включают в себя требования к CPU и памяти, а также объем дискового пространства, который может быть запрошен для контейнеров, запущенных в подах. Эти ресурсы определяют, сколько вычислительных ресурсов может использовать контейнер в подах, что помогает Kubernetes планировать поды на узлах кластера и эффективно использовать ресурсы.
Подробности:
Требования к CPU (requests) и ограничения (limits): Поды и контейнеры могут указывать требования к CPU (requests) – минимальное количество CPU, которое они ожидают получить при старте, и ограничения (limits) – максимальное количество CPU, которое они могут использовать. Эти требования помогают Kubernetes планировать поды на узлах, где есть достаточно ресурсов, чтобы удовлетворить запросы, и ограничивают использование CPU для избежания перегрузки.
Требования к памяти (requests) и ограничения (limits): Аналогично CPU, поды и контейнеры могут задавать требования к памяти (requests) и ограничения (limits). Эти требования помогают Kubernetes планировать поды на узлах с достаточным объемом памяти, и ограничения позволяют избежать переупотребления памяти одним подом.
Объем дискового пространства: Поды могут использовать persistent volume claims (PVC), чтобы получить доступ к постоянному хранилищу (persistent storage) в кластере. Это позволяет подам сохранять данные и не терять их при перезапуске контейнеров.
Другие ресурсы: Кроме CPU и памяти, Kubernetes также управляет другими ресурсами, такими как сетевые ресурсы и ресурсы GPU (если они доступны на узлах).
Пример использования:
В спецификации Pod можно определить требования и ограничения для CPU и памяти следующим образом:
Важное:
requests не должен превышать limits
сумма requests не должна превышать сумму ресурсов кластера
сумма limits может превышать сумму ресурсов кластера, но в случае повышения нагрузки на кластер - штатная работа системы не гарантирована
при превышении limits под перезагружается, т.к. не проходит liveness проба
CPU измеряется в mc - милликорах или с - корах, они же millicore и core они же виртуальные ядра системы. Это количественная мера процессора - по сути означает сколько процессорного времени/тактов. Т.е. если два приложения занимают по 500 mc, то оба будут забирать половину процессорного времени друг за другом.
Память измеряется в MiB (мебибайт) и GiB (гибибайт).
Привычный 1 GB = 1000 MB, а GiB = 1024 MiB.
Изменение конфигов
Для начала изменения конфигов необходимо найти файл вида “name”.yml или “name”.yaml - аналог docker.yaml.
Ресурсы
Как указано в примере выше, необходимо найти раздел recources:
Заглушки/внешние интеграции
Найти блок с настройками внешней интеграции - чаще всего соответствует названию интеграции. Сама строка подключения может выглядеть по разному - далее просто меняем на нужную. Теперь можем выполнить rollout нужного пода, чтобы применились необходимые настройки.
JVM
Настройки логирования для отладки
Анализ производительности и ошибок
В первую очередь собираем метрики утилизации нод (как обычных серверов Linux) и утилизации под (с помощью экспортеров через прометей). О метриках подробнее в разделе “мониторинг” - Теория.
Через прометей так же получаем бизнес/прикладные метрики, по тому какие именно метрики необходимо наблюдать и их SLA уточнят аналитики заказчика НТ.
Снятие дампов памяти может происходить множеством разнообразных способов, как именно снимать дампы уточните у разработчика. Подробнее о дампах в разделе “Java” - Теория.
Lens
Т.к. чаще всего у kubernetes отсутствует UI, можно воспользоваться крайне полезной утилитой Kubernetes Lens.
После запуска приложения понадобится добавить kubeconfig (запросить у сопровождения) требуемого Kubernetes-кластера. Согласно информации с официального сайта, Lens поддерживает не только «ванильный» Kubernetes, но и любую платформу: EKS, AKS, GKE, Minikube, Rancher, k0s, k3s, OpenShift и т.д. Параллельно можно добавить несколько конфигурационных файлов и потом переключаться между кластерами через боковое меню приложения.
Интерфейс
Всё рабочее пространство можно разделить на три области:
меню выбора элементов (Cluster, Nodes, Workloads...);
основное рабочее пространство;
терминал/текстовый редактор.
Через Lens можно управлять всеми сущностями кластера, а для удобства ресурсы сгруппированы в меню. Для человека, работавшего с Kubernetes, расположение элементов в этом меню является интуитивно понятным и не требует дополнительных пояснений. Например, в блоке Workloads содержатся разделы для доступа к Pod’ам, Deployment’ам, STS и т.д. При переходе в нужный раздел мы получаем возможность поиска по имени или сортировки элемента по нужному столбцу
При нажатии на конкретный элемент раскрывается дополнительное окно со всей информацией об этом элементе, в том числе: графики потребления, лейблы, пробы, volumes и т.д. При этом связанные дочерние элементы кликабельны, что позволяет, например, быстро переходить из Pod’а в окно с информацией о его томах, секретах или ConfigMap’ах.
При работе с Pod’ами удобно смотреть их логи, по которым можно также искать и которые легко сразу скачать. Однако важный нюанс в том, что сами логи обновляются не в режиме реального времени, а с некоторой задержкой — это может добавить неудобств:
В блоке Events доступны события в кластере — с возможностью их поиска по ключевым словам и фильтрации по пространствам имен. События с типом Warning по умолчанию подсвечиваются красным, что помогает не пропустить что-то важное. Здесь есть очевидная недоработка интерфейса: отсутствует горизонтальный скролл или возможность изменения ширины столбцов. Поэтому для удобства приходилось либо полностью убирать некоторые столбцы, либо регулировать общий масштаб всего интерфейса:
Терминал
Несмотря на то, что Lens предлагает модель управления кластером через веб-интерфейс, среди возможностей этого приложения нашлось место и терминалу — Smart terminal, вкладки которого можно раскрыть в нижней части интерфейса. В терминале предустановлена CLI-утилита kubectl (а также Helm 3), особенностью которой является «синхронизированность» её версии с версией Kubernetes API для выбранного кластера. Такой подход позволяет забыть о необходимости ставить различные версии kubectl при работе с разными K8s-кластерами на одном устройстве:
Несмотря на наличие «smart» в названии этого терминала, автодополнение через
echo 'source <(kubectl completion bash)' >>~/.bashrc
В той же, нижней, части интерфейса Lens можно создать вкладку для простого текстового редактора. Он предназначен для редактирования/применения YAML-манифестов в кластере. В редактор встроена проверка структуры YAML-файла, не позволяющая сохранить изменения, если обнаружены ошибки в отступах.
Размер рабочих окон терминала или текстового редактора можно регулировать — вплоть до полноэкранного режима.
Просмотр ошибок
1.Перейти во вкладку Pods
2.Далее Edit
3. Откроется окно с нужной нам информацией, тут необходимо найти поле ContainerStatuses
4. Видим текущее состояние контейнера
5. Видим причины предыдущего рестарта контейнера (отдаем разработчику + код ошибки можем посмотреть в интернете)