Cette page explique comment résoudre les problèmes liés aux charges de travail privilégiées que vous déployez dans les clusters Google Kubernetes Engine (GKE) Autopilot.
Problèmes de synchronisation de la liste d'autorisation
Lorsque vous déployez un AllowlistSynchronizer, GKE tente d'installer et de synchroniser les fichiers de liste d'autorisation que vous spécifiez. Si cette synchronisation échoue, le champ status de AllowlistSynchronizer signale l'erreur.
Les champs conditions.message et managedAllowlistStatus.lastError fournissent des informations détaillées sur l'erreur. Utilisez ces informations pour résoudre le problème.
Problèmes de déploiement de charges de travail privilégiées
Une fois la liste d'autorisation installée, vous déployez la charge de travail privilégiée correspondante dans votre cluster. Dans certains cas, GKE peut refuser la charge de travail.
Essayez les options de résolution suivantes :
Assurez-vous que la version GKE de votre cluster répond aux exigences de version de la charge de travail.
Assurez-vous que la charge de travail que vous déployez est celle à laquelle s'applique le fichier de liste d'autorisation.
Pour savoir pourquoi une charge de travail privilégiée a été refusée, demandez des informations détaillées à GKE sur les cas de non-respect de la liste d'autorisation :
Obtenez la liste des listes d'autorisation installées dans le cluster :
kubectlgetworkloadallowlist
Recherchez le nom de la liste d'autorisation qui doit s'appliquer à la charge de travail privilégiée.
Ouvrez le fichier manifeste YAML de la charge de travail privilégiée dans un éditeur de texte. Si vous ne pouvez pas accéder aux fichiers manifestes YAML (par exemple, si le processus de déploiement de la charge de travail utilise d'autres outils), contactez le fournisseur de la charge de travail pour signaler un problème. Vous pouvez ignorer les autres étapes.
Ajoutez le libellé suivant à la section spec.metadata.labels de la spécification de pod de la charge de travail privilégiée :
Remplacez ALLOWLIST_NAME par le nom de la liste d'autorisation que vous avez obtenue à l'étape précédente. Utilisez le nom de la sortie de la commande kubectl get workloadallowlist, et non le chemin d'accès au fichier de la liste d'autorisation.
Enregistrez le fichier manifeste et appliquez la charge de travail au cluster :
kubectlapply-fWORKLOAD_MANIFEST_FILE
Remplacez WORKLOAD_MANIFEST_FILE par le chemin d'accès au fichier manifeste.
Le résultat fournit des informations détaillées sur les champs de la charge de travail qui ne correspondaient pas à la liste d'autorisation spécifiée, comme dans l'exemple suivant :
Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:
===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
- data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
- env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
- env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
- Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
- data not found in allowlist. Verify volumeMount with matching name exists in allowlist.
Dans cet exemple, les cas de non-respect suivants se produisent :
La charge de travail spécifie hostNetwork: true, mais la liste d'autorisation ne spécifie pas hostNetwork: true.
La charge de travail spécifie hostPID: true, mais la liste d'autorisation ne spécifie pas hostPID: true.
La charge de travail spécifie un volume nommé data, mais la liste d'autorisation ne spécifie pas de volume nommé data.
Le conteneur spécifie des variables d'environnement nommées ENV_VAR1 et ENV_VAR2, mais la liste d'autorisation ne les spécifie pas.
Le conteneur spécifie l'image k8s.gcr.io/diff/image, mais la liste d'autorisation spécifie k8s.gcr.io/pause2.
Le conteneur ajoute les fonctionnalités SYS_ADMIN et SYS_PTRACE, mais la liste d'autorisation n'autorise pas l'ajout de ces fonctionnalités.
Le conteneur spécifie un montage de volume nommé data, mais la liste d'autorisation ne spécifie pas de montage de volume nommé data.
Si vous déployez une charge de travail fournie par un fournisseur tiers, ouvrez un problème avec ce fournisseur pour résoudre les cas de non-respect. Indiquez le résultat de l'étape précédente dans le problème.
Bugs et demandes de fonctionnalités pour les charges de travail privilégiées et les listes d'autorisation
Il incombe aux partenaires de créer, de développer et de gérer leurs charges de travail privilégiées et leurs listes d'autorisation. Si vous rencontrez un bug ou si vous souhaitez demander une fonctionnalité pour une charge de travail privilégiée ou une liste d'autorisation, contactez le partenaire correspondant.
Étapes suivantes
Si vous ne trouvez pas de solution à votre problème dans la documentation, consultez Obtenir de l'aide pour obtenir une assistance supplémentaire, y compris des conseils sur les sujets suivants :
Obtenir de l'aide de la communauté en posant des questions sur Stack Overflow et en utilisant le tag google-kubernetes-engine pour rechercher des problèmes similaires. Vous pouvez également rejoindre le canal Slack #kubernetes-engine pour obtenir de l'aide auprès de la communauté.
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,["# Troubleshoot deploying privileged Autopilot workloads\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview)\n\n*** ** * ** ***\n\nThis page shows you how to resolve issues with privileged workloads that you\ndeploy in Google Kubernetes Engine (GKE) Autopilot clusters.\n\nAllowlist synchronization issues\n--------------------------------\n\nWhen you deploy an `AllowlistSynchronizer`, GKE attempts to\ninstall and synchronize the allowlist files that you specify. If this\nsynchronization fails, the `status` field of the `AllowlistSynchronizer`\nreports the error.\n\nGet the status of the `AllowlistSynchronizer` object: \n\n kubectl get allowlistsynchronizer \u003cvar translate=\"no\"\u003eALLOWLIST_SYNCHRONIZER_NAME\u003c/var\u003e -o yaml\n\nThe output is similar to the following: \n\n ...\n status:\n conditions:\n - type: Ready\n status: \"False\"\n reason: \"SyncError\"\n message: \"some allowlists failed to sync: example-allowlist-1.yaml\"\n lastTransitionTime: \"2024-10-12T10:00:00Z\"\n observedGeneration: 2\n managedAllowlistStatus:\n - filePath: \"gs://path/to/allowlist1.yaml\"\n generation: 1\n phase: Installed\n lastSuccessfulSync: \"2024-10-10T10:00:00Z\"\n - filePath: \"gs://path/to/allowlist2.yaml\"\n phase: Failed\n lastError: \"Initial install failed: invalid contents\"\n lastSuccessfulSync: \"2024-10-08T10:00:00Z\"\n\nThe `conditions.message` field and the `managedAllowlistStatus.lastError` field\nprovide detailed information about the error. Use this information to resolve\nthe issue.\n\nPrivileged workload deployment issues\n-------------------------------------\n\nAfter successfully installing an allowlist, you deploy the corresponding\nprivileged workload in your cluster. In some cases, GKE might\nreject the workload.\n\nTry the following resolution options:\n\n- Ensure that the GKE version of your cluster meets the version requirement of the workload.\n- Ensure that the workload that you're deploying is the workload to which the allowlist file applies.\n\nTo see why a privileged workload was rejected, request detailed information\nfrom GKE about allowlist violations:\n\n1. Get a list of the installed allowlists in the cluster:\n\n kubectl get workloadallowlist\n\n Find the name of the allowlist that should apply to the privileged workload.\n2. Open the YAML manifest of the privileged workload in a text editor. If you\n can't access the YAML manifests, for example if the workload deployment\n process uses other tooling, contact the workload provider to open\n an issue. Skip the remaining steps.\n\n3. Add the following label to the `spec.metadata.labels` section of the\n privileged workload Pod specification:\n\n labels:\n cloud.google.com/matching-allowlist: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eALLOWLIST_NAME\u003c/span\u003e\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eALLOWLIST_NAME\u003c/var\u003e with the name of the\n allowlist that you obtained in the previous step. Use the name from the\n output of the `kubectl get workloadallowlist` command, not the path to the\n allowlist file.\n4. Save the manifest and apply the workload to the cluster:\n\n kubectl apply -f \u003cvar translate=\"no\"\u003eWORKLOAD_MANIFEST_FILE\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eWORKLOAD_MANIFEST_FILE\u003c/var\u003e with the path to the\n manifest file.\n\n The output provides detailed information about which fields in the workload\n didn't match the specified allowlist, like in the following example: \n\n Error from server (GKE Warden constraints violations): error when creating \"STDIN\": admission webhook \"warden-validating.common-webhooks.networking.gke.io\" denied the request:\n\n ===========================================================================\n Workload Mismatches Found for Allowlist (example-allowlist-1):\n ===========================================================================\n HostNetwork Mismatch: Workload=true, Allowlist=false\n HostPID Mismatch: Workload=true, Allowlist=false\n Volume[0]: data\n - data not found in allowlist. Verify volume with matching name exists in allowlist.\n Container[0]:\n - Envs Mismatch:\n - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.\n - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.\n - Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.\n - SecurityContext:\n - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]\n - VolumeMount[0]: data\n - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.\n\n In this example, the following violations occur:\n - The workload specifies `hostNetwork: true`, but the allowlist doesn't specify `hostNetwork: true`.\n - The workload specifies `hostPID: true`, but the allowlist doesn't specify `hostPID: true`.\n - The workload specifies a volume named `data`, but the allowlist doesn't specify a volume named `data`.\n - The container specifies environment variables named `ENV_VAR1` and `ENV_VAR2`, but the allowlist doesn't specify these environment variables.\n - The container specifies the image `k8s.gcr.io/diff/image`, but the allowlist specifies `k8s.gcr.io/pause2`.\n - The container adds the `SYS_ADMIN` and `SYS_PTRACE` capabilities, but the allowlist doesn't allow adding these capabilities.\n - The container specifies a volume mount named `data`, but the allowlist doesn't specify a volume mount named `data`.\n\nIf you're deploying a workload that's provided by a third-party provider,\nopen an issue with that provider to resolve the violations. Provide the output\nfrom the previous step in the issue.\n\nBugs and feature requests for privileged workloads and allowlists\n-----------------------------------------------------------------\n\nPartners are responsible for creating, developing, and maintaining their\nprivileged workloads and allowlists. If you encounter a bug or have a feature\nrequest for a privileged workload or allowlist, contact the corresponding\npartner.\n\nWhat's next\n-----------\n\n- If you can't find a solution to your problem in the documentation, see\n [Get support](/kubernetes-engine/docs/getting-support) for further help,\n including advice on the following topics:\n\n - Opening a support case by contacting [Cloud Customer Care](/support-hub).\n - Getting support from the community by [asking questions on StackOverflow](http://stackoverflow.com/questions/tagged/google-kubernetes-engine) and using the `google-kubernetes-engine` tag to search for similar issues. You can also join the [`#kubernetes-engine` Slack channel](https://googlecloud-community.slack.com/messages/C0B9GKTKJ/) for more community support.\n - Opening bugs or feature requests by using the [public issue tracker](/support/docs/issue-trackers)."]]
