Have you considered not using DinD? I would look to tools like Kaniko, Buildah, Img, Umochi, FTL, or Bazel.
Here's a good example from the Jenkins Kubernetes plugin that builds containers without using Docker or DinD in Kubernetes.
I've eventually created an umbrella chart with alias:
- name: app
- name: app
And in values.yaml i've changed the needed values,
then added the grafana dashboard in the bundled yaml file.
kubectl get sa --all-namespaces
This will only provide the service accounts.
In general, you can have a comma separated list of resources to display.
kubectl get pods,svc,sa,deployments [-FLAGS]
The FLAGS would apply to all the resources.
This can happen with releases in FAILED state as mentioned by simbo1905 in her/his answer.
Another case is if there's a previously deleted but not purged release with the same name.
Doing another delete with the purge option on the release will free the name for reuse.
helm ls -a
helm ls -a | grep -e NAME -e name_of_release
helm delete --purge ...
Based on the description of your problem, it looks like the solution would be to optimize your testcontainer image:
Double check your base for the testimage. Using something like Alpine for your base image can save a lot of space.
Check what you are baking into your testimage. Your "pre-built static data" should not be included as part of the image (as ...
Static assets should not be in the image, but rather on a PersistentVolume or better yet, on an object store such as AWS S3 then let a CDN to use it.
At the end of the day, Magento is a CMS, so the admin users will change the assets and other part of the content. It is not practical to bake assets these in to an container image doe the nature Magento.
First of all 404 error is resource error in kubernetes. It means your container in the pod is not created by your first script. Even if it is created and you can see it then your labeling is wrong in the second script.
I would suggest you check matchlabels of both YAML scripts. So in your case I can see that matchlabel is docker-registry in the spec ...
You can run your application on a particular node of the cluster by defining it in the application level. For this, you need to add the "placement " parameter in the yaml file and specify the node's name to it, then it will deploy the container on that node.
Secondly, what type of scheduling have you implemented on Swarm CLuster? Let me clear your thought, ...