Cet article explique comment exporter les journaux et les métriques d'un cluster d'utilisateur GKE sur AWS vers Cloud Logging et Cloud Monitoring.
Présentation
Différentes options de journalisation et de surveillance sont proposées avec GKE sur AWS. GKE Enterprise peut être intégré à Cloud Logging et Cloud Monitoring. Comme GKE Enterprise est basé sur Kubernetes Open Source, de nombreux outils Open Source et tiers sont compatibles.
Options de journalisation et de surveillance
Vous disposez de plusieurs options de journalisation et de surveillance pour votre cluster GKE Enterprise :
Vous pouvez déployer les agents Cloud Logging et Cloud Monitoring pour surveiller et afficher les journaux de vos charges de travail dans Google Cloud Console. Cet article présente cette solution.
Vous pouvez utiliser des outils Open Source tels que Prometheus, Grafana et Elasticsearch. L'article ne traite pas de cette solution.
Vous pouvez utiliser des solutions tierces, telles que Datadog. L'article ne traite pas de cette solution.
Cloud Logging et Cloud Monitoring
Avec GKE Enterprise, Cloud Logging et Cloud Monitoring, vous pouvez créer des tableaux de bord, envoyer des alertes, surveiller votre cluster et examiner les journaux des charges de travail exécutées sur celui-ci. Vous devez configurer les agents Cloud Logging et Cloud Monitoring pour qu'ils collectent des journaux et des métriques dans votre projet Google Cloud. Si vous ne configurez pas ces agents, les clusters GKE sur AWS ne collectent pas de données de journalisation et de surveillance.
Quelles sont les données recueillies ?
Une fois configurés, les agents collectent les journaux et les métriques du cluster et des charges de travail s'exécutant sur celui-ci. Ces données sont stockées dans votre projet Google Cloud. Vous devez configurer l'ID de projet dans le champ project_id
d'un fichier de configuration lorsque vous installez le service de transfert de journaux.
Les données collectées incluent les éléments suivants :
- Journaux des services système sur chacun des nœuds de calcul
- Journaux d'application pour toutes les charges de travail s'exécutant sur le cluster
- Métriques pour le cluster et les services système. Pour en savoir plus sur les métriques, consultez la page Métriques GKE Enterprise.
- Métriques d'applications pour les pods si vos applications sont configurées avec des cibles de scrape Prometheus et annotées avec une configuration incluant
prometheus.io/scrape
,prometheus.io/path
etprometheus.io/port
.
Vous pouvez désactiver les agents à tout moment. Consultez la page Effectuer un nettoyage pour en savoir plus. Les données collectées par les agents peuvent être gérées et supprimées comme toute autre donnée de métrique ou de journal, comme décrit dans les documentations de Cloud Monitoring et Cloud Logging.
Les données de journalisation sont stockées selon les règles de conservation configurées. La conservation des données de métriques varie selon le type de métrique.
Composants de journalisation et de surveillance
Pour exporter des données de télémétrie au niveau du cluster depuis des clusters GKE sur AWS vers Google Cloud, vous devez déployer les composants suivants dans votre cluster :
- Service de transfert de journaux Stackdriver (stackdriver-log-forwarder-*) Un DaemonSet Fluentbit qui transfère les journaux de chaque nœud Kubernetes vers Cloud Logging.
- Agent de métriques GKE (gke-metrics-agent-*). Un DaemonSet basé sur OpenTelemetry Collector qui collecte les données de métriques et les transmet à Cloud Monitoring.
Les fichiers manifestes de ces composants se trouvent dans le dépôt anthos-samples sur GitHub.
Prérequis
Un projet Google Cloud avec facturation activée. Pour en savoir plus sur les coûts, consultez la page Tarifs de Google Cloud Observability.
Les API Cloud Logging et Cloud Monitoring doivent également être activées sur le projet. Pour activer ces API, exécutez les commandes suivantes :
gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
Un environnement GKE sur AWS, y compris un cluster utilisateur enregistré auprès de Connect. Exécutez la commande suivante pour vérifier que votre cluster est enregistré.
gcloud container fleet memberships list
Si votre cluster est enregistré, Google Cloud CLI affiche son nom et son ID.
NAME EXTERNAL_ID cluster-0 1abcdef-1234-4266-90ab-123456abcdef
Si votre cluster n'est pas répertorié, consultez la section Se connecter à un cluster avec Connect.
L'outil de ligne de commande
git
doit être installé sur votre machine.
Configurer des autorisations pour Google Cloud Observability
Les agents de journalisation et de surveillance utilisent Fleet Workload Identity pour communiquer avec Cloud Logging et Cloud Monitoring. Cette identité a besoin d'autorisations pour écrire des journaux et des métriques dans votre projet. Pour ajouter les autorisations, exécutez les commandes suivantes :
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PROJECT_ID.svc.id.goog[kube-system/stackdriver]" \
--role=roles/logging.logWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PROJECT_ID.svc.id.goog[kube-system/stackdriver]" \
--role=roles/monitoring.metricWriter
Remplacez PROJECT_ID
par votre projet Google Cloud.
Se connecter à l'hôte bastion
Pour vous connecter à vos ressources GKE sur AWS, suivez les instructions suivantes. Indiquez si vous disposez d'un VPC AWS (ou d'une connexion directe à votre VPC) ou si vous avez créé un VPC dédié lors de la création de votre service de gestion.
VPC existant
Si vous disposez d'une connexion directe ou VPN à un VPC existant, omettez la ligne env HTTP_PROXY=http://localhost:8118
des commandes de cette rubrique.
VPC dédié
Lorsque vous créez un service de gestion dans un VPC dédié, GKE sur AWS inclut un hôte bastion placé dans un sous-réseau public.
Pour vous connecter à votre service de gestion, procédez comme suit :
Accédez au répertoire contenant votre configuration GKE sur AWS. Vous avez créé ce répertoire lors de l'installation du service de gestion.
cd anthos-aws
Pour ouvrir le tunnel, exécutez le script
bastion-tunnel.sh
. Le tunnel est transféré verslocalhost:8118
.Pour ouvrir un tunnel vers l'hôte bastion, exécutez la commande suivante :
./bastion-tunnel.sh -N
Les messages en provenance du tunnel SSH s'affichent dans cette fenêtre. Lorsque vous êtes prêt à fermer la connexion, arrêtez le processus à l'aide du raccourci Ctrl+C ou en fermant la fenêtre.
Ouvrez un nouveau terminal et accédez au répertoire
anthos-aws
.cd anthos-aws
Vérifiez que vous êtes en mesure de vous connecter au cluster à l'aide de
kubectl
.env HTTPS_PROXY=http://localhost:8118 \ kubectl cluster-info
La sortie inclut l'URL du serveur d'API du service de gestion.
Cloud Logging et Cloud Monitoring sur les nœuds de plan de contrôle
À l'aide de GKE sur AWS 1.8.0 et des versions ultérieures, Cloud Logging et Cloud Monitoring pour les nœuds du plan de contrôle peuvent être automatiquement configurés lors de la création de clusters d'utilisateur. Pour activer Cloud Logging ou Cloud Monitoring, complétez la section controlPlane.cloudOperations
de votre configuration AWSCluster
.
cloudOperations:
projectID: PROJECT_ID
location: GC_REGION
enableLogging: ENABLE_LOGGING
enableMonitoring: ENABLE_MONITORING
Remplacez les éléments suivants :
PROJECT_ID
: ID de votre projet.GC_REGION
: région Google Cloud dans laquelle vous souhaitez stocker les journaux. Choisissez une région proche de la région AWS. Pour plus d'informations, consultez la section Emplacements mondiaux – Régions et zones. Vous pouvez, par exemple, opter pour la régionus-central1
.ENABLE_LOGGING
:true
oufalse
, pour indiquer si Cloud Logging doit être activé ou non sur les nœuds du plan de contrôle.ENABLE_MONITORING
:true
oufalse
, pour indiquer si Cloud Monitoring doit être activé ou non sur les nœuds du plan de contrôle.
Ensuite, suivez la procédure décrite sur la page Créer un cluster d'utilisateur personnalisé.
Cloud Logging et Cloud Monitoring sur les nœuds de calcul
Supprimer la version précédente
Si vous avez configuré une version antérieure des agents de journalisation et de surveillance qui inclut stackdriver-log-aggregator
(Fluentd) et stackdriver-prometheus-k8s
(Prometheus), vous devrez peut-être les désinstaller avant de continuer.
Installer le service de transfert de journaux
Dans cette section, vous allez installer le service de transfert de journaux Stackdriver sur votre cluster.
Passez du répertoire
anthos-samples/aws-logging-monitoring/
au répertoirelogging/
.cd logging/
Modifiez le fichier
forwarder.yaml
pour qu'il corresponde à la configuration de votre projet :sed -i "s/PROJECT_ID/PROJECT_ID/g" forwarder.yaml sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" forwarder.yaml sed -i "s/CLUSTER_LOCATION/GC_REGION/g" forwarder.yaml
Remplacez l'élément suivant :
PROJECT_ID
: ID de votre projet.CLUSTER_NAME
: nom de votre cluster, par exemple,cluster-0
.GC_REGION
: région Google Cloud dans laquelle vous souhaitez stocker les journaux. Choisissez une région proche de la région AWS. Pour plus d'informations, consultez la section Emplacements mondiaux – Régions et zones. Vous pouvez, par exemple, opter pour la régionus-central1
.
(Facultatif) En fonction de vos charges de travail, du nombre de nœuds dans votre cluster et du nombre de pods par nœud, vous devrez peut-être définir des demandes de ressources de mémoire et de processeur. Pour plus d'informations, consultez la section Allocations de processeurs et de mémoire recommandées.
À partir de votre répertoire
anthos-aws
, utilisezanthos-gke
pour basculer vers le contexte de votre cluster d'utilisateur.cd anthos-aws env HTTPS_PROXY=http://localhost:8118 \ anthos-gke aws clusters get-credentials CLUSTER_NAME
Remplacez CLUSTER_NAME par le nom de votre cluster d'utilisateur.Créez le compte de service
stackdriver
s'il n'existe pas et déployez le service de transfert de journaux sur le cluster.env HTTPS_PROXY=http://localhost:8118 \ kubectl create serviceaccount stackdriver -n kube-system env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f forwarder.yaml
Utilisez
kubectl
pour vérifier que les pods ont démarré.env HTTPS_PROXY=http://localhost:8118 \ kubectl get pods -n kube-system | grep stackdriver-log
Vous devriez voir un pod de service de transfert par nœud dans un pool de nœuds. Par exemple, dans un cluster de six nœuds, vous devriez voir six pods de service de transfert.
stackdriver-log-forwarder-2vlxb 2/2 Running 0 21s stackdriver-log-forwarder-dwgb7 2/2 Running 0 21s stackdriver-log-forwarder-rfrdk 2/2 Running 0 21s stackdriver-log-forwarder-sqz7b 2/2 Running 0 21s stackdriver-log-forwarder-w4dhn 2/2 Running 0 21s stackdriver-log-forwarder-wrfg4 2/2 Running 0 21s
Tester le transfert de journaux
Dans cette section, vous allez déployer une charge de travail contenant un serveur Web HTTP de base avec générateur de charge sur votre cluster. Vous allez ensuite vérifier que les journaux sont présents dans Cloud Logging.
Avant d'installer cette charge de travail, vous pouvez vérifier les fichiers manifestes du serveur Web et du générateur de charge.
Déployez le serveur Web et le générateur de charge sur votre cluster.
env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/server/server.yaml env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/loadgen/loadgen.yaml
Pour vérifier que vous pouvez afficher les journaux de votre cluster dans le tableau de bord Cloud Logging, accédez à l'explorateur de journaux dans Google Cloud Console :
Copiez l'exemple de requête ci-dessous dans le champ Générateur de requête.
resource.type="k8s_container" resource.labels.cluster_name="CLUSTER_NAME"
Remplacez CLUSTER_NAME par le nom de votre cluster.
Cliquez sur Run query. Vous devriez voir les journaux de cluster récents apparaître sous Résultats de la requête.
Après avoir vérifié que les journaux apparaissent bien dans les résultats de la requête, supprimez le générateur de charge et le serveur Web.
env HTTPS_PROXY=http://localhost:8118 \ kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/loadgen/loadgen.yaml env HTTPS_PROXY=http://localhost:8118 \ kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/istio-samples/master/sample-apps/helloserver/server/server.yaml
Installer le collecteur de métriques
Dans cette section, vous allez installer un agent chargé d'envoyer des données à Cloud Monitoring.
Passez du répertoire
anthos-samples/aws-logging-monitoring/logging/
au répertoireanthos-samples/aws-logging-monitoring/monitoring/
.cd ../monitoring
Modifiez le fichier
gke-metrics-agent.yaml
pour qu'il corresponde à la configuration de votre projet :sed -i "s/PROJECT_ID/PROJECT_ID/g" gke-metrics-agent.yaml sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" gke-metrics-agent.yaml sed -i "s/CLUSTER_LOCATION/GC_REGION/g" gke-metrics-agent.yaml
Remplacez l'élément suivant :
PROJECT_ID
: ID de votre projet.CLUSTER_NAME
: nom de votre cluster, par exemple,cluster-0
.GC_REGION
: région Google Cloud dans laquelle vous souhaitez stocker les journaux. Choisissez une région proche de la région AWS. Pour plus d'informations, consultez la section Emplacements mondiaux – Régions et zones. Vous pouvez, par exemple, opter pour la régionus-central1
.
(Facultatif) En fonction de vos charges de travail, du nombre de nœuds dans votre cluster et du nombre de pods par nœud, vous devrez peut-être définir des demandes de ressources de mémoire et de processeur. Pour plus d'informations, consultez la section Allocations de processeurs et de mémoire recommandées.
Créez le compte de service
stackdriver
s'il n'existe pas et déployez l'agent de métriques sur votre cluster.env HTTPS_PROXY=http://localhost:8118 \ kubectl create serviceaccount stackdriver -n kube-system env HTTPS_PROXY=http://localhost:8118 \ kubectl apply -f gke-metrics-agent.yaml
Utilisez l'outil
kubectl
pour vérifier que le podgke-metrics-agent
est en cours d'exécution.env HTTPS_PROXY=http://localhost:8118 \ kubectl get pods -n kube-system | grep gke-metrics-agent
Vous devriez voir un pod d'agent par nœud dans un pool de nœuds. Par exemple, dans un cluster à trois nœuds, vous devez voir trois pods d'agent.
gke-metrics-agent-gjxdj 2/2 Running 0 102s gke-metrics-agent-lrnzl 2/2 Running 0 102s gke-metrics-agent-s6p47 2/2 Running 0 102s
Pour vérifier que vos métriques de cluster sont en cours d'exportation vers Cloud Monitoring, accédez à l'explorateur de métriques dans Google Cloud Console :
Dans l'explorateur de métriques, cliquez sur Éditeur de requête, puis copiez la commande suivante dans la zone de texte de l'éditeur :
fetch k8s_container | metric 'kubernetes.io/anthos/otelcol_exporter_sent_metric_points' | filter resource.project_id == 'PROJECT_ID' && (resource.cluster_name =='CLUSTER_NAME') | align rate(1m) | every 1m
Remplacez l'élément suivant :
PROJECT_ID
: ID de votre projet.CLUSTER_NAME
: nom de cluster que vous avez utilisé lors de la création du cluster d'utilisateur, par exemplecluster-0
.
Cliquez sur Run query. Le taux de points de métriques envoyés à Cloud Monitoring depuis chaque pod
gke-metrics-agent
de votre cluster s'affiche.Les autres métriques utiles incluent, mais sans s'y limiter :
kubernetes.io/anthos/container_memory_working_set_bytes
: l'utilisation de la mémoire du conteneur ;kubernetes.io/anthos/container_cpu_usage_seconds_total
: l'utilisation du processeur du conteneur ;kubernetes.io/anthos/apiserver_aggregated_request_total
: le nombre de requêtes kube-apiserver, disponible uniquement si Cloud Monitoring est activé sur le plan de contrôle.
Pour obtenir la liste complète des métriques disponibles, consultez la page Métriques Anthos. Pour en savoir plus sur l'utilisation de l'interface utilisateur, consultez la page Explorateur de métriques.
Créer un tableau de bord dans Cloud Monitoring
Dans cette section, vous allez créer un tableau de bord Cloud Monitoring qui surveille l'état des conteneurs de votre cluster.
Passez du répertoire
anthos-samples/aws-logging-monitoring/monitoring/
au répertoireanthos-samples/aws-logging-monitoring/monitoring/dashboards
.cd dashboards
Remplacez les instances de la chaîne
CLUSTER_NAME
danspod-status.json
par le nom de votre cluster.sed -i "s/CLUSTER_NAME/CLUSTER_NAME/g" pod-status.json
Remplacez
CLUSTER_NAME
par le nom de votre cluster.Créez un tableau de bord personnalisé avec le fichier de configuration en exécutant la commande suivante :
gcloud monitoring dashboards create --config-from-file=pod-status.json
Pour vérifier que votre tableau de bord a été créé, accédez à la page "Tableaux de bord Cloud Monitoring" dans Google Cloud Console.
Accéder à la page "Tableaux de bord"
Ouvrez le tableau de bord nouvellement créé avec un nom au format
CLUSTER_NAME (Anthos cluster on AWS) pod status
.
Nettoyer
Dans cette section, vous allez supprimer les composants de journalisation et de surveillance de votre cluster.
Supprimez le tableau de bord de surveillance de la liste "Tableaux de bord" de Google Cloud Console en cliquant sur le bouton de suppression associé au nom du tableau de bord.
Accédez au répertoire
anthos-samples/aws-logging-monitoring/
.cd anthos-samples/aws-logging-monitoring
Pour supprimer toutes les ressources créées dans ce guide, exécutez les commandes suivantes :
env HTTPS_PROXY=http://localhost:8118 \ kubectl delete -f logging/ env HTTPS_PROXY=http://localhost:8118 \ kubectl delete -f monitoring/
Allocations de processeurs et de mémoire recommandées
Cette section inclut les ressources de processeur recommandées et les allocations pour les composants individuels utilisés dans le cadre de la journalisation et de la surveillance. Chacun des tableaux ci-après répertorie les demandes de ressources de mémoire et de processeur pour un cluster comportant un nombre de nœuds compris dans une plage spécifique. Vous devez définir les demandes de ressources pour un composant dans le fichier spécifié dans le tableau.
Pour en savoir plus, consultez les sections Bonnes pratiques Kubernetes : requêtes et limites de ressources et Gérer les ressources pour les conteneurs.
De 1 à 10 nœuds
Fichier | Ressource | Demandes de ressources de processeur | Limites de processeur | Demandes de mémoire | Limites de mémoire |
---|---|---|---|---|---|
monitoring/gke-metrics-agent.yaml |
gke-metrics-agent | 30 m | 100 m | 50 Mi | 500 Mi |
logging/forwarder.yaml |
stackdriver-log-forwarder | 50 m | 100 m | 100 Mi | 600 Mi |
De 10 à 100 nœuds
Fichier | Ressource | Demandes de ressources de processeur | Limites de processeur | Demandes de mémoire | Limites de mémoire |
---|---|---|---|---|---|
monitoring/gke-metrics-agent.yaml |
gke-metrics-agent | 50 m | 100 m | 50 Mi | 500 Mi |
logging/forwarder.yaml |
stackdriver-log-forwarder | 60 m | 100 m | 100 Mi | 600 Mi |
Plus de 100 nœuds
Fichier | Ressource | Demandes de ressources de processeur | Limites de processeur | Demandes de mémoire | Limites de mémoire |
---|---|---|---|---|---|
monitoring/gke-metrics-agent.yaml |
gke-metrics-agent | 50 m | 100 m | 100 Mi | Non disponible |
logging/forwarder.yaml |
stackdriver-log-forwarder | 60 m | 100 m | 100 Mi | 600 Mi |
Étape suivante
Découvrez Cloud Logging :
- Présentation de Cloud Logging
- Utiliser l'explorateur de journaux
- Créer des requêtes pour Cloud Logging
- Créer des métriques basées sur les journaux