При виртуализации создаётся полная виртуальная машина (VM), имитирующая физическую машину с собственным набором аппаратных ресурсов (процессор, память, диски и т.д.). Каждая виртуальная машина запускает свою собственную операционную систему поверх гипервизора. Основные отличия виртуализациии:

• Полная изоляция: каждая виртуальная машина изолирована от других и имеет собственную копию ОС
• Большой расход ресурсов: виртуальные машины требуют значительных затрат на хранение образа ОС и выделение аппаратных ресурсов.
• Медленная работа: больше накладных расходов из-за дублирования ресурсов и уровней абстракции.
• Применение: подходит для сред, где важна полная изоляция

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

• Легкость и быстрота: контейнеры загружаются быстрее и занимают меньше места.
• Минимальные затраты ресурсов: меньшие накладные расходы на память и процессор, так как используется общее ядро.
• Быстрая разработка и доставка: упрощают упаковку и доставку приложений, обеспечивая консистентность среды между разработкой и продакшеном.
• Совместимость: контейнеры хорошо подходят для микроархитектуры, CI/CD-процессов и масштабируемых облачных платформ.

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

Основная единица развертывания Kubernetes. Pod представляет собой один или несколько контейнеров, работающих вместе и использующих общие ресурсы.

Это компонент который определяет сетевой доступ к набору Pod’ов. Поскольку Pod’ы в Kubernetes являются временными — они могут создаваться и удаляться при масштабировании или обновлении — обращаться к ним напрямую через IP-адреса неудобно и ненадёжно. Сервис решает эту проблему, создавая устойчивую точку доступа (имя + IP) для взаимодействия с Pod’ами. Он автоматически направляет трафик на актуальные живые Pod’ы, входящие в его группу. Пример-аналогия: Сервис как ресепшн в офисном здании.

• Readiness-проба определяет, готов ли контейнер обслуживать трафик. Пока проба не успешна, Service не направляет трафик на Pod.
• Liveness-проба нужна, чтобы обнаруживать “зависшие” контейнеры. Если приложение перестало отвечать на этот endpoint, Kubernetes перезапустит Pod автоматически.
• Startup-проба применяется, если приложение долго стартует (например, при инициализации данных или загрузке кешей). Пока Startup-проба активна, Kubernetes временно игнорирует livenessProbe, чтобы не убить Pod преждевременно.

• requests — минимальные ресурсы, которые Pod гарантированно получит.
• limits — максимальные ресурсы, которые он не может превысить.

Deployment — это объект kubernetes для автоматического управления нашим приложением. Например он следит, чтобы нужное количество копий приложения работало постоянно средствами ReplicaSet, помогает плавно обновлять версии с помощью RollingUpdate и др.

это внутренний механизм, управляющий количеством реплик конкретного pod'а. Его задача — поддерживать стабильное количество активных экземпляров определённой конфигурации приложения.

это стратегия обновления приложения, при которой новые версии разворачиваются постепенно, заменяя старые экземпляры (pod'ы) одно за другим, без прерывания обслуживания. Эта стратегия доступна в объектах Deployment и StatefulSet.

Это специальный тип ресурса в Kubernetes, созданный специально для управления группами приложений, которым важно сохранять своё состояние (stateful applications). Особенности StatefulSet:

• Постоянные имена: Каждый pod получает уникальное имя, которое сохраняется даже после перезапуска или перемещения pod'а на другой узел.
• Устойчивые объёмы данных: Каждому pod'у можно назначить постоянный volume (PV), сохраняющий данные даже после удаления pod'а.
• Упорядоченность: Pod'ы создаются и уничтожаются в строгом порядке, начиная с первого элемента списка.
• Поддержка специфичных задач: Подходит для баз данных, очередей сообщений и других приложений, чувствительных к состоянию и хранящих постоянные данные.

Это тип ресурса в Kubernetes, гарантирующий, что на каждом worker узле работает ровно один экземпляр определенного pod'a. Обычно DaemonSet применяется для служебных приложений, которые должны выполняться на каждом узле, например, сборщики логов (Logstash), утилиты мониторинга (Prometheus Node Exporter) или IstioD для ControlPlane.

Это инструмент управления сетевым взаимодействием между микросервисами. Реализуется с помощью добавления в наши поды sidecar-прокси, который перехватывает весь входящий и исходящий трафик. Структурно service mesh делится на две части. Первая это data plane, это все наши прокси сайдкары обрабатывающие трафик. И вторая control plane, слой распределяющий все настройки и политики между нашими прокси сайдкарами. К возможностям service mesh можно отнести управление шифрованием трафика(mTLS), управление обнаружением сервисов (Service Discovery), управление доступом(policies, RBAC, SNI и CIDR), балансировка нагрузки между сервисами, управление вызовами к сервисам (circuit breackers, rate limits, timeouts, retries) и трассировка для отслеживания пути каждого запроса (Observability).

• Master-нода - узел с управляющими компонентами кластера:
  • ETCD - хранилище, которое содержит состояние всех элементов. Все настройки (описания объектов) - yaml-ы с конфигурационными данными, хранятся тут. Хранилище является распределенным и все данные хранятся в нескольких экземплярах.
  • API-Server - принимает состояния от всех компонентов, валидирует их и сохраняет в хранилище (etcd), а также позволяет остальным компонентам k8s следить за состоянием интересующих их объектов.
  • Controller manager - содержит контроллеры для ресурсов, где каждый отслеживает состояние своего компонента и при различии текущего и желаемого состояний, приводит его в норму. Например ReplicaSet
  • Scheduler - ищет подходящий узел, чтобы назначить его, когда нужно развернуть еще один экземпляр приложения
• Worker-ноды - узлы, на которых работают наши приложения
  • Kubelet - компонент который управляет нашими приложениями на узле, запускает контейнеры, регулирует их состояние, при необхолдимости перезапускает. Иными словами, когда описание модуля (содержащего контейнер) становится готовым на master-ноде, kubelet по этому описанию создает и запускает реальный рабочий модуль.
  • kube-proxy - выполняет балансировку нагрузки, гарантирует, что IP-подключение попадет в модуль конкретно этого приложения, осуществляет переадресацию входящих запросов на конкретные pod'ы, используя IP-адресацию и port forwarding.
  • Container Runtime (Движок контейнеров) — это программа, которая фактически запускает контейнеры на уровне операционной системы. Она отвечает за исполнение контейнеризированных приложений и управление ими.

• DNS-сервер в Kubernetes — это дополнительный компонент, обеспечивающий внутреннюю систему именования (Domain Name System) для pod'ов и сервисов внутри кластера. Основной задачей DNS-сервера является разрешение доменных имён (имен сервисов) в IP-адреса. Как это работает:
  1. Pod отправляет запрос на разрешение имени (например, my-service).
  2. DNS-сервер принимает этот запрос и ищет соответствующую запись среди зарегистрированных сервисов.
  3. После нахождения соответствующей записи DNS возвращает IP-адрес соответствующего сервиса.
  4. Pod соединяется с указанным IP-адресом.
• Ingress Controller — это компонент Kubernetes, отвечающий за управление и обработку внешних запросов к сервисам внутри кластера. Примеры распространенных Ingress Controller: Envoy proxy, haproxy, Nginx Ingress Controller

Есть балансировщик нагрузки который балансирует запросы на worker-узлы, на которых установлен Ingress Controller (envoy, nginx, haproxy). С помощью манифеста Ingress Resources с типом kind: Ingress настраивается балансировка на необходимые services, которые в свою очередь балансируют на поды нашего приложения.

Gateway это шлюз на границе кластера. Описывающий порты, протоколы и хосты для входящего трафика. Основная задача gateway это маршрутизация и TLS-терминация входящего трафика.

С помощью virtual service настраиваются правила маршрутизации трафика к service внутри service mesh. Например canary-deploy или маршрутизация к разным версиям приложения с настройкой развесовки трафика балансировки.

С помощью DestinationRule настраиваются политики, применяемые к трафику, предназначенному для конкретного сервиса. Политики ретраев, таймаутов, балансировки нагрузки, размер пула соединений, circuit breaker.

Envoy Filter позволяюет изменять поведение прокси-сервера Envoy. Вставлять или изменять фильтры, влиять на обработку сетевых потоков и логику обработки запросов, тем самым расширяя или дополняя функционал стандартного Envoy.

Это компонент Istio, который концентрирует исходящий трафик через одну точку. Он позволяет контролировать и защищать трафик, идущий за пределы вашего кластера.
Для настройки егресса необходимо создать ряд конфигураций. Для начала нужно объявить внешний хост в нашем проекте с помощью ServiceEntry. Теперь нужно создать Service для Egress. Именно через этот Service будут проходить запросы к подам егресса. Затем для настройки маршрутизации трафика с egress нужно создать gateway. После создаем VirtualService который получает запросы на внешний по отношению к нашему неймспейсу ресурс и будет перенаправлять их на наш service егресса с которого через gateway будут улетать запросы. Если необходимо шифровать трафик то нужно добавить ресрурс DestinationRule в котором говорится какие сертификаты использовать.