K8s Applications mit MicroK8S auf Raspberry PI. Alfred Sabitzer

Чтение книги онлайн.

СКАЧАТЬ target="_blank" rel="nofollow" href="#fb3_img_img_39348f85-bb57-55fc-bede-bfd6902641d8.jpg" alt="OEBPS/images/image0005.jpg"/> Abbildung 4: pico-Cluster von der Seite

      Hier erkennt man den Cluster mit dem eingebauten Lüfter.

       Abbildung 5: pico-Cluster von hinten

      Hier kann man gut die Cluster-Storage erkennen. Aus thermischen Gründen befinden sich die SSD-Platten ausserhalb des Pico-Clusters.

      Der Aufbau wird in „Bau einer K8s bare-metal-cloud mit RaspberryPI“ beschrieben.

      Ein Übersicht gibt folgendes Bild:

       Abbildung 6: MicroK8S Cluster - Gesamtsystem

      Namespaces

      Inspiration:

       https://microk8s.io/docs/registry-built-in

      Um den Cluster richtig betreiben zu können, sind auch Namespaces wichtig. Es sind (neben den technischen Namespaces, die mit k8s automatisch angelegt werden) noch die folgenden Namespaces vorhanden.

      ---

      apiVersion: v1

      kind: Namespace

      metadata:

       labels:

       kubernetes.io/metadata.name: slainte

       name: slainte

      spec:

       finalizers:

       - kubernetes

      ---

      apiVersion: v1

      kind: Namespace

      metadata:

       labels:

       kubernetes.io/metadata.name: default

       name: default

      spec:

       finalizers:

       - kubernetes

      ---

      apiVersion: v1

      kind: Namespace

      metadata:

       labels:

       kubernetes.io/metadata.name: admin

       name: admin

      spec:

       finalizers:

       - kubernetes

      ---

      Slainte ist quasi die Produktion (von aussen erreichbar). Default ist ein Test-URL der auch von aussen erreichbar ist. Die Services in admin haben keinen Ingress (sind von aussen nicht erreichbar), werden aber idR. als LoadBalancer-Services bereitgestellt.

      IP-Adressen

      Inspiration:

      https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview

      Die im Cluster verfügbaren Bereiche sind:

      Im Konkreten:

      k8s.slainte.at 87.243.186.29

      default.k8s.slainte.at 87.243.186.29

      Aus dem Cluster selbst:

      alfred@pc1:~/yaml$ k get svc --all-namespaces | grep -v '<none>'

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

      ingress ingress LoadBalancer 10.152.183.126 192.168.0.210 443:31287/TCP,80:31681/TCP 22h

      kube-system kubernetes-dashboard LoadBalancer 10.152.183.150 192.168.0.211 443:31449/TCP 22h

      longhorn-system longhorn-frontend LoadBalancer 10.152.183.199 192.168.0.212 80:31444/TCP 22h

      container-registry registry LoadBalancer 10.152.183.207 192.168.0.213 5000:32000/TCP 22h

      admin chrony-udp-svc LoadBalancer 10.152.183.77 192.168.0.240 123:32658/UDP 40m

      admin pgadmin-svc LoadBalancer 10.152.183.201 192.168.0.241 5432:30954/TCP,80:30675/TCP,443:30676/TCP 19m

      Source Repository

      Inspiration:

       https://microk8s.io/docs/registry-built-in

      Eine Software-Registry wird benötigt, wenn man selbst entwickelte Anwendungen lokal speicher und verwenden möchte. Prinzipiell könnte man auch öffentliche Registrys nehmen, aber wir haben ja einen k8s-cluster.

      alfred@pc1:~$ microk8s enable registry:size=40Gi

      Addon storage is already enabled.

      Enabling the private registry

      Applying registry manifest

      namespace/container-registry created

      persistentvolumeclaim/registry-claim created

      deployment.apps/registry created

      service/registry created

      configmap/local-registry-hosting configured

      The registry is enabled

      The size of the persistent volume is 40Gi

      alfred@pc1:~$

      Nun ist die Registry vorhanden. Das Cluster-Setup ist wie folgt:

      alfred@pc1:~$ microk8s status

      microk8s is running

      high-availability: yes

       datastore master nodes: 192.168.0.202:19001 192.168.0.203:19001 192.168.0.204:19001

       datastore standby nodes: 192.168.0.201:19001 192.168.0.205:19001

      addons:

СКАЧАТЬ