Kubernetes Day-2 Operations — Part II

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

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

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

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

Новые приложения с Kubernetes не всегда подходят для компаний, поскольку они вложили средства в существующие приложения. Задача состоит в том, чтобы взять существующие приложения и запустить их в Kubernetes. Другим вариантом может быть запуск ваших существующих приложений как устаревших, но при этом они должны беспрепятственно взаимодействовать с новыми приложениями Kubernetes. Даже если в вашей команде есть ветераны Kubernetes, переход на Kubernetes все равно будет болезненным. Это может отнять у вашей команды DevOps значительное количество энергии и времени.

Kubernetes может быть дешевле в использовании и развертывании, но не тогда, когда ваши инженеры тратят время на его выяснение, а не на создание новой «осязаемой» ценности для бизнеса.

Тем не менее, операции второго дня в Kubernetes никогда не были легкими. В первой части трех серий блогов мы рассмотрели три болевые точки Операции второго дня Kubernetes: управление манифестами, управление томами, начальная загрузка кластера Kubernetes и как CloudPlex исправляет их для вас.

Динамические параметры

При сборке приложения то, как вы настроили свои контейнеры, многое говорит о его производительности в производственной среде и, таким образом, является критически важной частью. Переменные среды играют важную роль внутри кластера Kubernetes при настройке приложения для пар ключ-значение. За исключением того, что передача переменных среды в Kubernetes не так проста, как нам кажется. Если развертывание вашего приложения включает большое количество контейнеров, которые время от времени должны взаимодействовать друг с другом, то даже переназначение значения одной переменной становится долгой и сложной задачей для команд DevOps.

Если вы использовали свой собственный управляемый контейнер MySQL, совместно используемый большим количеством контейнеров Docker во время разработки, вы могли передать некоторые исключения при передаче переменных среды в Kubernetes в рабочей среде. Ваше решение перейти на сервер MySQL, управляемый провайдером, может не совпадать с вашими существующими реализациями контейнеров. Если вам не удобно менять строку подключения в каждом контейнере Docker, иногда вручную. Наступит момент, когда все это станет слишком сложным для обслуживания и передачи обновлений.

Начальная загрузка кластера Kubernetes

Настройка комплексной инфраструктуры Kubernetes состоит из ряда переменных. К ним относятся правильный DNS-адрес, политики балансировки нагрузки, сертификаты безопасности и надежный контроль доступа на основе ролей (RBAC). Наряду с множеством вспомогательных компонентов они делают возможным процесс развертывания.

В двух словах, развертывание собственного кластера Kubernetes (или DIY Kubernetes) с нуля — это долгая установка, а не чашка чая для каждого разработчика. Это требует определенной степени понимания.

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

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

Kubernetes RBAC

Это встроенный механизм управления доступом к ролям (RBAC), который позволяет настраивать детальные и конкретные наборы разрешений внутри кластера Kubernetes. Разрешения Kubernetes RBAC определяют, как вы взаимодействуете с объектом Kubernetes в кластере или в определенном пространстве имен кластера. Хотя Kubernetes RBAC упрощает управление разрешениями внутри кластера, он не очень удобен для разработчиков, поскольку им приходится вручную создавать роли, привязки ролей и учетные записи служб. Что еще хуже, каждому контейнеру или сервису может потребоваться своя конфигурация RBAC. То есть вам предстоит пройти через кошмар создания привязок между учетными записями служб и ролями для каждой службы. Были ли у создателей Kubernetes обиды на разработчиков?

Разработчики! Принесите CloudPlex на помощь.

К счастью для разработчиков, CloudPlex решает не одну, а все три вышеупомянутые проблемы. Кто сказал, что работа второго дня в Kubernetes должна быть кошмаром для разработчиков? Не тогда, когда CloudPlex вам в помощь.

![Динамические параметры, начальная загрузка кластера Kubernetes и RBAC Kubernetes]

Если динамические параметры разрушают вашу жизнь по одной переменной среды за раз, вам нужен способ определения динамических параметров в ваших службах. К счастью, CloudPlex дает вам его. Он сам определяет значение этих параметров и заменяет их во время развертывания в кластере Kubernetes.

![Динамические параметры, загрузка кластера Kubernetes и RBAC Kubernetes]

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

![Динамические параметры, загрузка кластера Kubernetes и RBAC Kubernetes]

CloudPlex упрощает развертывание кластера K8 с нуля. Вы можете запустить свой собственный кластер без ограничений, установленных управляемыми поставщиками, такими как GKE, AKS и EKS. Любой разработчик может запустить кластер Kubernetes с нуля, а CloudPlex предоставляет богатый набор K8 и вариантов конфигурации инфраструктуры. Использование пользовательского образа машины и ssh для установки дополнительных конфигураций не представляет сложности.

Не говоря уже о том, что CloudPlex позволяет использовать управляемые провайдером кластеры Kubernetes (GKE, AKS, EKS) для развертывания приложений.

Если настройки RBAC Kubernetes по умолчанию доставляют вам проблемы со сном, с CloudPlex вам нужно только предоставить информацию о ресурсах и разрешениях. Он автоматически создает и настраивает учетные записи служб, роли и привязки ролей.

CloudPlex позволяет безболезненно и быстро проектировать, разрабатывать, тестировать и запускать приложения Kubernetes. Это экономит ваше время при развертывании вашего кластера. Это инструмент для разработчиков разработчиками.

Начните прямо сейчас и бесплатно создайте свой первый кластер Kubernetes за несколько минут.

Асад Файзи

Генеральный директор

CloudPlex.io, Inc

asad@cloudplex.io