Question
Unable to deploy to Digital Ocean Kubernetes using GitLab CI
- Posted on July 2, 2019
- DigitalOceanKubernetes
Asked by Remco Haszing
I’m moving my review apps from Google Kubernetes to Digital Ocean Kubernetes.
I have succesfully linked the Kubernetes clusted to GitLab. I have installed Helm Tiller, Ingress, Cert-Manager, and Prometheus using the GitLab integration. I have upgraded Tiller to the latest version manually, as did I on the previous Google cluster.
The cluster is RBAC-enabled,GitLab-managed, configured to use the default namespace, and tied to the * wildcard environment scope.
Now my deployments are failing. job output
$ helm upgrade "$CI_ENVIRONMENT_SLUG" config/charts/appsemble-docs --atomic --install --set "git.commit.sha=$CI_COMMIT_SHA" --set "image.tag=$CI_COMMIT_REF_NAME"
Error: pods is forbidden: User "system:serviceaccount:default:default-service-account" cannot list resource "pods" in API group "" in the namespace "gitlab-managed-apps"
Manual deployments on my own laptop work fine.
What could be causing this issue?
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Featured on Community
Get our biweekly newsletter
Sign up for Infrastructure as a Newsletter.
Hollie's Hub for Good
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Become a contributor
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Hi there,
This looks like an RBAC permissions issue. The error you’re seeing is saying the service-account “default-service-account” in namespace “default” doesnt have access to pods in the ‘gitlab-managed-apps’ namespace.
You can fix this by either creating a role that allows this access then binding the sa to that role witha rolebinding:
See below for examples to achieve something similar:
This will create a role pod-reader that can get, list, and watch pods
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n <namespace to read pods>
Then we will create the rolebinding to associate a serviceaccount to this role that can view pods.
kubectl create rolebinding sa-read-pods --role=pod-reader --user=system:serviceaccount:default:default-service-account -n rbac
Let me know if you have any further questions.
Regards,
John Kwiatkoski Senior Developer Support Engineer