IBM Cloud Container Service Edge Nodes

By: Vinit Jain

IBM Cloud Container Service Edge Nodes

Edge Nodes are being introduced in IBM Cloud Container Service to allow a user to designate certain nodes to act as the edge of the cluster. By designating these Edge Nodes a user can ensure that only these nodes need to be exposed to the public network for the purpose of acting as an entry point to the cluster. When certain nodes are designated as Edge Nodes Kubernetes will schedule the Ingress Controller and Load Balancer to run on the Edge Nodes. Furthermore user’s application pods are not deployed on these nodes. This allows a user to isolate their application pods from the Ingress and Load Balancer workload.

Edge Nodes

How Edge Nodes work ?

Kubernetes uses the concepts of Taints and Labels to implement the Edge Node capability. A user is required to apply specific Taints and Labels to designate a node as an Edge Node. A Taint prevents services that do not tolerate the Taint from running on these nodes. IBM Cloud Container Service ensures that the required control services that need to run on these nodes have the required tolerations so that they will be able to continue being hosted on these nodes. The Taints ensures that the users applications do not get scheduled on these nodes. Services such as Load Balancer and Ingress Controller look for the Edge node label and have a builtin preference to run on Edge nodes when a cluster has Edge nodes.

Rescheduling pods

As Edge Nodes get defined on an existing cluster where both user application pods and IBM Cloud Container Service Load Balancer and Ingress pods may have already been scheduled without any consideration for Edge behavior, it is necessary for a user to take actions to ensure they get rescheduled after the Edge Nodes are defined. Details of how Load Balancer and Ingress Controller are rescheduled are described in the documentation link below.

Network for non-Edge Nodes

Even with Edge nodes, non-Edge nodes have a requirement for outgoing Public network access. This can be accomplished by retaining the Public Network (VLAN) on the non-Edge nodes so that outgoing NAT access is available. Documentation link below describes how additional Network Policies can be applied to block traffic to non-Edge Nodes. When there is no Public Network (VLAN) on the non-Edge nodes, the required outgoing public access can be through a Vyatta Gateway.

Edge Node Documentation

Be the first to hear about news, product updates, and innovation from IBM Cloud