Kubernetes enables all team members to be more involved in the entire development process, automates vital infrastructure tasks, and helps organizations make the best use of computing resources. Whether you write code, manage a team, or handle operations, understanding Kubernetes has become a baseline expectation in modern software delivery.
Priyanka Sharma, then GitLab Director of Technical Evangelism, captured the urgency well: “Kick the tires. See what’s been done in the past and how Kubernetes changes that today. It impacts business in such a fundamental way, and it will help you do your job.”
“Every company is discussing Kubernetes,” she adds, “even if it’s to decide that they won’t use it. Understand it so you have a voice. Like it or not, the conversation is coming.”
The History of Kubernetes
After decades of experience running large-scale workloads internally, Google open-sourced Kubernetes in 2014. The name itself has ancient roots — drawn from the Greek word for “helmsman” or “pilot” — and that meaning is intentional. Kubernetes steers containerized workloads the way a ship’s pilot navigates a vessel through complex conditions.
Sharma describes Kubernetes as “an orchestration layer on top of containers.” To appreciate why that matters, it helps to understand what containers solved first.
What Containers Made Possible
Containers are portable, self-contained units that run consistently across operating systems and cloud environments. They unlocked a set of architectural and operational benefits that were difficult or impossible with traditional monolithic deployments:
- Microservices architecture: Applications can be decomposed into smaller, independently deployable services.
- Agile and continuous delivery: Teams can ship and update individual services without taking down an entire application.
- Infrastructure decoupling: Application logic no longer depends on the specifics of the underlying host environment.
- Resource efficiency: Containers share the host OS kernel, reducing overhead compared to full virtual machines.
Why Container Orchestration Became Necessary
Once an application is broken into dozens — or hundreds — of containers, managing them manually becomes impractical. You need something to schedule containers across nodes, distribute traffic, handle failures, scale up under load, and roll back bad deployments automatically. That is precisely what Kubernetes does.
Kubernetes automates capabilities including:
- Load balancing and service discovery — routing traffic to healthy container instances
- Horizontal scaling — adding or removing container replicas based on demand
- Self-healing — restarting failed containers and rescheduling them away from unhealthy nodes
- Rollouts and rollbacks — deploying new versions gradually and reverting on failure
- Storage orchestration — mounting local or cloud storage automatically
- Secret and configuration management — keeping sensitive data separate from application code
As Sharma puts it: “The more containers and subsections you have, you need something to orchestrate it. Kubernetes lets you move resources up and down in response to traffic. It’s the intelligence you need.”
A Tool for Developers, Built by Developers
Kubernetes was designed with developer experience in mind from the outset — not just as an infrastructure tool for ops teams. Sharma notes: “In my opinion, Kubernetes was different from the start. It was designed for developers to be more involved.”
This matters because several transformative technologies emerged around the same time: public cloud platforms, container runtimes, microservices patterns, and infrastructure-as-code tooling. In many organizations, different teams adopted these tools independently, creating silos. One team had no visibility into what another was doing, making coordination difficult and slowing delivery.
The remedy Sharma and others advocate is a unified, shared toolchain — one that includes Kubernetes — adopted across the entire organization rather than confined to a single team.
“If people use the same toolchain, everyone knows if a team is stalled or if it’s time to arrange for the next phase. You need to know what’s going on to make those decisions,” she explains. “It’s best if everyone is on the same governance model.”
Crucially, Sharma argues that responsibility should not rest only with engineering leadership. Every developer on the team should feel ownership over how Kubernetes is used, not treat it as someone else’s concern. In an era where reliability and security must be built in from the start, shared accountability across roles is essential.
Core Kubernetes Concepts Every Team Member Should Know
You do not need to be a cluster administrator to benefit from understanding Kubernetes fundamentals. Here are the key concepts that appear across most team conversations:
- Pod: The smallest deployable unit in Kubernetes. A pod contains one or more containers that share networking and storage.
- Node: A worker machine (physical or virtual) that runs pods. A cluster is made up of multiple nodes.
- Cluster: A set of nodes managed by a Kubernetes control plane.
- Deployment: A declarative description of the desired state for a set of pod replicas, including how updates should be rolled out.
- Service: An abstraction that exposes a set of pods as a stable network endpoint, handling routing and load balancing.
- Namespace: A way to divide cluster resources between multiple teams or environments (e.g., staging vs. production).
- kubectl: The command-line tool used to interact with a Kubernetes cluster.
Where to Learn More
If you are ready to go deeper on Kubernetes, here are resources worth exploring:
- Kubernetes Fundamentals (Linux Foundation): A structured course covering how to deploy containerized applications and manage resources through the Kubernetes API. The Linux Foundation offers additional Kubernetes courses, including free options through edX.
- KubeCon + CloudNativeCon: The flagship conference for the Kubernetes and cloud-native ecosystem, bringing together practitioners, maintainers, and vendors for sessions, workshops, and networking.
- The official Kubernetes documentation (kubernetes.io): The authoritative reference for concepts, tutorials, tasks, and API documentation — a strong starting point for any role.
- GitLab: Provides integrated Kubernetes support, enabling teams to deploy clusters and manage workloads as part of their CI/CD pipelines.
Sharma recommends that those brand new to the subject start with the evolution of virtual machines and containers before diving into Kubernetes itself. Building that foundation makes the architecture of Kubernetes much easier to reason about.
“At first, Kubernetes can feel daunting and intimidating,” says Sharma, “but you will pick up quickly. There is a community here to support you, people who will get on a call and answer your questions. Press on and learn. This technology is not going away.”
The Bottom Line
Kubernetes is no longer a niche operations concern. It has become the standard platform for running containerized workloads at scale, and it shapes how modern development teams structure their applications, their pipelines, and their collaboration. Developers who understand Kubernetes — even at a conceptual level — are better equipped to write deployable code, participate in architectural discussions, and contribute to a culture of shared ownership across the delivery lifecycle.