Привет, меня зовут Иван, и сегодня я расскажу как управлять приложением Tarantool Cartridge в кластере Kubernetes при помощи Tarantool Operator. Мы пройдем полный цикл от разработки до эксплуатации:

Подготовим инструменты
Создадим тестовое приложение
Упакуем его в Docker
Установим приложение в kubernetes-кластер
Масштабируем приложение
Обновим версию приложения
Разберем возможные проблемы
Кастомизируем наш кластер
Разберемся с установкой в закрытом контуре

Устанавливаем инструменты

Нам потребуется:

cartridge-cli — утилита для работы с cartridge-приложениями. Нам нужна версии 2.3.0 или выше.
Инструкция по установке здесь. Если установка прошла успешно, в системе появится утилита cartridge.
```
$ cartridge version
---
Tarantool Cartridge CLI v2.3.0 linux/amd64 commit: 06a5dad
```

kubectl — инструмент для управления кластерами kubernetes. Нам потребуется релиз версии 1.16 или выше.
Инструкцию по установке можно найти тут.

$ kubectl version --client
---
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z",     GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

helm — пакетный менеджер для приложений Kubernetes.
Нам понадобится релиз версии 3.3.x. Инструкцию по установке можно найти здесь.
```
$ helm version
---
version.BuildInfo{Version:"v3.3.1", GitCommit:"249e5215cde0c3fa72e27eb7a30e8d55c9696144", GitTreeState:"clean", GoVersion:"go1.14.7"}
```
minikube — инструмент для создания локального кластера Kubernetes. Нам нужен версии 1.12 и выше. Как установить можно прочитать тут.
```
$ minikube version
---
minikube version: v1.12.3
commit: 2243b4b97c131e3244c5f014faedca0d846599f5-dirty
```
kind (необязательно) — еще один инструмент для создания локального кластера. Можно использовать вместо minikube. Инструкция по установке здесь.
```
$ kind version
kind v0.9.0 go1.15.2 linux/amd64
```

Создаем приложение

Создадим приложение test-app утилитой cartridge-cli:

$ cartridge create --name test-app
---
   • Create application test-app
   • Generate application files
   • Initialize application git repository
   • Application "test-app" created successfully

В директории test-app получим приложение, созданное из шаблона.

$ ls test-app
---
...

instances.yaml
test-app-scm-1.rockspec
...

Приложение полностью функционально и умеет отвечать на HTTP GET запрос /hello.

NOTE проверьте версию cartridge в test-app-scm-1.rockspec:

dependencies = {
    ...
    'cartridge == 2.3.0-1',
    ...
}

Версия cartridge должна быть >= 2.3.0. С этой версии cartridge ожидает, когда инстанс станет доступен по своему DNS-адресу при запуске, это нужно для корректной работы в Kubernetes. Для версий ниже 2.3.0 приложение нужно дорабатывать и реализовывать ожидание самостоятельно. Пример, как это сделать, есть по ссылке.

Собираем приложение

Соберем docker-образ с помощью cartridge-cli:

$ cartridge pack docker --tag vanyarock01/test-app:0.1.0-0-g68f6117
---
...
Running in 0ffbd57a0edf
Removing intermediate container 0ffbd57a0edf
 ---> aceef7a3be63
 ---> aceef7a3be63
Successfully built aceef7a3be63
Successfully tagged test-app:0.1.0-0-g68f6117
   • Created result image test-app:0.1.0-0-g68f6117
   • Application was successfully packed

Загружаем образ в registry:

$ docker push vanyarock01/test-app:0.1.0-0-g68f6117
---
The push refers to repository [docker.io/vanyarock01/test-app]
b327b35afe0a: Pushed 
de30ed3f758d: Pushed 
3c8808fbd85d: Pushed 
291f6e44771a: Pushed 
0.1.0-0-g275baa8: digest: sha256:5b3b92a615b34c7f132e72e2d61f692cf2091ca28be27bbbfed98106398d1c19 size: 1160

NOTE Вы должны быть авторизированы через docker login и иметь права доступа к целевому registry.

Создаем кластер Kubernetes

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

Minikube

Создадим кластер Kubernetes версии 1.16.4 с объемом выделенного RAM 4Gb (рекомендуемые параметры).

$ minikube start --kubernetes-version v1.16.4 --memory 4096
---
  minikube v1.12.3 on Ubuntu 18.10
  Automatically selected the docker driver. Other choices: kvm2, virtualbox
  Starting control plane node minikube in cluster minikube
  Creating docker container (CPUs=2, Memory=4096MB) ...
  Preparing Kubernetes v1.16.4 on Docker 19.03.8 ...
  Verifying Kubernetes components...
  Enabled addons: default-storageclass, storage-provisioner
  Done! kubectl is now configured to use "minikube"

Убедимся, что кластер в порядке, дождавшись статуса Ready.

$ kubectl get nodes
---
NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    master   21m   v1.16.4

Kind — альтернатива minikube

$ kind create cluster  --image kindest/node:v1.16.4
---
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.16.4)  
 ✓ Preparing nodes   
 ✓ Writing configuration  
 ✓ Starting control-plane ️ 
 ✓ Installing CNI  
 ✓ Installing StorageClass  
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Not sure what to do next?   Check out https://kind.sigs.k8s.io/docs/user/quick-start/

Проверим статус кластера.

$ kubectl get nodes
---
NAME                 STATUS   ROLES    AGE   VERSION
kind-control-plane   Ready    master   48s   v1.16.4

Запускаем приложение

Устанавливать оператор и разворачивать кластер будем через helm. Чарты опубликованы в нашем репозитории, добавим его:

$ helm repo add tarantool https://tarantool.github.io/tarantool-operator

В репозитории доступно два чарта:

$ helm search repo tarantool
---
NAME                            CHART VERSION   APP VERSION DESCRIPTION                  
tarantool/tarantool-operator    0.0.8           1.16.0      kubernetes tarantool operator
tarantool/cartridge             0.0.8           1.0         A Helm chart for tarantool

Чарт tarantool/tarantool-operator устанавливает и настраивает оператор, который управляет кластерами tarantool cartridge.

Чарт tarantool/cartridge — это шаблон для создания кластеров tarantool cartridge. С настройками по умолчанию этот чарт развернет example-приложение из 3 инстансов. Чарт работает только в паре с tarantool-operator'ом.

NOTE Используйте одинаковые версии чартов. Если ставите чарт оператора версии 0.0.8, ставьте cartridge чарт версии 0.0.8.

Установим tarantool-operator в пространство имен tarantool.

$ helm install tarantool-operator tarantool/tarantool-operator --namespace tarantool --create-namespace --version 0.0.8
---
NAME: tarantool-operator
LAST DEPLOYED: Sun Sep 13 23:29:28 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 1
TEST SUITE: None

Дождемся, пока под с оператором перейдет в рабочее состояние:

$ kubectl get pods -n tarantool
---
NAME                                 READY   STATUS    RESTARTS   AGE
tarantool-operator-xxx-yyy   0/1     Pending   0          3s

А пока под с оператором поднимается, давайте поговорим о том, что вообще такое Tarantool Operator и зачем он нужен.

Tarantool Operator

Это kubernetes-приложение, которое умеет управлять ресурсами Tarantool Cartridge.

Что это означает для нас?

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

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

Разобраться с операторами могут помочь эти ссылки:

Тем временем, наш под перешел в состояние Running. Следующим шагом будет установка приложения при помощи helm чарта tarantool/cartridge, для которого нужно подготовить описание системы.

Поднимаем кластер Tarantool Cartridge

Подняли кластер, установили оператор, можем переходить к запуску приложения.

Приложение будем разворачивать с помощью чарта tarantool/cartridge. Это шаблон, запустите его с настройками по умолчанию и получите наше example-приложение из 3 инстансов. Определите свои настройки и сможете развернуть любое приложение на Tarantool Cartrdige, любой топологии.

Зададим вот такие настройки в файле values.yaml. В комментариях есть пояснения, что они означают:

# Название среды и название кластера.
ClusterEnv: dev
ClusterName: test-app

# Docker-образ, из которого создаем контейнеры
image:
  repository: vanyarock01/test-app
  tag: 0.1.0-0-g68f6117
  pullPolicy: IfNotPresent

# Топология кластера, включающая в себя описание количества
# и характеристик репликасетов. Описывается в разделе RoleConfig

# Допустим, мы хотим создать кластер, содержащий два типа репликасетов:
# routers и storages
RoleConfig:
  - RoleName: routers  # Название типа репликасетов
    ReplicaCount: 1    # Количество реплик в репликасете
    ReplicaSetCount: 1 # Количество репликасетов у данной роли
    DiskSize: 1Gi      # Размер персистентного хранилища
    CPUallocation: 0.1 # Часть vCPUs выделенного под каждый контейнер
    MemtxMemoryMB: 256 # Количество RAM выделяемого под каждый контейнер
    RolesToAssign:     # Роли cartridge
      - app.roles.custom
      - vshard-router

  - RoleName: storages
    ReplicaCount: 2
    ReplicaSetCount: 1
    DiskSize: 1Gi
    CPUallocation: 0.1
    MemtxMemoryMB: 256
    RolesToAssign:
      - app.roles.custom
      - vshard-storage

На основе такой конфигурации получим:

Кластер Tarantool Cartridge, который называется test-app.
В кластере два репликасета: routers и storages.
В репликасете routers один инстанс Tarantool'a.
В репликасете storages два инстанса Tarantool'a — мастер и реплика.
В каждом репликасете запустятся роли, которые перечислены в параметре RolesToAssign.

Установим приложение:

$ helm install -f values.yaml test-app tarantool/cartridge --namespace tarantool --version 0.0.8
---
NAME: test-app
LAST DEPLOYED: Mon Sep 14 10:46:50 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 1

Подождем, когда все поды запустятся:

kubectl -n tarantool get pods
NAME                         READY   STATUS    RESTARTS   AGE
routers-0-0                  0/1     Running   0          10s
storages-0-0                 1/1     Running   0          10s
...
tarantool-operator-xxx-yyy   1/1     Running   0          2m

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

kubectl port-forward -n tarantool routers-0-0 8081:8081

Теперь webUI кластера Tarantool Cartridge доступен по адресу http://localhost:8081.

Управляем кластером

Добавляем новую реплику

Чтобы увеличить количество реплик в репликасете:

Меняем конфигурацию в файле values.yaml.
Обновляем приложение: helm upgrade.

За количество инстансов в репликасете отвечает параметр ReplicaCount. Выставим его равным 3 для репликасета storages:

- RoleName: storages
  ReplicaCount: 3
  ReplicaSetCount: 1
  DiskSize: 1Gi
  CPUallocation: 0.10
  MemtxMemoryMB: 256
  RolesToAssign: custom.vshard-storage

Обновим приложение:

$ helm upgrade -f values.yaml test-app tarantool/cartridge --namespace tarantool --version 0.0.8
---
Release "test-app" has been upgraded. Happy Helming!
NAME: test-app
LAST DEPLOYED: Tue Sep 15 10:35:55 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 2

Ожидаем, когда все новые поды перейдут в состояние Running и смотрим в webUI cartridge.

В репликасете storages 3 инстанса, 1 мастер и 2 реплики.

Добавляем шард (репликасет)

За количество репликасетов одного типа отвечает параметр ReplicaSetCount.

Увеличим количество репликасетов routers до 2:

- RoleName: routers
  ReplicaCount: 1
  ReplicaSetCount: 2
  DiskSize: 1Gi
  CPUallocation: 0.10
  MemtxMemoryMB: 256
  RolesToAssign: custom.vshard-router

Обновляем приложение:

helm upgrade -f values.yaml test-app tarantool/cartridge --namespace tarantool
---
Release "test-app" has been upgraded. Happy Helming!
NAME: test-app
LAST DEPLOYED: Tue Sep 15 10:37:57 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 3

Подождем, когда новый под запустится:

Обновляем версию приложения

Сейчас логика приложения состоит из одного эндпоинта /hello, который в ответ на HTTP GET запрос возвращает строку "Hello world!".

Чтобы проверить, прокинем порты до нужного узла:

$ kubectl port-forward -n tarantool routers-0-0 8081:8081
---
Forwarding from 127.0.0.1:8081 -> 8081
Forwarding from [::1]:8081 -> 8081

И выполним запрос:

$ curl http://localhost:8081/hello
---
Hello world!

Добавим еще один эндпоинт, который будет возвращать строку "Hello world, new version of the app!". Для этого в функции init, в роли app/roles/custom.lua добавим еще один httpd:route:

local function init(opts) -- luacheck: no unused args
    ...

    -- новый эндпоинт
    httpd:route({method = 'GET', path = '/v2/hello'}, function()
        return {body = 'Hello world, new version of the app!'}
    end)

    ...
end

Собираем приложение с новой версией:

$ cartridge pack docker --tag vanyarock01/test-app:0.1.0-1-g4577716

---

...
Successfully tagged vanyarock01/test-app:0.1.0-1-g4577716
   • Created result image vanyarock01/test-app:0.1.0-1-g4577716
   • Application was successfully packed

Загружаем новую версию образа в docker registry:

$ docker push vanyarock01/test-app:0.1.0-1-g4577716

Указываем новый image.tag в values.yaml:

image:
  repository: vanyarock01/test-app
  tag: 0.1.0-1-g4577716
  pullPolicy: IfNotPresent

Обновляем приложение в Kubernetes:

$ helm upgrade -f values.yaml test-app tarantool/cartridge --namespace tarantool --version 0.0.8
---
Release "test-app" has been upgraded. Happy Helming!
NAME: test-app
LAST DEPLOYED: Tue Sep 15 10:45:53 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 4

Tarantool Operator использует политику обновления OnDelete. Это значит, что обновление дошло до кластера, но чтобы поды обновили образ, нужно их жестко "перезапустить":

$ kubectl delete pods -l tarantool.io/cluster-id=test-app -n tarantool
---
pod "routers-0-0" deleted
pod "routers-1-0" deleted
pod "storages-0-0" deleted
pod "storages-0-1" deleted
pod "storages-0-2" deleted

Подождем, когда поды запустятся заново и проверим обновление:

$ kubectl port-forward -n tarantool routers-0-0 8081:8081
---
Forwarding from 127.0.0.1:8081 -> 8081
Forwarding from [::1]:8081 -> 8081
...

curl http://localhost:8081/v2/hello
---
Hello world, new version of the app!

Запуск нескольких кластеров Tarantool Cartridge в разных namespace

Tarantool Operator может управлять кластерами Tarantool Cartridge только в своем namespace. Поэтому, чтобы развернуть несколько кластеров Cartridge в разных namespace'ах, понадобится развернуть оператор в каждом из них.

Чтобы установить оператор в несколько namespace'ов, достаточно указать нужный namespace при установке:

$ helm install tarantool-operator tarantool/tarantool-operator --namespace NS_1 --create-namespace --version 0.0.8

$ helm install tarantool-operator tarantool/tarantool-operator --namespace NS_2 --create-namespace --version 0.0.8

Эти две команды установят по оператору в namespace'ы NS_1 и NS_2. Дальше в каждом из них можно запускать кластер Tarantool Cartridge.

$ helm install -f values.yaml cartridge tarantool/cartridge --namespace NS_1 --version 0.0.8

$ helm install -f values.yaml cartridge tarantool/cartridge --namespace NS_2 --version 0.0.8

Получим два namespace, в каждом запущен оператор и кластер Tarantool Cartridge. Каждый оператор управляет своим кластером, кластеры не пересекаются.

Удаляем кластер

Для того чтобы удалить Cartridge-приложение выполним:

$ helm uninstall test-app --namespace tarantool
---
release "test-app" uninstalled

Через некоторое время все поды нашего приложения исчезнут, среди подов в неймспейсе tarantool останется только operator.

$ kubectl -n tarantool get pods
---
NAME                                  READY   STATUS    RESTARTS   AGE
tarantool-operator-7dc948c89b-pb9r4   1/1     Running   0          9m45s

Если необходимо удалить и Tarantool Operator выполним:

$ helm uninstall tarantool-operator --namespace tarantool
---
release "tarantool-operator" uninstalled

NOTE helm uinstall не удаляет персистентные хранилища (Persistent Volumes). Чтобы их удалить, нужно дополнительно выполнить:

$ kubectl delete pvc --all -n tarantool
---
persistentvolumeclaim "www-routers-0-0" deleted
persistentvolumeclaim "www-routers-1-0" deleted
persistentvolumeclaim "www-storages-0-0" deleted

Troubleshooting

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

Рассмотрим признаки, возможные причины и решения:

Нехватка CPU

После выполнения helm install/upgrade поды остаются в состоянии Pending.

Выглядит так:

$ kubectl get pods -n tarantool
---
NAME                                  READY   STATUS    RESTARTS   AGE
routers-0-0                           0/1     Pending   0          20m
routers-1-0                           0/1     Pending   0          20m
storages-0-0                          0/1     Pending   0          20m
tarantool-operator-5bd6d895c4-xhjsg   1/1     Running   0          23m

Посмотрим на события одного из подвисших подов.

$ kubectl -n tarantool describe pods routers-0-0
---
Events:
  Type     Reason             Age                    From                Message
  ----     ------             ----                   ----                -------
  Warning  FailedScheduling   34m                    default-scheduler   0/2 nodes are available: 2 Insufficient cpu.
  Warning  FailedScheduling   34m                    default-scheduler   0/2 nodes are available: 2 Insufficient cpu.
  Normal   NotTriggerScaleUp  3m33s (x175 over 34m)  cluster-autoscaler  pod didn't trigger scale-up (it wouldn't fit if a new node is added):

Становится понятно, что нам не хватает CPU. В первую очередь стоит обратить внимание на конфигурацию кластера, которая находится в файле values.yaml, а именно на параметр CPUallocation у репликасетов. Уменьшив его можно добиться положительных результатов.

Нехватка места на дисках

После выполнения helm install/upgrade поды остаются в состоянии ContainerCreating.
Снова посмотрим в kubectl -n tarantool describe pods routers-0-0:

Events:
  Type     Reason                  Age                  From                                              Message
  ----     ------                  ----                 ----                                              -------
  Warning  FailedScheduling        7m44s                default-scheduler                                 pod has unbound immediate PersistentVolumeClaims
  Warning  FailedScheduling        7m44s                default-scheduler                                 pod has unbound immediate PersistentVolumeClaims
  Normal   Scheduled               7m42s                default-scheduler                                 Successfully assigned tarantool/routers-0-0 to kubernetes-cluster-3010-default-group-0
  Normal   SuccessfulAttachVolume  7m37s                attachdetach-controller                           AttachVolume.Attach succeeded for     volume "pvc-e0d3f30a-7dcc-4a67-a69d-4670dc77d556"
  Warning  FailedMount             67s (x9 over 7m5s)   kubelet, kubernetes-cluster-3010-default-group-0  MountVolume.MountDevice failed for volume "pvc-e0d3f30a-7dcc-4a67-a69d-4670dc77d556" : rpc error: code = Internal desc = Unable to find Device path for volume
  Warning  FailedMount             66s (x3 over 5m38s)  kubelet, kubernetes-cluster-3010-default-group-0  Unable to attach or mount volumes: unmounted volumes=[www], unattached volumes=[www default-token-jrz94]: timed out waiting for the condition

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

Кастомизация

Для большинства кейсов вам хватит helm чарта tarantool/cartridge. Но если требуется кастомизация, можно продолжить использовать чарт, внеся в него собственные правки, либо полностью отказаться от helm в пользу deployment.yaml и kubectl.

Sidecar-контейнеры

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

Подробнее узнать про данный архитектурный паттерн можно здесь.

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

Для этого придется изменить чарт tarantool/cartridge. Найти его можно здесь. Добавим новый контейнер с nginx в шаблон ReplicasetTemplate, который можно найти в файле templates/deployment.yaml.

containers:
- name: pim-storage
  image: "{{ $.Values.image.repository }}:{{ $.Values.image.tag }}"
  ...
- name: nginx-container
  image: nginx
  volumeMounts:
    - name: www
      mountPath: "/data"

NOTE важно описывать дополнительные контейнеры строго после контейнера pim-storage. Иначе при обновлении версии приложения могут возникнуть проблемы, так как Tarantool Operator по умолчанию считает контейнером приложения первый из данного списка.

Далее выполним установку, указав путь до директории с кастомизированным чартом:

$ helm install -f values.yaml test-app tarantool-operator/examples/kv/helm-chart/ --namespace tarantool
---
NAME: test-app
LAST DEPLOYED: Wed Sep 30 11:25:12 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 1

Успешность настройки и установки можно проверить взглянув на список подов.

$ kubectl -n tarantool get pods
---
NAME                                  READY   STATUS    RESTARTS   AGE
routers-0-0                           2/2     Running   0          113s
routers-1-0                           2/2     Running   0          113s
storages-0-0                          2/2     Running   0          113s
tarantool-operator-7dc948c89b-fnq28   1/1     Running   0          30m

READY 2/2 означает, что внутри пода готово 2 контейнера.

Установка в закрытом контуре

В enterprise-компаниях обычно доступ в дикий интернет жестко ограничен целях безопастности.

Доставка инструментов

Для того чтобы выполнять описанные выше процедуры с кластером в закрытом контуре, необходимо принести в этот контур helm чарты tarantool-operator и cartridge, docker-образ tarantool-operator и образ вашего приложения.

Скачать чарты можно по следующим ссылкам:

Далее необходимо запаковать докер образ tarantool-operator. Сперва заберем нужную версию из docker.hub:

$ docker pull tarantool/tarantool-operator:0.0.8
---
0.0.8: Pulling from tarantool/tarantool-operator
Digest: sha256:e3b46c2a0231bd09a8cdc6c86eac2975211b2c597608bdd1e8510ee0054a9854
Status: Downloaded newer image for tarantool/tarantool-operator:0.0.8
docker.io/tarantool/tarantool-operator:0.0.8

И упакуем в архив:

$ docker save tarantool/tarantool-operator:0.0.8 | gzip > tarantool-operator-0.0.8.tar.gz

После доставки архива с контейнером в целевой контур необходимо загрузить образ в локальный docker:

$ docker load < tarantool-operator-0.0.8.tar.gz
---
Loaded image: tarantool/tarantool-operator:0.0.8

Осталось разместить образ в доступном из контура docker registry. Я буду использовать поднятый на localhost:5000 и доступный для Kubernetes docker registry.

$ docker tag tarantool/tarantool-operator:0.0.8 localhost:5000/tarantool-operator:0.0.8
$ docker push localhost:5000/tarantool-operator:0.0.8
---
The push refers to repository [localhost:5000/tarantool-operator]
9ace38e69165: Pushed 
e38e5e822ecf: Pushed 
b6533bbd0bc5: Pushed 
eb29745b8228: Pushed 
0.0.8: digest: sha256:c0cfdc769f545ab106115ef5ee8d924778aea78b08454fbfed4a5b8e42afa5aa size: 1155

NOTE в случае, если сборка приложения в docker-образ осуществляется вне контура, доставить его туда можно способом описанным выше.

Установка Tarantool Operator

Опишем кастомную конфигурацию в файле operator_values.yaml, указав репозиторий, в который мы положили образ на предыдущем шаге.

image:
  repository: localhost:5000/tarantool-operator
  tag: 0.0.8
  pullPolicy: IfNotPresent

И выполним установку, указав путь до чарта:

$ helm install tarantool-operator -f operator_values.yaml ./tarantool-operator-0.0.8.tgz --namespace tarantool --create-namespace
---
NAME: tarantool-operator
LAST DEPLOYED: Tue Dec  1 14:53:47 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 1
TEST SUITE: None

Проверим, что запуск оператора прошел успешно

$ kubectl -n tarantool get pods
---
NAME                                  READY   STATUS    RESTARTS   AGE
tarantool-operator-7c867cb467-vthf4   1/1     Running   0          7s

Установка Tarantool Cartridge приложения

Образ приложения я заранее разместил в своем локальном docker registry. Осталось лишь подкорректировать values.yaml указав доступный в нашем контуре репозиторий.

...
image:
  repository: localhost:5000/test-app
  tag: 0.1.0-0-g68f6117
  pullPolicy: IfNotPresent
...

Полную конфигурацию values.yaml можно найти в инструкции по установке Tarantool Cartridge приложения описанной в статье ранее.

И выполнить установку указав путь до чарта:

$ helm install -f values.yaml test-app ./cartridge-
.tgz --namespace tarantool
---
NAME: test-app
LAST DEPLOYED: Tue Dec  1 15:52:41 2020
NAMESPACE: tarantool
STATUS: deployed
REVISION: 1

Посмотрим на поды, чтобы убедиться в успешности установки:

$ kubectl -n tarantool get pods
---
NAME                                  READY   STATUS    RESTARTS   AGE
routers-0-0                           1/1     Running   0          8m30s
storages-0-0                          1/1     Running   0          8m30s
storages-1-0                          1/1     Running   0          8m30s
tarantool-operator-7c867cb467-vthf4   1/1     Running   0          67m

Ссылки

Скачать Tarantool можно на официальном сайте.
Получить помощь можно в Telegram-чате.
Почитать, как на Tarantool сделать распределенный кэш в банке можно тут.

Руководство по использованию Tarantool Cartridge в Kubernetes