Gestion du cluster Kubernetes - suivre les composants système Kubernetes, les agents

1. Suivi des composants du système Kubernetes

État de la fonctionnalité : Kubernetes v1.27 [bêta]

La fonction de suivi des composants du système enregistre les informations de latence des opérations de cluster individuelles et la relation entre ces opérations.

Le composant Kubernetes envoie des informations de suivi basées sur le protocole OpenTelemetry de l'exportateur gRPC, collecte les informations de suivi avec le collecteur OpenTelemetry, puis les transfère en arrière-plan du système de suivi.

1. Collecte d'informations de suivi

Un guide complet sur la collecte des informations de trace et l'utilisation du collecteur est disponible dans Mise en route avec le collecteur OpenTelemetry. Cependant, il y a quelques éléments spécifiques aux composants Kubernetes qui méritent d'être notés.

Par défaut, les composants Kubernetes utilisent l'exportateur OTLP de gRPC pour exporter les informations de trace, en écrivant les informations sur le port IANA OpenTelemetry. Par exemple, si le collecteur s'exécute en tant que side-car d'un composant Kubernetes, la configuration de récepteur suivante collectera les informations d'étendue et les écrira sur la sortie standard.

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  # 用适合你后端环境的导出器替换此处的导出器
  logging:
    logLevel: debug
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [logging]

2. Suivi des composants

2.1 suivi kube-apiserver

kube-apiserver génère des étendues pour les requêtes HTTP entrantes, les requêtes sortantes vers les webhooks et etcd, et les requêtes réentrantes. Étant donné que kube-apiserver est généralement un point de terminaison public, il propage le contexte de trace W3C sur les requêtes sortantes, mais n'utilise pas le contexte de trace sur les requêtes entrantes.

2.2 Activer le traçage dans kube-apiserver

Pour activer la fonctionnalité de traçage, un fichier de configuration de traçage doit être fourni à kube-apiserver avec --tracing-config-file=<<chemin vers le fichier de configuration>. Vous trouverez ci-dessous un exemple de configuration qui enregistre les durées pour la dix-millième requête et utilise le point de terminaison OpenTelemetry par défaut.

apiVersion: apiserver.config.k8s.io/v1beta1
kind: TracingConfiguration
# 默认值
#endpoint: localhost:4317
samplingRatePerMillion: 100

Pour plus d'informations sur la structure TracingConfiguration, consultez API de configuration du serveur d'API (v1beta1).

2.3 suivi des kubelets

État de la fonctionnalité : Kubernetes v1.27 [bêta]

L'interface kubelet CRI et le serveur HTTP implémentant l'authentification sont instrumentés pour générer des traçages. Comme le serveur d'API, les points de terminaison et les taux d'échantillonnage sont configurables. La propagation du contexte de trace est également configurable. La décision d'échantillonnage de l'intervalle parent est toujours prioritaire. Le taux d'échantillonnage de configuration de trace fourni par l'utilisateur sera appliqué aux étendues sans parent. Si activé sans point de terminaison configuré, l'adresse par défaut du récepteur OpenTelemetry Collector "localhost:4317" sera utilisée.

2.4 Activer le traçage dans kubelet

Pour activer le traçage, une configuration de traçage doit être appliquée. Voici un exemple d'extrait de code pour une configuration kubelet, enregistrant une période demandée toutes les 10 000 requêtes et utilisant le point de terminaison OpenTelemetry par défaut :

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  KubeletTracing: true
tracing:
  # 默认值
  #endpoint: localhost:4317
  samplingRatePerMillion: 100

Si samplingRatePerMillion est défini sur un million (1000000), toutes les étendues seront envoyées à l'exportateur.

Le kubelet de Kubernetes v1.27 collecte les étendues de la récupération de place, des routines de synchronisation des pods et de chaque méthode gRPC. Les runtimes de conteneur associés tels que CRI-O et containerd peuvent lier des liens aux étendues qu'ils exportent pour fournir plus de contexte.

Notez que l'exportation de plages a toujours une légère surcharge de performances sur le réseau et le processeur, en fonction de la configuration globale du système. Si des problèmes de performances similaires se produisent dans un cluster avec le traçage activé, le problème peut être atténué en réduisant le taux d'échantillonnage par million ou en désactivant entièrement le traçage en supprimant cette configuration.

3. Stabilité

L'outil de suivi est toujours en cours de développement actif et il changera à bien des égards à l'avenir. Ces modifications incluent : les noms d'étendue, les propriétés jointes, les points de terminaison de détection, etc. De telles fonctionnalités ne garantissent pas la rétrocompatibilité avec les outils de suivi jusqu'à ce qu'ils atteignent une version stable.

Deux, agence

Les utilisateurs peuvent rencontrer plusieurs proxys différents (proxy) lors du processus d'utilisation de Kubernetes :

1. Proxy kubectl：
2. S'exécute sur le bureau de l'utilisateur ou dans un module
3. Proxy de l'adresse de la machine locale à l'apiserver Kubernetes
4. Client vers proxy utilisant le protocole HTTP
5. Proxy vers apiserver en utilisant le protocole HTTPS
6. apiserver orienté
7. Ajouter des informations d'en-tête d'authentification

1. Proxy serveur API：
2. C'est une "forteresse" construite à l'intérieur de l'apiserver
3. Connectez les utilisateurs en dehors du cluster aux adresses IP du cluster qui sont autrement inaccessibles
4. S'exécute dans le processus apiserver
5. Le client de l'agent utilise le protocole HTTPS (si l'apiserver est configuré pour utiliser le protocole HTTP, le protocole HTTP est utilisé)
6. Sélectionné par les informations disponibles, le proxy vers la destination peut utiliser le protocole HTTP ou HTTPS
7. Peut être utilisé pour accéder au nœud, au pod ou au service
8. Lorsqu'il est utilisé pour accéder au Service, l'équilibrage de charge sera effectué

1. être mandataire：
2. exécuter sur chaque nœud
3. Proxy UDP, TCP et SCTP
4. Ne prend pas en charge HTTP
5. Fournit des capacités d'équilibrage de charge
6. Utilisé uniquement pour accéder au service

1. Proxy/équilibreur de charge avant apiserver :
2. Différentes formes d'existence et d'implémentation dans différents clusters (comme nginx)
3. se situe entre tous les clients et un ou plusieurs serveurs d'API
4. Agit comme un équilibreur de charge lorsqu'il y a plusieurs serveurs d'API

1. Équilibreur de charge cloud pour les services externes :
2. Fourni par certains fournisseurs de cloud (par exemple AWS ELB, Google Cloud Load Balancer)
3. Créé automatiquement lorsque le type de service Kubernetes est LoadBalancer
4. Ne prend généralement en charge que le protocole UDP/TCP
5. La prise en charge de SCTP dépend de la mise en œuvre de l'équilibreur de charge du fournisseur de cloud
6. Différents fournisseurs de cloud implémentent différents équilibreurs de charge cloud

Les utilisateurs de Kubernetes n'ont généralement besoin de se soucier que des deux premiers types de proxys, et les administrateurs de cluster doivent généralement s'assurer que les derniers types de proxys sont correctement définis.