Kubernetes Nodegroups verwalten

Kubernetes Nodegroups verwalten

This entry is part 7 of 7 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.

Monitoring Kubernetes mit Prometheus

This entry is part 5 of 7 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.

Wie ich meine Open Source-Apps und MyEngineers zu schätzen gelernt habe

Corona-Lockdown: Und plötzlich sind fast alle im Homeoffice… So war das zumindest bei uns. Und sicher auch bei vielen von euch!

Für mich hatten die Apps, die mir auch vorher schon die tägliche Zusammenarbeit mit Kolleg*innen erleichtert haben, schlagartig einen noch viel höheren Stellenwert. Das gute Rocket.Chat, in dem ich mich in verschiedenen Kanälen mit departmentübergreifenden Teams auf kurzem Weg zum jeweiligen gemeinsamen Projekt austausche oder in dem ich der Kollegin im privaten Channel schreibe. Normalerweise würde sie neben mir sitzen, jetzt sitzt sie am anderen Ende der Welt im indischen Lockdown fest… Jitsi, mit dem wir unsere täglichen “Telkos” abhalten. Notiz an mich: Nicht vergessen, die Frisur zurecht zu rücken, bevor ich die Kamera aktiviere! Oder der Request Tracker, mit dem ich meine täglichen ToDo’s verwalte, der aber viel mehr ist: Projektmanagement-Tool, das mich via E-Mail benachrichtigt und außerdem alle anderen, die mit auf dem Ticket sind und vom Status und Fortschritt einer Aufgabe erfahren sollen. Die gesamte Kommunikation mit Kunden oder Kollegen an einem Ort gesammelt: Da geht keine Info stiften. Und weil ich ja meine coolen NETWAYS Web Services-Kollegen habe, die sich um die Technik kümmern, kann ich ganz entspannt die Dienste nutzen und muss mir keine Gedanken machen über Sicherheit, Updates, Backups, Betrieb und so: Das läuft einfach!

Das sind sie übrigens:

Vielleicht seid Ihr im Rahmen unserer Aktion #StayAtHome ja auch in den Genuss gekommen…

Manche von Euch werden sicher noch länger mit veränderten Arbeitsbedingungen zu tun haben, die plötzlich viel digitaler sind als jemals zuvor. Lehrer*innen zum Beispiel. Andere arbeiten wahrscheinlich schon immer viel am PC, jetzt aber fast ausschließlich, so wie ich. Ich weiß meine Apps jetzt jedenfalls viel mehr zu schätzen und will die zusätzlich gewonnenen Feinheiten in Kommunikation und Arbeitsabläufen nicht mehr missen. Vielleicht seid ihr aber auch dafür verantwortlich, dass die IT einer Organisation, einer Firma oder öffentlichen Einrichtung funktioniert. Wir unterstützen Euch gerne! Wir bieten professionelle IT-Dienstleistungen auf allen Ebenen. (Ja, auch wenn da oben eine Micky Maus auf diesem Pulli ist! Homeoffice halt.)

Neben den fertigen Open Source-Apps gibt es mit der NETWAYS Cloud eine individuelle “Infrastructure as a Service” oder mit NETWAYS Managed Kubernetes Deine private Container-Plattform. Mit dem MyEngineer sind wir zudem immer persönlich für unsere Kund*innen da. Egal ob IT-Beratung, Betrieb inklusive aller Sicherheitsstandards und Backups, Migration oder Troubleshooting: Wir unterstützen Dich!

Flexibel. Passioniert. Open Source. Überzeuge Dich selbst!

Open Source-Apps

Starte Deine Lieblings-Open-Source-Apps in wenigen Minuten. Wir helfen Dir gerne, sie nahtlos in Deine Arbeitsumgebung zu integrieren!

Unsere Apps:

  • Nextcloud – Ein sicherer Platz zum Ablegen & Teilen Deiner Daten
  • Rocket.Chat – Kommunikation multimedial & in mehreren Kanälen
  • Jitsi – Dein Open Source Videoconferencing Tool
  • GitLab – Projektmanagement, nicht nur für Entwickler*innen
  • Request Tracker – Verwaltung von Anfragen & Aufgaben, perfekt ins E-Mail-System integrierbar

und viele weitere Open Source Apps

NETWAYS Cloud

Du brauchst Online-Ressourcen? Die NETWAYS Cloud ist ideal zum Erstellen oder Erweitern Deiner IT-Infrastruktur. Wir helfen Dir, Deine Infrastruktur maßzuschneidern und die passenden Komponenten zu finden: Virtuelle Maschinen, Betriebssysteme, flexible Datenspeicher und Netzwerke. Gemeinsam bauen wir Deine IT, die Du mit ein bisschen Übung ganz leicht selbst erweitern und umbauen kannst.

Jetzt in die NETWAYS Cloud starten!

NETWAYS Managed Kubernetes

Du willst mit Containern arbeiten? Kubernetes ist klarer Sieger im Kampf um die Container-Orchestrierung. Dabei geht es um viel mehr, als nur Container auf einer Vielzahl von Nodes zu starten. Wir empfehlen unsere Blog-Serie “Kubernetes – so startest Du durch!” Der einfachste Weg zum funktionalen Kubernetes-Cluster ist sicherlich unser NETWAYS Managed Kubernetes-Angebot.

NETWAYS MyEngineer

Mit unseren MyEngineers startest Du durch – Dank persönlichem, direktem Kontakt und kompetenter Unterstützung. Gemeinsam finden wir Deine beste Lösung!

Erfahre mehr über unseren MyEngineer!

Fragen? Kontaktiere uns!

Wir haben einen Live-Chat auf unserer Webseite!
Außerdem:
+49 911 92885 0
info@netways.de
nws.netways.de

Wir freuen uns, von Dir zu hören!

Julia Hornung
Julia Hornung
Senior Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

So startest Du Dein Managed Kubernetes bei NWS

This entry is part 2 of 7 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.

Managed Kubernetes vs. Kubernetes On-Premises

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

Managed Kubernetes vs. Kubernetes On-Premises – setze ich auf ein Managed Kubernetes-Angebot oder betreibe ich Kubernetes besser selbst?

Für manche stellt sich diese Frage natürlich erst gar nicht, da es vom Konzern oder dem eigenen Betrieb strategisch vorgegeben wird. Für alle anderen sollen die folgenden Zeilen helfen, einen Überblick über die Vor- und Nachteile von Managed Kubernetes und On-Premises zu erhalten und auf technische Herausforderungen hinzuweisen.

Wieso Kubernetes?

Um auch Leser abzuholen, die noch nicht ganz soweit sind, möchte ich einleitend nicht unerwähnt lassen, wieso es eigentlich so einen Hype um Kubernetes gibt und warum man sich unbedingt damit befassen sollte.

Kubernetes ist klarer Sieger im Kampf um die Container-Orchestrierung. Dabei geht es um viel mehr, als nur Container auf einer Vielzahl von Nodes zu starten. Es ist die Art und Weise, wie die Anwendung von der Infrastruktur entkoppelt und abstrahiert wird. Textbasierte und versionierbare Konfigurationsdateien, ein ziemlich komplettes Featureset, das Ökosystem der Cloud Native Computing Foundation und andere Third-Party-Integrationen sind aktuell ein Garant für den Erfolg des Frameworks. Kein Wunder, dass es derzeit – trotz relativ steiler Lernkurve – “Developer’s Darling” ist.

Kubernetes versteht sich selbst als “First-Class-Citizen” der Cloud. Mit Cloud sind hier die Infrastructure as a Service-Angebote der Hyperscaler wie AWS, Azure und Google, aber natürlich auch anderer Hoster wie beispielsweise NETWAYS gemeint. Auf Basis dieser bereits bestehenden IaaS-Infrastruktur fühlt sich Kubernetes besonders wohl, denn es werden zum Beispiel Infrastrukturdienste für Storage und Netzwerk wiederverwendet. Das besondere an Kubernetes ist zudem, dass es “cloud-agnostic” ist. Das bedeutet, die eingesetzte Cloud wird abstrahiert und man ist vom Cloud-Dienstleister unabhängig. Ebenfalls sind Multi-Cloud-Strategien möglich.

In unserem Webinar und unserer Kubernetes-Blogserie wird der Einstieg in Kubernetes und dessen Möglichkeiten gezeigt und erklärt.

Managed Kubernetes

Der einfachste Weg zu einem funktionalen Kubernetes Cluster ist sicherlich, die Verwendung eines Managed Kubernetes-Angebots. Managed Kubernetes-Angebote sind nach nur wenigen Klicks und somit in nur wenigen Minuten einsatzbereit und beinhalten in der Regel eine betreute Kubernetes Control-Plane und zugehörige Nodes. Als Kunde konsumiert man eine wahlweise hochverfügbare Kubernetes API, über die letztendlich das Kubernetes Cluster bedient wird. Der Anbieter kümmert sich anschließend um Updates, Verfügbarkeit und Betrieb des K8s-Clusters. Bezahlt wird nach eingesetzten und verwendeten Cloud-Ressourcen. Im Abrechnungsmodell gibt es nur marginale Unterschiede. Manche Anbieter werben mit einer kostenfreien Control-Plane, dafür kosten dann die eingesetzten VMs wiederum mehr.

Die technischen Features sind umfassend, die Unterschiede zwischen den Angeboten aber eher minimal. Es gibt Unterschiede in der eingesetzten Kubernetes-Version, der Anzahl von Verfügbarkeitszonen und Regionen, der Möglichkeit für High-Availability-Cluster und Auto-Scaling oder ob zum Beispiel eine aktivierte Kubernetes RBAC-Implementation zum Einsatz kommt.

Der echte Vorteil eines Managed Kubernetes-Angebots ist, dass man sofort starten kann, kein operatives Datacenter- und Kubernetes-Fachwissen benötigt und sich auf die Expertise des jeweiligen Anbieters stützen kann.

Kubernetes On-Premises

Im totalen Kontrast steht dazu die Variante, sein Kubernetes bei sich im Rechenzentrum selbst zu betreiben. Um im eigenen Rechenzentrum eine cloudähnliche Funktionalität zu erreichen, müssten die Managed Kubernetes-Lösungen weitestgehend nachgebaut werden. Das hat es durchaus in sich – soviel sei vorab verraten. Wer Glück hat, betreibt bereits einige notwendige Komponenten. Technisch gibt es nämlich einige Herausforderungen:

  • Automatische Deployments

Für das Deployment eines oder mehrerer Kubernetes Cluster und zur Gewährleistung der Konsistenz, ist es ratsam – wenn nicht sogar zwingend notwendig – einen automatischen Deployment-Prozess einzurichten, sprich Configuration Management mit z.B. Ansible oder Puppet in Kombination mit dem Bootstrapping-Tool kubeadm. Alternativ gibt es Projekte wie kubespray, die mit Ansible Playbooks Kubernetes Cluster bereitstellen können.

  • Netzwerk

Neben dem eigentlichen Netzwerk, in dem sich die Nodes befinden, bildet Kubernetes innerhalb des Clusters ein zusätzliches Netzwerk. Eine Herausforderung ist die Wahl des passenden Container Network Interfaces. Das Verständnis für Lösungen, die Technologien wie VXLAN oder BGP einsetzen, ist ebenfalls zwingend erforderlich und hilfreich. Zusätzlich gibt es eine Besonderheit für Ingress-Traffic, der in das Cluster-Netzwerk geleitet wird. Für diese Art Traffic erstellt man für gewöhnlich ein Kubernetes-Service-Objekt mit dem Typ “Loadbalancer”. Kubernetes verwaltet dann diesen externen Loadbalancer. In einer IaaS Cloud mit LBaaS-Funktionalität kein Problem, aber in einem Rechenzentrum gestaltet sich das unter Umständen jedoch schwerer. Proprietäre Loadbalancer oder das Open Source-Projekt MetalLB können hilfreich sein.

  • Storage

Ähnlich wie mit der Auswahl des passenden CNIs gestaltet es sich teilweise schwer mit der richtigen Auswahl des Storage Volume Plugins. Zudem muss natürlich auch das passende Storage betrieben werden. Beliebt und geeignet ist zum Beispiel Ceph.

Ob man sich diesen technischen Herausforderungen stellen will, kann man als Leser vermutlich schnell selbst beantworten. Sie sollten jedoch keinesfalls unterschätzt werden.
Als Gegenwert für den harten und eher steinigen Weg erhält man dafür mit dem eigenen Setup definitv Unabhängigkeit gegenüber Dritten und stets die volle Kontrolle über seine IT. Ebenso wertvoll kann das erlernte Know-how sein. Finanziell hängt es stark von bereits existierenden Strukturen und Komponenten ab, ob es einen tatsächlichen Vorteil gibt. Vergleicht man nur die Kosten für Compute-Ressourcen, mag es durchaus günstiger sein. Nicht zu unterschätzen sind jedoch die enormen initialen Zeitaufwände für Evaluierung, Proof of Concept, Setup und der anschließende ständige Aufwand für den Betrieb.

Fazit

Wie immer gibt es für die beiden vorgestellten Varianten Managed Kubernetes und Kubernetes On-Premises Vor- und Nachteile. Je nach Unternehmen, Struktur und Personal gibt es sicher gute Gründe, sich für die eine oder die andere Variante zu entscheiden. Klar gibt es auch Hersteller, die den Spagat zwischen beiden Welten versuchen. Welche Art für ein Unternehmen die effizienteste und sinnvollste ist, muss also ganz individuell beantwortet werden.
Tendiert man zu einer Managed Lösung, gibt es gute Gründe, sich für NETWAYS Managed Kubernetes zu entscheiden. Da wäre zum Beispiel unser engagiertes Team mit unseren kompetenten MyEngineers, die unsere Kunden erfolgreich auf dem Weg in die Welt der Container begleiten. Ein weiterer Grund ist der direkte und persönliche Kontakt zu uns. Andere gute Gründe und Vorteile erklären meine Kolleginnen und Kollegen oder ich auch gerne persönlich.

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.

NETWAYS Managed Kubernetes. Auf in die Welt der Container!

Stolz können wir verkünden: Wir haben ab sofort Kubernetes (K8s) als “NETWAYS Managed Kubernetes” neu in unserem Managed und Web Services-Portfolio.

Kubernetes ist griechisch und bedeutet Steuermann. Der Name passt, denn das Open Source-System gibt wie ein Steuermann den Weg zur Bereitstellung, Skalierung und Verwaltung von Containern vor. Du definierst, was Du willst und Kubernetes steuert alles, was an Infrastruktur auf dem Weg dorthin nötig ist.

Ein ganz großer Vorteil von Kubernetes: Services werden in Containern automatisch auf den kompletten Kubernetes-Cluster verteilt. Die vorhandenen Ressourcen werden dabei optimal ausgenutzt. Die Herausforderung: K8s braucht die richtigen Ressourcen zur richtigen Zeit, der Kubernetes-Cluster muss hochverfügbar gebaut sein und bestens gepflegt werden, um skalieren zu können.

Ich könnte jetzt darüber witzeln, dass Sebastian, unser Head of Managed Services, Kopf der NWS-Mannschaft, Saemann heißt, also irgendwie ähnlich, und muss bei dem Gedanken daran wirklich ein bisschen schmunzeln. Weil das ja irgendwie gut passt. Der Saemann und seine Mannschaft bereiten den Boden, auf dem der Steuermann seine Container automatisch dirigieren kann. So ist das mit unserem Managed Kubernetes.

Also gut – damit ihr wisst, was ich meine, hier ein paar Fakten.

Das bietet NETWAYS Managed Kubernetes:

  • Cluster-Erstellung in Minuten | Cluster-Status definieren, die Anzahl der Nodes (früher Minions) festlegen, kubectl starten: Nach nur wenigen Schritten ist Dein Kubernetes bereit. Wir helfen Dir gern dabei!
  • Managed Control Plane | Auf Wunsch überwachen und betreiben wir die Control Plane für Dich, auch 24/7.
  • Object Storage | Du kannst lokalen Speicher oder Ceph-Speicher verwenden. Objekte werden über unsere zwei ISO 27001-zertifizierte Rechenzentren repliziert.
  • Offene Standards und APIs | Alle Kubernetes-Cluster sind kompatibel mit dem Upstream-Projekt. Ebenso die zugrunde liegende Infrastruktur, die auf OpenStack basiert. Eh klar. Wir lieben Open Source!
  • Persistente Volume Claims | Ermöglichen die Speicherung von Daten über den Lebenszyklus des Containers hinaus.
  • Load Balancer | Load Balancing und die DNS-Verwaltung erfolgen automatisch. Auf Wunsch stellen wir Dir Services und Ingress-Controller bereit.

Kubernetes unterstützt eine Reihe von Container-Runtime-Engines, einschließlich Docker. Es wird in vielen IT-Abteilungen häufig als eine Möglichkeit verwendet, eine auf Microservices basierende Anwendung zu betreiben. Das enorme Ökosystem und die verbreitete Integration in Drittanwendungen ist Garant für reibungslose Continuous Integration und Deployment-Prozesse.

Das Kubernetes-Projekt wurde von Google-Entwicklern initiiert und wird von der Cloud Native Computing Foundation (CNCF) betrieben. Die CNCF ist Teil der gemeinnützigen Linux Foundation.

Kubernetes – der De-facto-Standard im agilen Software-Entwicklungsumfeld

“Kubernetes ist der De-facto-Standard für moderne und zukunftsorientierte Anwendungen im agilen Software-Entwicklungsumfeld”, sagt Sebastian und zeigt sich stolz, diesen Service jetzt anbieten zu können.

Du willst mehr wissen? Oder direkt Deine ersten eigenen Container starten?

Dann schau doch mal auf nws.netways.de/kubernetes.

Julia Hornung
Julia Hornung
Senior Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.