Pod status as `CreateContainerConfigError` in Minikube cluster
Solution 1:
This can be solved by various ways, I suggest better go for kubectl describe pod podname
name, you now might see the cause of why the service that you've been trying is failing. In my case, I've found that some of my key-values were missing from the configmap while doing the deployment.
Solution 2:
I ran into this problem myself today as I was trying to create secrets and using them in my pod definition yaml file. It would help if you check the output of kubectl get secrets
and kubectl get configmaps
if you are using any of them and validate if the # of data items you wanted are listed correctly.
I recognized that in my case problem was that when we create secrets with multiple data items: the output of kubectl get secrets <secret_name>
had only 1 item of data while I had specified 2 items in my secret_name_definition.yaml
. This is because of the difference between using kubectl create -f secret_name_definition.yaml
vs kubectl create secret <secret_name> --from-file=secret_name_definition.yaml
The difference is that in the case of the former, all the items listed in the data section of the yaml will be considered as key-value pairs and hence the # of items will be shown as the correct output when we query using kubectl get secrets secret_name
but in the case of the latter only the first data item in the secret_name_definition.yaml
will be evaluated for the key-value pairs and hence the output of kubectl get secrets secret_name
will show only 1 data item and this is when we see the error "CreateContainerConfigError".
Note that this problem wouldn't occur if we use kubectl create secret <secret_name>
with the options --from-literal=
because then we would have to use the prefix --from-literal=
for every key-value pair we want to define.
Similarly, if we are using --from-file=
option, we still have to specify the prefix multiple times, one for each key-value pair, but just that we can pass the raw value of the key when we use --from-literal
and the encoded form (i.e. value of the key will now be echo raw_value | base64
of it as a value when we use --from-file
.
For example, say the keys are "username" and "password", if creating the secret using the command kubectl create -f secret_definition.yaml
we need to have the values for both "username" and "password" encoded as mentioned in the "Create a Secret" section of https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/
I would like to highlight the "Note:" section in https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/ Also, https://kubernetes.io/docs/concepts/configuration/secret/ has a very clear explanation of creating secrets
Also make sure that the deployment.yaml now has the correct definiton for this container:
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]
As quoted by others, "kubectl describe pods pod_name
" would help but in my case I only understood that the container wasn't being created first of all and the output of "kubectl logs pod_name -c container_name
" didn't help much.
Solution 3:
Recently, I had encountered the same CreateContainerConfigError
error and after little debugging I found out that it was because I was using a kubernetes secret in my Deployment yaml, which was not actually not present/created in that namespace where the pods were getting created.
Also after reading the previous answer I guess this can be assured that this particular error is focused around kubernetes secrets!
Solution 4:
Check your secrets
and config maps
(kubectl get [secrets|configmaps]
) that already exist and are correctly pointed in the YAML descriptor file, in both cases an incorrect secret/configmap (not created, mispelling, etc.) results in CreateContainerConfigError
.
As already pointed in the answers can check the error with kubectl describe pod [pod name]
and something like this should appear at the bottom of the ouput:
Warning Failed 85s (x12 over 3m37s) kubelet, gke-****-default-pool-300d3c89-9jkz
Error: configmaps "config-map-1" not found