Building a Continuous Deployment Pipeline Using LKE (Part 1): Get Ready
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
The goal of this series is to set up a continuous deployment pipeline for a Kubernetes app on a Kubernetes cluster. This introduction will cover what to expect, the prerequisite knowledge, and the software/components that are required.
Navigate the Series
- Main guide: Building a Continuous Deployment Pipeline Using LKE
- Next section: Part 2: Sample Application
Here’s a copy of the text contained within this section of the presentation. A link to the source file can be found within each slide of the presentation. Some formatting may have been changed.
- We’re going to set up a whole Continuous Deployment pipeline
- … for Kubernetes apps
- … on a Kubernetes cluster
- Ingredients: cert-manager, GitLab, Helm, Linode DNS, LKE, Traefik
- “Do one thing, do it well”
- … But a CD pipeline is a complex system with interconnected parts!
- GitLab is no exception to that rule
- Let’s have a look at its components!
- GitLab dependencies listed in the GitLab official Helm chart
- External dependencies:
shared-secrets(these dependencies correspond to external charts not created by GitLab)
- Internal dependencies:
webservice(these dependencies correspond to sub-charts embedded in the GitLab chart)
- Use the GitLab chart to deploy everything that is specific to GitLab
- Deploy cluster-wide components separately (cert-manager, ExternalDNS, Ingress Controller…)
What we’re going to do
- Spin up an LKE cluster
- Run a simple test app
- Install a few extras (the cluster-wide components mentioned earlier)
- Set up GitLab
- Push an app with a CD pipeline to GitLab
What you need to know
- If you just want to follow along and watch…
- container basics (what’s an image, what’s a container…)
- Kubernetes basics (what are Deployments, Namespaces, Pods, Services)
- If you want to run this on your own Kubernetes cluster…
- intermediate Kubernetes concepts (annotations, Ingresses)
- Helm basic concepts (how to install/upgrade releases; how to set “values”)
- basic Kubernetes troubleshooting commands (view logs, events)
- There will be a lot of explanations and reminders along the way
What you need to have
If you want to run this on your own…
- A Linode account
- A domain name that you will point to Linode DNS (I got
- Local tools to control your Kubernetes cluster:
- Patience, as many operations will require us to wait a few minutes!
Do I really need a Linode account?
- Can I use a local cluster, e.g. with Minikube? It will be very difficult to get valid TLS certs with a local cluster. Also, GitLab needs quite a bit of resources.
- Can I use another Kubernetes provider? You certainly can: Kubernetes is a standard platform! But you’ll have to adjust a few things. (I’ll try my best to tell you what as we go along.)
Why do I need a domain name?
- Because accessing
gitlab.cloudnative.partyis easier than 22.214.171.124
- Because we’ll need TLS certificates (and it’s very easy to obtain certs with Let’s Encrypt when we have a domain)
- We’ll illustrate automatic DNS configuration with ExternalDNS, too! (Kubernetes will automatically create DNS entries in our domain)
Here are a few tools that I like…
- linode-cli to manage Linode resources from the command line
- stern to comfortably view logs of Kubernetes pods
- k9s to manage Kubernetes resources with that retro BBS look and feel 😎
- kube-ps1 to keep track of which Kubernetes cluster and namespace we’re working on
- kubectx to easily switch between clusters, contexts, and namespaces
This page was originally published on