The GitLab + Google Kubernetes Engine integration's versatility speeds up software development and delivery while maintaining security and scale, allowing developers to focus on building apps instead of managing infrastructure. William Chia, Senior Product Marketing Manager at GitLab, and guest speaker William Denniss, Product Manager at Google, recently met to discuss the benefits of the integration.
- What is the GitLab GKE integration?
- What's in the webcast?
- Watch the recording
- Key takeaways
- Webcast Q&A
What is the GitLab GKE integration?
With our native Google Kubernetes Engine integration, you can automatically spin up a cluster to deploy applications, with just a few clicks. Simply connect your Google account, enter a few details, and GitLab will create the clusters for you. The clusters are fully managed by Google and run on Google Cloud Platform’s best-in-class infrastructure.
What's in the webcast
William Chia, Senior Product Marketing Manager at GitLab, and William Denniss, Product Manager at Google, explain how to deploy applications at scale using GKE and GitLab’s robust Auto DevOps capabilities.
We start with a crash course in Kubernetes, examining containers and deployment, before taking a closer look at the Google Kubernetes Engine integration and seeing it in action.
Watch the recording
Key takeaways
A seamless collaboration
Using GitLab with GKE creates an environment in which you just need to merge your code, and GitLab does all the rest. - William Chia, GitLab Senior Product Marketing Manager
Kubernetes for success
If you go with Kubernetes, it gives you a good start. You can hit a button and configure GKE to do it for you and scale massively when you need to. It really sets you up for success. GitLab is a really great way to get started with Kubernetes, because it sets up everything nicely for you in an automated way. - William Denniss, Google Product Manager
Webcast Q&A
During the webcast, live participants chatted in questions to the team. Here are some of the answers that were given via chat along with several questions we didn’t get a chance to answer during the webcast.
Does Kubernetes have a built-in load balancer?
It does have support for load balancing across pods within a service. You may also need an external load balancer, in the event you have multiple nodes. Creating a Kubernetes Service object and an external load balancer are great first steps.
Is it possible to deploy multiple projects in the same Kubernetes cluster?
It is, you can add the cluster manually to additional projects. We are also working to make this easier in our UI, with support for defining clusters at the group level.
So coming back to the setup of a cluster. If you have a separate environment for development, test, acceptance, and production, it seems we would have multiple options, like multiple clusters, or one cluster with multiple environments. Or even one cluster, one environment and point the correct environment in the
.gitlab-ci.ymlfile (environment page in GitLab). What do you recommend to use to have a nice CI/CD integration and still separate environments?
We support integrating multiple clusters into a single project, and you can define which environments should be deployed to which clusters by using the environment scope.
Is it possible to add several clusters to the same project? To isolate environments based on clusters rather than namespaces.
Yes, this is a feature of GitLab Premium/Silver. (Note: Open source projects on GitLab.com get all of the features of our top-tier plan for free. Public projects on GitLab.com also have this capability.)
Does GitLab support on-demand cluster creation for integration testing for QA environments?
We support the integration of multiple clusters, and you can define which cluster each environment should be deployed to. For example, you can state that all review apps should be deployed into one cluster. If you would like to dynamically create a cluster during a test, you of course can do that as well by scripting that in a job.
Are these features available on GitLab CE?
Cluster integration and the main Auto DevOps functionality are available in Core (CE or EE without a license). Some jobs do require Premium, and they are noted in our Auto DevOps documentation.
The test stages are paid features, right?
Many test jobs are open source features available in Core, and indeed some do require an paid license. The requirements for each job are noted in our Auto DevOps documentation.
What did you mean: “You can run Enterprise Edition without a license?”
GitLab Enterprise Edition uses a license key to grant you access to the features of the Starter, Premium, and Ultimate plans. If you install Enterprise Edition and don’t have a license key, then you will get access to all of the Core features.
Learn more about GitLab's tiers.
Learn if you should use Community Edition or Enterprise Edition.
Is there a free version of GKE for testing and learning?
Every new Google Cloud Platform account receives $300 in credit upon signup. In partnership with Google, GitLab is able to offer an additional $200 for new GCP accounts to get started with GitLab’s GKE Integration. This allows you ample usage to test and learn for free. Visit the Google partner credit page to apply for the $200 additional credit.
I see there is a $200 credit for playing around with GitLab and GKE. Can you elaborate on that? How to receive it, etc... Is it available for personal use or for professional use only? A contact form opens that wants my professional email address.
The $200 partner credit is intended for professional use. You can apply by visiting the Google Cloud Platform partner page and filling out the form. You'll receive an email from the Google team with a key to redeem your credit.
Will Prometheus also gather the metrics without Auto DevOps, for example our own
.gitlab-ci.yml? Or do we need to get something from the DevOps template?
We detect common system services like the NGINX Ingress or Kubernetes CPU/Memory metrics. If you use the NGINX Ingress deployed from GitLab, it is automatically configured for exporting Prometheus metrics. Additional documentation is available in our Prometheus documentation.
Will you also support AWS?
Other providers are certainly items we are considering for future releases, but we started with GKE since we felt it has the best managed Kubernetes experience available today. Other clusters can always be added manually, with just a few extra steps.
What if GitLab is running on GKE itself, can you connect the app to the same Kubernetes cluster GitLab is running on? And how safe is it to run this auto-deployment on your existing Kubernetes clusters/cluster GitLab is running on? Looks as if you could easily waste your cluster with this.
If you’re running GitLab on GKE, you can definitely connect it to the same cluster GitLab is running on to execute your GitLab runners, and as the deployment target for Auto DevOps. I’d advise to use separate namespaces for your GitLab instance to avoid any interference.
Namespaces are the key to achieving workload isolation in Kubernetes; they provide isolation between different deployments to avoid one accidentally influencing the other. If you like (and it’s a bit more configuration), you can even use RBAC to prevent any developer pipelines from ever touching production.
If you want total isolation, then create a separate GCP project, with a separate cluster for production :) This is definitely the best practice for larger deployments.
I have been playing around with the
dependency_scanning/sast/dastjobs, but the images are not cached on the runner. Will they be cached in (near) future or do we need to add any configuration?
We use Docker-in-Docker for most of these jobs, so caching is a bit tricky, and we have an issue tracking this.
What does GitLab use to create the container image?
Auto DevOps uses Herokuish and Heroku buildpacks to automatically detect and build the application into a Docker image. If you add a Dockerfile to your repo, GitLab will use docker build to create a Docker image.
Does the GKE/Kubenetes integration require the GitLab installation to be publicly accessible from the internet? Or will it work just as well if the GitLab server is private?
It does not, but if you deploy a runner to the cluster it will need to be able to access the GitLab server to pick up jobs and do its Git clones.
How does one manage to different
.envfiles for different environments with GitLab CI?
If you define environment variables at the project level, you can specify which ones are available for which environments by following the documentation on limiting environment scopes.
What do I do when I receive this error: “We could not verify that one of your projects on GCP has billing enabled. Please try again.”
Please read the second bullet on the GCP billing on the documentation page, which should help ensure that billing is set up for your account.
Is there a setting to control the number of review apps which are running live at any given time? Worried about cost.
Note that review apps only run on open Merge Requests. If you are using the Auto DevOps template, then once the code is merged, or the MR is closed, the review app shuts down. Today, there’s not a feature to limit the number of review apps, but there are a few options. Review app environments can be manually stopped from both the MR and the environments page. You can also disable review apps altogether.
What are requirements for installing the one-click applications to the cluster?
Helm Tiller, Ingress, Prometheus, and GitLab Runner don't have any special requirements to install via one-click. The integration takes care to ensure the appropriate container images are used and everything is configured properly. The only prerequisite is to install Helm Tiller first (since it is used to install the other applications.) If you install these applications manually to your cluster, you can learn about the requirements for each on their respective documentation pages.
Does this replace solutions like Rancher?
In a nutshell, yes, the GitLab GKE integration provisions and manages clusters on GKE, alleviating the need for Rancher. But this also depends on your needs. You can use GitLab with or without Rancher. For example, if you are using AKS or EKS, then Rancher will provision and manage your cluster automatically, while this requires manual configuration on GitLab.
What is the current state of installing GitLab on Kubernetes?
GitLab has two Helm charts for installing GitLab on Kubernetes – the GitLab-Omnibus chart and the cloud native GitLab chart.
GitLab-Omnibus: The best way to run GitLab on Kubernetes today, suited for small deployments. The chart is in beta and will be deprecated by the cloud native GitLab chart. Cloud native GitLab chart: The next generation GitLab chart, currently in alpha. Will support large deployments with horizontal scaling of individual GitLab components. For more information, please visit the GitLab Helm chart documentation page.
How usable is the new Helm chart for GitLab on Kubernetes?
It is in alpha, and we plan to have a beta available in May/June. We created an issue to note the items we are working to address before beta.
How can I enable Auto DevOps if I have
gitlab-ci.ymlfile already, but for only build and test?
Auto DevOps will use your custom gitlab-ci.yml file if it is present in your repo. If there is no file, then Auto DevOps will use the default Auto DevOps template. You can also see the Auto DevOps template gitlab-ci.yml and use it as a reference to add/update your gitlab-ci.yml. For more information, please visit the customizing .gitlab-ci.yml documentation page.
Have you tried the GitLab + GKE integration? Tweet us @gitlab.
