Weaveworks 2022.03 release featuring Magalix PaC | Learn more
Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
In a homogeneous Kubernetes environment, where every node is running the same hardware and operating system, your workloads will be scheduled wherever resources are available. Aside from your master nodes, there won’t be anything else differentiating between your nodes. This might be suitable at first, but not every pod will be created equally.
This is why Kubernetes and Magalix recommend labeling your nodes, preferably when you are provisioning them so when the time comes, you are already set.
Your workloads will get more complex over time. Scenarios you could run into include:
In addition to these scenarios, some organizations run both Windows and Linux servers. It’s quite possible that your handful of Windows Server 2019 servers all have 32GB of RAM, while your Linux machines range from 4GB to 8GB of RAM. Mix in the fact that some of your containers need to runAsUser, and you are looking at some complex scheduling since Windows does not yet support that feature.
Provisioning and managing these nodes without any sort of grouping won’t allow you to support any of these types of scenarios. You may even end up in a scenario where even though your total amount of resources are adequate for all of your workloads, they remain paused while you provision new nodes for additional resources.
Let’s take the following example of a cluster in AWS:
Our cluster doesn’t use node labels. Instead, we allow Kuberentes to manage the scheduling for us. You can see that ServiceA doesn’t have enough hardware resources to get scheduled, forcing you to provision another node with at least 8GB of RAM and 2 vCPUs. This leaves you with an existing server sitting there idly, adding costs for no reason at all.
With 3 available nodes, the problem seems reasonably manageable. A brute force method would be to juggle your pods by killing them off, until each lands on the node that it’s supposed to. I’m sure if you deployed in a certain order, things would be just fine. But, what happens if nodes become unavailable, or pods restart? If something were to cause your services to come up in a different order, you’ll be back at square one. Double the number of different services, all with different requirements and this type of juggling will end up in chaos, leaving you no choice but to add more nodes to work around the issue.
These are the situations when node labels play a crucial role. They are important enough that Kuberenetes advises adding well-known labels to your nodes. Based on the official Kubernetes documentation, we decided to implement our very own KubeAdvisor policies to ensure we are labelling our nodes appropriately, at all times, across all clusters. Revisiting our example, we labelled our nodes with the recommended node.kubernetes.io/instance-type and used nodeSelector in our deployments to select the right labels.
Maintaining consistency is a key factor in governing your Kubernetes clusters. Because of this, KubeAdvisor ships with node label policies out of the box. In anticipation of growth, we want to ensure your nodes are properly labeled so when it comes time to carve out resources for your cluster, or perform any other type of node organization, we have you covered.
More workloads will require more resources. Whether you’re scaling your nodes vertically or horizontally, organizing your nodes soon becomes a necessity. Keeping your nodes consistent is an ongoing process and may not be top of mind when situations call for rapidly expanding your server count. Although our example leverages the node.kubernetes.io/instance-type label, our policies also cover a node’s architecture type, operating system, role, and zone. Additionally, extend your governance reach by creating your own set of labels policies to meet your specific standards. Check out KubeAdvisor today to see our latest policies.
If you haven’t stumbled upon our other articles, read up on our complementary article about how Owner labels help your teams support each other.
Self-service developer platform is all about creating a frictionless development process, boosting developer velocity, and increasing developer autonomy. Learn more about self-service platforms and why it’s important.
Explore how you can get started with GitOps using Weave GitOps products: Weave GitOps Core and Weave GitOps Enterprise. Read more.
More and more businesses are adopting GitOps. Learn about the 5 reasons why GitOps is important for businesses.
Implement the proper governance and operational excellence in your Kubernetes clusters.
Comments and Responses