Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite wird beschrieben, wie Sie von Google entwickelte Systemkomponenten in Ihren angehängten GKE-Clustern anpassen, indem Sie benutzerdefinierte Toleranzen und Labels anwenden. Wenn Sie diese Komponenten anpassen, können Sie genauer festlegen, wo und wie sie in Ihrer Umgebung funktionieren.
Übersicht
Wenn Sie einen Cluster an Google Cloudanhängen, enthalten Google-eigene Systemkomponenten standardmäßig keine anpassbaren Felder wie Toleranzen. Dies kann zu Problemen führen, z. B. dass Pods nicht auf verfügbaren Knoten geplant werden können, was sich auf die gesamte Clusterverbindung und -funktionalität auswirkt. Außerdem benötigen Sie möglicherweise die Möglichkeit, Komponenten auf bestimmten Knoten zu platzieren und zu verwalten, einschließlich der Möglichkeit, benutzerdefinierte Labels für organisatorische und betriebliche Zwecke anzuwenden.
Durch die Anpassung von Systemkomponenten werden diese Probleme behoben und Sie haben mehr Kontrolle und Flexibilität bei der Funktionsweise dieser Komponenten in Ihrem Cluster. Sie können benutzerdefinierte Toleranzen und Labels auf Google-eigene Systemkomponenten anwenden:
Toleranzen ermöglichen es, dass Google-Komponenten auf Knoten geplant werden, die bestimmte Kubernetes-Markierungen haben. So können Sie die Arbeitslasttrennung erzwingen oder spezielle Knotenpools verwenden. Mit benutzerdefinierten Toleranzen lassen sich Probleme direkt beheben, bei denen nicht änderbare Taints die richtige Platzierung von Komponenten verhindern.
Labels bieten Ihnen eine flexible Möglichkeit, die Systemkomponenten von Google nach Ihren eigenen Betriebsstandards zu kategorisieren und zu identifizieren. Benutzerdefinierte Labels ermöglichen eine bessere Integration in Ihre vorhandenen Tools für Monitoring, Logging und Richtliniendurchsetzung.
Limits und Einschränkungen
Es gelten die folgenden Einschränkungen:
Sie können nur benutzerdefinierte Toleranzen und Labels hinzufügen, wenn Sie Ihren Cluster registrieren.
Sie können Ihrem Cluster bis zu 10 benutzerdefinierte Toleranzen und 10 benutzerdefinierte Labels hinzufügen.
Die folgenden Labels dürfen nicht verwendet werden:
name
component
app
Alle Labels, die k8s.io oder kubernetes.io enthalten, da sie zu reservierten Labels in Kubernetes gehören
Alle Labels, die google enthalten
Alle Labels, die gke.io enthalten
Benutzerdefinierte Toleranzen hinzufügen
Google-eigene Systemkomponenten-Pods enthalten immer die folgende Tolerierung:
GOOGLE_CLOUD_REGION: die Google Cloud Region, in der Sie Ihren Cluster verwalten möchten.
COMPONENT_TOLERATION: Eine durch Kommas getrennte Liste der Toleranzen, die Sie hinzufügen möchten. Sie können einen Schlüssel, einen Wert, einen Operator und einen Effekt in den folgenden Formaten angeben:
Für den Operator Equal: Verwenden Sie das Format key=value:operator:effect, z. B. workload=hpc:Equal:NoSchedule. Diese Einstellung bedeutet, dass der Pod eine Markierung nur toleriert, wenn die Markierung genau den Schlüssel und den Wert von workload=hpc hat.
Für den Operator Exists: Verwenden Sie das Format key:operator:effect, z. B. workload:Exists:NoSchedule. Diese Einstellung bedeutet, dass der Pod jede Markierung mit dem Schlüssel workload auf dem Knoten toleriert, unabhängig vom Wert.
Für die Planung auf einem beliebigen Knoten: Verwenden Sie das Format :operator:effect, z. B. :Exists:NoSchedule. Diese Einstellung bedeutet, dass der Pod jede Markierung auf dem Knoten mit dem Effekt NoSchedule toleriert und den Schlüssel oder Wert der Markierung ignoriert.
Eine Liste der Operatoren und Effekte, die Sie verwenden können, finden Sie in der Kubernetes-Dokumentation unter Markierungen und Toleranzen.
Benutzerdefinierte Labels hinzufügen
Wenn Sie benutzerdefinierte Labels angeben möchten, fügen Sie dem Befehl gcloud container attached clusters register das Flag --system-component-labels hinzu:
GOOGLE_CLOUD_REGION: die Google Cloud Region, in der Sie Ihren Cluster verwalten möchten.
COMPONENT_LABEL: Die durch Kommas getrennte Liste mit einem oder mehreren Labels, die Sie hinzufügen möchten. Sie geben ein Label und einen Wert im Format key=value an. Beispiel: env=production,region=us-east-1 Jedes Label muss einen Schlüssel haben, der zugehörige Wert kann jedoch leer sein. Beispiel: backend="".
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]