Dieser Artikel beendet den Zyklus der Übersetzungsnotizen zu OpenWhisk von Autor . Heute betrachten wir den Prozess der Bereitstellung von OpenWhisk über Kubernetes mit verbesserten Befehlen, um die Funktionsfähigkeit mit den aktuellen Anwendungsversionen sicherzustellen. Ebenso wird der Prozess des Startens von OpenWhisk-Funktionen unter Verwendung von Knative und TektonCD in Kubernetes mit der Nodejs-Laufzeit beschrieben.
Bereitstellung von OpenWhisk auf Kubernetes
In den letzten Tagen habe ich ein Experiment zur Bereitstellung von OpenWhisk in Kubernetes durchgeführt, um eine einfache und schnelle Plattform zur Erprobung von Aufgaben zu schaffen. Da ich neu in Kubernetes bin, vermute ich, dass anderthalb Tage für eine erfolgreiche Bereitstellung benötigt wurden. Im Repository gibt es sehr klare Anleitungen zur Bereitstellung von OpenWhisk in Kubernetes. Hier sind die für Mac erstellten Bereitstellungsanleitungen (Ich werde alles auch auf Linux machen, weil ich Linux bevorzuge. — Anmerkung des Übersetzers).
- Installieren des Paketmanagers
asdf, danach fügen wir automatisch hinzu~/.bash_profileoder ein Äquivalent so:
$ brew install asdf
$ [ -s "/usr/local/opt/asdf/asdf.sh" ] && . /usr/local/opt/asdf/asdf.sh
$ source ~/.bash_profile[Unter Linux ist dieser Schritt nicht nötig, obwohl brew vorhanden ist. — Anmerkung des Übersetzers]
- Plugins hinzufügen
minikubeundKubelet:
$ asdf plugin-add kubectl
$ asdf plugin-add minikube[Diesen Schritt überspringen wir erneut auf Linux. — Anmerkung des Übersetzers]
- Minikube und kubelet installieren:
$ asdf install kubectl 1.9.0
$ asdf global kubectl 1.9.0
$ asdf install minikube 0.25.2
$ asdf global minikube 0.25.2[konkrete Versionen werden installiert, aber ich habe alles mit den neuesten verfügbaren Versionen für Linux geprüft; ich vermute, dass man problemlos die neueste installieren kann. — Anmerkung des Übersetzers]
Unter Linux erfolgt dieser Schritt etwa so (alles wird in ~/bin installiert, das bei mir im PATH eingetragen ist, Anmerkung des Übersetzers):
$ 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/- Eine virtuelle Maschine mit minikube erstellen (VirtualBox muss zuvor installiert sein):
$ minikube start --cpus 2 --memory 4096 --kubernetes-version=v1.9.0 --extra-config=apiserver.Authorization.Mode=RBAC[Bei mir funktioniert alles mit dem Befehl minikube start , ohne Parameter und mit Standardwerten. — Anmerkung des Übersetzers]
$ minikube start
minikube v1.5.2 auf Debian 8.11
Automatisch den 'virtualbox'-Treiber ausgewählt
VM-Boot-Image wird heruntergeladen ...
> 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
Erstelle virtualbox VM (CPUs=2, Speicher=4096MB, Disk=20000MB) ...
Bereite Kubernetes v1.16.2 auf Docker '18.09.9' vor ...
Lade kubelet v1.16.2 herunter
Lade kubeadm v1.16.2 herunter
Bilder werden gezogen ...
Starte Kubernetes ... Warte auf: apiserver
Fertig! kubectl ist jetzt konfiguriert, um "minikube" zu verwenden- Wechseln Sie das Docker-Netzwerk in den Promiscuous-Modus:
$ minikube ssh -- sudo ip link set docker0 promisc on- Erstelle Namespace und markiere den Arbeitsknoten:
$ kubectl create namespace openwhisk
$ kubectl label nodes --all openwhisk-role=invoker- Erhalte den Inhalt des Repositories und überschreibe den Typ für ingress in der Datei 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- Installieren Sie Helm und führen Sie das Deployment damit durch:
$ brew install kubernetes-helm
$ helm init # init Helm Tiller, nicht notwendig bei Helm v3+
$ kubectl get pods -n kube-system # Überprüfen Sie, ob tiller-deploy im laufenden Zustand ist, nicht notwendig bei helm v3+
$ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
$ helm install ./openwhisk/helm/ --namespace=openwhisk -f mycluster.yaml[Auf Linux mit den neuesten Versionen (v3.0.1 war verfügbar) wird es etwas anders sein. — Anmerkung des Übersetzers]
$ 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- Überprüfen Sie, ob alles gestartet ist (STATUS = Running oder Completed):
$ kubectl get pods -n openwhisk
NAME READY STATUS RESTARTS AGE
openwhisk-1576070780-alarmprovider-6868dc694-plvpf 1/1 Running 1 1d5h
openwhisk-1576070780-apigateway-8d56f4979-825hf 1/1 Running 1 1d5h
openwhisk-1576070780-cloudantprovider-544bb46596-9scph 1/1 Running 1 1d5h
openwhisk-1576070780-controller-0 1/1 Running 2 1d5h
openwhisk-1576070780-couchdb-7fd7f6c7cc-42tw6 1/1 Running 1 1d5h
openwhisk-1576070780-gen-certs-z9nsb 0/1 Completed 0 1d5h
openwhisk-1576070780-init-couchdb-r2vmt 0/1 Completed 0 1d5h
openwhisk-1576070780-install-packages-27dtr 0/1 Completed 0 1d4h
openwhisk-1576070780-invoker-0 1/1 Running 1 1d5h
openwhisk-1576070780-kafka-0 1/1 Running 1 1d5h
openwhisk-1576070780-kafkaprovider-f8b4cf4fc-7z4gt 1/1 Running 1 1d5h
openwhisk-1576070780-nginx-6dbdbf69bc-5x76n 1/1 Running 1 1d5h
openwhisk-1576070780-redis-cfd8756f4-hkrt6 1/1 Running 1 1d5h
openwhisk-1576070780-wskadmin 1/1 Running 1 1d5h
openwhisk-1576070780-zookeeper-0 1/1 Running 1 1d5h
wskopenwhisk-1576070780-invoker-00-1-prewarm-nodejs10 1/1 Running 0 61s
wskopenwhisk-1576070780-invoker-00-2-prewarm-nodejs10 1/1 Running 0 61s
wskopenwhisk-1576070780-invoker-00-3-whisksystem-invokerhealtht 1/1 Running 0 59s- Wir konfigurieren wsk zur Verwendung:
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwPÜberprüfen:
$ wsk -i list
Entities im Namespace: default
packages
actions
triggers
rulesProbleme und deren Lösungen
getsockopt: Verbindung verweigert
$ wsk -i list
Fehler: Die Liste der Entitäten für den Namespace 'default' konnte nicht abgerufen werden: Get http://192.168.99.100:31001/api/v1/namespaces/_/actions?limit=0&skip=0: dial tcp 192.168.99.100:31001: getsockopt: Verbindung verweigertÜberprüfen, dass die Container im Namespace openwhisk im Status sind Laufend, da es manchmal zu Fehlern kommt CreateContainerConfigError.
Invoker wird noch initialisiert — Init:1/2
Der Vorgang zum Herunterladen aller möglichen Laufzeitumgebungen kann eine Weile dauern. Um die Installation zu beschleunigen, kann eine minimale Liste in der Datei angegeben werden mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"Container mit dem Namen -install-packages- gerät in einen Fehler
Erhöhen Sie einfach die Zeitüberschreitungen für die Liveness-Tests.
Installation von OpenWhisk über Knative
Priti Desai führte die Installation über ein Cluster in der IBM-Cloud sowie auf einem regulären Minikube durch, wobei Knative Build und BuildTemplates verwendet wurden. Ich werde ebenfalls eine Installation über Minikube durchführen, basierend darauf, wie In unserem Blog zuvor - unter Verwendung der neuesten Softwareversionen. Da Knative Build und BuildTemplates offiziell als veraltet gelten, werde ich die empfohlene Alternative in Form von Tekton Pipelines verwenden. Der weitere Teil des Artikels wurde nach dem Lesen der Dokumentation zu Tekton Pipelines verfasst, basiert jedoch auf den Ideen von Priti. Für die Arbeit benötigen Sie Zugriff auf ein Docker-Registry — ich werde wie der ursprüngliche Autor DockerHub verwenden.
$ 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
NAME READY STATUS RESTARTS AGE
activator-77fc555665-rvrst 1/1 Running 0 2m23s
autoscaler-5c98b7c9b6-x8hh4 1/1 Running 0 2m21s
autoscaler-hpa-5cfd4f6845-w87kq 1/1 Running 0 2m22s
controller-7fd74c8f67-tprm8 1/1 Running 0 2m19s
webhook-74847bb77c-txr2g 1/1 Running 0 2m17s
$ kubectl get pods -n gloo-system
NAME READY STATUS RESTARTS AGE
discovery-859d7fbc9c-8xhvh 1/1 Running 0 51s
gloo-545886d9c6-85mwt 1/1 Running 0 51s
ingress-67d4996d75-lkkmw 1/1 Running 0 50s
knative-external-proxy-767dfd656c-wwv2z 1/1 Running 0 50s
knative-internal-proxy-6fdddcc6b5-7vqd8 1/1 Running 0 51s
Die Erstellung und der Betrieb von OpenWhisk über Knative
- Inhalt abrufen :
$ git clone https://github.com/tektoncd/catalog/
$ cd catalog/openwhisk- Wir setzen die Zugangsdaten für das Registry als Umgebungsvariablen und speichern sie als Kubernetes-Secret:
$ 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.yamlÜberprüfen:
$ kubectl get secret
NAME TYPE DATA AGE
dockerhub-user-pass kubernetes.io/basic-auth 2 21s- Wir erstellen ein Benutzerkonto für den Build von Umgebungen:
$ kubectl apply -f service-account.yamlÜberprüfen:
$ kubectl get serviceaccount/openwhisk-runtime-builder
NAME SECRETS AGE
openwhisk-runtime-builder 2 31m- Wir erstellen einen Job zum Bauen des Images für OpenWhisk
$ kubectl apply -f openwhisk.yaml
task.tekton.dev/openwhisk created- Wir starten den Job zum Bauen des Images (am Beispiel von NodeJS):
Wir erstellen die Datei taskrun.yaml mit dem Inhalt:
# 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
---Wir wenden die aktuellen Daten für diese Datei an:
$ sed 's/${DOCKER_USERNAME}/'$DOCKER_USERNAME'/' -i taskrun.yamlWir wenden an:
$ 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 createdDie Überprüfung der Funktionsweise besteht darin, den Namen des Pods abzurufen, seinen Status zu überprüfen. Zudem kann das Protokoll jeder einzelnen Durchführung eingesehen werden, zum Beispiel:
$ kubectl get taskrun
NAME SUCCEEDED REASON STARTTIME COMPLETIONTIME
openwhisk-nodejs-helloworld True Erfolgreich 5m15s 44s
$ kubectl get pod openwhisk-nodejs-helloworld-pod-4640d3
NAME READY STATUS RESTARTS AGE
openwhisk-nodejs-helloworld-pod-4640d3 0\/6 Abgeschlossen 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: keine solche Datei oder Verzeichnis"}
{"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":"Unerwarteter Fehler: Symlink erstellen: symlink \/tekton\/home\/.ssh \/root\/.ssh: Datei existiert"}
{"level":"info","ts":1576532936.8202565,"logger":"fallback-logger","caller":"git\/git.go:109","msg":"Submodule erfolgreich initialisiert und aktualisiert in path \/workspace\/runtime-git"}Nach der Ausführung wird im Registry ein Image erscheinen, das mit dem Tool kn bereitgestellt werden kann, das für die Arbeit mit Knative-Diensten bestimmt ist, zum Beispiel:
kn service create nodejs-helloworld --image docker.io\/${DOCKER_USERNAME}\/openwhisk-nodejs-helloworld
Der Dienst 'nodejs-helloworld' wurde erfolgreich im Namespace 'default' erstellt.
Warten auf Dienst 'nodejs-helloworld', um bereit zu werden ... OK
Dienst-URL:
http:\/\/nodejs-helloworld.default.example.comIm Falle der Verwendung von Gloo kann die Funktionsfähigkeit so überprüft werden:
$ 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":"Hallo Welt!"}Weitere Artikel der Reihe
Quelle: habr.com
