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.
# Journalisation pour Amazon EKS
La journalisation Kubernetes peut être divisée en journalisation du plan de contrôle, journalisation des nœuds et journalisation des applications. Le [plan de contrôle Kubernetes](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) est un ensemble de composants qui gèrent les clusters Kubernetes et produisent des journaux utilisés à des fins d'audit et de diagnostic. Avec Amazon EKS, vous pouvez [activer les journaux pour les différents composants du plan de contrôle](https://docs.aws.amazon.com//eks/latest/userguide/control-plane-logs.html) et les envoyer à CloudWatch.
Kubernetes exécute également des composants système tels que `kubelet` et `kube-proxy` sur chaque nœud Kubernetes qui exécute vos pods. Ces composants rédigent des journaux au sein de chaque nœud et vous pouvez configurer CloudWatch Container Insights pour capturer ces journaux pour chaque nœud Amazon EKS.
Les conteneurs sont regroupés sous forme de [pods](https://kubernetes.io/docs/concepts/workloads/pods/) au sein d'un cluster Kubernetes et sont planifiés pour s'exécuter sur vos nœuds Kubernetes. La plupart des applications conteneurisées écrivent en sortie standard et en erreur standard, et le moteur de conteneur redirige la sortie vers un pilote de journalisation. Dans Kubernetes, les journaux des conteneurs se trouvent dans le `/var/log/pods` répertoire d'un nœud. Vous pouvez configurer CloudWatch Container Insights pour capturer ces journaux pour chacun de vos pods Amazon EKS.
## Journalisation de plan de contrôle d'Amazon EKS
Un cluster Amazon EKS consiste en un plan de contrôle à haute disponibilité à locataire unique pour votre cluster Kubernetes et les nœuds Amazon EKS qui exécutent vos conteneurs. Les nœuds du plan de contrôle s'exécutent dans un compte géré par AWS. Les nœuds du plan de contrôle du cluster Amazon EKS sont intégrés CloudWatch et vous pouvez activer la journalisation pour des composants spécifiques du plan de contrôle.
Des journaux sont fournis pour chaque instance de composant du plan de contrôle Kubernetes. AWS gère l'état de santé des nœuds de votre plan de contrôle et fournit un [accord de niveau de service (SLA) pour](https://aws.amazon.com//eks/sla/) le point de terminaison Kubernetes.
## Journalisation des applications et des nœuds Amazon EKS
Nous vous recommandons d'utiliser [CloudWatchContainer Insights](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs.html) pour capturer les journaux et les métriques pour Amazon EKS. Container Insights implémente des métriques au niveau du cluster, du nœud et du pod avec l' CloudWatch agent, et Fluent Bit ou Fluentd pour la capture des journaux. CloudWatch Container Insights fournit également des tableaux de bord automatiques avec des vues en couches de vos CloudWatch indicateurs capturés. Container Insights est déployé sous forme CloudWatch DaemonSet de Fluent Bit DaemonSet qui s'exécute sur chaque nœud Amazon EKS. Les nœuds Fargate ne sont pas pris en charge par Container Insights car ils sont gérés AWS par et ne sont pas pris en charge. DaemonSets La journalisation Fargate pour Amazon EKS est traitée séparément dans ce guide.
Le tableau suivant indique les CloudWatch groupes de journaux et les journaux capturés par la [configuration de capture de journaux Fluentd ou Fluent Bit par défaut](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html) pour Amazon EKS.
| | |
| --- |--- |
| /aws/containerinsights/Cluster\$1Name/application | Tous les fichiers journaux sont enregistrés/var/log/containers. Ce répertoire fournit des liens symboliques vers tous les journaux des conteneurs Kubernetes dans la structure du /var/log/pods répertoire. Cela capture les journaux du conteneur de votre application écrivant dans stdout oustderr. Il inclut également des journaux pour les conteneurs du système Kubernetes tels queaws-vpc-cni-init, etkube-proxy. coreDNS |
| /aws/containerinsights/Cluster\$1Name/host | Journaux provenant de /var/log/dmesg/var/log/secure, et/var/log/messages. |
| /aws/containerinsights/Cluster\$1Name/dataplane | Les journaux dans /var/log/journal pour kubelet.service, kubeproxy.service et docker.service. |
Si vous ne souhaitez pas utiliser Container Insights avec Fluent Bit ou Fluentd pour la journalisation, vous pouvez capturer les journaux des nœuds et des conteneurs avec l' CloudWatch agent installé sur les nœuds Amazon EKS. Les nœuds Amazon EKS sont des instances EC2, ce qui signifie que vous devez les inclure dans votre approche standard de journalisation au niveau du système pour Amazon EC2. Si vous installez l' CloudWatch agent à l'aide de Distributor et State Manager, les nœuds Amazon EKS sont également inclus dans l'installation, la configuration et la mise à jour de l' CloudWatch agent.
Le tableau suivant indique les journaux spécifiques à Kubernetes que vous devez capturer si vous n'utilisez pas Container Insights avec Fluent Bit ou Fluentd pour la journalisation.
| | |
| --- |--- |
| /var/log/containers | Ce répertoire fournit des liens symboliques vers tous les journaux des conteneurs Kubernetes dans la structure du /var/log/pods répertoire. Cela capture efficacement les journaux du conteneur de votre application qui écrivent dans stdout oustderr. Cela inclut les journaux pour les conteneurs du système Kubernetes tels queaws-vpc-cni-init, etkube-proxy. coreDNS Important : cela n'est pas obligatoire si vous utilisez Container Insights. |
| var/log/aws-routed-eni/ipamd.log/var/log/aws-routed-eni/plugin.log | Les journaux du démon L-IPAM se trouvent ici |
Vous devez vous assurer que les nœuds Amazon EKS installent et configurent l' CloudWatch agent pour envoyer les journaux et mesures appropriés au niveau du système. Cependant, l'AMI optimisée pour Amazon EKS n'inclut pas l'agent Systems Manager. À l'aide de [modèles de lancement](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html), vous pouvez automatiser l'installation de l'agent Systems Manager et une CloudWatch configuration par défaut qui capture les journaux importants spécifiques à Amazon EKS à l'aide d'un script de démarrage implémenté via la section des données utilisateur. Les nœuds Amazon EKS sont déployés à l'aide d'un groupe Auto Scaling en tant que [groupe de nœuds gérés](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-groups.html) ou en tant que [nœuds autogérés](https://docs.aws.amazon.com//eks/latest/userguide/worker.html).
Avec les groupes de nœuds gérés, vous fournissez un [modèle de lancement](https://docs.aws.amazon.com//eks/latest/userguide/launch-templates.html) qui inclut la section des données utilisateur pour automatiser l'installation et la CloudWatch configuration de l'agent Systems Manager. Vous pouvez personnaliser et utiliser le modèle [amazon\$1eks\$1managed\$1node\$1group\$1launch\$1config.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon_eks_managed_node_group_launch_config.yaml) pour créer un CloudFormation modèle de lancement qui installe l'agent Systems Manager, l'agent, et ajoute également une configuration de journalisation spécifique à Amazon EKS dans le répertoire de configuration. CloudWatch CloudWatch Ce modèle peut être utilisé pour mettre à jour votre modèle de lancement de groupes de nœuds gérés Amazon EKS avec une approche infrastructure-as-code (iAc). Chaque mise à jour du CloudFormation modèle fournit une nouvelle version du modèle de lancement. Vous pouvez ensuite mettre à jour le groupe de nœuds pour utiliser la nouvelle version du modèle et demander au [processus de gestion du cycle](https://docs.aws.amazon.com//eks/latest/userguide/managed-node-update-behavior.html) de vie de mettre à jour vos nœuds sans interruption de service. Assurez-vous que le rôle IAM et le profil d'instance appliqués à votre groupe de nœuds gérés incluent les politiques `AmazonSSMManagedInstanceCore` AWS gérées `CloudWatchAgentServerPolicy` et.
Avec les nœuds autogérés, vous provisionnez et gérez directement le cycle de vie et la stratégie de mise à jour de vos nœuds Amazon EKS. [Les nœuds autogérés vous permettent d'exécuter des nœuds Windows sur votre cluster Amazon EKS et sur [Bottlerocket, entre](https://aws.amazon.com//bottlerocket/) autres options.](https://docs.aws.amazon.com//eks/latest/userguide/eks-compute.html) Vous pouvez utiliser CloudFormation pour déployer des nœuds autogérés dans vos clusters Amazon EKS, ce qui signifie que vous pouvez utiliser une approche iAc et une approche de modification gérée pour vos clusters Amazon EKS. AWS fournit le CloudFormation modèle [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) que vous pouvez utiliser tel quel ou personnaliser. Le modèle fournit toutes les ressources requises pour les nœuds Amazon EKS d'un cluster (par exemple, un rôle IAM distinct, un groupe de sécurité, un groupe Amazon EC2 Auto Scaling et un modèle de lancement). Le CloudFormation modèle [amazon-eks-nodegroup.yaml](https://github.com/aws-samples/logging-monitoring-apg-guide-examples/blob/main/examples/eks/amazon-eks-nodegroup.yaml) est une version mise à jour qui installe l'agent Systems Manager requis, l' CloudWatch agent, et ajoute également une configuration de journalisation spécifique à Amazon EKS dans le CloudWatch répertoire de configuration.
## Journalisation pour Amazon EKS sur Fargate
Avec Amazon EKS sur Fargate, vous pouvez déployer des pods sans allouer ni gérer vos nœuds Kubernetes. Il n'est donc plus nécessaire de capturer des journaux au niveau du système pour vos nœuds Kubernetes. Pour capturer les journaux de vos pods Fargate, vous pouvez utiliser Fluent Bit pour les transférer directement vers. CloudWatch Cela vous permet d'acheminer automatiquement les journaux CloudWatch sans autre configuration ou vers un conteneur annexe pour vos pods Amazon EKS sur Fargate. Pour plus d'informations à ce sujet, consultez [Fargate logging](https://docs.aws.amazon.com//eks/latest/userguide/fargate-logging.html) dans la documentation Amazon EKS [et Fluent Bit pour Amazon](https://aws.amazon.com//blogs/containers/fluent-bit-for-amazon-eks-on-aws-fargate-is-here/) EKS sur le blog. AWS Cette solution capture les flux `STDOUT` et `STDERR` input/output (E/S) de votre conteneur et les envoie CloudWatch via Fluent Bit, sur la base de la configuration Fluent Bit établie pour le cluster Amazon EKS sur Fargate.