Personalizar componentes do sistema em clusters do AKS
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, descrevemos como personalizar componentes do sistema do Google nos seus
clusters anexados do GKE aplicando tolerâncias e rótulos personalizados. Ao
personalizar esses componentes, você tem um gerenciamento mais preciso de onde e como
eles operam no seu ambiente.
Visão geral
Ao anexar um cluster ao Google Cloud, por padrão, os componentes do sistema de propriedade do Google não incluem campos personalizáveis, como tolerâncias. Como resultado, você pode ter problemas, como falha na programação de pods em nós disponíveis, o que afeta a funcionalidade e a vinculação geral do cluster. Além disso, talvez seja necessário controlar a colocação e o gerenciamento de componentes em nós específicos, incluindo a capacidade de aplicar rótulos personalizados para fins organizacionais e operacionais.
A personalização dos componentes do sistema resolve esses problemas e permite que você tenha mais controle e flexibilidade sobre como esses componentes operam no cluster. É
possível aplicar tolerâncias e rótulos personalizados a componentes do sistema de propriedade do Google:
As tolerâncias permitem que os componentes do Google sejam programados em nós com taints específicos do Kubernetes, o que permite aplicar a separação de cargas de trabalho ou usar pools de nós especializados. As tolerâncias personalizadas resolvem diretamente problemas em que taints imutáveis impedem o posicionamento adequado dos componentes.
Os rótulos oferecem uma maneira flexível de categorizar e identificar os componentes do sistema do Google de acordo com seus próprios padrões operacionais. Os rótulos personalizados
permitem uma melhor integração com as ferramentas atuais de monitoramento, geração de registros e aplicação
de políticas.
Restrições e limitações
As seguintes restrições e limitações são aplicáveis:
Só é possível adicionar tolerâncias e rótulos personalizados ao registrar o cluster.
É possível adicionar até 10 tolerâncias e 10 rótulos personalizados ao cluster.
Não é possível usar os seguintes marcadores:
name
component
app
Qualquer rótulo que inclua k8s.io ou kubernetes.io, já que eles pertencem a rótulos reservados no Kubernetes
Qualquer marcador que inclua google
Qualquer marcador que inclua gke.io
Adicionar tolerâncias personalizadas
Os pods de componentes do sistema de propriedade do Google sempre incluem a seguinte tolerância:
GOOGLE_CLOUD_REGION: a região Google Cloud para administrar o cluster.
COMPONENT_TOLERATION: a lista separada por vírgulas das
tolerâncias que você quer adicionar. É possível fornecer uma chave, um valor, um operador e um efeito nos seguintes formatos:
Para o operador Equal: use o formato key=value:operator:effect, por
exemplo, workload=hpc:Equal:NoSchedule. Essa configuração significa que o pod
tolera um taint somente se ele tiver a chave e o valor exatos de
workload=hpc.
Para o operador Exists: use o formato key:operator:effect, por
exemplo, workload:Exists:NoSchedule. Essa configuração significa que o pod tolera qualquer taint com a chave workload no nó, independente do valor.
Para programar em qualquer nó: use o formato :operator:effect, por
exemplo, :Exists:NoSchedule. Essa configuração significa que o pod tolera qualquer
taint no nó que tenha o efeito NoSchedule e
ignora a chave ou o valor do taint.
Para conferir uma lista de operadores e efeitos que você pode usar, consulte Taints e tolerâncias na documentação do Kubernetes.
Adicionar rótulos personalizados
Para especificar rótulos personalizados, adicione a flag --system-component-labels ao comando gcloud container attached clusters register:
GOOGLE_CLOUD_REGION: a região Google Cloud para administrar o cluster.
COMPONENT_LABEL: a lista separada por vírgulas de um ou mais
rótulos que você quer adicionar. Você fornece um rótulo e um valor no formato key=value. Por exemplo, env=production,region=us-east-1. Embora todo rótulo precise ter uma chave, o valor associado a ela pode estar vazio. Por exemplo, backend="".
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]