IBM Cloud Container Service Edge Nodes

Share this post:

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.

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


More stories
June 13, 2018

Elinar Takes the Mystery out of GDPR with help from IBM Cloud and Watson

Even though GDPR May 25 deadline has come and gone, many companies are still scrambling to meet compliance. Here at Elinar, we are busier than ever. Our data discover solution, AI Miner, built with Watson APIs, for use on the IBM Cloud platform, can quickly uncover mysterious data with a quick scan on your data mass for records which have privacy settings that need updating to meet GDPR compliance.

Continue reading

May 23, 2018

How to rapidly develop applications with microservices (part 1)

This is the first post in a series on how to move your team towards the best long-term cloud platform adoption decision. Since adopting a cloud platform involves a significant commitment, and implies the confirmation that comes from previous work on one or more pilot projects, the primary goal of this series is to get you to the step of defining an appropriate cloud-based pilot project for your team.

Continue reading

February 12, 2018

A/B testing using App Launch on IBM Cloud Services

Yes, its mobile, mobile everywhere!! Every business aspires to have its own mobile app, hence the need for a mobile app is rapidly growing. To combat the competition, some app owners work hard on innovation, few others on engaging the customers and some try to evaluate their marketing strategies.

Continue reading