It's the most common response to anyone who hears the term “Kubernetes” for the first time. If Kubernetes is, quite literally, Greek to you, then this blog post and the corresponding video are two good places to start.
What is Kubernetes?
“You'll hear [Kubernetes] called a lot of different things. You'll hear people say, ‘Well, it's a container scheduler.’ You'll hear people say it's a desired state manager. You'll hear people say it's an orchestrator,” says Brendan. “All these things just basically boil down to it's a system that keeps the system how we want it to be, which sounds kind of crazy. But when we're a software company for software companies, you can relate a little bit.”
So a system that keeps the system how we want it to be, what does that mean exactly?
To understand what Kubernetes is and what it does, it’s best to dig a bit deeper into the origin story of this technology.
The journey to Kubernetes started at Google, when infrastructure developers were searching for a way to deploy new applications on hundreds of thousands of globally distributed servers. The result was Borg, a private tool developed by Google engineers for this purpose. The engineers iterated on Borg to launch Project Seven – an open source project that wasn’t entirely Borg, but took elements of Borg to produce version 1.0 of Kubernetes.
Kubernetes, which translates from Greek to “pilot," “helmsman,” or "governor," is managed by CNCF, a foundation created by Google and Linux to house Kubernetes and other open source computing projects.
The role of containers
Containers are a lightweight technology that lets you securely run an application and its dependencies without impacting other containers or your operating system (OS). This makes containers more nimble and scalable than using other tools for application management, like virtual machines (VMs) or bare metal. Like VMs, containers can repeat the application as it’s in development, but unlike VMs, the container does not duplicate the OS each time and instead shares the infrastructure, container technology (e.g., Docker), and OS with the host computer. Containers are lightweight and easier to run on the cloud because the OS is not duplicated along with the application, but container technology can be challenging to manage without a tool.
“As you get more and more containers… it has a huge advantage technically, but it really creates a mess as to how are we managing all these containers,” says Brendan. “And there’s another problem – bare metal, virtual machines, containers, these all assume to some extent that you know what's going on with the computer that's running them.”
Containers make application deployment simpler, but containers are hard to orchestrate without a tool like Kubernetes.
But orchestrating the various application deployments in containers is a level of abstraction that is difficult for the human mind to grapple with and is challenging to manage manually, which is where Kubernetes comes in.
Kubernetes as scheduler
Kubernetes is an open source container orchestrator that automates container management from deployment to scaling and operating.
There are a few key advantages to using Kubernetes, namely that the technology takes an extremely abstract method of application management – containers – and schedules the deployments to occur automatically.
Brendan mentions other advantages to using Kubernetes, including that is can run routine health checks and is a very self-healing technology. A second key advantage to using Kubernetes for DevOps is that it is a declarative technology at its core. By using the desired state manager, you can describe how you want your application to run and Kubernetes makes it happen.
Core Kubernetes concepts and definitions
- Pod: An abstraction that represents a group of one or more application containers. “The pod is just a unit that says these are the containers that represent the front end website, or these are the containers that represent the payment system,” explains Brendan.
- Node: A worker machine in Kubernetes that may be a VM or a physical machine (e.g., a computer), depending upon the cluster. The node often includes Docker, the pods (“group of containers”), and the VM or computer that includes the OS.
- Cluster: The highest level of abstraction in Kubernetes, it contains all the nodes, pods, and a master – which maintains the desired state of your application by orchestrating the nodes.
- Service: Defines a logical set of pods (e.g., “payment system”) and sets a policy about who can access them. “Pods come and go, but a service is forever,” or so the saying goes, Brendan says. “A pod is going to get scheduled into a node. But if that node went away, the fact that this pod is a member of this service means I've got to go find somewhere else to make a new pod that has this container running in it.” A service allows Kubernetes to route traffic to your application regardless of where the pod is running.
There are plenty of other buzzwords and phrases that are associated with Kubernetes, and Brendan dives into some of them in his presentation (captured in the video below). More concepts are explained on the Kubernetes website at CNCF.
GitLab and Kubernetes
There are three key touchpoints between GitLab and Kubernetes:
- GitLab is an application, so it can be run on Kubernetes. If a GitLab customer is already using a cloud native environment (i.e., containers and Kubernetes), then GitLab the application can be installed in that cloud native environment. We have already set-up Helm Charts, which describe how to install GitLab in a cloud native environment.
- Customers that build their applications in GitLab using CI/CD can deploy to Kubernetes. The Configure team at GitLab works on the integration between GitLab and Kubernetes so developers can deploy their applications automatically to a Kubernetes cluster. The GitLab and Kubernetes integration allows customers to create and dismantle Kubernetes clusters, use review apps, run pipelines, deploy apps, view pod logs, detect and monitor Kubernetes, and much more. The Ops product teams at GitLab are always working to enhance the integration between Kubernetes and GitLab to make Auto DevOps faster and more efficient.
- Moving our production system for GitLab.com to a Kubernetes cluster. We recently moved our giant GitLab.com application from Microsoft Azure to a Google Cloud Platform. A key reason we changed platforms is that we wanted to move our GitLab.com project to a Kubernetes cluster. This project is ongoing but we are making major strides toward continuous deployment using Kubernetes.
But wait, there’s more
If you have more questions, like why the heck Kubernetes is abbreviated to K8s, or are searching for more resources, you’re in luck. Brendan dives into more detail about some of the etymology, key concepts, vocabulary and even pop culture that shapes Kubernetes in his presentation. Watch the video below to learn more about how Kubernetes has been the impetus behind a major shift toward cloud native in the DevOps industry, and why we’re on the front lines of that change here at GitLab.
Kubernetes and the future of cloud native: Sid chats with Kelsey Hightower, Google staff developer advocate about cloud native.
Kubernetes, containers, cloud native – the basics: Get a quick overview of the key Kubernetes concepts.
Kubernetes + GitLab: Explore how GitLab and Kubernetes interact at various touchpoints.