Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Problème: le pod ne parvient pas à démarrer l'application et ne peut pas consommer les données montées à partir de l'appareil de sauvegarde/restauration.
Cela est dû aux différences entre les user ID avec lesquels tous les processus d'application s'exécutent sur la machine source (à partir de laquelle les données ont été capturées) et celui avec lequel ils s'exécutent sur le pod.
Solution: Définissez explicitement le contexte de sécurité d'un pod et spécifiez la valeur d'ID utilisateur appropriée pour le champ runAsUser dans le fichier YAML du pod. Par exemple, si l'application MySQL sur l'hôte source a exécuté tous les processus avec l'ID utilisateur 997, il est recommandé de définir le contexte de sécurité du pod pour qu'il utilise le même ID utilisateur 997. Pour ce faire, spécifiez les étapes suivantes dans la section "spec" du fichier YAML du pod.
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/04 (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/04 (UTC)."],[[["\u003cp\u003ePods may fail to start applications and consume mounted data due to discrepancies in user IDs between the source machine and the pod.\u003c/p\u003e\n"],["\u003cp\u003eThe primary cause of the issue is differing user IDs under which application processes run on the source and within the pod.\u003c/p\u003e\n"],["\u003cp\u003eTo resolve this, set the pod's security context explicitly, defining the correct user ID with the \u003ccode\u003erunAsUser\u003c/code\u003e field in the pod's YAML file.\u003c/p\u003e\n"],["\u003cp\u003eIt is recommended to align the \u003ccode\u003erunAsUser\u003c/code\u003e value in the pod's security context with the user ID used by application processes on the source machine.\u003c/p\u003e\n"]]],[],null,["# Troubleshoot container issues\n\n**Issue** : The pod fails to start the application and it is not\nable to consume data mounted from the backup/recovery appliance.\nThis is happening due to the differences in the `user ID`\nwith which all the application processes ran on the\nsource machine---from where the data was captured---and\nthe one with which they are run on the Pod.\n\n**Solution** : Explicitly set the security context for a pod and specify\nthe appropriate user ID value for **runAsUser** field in the\npod's YAML file. For example, if the MySQL application on\nthe source host ran all the processes with the user ID of 997,\nthen it is recommended to set the security context for the pod\nto use the same user ID 997. This could be done by specifying\nthe following steps in the \"spec\" section of the Pod's YAML file.\n\nSee [Configure a Security Context for a Pod or Container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)\nfor more information."]]
