Logging mit Loki und Grafana in Kubernetes

This entry is part 8 of 8 in the series Kubernetes - so startest Du durch!

Die wichtigsten Bausteine zum Starten deiner Anwendung kennst du bereits aus unserer Blogserie. Für den Betrieb fehlen dir noch Metriken und Logs deiner Anwendungen? Nach diesem Blogpost kannst du letzteres abhaken.

Logging mit Loki und Grafana in Kubernetes – ein Überblick

Zum Sammeln und Verwalten deiner Logs bieten sich auch für Kubernetes eine der wohl bekanntesten, schwergewichtigen Lösungen an. Diese bestehen in der Regel aus Logstash oder Fluentd zum Sammeln, gepaart mit Elasticsearch zum Speichern und Kibana bzw. Graylog zur Visualisierung deiner Logs.

Neben dieser klassischen Kombination gibt es seit wenigen Jahren mit Loki und Grafana einen neuen, leichtgewichtigeren Stack! Die grundlegende Architektur unterscheidet sich kaum zu den bekannten Setups.

Promtail sammelt auf jedem Kubernetes Node die Logs aller Container und sendet diese an eine zentrale Loki-Instanz. Diese aggregiert alle Logs und schreibt diese in ein Storage-Backend. Zur Visualisierung wird Grafana verwendet, welches sich die Logs direkt von der Loki-Instanz holt.

Der größte Unterschied zu den bekannten Stacks liegt wohl im Verzicht auf Elasticsearch. Dies spart Ressourcen und Aufwand, da somit auch kein dreifach replizierter Volltext-Index gespeichert und administriert werden muss. Und gerade wenn man beginnt, seine Anwendung aufzubauen, hört sich ein schlanker und einfacher Stack vielsprechend an. Wächst die Anwendungslandschaft, werden einzelne Komponenten von Loki in die Breite skaliert, um die Last auf mehrere Schultern zu verteilen.

Kein Volltextindex? Wie funktioniert das?

Zur schnellen Suche verzichtet Loki natürlich nicht auf einen Index, aber es werden nur noch Metadaten (ähnlich wie bei Prometheus) indexiert. Der Aufwand, den Index zu betreiben, wird dadurch sehr verkleinert. Für dein Kubernetes-Cluster werden somit hauptsächlich Labels im Index gespeichert und deine Logs werden automatisch anhand derselben Metadaten organisiert wie auch deine Anwendungen in deinem Kubernetes-Cluster. Anhand eines Zeitfensters und den Labels findet Loki schnell und einfach deine gesuchten Logs.

Zum Speichern des Index kann aus verschiedenen Datenbanken gewählt werden. Neben den beiden Cloud-Datenbanken BigTable und DynamoDB kann Loki seinen Index auch lokal in Cassandra oder BoltDB ablegen. Letztere unterstützt keine Replikation und ist vor allem für Entwicklungsumgebungen geeignet. Loki bietet mit boltdb-shipper eine weitere Datenbank an, welche aktuell noch in Entwicklung ist. Diese soll vor allem Abhängigkeiten zu einer replizierten Datenbank entfernen und regelmäßig Snapshots des Index im Chunk-Storage speichern (siehe unten).

Ein kleines Beispiel

Ein pod produziert mit stdout und stderr zwei Log-Streams. Diese Log-Streams werden in sogenannte Chunks zerlegt und komprimiert, sobald eine gewisse Größe erreicht wurde oder ein Zeitfenster abgelaufen ist.

Ein Chunk enthält somit komprimierte Logs eines Streams und wird auf eine maximale Größe und Zeiteinheit beschränkt. Diese komprimierten Datensätze werden dann im Chunk-Storage gespeichert.

Label vs. Stream

Eine Kombination aus exakt gleichen Labels (inkl. deren Werte) definiert einen Stream. Ändert man ein Label oder dessen Wert, entsteht ein neuer Stream. Die Logs aus stdout eines nginx-Pods be finden sich z.B. in einem Stream mit den Labels: pod-template-hash=bcf574bc8, app=nginx und stream=stdout.

Im Index von Loki werden diese Chunks mit den Labels des Streams und einem Zeitfenster verknüpft. Bei einer Suche muss im Index somit nur nach Labels und Zeitfenster gefiltert werden. Entspricht eine dieser Verknüpfungen den Suchkriterien, wird der Chunk aus dem Storage geladen und enthaltene Logs werden entsprechend der Suchanfrage gefiltert.

Chunk Storage

Im Chunk Storage werden die komprimierten und zerstückelten Log-Streams gespeichert. Wie beim Index kann auch hier zwischen verschiedenen Storage-Backends gewählt werden. Aufgrund der Größe der Chunks wird ein Object Store wie GCS, S3, Swift oder unser Ceph Object Store empfohlen. Die Replikation ist damit automatisch mit inbegriffen und die Chunks werden anhand eines Ablaufdatums auch selbständig vom Storage entfernt. In kleineren Projekten oder Entwicklungsumgebungen kann man aber natürlich auch mit einem lokalen Dateisystem beginnen.

Visualisierung mit Grafana

Zur Darstellung wird Grafana verwendet. Vorkonfigurierte Dashboards können leicht importiert werden. Als Query Language wird LogQL verwendet. Diese Eigenkreation von Grafana Labs lehnt sich stark an PromQL von Prometheus an und ist genauso schnell gelernt. Eine Abfrage besteht hierbei aus zwei Teilen:
Zuerst filtert man mithilfe von Labels und dem Log Stream Selector nach den entsprechenden Chunks. Mit = macht man hier immer einen exakten Vergleich und =~ erlaubt die Verwendungen von Regex. Wie üblich wird mit ! die Selektion negiert.
Nachdem man seine Suche auf bestimmte Chunks eingeschränkt hat, kann man diese mit einer Search Expression erweitern. Auch hier kann man mit verschiedenen Operatoren wie |= und |~ das Ergebnis weiter einschränken. Ein paar Beispiele zeigen wohl am schnellsten die Möglichkeiten:

Log Stream Selector:

{app = "nginx"}
{app != "nginx"}
{app =~ "ngin.*"}
{app !~ "nginx$"}
{app = "nginx", stream != "stdout"}
Search Expression:


{app = "nginx"} |= "192.168.0.1"
{app = "nginx"} != "192.168.0.1"
{app = "nginx"} |~ "192.*" 
{app = "nginx"} !~ "192$"

Weitere Möglichkeiten wie Aggregationen werden ausführlich in der offiziellen Dokumentation von LogQL erklärt.

Nach dieser kurzen Einführung in die Architektur und Funktionsweise von Grafana Loki legen wir natürlich gleich mit der Installation los. Viele weitere Informationen und Möglichkeiten zu Grafana Loki gibt es natürlich in der offiziellen Dokumentation.

Get it running!

Du willst Loki einfach ausprobieren?

Mit dem NWS Managed Kubernetes Cluster kannst du auf die Details verzichten! Mit einem Klick startest du deinen Loki Stack und hast dein Kubernetes Cluster immer voll im Blick!

 

Wie üblich mit Kubernetes ist ein laufendes Beispiel schneller deployed als die Erklärung gelesen. Mithilfe von Helm und einigen wenigen Variablen ist dein schlanker Logging Stack schnell installiert. Zuerst initialisieren wir zwei Helm-Repositories. Neben Grafana fügen wir auch noch das offizielle Helm stable Charts-Repository hinzu. Nach zwei kurzen helm repo add Befehlen haben wir Zugang zu den benötigten Loki und Grafana Charts.

Helm installieren

$ brew install helm
$ apt install helm
$ choco install kubernetes-helm

Dir fehlen die passenden Quellen? Auf helm.sh findest du eine kurze Anleitung für dein Betriebssystem.

 

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/

 

Loki und Grafana installieren

Für deinen ersten Loki-Stack benötigst du keine weitere Konfiguration. Die Default-Werte passen sehr gut und helm install erledigt den Rest. Vor der Installation von Grafana setzen wir zuerst noch dessen Konfiguration mithilfe der bekannten Helm-Values-Dateien. Speichere diese mit dem Namen grafana.values ab.

Neben dem Passwort für den Administrator wird auch das eben installierte Loki als Datenquelle gesetzt. Zur Visualisierung importieren wir gleich noch ein Dashboard und die dafür benötigten Plugins. Somit installiert du gleich ein für Loki konfiguriertes Grafana und kannst direkt nach dem Deploy loslegen.

grafana.values:

---
adminPassword: supersecret

datasources:
  datasources.yaml:
    apiVersion: 1
    datasources:
    - name: Loki
      type: loki
      url: http://loki-headless:3100
      jsonData:
        maxLines: 1000

plugins:
  - grafana-piechart-panel

dashboardProviders:
  dashboardproviders.yaml:
    apiVersion: 1
    providers:
      - name: default
        orgId: 1
        folder:
        type: file
        disableDeletion: true
        editable: false
        options:
          path: /var/lib/grafana/dashboards/default

dashboards:
  default:
    Logging:
      gnetId: 12611
      revison: 1
      datasource: Loki

 

Die eigentliche Installation erfolgt mithilfe von helm install. Der erste Parameter ist ein frei wählbarer Name. Mit dessen Hilfe kannst du dir auch schnell einen Überblick verschaffen:

$ helm install loki loki/loki-stack
$ helm install loki-grafana stable/grafana -f grafana.values
$ kubectl get all -n kube-system -l release=loki

 

Nach dem Deployment kannst du dich als admin mit dem Passwort supersecret einloggen. Damit du direkt auf das Grafana Webinterface zugreifen kannst, fehlt dir noch noch ein port-forward:

$ kubectl --namespace kube-system port-forward service/loki-grafana 3001:80

Die Logs deiner laufenden Pods sollten sofort im Grafana sichtbar sein. Probier doch die Queries unter Explore aus und erkunde das Dashboard!

 

Logging mit Loki und Grafana in Kubernetes – das Fazit

Grafana Labs bietet mit Loki einen neuen Ansatz für ein zentrales Logmanagement. Durch die Verwendung von kostengünstigen und leicht verfügbaren Object Stores wird eine aufwändige Administration eines Elasticsearch-Clusters überflüssig. Das einfache und schnelle Deployment ist auch ideal für Entwicklungsumgebungen geeignet. Zwar bieten die beiden Alternativen Kibana und Graylog ein mächtiges Featureset, aber für manche Administratoren ist Loki mit seinem schlanken und einfachen Stack vielleicht verlockender.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.
Kubernetes Nodegroups verwalten

Kubernetes Nodegroups verwalten

This entry is part 7 of 8 in the series Kubernetes - so startest Du durch!

Seit dieser Woche können unsere Kunden das “Nodegroup-Feature” für ihre NWS Managed Kubernetes Cluster nutzen. Was sind Nodegroups und was kann ich damit bewerkstelligen? Das und mehr erklärt unser siebter Blogpost der Serie.

Was sind Nodegroups?

Mit Nodegroups ist es möglich, mehrere Kubernetes-Node-Gruppen zu erstellen und unabhängig voneinander zu verwalten. Eine Nodegroup beschreibt eine Anzahl von virtuellen Maschinen, die als Gruppe diverse Attribute besitzt. Im Wesentlichen wird bestimmt, welches Flavor – also welches VM-Modell – innerhalb dieser Gruppe verwendet werden soll. Es sind aber auch andere Attribute wählbar. Jede Nodegroup kann unabhängig von den anderen jederzeit vertikal skaliert werden.

Wieso Nodegroups?

Nodegroups eignen sich, um Pods gezielt auf bestimmten Nodes auszuführen. Es ist zum Beispiel möglich, eine Gruppe mit dem “Availability-Zone”-Attribut zu definieren. Neben der bereits bestehenden “default-nodegroup”, die die Nodes relativ willkürlich über alle Verfügbarkeitszonen verteilt, können weitere Nodegroups erstellt werden, die jeweils nur in einer Verfügbarkeitszone explizit gestartet werden. Innerhalb des Kubernetes Clusters kann man seine Pods in die entsprechenden Verfügbarkeitszonen bzw. Node-Gruppen aufteilen.
Ein weiteres mögliches Szenario ist es, seine Nodegroups nach schnellen und langsameren VMs einzuteilen. Services und Anwendungen, die keine besonderen Ansprüche erheben, können der langsameren und somit meist auch günstigeren Nodegroup zugewiesen werden, während Pods mit mehr Anspruch ausschließlich auf schnellen Nodes betrieben werden. Der eigenen Fantasie und den eigenen Voraussetzungen wird durch die gewonnene Flexibilität Genüge getan. Neue Nodegroups lassen sich bequem über das NWS Web-Interface anlegen:

Existierende Nodegroups anzeigen


Im ersten Bild sieht man unseren exemplarischen Kubernetes Cluster “k8s-ses”. Dieser verfügt aktuell über zwei Nodegroups: “default-master” und “default-worker”.

 

Neue Nodegroup erstellen

Eine neue Nodegroup lässt sich über den Dialog “Create Nodegroup” mit folgenden Optionen erstellen:

  • Name: Name der Nodegroup, der später als Label für K8s genutzt werden kann
  • Flavor: Größe der eingesetzten virtuellen Maschinen
  • Node Count: Anzahl der initialen Nodes, kann später jederzeit vergrößert und verkleinert werden.
  • Availability Zone: eine spezifische Verfügbarkeitszone
  • Minimum Node Count: Die Nodegroup darf nicht weniger Nodes als den definierten Wert beinhalten.
  • Maximium Node Count: Die Nodegroup kann auf nicht mehr als die angegebene Anzahl Nodes anwachsen.

Die zwei letzten Optionen sind insbesondere für AutoScaling ausschlaggebend und begrenzen somit den automatischen Mechanismus.

 

 


Anschließend sieht man die neue Nodegroup in der Übersicht. Die Provisionierung der Nodes dauert nur wenige Minuten. Jede Gruppe lässt sich zudem individuell in ihrer Anzahl jederzeit verändern oder auch wieder entfernen.

 

Nodegroups im Kubernetes Cluster verwenden

Innerhalb des Kubernetes Clusters kann man seine neuen Nodes, nachdem sie fertig provisioniert wurden und einsatzbereit sind, sehen.

 
kubectl get nodes -L magnum.openstack.org/role
NAME                                 STATUS   ROLES    AGE   VERSION   ROLE
k8s-ses-6osreqalftvz-master-0        Ready    master   23h   v1.18.2   master
k8s-ses-6osreqalftvz-node-0          Ready    <none>   23h   v1.18.2   worker
k8s-ses-6osreqalftvz-node-1          Ready    <none>   23h   v1.18.2   worker
k8s-ses-zone-a-vrzkdalqjcud-node-0   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-1   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-2   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-3   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-4   Ready    <none>   31s   v1.18.2   zone-a

Die Node-Labels magnum.openstack.org/nodegroup und magnum.openstack.org/role tragen bei Nodes, die der Gruppe zugehörig sind, den Namen der Nodegroup. Zudem gibt es noch das Label topology.kubernetes.io/zone, das den Namen der Availability Zone trägt.

Mit Hilfe des nodeSelectors können Deployments oder Pods den Nodes bzw. Gruppen zugeordnet werden:

 
nodeSelector:
  magnum.openstack.org/role: zone-a

 

Du möchtest Dich selbst davon überzeugen, dass Managed Kubernetes bei NWS so einfach ist? Dann probiere es gleich aus auf: https://nws.netways.de/de/kubernetes/

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Persistente Volumes in Kubernetes erstellen

This entry is part 6 of 8 in the series Kubernetes - so startest Du durch!

Du willst ein persistentes Volume in Kubernetes erstellen? Hier erfährst du wie das mit Openstack Cinder im NWS Managed Kubernetes funktioniert.

Pods und Container sind per Definition mehr oder weniger flüchtige Komponenten in einem Kubernetes Cluster und werden je nach Notwendigkeit erstellt und zerstört. Viele Anwendungen wie Datenbanken können aber ohne langlebigen Storage nur selten sinnvoll betrieben werden. Mit dem Industriestandard Container Storage Interface (CSI) bietet Kubernetes eine einheitliche Integration für verschiedene Storage Backends zur Einbindung persistenter Volumes. Für unsere Managed Kubernetes Lösung verwenden wir die Openstack Komponente Cinder um persistente Volumes für Pods zur Verfügung zu stellen. Der CSI Cinder Controller ist für NWS Kubernetes ab Version 1.18.2 bereits aktiv und Du kannst mit nur einigen wenigen K8s Objekten persistente Volumes nutzen.

 

Persistente Volumes mit CSI Cinder Controller erstellen

Bevor Du ein Volume anlegen kannst, muss eine StorageClass mit Cinder als provisioner erstellt werden. Wie gewohnt werden die K8s-Objekte im YAML-Format und kubectl apply an dein Cluster gesendet:

storageclass.yaml:

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cinderStorage
provisioner: cinder.csi.openstack.org
allowVolumeExpansion: true
Du hast noch keine Erfahrung mit K8s und kubectl? Hier bekommst Du Hilfe für Deine ersten Schritte mit Kubernetes (klick)

 

Mit get und describe kannst Du überprüfen, ob das Anlegen funktioniert hat:

$ kubectl apply -f storageclass.yaml
$ kubectl get storageclass
$ kubectl describe storageclass cinderStorage

Auf Basis dieser Storage Klasse kannst Du nun beliebig viele Volumes erstellen.

 

Persistent Volume (PV) und Persistent Volume Claim (PVC)

Ein neues Volume kannst Du mit Hilfe eines peristentVolumeClaim erstellen. Der PVC beansprucht eine Ressource persistentVolume für Dich. Steht keine passende PV Ressource bereit, wird diese dynamisch durch den CSI Cinder Controller erstellt. PVC und PV werden aneinander gebunden und stehen exklusiv für Dich bereit. Ohne weitere Konfiguration wird ein dynamisch erstelltes PV mit dem Löschen des dazugehörigen PVC sofort gelöscht. Dieses Verhalten kann man in der oben definierten StorageClass mit Hilfe der reclaimPolicy überschreiben.

pvc.yaml:

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-documentroot
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: cinderStorage

 

Neben dem Namen werden im PVC-Objekt weitere Eigenschaften wie Größe und accessMode definiert. Nachdem Du das PVC mit kubectl apply im Cluster angelegt hast, wird im Hintergrund ein neues Volume im Storage Backend erstellt. Im Falle unseres NETWAYS Managed Kubernetes erstellt Cinder ein Volume als RBD im Ceph Cluster. Im nächsten Schritt wird Dein neues Volume in das document root eines Nginx Pods gemountet.

 

Pods und persistente Volumes

Für gewöhnlich werden Volumes im Kontext eines Pods definiert und haben somit auch den gleichen Lebenszyklus wie diese. Willst Du aber ein Volume verwenden, das unabhängig vom Pod und Container ist, kannst Du den eben erstellten PVC im volumes Bereich referenzieren und dann im Container unter volumeMounts einbinden. Im Beispiel wird das document root eines Nginx ersetzt.

deployment.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        volumeMounts:
          - mountPath: /usr/share/nginx/html
            name: documentroot
      volumes:
      - name: documentroot
        persistentVolumeClaim:
          claimName: nginx-documentroot
          readOnly: false
service.yaml:

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: nginx

 

Kubernetes und der CSI Cinder Controller sorgen natürlich dafür, dass Dein neues Volume und die dazugehörigen Pods immer am gleichen Worker Node gestartet werden. Mit kubectl kannst Du auch schnell die index.html anpassen und den K8s Proxy starten und schon kannst Du auf Deine neue index.html im persistenten Volume zugreifen:

$ kubectl exec -it deployment/nginx — bash -c ‘echo “CSI FTW” > /usr/share/nginx/html/index.html’
$ kubectl proxy

 

Fazit

Mit dem CSI Cinder Contoller kannst Du schnell und einfach persistente Volumes anlegen und verwalten. Weitere Features zum Erstellen von Snapshots oder dem Vergrößern der Volumes sind bereits enthalten. Und auch Möglichkeiten wie z.B. Multinode Attachment sind bereits in Planung. Deinem Datenbankcluster im Kubernetes steht also nichts mehr im Weg und auch das nächste spannende Thema in unsere Kubernetes Blogserie steht damit wohl fest!

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Monitoring Kubernetes mit Prometheus

This entry is part 5 of 8 in the series Kubernetes - so startest Du durch!

Monitoring – für viele eine gewisse Hass-Liebe. Die einen mögen es, die anderen verteufeln es. Ich gehöre zu denen, die es meist eher verteufeln, dann aber meckern, wenn man gewisse Metriken und Informationen nicht einsehen kann. Unabhängig der persönlichen Neigungen zu diesem Thema ist der Konsens aller jedoch sicher: Monitoring ist wichtig und ein Setup ist auch nur so gut wie sein dazugehöriges Monitoring.

Wer seine Anwendungen auf Basis von Kubernetes entwickeln und betreiben will, stellt sich zwangsläufig früher oder später die Frage, wie man diese Anwendungen und den Kubernetes Cluster überwachen kann. Eine Variante ist der Einsatz der Monitoringlösung Prometheus; genauer gesagt durch die Verwendung des Kubernetes Prometheus Operators. Eine beispielhafte und funktionale Lösung wird in diesem Blogpost gezeigt.

Kubernetes Operator

Kubernetes Operators sind kurz erklärt Erweiterungen, mit denen sich eigene Ressourcentypen erstellen lassen. Neben den Standard-Kubernetes-Ressourcen wie Pods, DaemonSets, Services usw. kann man mit Hilfe eines Operators auch eigene Ressourcen nutzen. In unserem Beispiel kommen neu hinzu: Prometheus, ServiceMonitor und weitere. Operators sind dann von großem Nutzen, wenn man für seine Anwendung spezielle manuelle Tasks ausführen muss, um sie ordentlich betreiben zu können. Das könnten beispielsweise Datenbank-Schema-Updates bei Versionsupdates sein, spezielle Backupjobs oder das Steuern von Ereignissen in verteilten Systemen. In der Regel laufen Operators – wie gewöhnliche Anwendungen auch – als Container innerhalb des Clusters.

Wie funktioniert es?

Die Grundidee ist, dass mit dem Prometheus Operator ein oder viele Prometheus-Instanzen gestartet werden, die wiederum durch den ServiceMonitor dynamisch konfiguriert werden. Das heißt, es kann an einem gewöhnlichen Kubernetes Service mit einem ServiceMonitor angedockt werden, der wiederum ebenfalls die Endpoints auslesen kann und die zugehörige Prometheus-Instanz entsprechend konfiguriert. Verändern sich der Service respektive die Endpoints, zum Beispiel in der Anzahl oder die Endpoints haben neue IPs, erkennt das der ServiceMonitor und konfiguriert die Prometheus-Instanz jedes Mal neu. Zusätzlich kann über Configmaps auch eine manuelle Konfiguration vorgenommen werden.

Voraussetzungen

Voraussetzung ist ein funktionierendes Kubernetes Cluster. Für das folgende Beispiel verwende ich einen NWS Managed Kubernetes Cluster in der Version 1.16.2.

Installation Prometheus Operator

Zuerst wird der Prometheus-Operator bereitgestellt. Es werden ein Deployment, eine benötigte ClusterRole mit zugehörigem ClusterRoleBinding und einem ServiceAccount definiert.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-operator
subjects:
- kind: ServiceAccount
  name: prometheus-operator
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
rules:
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
- apiGroups:
  - apiextensions.k8s.io
  resourceNames:
  - alertmanagers.monitoring.coreos.com
  - podmonitors.monitoring.coreos.com
  - prometheuses.monitoring.coreos.com
  - prometheusrules.monitoring.coreos.com
  - servicemonitors.monitoring.coreos.com
  - thanosrulers.monitoring.coreos.com
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - update
- apiGroups:
  - monitoring.coreos.com
  resources:
  - alertmanagers
  - alertmanagers/finalizers
  - prometheuses
  - prometheuses/finalizers
  - thanosrulers
  - thanosrulers/finalizers
  - servicemonitors
  - podmonitors
  - prometheusrules
  verbs:
  - '*'
- apiGroups:
  - apps
  resources:
  - statefulsets
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - configmaps
  - secrets
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list
  - delete
- apiGroups:
  - ""
  resources:
  - services
  - services/finalizers
  - endpoints
  verbs:
  - get
  - create
  - update
  - delete
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/component: controller
      app.kubernetes.io/name: prometheus-operator
  template:
    metadata:
      labels:
        app.kubernetes.io/component: controller
        app.kubernetes.io/name: prometheus-operator
        app.kubernetes.io/version: v0.38.0
    spec:
      containers:
      - args:
        - --kubelet-service=kube-system/kubelet
        - --logtostderr=true
        - --config-reloader-image=jimmidyson/configmap-reload:v0.3.0
        - --prometheus-config-reloader=quay.io/coreos/prometheus-config-reloader:v0.38.0
        image: quay.io/coreos/prometheus-operator:v0.38.0
        name: prometheus-operator
        ports:
        - containerPort: 8080
          name: http
        resources:
          limits:
            cpu: 200m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 100Mi
        securityContext:
          allowPrivilegeEscalation: false
      nodeSelector:
        beta.kubernetes.io/os: linux
      securityContext:
        runAsNonRoot: true
        runAsUser: 65534
      serviceAccountName: prometheus-operator
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
  namespace: default
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
    app.kubernetes.io/version: v0.38.0
  name: prometheus-operator
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: http
    port: 8080
    targetPort: http
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: prometheus-operator
$ kubectl apply -f 00-prometheus-operator.yaml
clusterrolebinding.rbac.authorization.k8s.io/prometheus-operator created
clusterrole.rbac.authorization.k8s.io/prometheus-operator created
deployment.apps/prometheus-operator created
serviceaccount/prometheus-operator created
service/prometheus-operator created

Role Based Access Control

Zusätzlich werden entsprechende Role Based Access Control (RBAC) Policies benötigt. Die Prometheus-Instanzen (StatefulSets), gestartet durch den Prometheus-Operator, starten Container unter dem gleichnamigen ServiceAccount “Prometheus”. Dieser Account benötigt lesenden Zugriff auf die Kubernetes API, um später die Informationen über Services und Endpoints auslesen zu können.

Clusterrole

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
$ kubectl apply -f 01-clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/prometheus created

 

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus
subjects:
- kind: ServiceAccount
  name: prometheus
  namespace: default
$ kubectl apply -f 01-clusterrolebinding.yaml
clusterrolebinding.rbac.authorization.k8s.io/prometheus created

 

ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus
$ kubectl apply -f 01-serviceaccount.yaml
serviceaccount/prometheus created

Monitoring von Kubernetes Cluster Nodes

Es gibt diverse Metriken, die aus einem Kubernetes Cluster ausgelesen werden können. In diesem Beispiel wird zunächst nur auf die Systemwerte der Kubernetes Nodes eingegangen. Für die Überwachung der Kubernetes Cluster Nodes bietet sich die ebenfalls vom Prometheus-Projekt bereitgestellte Software “Node Exporter” an. Diese liest sämtliche Metriken über CPU, Memory sowie I/O aus und stellt diese Werte unter /metrics zum Abruf bereit. Prometheus selbst “crawlet” diese Metriken später in regelmäßigen Abständen. Ein DaemonSet steuert, dass jeweils ein Container/Pod auf einem Kubernetes Node gestartet wird. Mit Hilfe des Services werden alle Endpoints unter einer Cluster IP zusammengefasst.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
      name: node-exporter
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - image: quay.io/prometheus/node-exporter:v0.18.1
        name: node-exporter
        ports:
        - containerPort: 9100
          hostPort: 9100
          name: scrape
        resources:
          requests:
            memory: 30Mi
            cpu: 100m
          limits:
            memory: 50Mi
            cpu: 200m
        volumeMounts:
        - name: proc
          readOnly:  true
          mountPath: /host/proc
        - name: sys
          readOnly: true
          mountPath: /host/sys
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: node-exporter
  annotations:
    prometheus.io/scrape: 'true'
  name: node-exporter
spec:
  ports:
  - name: metrics
    port: 9100
    protocol: TCP
  selector:
    app: node-exporter
$ kubectl apply -f 02-exporters.yaml
daemonset.apps/node-exporter created
service/node-exporter created

Service Monitor

Mit der sogenannten Third Party Ressource “ServiceMonitor”, bereitgestellt durch den Prometheus Operator, ist es möglich, den zuvor gestarteten Service, in unserem Fall node-exporter, für die zukünftige Überwachung aufzunehmen. Die TPR selbst erhält ein Label team: frontend, das wiederum später als Selector für die Prometheus-Instanz genutzt wird.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: node-exporter
  labels:
    team: frontend
spec:
  selector:
    matchLabels:
      app: node-exporter
  endpoints:
  - port: metrics
$ kubectl apply -f 03-service-monitor-node-exporter.yaml
servicemonitor.monitoring.coreos.com/node-exporter created

Prometheus-Instanz

Es wird eine Prometheus-Instanz definiert, die nun alle Services anhand der Labels sammelt und von deren Endpoints die Metriken bezieht.

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
spec:
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      team: frontend
  resources:
    requests:
      memory: 400Mi
  enableAdminAPI: false
$ kubectl apply -f 04-prometheus-service-monitor-selector.yaml
prometheus.monitoring.coreos.com/prometheus created

Prometheus Service

Die gestartete Prometheus-Instanz wird mit einem Service-Objekt exponiert. Nach einer kurzen Wartezeit ist ein Cloud-Loadbalancer gestartet, der aus dem Internet erreichbar ist und Anfragen zu unserer Prometheus-Instanz durchreicht.

apiVersion: v1
kind: Service
metadata:
  name: prometheus
spec:
  type: LoadBalancer
  ports:
  - name: web
    port: 9090
    protocol: TCP
    targetPort: web
  selector:
    prometheus: prometheus
$ kubectl apply -f 05-prometheus-service.yaml
service/prometheus created
$ kubectl get services
NAME         TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
prometheus   LoadBalancer   10.254.146.112    pending      9090:30214/TCP   58s

Sobald die externe IP-Adresse verfügbar ist, kann diese über http://x.x.x.x:9090/targets aufgerufen werden und man sieht alle seine Kubernetes Nodes, deren Metriken ab sofort regelmäßig abgerufen werden. Kommen später weitere Nodes hinzu, so werden diese automatisch mit aufgenommen bzw. wieder entfernt.

Visualisierung mit Grafana

Die gesammelten Metriken, lassen sich leicht und ansprechend mit Grafana visualisieren. Grafana ist ein Analyse-Tool, das diverse Datenbackends unterstützt.

apiVersion: v1
kind: Service
metadata:
  name: grafana
spec:
#  type: LoadBalancer
  ports:
  - port: 3000
    targetPort: 3000
  selector:
    app: grafana
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
spec:
  selector:
    matchLabels:
      app: grafana
  replicas: 1
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - image: grafana/grafana:latest
        name: grafana
        imagePullPolicy: Always
        ports:
        - containerPort: 3000
        env:
          - name: GF_AUTH_BASIC_ENABLED
            value: "false"
          - name: GF_AUTH_ANONYMOUS_ENABLED
            value: "true"
          - name: GF_AUTH_ANONYMOUS_ORG_ROLE
            value: Admin
          - name: GF_SERVER_ROOT_URL
            value: /api/v1/namespaces/default/services/grafana/proxy/
$ kubectl apply -f grafana.yaml
service/grafana created
deployment.apps/grafana created
$ kubectl proxy
Starting to serve on 127.0.0.1:8001

Sobald die Proxy-Verbindung durch kubectl verfügbar ist, kann die gestartete Grafana-Instanz via http://localhost:8001/api/v1/namespaces/default/services/grafana/proxy/ im Browser aufgerufen werden. Damit die in Prometheus vorliegenden Metriken jetzt auch visuell ansprechend dargestellt werden können, sind nur noch wenige weitere Schritte notwendig. Zuerst wird eine neue Data-Source vom Typ Prometheus angelegt. Dank des kuberneteseigenen und -internen DNS lautet die URL http://prometheus.default.svc:9090. Das Schema ist servicename.namespace.svc. Alternativ kann natürlich auch die Cluster-IP verwendet werden.

Für die gesammelten Metriken des node-exporters gibt es bereits ein sehr vollständiges Grafana-Dashboard, das sich über die Import-Funktion importieren lässt. Die ID des Dashboards ist 1860.

Nach dem erfolgreichem Import des Dashboards können jetzt die Metriken begutachtet werden.

Monitoring weiterer Anwendungen

Neben diesen eher technischen Statistiken sind auch weitere Metriken der eigenen Anwendungen möglich, beispielsweise HTTP Requests, SQL Queries, Business-Logik und vieles mehr. Hier werden einem durch das sehr flexible Datenformat kaum Grenzen gesetzt. Um seine eigenen Metriken zu sammeln, gibt es wie immer mehrere Lösungsansätze. Einer davon ist, seine Anwendung mit einem /metrics Endpunkt auszustatten. Manche Frameworks wie z.B. Ruby on Rails haben bereits brauchbare Erweiterungen. Ein weiterer Ansatz sind sogenannte Sidecars. Ein Sidecar ist ein zusätzlicher Container, der neben dem eigentlichen Anwendungscontainer mitläuft. Beide zusammen ergeben einen Pod, der sich Namespace, Netzwerk etc. teilt. In dem Sidecar läuft dann Code, der die Anwendung prüft und die Ergebnisse als parsebare Werte für Prometheus zur Verfügung stellt. Im Wesentlichen können beide Ansätze, wie im oben gezeigten Beispiel, mit dem Prometheus Operator verknüpft werden.

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Kubernetes Nginx Ingress Controller – So gelingt Dein einfacher Start!

This entry is part 4 of 8 in the series Kubernetes - so startest Du durch!

Kubernetes LogoMit den ersten Schritten mit Kubernetes weißt Du bereits, wie Du Anwendungen in Deinem Kubernetes Cluster startest. Nun exponieren wir Deine Anwendung online. Wie das Ganze funktioniert und wie Du mit einem Kubernetes Nginx Ingress Controller am besten selbst direkt loslegen kannst, erläutere ich Dir im Folgenden an einem Beispiel.

Um in einem Kubernetes Cluster Anwendungen von außen erreichbar zu machen, kann man einen Service vom Typ Loadbalancer verwenden. In der NETWAYS Cloud starten wir hier im Hintergrund ein Openstack Octavia LB mit öffentlicher IP und leiten den eingehenden Traffic an die Pods weiter (Bingo). Somit benötigen wir für jede Anwendung einen eigenen Loadbalancer mit öffentlicher IP. Um in einem Fall wie diesem etwas ressourcen- und somit kosteneffizienter arbeiten zu können, hat man vor Langem named-based virtual hosts und server name indication (sni) erfunden. Der altbekannte NGINX-Webserver unterstützt beides und als Kubernetes Ingress Controller kann dieser, mit nur einer öffentlichen IP-Adresse, all unsere http/s-Anwendungen schnell und einfach erreichbar machen.

Die Installation und die Aktualisierung des Ningx Ingress Controllers ist dank eines Helm Charts sehr vereinfacht. Mit K8s Ingress Objekten konfiguriert man die Zuordnung von vHosts, URI-Pfaden und TLS-Zertifikaten zu K8s Services und somit zu unseren Anwendungen. Damit die Buzzwords Dir nicht den Blick aufs Wesentliche verhindern, hier ein kleiner Überblick, wie die HTTP-Anfragen an unsere Anwendungen weitergeleitet werden:

 

Installation Kubernetes Nginx Ingress Controller

Helm Logo

Zur einfachen Installation des Kubernetes Nginx Ingress Controllers solltest Du Helm verwenden. Helm bezeichnet sich selbst als Paketmanager für Kubernetes-Anwendungen. Neben der Installation bietet Helm auch einfache Updates seiner Anwendungen. Wie auch bei kubectl brauchst Du nur die K8s-Config, um direkt loszulegen:

$ helm install my-ingress stable/nginx-ingress

 

 

Mit diesem Befehl startet Helm alle nötigen Komponenten im default Namespace und gibt diesen das Label my-ingress. Für den Nginx Ingress Controller wird ein deployment, ein replicaset und ein pod erstellt. Alle http/s-Anfragen müssen an diesen pod weitergeleitet werden, damit dieser anhand von vHosts und URI-Pfaden die Anfragen sortieren kann. Dafür wurde ein service vom Typ loadbalancer erstellt, welcher auf eine öffentliche IP lauscht und den ankommenden Traffic auf den Ports 443 und 80 an unseren pod weiterleitet. Ein ähnliches Konstrukt wird auch für das default-backend angelegt, auf welche ich hier aber nicht näher eingehe. Damit Du den Überblick nicht verlierst, kannst Du Dir alle beteiligten Komponenten mit kubectl anzeigen lassen:

$ kubectl get all -l release=my-ingress  #mit default-backend

$ kubectl get all -l release=my-ingress -l component=controller #ohne default-backend

NAME                                                             READY    STATUS      RESTARTS
pod/my-ingress-nginx-ingress-controller-5b649cbcd8-6hgz6         1/1      Running     0       

NAME                                                             READY    UP-TO-DATE  AVAILABLE
deployment.apps/my-ingress-nginx-ingress-controller              1/1      1           1        

NAME                                                             DESIRED  CURRENT     READY
replicaset.apps/my-ingress-nginx-ingress-controller-5b649cbcd8   1        1           1    

NAME                                              TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)
service/my-ingress-nginx-ingress-controller       LoadBalancer   10.254.252.54    185.233.188.56   80:32110/TCP,443:31428/TCP

 

Beispielanwendungen: Apache und Nginx

Als nächstes starten wir zwei einfache Beispielanwendungen. Im Beispiel verwende ich Apache und Nginx. Ziel ist es, beide Anwendungen unter eigenen name-based virtual hosts verfügbar zu machen: nginx.nws.netways.de und apache.nws.netways.de. Damit die beiden Deployments innerhalb des K8s Clusters erreichbar sind, müssen wir diese noch jeweils mit einem Service verbinden.

K8s Deployments

Nginx Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Apache Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache-deployment
  labels:
    app: apache
spec:
  replicas: 3
  selector:
    matchLabels:
      app: apache
  template:
    metadata:
      labels:
        app: apache
    spec:
      containers:
      - name: apache
        image: httpd:2.4
        ports:
        - containerPort: 80

K8s Service

Nginx Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: nginx
Apache Service

apiVersion: v1
kind: Service
metadata:
  name: apache-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: apache

 

Virtual Hosts ohne TLS

Um nun die Anfragen vom Nginx Controller zu unseren Anwendungen weiterzureichen, müssen wir ein passendes Kubernetes Ingress Objekt ausrollen. Im spec Bereich des Ingress Objekts können wir unterschiedliche Pfade und virtuell Hosts definieren. Im Beispiel sehen wir vHosts für nginx.nws.netways.de und apache.nws.netways.de. Für jeden der beiden vHosts ist im Bereich backend natürlich der entsprechende service eingetragen.

Die öffentliche IP findet man im service des Nginx Ingress Controllers und kubectl describe zeigt alle wichtigen Details zum Service (siehe unten). Zum Testen manipulierst Du am besten seine /etc/hosts Datei und trägst dort die IP von LoadBalancer Ingress ein.

K8s Ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: apache.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: apache-svc
            servicePort: 80
  - host: nginx.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: nginx-svc
            servicePort: 80

$ kubectl describe service/my-ingress-nginx-ingress-controller

$ kubectl get service/my-ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[].ip}’

 

Virtual Hosts mit TLS

Natürlich bietet man selten Anwendungen ohne Verschlüsselung öffentlich erreichbar an. Speziell für TLS-Zertifikate hat Kubernetes einen eigenen Typ tls innerhalb des secret Objekts. Alles was man benötigt ist ein TLS-Zertifikat und den dazugehörigen Schlüssel. Mit kubectl kannst Du das Pärchen in Kubernetes speichern:

$ kubectl create secret tls my-secret –key cert.key –cert cert.crt

Das angelegte secret kann dann durch den angegebenen Namen my-secret in spec des Ingress Objekts referenziert werden. Dazu gibst Du im Array hosts innerhalb von tls unser virtual host und das dazugehörige TLS-Zertifikat an. Ein automatischer Redirect von http auf https ist von Anfang an aktiviert.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  tls:
    - hosts:
      - apache.nws.netways.de
      - nginx.nws.netways.de
      secretName: my-secret
  rules:
  - host: apache.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: apache-svc
            servicePort: 80
  - host: nginx.nws.netways.de
    http:
      paths:
        - backend:
            serviceName: nginx-svc
            servicePort: 80

Fazit

Mit dem Nginx Ingress Controller ist es eine Leichtigkeit, Deine webbasierten Anwendungen öffentlich erreichbar zu machen. Die angebotenen Features und Konfigurationsmöglichkeiten sollten die Anforderungen aller Anwendungen abdecken und sind im offiziellen User Guide zu finden. Neben der eigenen Anwendung benötigst Du nur ein Helm Chart und ein K8s Ingress-Objekt. Kubernetes schafft es auch hier, mit nur wenigen abstrakten Objekten wie deployment und ingress viele komplexe Ebenen und Technologien zu verstecken. Mit einer NETWAYS Managed Kubernetes Lösung kannst Du die Vorteile dieser Abstraktion voll ausnutzen und Dich auf die eigene Anwendung konzentrieren. Na also: Leg los!

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

So startest Du Dein Managed Kubernetes bei NWS

This entry is part 2 of 8 in the series Kubernetes - so startest Du durch!

 

 

Dich interessiert, wie Du ein Managed Kubernetes bei NWS startest? Hier erfährst Du, wie du loslegen kannst! Zuerst benötigst Du einen Account für unsere NETWAYS Web Services Plattform. Nach der Registrierung kannst Du unsere Open Source-Apps wie RocketChat und GitLab starten und auch Zugänge zu Openstack und Kubernetes anlegen.

 

tl;dr – sehen statt lesen 

Christian zeigt Dir unser Managed Kubernetes übrigens im aufgezeichneten Webinar. Bilder sagen mehr als Tausend Worte ?

 

Du entscheidest Dich natürlich für einen Kubernetes-Zugang und kommst nach wenigen Klicks zur Ansicht zum Verwalten und Starten deiner Kubernetes Cluster.

 

Starte Dein Kubernetes Cluster

Das schwierigste beim Starten Deines Clusters ist wohl die Wahl des Namens. Das können wir Dir leider nicht abnehmen. Wie wäre es mit foobar? Aber bevor virtuelle Maschinen im Hintergrund starten, musst Du Dich jetzt noch für eine Control Plane entscheiden und die Anzahl deiner Worker Nodes festlegen.

Control Plane

Als Control Plane werden alle nötigen Dienste und Ressourcen zur Verwaltung und Steuerung deines Kubernetes Clusters bezeichnet. Diese Dienste können auf einem oder auf drei Master Nodes (VMs) gestartet werden. Letzteres hat den Vorteil, dass in einem Fehlerfall oder bei einem Update die Kubernetes-Dienste und -API trotzdem verfügbar sind. Zudem muss je nach Größe des geplanten Clusters ein Flavor für diese Master Nodes gewählt werden. Bitte beachte, dass Du die Anzahl der Master Nodes und den Flavor später nicht mehr ändern kannst.

Worker Nodes

Auf den Worker Nodes werden Deine Anwendungen gestartet, welche durch die Control Plane verwaltet und betrieben werden. Für eine hochverfügbare Anwendung benötigst Du davon mindestens zwei. Wie auch bei den Master Nodes musst Du ein Flavor auswählen. Aufgrund der auf Ressourcen basierenden Abrechnung fallen zum Beispiel für 16GB Ram immer die selben Kosten an, egal ob diese auf zwei oder vier VMs verteilt werden. Die Anzahl der Worker Nodes kannst Du jederzeit im NWS Webinterface an Deinen aktuellen Bedarf anpassen.

Das Starten des Clusters kann je nach Anzahl der Master- und Worker Nodes fünf bis 15 Minuten dauern. Es ist also genug Zeit für einen Kaffee. Im Hintergrund werden VMs, Floating IPs, Loadbalancer, Security Groups und vieles mehr Stück für Stück gestartet, konfiguriert und geprüft, bis Dein Kubernetes einsatzfähig ist. Und jetzt?

 

Verschaffe Dir einen Überblick im NWS Webinterface

Nachdem dein Cluster gestartet ist, gibt Dir das NWS Webinterface einen guten ersten Überblick. Dort findest Du wichtige Informationen und andere Möglichkeiten, um Dein Cluster zu steuern:

 

Zustand und Worker Nodes

Den Status Deiner Master- und Worker Nodes sowie die Erreichbarkeit der API kannst Du jederzeit im NWS Webinterface überprüfen. Solltest Du mehr Ressourcen benötigen, kannst Du die Anzahl Deiner Worker Nodes mit einigen wenigen Klicks anpassen und im Problemfall auch einen harten Neustart einzelner VMs durchführen.

Kubernetes Dashboard

Für einen einfacheren Einstieg haben wir bereits das Kubernetes Dashboard für Dich ausgerollt und vorbereitet. Ein einfacher Einblick gelingt in drei kleinen Schritten.

 

Object Store

Mit dem Start des Clusters bekommst Du auch einen Zugang zu unserem Object Store. Dieser basiert auf Ceph und ist mit der S3- und Swift-API kompatibel. Deine Daten werden über unsere ISO-27001 zertifizierten Rechenzentren repliziert und bleiben in Deutschland.

Cluster Update

Um Kubernetes Cluster-Updates für Dich so einfach wie möglich zu gestalten, werden diese von uns gründlich getestet. Aber damit Du die Kontrolle behältst, entscheidest Du per Knopfdruck, wann die Updates eingespielt werden. Neben den Kubernetes-Diensten wird auch das Betriebssystem der VMs aktualisiert. Im Falle einer hochverfügbaren Control Plane werden die Komponenten Stück für Stück aktualisiert, so dass kein Serviceausfall entsteht. Auch auf Deinen Worker Nodes werden die Anwendungen verschoben, so dass nach und nach einzelne VMs aktualisiert und neu gestartet werden können.

 

kubeconfig

Als kubeconfig bezeichnet man eine Datei, die alle Informationen enthält, um über das Kommando kubectl auf die Kubernetes-API zuzugreifen. Technisch enthält diese YAML-Datei den HTTP-Endpunkt der API, einen Benutzernamen und ein TLS-Client-Zertifikat mit CA. Im Webinterface kannst Du die Datei natürlich herunterladen und gleich unter $HOME/.kube/config speichern. Somit kannst Du ohne weitere Parameter Dein Cluster mit kubectl erkunden. Wie Du dies am schnellsten für Dein Betriebssystem installierst, erfährst du am besten aus der offiziellen Dokumentation.

 

Starte mit kubectl auf der Kommandozeile

Beim täglichen Arbeiten mit Kubernetes benötigst Du unser Webinterface leider nicht sehr oft. Die meiste Zeit wirst du auf der Kommandozeile verbringen. kubectl ist hier das zentrale Tool, um Deine Anwendungen im Cluster zu steuern. Zunächst solltest Du ein paar einfache Kommandos ausführen, um mit Deinem Cluster vertraut zu werden:

 

kubectl get nodes

Zeigt eine Liste deiner Nodes mit Status und Version.

kubectl describe node <Name>

Neben Labels, Pods und Metriken bekommst Du viele detaillierte Information zu Deinen Nodes.

 

kubectl explain <Ressourcentyp>

Mit explain kannst Du Dir schnell weitere Informationen zu einzelnen Ressourcentypen holen.

kubectl get all

Zeigt Dir eine Übersicht aller laufenden Ressourcen im default Namespace. Mit –all-namespaces siehst Du nicht nur Deine Anwendungen, sondern auch die Ressourcen des Kubernetes Clusters selbst.

 

Mit der kubeconfig und kubectl hast Du nun alles an der Hand, um zu starten. Mit was? Mit Teil 3 unserer Serie und deinen ersten Schritten in Kubernetes. Dort erfährst Du mehr über deployments, pods und services und wie Du Deine erste Anwendung ausrollst.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.