My company has been running Kuberenetes for over a year now and GitLab for about 6 months. We recently upgrade to GitLab 9.x and are having trouble trying to figure out what's up with the decision around the CI + app configuration with Kube. This feature is awesome and would love to get it working in our environment.
It seems as though GitLab is expecting you to only have one cluster setup with all of your environments inside of that one cluster broken up by namespace which would equal your service/application and app which would equal your environment. This is what it looks like GitLab wants my Kuberenetes environment to look like, a single cluster with your service broken up into namespaces:
namespace = hello-world
app = development
app = qa
app = production
where in a real world example we would prefer to have the opposite which would work well with a single cluster as well
DEVELOPMENT CLUSTER
namespace = development
app = hello-world
QA CLUSTER
namespace = qa
app = hello-world
PRODUCTION CLUSTER
namespace = production
app = hello-world
Having the namespace be the application and the apps be the environment, we wouldn't have the ability to upgrade to the latest version of kube without upgrading all. Maybe I'm missing something but based on what I'm reading and after testing this out, it looks as though this was the way it was designed.
For reference this is what my CI looks like right now to make the deploy board + terminal happy
development:
<<: *deploy_definition
stage: development
environment: hello-world
script:
deploy.sh -a "hello-world"
but it should look like this
development:
<<: *deploy_definition
stage: development
environment: development
script:
deploy.sh -a "hello-world"
To add to this confusion, they give you only one Kubernetes master to connect to in the integrations tab.
Is this correct, or am I missing something?
Access GitLab Kubernetes Integration Page by clicking on the ”Kubernetes” menu for groups and Operations > Kubernetes menu for projects and click the “Add Kubernetes Cluster” button. Select “Amazon EKS” in the options provided under the “Create new cluster on EKS” tab.
First, declare a new Namespace called gitlab-runner. After we create the new Namespace, we add the authentication roles to the Kubernetes cluster for the Runner. Below are the ServiceAccount, Role, and RoleBinding for the Runner. Copy this configuration into a file called gitlab-runner-service-account.
GitLab Runner can be installed on Linux, macOS and Windows. For our sample project, a small server instance with 1 GB RAM should be enough. In addition, since we will be running with the Docker executor, we also need to have Docker Engine installed.
You're correct. I found it frustrating too.
But you can use environments even without their kubernetes integration
development:
<<: *deploy_definition
stage: development
environment:
name: development
url: https://development.yourdomain.com
script:
deploy.sh -a "hello-world"
Check out the post I wrote recently about the configuration of auto deploy to kubernetes from gitlab.
http://blog.lwolf.org/post/how-to-create-ci-cd-pipeline-with-autodeploy-k8s-gitlab-helm/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With