Alfred Sabitzer - K8s Applications mit MicroK8S auf Raspberry PI

service/getinfo-service ClusterIP 10.152.183.43 8080/TCP 6m12s

NAME READY UP-TO-DATE AVAILABLE AGE

deployment.apps/webserver-slainte 1/1 1 1 67d

deployment.apps/getinfo 1/1 1 1 6m12s

NAME DESIRED CURRENT READY AGE

replicaset.apps/webserver-slainte-67494d5d7b 1 1 1 67d

replicaset.apps/getinfo-6c84cff999 1 1 1 89s

replicaset.apps/getinfo-6659cf7655 0 0 0 6m12s

Die Anzeige im Dashboard zeigt uns auch einen gut laufenden Pod.

Abbildung 23: GetInfo Pod im Dashboard

Nun schauen wir, was der Pod zurückliefert:

alfred@pc1:~$ curl http://10.152.183.43:8080/view/hello

Es ist 2021-10-15 20:00:26 Friday

alfred@pc1:~$

Sieht ganz gut aus:) Auch der Logoutput ist interessant:

alfred@pc1:~$ kubectl logs getinfo-6c84cff999-mtf5v

2021/10/15 19:58:40 Main Started

2021/10/15 20:00:26 hello.html

alfred@pc1:~$

Um den Output richtig zu sehen, ändere ich zu Testzwecken den Typ des Services auf einen NodePort um den Service von außen erreichen zu können.

alfred@pc1:~$ kubectl edit service getinfo-service

service/getinfo-service edited

alfred@pc1:~$

alfred@pc1:~$ kubectl get service

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

kubernetes ClusterIP 10.152.183.1 443/TCP 67d

webserver-slainte ClusterIP 10.152.183.125 443/TCP 67d

getinfo-service NodePort 10.152.183.43 8080:32304/TCP 19m

alfred@pc1:~$

Der Output aus dem inneren des Pods sieht am Browser auch gut aus.

Abbildung 24: GetInfo Anzeige aus dem Pod

Somit haben wir einen richtigen Service im Kubernetes-Cluster laufen. Wir kontrollieren den Pod noch von innen.

alfred@pc1:~$ kubectl exec getinfo-6c84cff999-mtf5v -it -- /bin/sh

/app # df -h

Filesystem Size Used Available Use% Mounted on

overlay 58.3G 9.8G 46.1G 17% /

tmpfs 64.0M 0 64.0M 0% /dev

tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup

/dev/mmcblk0p2 58.3G 9.8G 46.1G 17% /etc/localtime

/dev/mmcblk0p2 58.3G 9.8G 46.1G 17% /etc/hosts

/dev/mmcblk0p2 58.3G 9.8G 46.1G 17% /dev/termination-log

/dev/mmcblk0p2 58.3G 9.8G 46.1G 17% /etc/hostname

/dev/mmcblk0p2 58.3G 9.8G 46.1G 17% /etc/resolv.conf

shm 64.0M 0 64.0M 0% /dev/shm

tmpfs 3.8G 12.0K 3.8G 0% /run/secrets/kubernetes.io/serviceaccount

tmpfs 64.0M 0 64.0M 0% /proc/kcore

tmpfs 64.0M 0 64.0M 0% /proc/keys

tmpfs 64.0M 0 64.0M 0% /proc/latency_stats

tmpfs 64.0M 0 64.0M 0% /proc/timer_list

tmpfs 64.0M 0 64.0M 0% /proc/sched_debug

tmpfs 3.8G 0 3.8G 0% /proc/scsi

tmpfs 3.8G 0 3.8G 0% /sys/firmware

/app # date

Sat Oct 16 09:31:11 CEST 2021

/app # top -n 1

Mem: 3902992K used, 4095752K free, 6520K shrd, 180504K buff, 1651716K cached

CPU: 14% usr 11% sys 0% nic 16% idle 52% io 0% irq 4% sirq

Load average: 5.06 3.25 2.38 3/984 1332

PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND

1 0 root S 692m 9% 0 0% /GetInfo

1157 0 root S 1720 0% 3 0% /bin/sh

1332 1157 root R 1652 0% 3 0% top -n 1

/app # exit

alfred@pc1:~$ kubectl top pod getinfo-6c84cff999-mtf5v --containers --use-protocol-buffers

POD NAME CPU(cores) MEMORY(bytes)

getinfo-6c84cff999-mtf5v getinfo 8m 5Mi

alfred@pc1:~$

Sieht ganz gut aus.

Automatisierung der Entwicklungsumgebung

Inspiration:

https://elearning.wsldp.com/pcmagazine/install-liteide-on-ubuntu/ https://www.educative.io/blog/kubernetes-deployments-strategies

https://collabnix.github.io/kubetools/

Um die Entwicklung zu standardisieren und zu beschleunigen, legen wir eine gewisse Struktur an.

Unter dem Home-Directory gibt es ein Verzeichnis für die Templates.

.

├── make.sh

├── make_configmap.sh

├── make_configmap_dir.sh

├── make_docker.sh

├── make_yaml.sh

├── registry_delete.sh

├── registry_list.sh

└── svn.sh

Das svn.sh enthält in meinem Fall den Update der notwendigen Skripten für den Build und Deploy.

alfred@monitoring:~/devtemplates$ cat svn.sh

#!/bin/bash

# Auschecken der Sourcen

svn checkout https://monitoring.slainte.at/svn/slainte/trunk/k8s/dev ./

alfred@monitoring:~/devtemplates$

Das make.sh (kommt dann aus dem svn) enthält die notwendigen Befehle für das Bauen und ausrollen.