Интеграция 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
узла происходила в три этапа, которые затрагивают три варианта использования:
- Cloudify ориентированное определение.
- Врезанный Kubernetes YAML.
- Ссылка на внешний манифест 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.