Personnaliser les composants système sur les clusters AKS
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment personnaliser les composants système appartenant à Google dans vos clusters GKE associés en appliquant des tolérances et des libellés personnalisés. Lorsque vous personnalisez ces composants, vous pouvez gérer plus précisément où et comment ils fonctionnent dans votre environnement.
Présentation
Lorsque vous associez un cluster à Google Cloud, les composants système appartenant à Google n'incluent pas par défaut de champs personnalisables tels que les tolérances. Par conséquent, vous pouvez rencontrer des problèmes tels que l'échec de la planification des pods sur les nœuds disponibles, ce qui a un impact sur l'attachement et la fonctionnalité globale du cluster. Vous pouvez également avoir besoin de contrôler le placement et la gestion des composants sur des nœuds spécifiques, y compris la possibilité d'appliquer des libellés personnalisés à des fins organisationnelles et opérationnelles.
La personnalisation des composants système résout ces problèmes et vous permet de mieux contrôler et de rendre plus flexibles le fonctionnement de ces composants dans votre cluster. Vous pouvez appliquer des tolérances et des libellés personnalisés aux composants système appartenant à Google :
Les tolérances permettent aux composants Google de planifier des nœuds qui présentent des rejets Kubernetes spécifiques. Vous pouvez ainsi appliquer la séparation des charges de travail ou utiliser des pools de nœuds spécialisés. Les tolérances personnalisées résolvent directement les problèmes liés aux rejets non modifiables qui empêchent le placement correct des composants.
Les libellés vous permettent de classer et d'identifier de manière flexible les composants système de Google en fonction de vos propres normes opérationnelles. Les libellés personnalisés permettent une meilleure intégration avec vos outils existants de surveillance, de journalisation et d'application des règles.
Restrictions et limitations
Les restrictions et limites suivantes s'appliquent :
Vous ne pouvez ajouter des tolérances et des libellés personnalisés que lorsque vous enregistrez votre cluster.
Vous pouvez ajouter jusqu'à 10 tolérances personnalisées et 10 libellés personnalisés à votre cluster.
Vous ne pouvez pas utiliser les libellés suivants :
name
component
app
Tout libellé incluant k8s.io ou kubernetes.io, car ils appartiennent aux libellés réservés dans Kubernetes
Tout libellé incluant google
Tout libellé incluant gke.io
Ajouter des tolérances personnalisées
Les pods de composants système appartenant à Google incluent toujours la tolérance suivante :
GOOGLE_CLOUD_REGION : région Google Cloud depuis laquelle administrer votre cluster.
COMPONENT_TOLERATION : liste des tolérances à ajouter, séparées par une virgule. Vous pouvez fournir une clé, une valeur, un opérateur et un effet dans les formats suivants :
Pour l'opérateur Equal : utilisez le format key=value:operator:effect, par exemple workload=hpc:Equal:NoSchedule. Ce paramètre signifie que le pod tolère un rejet uniquement si celui-ci possède exactement la clé et la valeur workload=hpc.
Pour l'opérateur Exists : utilisez le format key:operator:effect, par exemple workload:Exists:NoSchedule. Ce paramètre signifie que le pod tolère toute propriété de rejet avec la clé workload sur le nœud, quelle que soit la valeur.
Pour planifier sur n'importe quel nœud : utilisez le format :operator:effect, par exemple :Exists:NoSchedule. Ce paramètre signifie que le pod tolère tout rejet sur le nœud ayant l'effet NoSchedule et ignore la clé ou la valeur du rejet.
Pour obtenir la liste des opérateurs et des effets que vous pouvez utiliser, consultez Rejets et tolérances dans la documentation Kubernetes.
Ajouter des libellés personnalisés
Pour spécifier des libellés personnalisés, ajoutez l'option --system-component-labels à la commande gcloud container attached clusters register :
GOOGLE_CLOUD_REGION : région Google Cloud depuis laquelle administrer votre cluster.
COMPONENT_LABEL : liste d'une ou de plusieurs étiquettes à ajouter, séparées par une virgule. Vous fournissez un libellé et une valeur au format key=value. Par exemple, env=production,region=us-east-1. Bien que chaque libellé doive comporter une clé, la valeur associée à cette clé peut être vide. Par exemple, backend="".
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/14 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/14 (UTC)."],[],[],null,["# Customize system components on AKS clusters\n\n| **Preview**\n|\n|\n| This feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThis page describes how to customize Google-owned system components in your\nGKE attached clusters by applying custom tolerations and labels. When you\ncustomize these components, you have more precise management of where and how\nthese components operate within your environment.\n\nOverview\n--------\n\nWhen you attach a cluster to Google Cloud, by default, Google-owned system\ncomponents don't include customizable fields such as tolerations. As a result,\nyou might experience issues such as Pods failing to schedule on available nodes, which\nimpact overall cluster attachment and functionality. Additionally, you might require\ncontrol over placing and managing components on specific nodes that include the\nability to apply custom labels for organizational and operational purposes.\n\nCustomizing system components resolves these issues and lets you have more\ncontrol and flexibility over how these components operate in your cluster. You\ncan apply custom *tolerations* and *labels* to Google-owned system components:\n\n- **Tolerations** provide the ability for Google's components to schedule onto\n nodes that have specific Kubernetes taints, which lets you enforce workload\n separation or use specialized node pools. Custom tolerations directly resolve\n issues where unmodifiable taints prevent proper component placement.\n\n- **Labels** offer a flexible way for you to categorize and identify Google's\n system components according to your own operational standards. Custom labels\n enable better integration with your existing monitoring, logging, and policy\n enforcement tools.\n\nRestrictions and limitations\n----------------------------\n\nThe following restrictions and limitations apply:\n\n- You can only add custom tolerations and labels when you [register your cluster](/kubernetes-engine/multi-cloud/docs/attached/aks/how-to/attach-cluster#attach_your_aks_cluster).\n- You can add up to 10 custom tolerations and 10 custom labels to your cluster.\n- You *can't* use the following labels:\n\n - `name`\n - `component`\n - `app`\n - Any label which includes `k8s.io` or `kubernetes.io` since they belong to reserved labels in Kubernetes\n - Any label which includes `google`\n - Any label which includes `gke.io`\n\nAdd custom tolerations\n----------------------\n\nGoogle-owned system component Pods always include the following toleration: \n\n - key: components.gke.io/gke-managed-components\n operator: Exists\n\nTo specify custom tolerations, add the `--system-component-tolerations` flag to the\n[`gcloud container attached clusters register`](/sdk/gcloud/reference/container/attached/clusters/register) command: \n\n gcloud container attached clusters register \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eGOOGLE_CLOUD_REGION\u003c/var\u003e \\\n ...\n --system-component-tolerations=\u003cvar translate=\"no\"\u003eCOMPONENT_TOLERATION\u003c/var\u003e \\\\\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of your cluster.\n- \u003cvar translate=\"no\"\u003eGOOGLE_CLOUD_REGION\u003c/var\u003e: the Google Cloud region to administer your cluster from.\n- \u003cvar translate=\"no\"\u003eCOMPONENT_TOLERATION\u003c/var\u003e: the comma-separated list of the\n tolerations that you want to add. You can provide a key, value, operator, and\n effect in the following formats:\n\n - **For the `Equal` operator** : use the format `key=value:operator:effect`, for example, `workload=hpc:Equal:NoSchedule`. This setting means that the Pod tolerates a taint only if the taint has the exact key and value of `workload=hpc`.\n - **For the `Exists` operator** : use the format `key:operator:effect`, for example, `workload:Exists:NoSchedule`. This setting means that the Pod tolerates any taint with the `workload` key on the node, regardless of the value.\n - **For scheduling on any node** : use the format `:operator:effect`, for example, `:Exists:NoSchedule`. This setting means that the Pod tolerates any taint on the node that has the effect `NoSchedule`, and ignores the key or value of the taint.\n\n For a list of operators and effects that you\n can use, see [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)\n in the Kubernetes documentation.\n\nAdd custom labels\n-----------------\n\nTo specify custom labels, add the `--system-component-labels` flag to the\n`gcloud container attached clusters register` command: \n\n gcloud container attached clusters register \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eGOOGLE_CLOUD_REGION\u003c/var\u003e \\\n ...\n --system-component-labels=\u003cvar translate=\"no\"\u003eCOMPONENT_LABEL\u003c/var\u003e \\\\\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of your cluster.\n- \u003cvar translate=\"no\"\u003eGOOGLE_CLOUD_REGION\u003c/var\u003e: the Google Cloud region to administer your cluster from.\n- \u003cvar translate=\"no\"\u003eCOMPONENT_LABEL\u003c/var\u003e: the comma-separated list of one or more labels that you want to add. You provide a label and value in the format of `key=value`. For example, `env=production,region=us-east-1`. Although every label must have a key, the value associated with that key can be empty. For example, `backend=\"\"`.\n\nWhat's next\n-----------\n\n- Learn more about [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) in the Kubernetes documentation.\n- Learn how to [attach your AKS cluster](/kubernetes-engine/multi-cloud/docs/attached/aks/how-to/attach-cluster)."]]