KNW-2158 - ready for translation

Author: sebkir

src/common/de/monitoring_kubernetes.asciidoc

@@ -85,10 +85,7 @@ Auch ist die Verwendung der xref:dashboards[Kubernetes-Dashboards] in den kommer
 
 
 === Unterschiede zum übrigen Monitoring in {CMK}
-//SK: Hier ist sicherlich eine genauere Erklärung erforderlich.
-// TK: Ja, ist etwas kurz. Ist mir auch nicht ganz klar: Was ist der Unterschied, ob ich einen Snapshot der Zustände jede Minute oder alle 10 Minuten bekomme? Das Ergebnis ist doch dann genauso "zweifelhaft", bleibt aber für 10 Minuten statt für 1 Minute stehen.
-// TK: Folgefrage: kann man die 10min verändern? Sollte man das tun? Und wenn nicht, warum?
-// SK: Diese 10 Minuten beziehen sich tatsächlich nur auf kube_pod_status und kube_replicas. Das muss ich noch mal genauer rausarbeiten. Jetzt füge ich erstmal diese beiden Begriffe hinzu.
+
 Beim Monitoring von Pods und Replicas in Ihren Kubernetes-Clustern kommt es mitunter wesentlich häufiger zu Statusänderungen bzw. zu Verzögerungen.
 Um dem Rechnung zu tragen, ändern die Checks bei bestimmten Zuständen dieser Objekte erst nach 10 Minuten ihren Status in {CMK}.
 
@@ -121,8 +118,6 @@ Sie können aber selbstverständlich auch jeden anderen Namen nutzen:
 Wir aktualisieren unsere Helm-Charts immer dann, wenn neue Gegebenheiten in Kubernetes dies erfordern.
 Deshalb lohnt sich von Zeit zu Zeit eine Prüfung, ob im Repository neue Versionen verfügbar sind.
 Wenn Sie Ihre lokale Kopie unseres Repositorys, wie in dem vorherigen Befehl, mit `checkmk-chart` bezeichnet haben, können Sie sich mit dem folgenden Befehl alle im Repository vorliegenden Versionen der Charts anzeigen lassen:
-// TK: Ichnuwieder: Wie finde ich denn raus, welche Version ich installiert habe? Ja, ist nicht so wichtig...
-// SK: Der Hinweis, wie man herausfinden kann, welcher Helm-Chart aktuell im eigenen Cluster läuft käme hier verfrührt, weil ja eben noch nix läuft. Es wäre eventuell sinnvoller hier nur einen Verweis auf ein späteres Kapitel einzufügen.
 
 [{shell}]
 ----
@@ -188,8 +183,6 @@ Die so erzeugte Datei können Sie nun nach Ihren Bedürfnissen anpassen und bei
 ==== 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.
-// TK: Den Link würde ich weiter oben setzen, wo Du Ingress das 1. Mal erwähnst. Zu NodePort gibt es wohl keine Erklärung? Vielleicht: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport
-// SK: Bei der ersten Erwähnung von Ingress in der Einleitung wäre mir das eine zu große Ablenkung. Da will ich keinen Link haben. An der zweiten Stelle ist Ingress zu nebensächlich. Da könnte der Link untergehen.
 Zur besseren Übersicht ist in dem folgenden Beispiel nur der relevante Ausschnitt gezeigt.
 Den Parameter `enabled` setzen Sie auf `true`.
 Die restlichen Parameter passen Sie entsprechend Ihrer Umgebung an:
@@ -729,9 +722,6 @@ Konsultieren Sie an dieser Stelle erneut die ausführliche Inline-Hilfe.
 *Hinweis:* Die Option [.guihint]#Import all valid annotations# bieten wir an dieser Stelle nur der Vollständigkeit halber an.
 Wir raten davon ab, einfach blind alle _Annotations_ zu importieren, weil hierdurch mitunter ein sehr großer Berg nutzloser Labels in {CMK} erzeugt wird.
 
-// TK: Auskommentiert, weil passt nicht mehr 
-// Nachdem Sie nun alles eingerichtet haben, könnte Ihre Regel wie folgt aussehen:
-
 *Wichtig:* Unter [.guihint]#Conditions > Explicit hosts# *müssen* Sie nun den xref:source-host[zuvor angelegten Host] eintragen:
 
 image::monitoring_kubernetes_explicit_hosts.png[alt="Regeln für Spezialagenten müssen, wie hier zu sehen, immer auf explizite Hosts festgelegt werden."]
@@ -744,8 +734,7 @@ image::monitoring_kubernetes_service_discovery.png[alt="Exemplarische Ansicht de
 Aktivieren Sie im Anschluss alle vorgenommenen Änderungen und überlassen Sie ab jetzt der dynamischen Host-Verwaltung die Arbeit.
 Diese wird schon nach kurzer Zeit alle Hosts für Ihre Kubernetes-Objekte erzeugen.
 
-// ML: review notes KNW-1200: "die Helm Chart" nach "das Helm-Chart" geändert (gemäß Dictionary); ebenso updaten -> aktualisieren; und ein paar Typos.
-// ML: Wir: Ärzte-Wir und Checkmk-Wir wechseln sich in diesem Kapitel ab, erstere müssen weg - aber wie genau, überlasse ich lieber Dir.
+
 [#update]
 == Cluster-Überwachung aktualisieren
 
@@ -806,7 +795,7 @@ Der Service [.guihint]#Cluster collector# zeigt Ihnen die verwendete Version an:
 
 image::monitoring_kubernetes_verify_collector_update.png[alt="Exemplarische Ansicht des Service Cluster collector."]
 
-// SK: Ich denke noch über eine bessere Überschrift nach.
+
 [#incompatible_changes]
 === Inkompatible Änderungen 
 
@@ -836,7 +825,7 @@ Alle Labels zu Kubernetes-Objekten, die {CMK} automatisch erzeugt, beginnen mit
 Ein Pod erhält beispielsweise immer ein Label der Node (`cmk/kubernetes/node:mynode`), ein Label, welches eben zeigt, dass es sich bei diesem Objekt um einen Pod handelt (`cmk/kubernetes/object:pod`) und ein Label für den Namespace (`cmk/kubernetes/namespace:mynamespace`).
 So lassen sich in der Folge sehr einfach Filter und Regeln für alle Objekte gleichen Typs bzw. im gleichen Namespace erstellen.
 
-// SK: In das folgende Kapitel werde ich bei nächster Gelegenheit alle Punkt aus 'Konfiguration auf Ihre Umgebung anpassen' verschieben, die da oben nicht zwingend für die Einrichtung des Monitorings benötigt werden.
+
 [#advanced_configuration]
 == Erweiterte Konfiguration
 

src/common/en/monitoring_kubernetes.asciidoc

@@ -173,7 +173,15 @@ An activation of _Ingress_ could look like this:
 
 ==== Extracting values.yaml from Helm charts
 
+// This block replaces the following text
+// start translation
+////
+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:
+////
+// end translation
+// delete from here
 The complete `values.yaml` supplied by us can be easily extracted with the following command:
+// delete to here
 
 [{shell}]
 ----
@@ -284,6 +292,54 @@ serviceAccount:
 
 If you operate your GKE (Google Kubernetes Engine) cluster in Autopilot mode, monitoring it with {CMK} is also possible, as {CMK} is a so-called link:https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-partners#allowlisted-partner-workloads[Autopilot partner].
 
+// This block replaces the following text
+// start translation
+////
+Zwei Dinge müssen Sie noch erledigen, bevor ein Autopilot-Cluster mit {CMK} überwacht werden kann.
+
+In der `values.yaml` finden Sie einen Abschnitt `gkeAutopilot`.
+Stellen Sie hier `enabled` auf `true`:
+
+.values.yaml
+[{yaml}]
+----
+gkeAutopilot:
+  ## Enable GKE Autopilot specific configurations
+  enabled: true
+----
+
+Darunter finden Sie noch die Einstellung `matchingAllowlist`.
+In der `values.yaml` müssen Sie an diesem Eintrag nichts ändern.
+In Ihrem Autopilot-Cluster muss aber eben diese Allowlist noch eingerichtet werden.
+Das funktioniert am einfachsten mit einem sogenannten AllowlistSynchronizer, den Sie mit dem folgenden Befehl in Ihrem Cluster einrichten können.
+
+[{shell}]
+----
+{c-user} kubectl apply -f https://raw.githubusercontent.com/Checkmk/checkmk_kube_agent/refs/heads/main/deploy/manifests/gke-allowlist/cmk-allowlist-synchronizer.yaml
+----
+
+Details zu diesen Allowlists für privilegierte Arbeitslasten (englisch: _privileged workloads_) und was es damit genau auf sich hat, finden Sie in dem Artikel link:https://docs.cloud.google.com/kubernetes-engine/docs/how-to/run-autopilot-partner-workloads?hl=de#create-allowlistsynchronizer[Zulassung privilegierter Arbeitslasten im Autopilot-Modus steuern] der GKE-Dokumentation.
+
+
+[#rancher]
+==== Kubernetes in Rancher-Installationen
+
+Wenn Sie Cluster überwachen wollen, die Sie mit Rancher managen, können Sie die benötigten Arbeitslasten ebenfalls mit unserer Helm-Chart direkt in Ihr Cluster installieren.
+In der `values.yaml` müssen Sie gegebenenfalls den CRI-Socket von `containerd` explizit angeben.
+Bei k3s und RKE2 ist dieser häufig in `/run/k3s/containerd/containerd.sock` zu finden.
+
+Kommentieren Sie die Zeile, die mit `containerdOverride` ein und passen Sie die Stelle an Ihre Umgebung an.
+
+.values.yaml
+[{yaml}]
+----
+## k3s and Rancher RKE2 host containerd in a different location.
+## If you are using one of them, or containerd is located in an alternate location, please uncomment / adapt the override.
+containerdOverride: "/run/k3s/containerd/containerd.sock"
+----
+////
+// end translation
+// delete from here
 You only need to set `var_run` to `readOnly` in your `values.yaml`:
 
 .values.yaml
@@ -293,6 +349,7 @@ volumeMountPermissions:
       var_run:
         readOnly: true
 ----
+// delete to here
 
 
 [#pod_security_standards]
@@ -711,6 +768,92 @@ image::monitoring_kubernetes_service_discovery.png[alt="An example of a view fro
 Now activate all of the changes you have made and let the dynamic host management do the work for you.
 This will create all hosts for your Kubernetes objects within a short space of time.
 
+// start translation
+////
+[#update]
+== Cluster-Überwachung aktualisieren
+
+Wie wir im Abschnitt xref:#setup_helm_repo[Helm-Repository einrichten] bereits angedeutet haben, nehmen wir anlassbezogen Updates am {CMK} Cluster Collector und am {CMK} Node Collector vor.
+Es könnte beispielsweise notwendig sein, den enthaltenen {CMK}-Agenten zu aktualisieren.
+Damit diese Änderungen auch in Ihrem Cluster ankommen, müssen Sie zuerst das Helm-Repository aktualisieren.
+Führen Sie dazu den folgenden Befehl aus:
+
+[{shell}]
+----
+{c-user} helm repo update
+Hang tight while we grab the latest from your chart repositories...
+...Successfully got an update from the "checkmk-chart" chart repository
+Update Complete. Happy Helming!
+----
+
+[.admonition-tip]
+****
+An dieser Stelle sollten Sie prüfen, ob unser neues Helm-Chart Werte enthält, das Ihre angepasste `values.yaml` ggf. wieder überschreiben würden.
+Im Speziellen sollten Sie prüfen, ob in Ihrer `values.yaml` der Schlüssel `.image.tag` gesetzt wird.
+Diesen müssen Sie dann entweder auf die Version des neusten Helm-Chart setzen oder aus Ihrer `values.yaml` löschen, damit in Zukunft immer das `.image.tag` direkt aus dem Helm-Chart verwendet wird.
+****
+
+Wenn Sie mit den Inhalten Ihrer `values.yaml` zufrieden sind, können Sie im Anschluss das neue Helm-Chart mit Ihren angepassten Werten an Ihr Cluster übergeben:
+
+[{shell}]
+----
+{c-user} helm upgrade -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yaml
+Release "myrelease" has been upgraded. Happy Helming!
+NAME: myrelease
+LAST DEPLOYED: Wed Mar 25 12:10:26 2026
+NAMESPACE: checkmk-monitoring
+STATUS: deployed
+REVISION: 17
+TEST SUITE: None
+NOTES:
+You can access the checkmk cluster-collector via:
+NodePort:
+  export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector);
+  export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}");
+  echo \http://$NODE_IP:$NODE_PORT
+  pass:[#] Cluster-internal DNS of cluster-collector: myrelease-checkmk-cluster-collector.checkmk-monitoring
+With the token of the service account named `myrelease-checkmk-checkmk` in the namespace `checkmk-monitoring` you can now issue queries against the `cluster-collector`.
+Run the following to fetch its token and the ca-certificate of the cluster:
+  export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode);
+  export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
+  pass:[#]  Note: Quote the variable when echo'ing to preserve proper line breaks: `echo "$CA_CRT"`
+To test access you can run:
+  curl -H "Authorization: Bearer $TOKEN" \http://$NODE_IP:$NODE_PORT/metadata | jq
+----
+
+In diesem Beispiel nehmen wir weiterhin an, dass Ihr Release `myrelease` und der verwendete Namespace `checmk-monitoring` heißt.
+Passen Sie beide Parameter gegebenenfalls an Ihre Umgebung an.
+
+Die Überwachung Ihres Clusters sollte nun mit den neuen Versionen von Cluster Collector und Node Collector laufen.
+Prüfen können Sie das in der Oberfläche von {CMK}.
+Der Service [.guihint]#Cluster collector# zeigt Ihnen die verwendete Version an:
+
+image::monitoring_kubernetes_verify_collector_update.png[alt="Exemplarische Ansicht des Service Cluster collector."]
+
+
+[#incompatible_changes]
+=== Inkompatible Änderungen 
+
+Bestimmte Arten von Änderungen an Helm-Charts machen es erforderlich, dass Kubernetes-Objekte erst entfernt und dann neu erzeugt werden.
+Beispielweise die Entfernung von Labels, die zu einem Kubernetes-Objekt gehören, macht dies erforderlich.
+Wenn wir eine solche inkompatible Änderung vornehmen, wird dies im zugehörigen Werk angegeben.
+In einem solchen Fall müssen Sie vor dem oben erklärten xref:update[`Update`] noch den folgenden Befehl ausführen:
+
+[{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
+----
+
+In diesem Beispiel nehmen wir weiterhin an, dass Ihr Release `myrelease` und der verwendete Namespace `checmk-monitoring` heißt.
+Passen Sie den im Befehl verwendeten Namespace gegebenenfalls an Ihre Umgebung an.
+////
+// end translation
+
+
 [#labels]
 == Labels for Kubernetes objects
 
@@ -719,6 +862,69 @@ All of the labels for Kubernetes objects that {CMK} automatically generates star
 For example, a pod always receives a label for the node (`cmk/kubernetes/node:mynode`), a label that shows that this object is a pod (`cmk/kubernetes/object:pod`) and a label for the namespace (`cmk/kubernetes/namespace:mynamespace`).
 This makes it very easy to create filters and rules for all objects of the same type or in the same namespace.
 
+
+// start translation
+////
+[#advanced_configuration]
+== Erweiterte Konfiguration
+
+=== Änderungen an der Konfiguration vornehmen
+
+Wie oben bereits beschrieben, empfehlen wir für die Konfiguration der Überwachung Ihrer Kubernetes-Cluster, die von uns zur Verfügung gestellte Helm-Chart zu verwenden.
+Wenn Sie dann im Anschluss an die Ersteinrichtung Änderungen an dieser Konfiguration vornehmen wollen, müssen Sie nur die von Ihnen erzeugte `values.yaml` modifizieren und diese anschließend an den Befehl `helm upgrade` übergeben.
+Der Befehl kann dann etwa so aussehen:
+
+[{shell}]
+----
+{c-user} helm upgrade -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yaml
+----
+
+
+=== 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.
+Setzen Sie dafür den Schlüssel `.nodeCollector.machineSectionsCollector.networkInterfaceMonitoring.enabled` auf `true`.
+In der von {CMK} bereitgestellten `values.yaml` finden Sie dazu bereits einen entsprechenden Abschnitt:
+
+.values.yaml
+[{yaml},highlight=4..5]
+----
+    # the machine sections collector can collect monitoring information for network interfaces of the underlying node.
+    # this means that the '/sys' directory of the node will be mounted into the container.
+    # the pod security policy is adjusted accordingly.
+    networkInterfaceMonitoring:
+      enabled: false
+----
+
+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.
+
+
+=== 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"
+        hostPath:
+          path: /
+          type: Directory
+----
+
+Wenn Sie dann zusätzlich noch beeinflussen möchten, welche Dateisysteme erkannt werden sollen, können Sie eine Regel im Regelsatz [.guihunt]#Filesystem discovery# einrichten und dieser als Bedingung beispielsweise das Host-Label `cmk/kubernetes/object:node` mitgeben.
+////
+// end translation
+
+
 [#dashboards_views]
 == Dashboards and views
 
@@ -799,62 +1005,6 @@ Here the three boxes [.guihint]#Primary datasource#, [.guihint]#Cluster collecto
 
 image::monitoring_kubernetes_cluster_state.png[alt="A correctly-functioning cluster monitoring."]
 
-////
-[#rancher]
-== Kubernetes in Rancher installations
-
-=== Creating a service account
-
-With Rancher, setting up a monitoring in {CMK} is very similar to the variant described above.
-Here, too, you need the service account so that {CMK} can access the cluster.
-You create the account directly in the Rancher web interface, where you can also find its token and certificate, which you import into {CMK}.
-
-In Rancher, first navigate to [.guihint]#Global > Security > Roles > Clusters# to create a new role, `checkmk`:
-
-[{image-border}]
-image::rancher_roles.png[]
-
-For simplicity, first clone the [.guihint]#Cluster Owner# role:
-
-[{image-border}]
-image::rancher_roles_clone.png[]
-
-Remove the [.guihint]#Create,# [.guihint]#Delete,# [.guihint]#Patch# and [.guihint]#Update# rights from the cloned role under [.guihint]#Grant Resources#:
-
-[{image-border}]
-image::rancher_roles_clone_rights.png[]
-
-Now create the new `checkmk` Rancher user under [.guihint]#Global > Users > Add User#.
-At [.guihint]#Global Permissions# select the option [.guihint]#User-Base# to grant the user only the most necessary read permissions:
-
-[{image-border}]
-image::rancher_adduser.png[]
-
-
-=== Assigning a cluster role
-
-Now switch to your cluster and click on [.guihint]#Edit# at the top right of the cluster menu.
-Here you can add the just created user [.guihint]#checkmk# with the corresponding role [.guihint]#checkmk# to the cluster via [.guihint]#Add Member#:
-
-[{image-border}]
-image::rancher_addmember.png[]
-
-
-=== Further actions
-
-Log in to Rancher with this new user, call up the cluster and click on [.guihint]#Kubeconfig File#.
-Here you will find the three specifications you need for monitoring in {CMK}:
-
-* `clusters` > `cluster` > `server`: URL/path specification for the xref:rule[{CMK} rule].
-* `clusters` > `cluster` > `certificate-authority-data`: the base64-encoded certificate
-* `users` > `user` > `token`: Access password in the form of a bearer token
-
-image::rancher_kubeconfig.png[]
-
-You will still need to decode the certificate, on the command line for example with `base64 --decode` or with one of the many online services.
-
-From here on, the setup in {CMK} corresponds to the procedure for pure Kubernetes use from the xref:setupincheckmk[Setting up the monitoring in {CMK}] section.
-////
 
 [#remove]
 == Removing monitoring components from a cluster