web-dev-qa-db-fra.com

Statut du pod en tant que `CreateContainerConfigError` dans le cluster de minikube

J'essaie d'exécuter le service Sonarqube en utilisant le diagramme helm suivant .

Ainsi, la configuration est comme si elle démarrait un service MySQL et Sonarqube dans le cluster de minikube et que le service Sonarqube communique avec le service MySQL pour extraire les données.

Lorsque je fais helm install suivi de kubectl get pods, je vois le statut du pod MySQL sous la forme running, mais le statut Sonarqube pos s'affiche sous la forme CreateContainerConfigError. Je pense que cela a à voir avec le problème du volume de montage: link . Bien que je ne sois pas tout à fait sûr de le résoudre (plutôt nouveau dans l'environnement Kubernetes et jusqu'à l'apprentissage :))

kubernetessonarqubekubernetes-helm
7
Always_Beginner

J'ai moi-même rencontré ce problème aujourd'hui alors que j'essayais de créer des secrets et de les utiliser dans mon fichier yaml de définition de pod. Il serait utile de vérifier la sortie de "kubectl get secrets" et de "kubectl get configmaps" si vous en utilisez un et de valider si le nombre d'éléments de données que vous souhaitez est répertorié correctement.

J'ai reconnu que dans mon cas, le problème était que lorsque nous créons des secrets avec plusieurs éléments de données: la sortie de "kubectl get secrets" ne contenait qu'un seul élément de données, alors que j'avais spécifié 2 éléments dans mon secret_name_definition.yaml. Cela est dû à la différence entre "kubectl create -f nom_du_ secret_définition.yaml" et "kubectl create secret --de_fichier = nom_du_ secret_définition.yaml". La différence est que, dans le cas précédent, tous les éléments répertoriés dans les données la section de yaml sera considérée comme une paire clé-valeur et par conséquent, le nombre d'éléments sera affiché comme la sortie correcte lorsque nous interrogerons à l'aide de "kubectl get secrets nom_ secret" mais, dans le cas de ce dernier, seul le premier élément de données de la définition secret_name .yaml sera évalué pour les paires clé-valeur et, par conséquent, la sortie de "kubectl get secrets nom-secret" ne montrera qu'un élément de données et nous verrons l'erreur "CreateContainerConfigError". Notez que ce problème ne se produirait pas si nous utilisions "kubectl create secret" avec les options "--from-literal =", car il faudrait alors utiliser le préfixe "--from-literal =" pour chaque paire clé-valeur. nous voulons définir. De même, si nous utilisons l'option "--from-file =", nous devons encore spécifier le préfixe plusieurs fois, une pour chaque paire clé-valeur, mais nous pouvons simplement transmettre la valeur brute de la clé lorsque nous utilisons " --from-literal "et la forme encodée (c'est-à-dire que la valeur de la clé sera désormais" echo raw_value | base64 "comme valeur lorsque nous utiliserons" --from-file ".

Par exemple, disons que les clés sont "nom d'utilisateur" et "mot de passe". Si vous créez le secret à l'aide de la commande "kubectl create -f définition_de_ secret" .vous devez "avoir les valeurs pour" nom d'utilisateur "et" mot de passe "codées comme indiqué dans la section "Créer un secret" de https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/

Je voudrais souligner la section "Note:" dans https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/ aussi, https: //kubernetes.io/docs/concepts/configuration/secret/ explique très clairement comment créer des secrets

Assurez-vous également que le fichier deployment.yaml a maintenant la définition correcte pour ce conteneur:

      env:
        - name: DB_Host
          value: 127.0.0.1
        # These secrets are required to start the pod.
        # [START cloudsql_secrets]
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: cloudsql-db-credentials
              key: username
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: cloudsql-db-credentials
              key: password
        # [END cloudsql_secrets]

Comme cité par d’autres, "kubectl décrit les pods nom_ pod" pourrait aider, mais dans mon cas, j’ai seulement compris que le conteneur n’était pas créé en premier lieu et que la sortie de "kubectl logs nom-pod -c nom_conteneur" ne l’a pas beaucoup aidé.

S'il vous plaît laissez-moi savoir si j'étais clair et si cette solution vous a aidé.

9
Madhavi Nori

Récemment, j'avais rencontré la même erreur CreateContainerConfigError et après un petit débogage, j'ai découvert que c'était parce que j'utilisais un kubernetes secret dans mon Deployment yaml, qui n'était pas présent/créé dans cet espace de noms où les pods ont été créés. 

Aussi, après avoir lu la réponse précédente, je suppose que cela peut être assuré que cette erreur particulière est centrée sur les secrets de Kubernetes!

1
garlicFrancium