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
Approach you are describing - where app version is substituted at helm upgrade command - is pretty popular as well. Maybe it's not well documented - I'm not sure about that.
Yet another approach that people use is doing helm template which would compile everything (including variable resolution) into fixed k8s definitions and then doing GitOps on that.
...
2
So, I actually ended up with the following strategy.
I separated the charts from the source code. Basically, I have a repository that tracks all the helm charts only
Why?
I wanted to have a repository representing my cluster(s) so it's easy to rebuild a cluster from it
I also wanted to keep track of the current version deployed. Basically, this repository ...
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
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
The error you are getting is from your Kubernetes cluster being unable to pull container image from GitLab.
Providing a temporary credential to pull the containers as deploy time is not a great solution. For example, say your Kubernetes cluster needs to scale up by adding another node, the node will come up and try and pull the container, but the secret will ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
