Разработку можно сравнить с картиной, где художник — ведущий разработчик. Создание элегантного микросервисного приложения — с творениями лучших архитекторов — модернистов. А вот поставить процесс на поток и оставить возможность выбирать — искусство. В первой статье из серии мы хотим рассказать о том, как создавался и работает облачный сервис IBM Kubernetes service и IBM Managed OpenShift, а также рассказать, как вы можете бесплатно развернуть и протестировать свой кластер Kubernetes в облаке IBM.

Облако IBM набирало свой функционал в течение последних десяти лет. Начиналось все с построения разделяемых инфраструктур для обслуживания больших корпораций, затем с виртуальных и физических машин на основе датацентров SoftLayer, потом была пятилетка строительства PaaS (на базе Cloud Foundry runtimes) и эволюция огромного количества сервисов. В создании части сервисов принимала участие и московская команда разработки. Но сегодня речь пойдет не о сервисах, а о том, что же такое managed kubernetes и managed openshift и как это работает в облаке IBM. Множество деталей рассказать не получится, так как проект внутренний, но некоторую завесу приоткрыть можно.

Что такое kubernetes и чем managed kubernetes/openshift отличается от локальной установки

Изначально kubernetes позиционировался как open-source платформа управления контейнеризированными приложениями и сервисами. Основными задачами kubernetes являются (оставлю без перевода, чтобы не ломать терминологию):

• Service discovery and load balancing
• Storage orchestration
• Automated rollouts and rollbacks
• Automatic bin packing
• Self-healing
• Secret and configuration management

В целом kubernetes отлично справляется со всеми этими задачами. С другой стороны, kubernetes стали позиционировать как базу данных для хранения конфигурации приложений или средство управления API ваших компонентов (особенно актуально в разрезе развития операторов).

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

• развертывание кластеров
• настройка сетевой доступности и распределенности
• установка обновлений и фикспаков
• настройка кластера для увеличения отказоустойчивости и безопасности (подробнее в самой статье)
• ...

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

Архитектура облачного решения

Внутри компании проект IBM Managed Kubernetes и IBM Managed OpenShift называется проект Armada. Проект начинался с одного датацентра, но теперь он доступен в 60 облачных датацентрах в 6 различных регионах. Для того, чтобы описать, как масштабируется облако, я буду использовать два термина: hubs и spokes. Весь проект Armada основан на kubernetes, что означает, что его кластеры управляются контрольной панелью, которая работает в kubernetes. Как только контрольной панели недостаточно ресурсов для управления необходимым набором кластеров — она разворачивает дополнительные spokes. Эти spokes в дальнейшем будут отвечать за управление кластерами в конкретном регионе.

Контрольная панель состоит из более чем 1500 деплойментов и размещена в 60 kubernetes-кластерах. Все это необходимо для того, чтобы управлять более чем 15000 кластерами наших заказчиков (не включая тестовых бесплатных кластеров, которые разворачиваются на одном воркере).

Чтобы создать IKS и Managed OpenShift, команда использовала OpenSource модель внутри компании. В большинство репозиториев Armada имеют доступ все сотрудники компании IBM и могут создавать свои PR для интеграции своих сервисов. В рамках сервисных работ также было разработано огромное количество CI/CD инструментов, которые были объединены в проект Razee. Летом 2019 года IBM выложила в OpenSource все наработки проекта Razee.

В целом архитектура для IKS и Managed OpenShift выглядит следующим образом:

Когда вы работаете с IBM Cloud CLI и запрашиваете создание кластера, то по факту ваши запросы уходят в Armada API, далее контрольная панель определяет доступность spokes и инициирует создание необходимого количества воркеров в указанных Вами регионах. Вся инфраструктура для воркеров обеспечивается с помощью IBM Cloud Infrastructure (aka Soflayer), фактически используются те же виртуальные инстансы и bare metal хосты, которые доступны в разделе "Compute" каталога облачных сервисов. Через некоторое время вы получите токен авторизации и сможете начать разворачивать ваши приложения.

Так как OpenShift и Kubernetes отличаются своими возможностями и дорожной картой развития, то соответственно отличается и базовый стек технологий:

Как обеспечивается безопасность

О проекте Armada можно говорить очень долго как с технической точки зрения, так и с маркетинговой. Но в первую очередь при выборе облачного провайдера, предоставляющего managed kubernetes все задаются одним и тем же вопросом — как провайдер гарантирует и обеспечивает безопасность и отказоустойчивость моих приложений?.. Невозможно оценивать производительность, удобство, уровень сервисной поддержки, не получив ответ на этот вопрос. Как руководитель разработки, во время разработки любого крупного проекта я рисую карту угроз. В нее необходимо внести все возможные варианты взлома и обезопасить свою инфраструктуру, приложения и данные. Для того, чтобы говорить о безопасности kubernetes — кластера, необходимо описать следующие моменты:

• безопасность самой инфраструктуры и Датацентров
• доступ к Kubernetes API и etcd
• безопасность мастер и воркер узлов
• безопасность сети
• безопасность persistent storage
• мониторинг и логирование
• безопасность контейнеров и образов контейнеров

Теперь обо всем по порядку:

Безопасность самой инфраструктуры и Датацентров

Как бы мы не хотели полностью абстрагироваться от железа и обслуживания аппаратной начинки ИТ-систем, на деле нам нужно быть уверенными что поставщик сервиса полностью прикроет нам тыл, и подтвердит это документально с помощью индустриальных и отраслевых сертификаций, а при необходимости и с помощью отчетов о проведении аудитов. Данный аспект был учтен командой IBM со всей возможной серьёзностью и все необходимые сведения собраны и представлены в одном месте (https://www.ibm.com/cloud/compliance)

Доступ к Kubernetes API и etcd

Для того, чтобы получить доступ к Kubernetes API и данным в etcd необходимо пройти три уровня авторизации. Каждый выпущенный токен авторизации связан с аутефикационными токенами, авторизационными данными кластера (RBAC) и Admission controller (см. схему ниже).

Так как мастера конфигурируются централизованно с помощью spokes, то это означает что вы не можете изменить конфигурацию мастера, сами мастера даже не расположены на вашем облачном аккаунте и не видны в перечне ваших устройств (в отличии от воркеров). Все конфигурационные изменения могут производиться только в рамках определенных возможностей. С одной стороны, это — ограничение, но за счет этого ограничения у злоумышленников тоже не будет доступа к вашим мастерам, помимо этого отсутствует человеческий фактор ошибки, нет риска от использования несовместимых версий компонентов kubernetes и облегчается весь процесс администрирования кластера. В целом можно сказать, что IBM отвечает за обеспечение отказоустойчивости и правильное конфигурирование kubernetes master. Если в вашем проекте есть жесткие требования по использованию определенных версий компонентов, то я бы на вашем месте не смотрел на managed kubernetes совсем и использовал собственную установку.

Безопасность мастер и воркер узлов

Для того, чтобы обеспечить безопасность воркеров и мастер узлов мы используем шифрованные VPN туннели между вычислительными узлами, и у пользователя есть возможность заказать воркер с шифрованными жесткими дисками. Мы также используем Application Armor для ограничения доступа приложений к ресурсам на уровне операционной системы. Application Armor является расширением ядра Linux для конфигурации доступа к ресурсам для каждого приложения.

При создании кластера после выбора подходящей вам конфигурации для вас будут созданы виртуальные или baremetal серверы, на которые будут установлены компоненты для работы ваших воркеров. К ОС воркера доступ у пользователя есть, но только при подключении через management VPN, что может пригодиться для траблшутинга, а также для обновления самой ОС воркера. Доступа по публичному IP по ssh нет, для того чтобы получить ssh внутрь контейнера необходимо использовать kubectl exec, данное соединение будет осуществлено через тунель OpenVPN.

Безопасность сети

В managed kubernetes и openshift в качестве решения по виртуализации сети используется Calico сетевой плагин. Безопасность сети достигается с помощью предустановленных Kubernetes и Calico сетевых политик. Ваши воркеры могут находиться в одних и тех же VLAN что и вся ваша остальная инфраструктура в этом же ЦОД-е, такая как обычные виртуальные машины и baremetal серверы, а также сетевые аплаенсы и системы хранения, и благодаря calico системы размещенные за пределами вашего кластера, смогут общаться по приватной сети с вашими деплойментами.

Когда создается кластер с публичным VLAN, контрольная панель создает ресурс HostEndpoint с лейблом ibm.role: worker_public для каждого воркера и его внешних сетевых интерфейсов. Для защиты внешних сетевых интерфейсов контрольная панель применит все политики по-умолчанию Calico ко всем endpoints с лейблом ibm.role: worker_public.

Политики по умолчанию Calico разрешают весь исходящий трафик и разрешают входящий трафик из интернета к определенным компонентам (Kubernetes NodePort, LoadBalancer и Ingress сервис). Весь остальной трафик блокируется. Политики по умолчанию не применяются к трафику внутри кластера (взаимодействие между pod-ами)

Безопасность persistent storage

Для безопасности на уровне персистенции используется шифрование и авторизация по ключам. Для IKS в данный момент доступны:

• Классический NFS
• Классический block storage (iSCSI)
• VPС block storage
• IBM Cloud object storage
• SDS на базе Porworx (использует локальные диски ваших же воркеров)

Мониторинг и логирование

Для мониторинга IKS можно использовать IBM Cloud Monitoring или решение от Sysdig. Естественно что без Prometheus не обошлось. В Managed OpenShift используются встроенные средства мониторинга.

С самими логами дела обстоят сложнее. Необходимо собирать логи с абсолютно различных уровней, у нас используется большое количество собственных и open source решений. Мы собираем и храним следующие логи:

• Логи самого контейнера (STDOUT, STDERR)
• Логи приложения (если указан путь к ним)
• Логи с рабочего узла
• Логи Kubernetes API
• Логи Ingress
• Логи всех системных компонентов Kubernetes (kube-system namespace)

Для контроля логов доступен отдельный сервис IBM Cloud Log Analysis with LogDNA, который позволяет выводить все логи в общую консоль и анализировать ретроспективно или в режиме реального времени в зависимости от тарифа. Инстанс можно создать отдельно в каждом из 6 регионов и затем использовать для сбора логов вашего Kubernetes кластера и прочей инфраструктуры на вашем аккаунте. Для подключения данного сервиса в ваш кластер необходимо поставить pod с агентом LogDNA следуя нехитрым инструкциям, и все логи будут отправляться в репозиторий LogDNA, далее в зависимости от выбранного плана будут доступны для дальнейшего анализа в течение определенного периода.

Для анализа активностей внутри ваших облачных сервисов, включая логины и многое другое, доступен Activity Tracker with LogDNA — он позволяет отслеживать различные действия в ваших сервисах.

В качестве дополнительного средства мониторинга можно натравить на ваш кластер сервис IBM Cloud Monitoring with Sysdig — доступен во всех 6 регионах, что позволит вам в реальном времени отслеживать множество метрик в вашем кластере, и использовать встроенные интеграции с множеством распространенных сред, запускаемых в контейнерах. Кроме этого, можно настроить реакцию на события с возможностью уведомлений через slack, email, PagerDuty, WebHook итп.

Безопасность контейнеров и образов контейнеров

У компании есть свое мнение о том, что же входит в DevOps. Если кому-то будет интересно — можете почитать об этом подробнее — IBM Garage method. Понимание что такое DevSecOps тоже формируется во многих компаниях и применяется на практике. Чтобы понять какие этапы проходит Docker image для того, чтобы стать Docker container, посмотрим на следующий рисунок.

В облаке IBM существует возможность использовать Docker registry как сервис. При отправке образа в данный registry docker image подписывается. Со стороны воркер ноды установлен addon, который отвечает за проверку целостности и соответствия политикам безопасности — Vulnerability Advisor. С помощью этих политик вы можете, например, ограничить круг registry, откуда возможно скачать docker images.

apiVersion: securityenforcement.admission.cloud.ibm.com/v1beta1
kind: ClusterImagePolicy
metadata:
name: ibmcloud-default-cluster-image-policy
spec:
 repositories:
  # CoreOS Container Registry
  - name: "quay.io/*"
    policy:

  # Amazon Elastic Container Registry
  - name: "*amazonaws.com/*"
    policy:

  # IBM Container Registry
  - name: "registry*.bluemix.net/*"
    policy

Vulnerability Advisor работает с запущенными контейнерами, периодически сканируя их и автоматически определяя установленные пакеты. Docker images с потенциальными уязвимостями помечаются, как опасные для использования и предоставляется подробная информацию о найденных уязвимостях.

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

Регистрация и пример разворачивания managed кластера kubernetes

Развернуть и протестировать свой кластер managed Kubernetes вы можете в облаке IBM абсолютно бесплатно:

• Зарегистрируйтесь в облаке IBM: https://ibm.biz/rucloud (вам придется подтвердить свой адрес электронной почты, данные кредитной карты на этом этапе добавлять не надо)
• Для использования сервиса IKS вы можете перевести ваш аккаунт в платный (нажав Upgrade, и введя данные банковской карты — при этом вы получите $200 на счет). Или специально для читателей хабра, можете получить купон на переключение аккаунта в режим "trial" — это позволит вам развернуть минимальный кластер бесплатно на 30 дней. По истечении этого срока кластер можно будет пересоздать заново и продолжить тестирование. Купон вы можете запросить по ссылке — https://ibm.biz/cloudcoupon. Подтверждение купона производится в течение рабочего дня.
• Бесплатный кластер (один воркер 2 vCPUs 4GB RAM) можете создать из каталога сервисов — https://cloud.ibm.com/kubernetes/catalog/cluster/create
• На создание кластера уйдет 5-7 минут, после чего вам будет доступен кластер IKS.

Заключение

Надеюсь после прочтения данной статьи у читателя стало меньше вопросов, о том как работает managed kubernetes и managed open shift. Данную статью можно так же использовать как инструкцию к действию по реализации своего собственного kubernetes. Все практики, использованные IBM применимы и для частных облаков и при определенных усилиях реализуемы в любом дата центре.

Ресурсы

IKS slack
https://ibm-container-service.slack.com/
https://www.ibm.com/cloud/blog/announcements/ibm-cloud-activity-tracker-with-logdna-for-ibm-cloud-object-storage
https://www.ibm.com/cloud/blog/announcements/introducing-the-portworx-software-defined-storage-solution
https://cloud.ibm.com/docs/services/Monitoring-with-Sysdig?topic=Sysdig-getting-started