Hello! Today, I’d like to delve deep into the concept of “Infra Node”, a term often heard when studying Kubernetes architecture or working with it in practice.
Typically, when first learning Kubernetes, you only learn about two types: Control Plane (Master) and Worker Node. However, in operations team meetings or architecture design documents, the term Infra Node often pops up.
For those who were surprised, thinking, “Huh? This wasn’t in the book I studied?”, I’ll perfectly clarify the identity and reason for the existence of Infra Nodes. π
1. What exactly is an Infra Node? π€
To get straight to the point, an Infra Node is a “worker node dedicated to running only core tools for cluster management.”
A typical Worker Node is where our developed business applications (Java, Python, Node.js, etc.) run. However, for a Kubernetes cluster to function properly, it requires not only applications but also the following system-level containers:
- Ingress Controller: A gatekeeper that receives and connects external traffic
- Monitoring System: Status monitoring tools like Prometheus, Grafana
- Logging System: Log collection tools like Fluentd, ELK/EFK stack
- Container Registry: Image repositories like Harbor, Quay
These components are like the lifeline of the entire cluster. Therefore, they are kept separate from general applications and are carefully managed (?) by being placed on a “dedicated, isolated node.” This node is precisely what we call an Infra Node.
2. Is it an official Kubernetes term? π
The answer to this question is “partially yes, partially no.”
β Vanilla Kubernetes
There is no official resource type called Infra Node in the official documentation (Docs) or API specifications. Officially, only Control Plane and Worker exist. In other words, in vanilla Kubernetes, an Infra Node is an “architectural design pattern” and a common idiom.
β Red Hat OpenShift
In OpenShift, an enterprise Kubernetes solution, it is an official term. It’s explicitly mentioned in the documentation, and there was even a benefit where Infra Nodes were excluded from billing (Subscription) when calculating license costs. (Varies by version)
π‘ Summary: In practice, regardless of the platform type, a node that isolates managed pods is generally referred to as an Infra Node.
3. Reasons for separating nodes (Advantages) π οΈ
Can’t we just run everything mixed on worker nodes? Of course, you can. However, in large-scale operational environments, separation is strongly recommended for the following reasons:
β Resolving the Noisy Neighbor problem π
Monitoring systems (e.g., Prometheus) consume a lot of memory. What if it’s on the same node as a business application, and the node goes down due to a surge in app traffic? A catastrophe occurs where both the app dies and the monitoring system meant to watch it also dies. Separating into an Infra Node can prevent such resource interference.
β‘ Security and Network Isolation π‘οΈ
The Ingress Controller (Router), which is the first to receive external user traffic, is security-sensitive. It becomes much easier to configure a security architecture where only Infra Nodes are connected to the Public Network (DMZ), and worker nodes containing actual data are hidden deep within the Private Network.
β’ Cost Optimization π°
As mentioned earlier, some commercial solutions (like OpenShift) may waive license fees for Infra Nodes that do not run business logic.
4. How is it implemented? (Technical principles) βοΈ
There is no node that is inherently designated as an “Infra Node” from birth. It is created post-hoc by applying Labels and Taints to a regular worker node.
Step 1. Apply a Label (Name Tag)
# Assign infra role to a specific node
kubectl label node worker-node-01 node-role.kubernetes.io/infra=Step 2. Set a Taint (Access Control) This prevents regular application pods from being scheduled on this node.
# No regular pods on infra nodes!
kubectl taint nodes worker-node-01 node-role.kubernetes.io/infra:NoScheduleStep 3. Configure Pod Deployment (Issue Access Pass) Add tolerations (access pass) and nodeSelector (assigned seat) to the Ingress or Monitoring pod yaml file to ensure they are placed only on Infra Nodes.
5. Conclusion π
In summary, an Infra Node is an architecture embodying the wisdom of operations to run Kubernetes clusters more stably and securely.
- Small-scale clusters: No need to separate. Master/Worker alone is sufficient.
- Large-scale/Commercial clusters: For stability, actively consider an Infra Node configuration to separate logs, monitoring, ingress, etc.
Now, when you hear the term “Infra Node” anywhere, you don’t have to be flustered; you can confidently show off your knowledge! π
Leave a Reply