**Contribuisci a migliorare questa pagina** Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. Per contribuire a questa guida per l'utente, scegli il GitHub link **Modifica questa pagina** nel riquadro destro di ogni pagina. Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Recupero delle metriche grezze del piano di controllo in formato Prometheus Il piano di controllo Kubernetes espone una serie di metriche che sono rappresentate in un [formato Prometheus.](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) Questi parametri sono utili per il monitoraggio e l'analisi. Sono esposti internamente tramite endpoint metrici ed è possibile accedervi senza dover implementare completamente Prometheus. Tuttavia, l’implementazione più semplice di Prometheus consente di analizzare le metriche nel tempo. Per visualizzare il risultato delle metriche grezze, sostituisci `endpoint` ed esegui il comando riportato. ``` kubectl get --raw endpoint ``` Questo comando consente di inoltrare qualsiasi endpoint e restituisce la risposta non elaborata. I diversi parametri sono elencati per riga e ogni riga include un nome di parametro, tag e un valore. ``` metric_name{tag="value"[,...]} value ``` ## Recuperare le metriche dal server API L’endpoint del server API generale è esposto sul piano di controllo Amazon EKS. Questo endpoint è utile principalmente per esaminare una metrica specifica. ``` kubectl get --raw /metrics ``` Di seguito viene riportato un output di esempio: ``` [...] # 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 ``` Questo output non elaborato restituisce in modo completo ciò che il server API espone. ## Recupera le metriche del piano di controllo con `metrics.eks.amazonaws.com` Per i cluster con versione Kubernetes `1.28` e successive, Amazon EKS espone anche i parametri relativi al gruppo di API `metrics.eks.amazonaws.com`. Queste metriche includono componenti del piano di controllo come `kube-scheduler` e `kube-controller-manager`. **Nota** Se disponi di una configurazione webhook che potrebbe bloccare la creazione della nuova risorsa `APIService` `v1.metrics.eks.amazonaws.com` nel cluster, la funzionalità degli endpoint delle metriche potrebbe non essere disponibile. È possibile verificarlo nel log di verifica `kube-apiserver` cercando la parola chiave `v1.metrics.eks.amazonaws.com`. ### Recuperare le metriche `kube-scheduler` Utilizza il codice seguente per recuperare le metriche `kube-scheduler`. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics" ``` Di seguito viene riportato un output di esempio: ``` # 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 [...] ``` ### Recuperare le metriche `kube-controller-manager` Utilizza il codice seguente per recuperare le metriche `kube-controller-manager`. ``` kubectl get --raw "/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics" ``` Di seguito viene riportato un output di esempio: ``` [...] 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 [...] ``` ### Comprendere le metriche di gestione del sistema di pianificazione e del controller La tabella seguente descrive le metriche di gestione del sistema di pianificazione e del controller rese disponibili per lo scraping in stile Prometheus. Per ulteriori informazioni relative a queste metriche, consulta [Riferimento delle metriche Kubernetes](https://kubernetes.io/docs/reference/instrumentation/metrics/) nella documentazione Kubernetes. | Parametro | Componente del piano di controllo | Descrizione | | --- | --- | --- | | scheduler\$1pending\$1pods | pianificatore | Il numero di pod in attesa di essere pianificati su un nodo per l’esecuzione. | | scheduler\$1schedule\$1attempts\$1total | pianificatore | Il numero di tentativi effettuati per pianificare i pod. | | scheduler\$1preemption\$1attempts\$1total | pianificatore | Il numero di tentativi effettuati dal sistema di pianificazione per i pod con priorità più alta eliminando quelli con priorità inferiore. | | scheduler\$1preemption\$1victims | pianificatore | Il numero di pod che sono stati selezionati per l’espulsione per fare spazio ai pod con priorità più alta. | | scheduler\$1pod\$1scheduling\$1attempts | pianificatore | Il numero di tentativi di pianificare correttamente un pod. | | scheduler\$1scheduling\$1attempt\$1duration\$1seconds | pianificatore | Indica la velocità o la lentezza con cui lo strumento di pianificazione riesce a trovare un luogo adatto per l’esecuzione di un pod in base a vari fattori come la disponibilità delle risorse e le regole di pianificazione. | | scheduler\$1pod\$1scheduling\$1sli\$1duration\$1seconds | pianificatore | La latenza end-to-end per un pod in fase di pianificazione, dal momento in cui il pod entra nella coda di pianificazione. Ciò potrebbe comportare più tentativi di pianificazione. | | cronjob\$1controller\$1job\$1creation\$1skew\$1duration\$1seconds | gestore del controller | Il tempo che intercorre tra la pianificazione dell’esecuzione di un cronjob e la creazione del processo corrispondente. | | workqueue\$1depth | gestore del controller | La profondità corrente della coda. | | workqueue\$1adds\$1total | gestore del controller | Il numero totale di aggiunte gestite dalla coda di lavoro. | | workqueue\$1queue\$1duration\$1seconds | gestore del controller | Il tempo in secondi in cui un elemento rimane nella coda di lavoro prima di essere richiesto. | | workqueue\$1work\$1duration\$1seconds | gestore del controller | Il tempo in secondi impiegato per l’elaborazione di un elemento dalla coda di lavoro. | ## Implementare uno scraper Prometheus per acquisire metriche in modo coerente Per implementare uno scraper Prometheus per eseguire lo scraping delle metriche in modo coerente, utilizza la seguente configurazione: ``` --- 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 ``` L’autorizzazione che segue è richiesta per consentire al pod di accedere al nuovo endpoint metrico. ``` { "effect": "allow", "apiGroups": [ "metrics.eks.amazonaws.com" ], "resources": [ "kcm/metrics", "ksh/metrics" ], "verbs": [ "get" ] }, ``` Per applicare una patch al ruolo, puoi utilizzare il seguente comando. ``` kubectl patch clusterrole --type=json -p='[ { "op": "add", "path": "/rules/-", "value": { "verbs": ["get"], "apiGroups": ["metrics.eks.amazonaws.com"], "resources": ["kcm/metrics", "ksh/metrics"] } } ]' ``` Quindi puoi visualizzare la dashboard di Prometheus effettuando il proxy della porta dello scraper Prometheus verso la porta locale. ``` kubectl port-forward pods/prom-pod 9090:9090 ``` Per il tuo cluster Amazon EKS, le principali metriche del piano di controllo Kubernetes sono inserite anche nelle metriche di Amazon CloudWatch sotto il namespace `AWS/EKS`. Per visualizzarli, apri la [console CloudWatch](https://console.aws.amazon.com/cloudwatch/home#logs:prefix=/aws/eks) e seleziona **Tutte le metriche** dal riquadro di navigazione a sinistra. Nella pagina di selezione **Metriche**, scegli il namespace `AWS/EKS` e una dimensione delle metriche per il tuo cluster.