Написать в техподдержку Позвонить нам
Админпанель Выход

Содержание статьи:

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

    В мире 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 есть пространство имен, у него нет развернутых артефактов, что означает, что просто потому, что пространство имен существует в членском кластере, не означает, что все автоматически распространяется в него без объявления в федеративном развертывании.


    Полезна ли была эта статья?