KNW-2130 finalized translation, added anchors, cleaned up a bit

Author: sebkir

src/common/de/monitoring_kubernetes.asciidoc

@@ -1,5 +1,5 @@
 // -*- coding: utf-8 -*-
-// IGNORE
+// IGNORE Allowlist AllowlistSynchronizer Allowlists CRI RKE2 k3s
 // NONASCII
 include::global_attr.adoc[]
 = Kubernetes überwachen
@@ -34,6 +34,7 @@ Kubernetes ist seit geraumer Zeit das am meisten verwendete Werkzeug für die Or
 Auf Ebene der Nodes und vom Cluster-Level bis hinab zu den einzelnen Pods, können Sie alle wichtigen Objekte Ihrer Workloads überwachen.
 Eine vollständige Auflistung aller verfügbaren Check-Plugins für die Überwachung von Kubernetes finden Sie in unserem link:https://checkmk.com/de/integrations?tags=kubernetes[Katalog der Check-Plugins.^]
 
+[#supported]
 === Unterstützte Distributionen und Versionen
 
 ifdef::onprem[]
@@ -56,18 +57,21 @@ Damit stellen wir vor allen Dingen die reibungslose Zusammenarbeit mit denjenige
 Unmittelbar nach dem Release einer neuen Version von Kubernetes kann es -- je nach Umfang der Neuerungen und Zeitpunkt -- etwas dauern, bis auch diese vollständig in {CMK} unterstützt wird.
 Sobald {CMK} mit dieser neuen Version reibungslos zusammenarbeiten kann, werden wir dies in einem Werk (wie beispielsweise link:https://checkmk.com/werk/19449[Werk #19449^]) kundtun.
 
+[#getting_started]
 === Einstieg in das Kubernetes-Monitoring
 
 Für einen Einstieg in das Monitoring von Kubernetes empfehlen wir unsere beiden Videos link:https://www.youtube.com/watch?v=H9AlO98afUE[Kubernetes Monitoring with {CMK}^] und link:https://www.youtube.com/watch?v=2H-cLhyfYbc[Detecting issues and configuring alerts for Kubernetes clusters.^]
 
 
 ifdef::onprem[]
+[#structure]
 === Aufbau der Monitoring-Umgebung
 
 Da es in Kubernetes-Clustern sehr schnell auch zu größeren Veränderungen kommen kann, was die Anzahl und Verortung der einzelnen Komponenten angeht, empfehlen wir, für das Monitoring Ihrer Kubernetes-Umgebung eine eigene Instanz zu erstellen.
 Diese können Sie dann wie üblich über das xref:distributed_monitoring#[verteilte Monitoring] an Ihre Zentralinstanz anbinden.
 endif::[]
 
+[#process]
 === Ablauf des Kubernetes-Monitorings in {CMK}
 
 {CMK} überwacht Ihre Kubernetes-Cluster auf zwei Wegen:
@@ -86,6 +90,7 @@ Ein nicht unerheblicher Teil der folgenden Ausführungen dreht sich dann auch da
 Auch ist die Verwendung der xref:dashboards[Kubernetes-Dashboards] in den kommerziellen Editionen nur dann sinnvoll, wenn Node und Cluster Collector hierfür Daten zur Auslastung liefern können.
 
 
+[#differences]
 === Unterschiede zum übrigen Monitoring in {CMK}
 
 Beim Monitoring von Pods und Replicas in Ihren Kubernetes-Clustern kommt es mitunter wesentlich häufiger zu Statusänderungen bzw. zu Verzögerungen.
@@ -134,6 +139,7 @@ checkmk-chart/checkmk	1.0.0        	  1.0.0       	Helm chart for Checkmk - Your
 Wenn eine neue Version für Sie vorliegt, können Sie das Update mit `helm repo update` durchführen.
 
 
+[#customize_configuration]
 === Konfiguration auf Ihre Umgebung anpassen
 
 Da wir im Vorfeld nicht wissen können, wie Ihr Kubernetes-Cluster aufgebaut ist, haben wir die sicherste Variante gewählt, wie die Cluster Collectors gestartet werden:
@@ -151,6 +157,7 @@ Sie können entweder die von uns in den Helm-Charts mitgelieferte Datei extrahie
 Immer wenn Sie Änderungen an dieser Datei in Ihrem Cluster bereitstellen möchten, können Sie erneut den später folgenden Befehl zur xref:install_helm_charts[Installation] des Helm-Charts verwenden.
 
 
+[#create_values_yaml]
 ==== Minimale `values.yaml` selbst anlegen
 
 Sie können eine `values.yaml` anlegen, in die Sie nur die Werte eintragen, die Sie auch ändern wollen.
@@ -170,6 +177,7 @@ Eine Aktivierung von _Ingress_ könnte etwa so aussehen:
 ----
 
 
+[#extract_values_yaml]
 ==== values.yaml aus Helm-Charts extrahieren
 
 Die vollständige von uns link:https://raw.githubusercontent.com/Checkmk/checkmk_kube_agent/refs/heads/main/deploy/charts/checkmk/values.yaml[mitgelieferte `values.yaml`^] lässt sich mit dem folgenden Befehl aus dem Helm-Chart extrahieren:
@@ -182,6 +190,7 @@ Die vollständige von uns link:https://raw.githubusercontent.com/Checkmk/checkmk
 Die so erzeugte Datei können Sie nun nach Ihren Bedürfnissen anpassen und bei der xref:install_helm_charts[Installation] oder einem späteren Upgrade mit dem Parameter `-f values.yaml` an `helm` übergeben.
 
 
+[#ingress]
 ==== Kommunikation per Ingress bereitstellen
 
 Falls Sie link:https://kubernetes.io/docs/concepts/services-networking/ingress/[Ingress^] verwenden, um die Zugriffe zu Ihren Diensten zu steuern, passen Sie entsprechend die bereits vorbereiteten Teile in der `values.yaml` an.
@@ -209,6 +218,7 @@ Die restlichen Parameter passen Sie entsprechend Ihrer Umgebung an:
 ----
 
 
+[#nodeport]
 ==== Kommunikation per NodePort bereitstellen
 
 Sie können den Zugriff auf die Dienste auch direkt über einen Port bereitstellen.
@@ -226,6 +236,8 @@ Sie setzen dabei den Wert `type` auf `NodePort` und entfernen die Auskommentieru
     nodePort: 30035
 ----
 
+
+[#https]
 ==== Cluster Collector auf HTTPS umstellen
 
 Wenn Sie die Kommunikation mit dem und zwischen den Cluster Collectors auf HTTPS umstellen möchten, müssen Sie hierzu ebenfalls Änderungen in der Datei `values.yaml` vornehmen.
@@ -264,6 +276,7 @@ Beachten Sie dabei nur die folgenden Voraussetzungen, die die Zertifikate erfül
 `subjectAltName = DNS:<service_name>.<namespace>.cluster.local, DNS:<service_name>.<namespace>, IP:<service ip>`
 
 
+[#configure_sa]
 ==== Eigenen Service-Account verwenden
 
 Mithilfe unserer Helm-Charts würde standardmäßig ein Service-Account in Ihrem Cluster erstellt.
@@ -278,6 +291,7 @@ serviceAccount:
 ----
 
 
+[#prerequisites_gke]
 ==== Voraussetzung für Monitoring von GKE Autopilot
 
 Falls Sie Ihren GKE-Cluster (Google Kubernetes Engine) im Autopilot-Modus betreiben, so ist das Monitoring mit {CMK} problemlos möglich, da {CMK} ein sogenannter link:https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-partners?hl=de#allowlisted-partner-workloads[Autopilot Partner] ist.
@@ -491,12 +505,7 @@ Der erste Block zeigt Ihnen Informationen zum NodePort an:
 [{shell-raw}]
 ----
 {c-user} export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector);
-----
-[{shell-raw}]
-----
 {c-user} export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}");
-----
-[{shell-raw}]
 {c-user} echo http://$NODE_IP:$NODE_PORT
 http://10.184.38.103:30035
 ----
@@ -624,12 +633,15 @@ image::monitoring_kubernetes_connection_properties.png[alt="Beispielhafte Einste
 
 
 ifdef::onprem[]
+[#piggyback_data]
 === Piggyback-Daten in {RE} verarbeiten
 
 In {RE} müssen Sie die Hosts für die anfallenden Piggyback-Daten xref:piggyback#piggyback_in_practice[manuell erstellen.]
 Weil hier in einem Kubernetes-Cluster eine große Zahl an Piggybacked-Hosts entstehen dürften, empfiehlt sich die Verwendung des Befehls xref:piggyback#orphaned_piggyback_data[`cmk-piggyback list orphans`].
 endif::[]
 
+
+[#customize_discovery]
 === Periodische Service-Erkennung anpassen
 
 Standardmäßig führt {CMK} alle zwei Stunden eine Service-Erkennung durch und zeigt das Ergebnis dieser Erkennung im Service [.guihint]#Check_MK Discovery# an.
@@ -810,7 +822,6 @@ In einem solchen Fall müssen Sie vor dem oben erklärten xref:update[`Update`]
 [{shell}]
 ----
 {c-user} kubectl delete --all deploy,ds -n checkmk-monitoring
-kubectl delete --all deploy,ds -n checkmk-monitoring
 deployment.apps "myrelease-checkmk-cluster-collector" deleted
 daemonset.apps "myrelease-checkmk-node-collector-container-metrics" deleted
 daemonset.apps "myrelease-checkmk-node-collector-machine-sections" deleted
@@ -832,6 +843,7 @@ So lassen sich in der Folge sehr einfach Filter und Regeln für alle Objekte gle
 [#advanced_configuration]
 == Erweiterte Konfiguration
 
+[#change_configuration]
 === Änderungen an der Konfiguration vornehmen
 
 Wie oben bereits beschrieben, empfehlen wir für die Konfiguration der Überwachung Ihrer Kubernetes-Cluster, das von uns zur Verfügung gestellte Helm-Chart zu verwenden.
@@ -843,7 +855,7 @@ Der Befehl kann dann etwa so aussehen:
 {c-user} helm upgrade -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yaml
 ----
 
-
+[#network_interfaces]
 === Netzwerkschnittstellen der Worker Nodes überwachen
 
 Wenn Sie die Netzwerkschnittstellen Ihrer Worker Nodes überwachen möchten, müssen Sie das dem {CMK} Node Collector entsprechend mitteilen.
@@ -864,21 +876,20 @@ Im Auslieferungszustand steht der Schlüssel `enabled` noch auf `false`.
 
 Wenn Sie dann zusätzlich noch beeinflussen möchten, welche Netzwerkschnittstellen auf welche Art erkannt werden sollen, können Sie eine Regel im Regelsatz [.guihunt]#Network interface and switch port discovery# einrichten und dieser als Bedingung beispielsweise das Host-Label `cmk/kubernetes/object:node` mitgeben.
 
-
+[#file_systems]
 === Dateisysteme auf Worker Nodes überwachen
 
 In einigen Kubernetes-Umgebungen (bspw. Tanzu) *kann* es sinnvoll sein, Dateisysteme des Hosts in den {CMK} Node Collector zu mounten, um diese überwachen zu können.
 In unserer mitgelieferten `values.yaml` haben wir für diesen Fall das Dictionary `.nodeCollector.machineSectionsCollector.extraHostPathMounts` eingebaut, das Sie leicht auskommentieren und anpassen können, um bestimmte Dateisysteme in das Blickfeld des Node Collectors zu rücken.
 
-// ML: Vielleicht ein paar Erklärungen zu den einzelnen Einträgen? Gerade  sowas wie "root-host" lässt immer vermuten, dass es sich um einen speziellen Ausdruck handelt - vielleicht "my-extra-host-path-mount" oder so?
 In Ihrer `values.yaml` könnte dieser Abschnitt beispielsweise so aussehen:
 
 .values.yaml
 [{yaml},highlight=4..5]
 ----
 extraHostPathMounts:
-      - name: host-root
-        mountPath: "/host"
+      - name: my-host-root-directory
+        mountPath: "/myhost"
         hostPath:
           path: /
           type: Directory
@@ -967,63 +978,6 @@ Hier sollten die drei Boxen [.guihint]#Primary datasource#, [.guihint]#Cluster c
 
 image::monitoring_kubernetes_cluster_state.png[alt="Funktionierendes Cluster-Monitoring."]
 
-////
-[#rancher]
-== Kubernetes in Rancher-Installationen
-
-=== Service-Account anlegen
-
-Mit Rancher ist die Einrichtung des Monitorings in {CMK} der oben beschriebenen Variante sehr ähnlich.
-Auch hier benötigen Sie den Service-Account, damit {CMK} auf den Cluster zugreifen kann.
-Den Account erstellen Sie direkt in der Rancher-Weboberfläche, wo Sie anschließend auch dessen Token und Zertifikat finden, die Sie wiederum in {CMK} importieren.
-
-Navigieren Sie in Rancher zunächst nach [.guihint]#Global > Security > Roles > Clusters#, um eine neue Rolle `checkmk` anzulegen:
-
-[{image-border}]
-image::rancher_roles.png[]
-
-Der Einfachheit halber klonen Sie die Rolle [.guihint]#Cluster Owner#:
-
-[{image-border}]
-image::rancher_roles_clone.png[]
-
-Entziehen Sie der geklonten Rolle unter [.guihint]#Grant Resources# die Rechte [.guihint]#Create,# [.guihint]#Delete,# [.guihint]#Patch# und [.guihint]#Update#:
-
-[{image-border}]
-image::rancher_roles_clone_rights.png[]
-
-Erstellen Sie nun einen neuen Rancher-Benutzer `checkmk` unter [.guihint]#Global > Users > Add User#.
-Bei [.guihint]#Global Permissions# wählen Sie die Option [.guihint]#User-Base#, um dem Benutzer nur die nötigsten Leserechte einzuräumen:
-
-[{image-border}]
-image::rancher_adduser.png[]
-
-
-=== Cluster-Rolle zuordnen
-
-Wechseln Sie nun zu Ihrem Cluster und klicken Sie im Cluster-Menü oben rechts auf [.guihint]#Edit.#
-Hier können Sie über [.guihint]#Add Member# den eben angelegten Benutzer [.guihint]#checkmk# mit der zugehörigen Rolle [.guihint]#checkmk# zum Cluster hinzufügen:
-
-[{image-border}]
-image::rancher_addmember.png[]
-
-
-=== Weiteres Vorgehen
-
-Melden Sie sich anschließend mit dem neuen Benutzer bei Rancher an, rufen Sie den Cluster auf und klicken Sie auf [.guihint]#Kubeconfig File#.
-Hier finden Sie drei Angaben, die Sie für das Monitoring in {CMK} benötigen:
-
-* `clusters` > `cluster` > `server`: URL-/Pfadangabe für die xref:rule[{CMK}-Regel]
-* `clusters` > `cluster` > `certificate-authority-data`: Das base64-kodierte Zertifikat
-* `users` > `user` > `token`: Zugangspasswort in Form eines Bearer Tokens
-
-image::rancher_kubeconfig.png[]
-
-Das Zertifikat müssen Sie noch dekodieren, auf der Befehlszeile beispielsweise mit `base64 --decode` oder in einem der vielen Online-Dienste.
-
-Die Einrichtung in {CMK} entspricht ab hier dem Vorgehen bei purer Kubernetes-Nutzung ab dem Abschnitt xref:setupincheckmk[Monitoring in {CMK} einrichten].
-
-////
 
 [#remove]
 == Monitoring-Komponenten aus Cluster entfernen