Journalisation pour Amazon EKS - AWS Conseils prescriptifs
Journalisation de plan de contrôle d'Amazon EKS Journalisation des applications et des nœuds Amazon EKSJournalisation pour Amazon EKS sur Fargate

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 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 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 dans 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 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 le point de terminaison Kubernetes.

Journalisation des applications et des nœuds Amazon EKS

Nous vous recommandons d'utiliser CloudWatchContainer Insights 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 pour Amazon EKS.

/aws/containerinsights/Cluster_Name/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_Name/host Journaux provenant de /var/log/dmesg/var/log/secure, et/var/log/messages.
/aws/containerinsights/Cluster_Name/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 EC2 des instances, 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, 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 ou en tant que nœuds autogérés.

Avec les groupes de nœuds gérés, vous fournissez un modèle de lancement 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_eks_managed_node_group_launch_config.yaml pour créer un AWS 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 selon une approche infrastructure-as-code (iAc). Chaque mise à jour du AWS 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 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 autres options. Vous pouvez utiliser AWS 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 AWS CloudFormation modèle 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 AWS CloudFormation modèle 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 dans la documentation Amazon EKS et Fluent Bit pour Amazon EKS sur le blog. AWS Cette solution capture les flux STDERR input/output (I/O (STDOUTet) 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.