Déployer des charges de travail tierces sur Config Controller
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment déployer vos propres charges de travail sur les clusters Config Controller.
Cette page est destinée aux administrateurs et opérateurs informatiques qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente, planifient la capacité, et déploient des applications et des services en production. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
Si votre cluster Config Controller utilise une version de GKE antérieure à la version 1.27, mettez à niveau votre cluster vers la version 1.27 ou ultérieure.
Activer le provisionnement automatique des nœuds sur les clusters standards
Vous devez activer le provisionnement automatique des nœuds pour déployer vos propres charges de travail sur les clusters Config Controller. Cela permet de séparer les charges de travail entre vos charges de travail et celles gérées par Google, qui sont installées par défaut sur les clusters Config Controller.
Si vous utilisez des clusters Autopilot, vous n'avez pas besoin d'activer le provisionnement automatique des nœuds, car GKE gère automatiquement le scaling et le provisionnement des nœuds.
gcloud
Pour activer le provisionnement automatique des nœuds, exécutez la commande suivante :
Lorsque vous déployez vos charges de travail, Config Controller active automatiquement GKE Sandbox pour fournir un niveau de sécurité supplémentaire et empêcher un code non approuvé d'affecter le noyau hôte sur les nœuds de votre cluster. Pour en savoir plus, consultez la page À propos de GKE Sandbox.
Vous pouvez déployer une charge de travail en écrivant un fichier manifeste de charge de travail, puis en exécutant la commande suivante :
kubectl apply -f WORKLOAD_FILE
Remplacez WORKLOAD_FILE par le fichier manifeste, tel que my-app.yaml.
Vérifiez que votre charge de travail est en cours d'exécution sur les nœuds provisionnés automatiquement :
Obtenez la liste des nœuds créés pour votre charge de travail :
kubectl get nodes
Inspecter un nœud spécifique :
kubectl get nodes NODE_NAME -o yaml
Remplacez NODE_NAME par le nom du nœud que vous souhaitez inspecter.
Limites
GKE Sandbox : GKE Sandbox fonctionne bien avec de nombreuses applications, mais pas toutes. Pour en savoir plus, consultez Limites de GKE Sandbox.
Sécurité du plan de contrôle : lorsque vous accordez des autorisations pour vos charges de travail, utilisez le principe du moindre privilège pour n'accorder que les autorisations dont vous avez besoin. Si votre charge de travail est compromise, elle peut utiliser des autorisations trop permissives pour modifier ou supprimer des ressources Kubernetes.
Disponibilité du plan de contrôle : si vos charges de travail entraînent une augmentation du trafic en peu de temps, le plan de contrôle du cluster peut devenir indisponible jusqu'à ce que le trafic diminue.
Redimensionnement du plan de contrôle : GKE redimensionne automatiquement le plan de contrôle selon les besoins. Si votre charge de travail entraîne une forte augmentation de la charge (par exemple, l'installation de milliers d'objets CRD), le redimensionnement automatique de GKE peut ne pas être en mesure de suivre l'augmentation de la charge.
Quotas : lorsque vous déployez des charges de travail, vous devez connaître les quotas et limites de GKE et ne pas les dépasser.
Accès réseau au plan de contrôle et aux nœuds : Config Controller utilise des nœuds privés avec des réseaux autorisés maîtres activés, le point de terminaison privé activé et l'accès public désactivé. Pour en savoir plus, consultez Sécurité du réseau GKE.
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/09/01 (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/09/01 (UTC)."],[],[],null,["# Deploy third-party workloads on Config Controller\n\nThis page explains how to deploy your own workloads on Config Controller\nclusters.\n\nThis page is for IT administrators and Operators who manage\nthe lifecycle of the underlying tech infrastructure and plan capacity, and\ndeploy apps and services to production. To learn more about common roles and\nexample tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nBefore you begin\n----------------\n\nBefore you start, make sure you have performed the following tasks:\n\n1. Set up [Config Controller](/kubernetes-engine/enterprise/config-controller/docs/setup).\n2. If your Config Controller cluster is on a GKE version earlier than version 1.27, [upgrade your cluster](/kubernetes-engine/docs/how-to/upgrading-a-cluster#upgrading_the_cluster) to version 1.27 or later.\n\nEnable node auto-provisioning on Standard clusters\n--------------------------------------------------\n\nYou must enable [node auto-provisioning](/kubernetes-engine/docs/concepts/node-auto-provisioning)\nto deploy your own workloads on Config Controller clusters. This allows for\nworkload separation between your workloads and the Google-managed workloads\ninstalled by default on Config Controller clusters.\n\nIf you use Autopilot clusters, you don't need to enable node auto-provisioning\nbecause GKE automatically manages node scaling and provisioning. \n\n### gcloud\n\nTo enable node auto-provisioning, run the following command: \n\n```\ngcloud container clusters update CLUSTER_NAME \\\n --enable-autoprovisioning \\\n --min-cpu MINIMUM_CPU \\\n --min-memory MIMIMUM_MEMORY \\\n --max-cpu MAXIMUM_CPU \\\n --max-memory MAXIMUM_MEMORY \\\n --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of your Config Controller cluster.\n- \u003cvar translate=\"no\"\u003eMINIMUM_CPU\u003c/var\u003e: the minimum number of cores in the cluster.\n- \u003cvar translate=\"no\"\u003eMINIMUM_MEMORY\u003c/var\u003e: the minimum number of gigabytes of memory in the cluster.\n- \u003cvar translate=\"no\"\u003eMAXIMUM_CPU\u003c/var\u003e: the maximum number of cores in the cluster.\n- \u003cvar translate=\"no\"\u003eMAXIMUM_MEMORY\u003c/var\u003e: the maximum number of gigabytes of memory in the cluster.\n\n### Console\n\nTo enable node auto-provisioning, perform the following steps:\n\n1. Go to the **Google Kubernetes Engine** page in Google Cloud console.\n\n [Go to Google Kubernetes Engine](https://console.cloud.google.com/kubernetes/list)\n2. Click the name of the cluster.\n\n3. In the **Automation** section, for **Node auto-provisioning** , click edit **Edit**.\n\n4. Select the **Enable node auto-provisioning** checkbox.\n\n5. Set the minimum and maximum CPU and memory usage for the cluster.\n\n6. Click **Save changes**.\n\nFor more information on configuring node auto-provisioning, such as setting defaults,\nsee [Configure node auto-provisioning](/kubernetes-engine/docs/how-to/node-auto-provisioning).\n\nDeploy your workload\n--------------------\n\nWhen you deploy your workloads, Config Controller automatically\nenables GKE Sandbox to provide an extra layer of security to prevent untrusted\ncode from affecting the host kernel on your cluster nodes. For more information, see\n[About GKE Sandbox](/kubernetes-engine/docs/concepts/sandbox-pods).\n\nYou can deploy a workload by writing a workload manifest file and then\nrunning the following command: \n\n```\nkubectl apply -f WORKLOAD_FILE\n```\n\nReplace \u003cvar translate=\"no\"\u003eWORKLOAD_FILE\u003c/var\u003e with the manifest file, such as `my-app.yaml`.\n\nConfirm that your workload is running on the auto-provisioned nodes:\n\n1. Get the list of nodes created for your workload:\n\n ```\n kubectl get nodes\n ```\n2. Inspect a specific node:\n\n kubectl get nodes \u003cvar translate=\"no\"\u003eNODE_NAME\u003c/var\u003e -o yaml\n\n Replace \u003cvar translate=\"no\"\u003eNODE_NAME\u003c/var\u003e with the name of the node that you want to inspect.\n\nLimitations\n-----------\n\n- GKE Sandbox: GKE Sandbox works well with many applications, but not all. For more information, see [GKE Sandbox limitations](/kubernetes-engine/docs/concepts/sandbox-pods#limitations).\n- Control plane security: when granting permission for your workloads, use the principle of least privilege to grant only the permissions that you need. If your workload becomes compromised, the workload can use overly-permissive permissions to change or delete Kubernetes resources.\n- Control plane availability: if your workloads cause increased traffic in a short time, the cluster control plane might become unavailable until the traffic decreases.\n- Control plane resizing: GKE automatically resizes the control plane as needed. If your workload causes a large load increase (for example, installing thousands of CRD objects), GKE's automatic resizing might not be able to keep up with the load increase.\n- Quotas: when deploying workloads, you should be aware of GKE's [quotas and limits](/kubernetes-engine/quotas) and not exceed them.\n- Network access to control plane and nodes: Config Controller uses private nodes with Master Authorized Networks Enabled, Private Endpoint Enabled, and Public Access Disabled. For more information, see [GKE network security](/kubernetes-engine/docs/how-to/hardening-your-cluster#restrict_network_access_to_the_control_plane_and_nodes).\n\nWhat's next\n-----------\n\n- Learn more about Config Controller best practices: [Config Controller scalability](/kubernetes-engine/enterprise/config-controller/docs/scalability), [Config Controller sharding](/kubernetes-engine/enterprise/config-controller/docs/sharding), and [Configuring Config Controller for high availability](/kubernetes-engine/enterprise/config-controller/docs/availability)\n- [Troubleshoot Config Controller](/kubernetes-engine/enterprise/config-controller/docs/troubleshoot)\n- [Monitor Config Controller](/kubernetes-engine/enterprise/config-controller/docs/monitor)"]]