Kubernetes’ reputation as a powerful platform, especially for cloud-native applications, is deserved. It offers a rich, flexible set of capabilities. This reputation also includes a learning curve that can be steep for beginners, especially if you’re trying to go it your own way with the open source platform.
“Kubernetes is deceptively simple to set up initially, but then rather complex to configure correctly for your needs, for scale, and for security,” says Amir Jerbi, co-founder and CTO at Aqua Security. “As an open source project, it is deliberately rather loosely knit, with a baffling array of options.”
Those options are indeed a part of the orchestration tool’s power: You’ve got robust features at your fingertips, and lots of them. In the long run, Kubernetes can simplify the burden for DevOps teams managing containerized workloads. Without an orchestration platform, containers and microservices can produce a lot of operational overhead. But in the short term, it can feel overwhelming.
[ Get the free eBook: O’Reilly: Kubernetes Operators: Automating the Container Orchestration Platform. ]
Kubernetes architecture: Where to start
“Kubernetes provides a very rich set of abstractions, effectively software primitives, that automate functions for compute, storage, networking, and other infrastructure services,” says Tom Manville, engineering lead at Kasten. “In many ways, developers will have less to think about in those areas, but they’ll need to learn how Kubernetes defines and automates those functions so they invoke the capabilities appropriately.”
“None of the abstractions that exist in Kubernetes today make the underlying systems any easier to understand. They only make them easier to use,” says Chris Short, Red Hat OpenShift principal technical marketing manager. You and your teams should be ready to learn from mistakes, Short notes.
If you’re just getting started, it’s important to understand the basics of Kubernetes architecture and get a feel for some of the kinds of choices you’ll need to make. Grizzled Kubernetes veterans might find this rather elementary, but there are thousands and thousands of IT pros who are still new to the platform. This is a quick primer in the basics of Kubernetes architecture and some other key things to know at the outset.
“In providing those capabilities, Kubernetes has different architecture components that operators will need to learn – the control plane of Kubernetes and those that run on every node,” Manville says. “They’ll [also] need to understand what it takes to secure the master components, including the API server, for example, since that’s where many critical functions are handled.”
Let’s build the basis for that understanding with more expert insights from Manville and others.
[ Why does Kubernetes matter to IT leaders? Learn more about Red Hat's point of view. ]
Kubernetes basics: Nodes and clusters
Kubernetes essentially has a client-server architecture – it’s just that the terminology might be a little different than other systems you’re familiar with. A key concept here is a node: Every Kubernetes cluster includes a master node and at least one worker node. (A cluster will often include multiple worker nodes.)
The master node is essentially the brains of the operation: It controls your desired state, and everything feeds off of it. Worker nodes are physical or virtual machines that run your actual applications and workloads.
[ Kubernetes terminology, demystified: Get our Kubernetes glossary cheat sheet for IT and business leaders. ]
“Kubernetes has two goals: to be a cluster manager and a resource manager,” explains Ravi Lachhman, DevOps evangelist at Harness. “Kubernetes works off a master-to-worker node model, meaning the worker nodes are scalable and disposable. Kubernetes architectures can have varying worker node sizes for different workloads, so the resource manager portion will find an appropriate spot on your cluster for work to be performed.”
There are three key components of the master node: the Kubernetes API server, scheduler, and controller manager. The complete Kubernetes control plane also includes etcd and kubectl. The latter is Kubernetes’ command-line interface for managing a cluster. It’s essentially how you tell your master node what to do.
Worker nodes, meanwhile, include kubelet, kube-proxy, and your container runtime. The official Kubernetes documentation offers a useful diagram showing the relationship between master and worker nodes, including each of these components.
That’s the basic setup of every cluster: One master node and at least one (and possibly many) worker nodes or worker machines, which can be virtual or physical.
Now let's talk about platforms and security choices:
Comments
I love your articles, but why do you split your articles apart like this? It makes no sense. You don't appear to serve ads, so what good is this doing you? It's a bad experience for me as a reader.