Blog Insights Understand Kubernetes terminology from namespaces to pods
Published on July 30, 2020
5 min read

Understand Kubernetes terminology from namespaces to pods

Kubernetes can be a critical piece of successful DevOps but there's a lot to learn. We explain the terms and share a hands-on demo.


If you're brand new to Kubernetes, you'll want to start with our Kubernetes 101 guide.

Kubernetes and containers are often seen as two key elements in a successful DevOps practice. But there's no question that Kubernetes can be intimidating to those not familiar with it. In fact, our 2020 Global DevSecOps Survey found just 38% of respondents are actively using Kubernetes today while 50% are not. Anecdotally though, interest in Kubernetes is very high:

"We are on the path to get our monolithic server into a sert of microservices and the goal is to use Kubernetes to help on this side."

"We're trying to get there."

"It's a priority for our platform team."

This past spring staff distribution engineer Jason Plum and senior distribution engineer Gerard Hickey walked attendees at GitLab's company-wide meeting Contribute through something they called Kubernetes 102 that looked at the practical building blocks required for a cloud-native application on Kubernetes. As Jason puts it in the video, "what we're trying to do here is to not just say, 'Look at all the magic we do' but actually explain the things we're doing right." Although this was a "laptops out" demo, here's a look at the key concepts and Kubernetes terminology you'll need to understand followed by a link to the entire presentation if you'd like to dive right in.

Start with containers

A container is not a jail, but a jail is a container, Jason explains. "A container is a way of packaging an application so that it is portable. It's contained, hence (the term) 'container' and it's immutable. It's the runtime requirements to actually execute and package that up in an immutable form that you can hand to someone."

But containers can have a tendency to get out of hand so you need something to help keep track. That's where Kubernetes comes in, Jason says in the presentation. "So what is Kubernetes at a high level? I've seen orchestrator, I've seen management system and I've seen coordinator. Kubernetes is all of those things."

Kubernetes weaves both containers and software-defined networking together, creating "a platform you can deploy onto with a clear syntax," Jason says. "That syntax is replicable and not vendor bound so that you can deploy it anywhere that supports the official behaviors. Its job is to start containers, keep them running and make sure they're still running. That's what its job is really about."

Unpacking the moving parts

If you want to get more familiar with Kubernetes, it helps to understand the unique terminology, Jason stresses. Here are key terms that will help to explain the processes involved in running Kubernetes:

Namespaces: In Kubernetes, the namespaces is effectively your working area. It's like a project in GCP or a similar thing in AWS.

Pods: A pod is effectively a unit of work. It is a way to describe a series of containers, the volumes they might share, and interconnections that those containers within the pod may need. You can have a pod that has a single container in it (or more than one container). Pods are flexible, too: Update one and it becomes version two, and version one is taken out, giving you a rolling update. As Jason spells out, "It gives us a way to say, 'I always want to have three and still be able to migrate an application live from one version to another version without having downtime.'

Service: Kubernetes "has a concept of a service," Jason says. "It can be thought of as like a load balancer for pods. It knows which pods are alive, healthy, and ready to respond so that when we try to access whatever pod we want to get to instead of to connect to the deployment and getting the one we get, and then always asking that pod for work."

Ingress: This works with the service to make sure everything ends up in the right place. Ingress can also provide load balancing.

ConfigMaps: This is an API object for storing information in key-value pairs. "A ConfigMap is very useful for doing things like pre-stashing environment variables or files that can actually be mounted directly into pods without actually having to have an actual file system somewhere," Jason says, adding that they're not meant for confidential data.

Secrets: Secrets are an object and a place to store confidential information as the name implies.

Now that you have the Kubernetes terminology down, watch the entire presentation here:

Read more about Kubernetes:

Cover image by Matti Johnson on Unsplash

Read more on Kubernetes:

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert