Esegui il deployment di carichi di lavoro di terze parti su Config Controller
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina spiega come eseguire il deployment dei tuoi carichi di lavoro sui cluster Config Controller.
Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono
il ciclo di vita dell'infrastruttura tecnologica sottostante e pianificano la capacità, nonché
implementano app e servizi in produzione. Per scoprire di più sui ruoli comuni e
sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta la pagina
Ruoli e attività comuni degli utenti GKE. Google Cloud
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
Se il cluster Config Controller utilizza una versione di GKE precedente
alla versione 1.27,
esegui l'upgrade del cluster
alla versione 1.27 o successive.
Abilita il provisioning automatico dei nodi sui cluster Standard
Per eseguire il deployment dei tuoi workload sui cluster Config Controller, devi abilitare il provisioning automatico dei nodi. Ciò consente la
separazione dei workload tra i tuoi workload e quelli gestiti da Google
installati per impostazione predefinita sui cluster Config Controller.
Se utilizzi cluster Autopilot, non devi abilitare il provisioning automatico dei nodi
perché GKE gestisce automaticamente lo scaling e il provisioning dei nodi.
gcloud
Per abilitare il provisioning automatico dei nodi, esegui questo comando:
Nella sezione Automazione, in Provisioning automatico dei nodi, fai clic su editModifica.
Seleziona la casella di controllo Abilita provisioning automatico dei nodi.
Imposta l'utilizzo minimo e massimo di CPU e memoria per il cluster.
Fai clic su Salva modifiche.
Per ulteriori informazioni sulla configurazione del provisioning automatico dei nodi, ad esempio l'impostazione dei valori predefiniti,
consulta Configurare il provisioning automatico dei nodi.
Esegui il deployment del carico di lavoro
Quando esegui il deployment dei carichi di lavoro, Config Controller attiva automaticamente
GKE Sandbox per fornire un ulteriore livello di sicurezza per impedire che codice non attendibile
influisca sul kernel host sui nodi del cluster. Per maggiori informazioni, consulta la pagina
Informazioni su GKE Sandbox.
Puoi eseguire il deployment di un workload scrivendo un file manifest del workload e poi
eseguendo questo comando:
kubectl apply -f WORKLOAD_FILE
Sostituisci WORKLOAD_FILE con il file manifest, ad esempio my-app.yaml.
Verifica che il tuo workload sia in esecuzione sui nodi di cui è stato eseguito il provisioning automatico:
Recupera l'elenco dei nodi creati per il tuo workload:
kubectl get nodes
Controllare un nodo specifico:
kubectl get nodes NODE_NAME -o yaml
Sostituisci NODE_NAME con il nome del nodo che vuoi ispezionare.
Limitazioni
GKE Sandbox: GKE Sandbox funziona bene con molte applicazioni, ma non con tutte. Per maggiori informazioni, consulta Limitazioni di GKE Sandbox.
Sicurezza del control plane: quando concedi l'autorizzazione per i tuoi carichi di lavoro, utilizza il principio del privilegio minimo per concedere solo le autorizzazioni di cui hai bisogno. Se
il tuo workload viene compromesso, può utilizzare autorizzazioni eccessivamente permissive
per modificare o eliminare le risorse Kubernetes.
Disponibilità del control plane: se i tuoi carichi di lavoro causano un aumento del traffico in un breve periodo di tempo, il control plane del cluster potrebbe non essere disponibile finché il traffico non diminuisce.
Ridimensionamento del control plane: GKE ridimensiona automaticamente il control plane in base alle esigenze. Se il tuo workload causa un aumento significativo del carico (ad esempio, l'installazione di migliaia di
oggetti CRD), il ridimensionamento automatico di GKE potrebbe non essere in grado di tenere
il passo con l'aumento del carico.
Quote: quando esegui il deployment dei carichi di lavoro, devi tenere conto delle quote e dei limiti di GKE e non superarli.
Accesso di rete al control plane e ai nodi: Config Controller utilizza nodi privati con reti autorizzate master abilitate, endpoint privato abilitato e accesso pubblico disabilitato. Per maggiori informazioni, consulta
Sicurezza di rete GKE.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)"]]