Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Installez l' CloudWatch agent avec le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm
Vous pouvez utiliser le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Amazon CloudWatch Observability Helm pour installer l' CloudWatch agent et l'agent Fluent-bit sur un cluster Amazon EKS. Vous pouvez également utiliser le graphique Helm pour installer l' CloudWatch agent et l'agent Fluent-bit sur un cluster Kubernetes qui n'est pas hébergé sur Amazon EKS.
L'utilisation de l'une ou l'autre méthode sur un cluster Amazon EKS permet à Container Insights de bénéficier d'une observabilité améliorée pour Amazon EKS et CloudWatch d'Application Signals par défaut. Les deux fonctionnalités vous aident à collecter des métriques d'infrastructure, des données de télémétrie sur les performances des applications et des journaux de conteneurs à partir du cluster.
Grâce à Container Insights avec observabilité améliorée pour Amazon EKS, les métriques de Container Insights sont facturées par observation au lieu d'être facturées par métrique stockée ou par journal ingéré. Pour Application Signals, la facturation est basée sur les demandes entrantes adressées à vos applications, les demandes sortantes provenant de vos applications et sur chaque objectif de niveau de service (SLO) configuré. Chaque requête entrante reçue génère un signal d’application, et chaque requête sortante effectuée génère un signal d’application. Chaque SLO crée deux signaux d’application par période de mesure. Pour plus d'informations sur CloudWatch les tarifs, consultez Amazon CloudWatch Pricing
Les deux méthodes activent Container Insights sur les nœuds de travail Linux et Windows du cluster Amazon EKS. Pour activer Container Insights sous Windows, vous devez utiliser la version 1.5.0 ou ultérieure du module complémentaire Amazon EKS ou le graphique Helm. Actuellement, Application Signals n'est pas pris en charge sous Windows dans les clusters Amazon EKS.
Le module complémentaire Amazon CloudWatch Observability EKS est pris en charge sur les clusters Amazon EKS exécutés avec Kubernetes version 1.23 ou ultérieure.
Lorsque vous installez le module complémentaire ou le graphique Helm, vous devez également accorder des autorisations IAM pour permettre à l' CloudWatch agent d'envoyer des métriques, des journaux et des traces à CloudWatch. Il existe deux façons de procéder :
Attachez une politique au rôle IAM de vos composants master. Cette option accorde des autorisations aux nœuds de travail auxquels envoyer des données télémétriques. CloudWatch
Utilisez un rôle IAM pour les comptes de service des pods d'agent et attachez la politique à ce rôle. Cela ne fonctionne que pour les clusters Amazon EKS. Cette option donne CloudWatch accès uniquement aux modules d'agent appropriés.
Rubriques
Option 1 : installation à l'aide d'EKS Pod Identity
Si vous utilisez la version 3.1.0 ou ultérieure du module complémentaire, vous pouvez utiliser EKS Pod Identity pour accorder les autorisations requises au module complémentaire. EKS Pod Identity est l'option recommandée et offre des avantages tels que le moindre privilège, la rotation des informations d'identification et l'auditabilité. En outre, l'utilisation d'EKS Pod Identity vous permet d'installer le module complémentaire EKS dans le cadre de la création du cluster elle-même.
Pour utiliser cette méthode, suivez d'abord les étapes d'association EKS Pod Identity pour créer le rôle IAM et configurer l'agent EKS Pod Identity.
Installez ensuite le module complémentaire Amazon CloudWatch Observability EKS. Pour installer le module complémentaire, vous pouvez utiliser la AWS CLI console Amazon EKS ou Terraform. AWS CloudFormation
Option 2 : Installation avec des autorisations IAM sur les nœuds de travail
Pour utiliser cette méthode, associez d'abord la politique CloudWatchAgentServerPolicyIAM à vos nœuds de travail en saisissant la commande suivante. Dans cette commande, remplacez my-worker-node-role
par le rôle IAM utilisé par vos nœuds de travail Kubernetes.
aws iam attach-role-policy \ --role-name
my-worker-node-role
\ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
Installez ensuite le module complémentaire Amazon CloudWatch Observability EKS. Pour installer le module complémentaire, vous pouvez utiliser la AWS CLI console ou Terraform. AWS CloudFormation
Option 3 : Installation à l'aide du rôle de compte de service IAM (s'applique uniquement à l'utilisation du module complémentaire)
Cette méthode n'est valide que si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS. Avant d'utiliser cette méthode, vérifiez que les conditions préalables suivantes sont respectées :
-
Vous disposez d'un cluster Amazon EKS fonctionnel avec des nœuds rattachés à l'une des Régions AWS prenant en charge Container Insights. Pour obtenir la liste des régions prises en charge, consultez Container Insights.
-
kubectl
est installé et configuré pour le cluster. Pour plus d'informations, consultez Installation dekubectl
dans le Guide de l'utilisateur Amazon EKS. -
eksctl
est installé. Pour plus d'informations, veuillez consulter Installation ou mise à jour deeksctl
dans le Guide de l'utilisateur Amazon EKS.
Considérations relatives aux nœuds hybrides Amazon EKS
Les métriques au niveau des nœuds ne sont pas disponibles pour les nœuds hybrides car elles Container Insights dépendent de la disponibilité du service de métadonnées d'EC2 instance (IMDS) pour les métriques au niveau des nœuds. Des métriques au niveau du clusterPod, de la charge de travail et du conteneur sont disponibles pour les nœuds hybrides.
Après avoir installé le module complémentaire en suivant les étapes décrites dans les sections précédentes, vous devez mettre à jour le manifeste du module complémentaire afin que l'agent puisse s'exécuter correctement sur les nœuds hybrides. Modifiez la amazoncloudwatchagents
ressource du cluster pour ajouter la variable d'RUN_WITH_IRSA
environnement correspondant à ce qui suit.
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
apiVersion: v1 items: - apiVersion: cloudwatch.aws.amazon.com/v1alpha1 kind: AmazonCloudWatchAgent metadata: ... name: cloudwatch-agent namespace: amazon-cloudwatch ... spec: ... env: - name: RUN_WITH_IRSA # <-- Add this value: "True" # <-- Add this - name: K8S_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ...
(Facultatif) Configuration supplémentaire
Rubriques
Désactiver la collecte des journaux de conteneurs
Par défaut, le module complémentaire utilise Fluent Bit pour collecter les journaux des conteneurs à partir de tous les pods, puis envoie les CloudWatch journaux à Logs. Pour plus d'informations sur les journaux collectés, veuillez consulter Configuration de Fluent Bit.
Note
Ni le module complémentaire ni le graphique Helm ne gèrent les ressources Fluentd ou Fluent Bit existantes dans un cluster. Vous pouvez supprimer les ressources Fluentd ou Fluent Bit existantes avant d'installer le module complémentaire ou le graphique Helm. Sinon, pour conserver votre configuration existante et éviter que le module complémentaire ou le graphique Helm n'installent également Fluent Bit, vous pouvez le désactiver en suivant les instructions de cette section.
Pour refuser la collecte des journaux de conteneurs si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS, passez l'option suivante lorsque vous créez ou mettez à jour le module complémentaire :
--configuration-values '{ "containerLogs": { "enabled": false } }'
Pour refuser la collecte des journaux de conteneurs si vous utilisez le graphique Helm, passez l'option suivante lorsque vous créez ou mettez à jour le module complémentaire :
--set containerLogs.enabled=false
Utiliser une configuration Fluent Bit personnalisée
À partir de la version 1.7.0 du module complémentaire Amazon CloudWatch Observability EKS, vous pouvez modifier la configuration de Fluent Bit lorsque vous créez ou mettez à jour le module complémentaire ou le graphique Helm. Vous fournissez la configuration Fluent Bit personnalisée dans la section de niveau containerLogs
racine de la configuration avancée du module complémentaire ou les remplacements de valeurs dans le graphique de Helm. Dans cette section, vous fournissez la configuration personnalisée de Fluent Bit dans la config
section (pour Linux) ou dans configWindows
la section (pour Windows). config
Il est ensuite décomposé dans les sous-sections suivantes :
service
— Cette section représente laSERVICE
configuration permettant de définir le comportement global du moteur Fluent Bit.customParsers
— Cette section représente tous les éléments globauxPARSER
que vous souhaitez inclure et qui sont capables de prendre des entrées de journal non structurées et de leur donner une structure afin de faciliter le traitement et le filtrage ultérieur.extraFiles
— Cette section peut être utilisée pour fournir desconf
fichiers Fluent Bit supplémentaires à inclure. Par défaut, les 3conf
fichiers suivants sont inclus :application-log.conf
— Unconf
fichier permettant d'envoyer les journaux d'applications de votre cluster au groupe de CloudWatch journaux/aws/containerinsights/
dans Logs.my-cluster-name
/applicationdataplane-log.conf
— Unconf
fichier permettant d'envoyer les journaux correspondant aux composants du plan de données de votre cluster, notamment les journaux CRI, les journaux kubelet, les journaux kube-proxy et les journaux Amazon VPC CNI, au groupe de journaux dans Logs./aws/containerinsights/
CloudWatchmy-cluster-name
/dataplanehost-log.conf
— Aconf
pour envoyer des journaux depuis/var/log/dmesg
/var/log/messages
, et/var/log/secure
sous Linux, et Systemwinlogs
sous Windows,/aws/containerinsights/
au groupe de journaux CloudWatch.my-cluster-name
/host
Note
Fournissez la configuration complète pour chacune de ces sections individuelles, même si vous ne modifiez qu'un seul champ dans une sous-section. Nous vous recommandons d'utiliser la configuration par défaut fournie ci-dessous comme référence, puis de la modifier en conséquence afin de ne pas désactiver les fonctionnalités activées par défaut. Vous pouvez utiliser la configuration YAML suivante lorsque vous modifiez la configuration avancée du module complémentaire Amazon EKS ou lorsque vous fournissez des remplacements de valeur pour le graphique Helm.
Pour trouver la config
section correspondant à votre cluster, consultez aws-observability/helm-charts/charts/amazon-cloudwatch-observability/values.yaml
vers pour trouver la config
section (pour Linux) et configWindows
la section (pour Windows) dans la fluentBit
section ci-dessouscontainerLogs
.
À titre d'exemple, la configuration Fluent Bit par défaut pour la version 1.7.0 se trouve ici
Nous vous recommandons de fournir le config
format YAML lorsque vous le fournissez à l'aide de la configuration avancée du module complémentaire Amazon EKS ou lorsque vous le fournissez en tant que remplacement de valeur pour votre installation Helm. Assurez-vous que le YAML est conforme à la structure suivante.
containerLogs: fluentBit: config: service: | ... customParsers: | ... extraFiles: application-log.conf: | ... dataplane-log.conf: | ... host-log.conf: | ...
L'exemple suivant config
modifie le paramètre global de l'intervalle de rinçage à 45 secondes. Même si la seule modification concerne le Flush
champ, vous devez tout de même fournir la SERVICE
définition complète de la sous-section du service. Comme cet exemple n'a pas spécifié de remplacements pour les autres sous-sections, les valeurs par défaut sont utilisées pour celles-ci.
containerLogs: fluentBit: config: service: | [SERVICE] Flush 45 Grace 30 Log_Level error Daemon off Parsers_File parsers.conf storage.path /var/fluent-bit/state/flb-storage/ storage.sync normal storage.checksum off storage.backlog.mem_limit 5M
L'exemple de configuration suivant inclut un conf
fichier Fluent bit supplémentaire. Dans cet exemple, nous ajoutons un my-service.conf
sous-titre extraFiles
personnalisé qui sera inclus en plus des trois par défautextraFiles
.
containerLogs: fluentBit: config: extraFiles: my-service.conf: | [INPUT] Name tail Tag myservice.* Path /var/log/containers/*myservice*.log DB /var/fluent-bit/state/flb_myservice.db Mem_Buf_Limit 5MB Skip_Long_Lines On Ignore_Older 1d Refresh_Interval 10 [OUTPUT] Name cloudwatch_logs Match myservice.* region ${AWS_REGION} log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice log_stream_prefix ${HOST_NAME}- auto_create_group true
L'exemple suivant supprime entièrement un conf
fichier existant deextraFiles
. Cela les exclut application-log.conf
complètement en le remplaçant par une chaîne vide. Le simple fait d'omettre application-log.conf
de extraFiles
impliquerait plutôt d'utiliser la valeur par défaut, ce que nous n'essayons pas de réaliser dans cet exemple. Il en va de même pour la suppression de tout conf
fichier personnalisé que vous auriez pu ajouter précédemmentextraFiles
.
containerLogs: fluentBit: config: extraFiles: application-log.conf: ""
Gérez les tolérances de Kubernetes pour les charges de travail des pods installés
À partir de la version 1.7.0 du module complémentaire Amazon CloudWatch Observability EKS, le module complémentaire et le graphique Helm définissent par défaut des tolérances Kubernetes afin de tolérer toutes les altérations des charges de travail du pod installées par le module complémentaire ou le graphique Helm. Cela garantit que les daemonsets tels que l' CloudWatch agent et Fluent Bit peuvent planifier des pods sur tous les nœuds de votre cluster par défaut. Pour plus d'informations sur les tolérances et les altérations, consultez Taints and Tolerations
Les tolérances par défaut définies par le module complémentaire ou le graphique de Helm sont les suivantes :
tolerations: - operator: Exists
Vous pouvez annuler les tolérances par défaut en définissant le tolerations
champ au niveau de la racine lorsque vous utilisez la configuration avancée du module complémentaire ou lorsque vous installez ou mettez à niveau le graphique de Helm avec des remplacements de valeurs. Voici un exemple :
tolerations: - key: "key1" operator: "Exists" effect: "NoSchedule"
Pour omettre complètement les tolérances, vous pouvez utiliser une configuration qui ressemble à ce qui suit :
tolerations: []
Toute modification des tolérances s'applique à toutes les charges de travail du module installées par le module complémentaire ou le graphique Helm.
Désactiver la collecte accélérée de métriques de calcul
Par défaut, Container Insights, doté d'une observabilité améliorée, collecte des métriques pour la surveillance accélérée du calcul, notamment les métriques du GPU NVIDIA, les métriques AWS Neuron pour AWS Trainium et AWS Inferentia, et les métriques AWS Elastic Fabric Adapter (EFA).
Les métriques du GPU NVIDIA issues des charges de travail Amazon EKS sont collectées par défaut en commençant par la version v1.3.0-eksbuild.1
du module complémentaire EKS ou le graphique Helm et la version 1.300034.0
de l' CloudWatch agent. Pour obtenir la liste des mesures collectées et des conditions requises, consultezMétriques du GPU NVIDIA.
AWS Les métriques neuronales pour les accélérateurs AWS Trainium et AWS Inferentia sont collectées par défaut à partir de la version v1.5.0-eksbuild.1
du module complémentaire EKS ou du graphique Helm et de la version 1.300036.0
de l'agent. CloudWatch Pour obtenir la liste des mesures collectées et des conditions requises, consultezAWS Métriques neuronales pour AWS Trainium et Inferentia AWS.
AWS Les métriques Elastic Fabric Adapter (EFA) issues des nœuds Linux des clusters Amazon EKS sont collectées par défaut en commençant par la v1.5.2-eksbuild.1
version du module complémentaire EKS ou le graphique Helm et la 1.300037.0
version de CloudWatch l'agent. Pour obtenir la liste des mesures collectées et des conditions requises, consultezAWS Métriques de l'Elastic Fabric Adapter (EFA) .
Vous pouvez choisir de ne pas collecter ces métriques en définissant le accelerated_compute_metrics
champ du fichier de configuration de l' CloudWatch agent surfalse
. Ce champ se trouve dans la kubernetes
section de la metrics_collected
section du fichier CloudWatch de configuration. Voici un exemple de configuration de désinscription. Pour plus d'informations sur l'utilisation des configurations d' CloudWatch agent personnalisées, consultez la section suivante,Utiliser une configuration d' CloudWatch agent personnalisée.
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true, "accelerated_compute_metrics": false } } } }
Utiliser une configuration d' CloudWatch agent personnalisée
Pour collecter d'autres métriques, journaux ou traces à l'aide de l' CloudWatch agent, vous pouvez définir une configuration personnalisée tout en gardant Container Insights et CloudWatch Application Signals activés. Pour ce faire, intégrez le fichier de configuration de l' CloudWatch agent dans la clé de configuration située sous la clé d'agent de la configuration avancée que vous pouvez utiliser lors de la création ou de la mise à jour du module complémentaire EKS ou du graphique Helm. Ce qui suit représente la configuration par défaut de l’agent lorsque vous ne fournissez aucune configuration supplémentaire.
Important
Toute configuration personnalisée que vous fournissez à l’aide de paramètres de configuration supplémentaires remplace la configuration par défaut utilisée par l’agent. Veillez à ne pas désactiver involontairement les fonctionnalités activées par défaut, telles que Container Insights avec une observabilité améliorée et les signaux d' CloudWatch application. Dans le cas où vous devez fournir une configuration d’agent personnalisée, nous vous recommandons d’utiliser la configuration par défaut suivante comme référence, puis de la modifier en conséquence.
Pour utiliser le module complémentaire Amazon CloudWatch observability EKS
--configuration-values '{ "agent": { "config": { "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } } }'
-
Pour utiliser le graphique Helm
--set agent.config='{ "logs": { "metrics_collected": { "application_signals": {}, "kubernetes": { "enhanced_container_insights": true } } }, "traces": { "traces_collected": { "application_signals": {} } } }'
L'exemple suivant montre la configuration par défaut de l' CloudWatch agent sous Windows. L' CloudWatch agent sous Windows ne prend pas en charge la configuration personnalisée.
{ "logs": { "metrics_collected": { "kubernetes": { "enhanced_container_insights": true }, } } }
Gérer les certificats TLS du webhook d’admission
Le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm exploitent les webhooks d'admissionInstrumentation
personnalisées (CR), AmazonCloudWatchAgent
et éventuellement les requêtes de pod Kubernetes sur le cluster si Application Signals est activé. CloudWatch Dans Kubernetes, les webhooks nécessitent que le serveur d’API soit configuré pour faire confiance à un certificat TLS afin de garantir une communication sécurisée.
Par défaut, le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm génèrent automatiquement une autorité de certification auto-signée et un certificat TLS signé par cette autorité de certification afin de sécuriser la communication entre le serveur d'API et le serveur Webhook. Ce certificat généré automatiquement a une durée de validité par défaut de 10 ans et n’est pas renouvelé automatiquement à l’expiration. En outre, le bundle CA et le certificat sont régénérés chaque fois que le module complémentaire ou le graphique Helm est mis à niveau ou réinstallé, ce qui réinitialise l'expiration. Si vous souhaitez modifier la durée de validité par défaut du certificat généré automatiquement, vous pouvez utiliser les configurations supplémentaires suivantes lors de la création ou de la mise à jour du module complémentaire. expiry-in-days
Remplacez-le par la durée de péremption souhaitée en jours.
Utilisez-le pour le module complémentaire Amazon CloudWatch Observability EKS
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays":
expiry-in-days
} } }'Utilisez-le pour le graphique Helm
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
Pour une solution d’autorité de certification plus sécurisée et riche en fonctionnalités, le module complémentaire prend en charge cert-manager
Nous vous recommandons de consulter les bonnes pratiques en matière de gestion des certificats TLS sur vos clusters et d’opter pour cert-manager pour les environnements de production. Notez que si vous acceptez d'activer cert-manager pour gérer les certificats TLS du webhook d'admission, vous devez préinstaller cert-manager sur votre cluster Amazon EKS avant d'installer le module complémentaire Amazon Observability EKS ou le graphique Helm CloudWatch . Pour plus d'informations sur les options d'installation disponibles, consultez la documentation de cert-manager
Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
Si vous utilisez le graphique Helm
--set admissionWebhooks.certManager.enabled=true
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
La configuration avancée décrite dans cette section utilisera par défaut un SelfSigned
Collectez le volume Amazon EBS IDs
Si vous souhaitez collecter le volume Amazon EBS IDs dans les journaux de performance, vous devez ajouter une autre politique au rôle IAM qui est attaché aux nœuds de travail ou au compte de service. Ajoutez les éléments suivants en tant que politique en ligne. Pour de plus amples informations, veuillez consulter Ajout et suppression d'autorisations basées sur l'identité IAM.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeVolumes" ], "Resource": "*", "Effect": "Allow" } ] }
Collectez les métriques des extensions de gestion Java (JMX)
L' CloudWatch agent prend en charge la collecte de métriques Java Management Extensions (JMX) sur Amazon EKS. Cela vous permet de collecter des métriques supplémentaires à partir d'applications Java exécutées sur des clusters Amazon EKS, ce qui vous permet de mieux comprendre les performances, l'utilisation de la mémoire, le trafic et d'autres mesures critiques. Pour de plus amples informations, veuillez consulter Collectez les métriques des extensions de gestion Java (JMX).
Activer les métriques Kueue
À partir de la version v2.4.0-eksbuild.1
du module complémentaire CloudWatch Observability EKS, Container Insights for Amazon EKS prend en charge la collecte de métriques Kueue à partir de clusters Amazon EKS. Pour plus d’informations sur ces métriques, consultez Métriques de Kueue .
Si vous utilisez le module complémentaire Amazon SageMaker AI Hyperpod Task Governance EKS, vous pouvez ignorer les étapes de la section Prérequis et simplement suivre les étapes décrites. Activer l'indicateur de configuration
Prérequis
Avant d'installer Kueue dans votre cluster Amazon EKS, effectuez les mises à jour suivantes dans le fichier manifeste :
Activez les métriques de ressources de file d'attente de cluster facultatives pour Kueue. Pour ce faire, modifiez le texte en ligne
controller_manager_config.yaml
dans lekueue-system
ConfigMap. Dans lametrics
section, ajoutez ou décommentez la ligneenableClusterQueueResources: true
.apiVersion: v1 data: controller_manager_config.yaml: | apiVersion: config.kueue.x-k8s.io/v1beta1 kind: Configuration health: healthProbeBindAddress: :8081 metrics: bindAddress: :8080 enableClusterQueueResources: true
<-- ADD/UNCOMMENT THIS LINE
Par défaut, tous les
k8s
services sont disponibles à l'échelle du cluster. Kueue crée un servicekueue-controller-manager-metrics-service
pour exposer les métriques. Pour éviter les observations dupliquées pour les métriques, modifiez ce service pour autoriser l'accès uniquement au service de métriques depuis le même nœud. Pour ce faire, ajoutez la ligneinternalTrafficPolicy: Local
à lakueue-controller-manager-metrics-service
définition.apiVersion: v1 kind: Service metadata: labels: ... name: kueue-controller-manager-metrics-service namespace: kueue-system spec: ports: - name: https port: 8443 protocol: TCP targetPort: https internalTrafficPolicy: Local
<-- ADD THIS LINE
selector: control-plane: controller-managerEnfin, le
kueue-controller-manager
pod crée unkube-rbac-proxy
contenant. Ce conteneur présente actuellement un niveau élevé de verbosité de journalisation, ce qui fait que le jeton porteur du cluster est enregistré par ce conteneur lorsque le scraper de métriques accède au.kueue-controller-manager-metrics-service
Nous vous recommandons de réduire cette verbosité de journalisation. La valeur par défaut du manifeste distribué par Kueue est 10, nous vous recommandons de la remplacer par 0.apiVersion: apps/v1 kind: Deployment metadata: labels: ... name: kueue-controller-manager namespace: kueue-system spec: ... template: ... spec: containers: ... - args: - --secure-listen-address=0.0.0.0:8443 - --upstream=http://127.0.0.1:8080/ - --logtostderr=true - --v=0
<-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0 name: kube-rbac-proxy ...
Activer l'indicateur de configuration
Pour activer les métriques Kueue, vous devez activer la configuration supplémentaire kueue_container_insights
dans le module complémentaire. Vous pouvez le faire soit en utilisant le module complémentaire EKS Observability AWS CLI pour configurer, soit en utilisant la console Amazon EKS.
Après avoir correctement installé le module complémentaire EKS Observability à l'aide de l'une des méthodes suivantes, vous pouvez consulter les métriques de votre cluster Amazon EKS sous l'onglet Tableau de bord de la HyperPod console.
Ajout de fichiers de configuration du OpenTelemetry collecteur
L' CloudWatch agent prend en charge les fichiers de configuration de OpenTelemetry collecteurs supplémentaires en plus de ses propres fichiers de configuration. Cette fonctionnalité vous permet d'utiliser des fonctionnalités d' CloudWatch agent telles que CloudWatch Application Signals ou Container Insights dans le cadre de la configuration de l' CloudWatch agent et d'intégrer votre configuration de OpenTelemetry collecteur existante avec un seul agent.
Pour éviter les conflits de fusion avec les pipelines créés automatiquement par CloudWatch l'agent, nous vous recommandons d'ajouter un suffixe personnalisé à chacun des composants et pipelines de la configuration de votre OpenTelemetry collecteur. Cela permettra d'éviter les collisions et les conflits de fusion.
Si vous utilisez le module complémentaire Amazon CloudWatch Observability EKS
--configuration-values file://values.yaml
or
--configuration-values ' agent: otelConfig: receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
Si vous utilisez le graphique Helm
--set agent.otelConfig=' receivers: otlp/custom-suffix: protocols: http: {} exporters: awscloudwatchlogs/custom-suffix: log_group_name: "test-group" log_stream_name: "test-stream" service: pipelines: logs/custom-suffix: receivers: [otlp/custom-suffix] exporters: [awscloudwatchlogs/custom-suffix] '
Configuration des signaux d'application pour votre cluster Amazon EKS
Application Signals est activé par défaut lors de l'installation du module complémentaire CloudWatch Observability EKS ou du graphique Helm. Vous pouvez personnaliser davantage des paramètres spécifiques à l'aide de la configuration avancée du module complémentaire Amazon EKS ou en remplaçant les valeurs par le graphique de Helm.
Surveillance automatique des signaux d'application
La version 4.0.0 du module complémentaire CloudWatch Observability Amazon EKS et du graphique Helm introduit de nouvelles fonctionnalités. Vous pouvez désormais activer automatiquement les signaux d'application pour toutes les charges de travail de service ou pour des charges de travail spécifiques de votre cluster EKS via la configuration du moniteur automatique. Les autoMonitor
paramètres suivants peuvent être spécifiés dans la applicationSignals
section située sous la manager
section de la configuration avancée.
monitorAllServices— Un indicateur booléen permettant d'activer (vrai) ou de désactiver (faux) la surveillance de toutes les charges de travail des services par Auto Monitor. La valeur par défaut est false. L'activation de cet indicateur garantit que toutes les charges de travail Kubernetes (déploiements DaemonSets, et StatefulSets) du cluster mappées à un service Kubernetes seront autorisées à activer automatiquement les signaux d'application lorsqu'ils seront affichés pour la première fois (ou lors du redémarrage pour les charges de travail existantes). Le système exclut les charges de travail dans les
amazon-cloudwatch
espaces de nomskube-system
et par défaut.languages — Une liste de chaînes spécifiant l'ensemble de langues avec lesquelles Application Signals essaiera d'instrumenter automatiquement vos services, lorsqu'il
monitorAllServices
est activé. Par défaut, toutes les langues prises en charge sont prises en charge.RestartPods — Un indicateur booléen contrôle si les charges de travail redémarrent après les modifications de configuration. La valeur par défaut est false. L'activation de cet indicateur permet de
true
contrôler si les charges de travail Kubernetes dans le cadre de la surveillance automatique redémarrent automatiquement lors de l'enregistrement des modifications de configuration. Tous les paramètres de vos charges de travail Kubernetes qui influencent le redémarrage des pods seront pris enupdateStrategy
compte. Tenez compte du fait que le redémarrage peut entraîner une interruption du service.CustomSelector : paramètres permettant de sélectionner des espaces de noms ou des charges de travail Kubernetes spécifiques pour Auto Monitor.
java — Spécifie les charges de travail à instrumenter automatiquement avec Java
python — Spécifie les charges de travail à instrumenter automatiquement avec Python
nodejs — Spécifie les charges de travail à instrumenter automatiquement avec Node.js
dotnet — Spécifie les charges de travail à instrumenter automatiquement avec .NET
Pour chacune des langues ci-dessus, les champs suivants peuvent être configurés.
namespaces — Liste de chaînes spécifiant les espaces de noms à sélectionner. Par défaut, il s'agit d'une liste vide, c'est-à-dire []
déploiements : liste de chaînes spécifiant les déploiements à sélectionner. Spécifiez dans le
namespace/deployment
format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []daemonsets — Liste de chaînes spécifiant les daemonsets à sélectionner. Spécifiez dans le
namespace/daemonset
format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []statefulsets — Liste de chaînes spécifiant les ensembles d'états à sélectionner. Spécifiez dans le
namespace/statefulset
format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []
exclude — Paramètres permettant d'exclure des espaces de noms ou des charges de travail Kubernetes spécifiques du moniteur automatique. L'exclusion d'une charge de travail a priorité lorsque la même charge de travail est également comprise dans le champ d'application de
monitorAllServices
oucustomSelector
.java — Spécifie les charges de travail à exclure de l'instrumentation automatique avec Java
python — Spécifie les charges de travail à exclure de l'instrumentation automatique avec Python
nodejs — Spécifie les charges de travail à exclure de l'instrumentation automatique avec Node.js
dotnet — Spécifie les charges de travail à exclure de l'instrumentation automatique avec .NET
Pour chacune des langues ci-dessus, les champs suivants peuvent être configurés.
namespaces — Liste de chaînes spécifiant les espaces de noms à exclure. Par défaut, il s'agit d'une liste vide, c'est-à-dire []
déploiements : liste de chaînes spécifiant les déploiements à exclure. Spécifiez dans le
namespace/deployment
format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []daemonsets — Liste de chaînes spécifiant les daemonsets à exclure. Spécifiez dans le
namespace/daemonset
format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []statefulsets — Liste de chaînes spécifiant les ensembles d'états à exclure. Spécifiez dans le
namespace/statefulset
format. Par défaut, il s'agit d'une liste vide, c'est-à-dire []
Voici un exemple de configuration qui active automatiquement les signaux d'application pour toutes les charges de travail de service existantes et nouvelles sur le cluster.
manager: applicationSignals: autoMonitor: monitorAllServices: true restartPods: true
Voici un exemple de configuration qui active automatiquement les signaux d'application pour toute nouvelle charge de travail de service créée et pour toute charge de travail de service existante qui est explicitement redémarrée sur le cluster.
manager: applicationSignals: autoMonitor: monitorAllServices: true
Voici un exemple de configuration qui active automatiquement les signaux d'application avec Java pour tous les pods existants et nouveaux correspondant à une charge de travail dans l'espace de pet-warehouse
noms.
manager: applicationSignals: autoMonitor: restartPods: true customSelector: java: namespaces: ["pet-warehouse"]
Voici un exemple de configuration qui active automatiquement les signaux d'application avec Python pour toutes les charges de travail de service existantes et nouvelles du cluster, à l'exception du pet-clinic
déploiement.
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["python"] restartPods: true exclude: python: deployments: ["pet-warehouse/pet-clinic"]
Voici un exemple de configuration qui active automatiquement les signaux d'application avec Java pour toutes les charges de travail de service du cluster, à l'exception de celles de l'python-apps
espace de noms, et qui active également les signaux d'application avec Python spécifiquement pour le sample-python-app
déploiement dans l'python-apps
espace de noms.
manager: applicationSignals: autoMonitor: monitorAllServices: true languages: ["java"] restartPods: true customSelector: python: deployments: ["python-apps/sample-python-app"] exclude: java: namespaces: ["python-apps"]
Résolution des problèmes liés au module complémentaire Amazon CloudWatch Observability EKS ou au graphique Helm
Utilisez les informations suivantes pour résoudre les problèmes liés au module complémentaire Amazon CloudWatch Observability EKS ou au graphique Helm
Rubriques
Mise à jour et suppression du module complémentaire Amazon CloudWatch Observability EKS ou du graphique Helm
Pour obtenir des instructions sur la mise à jour ou la suppression du module complémentaire Amazon CloudWatch Observability EKS, consultez la section Gestion des modules complémentaires Amazon EKS. Utilisez amazon-cloudwatch-observability
comme nom du module complémentaire.
Pour supprimer le graphique Helm d'un cluster, entrez la commande suivante.
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
Vérifiez la version de l' CloudWatch agent utilisée par le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm
Le module complémentaire Amazon CloudWatch Observability EKS et le graphique Helm installent une ressource personnalisée AmazonCloudWatchAgent
qui contrôle le comportement du daemonset de l' CloudWatchagent sur le cluster, y compris la version de l' CloudWatch agent utilisée. Vous pouvez obtenir la liste de toutes les ressources AmazonCloudWatchAgent
personnalisées installées sur votre cluster en saisissant la commande suivante :
kubectl get amazoncloudwatchagent -A
Dans le résultat de cette commande, vous devriez être en mesure de vérifier la version de l' CloudWatch agent. Vous pouvez également décrire la ressource amazoncloudwatchagent
ou l’un des pods cloudwatch-agent-*
exécutés sur votre cluster pour inspecter l’image utilisée.
Manipulation d'un ConfigurationConflict lors de la gestion du module complémentaire ou du graphique Helm
Lorsque vous installez ou mettez à jour le module complémentaire Amazon CloudWatch Observability EKS ou le graphique Helm, si vous remarquez une défaillance due à des ressources existantes, c'est probablement parce que vous avez déjà ClusterRoleBinding installé l' CloudWatch agent et ses composants associés tels que le ServiceAccount, le ClusterRole et le sur le cluster.
L'erreur affichée par le module complémentaire inclura : Conflicts found when trying to apply. Will not continue due to resolve conflicts mode
L'erreur affichée par le graphique Helm sera similaire àError: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.
.
Lorsque le module complémentaire ou le graphique Helm tente d'installer l' CloudWatch agent et ses composants associés, s'il détecte une modification du contenu, il échoue par défaut à l'installation ou à la mise à jour afin d'éviter de modifier l'état des ressources du cluster.
Si vous essayez d'intégrer le module complémentaire Amazon CloudWatch Observability EKS et que vous constatez cet échec, nous vous recommandons de supprimer une configuration d' CloudWatch agent existante que vous aviez précédemment installée sur le cluster, puis d'installer le module complémentaire EKS ou le graphique Helm. Veillez à sauvegarder toutes les personnalisations que vous avez éventuellement apportées à la configuration d'origine de l' CloudWatch agent, telle qu'une configuration d'agent personnalisée, et à les fournir au module complémentaire ou au tableau Helm lors de sa prochaine installation ou mise à jour. Si vous avez déjà installé l' CloudWatch agent pour l'intégration à Container Insights, consultez Supprimer l' CloudWatch agent et Fluent Bit for Container Insights pour plus d'informations.
Le module complémentaire prend également en charge une option de configuration de résolution des conflits capable de spécifier OVERWRITE
. Vous pouvez utiliser cette option pour procéder à l’installation ou à la mise à jour du module complémentaire en remplaçant les conflits sur le cluster. Si vous utilisez la console Amazon EKS, vous trouverez la Méthode de résolution des conflits lorsque vous choisissez les Paramètres de configuration facultatifs lorsque vous créez ou mettez à jour le module complémentaire. Si vous utilisez le AWS CLI, vous pouvez fournir le --resolve-conflicts OVERWRITE
à votre commande pour créer ou mettre à jour le module complémentaire.