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.

GUDE Netzwerkthermometer: Expert Sensor Box 7213 und 7214-Serie im direkten Vergleich

Gude-Expert Sensor Box 7214-Serie und Gude-Expert Sensor Box 7213-Serie, zwei Produkte, die sich sehr ähneln. Um Ihnen die Entscheidung bei einem Kauf leichter zu machen, werden diese zwei Geräte heute in einen direkten Vergleich gestellt.

 

GUDE und das Qualitätsversprechen

GUDE ist seit über 30 Jahren Hersteller von innovativen Geräten für den IT-Bereich. Sie ermöglichen die Optimierung und Erweiterung von IT-Infrastrukturen in Netzwerk-, Server- und Medienschränken. Die Einsatzbereiche der Kunden reichen von Unternehmensnetzwerken über Mediensteuerungen bis hin zu Rechenzentren und Industrieumgebungen. Beide Geräte eignen sich perfekt für kleinere Serverräume, was auch an der Größe und den Montagemöglichkeiten der 7213 und 7214 Geräten liegt. Mit entsprechenden Klammern lassen sich die Netzwerkthermometer auch bequem auf Hutschiene montieren.

GUDE setzt bei all seinen Produkten auf “Made in Germany”. Dies ist genauso wie bei den “großen” Geräten auch bei den kleinen sofort erkennbar: Alle Geräte zeichnen sich durch exzellente Verarbeitung aus, die unter anderem durch die Auswahl und Verarbeitung der Materialien gewährleistet wird, hier zum Beispiel das robuste rostfreie Stahlgehäuse. Flexible Bedienmöglichkeiten und ein sparsamer Betrieb runden dabei das überzeugende Erscheinungsbild ab.

 

Vorteile haben beide der Produkte, aber was können sie genau?

Der Vorteil dieser Netzwerk Thermometer besteht darin, dass sie Umgebungsrisiken, wie Überhitzung, Feuer, Wasser, erhöhte Luftfeuchtigkeit, erhöhter Luftdruck und Vandalismus frühzeitig erkennen. Diese Geräte überwachen diese Risiken mit Hilfe von den anzuschließenden oder schon integrierten Sensoren. So kann der Serverraum oder andere IT-Umgebungen über Netzwerk gemonitored werden bevor es zum Ausfall kommt. Dies schützt Ihre kritische IT-Infrastruktur gegen Ausfälle und spart Ihnen am Ende Geld.

  • Überhitzung: Überwachung mit dem Temperatursensor
  • Feuer: Überwachung mit dem Rauchmeldesensor
  • Wasser: Überwachung mit dem Leckage-Sensor
  • Vandalismus: Überwachung mit dem Türkontaktsensor
  • Erhöhte Luftfeuchtigkeit
  • Erhöhter Luftdruck

 

Merkmale und Ausstattung der Serien
Integrierter Temperatur-, Luftfeuchtigkeit- und Luftdrucksensor
2 weitere Anschlüsse (RJ45) für optionale Sensoren
Redundante Stromversorgung beim 7214, beide Serien auch mit Power-over-Ethernet erhältlich
Verfügbare Protokolle: IPv6, DHCP, SNMPv3, SSL, Telnet, Radius, Modbus TCP
Verschlüsselung mithilfe von SNMPv3, SSL, HTTPS, TLS
Zugriffsschutz durch IP-Zugriffskontrolle
Versenden von Alarmen und Nachrichten per E-Mail, Syslog und SNMP-Traps
Das 7214 verfügt über einen passiven Signaleingang und einen schaltbaren Relaisausgang (jeweils 3-fach Industrieklemme)
Eigenständiger LAN-Sensor für Environment Monitoring, beim 7214 auch für I/O-Monitoring
Robustes gepulvertes Stahlblechgehäuse mit Befestigungslaschen
Kostenlose Smartphone-Apps für Android und iOS für remote Zugriff
Netzwerkanschluss RJ45 mit 10/100 Mbit/s
Konfiguration über Telnet, Webbrowser oder Windows- bzw. Linux-Software
Software Updates im laufenden Betrieb ohne Neustart des Gerätes

 

Bei uns erhältliche Varianten

Beide Netzwerkthermometerserien können bei uns mit folgenden integrierten Sensoren geliefert werden:

  • LAN-Temperatur Sensor
  • LAN-Temperatur / Luftfeuchte Sensor
  • LAN Temperatur / Luftfeuchte / Luftdruck Sensor
  • LAN-Temperatur Sensor (PoE)
  • LAN-Temperatur / Luftfeuchte Sensor (PoE)
  • LAN-Temperatur / Luftfeuchte / Luftdruck Sensor (PoE)

 

Anschließbare Sensoren und Zubehör

 

FAZIT

Gude-Expert Sensor Box 7214-Serie und Gude-Expert Sensor Box 7213-Serie unterscheiden sich kaum im direkten Vergleich. Der Unterschied beruht insbesondere darauf, dass die 7214-Serie passiven Signaleingang und einen Relaisausgänge aufweist als der 7213. Weiterhin bietet der 7214 eine redundante Stromversorgung. Wer also remote steuern und noch weitere Sensoren, wie Rauchmelder oder Leckage-Sensor oder Türkontakte anschließen möchte, der kommt am der Gude-Expert Sensor Box 7214-Serie nicht vorbei.

Wir sind jederzeit für Euch erreichbar per Mail: shop@netways.de oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team. Bleibt gesund – wir freuen uns auf Euch!

Natalie Regn
Natalie Regn
Junior Office Manager

Natalie macht seit September 2019 ihre Ausbildung zur Kauffrau für Büromanagement hier bei NETWAYS. Vor ihrer Zeit bei NETWAYS war sie ein Jahr als Au-pair in Schottland unterwegs. Passend dazu widmet sie sich seit vielen Jahren dem Spielen der Great Highland Bagpipe. Natalie ist in ihrer Freizeit nicht nur musikalisch unterwegs, sondern auch sportlich. Sie trainiert im Fitnessstudio und geht gerne in den Kletterpark, in die Trampolinhalle oder zum Wandern in die fränkische Schweiz.

Ein kleiner Exkurs zu SNMP

Wer sich schon einmal mit SNMP beschäftigt hat, der weiß, dass das Verarbeiten sowie Auswerten von SNMP-Traps eine wichtige Rolle beim Monitoring spielt. Eine fast genauso große Rolle spielt hierbei das oft mühselige „ergoogeln“ der MIBs und OIDs. Für diesen Fall kann ich folgende Webseite empfehlen. Das eigentliche Problem ist allerdings, wenn man, wie in meinem Fall, einen Check entwickeln möchte, aber sich auf Grund von COVID-19 im Homeoffice befindet. Nicht ein Jeder hat bspw. Cisco Supervisor Module bei sich zu Hause stehen, die für das Testen benötigt werden. Nun, wie kann man sich dabei helfen? Man benutzt die override Option in snmpd.conf .

Ich gehe bei den weiteren Schritten davon aus, dass SNMP bereits auf dem System richtig konfiguriert wurde

Im Folgenden werde ich zeigen wie man beispielhaft den „Redundanz-Status“ eines Cisco-Gerätes mit selbst eingetragenen Werten überprüfen kann. Es handelt sich genauer gesagt um folgende OID.

Wenn ich versuche diese OID auf meinem lokalen Gerät auszulesen, stelle ich fest das diese unbekannt ist:
# snmpwalk -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
SNMPv2-SMI::enterprises.9.9.176.1.1.2 = No Such Object available on this agent at this OID

Das heisst, man muss zunächst dem lokalen System die entsprechende MIB zur Verfügung stellen. Ich speichere die MIB also in den Pfad der konfiguriert ist und “aktiviere” diese anschließend:

Auslesen des Standardpfades:
# net-snmp-config --default-mibdirs
/root/.snmp/mibs:/usr/share/snmp/mibs

Herunterladen der benötigten MIBs:
# wget -O .snmp/mibs/CISCO-RF-MIB.mib http://www.circitor.fr/Mibs/Mib/C/CISCO-RF-MIB.mib
# wget -O .snmp/mibs/CISCO-SMI.my https://www.cisco.com/iam/PGW_MIBS/973/CISCO-SMI.my

Laden bzw. “aktivieren” der MIBs:
# cat .snmp/snmp.conf
mibs +CISCO-RF-MIB
mibs +CISCO-SMI

Nun kann man ein weiteres Mal testen ob die MIBs korrekt geladen wurden und ob das lokale System diese auch benutzt:
snmpwalk -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
CISCO-RF-MIB::cRFStatusUnitState = No Such Object available on this agent at this OID

Wie in der oberen Ausgabe zu erkennen, kann mein lokales System nun die OID verarbeiten und erkennt diese auch. Das Problem an dieser Stelle ist aber nun, dass es sich bei meinem System nicht um ein CiscoGerät mit dem Redundancy-Feature handelt, Daher auch die Meldung No Such Object available on this agent at this OID.
Das können wir beheben, indem man dem SNMP-Daemon mitteilt, welchen Status das Objekt haben soll:
# cat /etc/snmp/snmpd.conf
override 1.3.6.1.4.1.9.9.176.1.1.2 integer 14

Nach einem Neustart des Dienstes wird nun der “gewollte” Wert vom SNMP-Daemon zurück geliefert:
# systemctl restart snmpd
# snmpget -v2c -c public localhost 1.3.6.1.4.1.9.9.176.1.1.2
CISCO-RF-MIB::cRFStatusUnitState = INTEGER: active(14)

Wie man sieht kann diese manuelle Überschreibung von einzelnen OIDs sehr hilfreich bei einer Pluginentwicklung sein. Dadurch hat man die Möglichkeit verschiedene Zustände zu prüfen, ohne das man diese extra herbeiführen muss.

Bildquelle: https://pixabay.com/photos/cup-of-coffee-laptop-office-macbook-1280537/

Philipp Dorschner
Philipp Dorschner
Consultant

Philipp hat im Jahr 2017 die Ausbildung zum Fachinformatiker – Systemintegration bei NETWAYS Professional Services begonnen. Während der Ausbildung bekam er ein immer größeres Interesse am Programmieren. Das führte dazu, dass Philipp nach erfolgreich bestandener Ausbildung die Kollegen aus Professional Services nicht nur als Consultant sondern auch als Entwickler tatkräftig unterstützt. Neben seinem Interesse an der Informationstechnologie, macht er Sport im Freien oder liest bei schlechtem Wetter auch gerne mal ein Buch zu Hause.

Alles neu macht der Mai: NETWAYS Trainings – Online und vor Ort

Alles neu macht der Mai. Und nicht nur der! Wir haben in den kommenden Monaten jede Menge neuen Input in spannenden NETWAYS Trainings für Dich. Online oder vor Ort: Das entscheidest Du. Wir haben aktuell beide Varianten im Portfolio. So kannst Du Dir das Wissen zu Deinem Open Source-Tool entweder ganz bequem und auf dem schnellen Weg zu Hause im Online Training aneignen. Oder Du kommst nach Nürnberg, Hamburg, München oder Berlin, um Dir gemeinsam mit anderen vor Ort neuen Input abzuholen.

Wir bringen Dir das state-of-the-art Praxiswissen bei!

MONITORING TRAININGS

Ein leistungsstarkes Tool zur Überwachung der Verfügbarkeit und Leistung aller Teile Deines Systems: Icinga zeigt Dir alle relevanten Daten an und gibt Warnmeldungen aus, um Dich auf dem Laufenden zu halten. Lerne Icinga von der Pike auf in unseren Schulungen und setze mit unseren Icinga Workshops noch eine Portion Profiwissen drauf!

Icinga 2 Fundamentals
Online | 7.–10. Juli 2020
Nürnberg | 22.–25. September 2020
Icinga 2 Advanced
Online | 21.–23. Juli 2020
Berlin | 6.–8. Oktober 2020
Icinga & Puppet Workshop
Nürnberg | 22.–23. September 2020
Icinga Director Workshop
Nürnberg | 20.–21. Oktober 2020

AUTOMATION TRAININGS

Der Trend zur Virtualisierung nahezu aller IT-Plattformen und Umgebungen erhöht den Bedarf an flexibler und vor allem schneller Verwendung der verfügbaren Ressourcen. Wir helfen Dir dabei, mit dieser Geschwindigkeit nicht nur Schritt zu halten, sondern ihr sogar einen Schritt voraus zu sein.

Ansible
Nürnberg | 21.–23. Juli 2020
Hamburg | 13.–15.Oktober 2020
Ansible AWX (Tower)
Nürnberg | 24. Juli 2020
Hamburg | 16. Oktober 2020
Icinga & Puppet Workshop
Nürnberg | 22.–23. September 2020
Fundamentals for Puppet
Online | 30. Juni – 2. Juli 2020
Nürnberg | 20.–22. Oktober 2020
Foreman
Nürnberg | 8.–9. September 2020

LOGGING & METRICS TRAININGS

Für Sammler und Sondierer: Hier erfährst Du, wie Du Log-Daten von Anwendungen, Betriebssystemen oder Netzwerkinfrastrukturen zentral sammelst, verarbeitest, verwaltest, analysierst und visualisierst. Mehrwertgenerierung garantiert!

Elastic Stack
Online | 23.–25. Juni 2020
München | 15.–17. September 2020
Graphite & Grafana
Online | 26.–27. Mai 2020

Berlin | 29.–30. September 2020
Graylog
Nürnberg | 30. Juni – 1. Juli 2020
Nürnberg | 27. – 28. Oktober 2020

ADMINISTRATION TRAININGS

Geballte Admin-Power: Hier lernst Du ein unabhängiges Linux-System zu administrieren und wiederkehrende Aufgaben zu automatisieren oder die Vorzüge unserer liebsten, flexiblen und erweiterbaren relationalen Datenbank kennen. Das und noch viel mehr. Jetzt anmelden!

Linux Basics
Nürnberg | 27.–29. Oktober 2020

PostgreSQL Fundamentals
Nürnberg | 14.–16. Juli 2020
PostgreSQL Advanced
Nürnberg | 8.–11. September 2020

DEVELOPMENT TRAININGS

Softwareentwicklung bedarf heute mehr denn je einer ganzheitlichen Betrachtung des DevOps-Lifecycles. Reine Source Code-Verwaltung wird dem nicht mehr gerecht und der gesamte Prozess von Planung bis hin zu Continuous Integration und Deployment benötigt eine technische Abbildung. GitLab ist das Tool dafür!

GitLab
Online | 14.–15. Juli 2020
Nürnberg | 15.–16. Dezember 2020

Das sagen unsere Teilnehmer*innen

“Man hat auf jeden Fall gemerkt, dass der Trainer sehr viel praktische Erfahrung mit der Software hat und weiß, wo er ansetzen muss.” – Feedback Ansible Online Training

“Eine neue Erfahrung, etwas anstrengender als in einer Präsenzschulung, aber mit viel technischem Hintergrund. Hat Spaß gemacht.” – Feedback Ansible Online Training

“Sehr gute Umsetzung einer neuen Schulungsmöglichkeit, auf jeden Fall für die Zukunft sehr interessant.” – Feedback GitLab Online Training

“Sehr gut organisiertes Online-Training, kompetenter und sympathischer Trainer. Alle Fragen wurden beantwortet. Absolut zu empfehlen!” – Feedback GitLab Online Training

Und was sagst Du? Wir freuen uns, Dich bald bei uns zu begrüßen! Virtuell oder vor Ort.

Julia Hornung
Julia Hornung
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.

Kubernetes Nginx Ingress Controller – So gelingt Dein einfacher Start!

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

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

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

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

 

Installation Kubernetes Nginx Ingress Controller

Helm Logo

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

$ helm install my-ingress stable/nginx-ingress

 

 

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

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

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

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

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

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

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

 

Beispielanwendungen: Apache und Nginx

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

K8s Deployments

Nginx Deployment

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

Apache Deployment

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

K8s Service

Nginx Service

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

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

 

Virtual Hosts ohne TLS

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

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

K8s Ingress

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

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

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

 

Virtual Hosts mit TLS

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

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

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

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

Fazit

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

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

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