Generally, a Helm chart would cover all your microservices - ideally, you should be able to deploy whole application in one chart. It may get a little messy if you include external 3rd party dependencies, where you would need to handle dependent charts, but I assume this is out of scope of your question.
More so, if your microservices are very similar you ...
Helm isn't made to be used this way. If you'd prefer to use a static deployment, you're better off using a plain Kubernetes manifest. Then, people changing the image field won't break your release.
You can easily convert it to one simply by running helm get manifest command
Helm is used to manage release versions. I.e. every new release (and a docker ...
Since the timeout is a Helm option and not a Kubernetes object attribute, it can't be embedded in the chart itself.
The --timeout option is the amount of time the Helm utility will wait for Kubernetes commands to complete before marking the release as FAILED.
More Info on Helm CLI options
I believe what you're asking is: "Is there any way to create just one helm chart that can be used for all microservices in my application?". If so, then you can just use the values.yaml file to store all the values for your templates. This is not considered good practice, considering your template file needs to hold the information for each of your ...
You explained what each does pretty well! I strongly suggest reading the documentation, especially for the commands, don't rely on tutorials only.helm commands helm repo add => This is what it stands for, it adds a new helm chart repository. helm repo update => Update gets the latest information about charts from the respective chart repositories. When ...
If anyone comes across this later I resolved my issue by using an initContainer for any Pod that needed to write to the file system.
- name: app3
args: ["-c", "while true; do echo $(date -u) >> /...
monitor-prometheus-server-5587c7f464-z9tcj 1/2 CrashLoopBackOff
1/2 here means that 1 of 2 containers in the Pod is "Ready"
When you describe the Pod, you see the status of the containers:
You probably need to ...
Yeah, this is what I had in mind all along. Blue/Green Deployments on Kubernetes. So in short, Helm as it stands, is not for me since it doesn't have the concept of a blue/green deployment. With Helm, when you install a new package, the Deployment gets updated with the new Pod versions, but the Service is still pointing to the Deployment. Helm doesn't have ...
Helm charts should not be built for a specific environment, IMHO. You can see that many of the official helm charts have a set of default values and they are configurable from outside. You also can create a helm chart like that and declare your deployment + environment-specific values with another tool like Helm Operator or ArgoCD. In this way, you can both ...