VK Cloud Solutions logo

Федерация кластеров

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

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

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

Kubernetes Federation расширяет некоторые атрибуты мульти-кластера, но не охватывает все мульти-кластерные сценарии. Когда несколько кластеров объединены, они фактически совместно используют части своей конфигурации, которая управляется так называемым кластером узлов и отправляется кластерам-членам федерации. Преимущество совместного использования высокоуровневых частей конфигурации заключается в том, что любые ресурсы, настроенные для использования преимуществ федерации, будут рассматривать все кластеры-члены как единый распределенный кластер под контролем кластера хоста.

Kubernetes Federation

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

Базовая архитектура Kubernetes Federation

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

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

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

Так, например, федерация Kubernetes настроена с кластерами из трех членов. Первый работает в облаке Google в Канаде, второй - в Azure в Сингапуре, а третий - в облаке IBM в Великобритании. И есть возможность развернуть приложение A в пространстве имен test-app1 в gke-canada и ibm-uk, в то время как приложение B будет развернуто в gke-canada и aks-singapore.

Более подробную информацию об архитектуре Kubefed можно найти на GitHub проекта.

Настройка Федерации Kubernetes

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

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system
EOF


helm init --service-account tiller

Далее нужно установить плоскость управления KubeFed через Helm.

helm repo add kubefed-charts \
  https://raw.githubusercontent.com/kubernetes-sigs/kubefed/master/charts
helm install kubefed-charts/kubefed --name kubefed --version= \
  --namespace kube-federation-system

Процесс настройки в Федерации Kubernetes

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

Первые две части головоломки, которые нужны, - это центральное пространство имен, созданное в хост-кластере, чтобы содержать объединенные ресурсы развертывания, и объединенное пространство имен с тем же именем в каждом кластере, которое будет содержать развернутые ресурсы:

apiVersion: v1
kind: Namespace
metadata:
  name: nginx-test
---
apiVersion: types.kubefed.io/v1beta1
kind: FederatedNamespace
metadata:
  name: nginx-test
  namespace: nginx-test
spec:
  placement:
    clusters:
    - name: cluster1
    - name: cluster2
    - name: cluster3

Функциональная часть головоломки - это фактическое федеративное развертывание nginx, которое создаст четыре реплики, которые будут равномерно распределены по указанным кластерам и будут использовать пространство имен nginx-test на всех кластерах:

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: nginx-test
  namespace: nginx-test
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 4
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx
            name: nginx
  placement:
    clusters:
    - name: cluster1
    - name: cluster3

На схеме ниже показано, как конфигурация распространяется по активным кластерам, которые объединены. Нужно заметить, что конфигурация не попала в исключенный из нее кластер. Хотя у cluster2 есть пространство имен, у него нет развернутых артефактов, что означает, что просто потому, что пространство имен существует в членском кластере, не означает, что все автоматически распространяется в него без объявления в федеративном развертывании.