Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Konfiguration des NetApp Kubernetes Monitoring Operator

Beitragende

Cloud Insights verwendet u. a. verschiedene Komponenten "Fließendes Bit" Und "Telegraf", Für die Erfassung von Kubernetes-Daten. Telegraf ist ein Plug-in-gestützter Server-Agent, mit dem Kennzahlen, Ereignisse und Protokolle erfasst und protokolliert werden können. Input-Plugins werden verwendet, um die gewünschten Informationen in den Agenten zu sammeln, indem Sie direkt auf das System/Betriebssystem zugreifen, indem Sie APIs von Drittanbietern aufrufen oder konfigurierte Streams (d. h. anhören Kafka, StatsD usw.). Mit Output-Plug-ins werden die gesammelten Metriken, Ereignisse und Protokolle vom Agenten an Cloud Insights gesendet.

Cloud Insights bietet die Sammlung NetApp Kubernetes Monitoring Operator (NKMO) für Kubernetes an. Wählen Sie beim Hinzufügen eines Datensammlers einfach die Kachel „Kubernetes“.

Kubernetes Data Collector

Vor der Installation des NetApp Kubernetes Monitoring Operator

Voraussetzungen:

  • Beachten Sie bitte die folgenden Komponentenversionen. Dies sind die aktuellen required Versionen, die vom NetApp Kubernetes Monitoring Operator enthalten sind. Diese Versionen müssen Sie besonders beachten, wenn Sie sind Verwenden eines benutzerdefinierten oder privaten Docker Repositorys:

    • Telegraf: 1.25.0

    • kube-rbac-Proxy: V0.13.0

    • kube-State-Metriken: V2.6.0

    • Fließendes Bit: 1.9.8

    • kubernetes-Event-Exporter: Version 0.10

  • Die Installation des NetApp Kubernetes Monitoring Operator wird mit Kubernetes Version 1.20 oder neuer unterstützt.

  • Wenn Cloud Insights den Back-End-Storage überwacht und Kubernetes bei der Laufzeit des Docker Containers verwendet wird, kann Cloud Insights POD-to-PV-to-Storage-Zuordnungen sowie Kennzahlen für NFS und iSCSI anzeigen. Andere Laufzeiten zeigen nur NFS an.

  • Ab August 2022 unterstützt der NetApp Kubernetes Monitoring Operator Pod Security Policy (PSP). Unbedingt Upgrade Den neuesten NetApp Kubernetes Monitoring Operator finden, wenn in Ihrer Umgebung PSP verwendet wird.

  • Wenn Sie auf OpenShift 4.6 oder höher laufen, müssen Sie die OpenShift-Anweisungen weiter unten befolgen. Außerdem müssen Sie sicherstellen, dass diese Voraussetzungen erfüllt sind.

  • Die Überwachung ist nur auf Linux Knoten installiert

    Cloud Insights unterstützt das Monitoring von Kubernetes-Nodes, auf denen Linux ausgeführt wird, indem eine Kubernetes-Node-Auswahl angegeben wird, die auf diesen Plattformen die folgenden Kubernetes-Labels berücksichtigt:

    Plattform

    Etikett

    Kubernetes v1.20 und höher

    Kubernetes.io/os = linux

    Rancher + Cattle.io als Orchestrierungs-/Kubernetes-Plattform

    Cattle.io/os = linux

  • Der NetApp Kubernetes Monitoring Operator und seine Abhängigkeiten (telegraf, kube-State-metrics, Fluentbit, etc.) werden nicht auf Nodes unterstützt, die mit der Arm64-Architektur ausgeführt werden.

  • Folgende Befehle müssen verfügbar sein: Curl, sudo, openssl, sha256sum und kubectl. Um optimale Ergebnisse zu erzielen, fügen Sie diese Befehle in den PFAD ein.

  • Der Host, den Sie für die Installation des NetApp Kubernetes Monitoring Operator verwenden werden, muss für die Kommunikation mit dem Ziel-K8s-Cluster kubectl konfiguriert sein. Zudem muss eine Internetverbindung zur Cloud Insights-Umgebung vorhanden sein. Wenn für diesen Host ein Proxy erforderlich ist, um Cloud Insights zu erreichen, befolgen Sie die Anweisungen im Proxy-Unterstützung Wird Konfiguriert Abschnitt.

  • Der NetApp Kubernetes Monitoring Operator installiert seine eigenen kube-State-Metriken, um Konflikte mit anderen Instanzen zu vermeiden.

  • Wenn Sie sich während der Installation hinter einem Proxy befinden oder wenn Sie den zu überwachenden K8s-Cluster betreiben, befolgen Sie die Anweisungen im Proxy-Unterstützung Wird Konfiguriert Abschnitt.

  • Zum Erstellen von Kubernetes-Clusterrollen und Rollenbindungen müssen Sie über die erforderlichen Berechtigungen verfügen.

Für eine genaue Audit- und Datenberichterstattung wird dringend empfohlen, die Zeit auf dem Agent-Rechner mit Network Time Protocol (NTP) oder Simple Network Time Protocol (SNTP) zu synchronisieren.

Beachten Sie diese, bevor Sie beginnen

Wenn Sie mit einem laufen Proxy, Haben Sie eine Benutzerdefiniertes Repository, Oder verwenden OpenShift, Lesen Sie die folgenden Abschnitte sorgfältig.

Wenn Sie ein Upgrade von einer früheren Installation durchführen, lesen Sie auch den Aktualisierung Informationsdaten.

Wenn Sie die Installationsdateien vor der Installation des Agenten überprüfen möchten, lesen Sie nach Überprüfen Von Kubernetes Prüfsummen.

Proxy-Unterstützung Wird Konfiguriert

An zwei Stellen können Sie in Ihrer Umgebung einen Proxy verwenden, um den NetApp Kubernetes Monitoring Operator zu installieren. Es kann sich um dieselben oder separate Proxy-Systeme handelt:

  • Proxy benötigt bei Ausführung des Installationscodes Snippet (mit "Curl"), um das System, an dem das Snippet ausgeführt wird, mit Ihrer Cloud Insights-Umgebung zu verbinden

  • Proxy für die Kommunikation mit Ihrer Cloud Insights Umgebung durch das Ziel-Kubernetes-Cluster

Wenn Sie einen Proxy für diesen oder beide verwenden, müssen Sie für die Installation des NetApp Kubernetes Operating Monitor zunächst sicherstellen, dass Ihr Proxy konfiguriert ist und eine gute Kommunikation mit Ihrer Cloud Insights-Umgebung ermöglicht. Wenn Sie über einen Proxy verfügen und über den Server/die VM auf Cloud Insights zugreifen können, von dem aus Sie den Operator installieren möchten, wird Ihr Proxy wahrscheinlich richtig konfiguriert.

Legen Sie für den Proxy, der zur Installation des NetApp Kubernetes Operating Monitor verwendet wurde, vor der Installation des Operators die Umgebungsvariablen http_Proxy/https_Proxy fest. In einigen Proxy-Umgebungen müssen Sie möglicherweise auch die Variable no_Proxy Environment festlegen.

Um die Variable(en) festzulegen, führen Sie auf Ihrem System vor der Installation des NetApp Kubernetes Monitoring Operators folgende Schritte aus:

  1. Legen Sie die Umgebungsvariable https_Proxy und/oder http_Proxy für den aktuellen Benutzer fest:

    1. Wenn der Proxy, der eingerichtet wird, keine Authentifizierung (Benutzername/Passwort) aufweist, führen Sie den folgenden Befehl aus:

       export https_proxy=<proxy_server>:<proxy_port>
.. Wenn der Proxy, der eingerichtet wird, über Authentifizierung (Benutzername/Passwort) verfügt, führen Sie folgenden Befehl aus:
      export http_proxy= <proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>

Nachdem Sie alle diese Anweisungen gelesen haben, installieren Sie den Proxy, der für die Kommunikation Ihres Kubernetes Clusters mit Ihrer Cloud Insights-Umgebung verwendet wurde.

Um die Konfiguration abzuschließen, führen Sie folgende Schritte auf dem System durch nach haben Sie den NetApp Kubernetes Monitoring Operator installiert.

Öffnen Sie zunächst die Datei Agent-Monitoring-netapp zur Bearbeitung:

 kubectl -n netapp-monitoring edit agent agent-monitoring-netapp
Suchen Sie den Abschnitt *spec:* dieser Datei und fügen Sie den folgenden Code hinzu:
 proxy:

 # If an AU is enabled on your cluster for monitoring
 # by Cloud Insights, then isAuProxyEnabled should be set to true:
  isAuProxyEnabled: <true or false>

 # If your Operator install is behind a corporate proxy,
 # isTelegrafProxyEnabled should be set to true:
  isTelegrafProxyEnabled: <true or false>

 # If LOGS_COLLECTION is enabled on your cluster for monitoring
 # by CI, then isFluentbitProxyEnabled should be set to true:
  isFluentbitProxyEnabled: <true or false>

 # Set the following values according to your proxy login:
  password: <password for proxy, optional>
  port: <port for proxy>
  server: <server for proxy>
  username: <username for proxy, optional

 # In the noProxy section, enter a comma-separated list of
 # IP addresses and/or resolvable hostnames that should bypass
 # the proxy:
  noProxy: <comma separated list>

Verwenden eines benutzerdefinierten oder privaten Docker Repositorys

Standardmäßig werden in der Konfiguration des NetApp Kubernetes Monitoring Operator Container-Images aus öffentlichen Registrys übertragen. Wenn Sie über ein Kubernetes-Cluster verfügen, das als Ziel für das Monitoring verwendet wird, Dieses Cluster ist so konfiguriert, dass nur Container-Images aus einem benutzerdefinierten oder privaten Docker Repository oder einer Container-Registrierung entfernt werden. Daher müssen Sie den Zugriff auf die Container konfigurieren, die vom NetApp Kubernetes Monitoring Operator benötigt werden, damit die erforderlichen Befehle ausgeführt werden können.

Verwenden Sie die folgenden Anweisungen, um Container-Images in Ihrer Registrierung vorab zu positionieren und die Konfiguration des NetApp Kubernetes Monitoring Operator zu ändern, um auf diese Images zuzugreifen. Ersetzen Sie Ihren gewählten Installations-Namespace in den folgenden Befehlen, wenn er sich vom Standard-Namespace von „netapp-Monitoring“ unterscheidet.

  1. Informieren Sie sich über den Docker:

     kubectl -n netapp-monitoring get secret docker -o yaml
. Den Wert von _.dockerconfigjson:_ aus der Ausgabe des obigen Befehls kopieren/einfügen.
. Decodieren des Dockers Secret:
    echo <paste from _.dockerconfigjson:_ output above> | base64 -d

Die Ausgabe dieser wird im folgenden JSON-Format vorliegen:

{ "auths":
  {"docker.<cluster>.cloudinsights.netapp.com" :
    {"username":"<tenant id>",
     "password":"<password which is the CI API token>",
     "auth"    :"<encoded username:password basic auth token. This is internal to docker>"}
  }
}

Melden Sie sich beim Docker Repository an:

docker login docker.<cluster>.cloudinsights.netapp.com (from step #2) -u <username from step #2>
password: <password from docker secret step above>

Ziehen Sie das Fahrerandockerbild aus dem Cloud Insights. Stellen Sie sicher, dass die Versionsnummer netapp-Monitoring aktuell ist:

docker pull docker.<cluster>.cloudinsights.netapp.com/netapp-monitoring:<version>
docker pull docker.<cluster>.cloudinsights.netapp.com/distroless-root-user:<version>

Suchen Sie das Feld „netapp-Monitoring <Version>“ mit dem folgenden Befehl:

 kubectl -n netapp-monitoring describe deployment monitoring-operator | grep -i "image:" |grep netapp-monitoring
Übertragen Sie das Operator-Docker-Image gemäß Ihren Unternehmensrichtlinien in das private/lokale/unternehmenseigene Docker-Repository.

Laden Sie alle Open-Source-Abhängigkeiten in Ihre private Docker-Registrierung herunter. Die folgenden Open-Source-Images müssen heruntergeladen werden. Siehe Voraussetzungen Abschnitt oben für die aktuellsten Versionen dieser Komponenten:

docker pull docker.<cluster>.cloudinsights.netapp.com/telegraf:<telegraf version>
docker pull docker.<cluster>.cloudinsights.netapp.com/kube-rbac-proxy:<kube-rbac-proxy version>
docker pull docker.<cluster>.cloudinsights.netapp.com/kube-state-metrics:<kube-state-metrics version>

Wenn fließendes Bit aktiviert ist, laden Sie auch Folgendes herunter:

docker pull docker.<cluster>.cloudinsights.netapp.com/fluent-bit:<fluent-bit version>
docker pull docker.<cluster>.cloudinsights.netapp.com/kubernetes-event-exporter:<kubernetes-event-exporter version>

Bearbeiten Sie die Bereitstellung des Monitoring-Operators, und ändern Sie alle Bildreferenzen, um den neuen Speicherort für den Docker Repo zu verwenden:

image: <docker repo of the enterprise/corp docker repo>/kube-rbac-proxy:<kube-rbac-proxy version>
image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>

Bearbeiten Sie das Agent CR, um den neuen Repoort des Dockers wiederzugeben.

kubectl -n netapp-monitoring edit agent agent-monitoring-netapp
docker-repo: <docker repo of the enterprise/corp docker repo>
dockerRepoSecret: <optional: name of the docker secret of enterprise/corp docker repo, this secret should be already created on the k8s cluster in the same namespace>

Nehmen Sie im Abschnitt spec: folgende Änderungen vor:

spec:
  telegraf:
    - name: ksm
      substitutions:
        - key: k8s.gcr.io
          value: <same as "docker-repo" field above>

OpenShift-Anweisungen

Wenn Sie auf OpenShift 4.6 oder höher ausgeführt werden, müssen Sie die Einstellung „privilegierter Modus“ ändern. Führen Sie den folgenden Befehl aus, um den Agenten zum Bearbeiten zu öffnen. Wenn Sie einen anderen Namespace als „netapp-Monitoring“ verwenden, geben Sie diesen Namespace in der Befehlszeile an:

 kubectl edit agent agent-monitoring-netapp -n netapp-monitoring
Ändern Sie in der Datei _privilegiert-Mode: False_ in _privilegiert-Mode: True_

OpenShift kann zusätzliche Sicherheitsstufen implementieren, die den Zugriff auf einige Kubernetes-Komponenten blockieren könnten.

Installation des NetApp Kubernetes Monitoring Operator

Bedienerbasierte Installation

Schritte zur Installation des NetApp Kubernetes Monitoring Operator Agent auf Kubernetes:

  1. Geben Sie einen eindeutigen Cluster-Namen und einen eindeutigen Namespace ein. Wenn Sie es sind Aktualisierung Verwenden Sie vom Skript-basierten Agent oder einem vorherigen Kubernetes Operator denselben Cluster-Namen und denselben Namespace.

  2. Sobald diese eingegeben wurden, können Sie das Snippet für den Agent Installer kopieren

  3. Klicken Sie auf die Schaltfläche, um dieses Snippet in die Zwischenablage zu kopieren.

  4. Fügen Sie das Snippet in ein bash Fenster ein und führen Sie es aus. Beachten Sie, dass das Snippet einen eindeutigen Schlüssel hat und für 24 Stunden gültig ist.

  5. Die Installation wird automatisch ausgeführt. Klicken Sie nach Abschluss des Programms auf die Schaltfläche Setup abschließen.

Anmerkung Die Einrichtung ist unvollständig, bis Sie abgeschlossen sind Konfigurieren Sie Ihren Proxy.
Anmerkung Wenn Sie über ein benutzerdefiniertes Repository verfügen, müssen Sie die Anweisungen für befolgen Verwenden eines benutzerdefinierten/privaten Docker-Repositorys.

Aktualisierung

Anmerkung Wenn Sie bereits über einen skriptbasierten Agent verfügen, müssen Sie _ein Upgrade auf den NetApp Kubernetes Monitoring Operator durchführen.

Upgrade vom skriptbasierten Agent auf den NetApp Kubernetes Monitoring Operator

Um den telegraf-Agent zu aktualisieren, gehen Sie wie folgt vor:

  1. Notieren Sie sich den Cluster-Namen, der von Cloud Insights anerkannt ist. Sie können den Cluster-Namen anzeigen, indem Sie den folgenden Befehl ausführen. Wenn Ihr Namespace nicht der Standard (CI-Monitoring) ist, ersetzen Sie den entsprechenden Namespace:

    kubectl -n ci-monitoring get cm telegraf-conf -o jsonpath='{.data}' |grep "kubernetes_cluster ="

  2. Speichern Sie den K8s-Clusternamen für die Verwendung während der Installation der Bedienerlösung K8s, um die Datenkontinuität zu gewährleisten.

    Wenn Sie sich den Namen des K8s-Clusters in CI nicht merken, können Sie ihn mit der folgenden Befehlszeile aus Ihrer gespeicherten Konfiguration extrahieren:

     cat /tmp/telegraf-configs.yaml | grep kubernetes_cluster | head -2
. Entfernen Sie die skriptbasierte Überwachung

    Gehen Sie wie folgt vor, um den skriptbasierten Agent auf Kubernetes zu deinstallieren:

    Wenn der Monitoring Namespace ausschließlich für Telegraf genutzt wird:

    kubectl --namespace ci-monitoring delete ds,rs,cm,sa,clusterrole,clusterrolebinding -l app=ci-telegraf
    kubectl delete ns ci-monitoring

    Wenn zusätzlich zu Telegraf der Monitoring-Namespace für andere Zwecke verwendet wird:

     kubectl --namespace ci-monitoring delete ds,rs,cm,sa,clusterrole,clusterrolebinding -l app=ci-telegraf
. <<installing-the-netapp-kubernetes-monitoring-operator,Installieren>> Der aktuelle Operator. Verwenden Sie unbedingt denselben Cluster-Namen, wie oben in Schritt 1 beschrieben.

Upgrade auf den aktuellen NetApp Kubernetes Monitoring Operator

Führen Sie die folgenden Befehle für die Aktualisierung der Installation durch, die auf dem Bediener basiert:

  • Notieren Sie sich den Cluster-Namen, der von Cloud Insights anerkannt ist. Sie können den Cluster-Namen anzeigen, indem Sie den folgenden Befehl ausführen. Wenn Ihr Namespace nicht der Standard (netapp-Monitoring) ist, ersetzen Sie den entsprechenden Namespace:

    kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}'

Deinstallieren Der aktuelle Operator.

Installieren Der neueste Operator. Verwenden Sie denselben Cluster-Namen und stellen Sie sicher, dass Sie neue Container-Images ziehen, wenn Sie eine benutzerdefinierte Repo eingerichtet haben.

Stoppen und Starten des NetApp Kubernetes Monitoring Operator

So beenden Sie den NetApp Kubernetes Monitoring Operator:

 kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0
So starten Sie den NetApp Kubernetes Monitoring Operator:
kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=1

Deinstallation

Anmerkung Wenn Sie auf einem bereits installierten, skriptbasierten Kubernetes-Agent ausgeführt werden, müssen Sie dies unbedingt tun Upgrade Für den NetApp Kubernetes Monitoring Operator.

Um den veralteten, skriptbasierten Agent zu entfernen

Beachten Sie, dass diese Befehle den Standard-Namespace "CI-Monitoring" verwenden. Wenn Sie Ihren eigenen Namespace festgelegt haben, ersetzen Sie diesen Namespace in diesen und allen nachfolgenden Befehlen und Dateien.

Um den skriptbasierten Agent auf Kubernetes zu deinstallieren (z. B. bei einem Upgrade auf den NetApp Kubernetes Monitoring Operator), gehen Sie folgendermaßen vor:

Wenn der Monitoring Namespace ausschließlich für Telegraf genutzt wird:

 kubectl --namespace ci-monitoring delete ds,rs,cm,sa,clusterrole,clusterrolebinding -l app=ci-telegraf
 kubectl delete ns ci-monitoring
Wenn zusätzlich zu Telegraf der Monitoring-Namespace für andere Zwecke verwendet wird:
kubectl --namespace ci-monitoring delete ds,rs,cm,sa,clusterrole,clusterrolebinding -l app=ci-telegraf

Um den NetApp Kubernetes Monitoring Operator zu entfernen

Beachten Sie, dass der Standard-Namespace für den NetApp Kubernetes Monitoring Operator „netapp-Monitoring“ ist. Wenn Sie Ihren eigenen Namespace festgelegt haben, ersetzen Sie diesen Namespace in diesen und allen nachfolgenden Befehlen und Dateien.

Neuere Versionen des Überwachungsoperators können mit den folgenden Befehlen deinstalliert werden:

kubectl delete agent -A -l installed-by=nkmo-<name-space>
kubectl delete ns,clusterrole,clusterrolebinding,crd -l installed-by=nkmo-<name-space>

Wenn der erste Befehl „Keine Ressourcen gefunden“ zurückgibt, verwenden Sie die folgenden Anweisungen, um ältere Versionen des Überwachungsoperators zu deinstallieren.

Führen Sie jeden der folgenden Befehle in der Reihenfolge aus. Abhängig von Ihrer aktuellen Installation können einige dieser Befehle Nachrichten ‘object not found’ zurückgeben. Diese Meldungen können sicher ignoriert werden.

kubectl -n <NAMESPACE> delete agent agent-monitoring-netapp
kubectl delete crd agents.monitoring.netapp.com
kubectl -n <NAMESPACE> delete role agent-leader-election-role
kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader <NAMESPACE>-agent-manager-role <NAMESPACE>-agent-proxy-role <NAMESPACE>-cluster-role-privileged
kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding <NAMESPACE>-agent-manager-rolebinding <NAMESPACE>-agent-proxy-rolebinding <NAMESPACE>-cluster-role-binding-privileged
kubectl delete <NAMESPACE>-psp-nkmo
kubectl delete ns <NAMESPACE>

Wenn zuvor eine Security Context Constraint manuell für eine skriptbasierte Telegraf-Installation erstellt wurde:

kubectl delete scc telegraf-hostaccess

Über Kube-State-Metrics

Der NetApp Kubernetes Monitoring Operator installiert kube-State-Metriken automatisch. Gleichzeitig ist keine Interaktion mit den Benutzern erforderlich.

kube-State-Metrics Counters

Verwenden Sie die folgenden Links, um auf Informationen zu diesen kube State-Metriken zuzugreifen:

  1. "Kennzahlen für die Konfigmap"

  2. "DemonSet Metrics"

  3. "Implementierungsmetriken"

  4. "Ingress Metrics"

  5. "Namespace-Kennzahlen"

  6. "Node-Kennzahlen"

  7. "Persistente Volume-Kennzahlen"

  8. "Kenngrößen Für Die Forderung Im Persistenten Volume"

  9. "Pod-Metriken"

  10. "Kennzahlen für ReplicaSet"

  11. "Geheimkennzahlen"

  12. "Service-Kennzahlen"

  13. "StatfulSet-Kennzahlen"

Überprüfen Von Kubernetes Prüfsummen

Das Cloud Insights Agent-Installationsprogramm führt Integritätsprüfungen durch. Einige Benutzer müssen jedoch vor der Installation oder Anwendung heruntergeladener Artefakte möglicherweise ihre eigenen Überprüfungen durchführen. Um einen nur-Download-Vorgang durchzuführen (im Gegensatz zum Standard-Download-and-install), können diese Benutzer den Agent-Installation Befehl erhalten von der UI und entfernen Sie die nachhängbare "Installation" Option.

Führen Sie hierzu folgende Schritte aus:

  1. Kopieren Sie das Agent Installer-Snippet wie angewiesen.

  2. Anstatt das Snippet in ein Befehlsfenster einzufügen, fügen Sie es in einen Texteditor ein.

  3. Entfernen Sie den nachfolgenden „--install“ aus dem Befehl.

  4. Kopieren Sie den gesamten Befehl aus dem Texteditor.

  5. Fügen Sie es nun in Ihr Befehlsfenster ein (in einem Arbeitsverzeichnis) und führen Sie es aus.

    • Download und Installation (Standard):

       installerName=cloudinsights-kubernetes.sh … && sudo -E -H ./$installerName --download –-install
** Nur Download:
      installerName=cloudinsights-kubernetes.sh … && sudo -E -H ./$installerName --download

Der Download-Only-Befehl lädt alle erforderlichen Artefakte vom Cloud Insights in das Arbeitsverzeichnis herunter. Die Artefakte umfassen, dürfen aber nicht beschränkt sein auf:

  • Ein Installationsskript

  • Einer Umgebungsdatei

  • YAML-Dateien

  • Eine signierte Prüfsumme-Datei (sha256.signed)

  • Eine PEM-Datei (netapp_cert.pem) zur Signaturverifizierung

Das Installationsskript, die Umgebungsdatei und die YAML-Dateien können mittels Sichtprüfung verifiziert werden.

Die PEM-Datei kann durch Bestätigung des Fingerabdrucks wie folgt verifiziert werden:

 1A918038E8E127BB5C87A202DF173B97A05B4996
Genauer gesagt,
 openssl x509 -fingerprint -sha1 -noout -inform pem -in netapp_cert.pem
Die signierte Prüfsummendatei kann mit der PEM-Datei verifiziert werden:
 openssl smime -verify -in sha256.signed -CAfile netapp_cert.pem -purpose any
Sobald alle Artefakte zufriedenstellend überprüft wurden, kann die Agenteninstallation durch Ausführen von gestartet werden:
sudo -E -H ./<installation_script_name> --install

Einstellung des Bedienpersonals

Sie können den NetApp Kubernetes Monitoring Operator für eine optimale Performance anpassen, indem Sie bestimmte Variablen für benutzerdefinierte Ressourcen Feinabstimmung vornehmen. Anweisungen und Listen der Variablen, die Sie einstellen können, finden Sie in der im Installationspaket enthaltenen README-Datei. Verwenden Sie nach der Installation des Operators den folgenden Befehl, um README anzuzeigen:

kubectl exec -c manager -it <operator-pod-name> -n <namespace> -- cat configs/substitution-vars/README.txt

Fehlerbehebung

Einige Dinge, die Sie versuchen können, wenn Probleme bei der Einrichtung des NetApp Kubernetes Monitoring Operators auftreten:

Problem: Versuchen Sie dies:

Ich sehe keinen Hyperlink/Verbindung zwischen meinem Kubernetes Persistent Volume und dem entsprechenden Back-End Storage-Gerät. Mein Kubernetes Persistent Volume wird mit dem Hostnamen des Storage-Servers konfiguriert.

Befolgen Sie die Schritte, um den bestehenden Telegraf-Agent zu deinstallieren, und installieren Sie dann den neuesten Telegraf-Agent erneut. Sie müssen Telegraf Version 2.0 oder höher verwenden, und Ihr Kubernetes Cluster Storage muss von Cloud Insights aktiv überwacht werden.

Ich sehe Nachrichten in den Protokollen, die folgenden ähneln: E0901 15:21:39.962145 1 Reflektor.go:178] k8s.io/kube-State-metrics/intern/Store/Builder.go:352: Listen fehlgeschlagen *v1.MutatingWebhookKonfiguration: Der Server konnte die angeforderte Ressource E0901 15:21 352:43.168161 1 Reflektor.GO:178] k8s.io/kukio-Verzeichnis nicht gefunden

Diese Nachrichten können auftreten, wenn Sie kube-State-Metrics Version 2.0.0 oder höher mit Kubernetes-Versionen unter 1.20 ausführen. Um die Kubernetes-Version zu erhalten: Kubectl Version um die kube-State-metrics-Version zu erhalten: Kubectl get Deploy/kube-State-metrics -o jsonpath='{..image}' um zu verhindern, dass diese Nachrichten passieren, können Benutzer ihre kube-State-Metrics-Implementierung ändern, um die folgenden Elemente zu deaktivieren: _Mutingwebhookkonfigurationen___volumehaWeitere Resources=certificationesigningrequests,configmaps,cronjobs,dämsets, Bereitstellungen,Endpunkte,HorizontalpodAutoscaler,nesresses,Jobs,Begrenzungsbereiche,Namensräume,Netzwerkrichtlinien,Knoten,Persistenz,stagemasnesmases,nesmasnesmases,nesmasnesmasnesmasnesnesmasnesequets,ndecoses,nescontascrises,nesequequequequesefises,nesequequesequesefiscones,mases,nesequidatequesequesefiscones,nesequesequesefiscrises,nesequesequesefiscones,nesefisconesefisconmases,mases,nesequesequesefiscones,necequesequeseques Validatingwebhookkonfigurationen, Volumeanhänge“

Ich sehe Fehlermeldungen von Telegraf ähnlich wie die folgenden, aber Telegraf startet und läuft: Okt 11 14:23:41 ip-172-31-39-47 systemd[1]: Startete den Plugin-getriebenen Server Agent für das Reporting von Metriken in InfluxDB. Okt 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time=„2021-10-11T14:23:41Z“ Level=error msg=„konnte kein Cache-Verzeichnis erstellen. /Etc/telegraf/.Cache/snowflake, err: Mkdir /etc/telegraf/.ca che: Berechtigung verweigert. Ignorierte\n" Funktion=„gosnowflake.(*defaultLogger).Errorf“ file=„log.go:120“ Okt 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time=„2021-10-11T14:23:41Z“ Level=Fehler msg=„konnte nicht geöffnet werden. Ignoriert. Öffnen Sie /etc/telegraf/.Cache/snowflake/ocsp_response_Cache.json: Keine solche Datei oder Verzeichnis\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.go:120" Okt 11 14:23:41 ip-172-31:39-47 telegraf[1827 23]: 2021-10-11T14:41I! Telegraf 1.19.3 Starten

Dies ist ein bekanntes Problem. Siehe "Dieser GitHub-Artikel" Entnehmen. Solange Telegraf läuft, können Benutzer diese Fehlermeldungen ignorieren.

Auf Kubernetes meldet mein Telegraf pod(s) den folgenden Fehler: „Fehler in der Verarbeitung von mountstats-Infos: Habe mountstats-Datei nicht geöffnet: /Hostfs/proc/1/mountstats, Fehler: Open /hostfs/proc/1/mountstats: Permission dementied“

Wenn SELinux aktiviert ist und die Durchsetzung aktiviert wird, wird wahrscheinlich verhindert, dass Telegraf Pod(s) auf die Datei /proc/1/mountstats auf den Kubernetes Nodes zugreifen. Um diese Einschränkung zu entspannen, bearbeiten Sie den Agenten (kubectl edit agent agent-monitoring-netapp), und ändern Sie "Privileged-Mode: False" in "Privileged-Mode: True"

Auf Kubernetes meldet mein Telegraf ReplicaSet POD den folgenden Fehler: [inputs.prometheus] Fehler im Plugin: Konnte keine keypair /etc/kubernetes/pki/etcd/Server.crt:/etc/kubernetes/pki/etcd/Server.key: Öffnen /etc/kubernetes/pki/etcd/Server.crt: Keine solche Datei oder Verzeichnis

Der Pod Telegraf ReplicaSet soll auf einem Knoten ausgeführt werden, der als Master oder für etc bestimmt ist. Wenn der ReplicaSet-Pod auf einem dieser Knoten nicht ausgeführt wird, werden diese Fehler angezeigt. Überprüfen Sie, ob Ihre Master/etcd-Knoten eine Tönungswalle haben. Fügen Sie in diesem Fall die erforderlichen Verträgungen in das Telegraf ReplicaSet, telegraf-rs ein. Bearbeiten Sie zum Beispiel die Datei ReplicaSet…​ kubectl edit rs telegraf-rs …​und fügen Sie die entsprechenden Verträgungen der Spezifikation hinzu. Starten Sie anschließend den Pod ReplicaSet neu.

Ich habe eine PSP/PSA Umgebung. Hat dies Auswirkungen auf meinen Überwachungsperator?

Wenn Ihr Kubernetes Cluster mit der Pod Security Policy (PSP) oder PSA (Pod Security Admission) ausgeführt wird, müssen Sie ein Upgrade auf den aktuellen NetApp Kubernetes Monitoring Operator durchführen. Führen Sie die folgenden Schritte aus, um auf den aktuellen NKMO mit Unterstützung für PSP/PSA zu aktualisieren: 1. Deinstallieren Der vorherige Überwachungsoperator: Kubectl delete Agent-Monitoring-netapp -n netapp-Monitoring kubectl delete ns netapp-Monitoring kubectl delete crd agents.monitoring.netapp.com kubectl delete clusterrolle Agent-Manager-role Agent-Proxy-role Agent-metrics-reader kubectl delete clusterrolebinding Agent-Manager-rolebinding Agent-Proxy-rolebinding Agent-Proxy-rolebinding Agent-Cluster-admin-rolebinding 2. Installieren Die neueste Version des Überwachungsbedieners.

Bei der Bereitstellung des NKMO begegnete mir Probleme, und PSP/PSA ist im Einsatz.

1. Bearbeiten Sie den Agenten mit dem folgenden Befehl: Kubectl -n <Name-space> Edit Agent 2. Markieren Sie „Sicherheitspolitik aktiviert“ als „falsch“. Dadurch werden Pod Security Policies und Pod Security Admission deaktiviert und die Bereitstellung des NKMO ermöglicht. Bestätigung mit den folgenden Befehlen: Kubectl get psp (sollte Pod Security Policy entfernt zeigen) kubectl get all -n <Namespace> grep -i psp (sollte zeigen, dass nichts gefunden wird)

„ImagePullBackoff“-Fehler erkannt

Diese Fehler treten möglicherweise auf, wenn Sie über ein benutzerdefiniertes oder privates Docker Repository verfügen und den NetApp Kubernetes Monitoring Operator noch nicht so konfiguriert haben, dass es richtig erkannt wird. Weitere Informationen Info zur Konfiguration für benutzerdefinierte/private Repo.

Ich habe ein Problem mit der Installation meines Monitoring-Bedieners, und die aktuelle Dokumentation hilft mir nicht, es zu lösen.

Erfassen oder notieren Sie die Ausgabe der folgenden Befehle, und wenden Sie sich an den technischen Support.

 kubectl -n netapp-monitoring get all
 kubectl -n netapp-monitoring describe all
 kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true
 kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true

Weitere Informationen finden Sie im "Unterstützung" Oder auf der "Data Collector Supportmatrix".