Статус Pod как "CreateContainerConfigError" в кластере Minikube

Я пытаюсь запустить сервис Sonarqube используя следующую схему рулевого управления.

Таким образом, установка похожа на запуск службы MySQL и Sonarqube в кластере minikube, а служба Sonarqube связывается со службой MySQL для сброса данных.

Когда я выполняю helm install а затем kubectl get pods я вижу состояние pod MySQL как running, но Sonarqube pos Sonarqube отображается как CreateContainerConfigError. Я считаю, что это связано с монтажным объемом штука: ссылка. Хотя я не совсем уверен, как это исправить (довольно новое в среде Kubernetes и до изучения :))

Ответ 1

Я сам столкнулся с этой проблемой сегодня, когда пытался создать секреты и использовать их в своем файле yaml для определения модуля. Было бы kubectl get secrets если вы проверяете выходные данные kubectl get secrets и kubectl get configmaps если используете какой-либо из них, и проверяете, правильно ли указано количество требуемых элементов данных.

Я понял, что в моем случае проблема заключалась в том, что когда мы создавали секреты с несколькими элементами данных: выходные данные kubectl get secrets <secret_name> содержали только 1 элемент данных, в то время как я указал 2 элемента в моем secret_name_definition.yaml. Это из-за разницы между использованием kubectl create -f secret_name_definition.yaml против kubectl create secret <secret_name> --from-file=secret_name_definition.yaml Разница в том, что в случае с первым все все элементы перечисленные в разделе данных yaml будут рассматриваться как пары ключ-значение, и, следовательно, количество элементов будет отображаться как правильный вывод при выполнении запроса с использованием kubectl get secrets secret_name но в случае последнего только первый элемент данных в secret_name_definition.yaml будет оцениваться для пар ключ-значение, и, следовательно, выходные данные kubectl get secrets secret_name будут показывать только 1 элемент данных, и это происходит, когда мы видим ошибку "CreateContainerConfigError".

Обратите внимание, что эта проблема не возникнет, если мы используем kubectl create secret <secret_name> с параметрами --from-literal= потому что тогда нам придется использовать префикс --from-literal= для каждого значения ключа пара, которую мы хотим определить.

Аналогично, если мы используем --from-file=, нам все равно придется указывать префикс несколько раз, по одному для каждой пары ключ-значение, но только для того, чтобы мы могли передать необработанное значение ключа, когда мы use --from-literal и закодированная форма (т.е. значением ключа теперь будет echo raw_value | base64 этого значения в качестве значения при использовании --from-file.

Например, допустим, что ключами являются "имя пользователя" и "пароль", если при создании секрета с помощью команды kubectl create -f secret_definition.yaml нам необходимо иметь значения для "имени пользователя" и "пароля", закодированные, как указано в Раздел "Создать секрет" https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/

Я хотел бы выделить раздел " Примечание: " в https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/ Также https://kubernetes.io/docs/понятия/конфигурация/секрет/ имеет очень четкое объяснение создания секретов

Также убедитесь, что для deploy.yaml теперь есть правильное определение для этого контейнера:

      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]

Как цитировали другие, " kubectl describe pods pod_name " помогло бы, но в моем случае я только понял, что контейнер не создавался в первую очередь, и вывод " kubectl logs pod_name -c container_name " не сильно помог.

Ответ 2

Недавно я столкнулся с той же ошибкой CreateContainerConfigError и после небольшой отладки я обнаружил, что это произошло потому, что я использовал секрет kubernetes в моем yaml развертывания, который на самом деле не присутствовал/не создавался в том пространстве имен, где создавались модули.

Также после прочтения предыдущего ответа, я думаю, можно быть уверенным, что эта конкретная ошибка сосредоточена вокруг секретов kubernetes!

Ответ 3

Это может быть решено различными способами, я предлагаю лучше перейти к kubectl describe pod podname имя kubectl describe pod podname, теперь вы можете увидеть причину kubectl describe pod podname службы, которую вы пытались. В моем случае я обнаружил, что некоторые из моих значений ключей отсутствовали в configmap при выполнении развертывания.

Ответ 4

Я также столкнулся с этой проблемой, и проблема была из-за переменной среды, использующей поле ref на контроллере. Другой контроллер и рабочий смогли разрешить ссылку. У нас не было времени, чтобы найти причину проблемы и привести к разрушению кластера и его восстановлению.

          - name: DD_KUBERNETES_KUBELET_HOST
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
Apr 02 16:35:46 ip-10-30-45-105.ec2.internal sh[1270]: E0402 16:35:46.502567    1270 pod_workers.go:186] Error syncing pod 3eab4618-5564-11e9-a980-12a32bf6e6c0 ("datadog-datadog-spn8j_monitoring(3eab4618-5564-11e9-a980-12a32bf6e6c0)"), skipping: failed to "StartContainer" for "datadog" with CreateContainerConfigError: "host IP unknown; known addresses: [{Hostname ip-10-30-45-105.ec2.internal}]"

Ответ 5

Проверьте свои secrets и config maps (kubectl get [secrets|configmaps]), которые уже существуют и правильно указаны в файле дескриптора YAML, в обоих случаях неправильный секрет/файл конфигурации (не создан, неправильно введен и т.д.) CreateContainerConfigError.

Как уже указывалось в ответах, можно проверить ошибку с помощью kubectl describe pod [pod name] и что-то вроде этого должно появиться в нижней части вывода:

  Warning  Failed     85s (x12 over 3m37s)  kubelet, gke-****-default-pool-300d3c89-9jkz
  Error: configmaps "config-map-1" not found

Ответ 6

Попробуйте использовать опцию --from-env-file вместо --from-file и посмотреть, исчезнет ли эта проблема. Я получил ту же ошибку и, просматривая события pod, предположил, что пары ключ-значение внутри файла mysecrets.txt не читаются должным образом. Если у вас есть только одна строка, Kubernetes принимает содержимое файла как значение, а имя файла - как ключ. Чтобы избежать этой проблемы, вам нужно прочитать файл как переменные окружения, как показано ниже.

mysecrets.txt:

MYSQL_PASSWORD=dfsdfsdfkhk

Например:

kubectl create secret generic secret-name --from-env-file=mysecrets.txt
kubectl create configmap generic configmap-name --from-env-file=myconfigs.txt