**Unterstützung für die Verbesserung dieser Seite beitragen** Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet. Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Rohmetriken der Steuerebene im Prometheus-Format abrufen Die Kubernetes-Steuerebene stellt eine Reihe von Metriken bereit, die im [Prometheus-Format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) dargestellt werden. Diese Metriken sind für die Überwachung und Analyse hilfreich. Sie werden intern über Metrik-Endpunkte bereitgestellt und können ohne vollständige Bereitstellung von Prometheus abgerufen werden. Die Bereitstellung von Prometheus vereinfacht jedoch die Analyse von Metriken im Zeitverlauf. Um die Rohdaten der Metriken anzuzeigen, ersetzen Sie `endpoint` und führen Sie den folgenden Befehl aus. ``` kubectl get --raw endpoint ``` Mit diesem Befehl können Sie einen beliebigen Endpunktpfad übergeben und erhalten die Rohdaten als Antwort zurück. Die Ausgabe listet zeilenweise verschiedene Metriken auf, wobei jede Zeile einen Metriknamen, Tags und einen Wert enthält. ``` metric_name{tag="value"[,...]} value ``` ## Metriken vom API-Server abrufen Der allgemeine API-Server-Endpunkt wird in der Amazon-EKS-Steuerebene bereitgestellt. Dieser Endpunkt ist vor allem nützlich, wenn Sie eine bestimmte Metrik betrachten möchten. ``` kubectl get --raw /metrics ``` Eine Beispielausgabe sieht wie folgt aus. ``` [...] # HELP rest_client_requests_total Number of HTTP requests, partitioned by status code, method, and host. # TYPE rest_client_requests_total counter rest_client_requests_total{code="200",host="127.0.0.1:21362",method="POST"} 4994 rest_client_requests_total{code="200",host="127.0.0.1:443",method="DELETE"} 1 rest_client_requests_total{code="200",host="127.0.0.1:443",method="GET"} 1.326086e+06 rest_client_requests_total{code="200",host="127.0.0.1:443",method="PUT"} 862173 rest_client_requests_total{code="404",host="127.0.0.1:443",method="GET"} 2 rest_client_requests_total{code="409",host="127.0.0.1:443",method="POST"} 3 rest_client_requests_total{code="409",host="127.0.0.1:443",method="PUT"} 8 # HELP ssh_tunnel_open_count Counter of ssh tunnel total open attempts # TYPE ssh_tunnel_open_count counter ssh_tunnel_open_count 0 # HELP ssh_tunnel_open_fail_count Counter of ssh tunnel failed open attempts # TYPE ssh_tunnel_open_fail_count counter ssh_tunnel_open_fail_count 0 ``` Diese Rohausgabe zeigt exakt das, was der API-Server bereitstellt. ## Metriken der Steuerebene mit `metrics.eks.amazonaws.com` abrufen Für Cluster mit Kubernetes-Version `1.28` und höher stellt Amazon EKS auch Metriken unter der API-Gruppe `metrics.eks.amazonaws.com` bereit. Diese Metriken umfassen Steuerebenen-Komponenten wie `kube-scheduler` und `kube-controller-manager`. **Anmerkung** Wenn Sie über eine Webhook-Konfiguration verfügen, welche die Erstellung der neuen `APIService`-Ressource `v1.metrics.eks.amazonaws.com` in Ihrem Cluster blockieren könnte, ist das Feature des Metrik-Endpunkts möglicherweise nicht verfügbar. Sie können dies im Überwachungsprotokoll `kube-apiserver` überprüfen, indem Sie nach dem Schlüsselwort `v1.metrics.eks.amazonaws.com` suchen. ### `kube-scheduler`-Metriken abrufen Verwenden Sie zum Abrufen von `kube-scheduler`-Metriken den folgenden Befehl. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics" ``` Eine Beispielausgabe sieht wie folgt aus. ``` # TYPE scheduler_pending_pods gauge scheduler_pending_pods{queue="active"} 0 scheduler_pending_pods{queue="backoff"} 0 scheduler_pending_pods{queue="gated"} 0 scheduler_pending_pods{queue="unschedulable"} 18 # HELP scheduler_pod_scheduling_attempts [STABLE] Number of attempts to successfully schedule a pod. # TYPE scheduler_pod_scheduling_attempts histogram scheduler_pod_scheduling_attempts_bucket{le="1"} 79 scheduler_pod_scheduling_attempts_bucket{le="2"} 79 scheduler_pod_scheduling_attempts_bucket{le="4"} 79 scheduler_pod_scheduling_attempts_bucket{le="8"} 79 scheduler_pod_scheduling_attempts_bucket{le="16"} 79 scheduler_pod_scheduling_attempts_bucket{le="+Inf"} 81 [...] ``` ### `kube-controller-manager`-Metriken abrufen Verwenden Sie zum Abrufen von `kube-controller-manager`-Metriken den folgenden Befehl. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics" ``` Eine Beispielausgabe sieht wie folgt aus. ``` [...] workqueue_work_duration_seconds_sum{name="pvprotection"} 0 workqueue_work_duration_seconds_count{name="pvprotection"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-08"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-07"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="1e-06"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-06"} 0 workqueue_work_duration_seconds_bucket{name="replicaset",le="9.999999999999999e-05"} 19 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.001"} 109 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.01"} 139 workqueue_work_duration_seconds_bucket{name="replicaset",le="0.1"} 181 workqueue_work_duration_seconds_bucket{name="replicaset",le="1"} 191 workqueue_work_duration_seconds_bucket{name="replicaset",le="10"} 191 workqueue_work_duration_seconds_bucket{name="replicaset",le="+Inf"} 191 workqueue_work_duration_seconds_sum{name="replicaset"} 4.265655885000002 [...] ``` ### Metriken des Schedulers und des Controller-Managers verstehen In der folgenden Tabelle werden die Scheduler- und Controller-Manager-Metriken beschrieben, die für das Scraping im Prometheus-Stil verfügbar gemacht werden. eitere Informationen zu diesen Metriken finden Sie in der [Kubernetes-Metriken-Referenz](https://kubernetes.io/docs/reference/instrumentation/metrics/) in der Kubernetes-Dokumentation. | Metrik | Komponente der Steuerebene | Beschreibung | | --- | --- | --- | | scheduler\$1pending\$1pods | Scheduler | Die Anzahl der Pods, die darauf warten, zur Ausführung in einen Knoten geplant zu werden. | | scheduler\$1schedule\$1attempts\$1total | Scheduler | Die Anzahl der Versuche, Pods zu planen. | | scheduler\$1preemption\$1attempts\$1total | Scheduler | Die Anzahl der Versuche des Schedulers, Pods mit höherer Priorität zu planen, indem Pods mit niedrigerer Priorität entfernt werden. | | scheduler\$1preemption\$1victims | Scheduler | Die Anzahl der Pods, die zur Bereinigung ausgewählt wurden, um Platz für Pods mit höherer Priorität zu schaffen. | | scheduler\$1pod\$1scheduling\$1attempts | Scheduler | Die Anzahl der Versuche, einen Pod erfolgreich zu planen. | | scheduler\$1scheduling\$1attempt\$1duration\$1seconds | Scheduler | Gibt an, wie schnell oder langsam der Scheduler in der Lage ist, einen geeigneten Ausführungsort für einen Pod zu finden, basierend auf verschiedenen Faktoren wie Ressourcenverfügbarkeit und Planungsregeln. | | scheduler\$1pod\$1scheduling\$1sli\$1duration\$1seconds | Scheduler | Die durchgängige Latenz für einen Pod, der geplant wird, ab dem Zeitpunkt, an dem der Pod in die Planungswarteschlange aufgenommen wird. Dies kann mehrere Planungsversuche umfassen. | | cronjob\$1controller\$1job\$1creation\$1skew\$1duration\$1seconds | controller manager | Der Zeitraum zwischen der geplanten Ausführung eines Cronjobs und der Erstellung des entsprechenden Auftrags. | | workqueue\$1depth | controller manager | Die aktuelle Ebene der Warteschlange. | | workqueue\$1adds\$1total | controller manager | Die Gesamtzahl der von der Arbeitswarteschlange bearbeiteten Einträge. | | workqueue\$1queue\$1duration\$1seconds | controller manager | Die Zeit in Sekunden, die ein Element in der Arbeitswarteschlange verbleibt, bevor es angefordert wird. | | workqueue\$1work\$1duration\$1seconds | controller manager | Die Zeit in Sekunden, die für die Bearbeitung eines Elements aus der Arbeitswarteschlange benötigt wird. | ## Prometheus-Scraper einsetzen, um Metriken konsistent zu scrapen Um einen Prometheus-Scraper einzusetzen, der die Metriken konsistent scrapt, verwenden Sie die folgende Konfiguration: ``` --- apiVersion: v1 kind: ConfigMap metadata: name: prometheus-conf data: prometheus.yml: |- global: scrape_interval: 30s scrape_configs: # apiserver metrics - job_name: apiserver-metrics kubernetes_sd_configs: - role: endpoints scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https # Scheduler metrics - job_name: 'ksh-metrics' kubernetes_sd_configs: - role: endpoints metrics_path: /apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https # Controller Manager metrics - job_name: 'kcm-metrics' kubernetes_sd_configs: - role: endpoints metrics_path: /apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [ __meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name, ] action: keep regex: default;kubernetes;https --- apiVersion: v1 kind: Pod metadata: name: prom-pod spec: containers: - name: prom-container image: prom/prometheus ports: - containerPort: 9090 volumeMounts: - name: config-volume mountPath: /etc/prometheus/ volumes: - name: config-volume configMap: name: prometheus-conf ``` Die folgende Berechtigung ist erforderlich, damit der Pod auf den neuen Metrik-Endpunkt zugreifen kann. ``` { "effect": "allow", "apiGroups": [ "metrics.eks.amazonaws.com" ], "resources": [ "kcm/metrics", "ksh/metrics" ], "verbs": [ "get" ] }, ``` Um die verwendete Rolle zu patchen, können Sie den folgenden Befehl verwenden. ``` kubectl patch clusterrole --type=json -p='[ { "op": "add", "path": "/rules/-", "value": { "verbs": ["get"], "apiGroups": ["metrics.eks.amazonaws.com"], "resources": ["kcm/metrics", "ksh/metrics"] } } ]' ``` Anschließend können Sie das Prometheus-Dashboard anzeigen, indem Sie den Port des Prometheus-Scrapers auf Ihren lokalen Port umstellen. ``` kubectl port-forward pods/prom-pod 9090:9090 ``` Für Ihren Amazon-EKS-Cluster werden die Kernmetriken der Kubernetes-Steuerebene auch unter dem `AWS/EKS`-Namespace in Amazon CloudWatch-Metriken aufgenommen. Um sie anzuzeigen, öffnen Sie die [CloudWatch-Konsole](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks) und wählen Sie im linken Navigationsbereich **Alle Metriken** aus. Wählen Sie auf der Auswahlseite **Metriken** den `AWS/EKS`-Namespace und eine Metrikdimension für Ihren Cluster aus.