Ten artykuł kończy cykl tłumaczeń notatek o OpenWhisk autorstwa . Dziś omówimy proces wdrażania OpenWhisk na Kubernetes z poprawionymi poleceniami, aby działały z aktualnymi wersjami aplikacji. Opisany będzie również proces uruchamiania funkcji OpenWhisk z użyciem Knative i TektonCD w Kubernetes z użyciem środowiska wykonawczego Nodejs.
Wdrażamy OpenWhisk na Kubernetes
W ciągu kilku dni przeprowadziłem eksperyment związany z wdrażaniem OpenWhisk w Kubernetes, aby stworzyć prosty i szybki stwór do pracy nad zadaniami. Ponieważ jestem początkującym użytkownikiem Kubernetes, uważam, że półtora dnia zajęło mi pomyślne wdrożenie. W repozytorium znajdują się bardzo zrozumiałe instrukcje dotyczące wdrażania OpenWhisk w Kubernetes. Tutaj znajdziecie instrukcje dotyczące wdrożenia, które zostały przygotowane dla Mac (ja również zrobię to na Linuxie, ponieważ preferuję Linux. — przyp. tłumacza.
- Instalujemy menedżera pakietów
asdf, a następnie automatycznie poprawiamy~/.bash_profilelub jego odpowiednik w ten sposób:
$ brew install asdf
$ [ -s "/usr/local/opt/asdf/asdf.sh" ] && . /usr/local/opt/asdf/asdf.sh
$ source ~/ .bash_profile[Na Linuxie ten krok nie jest potrzebny, chociaż brew jest dostępne. — uwaga tłumacza]
- Dodajemy wtyczki
minikubeikubelet:
$ asdf plugin-add kubectl
$ asdf plugin-add minikube[Znowu pomijamy ten krok na Linuxie. — uwaga tłumacza]
- Instalujemy 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[instalowane są konkretne wersje, ale sprawdzałem to na najnowszych dostępnych wersjach dla Linuxa; podejrzewam, że można spokojnie zainstalować wersję latest. — uwaga tłumacza]
Na Linuxie ten krok wygląda mniej więcej tak (wszystko instalowane jest w ~/bin, który mam wpisany w PATH, przyp. tłumacza):
$ 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/- Tworzymy maszynę wirtualną minikube (VirtualBox musi być wcześniej zainstalowany):
$ minikube start --cpus 2 --memory 4096 --kubernetes-version=v1.9.0 --extra-config=apiserver.Authorization.Mode=RBAC[U mnie wszystko działa z poleceniem minikube start , bez parametrów i wartości domyślnych. — uwaga tłumacza]
$ minikube start
minikube v1.5.2 na Debian 8.11
Automatycznie wybrano sterownik 'virtualbox'
Pobieranie obrazu startowego 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
Tworzenie VM virtualbox (CPUs=2, Pamięć=4096MB, Dysk=20000MB) ...
Przygotowywanie Kubernetes v1.16.2 na Docker '18.09.9' ...
Pobieranie kubelet v1.16.2
Pobieranie kubeadm v1.16.2
Pobieranie obrazów ...
Uruchamianie Kubernetes ... Czekanie na: apiserver
Gotowe! kubectl jest teraz skonfigurowane do użycia "minikube"- Przełączamy sieć w Dockerze w tryb promiskutywny:
$ minikube ssh -- sudo ip link set docker0 promisc on- Tworzymy namespace i oznaczamy węzeł roboczy:
$ kubectl create namespace openwhisk
$ kubectl label nodes --all openwhisk-role=invoker- Pobieramy zawartość repozytorium i przedefiniowujemy typ dla ingress w pliku 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- Instalujemy Helm i przeprowadzamy wdrożenie za jego pomocą:
$ brew install kubernetes-helm
$ helm init # inicjalizacja Helm Tiller, niepotrzebne w Helm v3+
$ kubectl get pods -n kube-system # weryfikacja, że tiller-deploy działa, niepotrzebne w helm v3+
$ kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default
$ helm install ./openwhisk/helm/ --namespace=openwhisk -f mycluster.yaml[Na Linuksie z najnowszymi wersjami (wcześniej dostępna v3.0.1) będzie to wyglądać nieco inaczej. — uwaga tłumacza]
$ 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- Sprawdzamy, czy wszystko działa (STATUS = Running lub 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- Konfigurujemy wsk do pracy:
$ wsk property set --apihost 192.168.99.100:31001
$ wsk property set --auth 23bc46b1-71f6-4ed5-8c54-816aa4f8c502:123zO3xZCLrMN6v2BKK1dXYFpXlPkccOFqm12CdAsMgRU4VrNZ9lyGVCGuMDGIwPSprawdzamy:
$ wsk -i list
Entities in namespace: default
packages
actions
triggers
rulesProblemy i ich rozwiązania
getsockopt: odrzucono połączenie
$ wsk -i list
error: Nie można uzyskać listy bytów 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: odrzucono połączenieSprawdzamy, czy kontenery w namespace openwhisk są w statusie Running, ponieważ czasami padają z błędami CreateContainerConfigError.
Invoker wciąż się inicjalizuje — Init:1/2
Proces pobierania różnych środowisk wykonawczych może zająć dużo czasu. Możesz przyspieszyć to, podając skróconą minimalną listę w pliku mycluster.yaml:
whisk:
runtimes: "runtimes-minimal-travis.json"Kontener o nazwie -install-packages- wychodzi z błędem
Po prostu zwiększ czasy oczekiwania dla testów liveness.
Instalacja OpenWhisk na Knative
Priti Desai przeprowadzała instalację na klastrze w chmurze IBM oraz na zwykłym minikube, używając Knative Build i BuildTemplates. Ja również zainstaluję na minikube, na podstawie tego, jak W naszym blogu wcześniej — korzystając z najnowszych wersji oprogramowania. Ponieważ Knative Build i BuildTemplates zostały oficjalnie ogłoszone jako przestarzałe, użyję zalecanego zamiennika w postaci Tekton Pipelines. Reszta artykułu została napisana po zapoznaniu się z dokumentacją Tekton Pipelines, ale opiera się na pomysłach Priti. Do pracy potrzebny będzie dostęp do jakiegoś Docker Registry — ja, tak jak oryginalny autor, korzystam z 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
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
Budowanie i działanie OpenWhisk na Knative
- Pobieramy zawartość :
$ git clone https://github.com/tektoncd/catalog/
$ cd catalog/openwhisk- Ustawiamy dane do dostępu do Registry jako zmienne środowiskowe i zapisujemy je jako sekrety 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.yamlSprawdzamy:
$ kubectl get secret
NAME TYPE DATA AGE
dockerhub-user-pass kubernetes.io/basic-auth 2 21s- Tworzymy konto użytkownika do budowy środowisk:
$ kubectl apply -f service-account.yamlSprawdzamy:
$ kubectl get serviceaccount/openwhisk-runtime-builder
NAME SECRETS AGE
openwhisk-runtime-builder 2 31m- Tworzymy zadanie do budowy obrazu dla OpenWhisk
$ kubectl apply -f openwhisk.yaml
task.tekton.dev/openwhisk created- Uruchamiamy zadanie do budowy obrazu (na przykład NodeJS):
Tworzymy plik taskrun.yaml z zawartością:
# 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
---Stosujemy aktualne dane do tego pliku:
$ sed 's/${DOCKER_USERNAME}/'$DOCKER_USERNAME'/' -i taskrun.yamlStosujemy:
$ 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 createdSprawdzenie działania polega na uzyskaniu nazwy pod`a, sprawdzeniu jego statusu. Można również zobaczyć dziennik wykonania każdego kroku, na przykład:
$ 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"}Po wykonaniu w naszym rejestrze pojawi się obraz, który można wdrożyć za pomocą narzędzia kn, przeznaczonego do pracy z usługami Knative, na przykład:
kn service create nodejs-helloworld --image docker.io/${DOCKER_USERNAME}/openwhisk-nodejs-helloworld
Usługa 'nodejs-helloworld' pomyślnie utworzona w namespace 'default'.
Czekam na gotowość usługi 'nodejs-helloworld' ... OK
URL usługi:
http://nodejs-helloworld.default.example.comW przypadku używania Gloo, aby sprawdzić działanie, można to zrobić w ten sposób:
$ 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!"}Inne artykuły z cyklu
Źródło: habr.com
