Безсерверні обчислення на основі OpenWhisk, частина 4
Ця стаття закінчує цикл перекладних нотаток про OpenWhisk від автора Priti Desai. Сьогодні розглянемо процес розгортання OpenWhisk поверх Kubernetes із виправленими командами для працездатності із актуальними версіями додатків. Також буде описано процес запуску функцій OpenWhisk з використанням Knative та TektonCD у Kubernetes з використанням середовища виконання Nodejs.
Розгортаємо OpenWhisk на Kubernetes
За кілька днів я провела експеримент із розгортання OpenWhisk у Kubernetes для створення простого та швидкого полігону для відпрацювання завдань. А оскільки я новачок у Kubernetes — гадаю, що півтора дня було витрачено на успішне розгортання. У в цьому Репозиторії є дуже зрозумілими інструкціями для розгортання OpenWhisk в Kubernetes. Тут будуть інструкції для розгортання, зроблені для Mac (я також робитиму все на Linux, тому що віддаю перевагу Linux. - прим. перекладача).
Встановлюємо пакетний менеджер asdfпісля чого автоматично виправляємо ~/.bash_profile або його аналог так:
[Знову ж таки пропускаємо цей крок на Linux. - прим. перекладача]
Ставимо minikube та kubelet:
$ asdf install kubectl 1.9.0
$ asdf global kubectl 1.9.0
$ asdf install minikube 0.25.2
$ asdf global minikube 0.25.2
[ставляться конкретні версії, але я перевіряв все на останніх доступних версіях для Linux; підозрюю, що можна сміливо ставити останній. - прим. перекладача]
На Linux цей крок робиться приблизно так (все ставиться в ~/bin, який у мене прописаний у PATH, прим. перекладача):
Встановлюємо Helm та проводимо розгортання за його допомогою:
$ brew install kubernetes-helm
$ helm init # init Helm Tiller, не нужно на Helm v3+
$ kubectl get pods -n kube-system # verify that tiller-deploy is in the running state, не нужно на helm v3+
$ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
$ helm install ./openwhisk/helm/ --namespace=openwhisk -f mycluster.yaml
[На Linux з останніми версіями (була доступна v3.0.1) трохи по-іншому. - прим. перекладача]
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
перевіряємо:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rules
Проблеми та їх вирішення
getsockopt: connection refused
$ wsk -i list
error: Unable to obtain the list of entities for namespace 'default': Get http://192.168.99.100:31001/api/v1/namespaces/_/actions?limit=0&skip=0: dial tcp 192.168.99.100:31001: getsockopt: connection refused
Перевіряємо, що контейнери в namespace openwhisk у статусі Running, т.к. іноді воно падає з помилками CreateContainerConfigError.
Invoker still initializing — Init:1/2
Процес скачування різноманітних середовищ виконання може тривати багато часу. Для прискорення можна вказати скорочений мінімальний список у файлі mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"
Контейнер з ім'ям -install-packages- вивалюється в Error
Просто наростіть таймати для liveness тестів.
Установка OpenWhisk поверх Knative
Priti Desai проводила установку поверх кластера в хмарі IBM, а також на звичайному minikube, використовуючи Knative Build та BuildTemplates. Я також буду встановлювати поверх minukube, за мотивами того, як це було описано у нашому блозі раніше – з використанням останніх версій ПЗ. Оскільки Knative Build і BuildTemplates офіційно оголошені застарілими, використовуватиму рекомендовану заміну у вигляді Tekton Pipelines. Подальша частина статті написана після прочитання документації Tekton Pipelines, але заснована на ідеях Priti. Для роботи буде потрібний доступ до деякої Docker Registry — я, як і оригінальна авторка, використовуватиму DockerHub.
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml
Застосовуємо:
$ kubectl apply -f taskrun.yaml
pipelineresource.tekton.dev/openwhisk-nodejs-runtime-git created
pipelineresource.tekton.dev/openwhisk-nodejs-helloworld-image created
taskrun.tekton.dev/openwhisk-nodejs-helloworld created
Перевірка роботи полягає у отриманні імені pod`а, перегляду його статусу. Також можна переглянути журнал виконання кожного кроку, наприклад:
$ kubectl get taskrun
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME
openwhisk-nodejs-helloworld True Succeeded 5m15s 44s
$ kubectl get pod openwhisk-nodejs-helloworld-pod-4640d3
NAME READY STATUS RESTARTS AGE
openwhisk-nodejs-helloworld-pod-4640d3 0/6 Completed 0 5m20s
$ kubectl logs openwhisk-nodejs-helloworld-pod-4640d3 -c step-git-source-openwhisk-nodejs-runtime-git-r8vhr
{"level":"info","ts":1576532931.5880227,"logger":"fallback-logger","caller":"logging/config.go:69","msg":"Fetch GitHub commit ID from kodata failed: open /var/run/ko/refs/heads/master: no such file or directory"}
{"level":"info","ts":1576532936.538926,"logger":"fallback-logger","caller":"git/git.go:81","msg":"Successfully cloned https://github.com/apache/openwhisk-runtime-nodejs.git @ master in path /workspace/runtime-git"}
{"level":"warn","ts":1576532936.5395331,"logger":"fallback-logger","caller":"git/git.go:128","msg":"Unexpected error: creating symlink: symlink /tekton/home/.ssh /root/.ssh: file exists"}
{"level":"info","ts":1576532936.8202565,"logger":"fallback-logger","caller":"git/git.go:109","msg":"Successfully initialized and updated submodules in path /workspace/runtime-git"}
Після виконання у нас в Registry з'явиться образ, який можна розгорнути за допомогою утиліти kn, призначеної для роботи з Knative сервісами, наприклад:
kn service create nodejs-helloworld --image docker.io/${DOCKER_USERNAME}/openwhisk-nodejs-helloworld
Service 'nodejs-helloworld' successfully created in namespace 'default'.
Waiting for service 'nodejs-helloworld' to become ready ... OK
Service URL:
http://nodejs-helloworld.default.example.com
У разі використання Gloo перевірити працездатність можна так: