Questo articolo conclude il ciclo di note tradotte su OpenWhisk dall'autore . Oggi analizzeremo il processo di distribuzione di OpenWhisk su Kubernetes con comandi corretti per funzionare con le versioni attuali delle applicazioni. Sarà anche descritto il processo di esecuzione delle funzioni di OpenWhisk utilizzando Knative e TektonCD su Kubernetes con un ambiente di esecuzione Nodejs.
Distribuiamo OpenWhisk su Kubernetes
In pochi giorni ho condotto un esperimento per distribuire OpenWhisk su Kubernetes per creare un poligono semplice e veloce per esercitarsi con i compiti. E poiché sono un principiante in Kubernetes, credo che un giorno e mezzo sia stato speso per una distribuzione riuscita. Nel repository ci sono istruzioni molto chiare per la distribuzione di OpenWhisk su Kubernetes. Qui ci saranno istruzioni per la distribuzione, realizzate per Mac (farò tutto su Linux, perché preferisco Linux. — nota del traduttore).
- Installiamo il gestore di pacchetti
asdf, dopodiché correggiamo automaticamente~/.bash_profileo un'alternativa in questo modo:
$ brew install asdf
$ [ -s "/usr/local/opt/asdf/asdf.sh" ] && . /usr/local/opt/asdf/asdf.sh
$ source ~/.bash_profile[Su Linux questo passaggio non è necessario, anche se brew è disponibile. — nota del traduttore]
- Aggiungiamo i plugin
minikubeekubelet:
$ asdf plugin-add kubectl
$ asdf plugin-add minikube[Ancora una volta saltiamo questo passaggio su Linux. — nota del traduttore]
- Installa minikube e 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[si installano versioni specifiche, ma ho verificato tutto con le versioni più recenti disponibili per Linux; sospetto che si possa tranquillamente installare l'ultima. — nota del traduttore]
Su Linux questo passaggio si fa più o meno in questo modo (tutto si installa in ~/.bin, che ho nel PATH, nota del traduttore):
$ curl -L0 minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 && chmod +x minikube && mv minikube ~/.bin/
$ curl -L0 https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl && chmod +x kubectl && mv kubectl ~/.bin/- Creiamo la macchina virtuale minikube (deve essere installato VirtualBox in precedenza):
$ minikube start --cpus 2 --memory 4096 --kubernetes-version=v1.9.0 --extra-config=apiserver.Authorization.Mode=RBAC[A me funziona tutto con il comando minikube start , senza parametri e con i valori predefiniti. — nota del traduttore]
$ minikube start
minikube v1.5.2 su Debian 8.11
Driver 'virtualbox' selezionato automaticamente
Downloading immagine di avvio della VM ...
> minikube-v1.5.1.iso.sha256: 65 B / 65 B [--------------] 100.00% ? p/s 0s
> minikube-v1.5.1.iso: 143.76 MiB / 143.76 MiB [-] 100.00% 5.63 MiB p/s 26s
Creazione della VM virtualbox (CPUs=2, Memoria=4096MB, Disco=20000MB) ...
Preparazione di Kubernetes v1.16.2 su Docker '18.09.9' ...
Download kubelet v1.16.2
Download kubeadm v1.16.2
Pulling images ...
Lancio di Kubernetes ... In attesa di: apiserver
Fatto! kubectl è ora configurato per utilizzare "minikube"- Switching the network in Docker to promiscuous mode:
$ minikube ssh -- sudo ip link set docker0 promisc on- Creiamo uno namespace e etichettiamo il nodo di lavoro:
$ kubectl create namespace openwhisk
$ kubectl label nodes --all openwhisk-role=invoker- Otteniamo il contenuto del repository e ridefiniamo il tipo per ingress nel file mycluster.yaml:
$ git clone https://github.com/apache/incubator-openwhisk-deploy-kube.git
$ cd incubator-openwhisk-deploy-kube/
$ cat < mycluster.yaml
whisk:
ingress:
type: NodePort
api_host_name: 192.168.99.100
api_host_port: 31001
nginx:
httpsNodePort: 31001
EOF- Installa Helm e procedi con il deployment tramite questo:
$ brew install kubernetes-helm
$ helm init # init Helm Tiller, non necessario su Helm v3+
$ kubectl get pods -n kube-system # verifica che tiller-deploy sia in stato di esecuzione, non necessario su helm v3+
$ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
$ helm install ./openwhisk/helm/ --namespace=openwhisk -f mycluster.yaml[Su Linux con le ultime versioni (era disponibile v3.0.1) sarà un po' diverso. — nota del traduttore]
$ curl -L0 https://get.helm.sh/helm-v3.0.1-linux-amd64.tar.gz | tar -xzvf - linux-amd64/helm --strip-components=1; sudo mv helm /usr/local/bin
$ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
$ helm install ./openwhisk/helm/ --namespace=openwhisk --generate-name -f mycluster.yaml- Controlliamo che tutto sia attivo (STATUS = Running o Completed):
$ kubectl get pods -n openwhisk
NOME PRONTO STATO RIAVVII ETÀ
openwhisk-1576070780-alarmprovider-6868dc694-plvpf 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-apigateway-8d56f4979-825hf 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-cloudantprovider-544bb46596-9scph 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-controller-0 1/1 In esecuzione 2 1d5h
openwhisk-1576070780-couchdb-7fd7f6c7cc-42tw6 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-gen-certs-z9nsb 0/1 Completato 0 1d5h
openwhisk-1576070780-init-couchdb-r2vmt 0/1 Completato 0 1d5h
openwhisk-1576070780-install-packages-27dtr 0/1 Completato 0 1d4h
openwhisk-1576070780-invoker-0 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-kafka-0 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-kafkaprovider-f8b4cf4fc-7z4gt 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-nginx-6dbdbf69bc-5x76n 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-redis-cfd8756f4-hkrt6 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-wskadmin 1/1 In esecuzione 1 1d5h
openwhisk-1576070780-zookeeper-0 1/1 In esecuzione 1 1d5h
wskopenwhisk-1576070780-invoker-00-1-prewarm-nodejs10 1/1 In esecuzione 0 61s
wskopenwhisk-1576070780-invoker-00-2-prewarm-nodejs10 1/1 In esecuzione 0 61s
wskopenwhisk-1576070780-invoker-00-3-whisksystem-invokerhealtht 1/1 In esecuzione 0 59s- Configuriamo wsk per il funzionamento:
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwPControlliamo:
$ wsk -i list
Entità nello spazio dei nomi: default
pacchetti
action
attivatori
regoleProblemi e le loro soluzioni
getsockopt: connessione rifiutata
$ wsk -i list
errore: Impossibile ottenere l'elenco delle entità per lo spazio dei nomi 'default': Get http://192.168.99.100:31001/api/v1/namespaces/_/actions?limit=0&skip=0: dial tcp 192.168.99.100:31001: getsockopt: connessione rifiutataControlliamo che i container nello spazio dei nomi openwhisk siano nello stato Esecuzione, poiché a volte potrebbe bloccarsi con errori CreateContainerConfigError.
Invoker ancora in fase di inizializzazione — Init:1/2
Il processo di download di vari ambienti di esecuzione può richiedere molto tempo. Per accelerare, è possibile indicare un elenco minimo ridotto nel file mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"Container con nome -install-packages- si blocca con Error
Cresci semplicemente i timeout per i test di liveness.
Installazione di OpenWhisk sopra Knative
Priti Desai ha effettuato l'installazione sopra un cluster nel cloud IBM, così come su un normale minikube, utilizzando Knative Build e BuildTemplates. Anche io installerò sopra minikube, seguendo l'esempio di come nel nostro blog in precedenza — utilizzando le versioni più recenti del software. Poiché Knative Build e BuildTemplates sono stati ufficialmente dichiarati obsoleti, utilizzerò la sostituzione raccomandata in forma di Tekton Pipelines. La parte successiva dell'articolo è stata scritta dopo aver letto la documentazione di Tekton Pipelines, ma si basa sulle idee di Priti. Per procedere, è necessario avere accesso a un certo Docker Registry — io, come l'autore originale, utilizzerò DockerHub.
$ curl -L0 https://github.com/solo-io/gloo/releases/download/v1.2.10/glooctl-linux-amd64; chmod +x glooctl-linux-amd64; mv glooctl-linux-amd64 ~/bin
$ glooctl install knative
$ kubectl get pods -n knative-serving
NOME PRONTO STATO RICARICAMENTI ETÀ
activator-77fc555665-rvrst 1/1 In esecuzione 0 2m23s
autoscaler-5c98b7c9b6-x8hh4 1/1 In esecuzione 0 2m21s
autoscaler-hpa-5cfd4f6845-w87kq 1/1 In esecuzione 0 2m22s
controller-7fd74c8f67-tprm8 1/1 In esecuzione 0 2m19s
webhook-74847bb77c-txr2g 1/1 In esecuzione 0 2m17s
$ kubectl get pods -n gloo-system
NOME PRONTO STATO RICARICAMENTI ETÀ
discovery-859d7fbc9c-8xhvh 1/1 In esecuzione 0 51s
gloo-545886d9c6-85mwt 1/1 In esecuzione 0 51s
ingress-67d4996d75-lkkmw 1/1 In esecuzione 0 50s
knative-external-proxy-767dfd656c-wwv2z 1/1 In esecuzione 0 50s
knative-internal-proxy-6fdddcc6b5-7vqd8 1/1 In esecuzione 0 51s
Costruzione e funzionamento di OpenWhisk su Knative
- Otteniamo il contenuto :
$ git clone https://github.com/tektoncd/catalog/
$ cd catalog/openwhisk- Impostiamo come variabili d'ambiente i dati per accedere al Registry e li salviamo come segreto di Kubernetes:
$ export DOCKER_USERNAME=
$ export DOCKER_PASSWORD=
$ sed -e 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -e 's/${DOCKER_PASSWORD}/'"$DOCKER_PASSWORD"'/' docker-secret.yaml.tmpl > docker-secret.yaml
$ kubectl apply -f docker-secret.yamlControlliamo:
$ kubectl get secret
NOME TIPO DATI ETÀ
dockerhub-user-pass kubernetes.io/basic-auth 2 21s- Creiamo un account per la costruzione degli ambienti:
$ kubectl apply -f service-account.yamlControlliamo:
$ kubectl get serviceaccount/openwhisk-runtime-builder
NOME SEGRETI ETÀ
openwhisk-runtime-builder 2 31m- Creiamo un compito per la costruzione dell'immagine per OpenWhisk
$ kubectl apply -f openwhisk.yaml
task.tekton.dev/openwhisk creato- Avviamo il compito per la costruzione dell'immagine (con NodeJS come esempio):
Creiamo un file taskrun.yaml con il contenuto:
# Git Pipeline Resource for OpenWhisk NodeJS Runtime
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: openwhisk-nodejs-runtime-git
spec:
type: git
params:
- name: revision
value: master
- name: url
value: https://github.com/apache/openwhisk-runtime-nodejs.git
---
# Image Pipeline Resource for OpenWhisk NodeJS Sample Application
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: openwhisk-nodejs-helloworld-image
spec:
type: image
params:
- name: url
value: docker.io/${DOCKER_USERNAME}/openwhisk-nodejs-helloworld
---
# Task Run to build NodeJS image with the action source
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
name: openwhisk-nodejs-helloworld
spec:
serviceAccountName: openwhisk-runtime-builder
taskRef:
name: openwhisk
inputs:
resources:
- name: runtime-git
resourceRef:
name: openwhisk-nodejs-runtime-git
params:
- name: DOCKERFILE
value: "./runtime-git/core/nodejs10Action/knative/Dockerfile"
- name: OW_ACTION_NAME
value: "nodejs-helloworld"
- name: OW_ACTION_CODE
value: "function main() {return {payload: 'Hello World!'};}"
- name: OW_PROJECT_URL
value: ""
outputs:
resources:
- name: runtime-image
resourceRef:
name: openwhisk-nodejs-helloworld-image
---Applichiamo i dati attuali per questo file:
$ sed 's/${DOCKER_USERNAME}/'"$DOCKER_USERNAME"'/' -i taskrun.yamlApplichiamo:
$ kubectl apply -f taskrun.yaml
pipelineresource.tekton.dev/openwhisk-nodejs-runtime-git creato
pipelineresource.tekton.dev/openwhisk-nodejs-helloworld-image creato
taskrun.tekton.dev/openwhisk-nodejs-helloworld creatoLa verifica del funzionamento consiste nel ottenere il nome del pod, controllare il suo stato. È anche possibile visualizzare i registri di esecuzione di ogni passaggio, ad esempio:
$ kubectl get taskrun
NOME RIESCITA RAGIONE ORA INIZIO ORA DI COMPLETAMENTO
openwhisk-nodejs-helloworld True Riuscito 5m15s 44s
$ kubectl get pod openwhisk-nodejs-helloworld-pod-4640d3
NOME PRONTO STATO RIAVVII ETA'
openwhisk-nodejs-helloworld-pod-4640d3 0/6 Completo 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":"Recupero dell'ID del commit GitHub da kodata non riuscito: open \/var\/run\/ko\/refs\/heads\/master: nessun file o cartella di questo tipo"}
{"level":"info","ts":1576532936.538926,"logger":"fallback-logger","caller":"git/git.go:81","msg":"Clonazione riuscita di https:\/\/github.com\/apache\/openwhisk-runtime-nodejs.git @ master nel percorso \/workspace\/runtime-git"}
{"level":"warn","ts":1576532936.5395331,"logger":"fallback-logger","caller":"git/git.go:128","msg":"Errore inaspettato: creazione del symlink: symlink \/tekton\/home\/.ssh \/root\/.ssh: il file esiste"}
{"level":"info","ts":1576532936.8202565,"logger":"fallback-logger","caller":"git/git.go:109","msg":"Inizializzazione e aggiornamento riusciti dei submoduli nel percorso \/workspace\/runtime-git"}Dopo l'esecuzione avremo un'immagine nel Registro, che può essere distribuita utilizzando l'utilità kn, progettata per lavorare con i servizi Knative, ad esempio:
kn service create nodejs-helloworld --image docker.io\/${DOCKER_USERNAME}\/openwhisk-nodejs-helloworld
Il servizio 'nodejs-helloworld' è stato creato con successo nello spazio dei nomi 'default'.
In attesa che il servizio 'nodejs-helloworld' diventi pronto ... OK
URL del servizio:
http:\/\/nodejs-helloworld.default.example.comNel caso in cui venga utilizzato Gloo, è possibile verificare il funzionamento in questo modo:
$ curl -H "Host: nodejs-helloworld.default.example.com" -X POST $(glooctl proxy url --name knative-external-proxy)
{"OK":true}
$ curl -H "Host: nodejs-helloworld.default.example.com" -X POST $(glooctl proxy url --name knative-external-proxy)
{"payload":"Hello World!"}Altri articoli del ciclo
Fonte: habr.com
