Monitoring Kubernetes mit Prometheus

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

Managed Kubernetes vs. Kubernetes On-Premises

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

Edge-Cloud-Computing – Cloud to the Edge

Während man in Deutschland immer noch und immer wieder in Funklöchern sitzt und oftmals nur 2G als Datenübertragung nutzen kann, bereitet sich die Welt – auch Deutschland – auf den nächsten Standard vor: 5G. Die neue Generation besticht durch hohe Bandbreiten (~1-20Gbps), niedrige Latenzen und eine hohe mögliche Dichte von Geräten auf neuen Frequenzbändern, die natürlich heiß begehrt sind. Braucht man aber solch hohe Bandbreiten und niedrige Latenzen um seine E-Mails zu checken oder Social Media Inhalte zu betrachten? Wohl eher nicht. Diese neuen Anforderungen an das Netzwerk benötigen aber Anwendungen, die in Zukunft vermutlich nicht mehr wegzudenken sind und maßgeblich unsere Welt verändern könnten – so zumindest die Vision. Autonomes Fahren, künstliche Intelligenz, Augmented- und Virtual-Reality und Internet of Things sind nur einige Anwendungsbereiche, die durch den neuen Standard ihre Möglichkeiten besser ausschöpfen können.

Ein völlig autonom fahrendes Auto, gespickt mit mehreren hundert Sensoren und vielen Kameras, produziert eine gewaltige Menge an Daten, die in einer Cloud zum Beispiel zur Koordination anderer Fahrzeuge eingespeist und verarbeitet werden. Ein weiteres Beispiel wäre die Videoüberwachung in einer U-Bahn kombiniert mit den Aufzeichnungen der Kameras vom Bahnsteig, die in Echtzeit menschliche Verhaltensmuster analysiert oder gar erlernt und entsprechend entscheidet. Benötigt es eine Vollbremsung, weil ein Passant gerade am Bahnsteig mit böser Absicht geschubst wird oder ist es eher eine harmlose Situation unter Freunden? Damit das funktioniert, benötigt man nicht nur ein schnelles Mobilfunknetz sondern auch Edge-Cloud-Computing.

Edge-Cloud-Computing

Edge-Cloud-Computing ist zu Recht einer der letzten und heißesten Trends im Bereich Cloud-Computing. Dabei gilt es, seine zentrale Cloud an den Rand (Edge) zu bewegen – also näher an den Kunden. Mit anderen Worten eine verteilte Cloud. Was genau jetzt der Rand sein soll ist noch nicht so ganz klar, man nimmt einen Bereich an, der nicht weiter als 20ms vom Endgerät entfernt ist. An diesem Rand ist es also nun notwendig, seine Cloud-Compute-Ressourcen verfügbar zu haben und nutzen zu können, um entsprechende Workload darauf zu betreiben. Ob die Workload in Containern, VMs oder Bare-Metal betrieben wird ist eher nachrangig zu betrachten, der Mix wird es sein. Dabei stützt man sich auf bestehende Technologie-Komponenten wie etwa Ceph, Qemu, Kubernetes, DPDK, OpenVSwitch und so weiter. 5G alleine wird also ohne Edge-Computing vermutlich nicht reichen, um zukünftigen Anwendungen gerecht zu werden.

Die beiden Open-Source Cloud-Lösungen, OpenNebula und OpenStack, die wir auch bei NETWAYS im Einsatz haben, sind natürlich bereits auf den Hype-Train aufgesprungen. OpenNebula hat gleich ihr gestriges Release 5.8 dem Codenamen “Edge” verpasst und OpenStack hat mit StarlingX sein eigenes Projekt und ein “Edge Computing Group” Gremium ins Leben gerufen.

Man kann wirklich gespannt sein was die Zukunft bringen wird und wie die Herausforderungen technisch realisiert werden.

Anwendungen, die ohne 5G und Edge auskommen, können aber auch schon heute in unserer Cloud basierend auf OpenStack modern, zeitgemäß und zukunftssicher betrieben 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.

Road to OpenStack

Seit bereits sieben Jahren betreiben wir bei NETWAYS eine Private Cloud Installation auf Basis von OpenNebula. Damals starteten wir gerade einmal mit drei Hypervisor Servern und einem NFS-Datastore, bereitgestellt aus einer Netapp 3140. Bis heute hat sich daran natürlich einiges verändert. Die Technologien haben sich geändert, als auch die notwendigen Ressourcen sind deutlich gestiegen. Heute laufen zum Beispiel unsere virtuellen Maschinen nicht mehr auf NFS sonder auf Ceph RBDs. Das Ceph-Cluster, verteilt über zwei Standorte, umfasst aktuell knapp ein halbes Petabyte Storage Kapazität.
OpenNebula hat uns während dieser Zeit der Transformation immer gut und zuverlässig zur Seite gestanden. Sämtliche Upgrades verliefen meist tadellos. Deshalb ist es fast ein bisschen Schade, diesem tollem Open-Source-Projekt den Rücken zu kehren und von nun an mit dem Platzhirsch OpenStack zu liebäugeln. Einer der Hauptgründe diesen Schritt zu gehen – neben beispielsweise der oft besseren und breiteren Verfügbarkeit an Integrationen und Tools von Dritten (z.B. Foreman, Puppet, Terraform usw.) – ist Software Defined Networking. Kurz SDN. Natürlich gibt es hierfür auch gute Ansätze und eine Basis-Unterstützung im OpenNebula Projekt. Theoretisch gibt es sogar die Möglichkeit fast jeden SDN Provider in OpenNebula, dank seiner Erweiterbarkeit, zu integrieren, aber leider nicht ohne selbst vorher ordentlich Pionierarbeit leisten zu müssen. Bei OpenStack hat man eher die Qual der Wahl, welcher SDN Provider für sein Setup passt.
Mit SDN virtualisiert man in einem Overlay Netzwerk ein künstliches und unabhängiges Netzwerk, ohne dass man das Underlay, die tatsächliche Hardware z.B. Switches und Router, auf die jeweiligen Umstände und Anforderungen anpassen muss. Die Vorteile liegen dabei auf der Hand: Im Underlay hat man ein stabiles Trägernetzwerk, dass man im Prinzip nur noch skalieren und robust betreiben muss und im Overlay werden die Anforderungen der Kunden realisiert. Wir setzen hierbei im Underlay auf Cumulus Linux in Kombination mit Mellanox Hardware und im Overlay auf die SDN Lösung von Midonet. Beides harmoniert gut miteinander und kann entsprechend verknüpft werden.
In unserer neuen Cloud-Installation ist es für uns und unsere Kunden dann dadurch möglich im Self-Service sich Netzwerke, Router, VPNs, Load-Balancer und Firewall-Regeln zu erstellen, ohne hierfür vom Administrator Hilfe und Beistand einzufordern. Auch überlappende private Netzwerke sind dann kein Problem und eine Pflege und penible Vergabe von IPs und Subnetzen bzw. VLANs fallen somit vom Tisch.
Klar ist, der Self-Service Part könnte mit OpenNebula in unserer bisherigen Installation ebenfalls gelöst werden, allerdings beeindruckt insbesondere die technische Umsetzung und das sehr raffinierte und intelligente Konzept der SDN Lösung von Midonet. Wie das ganze technisch funktioniert erklären wir im Blog in einem unserer nächsten Artikel.

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.

Docker Overlay Network

In den letzten Versionen von Docker hat sich im Bereich Netzwerk einiges getan. Man konnte sich zwar schon seit längerem mit Projekten wie Calico, Flannel oder Socketplane ein Multihost Docker Netzwerk schaffen, aber seit dem Zusammenschluss von Docker und Socketplane und dem daraus gewachsenem libnetwork gibt es jetzt Multihost Docker Networking out of the box.
Damit man es nutzen kann benötigt man neben einer sehr aktuellen Docker Version auch einen zentralen Key-Value Store wie Zookeeper, Etcd oder Consul. Sofern alles richtig konfiguriert ist, erstellt man ein Netzwerk vom Typ ‘Overlay’ mit dem Docker-CLI oder wer es braucht über die Docker API.
docker network create --driver overlay --subnet=10.0.9.0/24 my-net

Ein Container, der sich diesem Netz anschließen soll wird dann ebenfalls wie gewohnt gestartet, jedoch zusätzlich mit dem Zusatz --net, der das entsprechende Netzwerk bestimmt.
docker run -itd --name=web --net=my-net nginx

Ein zweiter, dritter oder x-ter Container auf anderen Hosts wird nach dem gleichem Schema gestartet und schon hat man in dem angegeben IP-Subnetz ein eigenes und neues isoliertes Netzwerk über mehrere Hosts hinweg, über das die Container direkt miteinander kommunizieren können, ohne Umwege wie z.B. über einen Service-Discovery Loadbalancer machen zu müssen.
Das ganze wirkt fast schon magisch und ist für ein so komplexes Thema super leicht zu konfigurieren und zu nutzen. Hinter den Kulissen wird über den VxLAN Standard ein Layer2 Netzwerk (10.0.0.9/24) über Layer4 (UDP) hinweg getunnelt. Das Virtual extensible LAN verhält sich ähnlich zu einem gewöhnlichen Layer2 VLAN, hat jedoch in sehr großen Umgebungen seinem etabliertem VLAN Namensvetter einiges voraus. Die Anzahl der möglichen VLANs wächst von 4094 auf über 16 Millionen. Broadcast Traffic wird zu Multicasts gemapped und vieles mehr.
Wer mehr zu dem Thema wissen will und in entspannter Atmosphäre und isolierten Testumgebung ausprobieren möchte, dem sind unsere Docker Trainings und auch der Docker Workshop vor der OSDC sehr zu empfehlen.

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.

CoreOS und etcd

Im zweiten Teil der Serie wird eine Kernkomponente von CoreOS beschrieben: etcd. Etcd ist ein distributed Key-Value-Store, der für die Konfiguration und das Service-Discovery innerhalb eines CoreOS Clusters verantwortlich ist. Wie viele Tools im Docker Umfeld ist auch etcd in Go geschrieben. Es zeichnet sich durch seine Geschwindigkeit, Verlässlichkeit, Sicherheit und Einfachheit aus. Für sein Konsens verwendet es das Raft Protokoll. Etcd kann man über API (HTTP+JSON) sowie über ein Command Line Interface (etcdctl) steuern.
Ein Beispiel verdeutlicht sehr schnell und einfach, wie etcd verwendet werden kann, um Daten zu schreiben bzw. sie wieder auszulesen:
$ etcdctl set /message Hello
Hello

$ etcdctl get /message
Hello

oder per HTTP-API
$ curl -L -X PUT http://127.0.0.1:4001/v2/keys/message -d value="Hello"
{"action":"set","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}

$ curl -L http://127.0.0.1:4001/v2/keys/message
{"action":"get","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}

Neben der erwähnten Konfiguration des CoreOS Clusters selbst ist es möglich seine gestarteten Container mit Hilfe von etcd wieder zu finden. Das Schlüsselwort ist “Service-Discovery”. Hierfür wird meist ein Sidekick Prozess gemeinsam mit dem eigentlichen Anwendungscontainer gestartet. Der Sidekick kümmert sich hierbei um das Registrieren der Anwendung. Wie im ersten Teil bereits beschrieben, startet man Container und Services über Fleet, das sich wiederum auf Unit-Files stützt.
[Unit]
Description=Announce myawesomeapp
BindsTo=myawesomeapp@%i.service
After=myawesomeapp@%i.service
[Service]
ExecStart=/bin/sh -c "while true; do etcdctl set /services/myawesomeapp/%i/status/current 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/expected 'started' --ttl 60; etcdctl set /services/myawesomeapp/%i/status/alive 'started' --ttl 60;etcdctl set /services/myawesomeapp/%i/location \"{\\\"host\\\": \\\"%H\\\", \\\"port\\\": \"`docker inspect --format='{{(index (index .NetworkSettings.Ports \"8080/tcp\") 0).HostPort}}' myawesomeapp`\"}\" --ttl 60; etcdctl set /domains/myawesomeapp.netways.de/type 'service' --ttl 60;etcdctl set /domains/myawesomeapp.netways.de/value 'myawesomeapp' --ttl 60;sleep 45;done"
ExecStop=/usr/bin/etcdctl rm /services/website/myawesomeapp@%i
[X-Fleet]
MachineOf=myawesomeapp@%i.service

Das Beispiel zeigt ein Unit-File, das für den Anwendungscontainer (myawesomeapp@.service) einen Sidekick startet. Der Sidekick schreibt verschiedene Informationen des Anwendungscontainers mit einer Gültigkeit (ttl) von 60 Sekunden in etcd unter anderem zum Beispiel seine Location: “etcdctl set /services/myawesomeapp/%i/location”
Das ist wichtig, da in einem Container Cluster die Container auf beliebigen Nodes mit beliebigen Ports gestartet werden können. Ein geeigneter Loadbalancer bzw. geeignete Software kann so dynamisch die aktuelle Umgebung auslesen und Requests an die laufenden Applikationen bzw. Container weiterleiten.
In den nächsten Teilen der Serie wird auf Loadbalancer und Fleet genauer eingegangen.

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.

Coreos Übersicht

Docker, Docker Docker! So oder so ähnlich wird teilweise hämisch oder motivierend auf Ideen kommentiert, seine Anwendung in einen bzw. mehrere Docker Container zu migrieren. Für eine produktive Umgebung reicht das Standard Set von Docker nicht aus, zumindest nicht ohne Docker Swarm, Compose und Machine. Es gibt mittlerweile und gab neben den Produkten aus dem Hause Docker bereits Lösungen, die sich um das Deployment und Managen von Containern kümmern können. Eine sehr gute Alternative ist Mesos, aber auch CoreOS.
In der mehrteiligen Blogserie zu CoreOS werden die einzelnen Komponenten, Features und Vorzüge von CoreOS genauer betrachtet. Im ersten Beitrag zur Serie soll ein erster grober Überblick vermittelt werden.
Three-Tier-Webapp
CoreOS ist ein leichtgewichtiges auf dem Linux Kernel aufbauendes Open Source Betriebssystem. Das System ist auf das Nötigste reduziert, kommt ohne Paketmanager aus und nutzt systemd als init. Neben den essentiellen Userland Tools besteht es im wesentlichen aus: Container Runtime (Docker/Rkt), etcd und fleet. Es kann auf diversen Plattformen betrieben werden wie Vagrant, EC2, KVM, VMware, OpenStack, Digital Ocean Droplets, und natürlich auf eigener Hardware. Updates werden durch Reboots vollzogen.
Eine Variante der Installation ist über PXE/iPXE. Hier wird für die entsprechenden VMs oder Hardware-Server ein korrespondierender PXE-Boot-Eintrag erstellt, der das aktuelle CoreOS Image vorhält. Die einzelnen Maschinen können individuell auf ihre zukünftige Rolle mit einer sogenannten cloud-config konfiguriert werden. Beim boot liest das System diese in YAML formatierte Datei ein und konfiguriert sich entsprechend. Es kann der Discovery Service Endpoint, fleet, etcd, ssh-keys und Dateien konfiguriert werden.
Beispiel cloud-config.yaml:
#cloud-config
coreos:
units:
- name: etcd.service
command: start
- name: fleet.service
command: start
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABA....AAAYQC2++odpaavdW2/AU0l7RZiE=

Das Discovery dient zur Clusterbildung und wird von CoreOS bereitgestellt. Natürlich kann man auch seinen eigenen Discovery-Service nutzen. Unter einem eindeutigen Token wird ein neuer Cluster definiert. Die erste Maschine, die startet nimmt Kontakt auf und registriert sich als Leader für den Cluster. Alle weiteren Maschinen, lesen die bereits teilnehmenden Cluster-Nodes aus und können sich entsprechend integrieren und verbinden. Für die Services etcd und fleet sind diese Informationen essentiell.
etcd ist ein verteilter Key-Value-Store, der für Service-Discovery und Konfiguration benutzt wird. Es kümmert sich mit Hilfe des Raft Protokolls um Consensus.
fleet kann man sich als Serverübergreifender systemd vorstellen. Mit Hilfe von Unit-Files erstellt man Services die fleet im Cluster nach Regeln verteilt und startet bzw. stoppt. Ein Service ist in der Regel ein Container.
Beispiel Unit-File:
[Unit]
Description=MyApp
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill busybox1
ExecStartPre=-/usr/bin/docker rm busybox1
ExecStartPre=/usr/bin/docker pull busybox
ExecStart=/usr/bin/docker run --name busybox1 busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
ExecStop=/usr/bin/docker stop busybox1

In den nächsten Blogposts der Serie werden die einzelnen Komponenten und weitere wie Loadbalancer etc. genauer betrachtet und anhand von Beispielen näher auf die Vorzüge eines Setups mit CoreOS und mögliche Workflows eingegangen.

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.

WLAN Analyse mit Mac OS X Boardmitteln

Durch immer mehr WLAN Hotspots im Umkreis des eigenen Hotspots häufen sich oftmals die Verbindungsprobleme. Der Grund hierfür sind oftmals nicht der schlechte Empfang sondern Geräte die als Störer mit in das eigene Frequenzband funken. Im 2,4GHz Standard gibt es lediglich 3 Kanäle die genug Abstand in MHz zueinander haben, so dass es keine Störung des eigenen Kanals gibt. Das Problem ist jedoch, dass man Hotspots der Nachbarn oder angrenzenden Firmen selber nicht auf seine Vorstellungen konfigurieren kann, um eine bestmögliche Kanalwahl aller betroffenen Geräte steuern zu können. Eine gute Alternative ist, den stärksten Sender zu suchen und den gleichen Kanal zu wählen, damit sich die Geräte untereinander einigen können. Besser man geht auf eine Frequenz, die keiner nutzt. Aktuell gibt es im 5GHz Standard die Chance der einzigste im Umkreis zu sein. Falls nicht gibt es zumindest die Chance einen Kanal bzw. eine Frequenz zu erwischen, die einem allein zur Verfügung steht. Mit der Verbreitung von 5GHz tauglicher Hardware wird die Chance natürlich auch immer geringer.
Für eine entsprechende Analyse der Gegebenheiten im aktuellen Umkreis kann man mit den Boardmitteln von Mac OS X, die wirklich sehr versteckt zu finden sind, gut gearbeitet werden.
Mit gedrückter “alt”-Taste auf das WLAN-Symbol und anschließend die Diagnose öffnen. Es öffnet sich ein Assistent, der ignoriert werden kann. Im Menu “Fenster” können dann die verschiedensten Tools geöffnet werden. Interessant sind für oben beschriebenes Szenario die Programme “Scan” und “Leistung”.
Scan zeigt die aktuellen Netze mit gewähltem Frequenzbereich und -breite. Zudem den Received Signal Strength Indicator (RSSI) und die Stärke des Störsignals aus denen man den Signalrauschabstand ableiten kann.
Das Fenster Leitung stellt das ganze zusätzlich mit Hilfe eines sich aktualisierenden Graphen dar. Was sehr hilfreich werden kann, sobald man Räume oder Stockwerke wechselt und dessen Umgebung analysieren möchte.
WLAN-Leistung

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.

Viva la Revolución?

Docker ist in aller Munde und erfährt derzeit einen riesen Hype um sich. Es wird teilweise gar von „Revolution“ gesprochen. Doch ist das ganze wirklich so revolutionär? Die Lager in der DevOps Community sind sich hierüber nicht ganz einig und sind teilweise gespalten. Die eingesetzten Technologien aus denen Docker besteht sind eigentlich nicht neu und werfen den Mehrwert, den man in der letzten Zeit durch Configuration Management Tools wie Puppet, Chef etc. gewonnen hat, teilweise wieder zurück. Im wesentlichen besteht Docker aus einer Container-Virtualisierung, einem Copy on Write Filesystem bzw. Overlay Filesystem, einem Repository, einer Versionsverwaltung und einer mächtigen API. Das ganze zusammengeschnürt und einfach zu steuern und zu verwenden ist dann Docker.
 
Die Plattform verfolgt den Continious Integration Gedanken mit der man kontinuierlich Änderungen, möglichst automatisiert mit einer Kette an Tests, in die Produktion ausrollt. Der Workflow sieht im einfachsten Fall vor, dass man ein Image startet, Änderungen an diesem Image durchführt und diese dann als „commit“ speichert. Aus diesem kann man wiederum weitere Instanzen klonen und kann sie, sollte etwas nicht wie gewünscht funktionieren, wieder auf einen älteren Stand zurückrollen.
 
Wie immer und auch bei anderen Lösungen birgt Docker nicht nur Vorteile. Technisch gibt es einige Herausforderungen und Probleme die bei der Integration in die Produktion früher oder später auftauchen werden. (Noch) keine Möglichkeit Disk I/O zu limitieren, kein Quota auf AUFS, keine persistenten Anwendungsdaten, keine vollständige Isolation, dynamische Hostnames, Loadbalancing um nur einige zu nennen. Neben technischen Herausforderungen gibt es außerdem das Workflow Dilemma, das sich wie schon erwähnt teilweise mit den Config Management Tools beißt und deshalb auch die Lager spaltet.
 
Der richtige Weg ist aber wohl mehr eine Glaubensfrage oder am ehesten dem Use-Case gezollt. Jedes Unternehmen hat eigene Anforderungen und muss diese gegen den „Docker-Workflow“ evaluieren. Die bereits existierenden Schwierigkeiten, die es in einer automatisierten Umgebung und Continious Integretion gibt, löst Docker deshalb auch nicht, aber es zeigt einen interessanten alternativen Weg auf. Die Antwort auf die ursprüngliche Frage der revolutionären Ansätze und des Umdenkens, kann wohl erst in einigen Jahren gegeben werden nachdem Erfahrungen gemacht wurden und man den tatsächlichen Einfluss bewerten kann. Mehr zum Thema und Docker erfährt man bei uns in den Trainings.

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.

Mesos

Mit Mesos hat das Apache Projekt ein Cluster-Manager geschaffen, der sich um das Ausführen verteilter Applikationen kümmert.
Der Mehrwert ist, dass mit dem Framework ein Standard geschaffen werden soll, der das komplexe “Rad neu erfinden” für solche Zwecke abgeschafft werden soll und auf bereits funktionierende Software gesetzt werden kann. Ein Beispiel ist z.B. das managen eines Quorum in einem Cluster. Jeder Clusterstack wie Pacemaker/Corosync etc. hat seine eigene Logik. Mesos setzt hierfür auf das ebenfalls aus dem Hause Apache stammende Zookeeper. Das wiederum kann dann modular für Mesos, SolR, eigene Entwicklungen usw. genutzt werden.
Was macht jetzt Mesos? Mesos besteht aus mind. einem Master und einem Slave. Der Master verteilt Jobs oder Anwendungen und die Slaves führen diese aus. Die Slaves melden außerdem regelmäßig ihre aktuelle Auslastung, so dass der Mesos-Master weiß wohin er die neuen Aufgaben verteilen soll. In dieses Konstrukt kann sich ein weiteres Framework, dass für die unterschiedlichsten Zwecke verwendet werden kann, registrieren. Es gibt die wildesten Frameworks genannt Marathon, Aurora, Chronos und viele mehr. Jedes nutzt als Basis Mesos, aber eben für seine eigenen Zwecke.
Chronos ist z.B. für das Ausführen von zeitgesteuerten Jobs entwickelt worden. Also ein Crond, nur eben, dass die Cronjobs nicht nur auf einem Host sondern auf vielen ausgeführt werden können. Mit Marathon werden Commands oder ganze Anwendungen am laufen gehalten. Einmal gestartet, sorgt es dafür dass es immer mind. xmal gestartet ist. Ein Job kann z.B. ein “/usr/sbin/apachectl -d /etc/apache2 -f apache2.conf -e info -DFOREGROUND”. Das setzt natürlich die installierte Software auf dem Slave voraus, also Apache2.
Noch abstrakter geht es indem man Mesos konfiguriert einen externen containerizer zu nutzen: Docker. Obiges Beispiel würde also nicht auf dem Slave direkt gestartet werden, sondern ein Docker Container starten und in diesem das Command ausführen. Betrieben werden kann das ganze auf physischen oder in virtuellen Servern oder beidem.
Wozu man so etwas verwenden kann muss man letztendlich selbst entscheiden. Die Lösung verfolgt den SaaS/PaaS Ansatz und stellt im wesentlichen Hardwareressourcen aus einem Pool(IaaS) zur Verfügung und bietet Bibliotheken, Frameworks und APIs um sie zu steuern. Das Buzzword nennt sich ganz allgemein Cloudcomputing 🙂
Für Docker werden wir übrigens noch dieses Jahr Schulungen anbieten.

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.