Openshift архитектура

OpenShift — это мощная платформа для развертывания, управления и масштабирования контейнеризированных приложений на основе Kubernetes. Она предоставляет расширенные возможности по автоматизации CI/CD, безопасности, мониторингу и интеграции с корпоративной инфраструктурой. Архитектура OpenShift построена так, чтобы обеспечивать надежность, гибкость и соответствие требованиям современных DevOps-команд.

Что такое OpenShift: обзор и ключевые особенности

Red Hat OpenShift — это сертифицированная дистрибуция Kubernetes, дополненная инструментами для упрощения разработки, тестирования и эксплуатации приложений. В отличие от «голого» Kubernetes, OpenShift предлагает встроенные решения для CI/CD, безопасного хранения образов, сетевой изоляции и управления политиками безопасности. Это делает его особенно привлекательным для крупных организаций, которым важны соответствие стандартам, поддержка и интеграция с существующими системами.
Платформа поддерживает различные режимы развертывания: локально (OpenShift Local), в частных облаках (OpenShift Container Platform) и в публичных (OpenShift Dedicated, ROSA — Red Hat OpenShift Service on AWS). Независимо от среды, архитектурные принципы остаются единообразными. OpenShift добавляет к Kubernetes собственные API-объекты, такие как BuildConfig, ImageStream и Route, что позволяет глубже интегрировать процессы доставки приложений.
Одним из главных преимуществ является унификация DevOps-процессов. Разработчики могут использовать веб-консоль или CLI для запуска сборок, развертывания приложений и просмотра логов без необходимости взаимодействовать напрямую с Docker или внешними CI-серверами. Это снижает порог входа и повышает скорость выхода на рынок.

Основные компоненты архитектуры OpenShift

Архитектура OpenShift строится вокруг нескольких ключевых компонентов, разделённых на плоскость управления (control plane) и рабочие ноды (worker nodes). Каждый элемент выполняет свою функцию, обеспечивая целостность и отказоустойчивость системы.
Контроллеры на мастер-нодах управляют состоянием кластера, принимают запросы через API, планируют размещение подов и следят за их здоровьем. Вычислительные ноды исполняют контейнеры, управляют сетевыми интерфейсами и томами. Между ними находится etcd — распределённое хранилище конфигураций, которое сохраняет текущее состояние всего кластера.
Дополнительно в состав входят специализированные сервисы:

• Router (HAProxy) — обеспечивает внешний доступ к приложениям через HTTP/HTTPS;
• Registry — внутреннее хранилище образов контейнеров;
• Operator Hub — центр управления операторами для автоматизации задач;
• Monitoring Stack — набор Prometheus, Grafana и Alertmanager для сбора метрик.

Все эти компоненты взаимодействуют через единый API-сервер, который служит единственной точкой входа для всех операций — будь то команды oc, веб-интерфейс или автоматизированные скрипты. Такой подход упрощает аудит, контроль доступа и централизованное управление.

Пример типичного взаимодействия

Представьте, что разработчик отправляет новый код в Git-репозиторий. Система CI запускает сборку, создавая образ контейнера и помещая его в OpenShift Registry. Затем триггер в DeploymentConfig автоматически обновляет поды, запуская новую версию приложения. Router перенаправляет трафик, а система мониторинга фиксирует метрики производительности. На каждом этапе задействованы разные компоненты, но процесс выглядит как единый поток.

Плоскость управления: как работает мастер-нода

Мастер-нода (или control plane node) — это «мозг» кластера OpenShift. Она содержит несколько критически важных компонентов, каждый из которых отвечает за определённый аспект управления:

• API Server — принимает все REST-запросы, проверяет права доступа и обновляет состояние в etcd;
• etcd — высокодоступное ключ-значение хранилище, где хранятся все конфигурации кластера;
• Controller Manager — следит за состоянием ресурсов и корректирует их при отклонениях (например, перезапускает поды при сбоях);
• Scheduler — определяет, на какой worker node будет запущен новый под, учитывая ресурсы, политики и ограничения.

В продакшен-средах рекомендуется разворачивать минимум три мастер-ноды для обеспечения отказоустойчивости. etcd работает в кластерном режиме, требуя нечётного числа узлов (3, 5, 7) для предотвращения «разделения мозга» (split-brain).
API сервер также интегрируется с внешними системами аутентификации — LDAP, OAuth2, OpenID Connect. Это позволяет централизованно управлять доступом пользователей и сервисных аккаунтов. Все действия логируются, что критично для аудита и соответствия стандартам (например, ISO 27001, GDPR).

Рабочие ноды и управление контейнерами

Worker nodes — это узлы, где фактически запускаются контейнеры. Каждая нода выполняет kubelet, kube-proxy и контейнерный движок (в OpenShift — CRI-O, альтернатива Docker). Kubelet взаимодействует с API-сервером, применяет конфигурации и сообщает о состоянии подов.
CRI-O — легковесный runtime, оптимизированный для работы с Kubernetes. Он не поддерживает команды вроде docker run, но зато обеспечивает меньшее потребление ресурсов и повышенную безопасность за счёт минимального набора функций. Это соответствует философии OpenShift: «меньше возможностей — меньше векторов атак».
На каждой ноде также работает OpenShift Node Agent, который управляет:

• локальными томами;
• сетевыми правилами;
• политиками безопасности контейнеров (SCC);
• логированием через Fluentd или Loki.

Планировщик (Scheduler) учитывает множество факторов при размещении пода: количество свободных CPU и RAM, affinity/anti-affinity правила, зоны доступности и метки нод. Например, можно указать, что поды базы данных должны находиться на нодах с SSD-дисками, а frontend-приложения — ближе к внешнему маршрутизатору.

Как проверить состояние нод?

Через CLI:

1. Выполните oc get nodes — покажет список всех нод и их статус (Ready, NotReady);
2. Используйте oc describe node <имя> — детальная информация о загрузке, подах, условиях;
3. Проверьте логи kubelet: journalctl -u kubelet на самой ноде.

Сетевая модель и маршрутизация в OpenShift

Сеть в OpenShift основана на модели Pod-to-Pod коммуникации без NAT. Каждый под получает уникальный IP-адрес, доступный из любой ноды кластера. Это реализуется с помощью CNI-плагинов — по умолчанию используется OpenShift SDN или OVN-Kubernetes.
Внутренний сервисный DNS позволяет обращаться к другим подам и сервисам по имени (например, database.default.svc.cluster.local). Сервисы абстрагируют группы подов, обеспечивая балансировку нагрузки и стабильный эндпоинт.
Для внешнего доступа используются два механизма:

• Routes — основаны на Ingress, используют HAProxy для HTTP/HTTPS трафика;
• Services с типом LoadBalancer или NodePort — для TCP/UDP приложений.

Route может включать TLS-терминацию, что позволяет использовать собственные сертификаты или автоматически получать Let’s Encrypt через cert-manager. Это особенно удобно для веб-приложений, которым нужен HTTPS.

Пример маршрута

«`yaml
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: my-app-route
spec:
host: app.example.com
to:
kind: Service
name: my-app-service
tls:
termination: edge
certificate: |-
——BEGIN CERTIFICATE——
…
——END CERTIFICATE——
«`

Хранение данных: тома и Persistent Volumes

Хотя контейнеры по своей природе эфемерны, многим приложениям нужно постоянное хранилище. OpenShift поддерживает Persistent Volumes (PV) и Persistent Volume Claims (PVC), которые позволяют подключать долгоживущие тома к подам.
PV могут быть:

• локальными (на диске ноды);
• сетевыми (NFS, iSCSI);
• облачными (AWS EBS, Azure Disk, GCP Persistent Disk);
• динамическими, создаваемыми через StorageClass.

StorageClass определяет тип хранилища и политику предоставления. Например, можно создать класс «fast-storage» на SSD и «backup-storage» на медленных HDD. PVC запрашивает том указанного размера и класса, после чего он автоматически привязывается к PV.
Важно помнить, что тома привязаны к availability zone. Если под перемещается в другую зону, он не сможет подключиться к тому же PV, если тот не поддерживает multi-zone доступ. Для таких случаев используются распределённые файловые системы, например, GlusterFS или Ceph (через CSI-драйверы).

Best practices по работе с хранилищем

1. Не храните данные внутри контейнера — они потеряются при перезапуске;
2. Используйте PVC для всех stateful-приложений (базы данных, очереди);
3. Настройте backup-стратегию для критичных томов;
4. Указывайте access modes: ReadWriteOnce, ReadOnlyMany, ReadWriteMany.

Безопасность и управление доступом (RBAC, SCC)

Безопасность в OpenShift выходит за рамки стандартного Kubernetes. Помимо RBAC (Role-Based Access Control), здесь активно используется механизм Security Context Constraints (SCC) — это политико-управляемые правила, определяющие, что может делать контейнер.
SCC контролирует:

• возможность запуска в privileged-режиме;
• доступ к хост-сети и PID-пространству;
• типы томов, которые можно монтировать;
• runAsUser стратегии (root или non-root).

По умолчанию обычные пользователи не могут запускать привилегированные поды. Только администраторы или специальные service accounts имеют такие права. Это значительно снижает риски при компрометации приложения.
RBAC в OpenShift работает через:

• Roles / ClusterRoles — наборы разрешений;
• RoleBindings / ClusterRoleBindings — привязка ролей к пользователям или группам.

Также поддерживается мульти-тенантность: проекты (проект = namespace) изолируют ресурсы между командами. Администратор может назначить квоты на использование CPU, памяти и количества подов.

Жизненный цикл приложения в OpenShift

Разработка и развертывание приложения в OpenShift проходит несколько этапов:

• Source — код в Git-репозитории;
• Build — сборка образа через Source-to-Image (S2I) или Dockerfile;
• Image Stream — тегирование и хранение образа в registry;
• Deployment — запуск подов на основе нового образа;
• Routing — открытие доступа через Route;
• Monitoring — сбор метрик, логов, алертов.

Каждый шаг может быть автоматизирован через Pipeline (на основе Tekton) или Jenkins. OpenShift Pipelines позволяют описать весь CI/CD в виде YAML-манифестов, что обеспечивает воспроизводимость и контроль версий.

Пример простого BuildConfig

«`yaml
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
name: my-app-build
spec:
source:
type: Git
git:
uri: https://github.com/user/myapp.git
strategy:
type: Source
sourceStrategy:
from:
kind: ImageStreamTag
name: python:3.9
output:
to:
kind: ImageStreamTag
name: my-app:latest
«`
После успешной сборки, ImageChangeTrigger в DeploymentConfig автоматически запускает обновление подов.

Экспертное мнение

Открытость архитектуры OpenShift позволяет адаптировать её под любые бизнес-задачи, но успех зависит от правильного проектирования. Начинайте с чёткого определения требований: уровень доступности, объём данных, регуляторные нормы. Избегайте избыточной сложности — не подключайте операторы и сервисы без реальной необходимости.
При проектировании кластера учитывайте будущее масштабирование. Выделите отдельные пулы нод для разных типов нагрузок: stateful, batch, high-memory. Используйте network policies для сегментации трафика между проектами. Это защитит от «шума» и возможных атак.
Регулярно обновляйте кластер. OpenShift 4 поддерживает zero-downtime обновления через Operators. Не откладывайте апгрейды — они содержат исправления уязвимостей и новые функции. Автоматизируйте бэкапы etcd и важных томов.
Интегрируйте OpenShift с системами централизованного логирования и мониторинга. Настройте алерты на ключевые метрики: использование ресурсов, ошибки планировщика, недоступность нод. Это позволит быстро реагировать на инциденты.

Вопросы и ответы

Заключение

OpenShift представляет собой зрелую, enterprise-ready платформу, сочетающую мощь Kubernetes с инструментами для полного жизненного цикла приложений. Его архитектура спроектирована с учётом отказоустойчивости, безопасности и масштабируемости, что делает её идеальным выбором для крупных организаций.
Понимание компонентов — от etcd до SCC — позволяет эффективно управлять кластером, быстро диагностировать проблемы и проектировать надёжные системы. Автоматизация, централизованное управление и встроенная безопасность снижают операционные издержки и ускоряют вывод продуктов на рынок.

• OpenShift расширяет Kubernetes встроенными DevOps-инструментами и механизмами безопасности.
• Архитектура включает мастер-ноды, worker nodes, etcd, router и registry — каждый компонент критичен.
• Используйте SCC и RBAC для контроля доступа и повышения безопасности.
• Автоматизируйте жизненный цикл приложений через BuildConfig, ImageStream и Deployment.
• Регулярно обновляйте кластер и делайте бэкапы ключевых данных.