Aquest article finalitza la sèrie de notes traduïdes sobre OpenWhisk de l'autor Priti Desai. Avui veurem el procés de desplegament d'OpenWhisk a Kubernetes amb ordres corregides per treballar amb les versions actuals d'aplicacions. També cobrirà el procés d'execució de funcions d'OpenWhisk mitjançant Knative i TektonCD a Kubernetes mitjançant el temps d'execució de Nodejs.
Desplegant OpenWhisk a Kubernetes
Al llarg d'uns quants dies, vaig experimentar amb la implementació d'OpenWhisk a Kubernetes per crear un camp de proves senzill i ràpid. I com que sóc nou a Kubernetes, crec que es va dedicar un dia i mig a un desplegament reeixit. EN això Els repositoris tenen instruccions molt clares per desplegar OpenWhisk a Kubernetes. Aquí teniu les instruccions de desplegament fetes per a Mac (També ho faré tot a Linux perquè prefereixo Linux. —aprox. traductor).
Instal·lació del gestor de paquets asdf, després del qual corregim automàticament ~/.bash_profile o el seu equivalent així:
[De nou, ometeu aquest pas a Linux. —aprox. traductor]
Instal·leu minikube i 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
[s'instal·len versions específiques, però ho vaig comprovar tot a les darreres versions disponibles per a Linux; Sospito que podeu instal·lar l'última de manera segura. —aprox. traductor]
A Linux, aquest pas es fa una cosa així (tot es posa a ~/bin, que apareix a la meva PATH, nota del traductor):
$ 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
[A Linux amb les últimes versions (la v3.0.1 estava disponible) serà una mica diferent. —aprox. traductor]
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwP
Comprovem:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rules
Problemes i Solucions
getsockopt: connexió rebutjada
$ 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
Comprovant que els contenidors es troben a l'espai de noms openwhisk en estat Running, perquè de vegades s'estavella amb errors CreateContainerConfigError.
L'invocador encara s'està inicialitzant — Init:1/2
El procés de descàrrega de diversos entorns d'execució pot trigar molt de temps. Per accelerar les coses, podeu especificar una llista mínima escurçada al fitxer mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"
Contenidor amb nom -instal·lar-paquets- bloqueja a Error
Només augmenta els temps morts per a les proves de vivacitat.
Instal·lant OpenWhisk sobre Knative
Priti Desai va realitzar la instal·lació a sobre d'un clúster al núvol d'IBM, així com en un minikube normal, utilitzant Knative Build i BuildTemplates. També instal·laré a sobre de minukube, segons com es va descriure al nostre bloc anteriorment, utilitzant les últimes versions de programari. Com que Knative Build i BuildTemplates han quedat oficialment obsolets, utilitzaré el reemplaçament recomanat en forma de Tekton Pipelines. La resta de l'article es va escriure després de llegir la documentació de Tekton Pipelines, però es basa en les idees de Priti. Per funcionar, necessitareu accés a algun registre de Docker: jo, com l'autor original, utilitzaré DockerHub.
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yaml
Apliquem:
$ 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
La comprovació del treball consisteix a obtenir el nom del pod i veure'n l'estat. També podeu veure el registre d'execució de cada pas, per exemple:
$ 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"}
Després de l'execució, tindrem una imatge al Registre que es pot desplegar mitjançant la utilitat kn, dissenyada per treballar amb serveis Knative, per exemple:
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
Si utilitzeu Gloo, podeu comprovar la seva funcionalitat així: