Как реализовать многопользовательскую SaaS в кластере Kubernetes

В этой статье конкретно показано, как реализовать многопользовательскую SaaS в кластере Kubernetes .

В примере из предыдущей статьи вымышленное автономное приложение Clyde's Clarinets было преобразовано в платформу SaaS под названием Instrument Resellers. Кларнеты Клайда предназначались для приобретения, ремонта и перепродажи бывших в употреблении кларнетов. Кларнеты Клайда превратились в платформу SaaS для реселлеров инструментов, чтобы любой бизнес мог приобретать, ремонтировать и перепродавать определенный тип инструментов. Таким образом, у реселлеров инструментов есть возможность поддерживать таких арендаторов, как духовые инструменты Бетти и саксофоны Сидни, а также кларнеты Клайда. (См. рис. 1.)

Автономное веб-приложение было преобразовано в платформу SaaS.

Рисунок 1: Автономное веб-приложение было преобразовано в платформу SaaS.

Внедрение SaaS в Kubernetes

В этой статье описывается, как использовать стандартные ресурсы Kubernetes — пространства имен, развертывания и службы — для создания различных арендаторов с использованием общей базы кода. В дополнение к стандартным ресурсам Kubernetes мы используем ресурс маршрута , предоставляемый Red Hat OpenShift , для создания общедоступного URL-адреса, который обеспечивает доступ к внутренней службе Kubernetes, представляющей конкретный экземпляр приложения клиента.

Демонстрационный код работает на платформе Red Hat OpenShift Container Platform, поскольку его ресурс маршрута обеспечивает простой способ создания доменного имени, обеспечивающего доступ к арендатору, работающему в кластере Kubernetes.

Эта статья относится к демонстрационному коду для реализации платформы SaaS Instrument Reseller. В следующей статье этой серии будет подробно описан код в демонстрационном проекте. На данный момент вы можете использовать демонстрационный проект в качестве вспомогательного материала для этой статьи.

Имейте в виду, что для получения полной пользы от чтения этой статьи вам необходимо иметь представление о контейнерах и Kubernetes, особенно в отношении назначения и использования модулей Kubernetes , развертываний , секретов и сервисов . Также у вас должен быть опыт работы с клиентом kubectl для Kubernetes. Кроме того, вам должно быть удобно создавать ресурсы Kubernetes с помощью файлов манифеста (они же конфигурации) .

В следующих разделах описано, как:

Используйте пространства имен Kubernetes для изоляции арендаторов на платформе SaaS.
Настройте развертывания Kubernetes, чтобы выделить логику приложения конкретному арендатору.
Привяжите базу данных к конкретному арендатору с помощью секрета Kubernetes.
Представьте логику приложения арендатора во внутренней сети в кластере с помощью службы Kubernetes.
Предоставьте доступ к арендатору за пределами кластера с помощью маршрута OpenShift.
Развертывайте и обновляйте логику клиентского приложения, используя базовый процесс непрерывной интеграции/непрерывного развертывания (CI/CD) .

Роль пространств имен Kubernetes в SaaS

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

Существует несколько возможных подходов к мультиарендности на платформе SaaS в Kubernetes:

Встраивайте изоляцию арендаторов прямо в логику одного приложения.
Запустите каждого арендатора в своем собственном кластере.
Запускайте каждого арендатора в собственном пространстве имен Kubernetes.

Платформа Instrument Reseller SaaS использует третий подход и использует пространства имен для поддержки нескольких арендаторов в одном кластере Kubernetes. В этом разделе объясняются детали концепции пространства имен.

Пространства имен, как следует из названия, создают рабочую границу, которую можно наложить на другие ресурсы. Например, вы можете создать пространство имен с именем foo, а затем создать другие ресурсы, такие как модули и службы, в этом fooпространстве имен. Эти ресурсы знают только о других ресурсах в fooпространстве имен. Ресурсы за пределами этого пространства имен не имеют доступа к ресурсам внутри этого пространства имен.

В многопользовательской службе, использующей изоляцию пространства имен, каждый арендатор в кластере Kubernetes представлен определенным пространством имен. Ресурсы развертывания, службы и маршрута для конкретного арендатора создаются в пространстве имен этого арендатора. На рис. 2 показано, как пространства имен Kubernetes изолируют арендаторов на платформе SaaS Instrument Resellers.

Каждый арендатор имеет собственное пространство имен и URL-адрес, но запускает одно и то же приложение.

Рис. 2. У каждого арендатора есть собственное пространство имен и URL-адрес, но выполняется одно и то же приложение.

Хотя на рис. 2 показаны три арендатора, в этой статье показаны конфигурации только для Betty's Brass и Clyde's Clarinets, поскольку двух арендаторов достаточно, чтобы проиллюстрировать концепции, которые вам необходимо знать. В таблице 1 показаны файлы манифеста, в которых объявляются пространства имен Kubernetes для этих арендаторов. Два манифеста одинаковы, за исключением nameсвойств.

Таблица 1: Манифесты, объявляющие пространства имен.

Бетти Брасс

kind: Namespace
apiVersion: v1
metadata:
  name: bettysbrass
  labels:
    name: bettysbrass

Кларнеты Клайда

kind: Namespace
apiVersion: v1
metadata:
  name: clydesclarinets
  labels:
    name: clydesclarinets

Чтобы создать каждое пространство имен в кластере Kubernetes, выполните следующую команду, где <tenant_namespace>— имя файла манифеста, относящегося к арендатору:

$ kubectl apply -f <tenant_namespace>.yaml

Создание и настройка арендаторов в рамках SaaS с использованием развертывания Kubernetes.

После создания пространств имен следующей задачей является реализация логики для данного арендатора в соответствии с назначенным ему пространством имен. Эта задача использует ресурс развертывания Kubernetes.

Как упоминалось ранее, ключевой особенностью SaaS Instrument Reseller является то, что единая кодовая база может поддерживать любое количество арендаторов, желающих приобретать и перепродавать музыкальные инструменты. Логика приложения для каждого реселлера инструментов представлена в SaaS ресурсом развертывания Kubernetes.

Развертывание контролирует одну или несколько реплик модуля . Количество модулей, работающих в рамках развертывания, определяется replicasсвойством в файле манифеста ресурса развертывания.

Таким образом, вы можете изменить количество реплик, поддерживаемых развертыванием во время работы приложения. Например, торговый посредник может начать с запуска трех модулей. Но через какое-то время нагрузка на тенанта такова, что pod'ов нужно больше. Чтобы создать больше модулей в развертывании, увеличьте значение, присвоенное replicasсвойству в файле манифеста, например, с трех до пяти. Затем повторно примените файл манифеста развертывания к кластеру. Когда нагрузки уменьшатся, вы можете уменьшить количество модулей в развертывании, изменив replicasпараметр в файле манифеста и таким же образом повторно применив измененный файл к кластеру.

Если модуль отключится, ресурс развертывания создаст замену, если это возможно.

Настройка развертываний

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

Например, в таблице 2 показаны манифесты, которые настраивают развертывание Kubernetes для Betty's Brass и Clyde's Clarinets. Единственными отличиями являются значения имен и инструментов.

Таблица 2: Манифесты настройки развертываний.

Бетти Брасс

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: bettysbrass
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: SEEDER_COUNT
              value: "10"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Betty's Brass"
            - name: RESELLER_INSTRUMENT
              value: "brass"
            - name: RESELLER_DB_NAME
              value: "brass"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Кларнеты Клайда

apiVersion: apps/v1
kind: Deployment
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
  labels:
    app: instrumentreseller
spec:
  replicas: 3
  selector:
    matchLabels:
      app: instrumentreseller
  template:
    metadata:
      labels:
        app: instrumentreseller
    spec:
      initContainers:
        - name: seeder
          image: quay.io/rhdevelopers/instrumentresellerseeder
          env:
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: SEEDER_COUNT
              value: "10"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
      containers:
        - name: instrumentreseller
          image: quay.io/rhdevelopers/instrumentreseller
          env:
            - name: RESELLER_NAME
              value: "Clyde's Clarinets"
            - name: RESELLER_INSTRUMENT
              value: "clarinet"
            - name: RESELLER_DB_NAME
              value: "clarinets"
            - name: MONGODB_URL
              valueFrom:
                secretKeyRef:
                  name: mongo-url
                  key: url
          ports:
            - containerPort: 8088

Ключевым моментом для понимания предыдущих примеров является то, что оба арендатора используют одни и те же образы контейнеров. В каждом арендаторе контейнер инициализации использует quay.io/rhdevelopers/instrumentresellerseeder образ, а основной контейнер — quay.io/rhdevelopers/instrumentreseller образ. Помните, что основной принцип множественной аренды на платформе SaaS заключается в том, что все арендаторы используют одну и ту же кодовую базу. Использование одними и теми же образами контейнеров несколькими арендаторами поддерживает этот базовый принцип.

Каждый арендатор на платформе SaaS привязывается к своей собственной базе данных. Эта база данных может существовать в кластере Kubernetes или быть внешней службой базы данных, определяемой URL-адресом. Часто информация об имени пользователя и пароле, необходимая для доступа к базе данных, будет частью URL-адреса.

Размещение информации об имени пользователя и пароле в кластере всегда является рискованным мероприятием. Лучший способ сделать информацию об имени пользователя и пароле доступной для модулей в кластере Kubernetes — использовать ресурс Kubernetes под названием Secret . Вскоре мы увидим, как наше приложение передает учетные данные в базу данных.

Заполнение данных

Как кратко упоминалось ранее, модули в развертывании используют контейнеры инициализации в дополнение к стандартным контейнерам. Контейнер инициализации — это контейнер, который запускается перед основным контейнером. В случае SaaS Instrument Reseller контейнер инициализации реализует специальную функцию демонстрационного кода: заполнение данных.

Поскольку в демонстрации мы не работаем с реальными розничными продавцами, мы используем контейнер инициализации для заполнения базы данных экземпляра клиента случайными данными, характерными для типа инструмента, продаваемого торговым посредником. Цель заполнения данных в демонстрации — предоставить некоторые начальные данные для просмотра при первом использовании приложения. Betty's Brass будет заполнен данными о духовых инструментах. Кларнеты Клайда будут заполнены данными о кларнетах. Sidney's Saxophones будет заполнен данными, относящимися к саксофонам.

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

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

Предоставление учетных данных базы данных через Kubernetes Secrets

Секреты — это ресурс Kubernetes для безопасного предоставления конфиденциальной информации другим ресурсам.

В таблице 3 показаны конфигурации, объявляющие секрет с именем mongo-urlв двух разных пространствах имен: одно для духовых инструментов Бетти, а другое — для кларнетов Клайда.

Таблица 3: Манифесты настройки секретов.

Бетти Брасс

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: bettysbrass
type: Opaque
stringData:
  url: <mongo-url-here>

Кларнеты Клайда

apiVersion: v1
kind: Secret
metadata:
  name: mongo-url
  namespace: clydesclarinets
type: Opaque
stringData:
  url: <mongo-url-here>

Обратите внимание, что каждый секрет назначается соответствующему пространству имен. Секрет, названный mongo-urlв честь Betty's Brass, назначается bettysbrassпространству имен. Секрет с тем же mongo-urlименем для кларнетов Клайда назначается clydesclarinetsпространству имен. Несмотря на то, что все секреты имеют одно и то же имя, они отличаются друг от друга, поскольку относятся к разным пространствам имен. Использование одного и того же имени среди ресурсов — одно из преимуществ использования пространств имен.

Предоставление логики приложения с помощью службы Kubernetes

После настройки секрета для каждого арендатора следующим шагом будет создание службы Kubernetes, которая предоставляет логику приложения внутренней сети Kubernetes на платформе SaaS. В таблице 4 показаны конфигурации для службы Kubernetes в Betty's Brass с использованием bettysbrassпространства имен и для Clyde's Clarinets с использованием clydesclarinetsпространства имен. Опять же, назначение каждой службы отдельному пространству имен обеспечивает изоляцию арендаторов.

Таблица 4: Манифесты настройки служб.

Бетти Брасс

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Кларнеты Клайда

apiVersion: v1
kind: Service
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  selector:
    app: instrumentreseller
  ports:
    - protocol: TCP
      port: 8088
      targetPort: 8088

Предоставление арендатора за пределами кластера с использованием маршрута OpenShift

Последним шагом настройки является создание ресурса маршрута OpenShift, который публикует доменное имя, чтобы предоставить арендатору за пределами кластера Kubernetes. Манифесты в Таблице 5 объявляют маршруты OpenShift для Betty's Brass и Clyde's Clarinets. Каждый манифест использует пространство имен своего клиента, а также другой хост.

Таблица 5: Манифесты настройки маршрутов OpenShift.

Бетти Брасс

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: bettysbrass
spec:
  host: bettysbrass.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

Кларнеты Клайда

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: instrumentreseller
  namespace: clydesclarinets
spec:
  host: clydesclarinets.com
  port:
    targetPort: 8088
  to:
    kind: Service
    name: instrumentreseller

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

Объявление набора файлов манифеста для пространства имен Kubernetes, развертывания, секрета, службы и маршрута — это первые шаги к запуску арендатора в кластере Kubernetes. После создания файлов манифеста выполните следующую команду, чтобы запустить каждого арендатора в кластере Kubernetes, где <manifest_file>это имя файла манифеста для данного арендатора:

$ kubectl apply -f <manifest_file>.yaml

Предполагая правильную конфигурацию, клиент будет запущен и работает, используя всего несколько kubectlкоманд. Однако те из нас, кто потратил много времени на работу с Kubernetes, поняли, что слова «правильная конфигурация» могут означать часы, если не дни труда. Короче говоря, подключить все сложно. Ты должен быть осторожен.

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

Процесс выпуска CI/CD

Развертывание арендаторов на платформе SaaS сопряжено с различной степенью сложности. Вы можете выполнить ручное развертывание, в котором вы создаете образы контейнеров Linux для логики приложения платформы SaaS, а затем отправляете эти образы в реестр образов контейнеров, например Quay.io.

Затем, когда необходимые образы контейнеров появятся в реестре, создайте файлы манифеста, которые вы будете использовать для реализации ресурса развертывания Kubernetes в кластере Kubernetes, в котором работает платформа SaaS. Эти файлы манифеста объявляют образы контейнеров приложений, которые будут использоваться.

Создав файлы манифеста, запустите kubectl applyкоманду, показанную в конце предыдущего раздела, чтобы создать связанный ресурс Kubernetes в кластере.

Только что описанный процесс показан на рисунке 3.

Ручное развертывание поддерживает несколько арендаторов, запустив для нас команду kubectl apply.

Рисунок 3: Развертывание вручную поддерживает несколько арендаторов, запустив для нас команду kubectl apply.

Развертывание вручную — это реальный способ работы с платформой SaaS для исследований и экспериментов. Но это нереально для сегодняшних производственных релизов, которые требуют автоматизации процесса.

Использование автоматизации особенно подходит для организаций, в которых есть несколько команд, поддерживающих платформу SaaS. Полагаться на электронную почту и устное общение между командами может быть рискованно. Автоматизация помогает сделать процесс выпуска более формальным.

Центральным элементом автоматизации выпуска является контроллер CI/CD, такой как Jenkins или OpenShift Pipelines . Контроллер CI/CD автоматизирует многие, если не все задачи, необходимые для передачи артефактов приложения из репозитория исходного кода в рабочую среду.

На рис. 4 показан пример процесса CI/CD, который обновляет платформу SaaS. Контроллер CI/CD выполняет работу по упаковке кода, готового к выпуску, в образ контейнера. Затем он помещает этот образ в реестр контейнеров и обновляет платформу SaaS новой версией образа.

Автоматизированный процесс CI/CD для многопользовательской платформы SaaS использует контроллер CI/CD на нескольких этапах.

Рис. 4. Автоматизированный процесс CI/CD для многопользовательской платформы SaaS использует контроллер CI/CD на нескольких этапах.

Пронумерованные шаги на рисунке 4:

Разработчик обновляет код и фиксирует обновленную работу в ветке dev в репозитории исходного кода.
Группа обеспечения качества (Q/A) передает код из ветки разработки в ветку Q/A и запускает модульные тесты. Если тесты пройдены, Q/A выполняет интеграционное тестирование. После успешного выполнения Q/A уведомляет группу управления выпуском о том, что новая версия кода готова для эскалации в основную ветвь репозитория исходного кода.
Управление выпуском объединяет код в основную ветку.
Управление выпуском обновляет файлы манифеста Kubernetes, добавляя тег новой версии образа контейнера, связанного с предполагаемым выпуском. Обновленные файлы фиксируются в репозитории файлов манифеста.
После успешного слияния исходного кода и файлов манифеста контроллер CI/CD уведомляется посредством автоматизации о том, что код готов к упаковке в образ контейнера и развертыванию в реестре образов контейнеров, таком как Quay.io.
Контроллер CI/CD получает обновленный код из репозитория исходного кода и создает обновленный образ контейнера из файла Containerfile , хранящегося в репозитории вместе с исходным кодом приложения.
Контроллер CI/CD отправляет обновленный образ контейнера в репозиторий образов контейнеров.
Контроллер CI/CD получает обновленные файлы манифеста для соответствующих арендаторов из репозитория файлов манифеста и выполняет kubectl applyописанную ранее команду, чтобы обновить модули, работающие в кластере Kubernetes, с помощью образа контейнера с последней версией кода приложения.

Имейте в виду, что процессы выпуска обычно различаются в разных организациях. Редко существует универсальный подход к автоматизированным выпускам с использованием контроллера CI/CD. Этот пример — один из многих возможных.

Важно понимать, что при наличии автоматизированного процесса CI/CD он выполняет большую часть детальной работы по переносу кода из ветки релиза в работающий мультиарендный кластер Kubernetes. Задачи выпуска различаются, но в целом многие детали обрабатываются с помощью сценариев автоматизации в контроллере CI/CD. Персонал по освобождению не возится с ручными задачами, если только они не сталкиваются с критической чрезвычайной ситуацией. Скорее, изменения в процессе CI/CD реализуются путем изменения сценариев автоматизации.

Kubernetes поддерживает масштабируемую многопользовательскую SaaS.

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

Логика приложения, общая для всех арендаторов, инкапсулируется в образы контейнеров, которые хранятся в реестре контейнеров. Образ загружается в кластер в соответствии с информацией о конфигурации, установленной в файле манифеста развертывания для данного арендатора. Наконец, выпуски производственного уровня автоматизируются с помощью контроллера CI/CD.

Большинство платформ SaaS предназначены для определенного набора вариантов использования. Каждый склонен быть особенным. В результате платформа будет иметь свой собственный набор сложностей и исключений, которые необходимо учитывать. Тем не менее, реализовать платформу SaaS с помощью Kubernetes намного проще, чем создавать ее с нуля. Kubernetes делает большую часть, если не все, тяжелого листинга.

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

Ссылка: https://developers.redhat.com/articles/2022/08/12/implement-multitenant-saas-kubernetes#kubernetes_supports_scalable_multitenant_saas

#sass #kubernetes

What is GEEK

Buddha Community

Как реализовать многопользовательскую SaaS в кластере Kubernetes

Christa Stehr

1602964260

50+ Useful Kubernetes Tools for 2020 - Part 2

Introduction

Last year, we provided a list of Kubernetes tools that proved so popular we have decided to curate another list of some useful additions for working with the platform—among which are many tools that we personally use here at Caylent. Check out the original tools list here in case you missed it.

According to a recent survey done by Stackrox, the dominance Kubernetes enjoys in the market continues to be reinforced, with 86% of respondents using it for container orchestration.

(State of Kubernetes and Container Security, 2020)

And as you can see below, more and more companies are jumping into containerization for their apps. If you’re among them, here are some tools to aid you going forward as Kubernetes continues its rapid growth.

(State of Kubernetes and Container Security, 2020)

#blog #tools #amazon elastic kubernetes service #application security #aws kms #botkube #caylent #cli #container monitoring #container orchestration tools #container security #containers #continuous delivery #continuous deployment #continuous integration #contour #developers #development #developments #draft #eksctl #firewall #gcp #github #harbor #helm #helm charts #helm-2to3 #helm-aws-secret-plugin #helm-docs #helm-operator-get-started #helm-secrets #iam #json #k-rail #k3s #k3sup #k8s #keel.sh #keycloak #kiali #kiam #klum #knative #krew #ksniff #kube #kube-prod-runtime #kube-ps1 #kube-scan #kube-state-metrics #kube2iam #kubeapps #kubebuilder #kubeconfig #kubectl #kubectl-aws-secrets #kubefwd #kubernetes #kubernetes command line tool #kubernetes configuration #kubernetes deployment #kubernetes in development #kubernetes in production #kubernetes ingress #kubernetes interfaces #kubernetes monitoring #kubernetes networking #kubernetes observability #kubernetes plugins #kubernetes secrets #kubernetes security #kubernetes security best practices #kubernetes security vendors #kubernetes service discovery #kubernetic #kubesec #kubeterminal #kubeval #kudo #kuma #microsoft azure key vault #mozilla sops #octant #octarine #open source #palo alto kubernetes security #permission-manager #pgp #rafay #rakess #rancher #rook #secrets operations #serverless function #service mesh #shell-operator #snyk #snyk container #sonobuoy #strongdm #tcpdump #tenkai #testing #tigera #tilt #vert.x #wireshark #yaml

Maud Rosenbaum

1601051854

Kubernetes in the Cloud: Strategies for Effective Multi Cloud Implementations

Kubernetes is a highly popular container orchestration platform. Multi cloud is a strategy that leverages cloud resources from multiple vendors. Multi cloud strategies have become popular because they help prevent vendor lock-in and enable you to leverage a wide variety of cloud resources. However, multi cloud ecosystems are notoriously difficult to configure and maintain.

This article explains how you can leverage Kubernetes to reduce multi cloud complexities and improve stability, scalability, and velocity.

Kubernetes: Your Multi Cloud Strategy

Maintaining standardized application deployments becomes more challenging as your number of applications and the technologies they are based on increase. As environments, operating systems, and dependencies differ, management and operations require more effort and extensive documentation.

In the past, teams tried to get around these difficulties by creating isolated projects in the data center. Each project, including its configurations and requirements were managed independently. This required accurately predicting performance and the number of users before deployment and taking down applications to update operating systems or applications. There were many chances for error.

Kubernetes can provide an alternative to the old method, enabling teams to deploy applications independent of the environment in containers. This eliminates the need to create resource partitions and enables teams to operate infrastructure as a unified whole.

In particular, Kubernetes makes it easier to deploy a multi cloud strategy since it enables you to abstract away service differences. With Kubernetes deployments you can work from a consistent platform and optimize services and applications according to your business needs.

The Compelling Attributes of Multi Cloud Kubernetes

Multi cloud Kubernetes can provide multiple benefits beyond a single cloud deployment. Below are some of the most notable advantages.

Stability

In addition to the built-in scalability, fault tolerance, and auto-healing features of Kubernetes, multi cloud deployments can provide service redundancy. For example, you can mirror applications or split microservices across vendors. This reduces the risk of a vendor-related outage and enables you to create failovers.

#kubernetes #multicloud-strategy #kubernetes-cluster #kubernetes-top-story #kubernetes-cluster-install #kubernetes-explained #kubernetes-infrastructure #cloud

hourly developer

1593502827

Hire Dedicated SaaS Developer

Are you looking for custom software development that works off the cloud?

SaaS is the abbreviation for the ‘Software-as-a-service’ application. SaaS development process includes design, development, unit testing, and integration. Hire Dedicated SaaS Developer from HourlyDeveloper.io, With years of experience and excellence, we offer the best quality services and create scalable, flexible, and user-friendly SaaS solutions or websites using SaaS application.

Consult with our experts- https://bit.ly/2A8L4vz

#hire dedicated saas developer #saas developer #saas development company #saas development services #saas development #saas

Майя Александровна Третьякова

1660393637