Kubernetes is becoming increasingly widespread, with more companies seeing the advantages it brings. It helps you orchestrate your containers, scale the number of containers running, and make sure they’re evenly spread on the underlying nodes—all while helping to simplify the deployment process.
Clusters are a key part of Kubernetes, as they allow you to split your node pools into multiple different configurations. For example, you can set up a node pool for apps running a web service and another one for your machine-learning apps.
But, clusters can be confusing and difficult to navigate to the Kubernetes novice. Although it’s not strictly necessary to be a cluster expert to use Kubernetes, some basic knowledge helps a lot when you have to set it up, configure it, and maintain it.
What is a cluster?
In short, a cluster is a collection of node pools. While you can have any number of nodes in a single pool, they will all be configured the same. So, one of the main reasons you may want to have more than one node pool can be a need for multiple configurations.
Imagine you have a set of applications running a web service, and another set of applications running machine learning tasks. You don’t want your machine learning applications to run on regular nodes without a GPU, since performance will be hindered. Likewise, you don’t want to run a web service on a node with a GPU, since it’s overpowered and more expensive. With two different node pools–one with a GPU and one without–you can run both of the applications in the same cluster and still only pay for what you need.
Every cluster has to have at least two nodes: a master node and a worker node. These nodes carry different components that make the cluster work. The master node is where you’ll find the API server, the scheduler, and the controller manager. On the worker node, you will find the kubelet, kube-proxy, and the underlying container runtime. These individual components won’t be covered here, as they’re a complete subject in and of themselves.
You can think of a cluster as a sort of logical container. While it is true that the cluster is running on nodes, you should think of it as an abstraction on top of them. When talking about containers in Kubernetes, you often don’t think of it as “running a container on a node,” you think of it as “running a container in a cluster.”
Deploying a cluster
The biggest differentiator for a cluster is whether you deploy it locally or in the cloud. If you plan to deploy it in a cloud, like Azure, GCP, or AWS, things will be relatively straightforward. Most cloud providers guide you through the process and leave you with some sensible defaults for networking and storage.
On the other hand, if you are going to be deploying your own cluster locally, then you have a few more options. It’s possible to set everything up manually from scratch. This is a very valid way to learn the inner workings of Kubernetes, although it’s recommended that you use a purpose-built tool if the intention is to run a production cluster. If you plan to learn, and you don’t want to do everything from scratch, it’s recommended to use something like Minikube or Docker Desktop.
If you plan to set up a production cluster, you can use tools like kubeadm or kubespray. No matter how you deploy your cluster, the knowledge you need to have is pretty much the same. There are some Kubernetes guidelines that all major providers, cloud and local, adhere to. This means that no matter the cluster, your base knowledge is valid.
Clusters in relation to objects
As stated earlier, you refer to containers as “running in a cluster.” This is true for most resources in Kubernetes. Pods, Services, and Ingress all run in the cluster. The cluster is a logical container, wherein you have a control plane taking care of everything. The control plane schedules Pods to run, routes traffic, and handles everything else happening inside a cluster.
Knowing that everything runs in a cluster, it’s important to also be aware of namespaces. A namespace is a logical container, just like a cluster. Any object in Kubernetes lives in a namespace, and so in that way, you can think of a namespace as a little cluster on its own. It’s not a full cluster in that it doesn’t have its own API server, scheduler, etc., but it does provide some separation of concerns.
Cluster management
The way you manage a Kubernetes cluster can vary a bit, depending on how you’ve deployed it. All the external properties, like how many nodes you have, how many outgoing IPs are available, and what type of storage you are running, are all very much dependent on the way your cluster is deployed. But, some things are common across all clusters.
Everything internal is managed the same via kubectl. Since all major Kubernetes providers conform to the same standards, once you get inside the cluster everything will be the same. Although the method of managing a cluster internally will be the same, be aware that the decisions you make will affect things externally. For example, if you set up a Service to use a LoadBalancer, you’ll have to be sure that the underlying infrastructure has a LoadBalancer.
GKE, EKS, and AKS are the most popular managed Kubernetes services. These guides walk users through using each of the major managed offerings:
- Google Kubernetes Engine (GKE), by Google
- Amazon Elastic Kubernetes Service (EKS), by Amazon
- Azure Kubernetes Service (AKS), by Microsoft
Authentication and authorization
Kubernetes expects all communication to the API server to be done over HTTPS. On top of having to communicate over HTTPS, you need to authenticate against the Kubernetes API. It’s recommended that you enable service account tokens and at least one other authentication method. Such an authentication method could be Basic Auth or X509 certs.
If you’re working in a large organization, you may be interested in looking into getting your cluster synchronized with an OIDC or LDAP solution, as a way of enabling SSO in your cluster. If you are deploying your cluster in the cloud, most providers will have a built-in solution ready for you to use.
Once you’ve figured out your authentication method, you also need to make sure users are authorized. This is done through Role-Based Access Control (RBAC). By default, Kubernetes comes with many predefined roles you can assign your users, but you also have the possibility of defining your own roles. This can be useful in cases where you want strict permissions set.
Networking
If you understand basic computer networking, then you are going to get the hang of things quickly in Kubernetes. You can think of a Pod as a Virtual Machine. Every Pod in your cluster will have its own IP address, meaning you don’t have to worry about coordinating ports between applications. Since a single Pod has its own MAC address, containers inside a Pod can talk to each other using localhost. This means that while you don’t have to coordinate ports between Pods, you do have to coordinate ports between containers running in the same Pod.
The above is mostly relevant if you want to communicate between applications within your cluster. If you want to expose your application to the outside world, it does get a bit more complicated. In that case, you want to use Services, which we’ll cover in another post.
This guide, An Introduction to Kubernetes Networking, By Lee Atchison, explores the concept of Kubernetes networking with 10-helpful graphics and examples.
Conclusion
Put simply, a cluster is a logical container for a Kubernetes deployment. It holds the API server, controller manager, scheduler, and all the things that make your applications work. Remember that everything inside Kubernetes is running in a cluster, everything managed via kubectl will always be the same, and that things may change externally depending on how your cluster is deployed.
If you're looking for a solution to help manage your Kubernetes clusters, consider Airplane. Airplane is the developer platform for building internal tools. With Airplane, you can transform scripts, queries, APIs, and more into powerful workflows and UIs. The basic building blocks of Airplane are Tasks, which are operations that anyone on your team can use. Airplane Views is a React-based platform for building custom UIs quickly.
To test it out and build your first cluster management dashboard in minutes, sign up for a free account or book a demo.
