4

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 ...


2

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 ...


2

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


2

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 ...


1

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 ...


1

This is not a Helm issue. You are probably trying to update the LabelSelector fields which are immutable. This is expected behaviour as per the kubernetes.


1

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. For example: apiVersion: v1 kind: Pod metadata: name: app3 spec: containers: - name: app3 image: busybox command: ["/bin/sh"] args: ["-c", "while true; do echo $(date -u) >> /...


1

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: Containers: prometheus-server-configmap-reload: Ready: True ... prometheus-server: Ready: False You probably need to ...


1

Managed to solve this by changing the values.yaml in the loki-stack helm chart to the following: promtail: enabled: true pipelineStages: - cri: {} Enjoy.


1

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 ...


1

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible