Hot answers tagged

8

Based on this Github documentation it is possible to pull a docker image from a private docker registry: values.yaml imageCredentials: name: credentials-name registry: private-docker-registry username: user password: pass templates/imagePullSecret.yaml {{- define "imagePullSecret" }} {{- printf "{\"auths\": {\"%s\": {\"auth\": \"%s\"}}}" .Values....


5

Running two tillers does not make it HA. There is an open issue at the moment.


5

Back when Kubernetes announced the new StatefulSet feature with K8s v1.5 (converting it from the old PetSet name), they put out a really good blog post walking through an example of its usage: https://kubernetes.io/blog/2016/12/statefulset-run-scale-stateful-applications-in-kubernetes/ The first paragraph has a really good description of differentiating ...


4

Check https://github.com/helm/helm/issues/3130, this might help. I followed the instruction in the post: kubectl --namespace kube-system create serviceaccount tiller kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller helm init --service-account tiller --upgrade This works for me.


3

Yes this happens frequently when debugging helm releases. The problem happens when a previously failed release is preventing you from updating it. If you run helm ls you should see a release in state FAILED. You might have deleted it in which case it might show up with helm ls -a. Such a release cannot be upgraded using the normal approach of having helm ...


3

ibuildthecloud9 gave me the right hint. Since the github issue doesn't describe how to midify the dns, I figured it out and want to document it here in case someone need to change it, too. It's stored in the configmap coredns as Corefile: proxy . 1.1.1.1 You need to replace this by your dns server (192.168.0.19 in my case). It could be done manually using ...


3

I believe this is an current bug in k3s that upstream DNS is hardcoded to 1.1.1.1. this should be resolved shortly https://github.com/rancher/k3s/issues/53


3

The problem was that nodes, while registered with kubeadm init were providing their private IPs to the cluster master. This caused problems, because master was trying to reach 192.0.*.* addresses which were not resolved as nodes from it's point of view. I needed to edit /etc/systemd/system/kubelet.service.d/10-kubeadm.conf and specify public IP of the node ...


3

You have found a Kubernetes issue #22770, where there is a workaround mentioned here and it goes like follows: What you're experiencing is a known issue with k8s where for some operations it expects to be able to resolve your node names in the global DNS. And suggested a work around would be to: Add entries to /etc/hosts on the master mapping your ...


3

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

Use a docker image within your pipeline that has helm and other tools installed. To quote the docs: Pipeline is designed to easily use Docker images as the execution environment for a single Stage or the entire Pipeline. Meaning that a user can define the tools required for their Pipeline, without having to manually configure agents. Practically ...


2

Helm is a Kubernetes tool so this answer assumes you are deploying to Kubernetes or OpenShift not Docker Swarm. If you are using Helm well then I don't think it is particularly important what build pipeline tech you are using to invoke it. I think what is more important is how you manage all your configuration within Git and how you structure the Helm ...


2

I ended up using stolon for its automatic leader election and fail over handling. Crunchy Data offers small building blocks so there is a lot of work to do to put them all together while stolon has a ready helm chart. But I didn't try patroni since stolon worked just fine.


2

You can use helm get manifest <RELEASE_NAME> to fetch the kubernets manifests and you can use helm get values <RELEASE_NAME> to get the values.yaml from the cluster. But I don't think there is any way to get the chart files back. Sorry. PS: Please replace <RELEASE_NAME> with your release name.


2

You need to add the jenkins user to the docker group: # run the following command as root usermod -aG docker jenkins


2

Just unregister offline runners: As per GitLab Runner commands manual: To delete the old and removed from GitLab runners, execute the following command. gitlab-runner verify --delete You are not alone P.S. The problem is common: there are many issues with questions like yours. Moreover, there are several custom recipes to unregister "offline"...


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

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

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


2

I tend to prefer infra code living separately from application deployment code. Multiple reasons for this: You want your infra team to make infra changes. You want your app team to make application changes (including application configuration). Putting them separately lets you specify separate guard rails on them (for example, only the infra team is ...


1

You can try below options to debug this further. First verify values.yaml and check the values for serviceAccount (default value is true ) that means the helm chart when deployed will create a service account for the deployment. When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the ...


1

Why are you adding the image tag to the pull policy? you dont need it there, just leave it like this: imagePullPolicy: {{ .Values.image.pullPolicy }}


1

I've eventually created an umbrella chart with alias: dependencies: - name: app repository: file://./app version: 1.0.0 alias: child1 - name: app repository: file://./app version: 1.0.0 alias: child2 And in values.yaml i've changed the needed values, then added the grafana dashboard in the bundled yaml file.


1

See my answer here: Ran into this today when trying to use Garden.io for a cluster running in Jelastic. Found the solution in this Github comment: First acquire a local binary for Tiller (server-version of Helm), either by compiling or by downloading it from the release page. Then run: $ export HELM_HOST=":44134" $ tiller -listen ${HELM_HOST} -...


1

A co-worker ended up taking over deploying this a few days ago and managed to get it working. I'm not certain what he did differently, but I know discovered very similar issues I was facing with other Helm charts boiled down to the database they depended on not deploying properly which caused the other components to fail during initialization. Database ...


1

I learned that it's not required to set the ingress class to nginx as I did in kubernetes.io/ingress.class: nginx. All annotations prefixed with nginx.ingress.kubernetes.io apply to the default Kubernetes ingress. Setting the timeouts is also not required. The only important annotation is nginx.ingress.kubernetes.io/proxy-body-size: "0" because the default ...


1

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


1

Okay the answer to this is that you can set spec.serviceAccountName on the dc and the secrets are mounted. Annoyingly the same does not hold true for BuildConfig objects. They have an inconsistently named spec.serviceAccount. Setting that doesn’t mount any secrets associated with the sa. It also means your build isn’t an “image puller” until you explicitly ...


1

By default, tiller stores release information in ConfigMaps in the namespace where it is running. You can refer to the official Helm RBAC documentation for more information on setting up different RBAC scenarios for Tiller. Kubernetes authorizes API requests using the API server. It evaluates all of the request attributes against all policies and allows or ...


1

Finnaly, I found the solution, thanks to @simbo1905. All that I need to fix that problem: values.yaml Child Chart 1 (or two) postgresql: nameOverride: chart-1-postgres In the Child Chart 2 nameOverride became to chart-2-postgres.


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