Статьи

Cloudify встречает Kubernetes: улучшая интеграцию

OpenStack |  OpenStack Summit |  TOSCA Cloud Orchestration |  Микросервисы |  Kubernetes Orchestration |  OpenStack NFV |  Kubernetes Cluster

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

Microservices

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

Workflows

Эти рабочие процессы просто делегируются kubectlна master. Все они имеют параметр с именем master. masterПараметр установлен на имя узла мастера Kubernetes , что рабочий процесс должен быть запущен против. Другой шаблон заключается в предоставлении многих (но не всех) параметров, которые kubectlпринимаются, но с использованием overridesсвойства как перехвата всех. Эти рабочие процессы предоставляются в качестве примеров. Следует понимать, что любой фактический план производства будет реализовывать только рабочие процессы, относящиеся к цели проекта, которые могут включать или не включать в себя следующее и, возможно, содержать другие.

Название рабочего процесса | Описание —— | ——- Кубе запустить | kubectl run эквивалент куба разоблачить | kubectl run эквивалентная остановкаkubectl stop кубе  эквивалентный куб удалить | kubectl delete эквивалент

Рабочие процессы реализованы в   файле workflows.py . Пример реализации:

@workflow
def kube_run(**kwargs):
  setfabenv(kwargs)
  optstr=buildopts(kwargs,{"dry_run":"dry-run"},{"port":"not _val_ == -1"},["dry_run"],['name','master'])
  ctx.logger.info("Running: {}".format(optstr))
  run("./kubectl -s http://localhost:8080 run "+" "+kwargs['name']+optstr)

Микросервисный узел

Рабочие процессы обеспечивают удобный внешний интерфейс для управления кластером Kubernetes, делая Kubernetes доступным через CLI Cloudify и API REST. Это хорошо, но не дает никакой возможности интеграции TOSCA. TOSCA  оркестровка определяется это узлы и отношения, поэтому microservice нуждается в абстракции узел из его собственной.

Разработка  cloudify.kubernetes.Microservice узла происходила в три этапа, которые затрагивают три варианта использования:

  1. Cloudify ориентированное определение.
  2. Врезанный Kubernetes YAML.
  3. Ссылка на внешний манифест Kubernetes, с переопределениями.

Следует отметить, что этот узел требует использования для получения  cloudify.kubernetes.relationships.connected_to_masterинформации о соединении. Кроме того, я добавил  install (по умолчанию  true) и  install_docker (по умолчанию  false) свойства к cloudify.kubernetes.Master узлу, чтобы включить установку докера и просто подключиться к работающему кластеру Kubernetes, а не устанавливать его.

Cloudify ориентированное определение

Этот режим работы абстрагирует API-интерфейс Kubenetes и определяет свойства, которые автоматизируют создание сервисов, используя kubectl  run и  expose команды очень специфическим способом. Соответствующие свойства: Недвижимость | Описание ————— | ——————— имя | название сервиса image | имя порта изображения | порт прослушивания службы целевой порт | порт контейнера (по умолчанию: порт) протокол | TCP / UDP (по умолчанию TCP) реплики | количество реплик (по умолчанию 1) запускает переопределения | json переопределяет для kubectl «run» expose_overrides | JSON переопределяет для kubectl «разоблачить»

Функция плагина, которая реализует этот вариант использования, находится в   файле tasks.py .

Kubernetes Embedded YAML

Вместо того, чтобы просто запускать команды с использованием kubectlпараметров, службы могут (должны быть) настраиваться с использованием собственных манифестов YAML Kubernetes. Второй режим работы позволяет встраивать нативный манифест YAML Kubernetes непосредственно в проект Cloudify. Пример:

nodecellar:
  type: cloudify.kubernetes.Microservice
  properties:
    config:
      apiVersion: v1
      kind: Pod
      metadata:
        name: nodecellar
      spec:
        restartPolicy: Never
        containers:
        - name: nodecellar
          image: dfilppi/nodecellar:v1
          workingDir: /root/nodecellar-master
          command: ["../node/bin/node","server.js"]
          ports:
          - containerPort: 3000
            hostPort: 3000
          hostIP: { get_property: [ master, ip]}
          env:
          - name: MONGO_HOST
            value: { get_input: host_ip }
          - name: MONGO_PORT
            value: { concat: ["", { get_property: [ mongod1 , port ]}] }

Внедряя YAML непосредственно в проект, легко использовать  встроенные функции,  чтобы заполнить его другими значениями проекта. Чтобы использовать встроенный YAML, используется только configсвойство. Все подчиненные операторы YAML экспортируются (после замены) в стандартный манифест YAML, который подается в kubectl createоператор на главном узле.

Файл Kubernetes с переопределениями

Этот режим основан на представлении, что пользователи могут захотеть сохранить свои существующие манифесты Kubernetes, но при этом использовать их в проекте Cloudify. Для гибридной облачной среды это имеет смысл в динамической оркестровке, только если существующие значения в манифесте могут быть переопределены, чтобы отразить значения в проекте. Например, если мы представляем размещенный на веб-уровне Kubenetes веб-уровень в сочетании с не-Kubernetes размещенным бэкэндом, мы бы хотели указать хост и порт серверной службы без изменения файла манифеста Kubernetes. Переопределения позволяют вам сделать это. Пример конфигурации:

  nodecellar:
    type: cloudify.kubernetes.Microservice
    properties:
      config_path: service.yaml
      config_overrides:
        - { concat: ["['spec']['containers'][0]['ports'][0]['hostIP']=","'",{ get_property: [ master, ip]},"'"] }
        - { concat: ["['spec']['containers'][0]['env'][0]['value']=","'",{ get_input: host_ip},"'"] }
        - { concat: ["['spec']['containers'][0]['env'][1]['value']=","'",{ get_property: [ mongod1, port]},"'"] }
    relationships:
      - type: cloudify.kubernetes.relationships.connected_to_master
        target: master

Обратите внимание, что переопределения немного многословны, чтобы приспособиться к кавычкам. Основная потребность в использовании встроенной concatфункции заключается в добавлении необходимых кавычек в строковые значения в манифесте Kubernetes. Узел, который фактически заменяет собой код Python, ссылаясь на документ YAML в терминах вложенных кодов, которые service.yamlв этом случае являются результатом анализа целевого файла ( ), стандартным Pythonyaml.

Вывод

Код находится на том же  месте  версии 1.5. Эта итерация превратила первые набеги в достойную интеграцию Kubernetes, и многое еще предстоит сделать. Комментарии приветствуются.

бонус

Приходите к нашим собственным Сивану Барзили и Рану Зиву, которые представят демонстрацию в OpneStack Tokyo в Expo Hall (Marketplace Theatre) на тему  «Как создать облачные собственные микросервисы с гибридной рабочей нагрузкой на OpenStack»  в 16:00 во вторник, 27 октября.

Чтобы глубже погрузиться в Cloudify и Kubernetes в гибридной среде на OpenStack, посмотрите видео ниже:

Эта статья первоначально появилась в блоге Cloudify DeWayne Flippi.