How-tos

Anti-affinity and IP Binding in IBM Containers Groups

Share this post:

As of May 23rd IBM Bluemix Container Service now provides a native Kubernetes operations experience while removing the burden of maintaining master nodes. Kubernetes itself is based on the Docker engine for managing software images and instantiating containers. Get the details.

Anti-affinity is a relatively new concept to IBM Containers . To define this concept, I’ll begin by describing it in the larger context of comparing containers to groups, and I’ll also provide an example of binding an IP to a group (as this is done differently for groups than containers).

Containers are great for rapid deployment, component reuse, sharing, and preventing compatibility issues. However, containers are ephemeral, and you are not meant to rely on the continued persistence of any one container.

For your service to be both long-running and highly available, IBM Containers provides container groups. A container group is a set of containers all created from the same image that can be managed as a single entity. In addition, the number of containers in the group can be scaled up or down based on the current demand on your service.

Let’s talk about the command-line flags that are unique to creating a container group:

  • Number of containers (–desired, –max, –min): The desired (–desired) flag sets the default number of containers your group will have, and max and min (–max, –min) set the limits to which the group can be scaled up or down. The default values are desired=2, max=2, min=1.
  • Auto-recovery (–auto): Auto-recovery (–auto) causes the IBM Containers service to regularly check that each container in the group is running. If a container is not running it is deleted and another container is started in its place. Auto-recovery is not turned on unless the –auto flag is included on the group create.
  • Anti-affinity (–anti): Anti-affinity (–anti) ensures that no two containers in your group reside on the same physical machine. You might think of it as anti-colocation. This forced distribution limits the impact in the group if a problem were to occur with a particular compute node. The remaining containers in your group will be unaffected. Anti-affinity is strictly enforced, so you will be unable to create a group with anti-affinity that has or could have more containers than the number of available compute nodes. Just as with auto-recovery, anti-affinity will only be enabled if the –anti flag is present on the group create.

Now, here’s an example of how you can create a container with anti-affinity and bind an IP address. Just as with individual containers, you must first obtain the IP address.


$ cf ic ip request
OK
The IP address "169.44.13.11" was obtained.

You then bind the IP address to the group by specifying –ip IP_ADDRESS on the group create. Because we want anti-affinity we will also provide the –anti flag. I’m going to include the size flags I described earlier, and I’m going to avoid including the –auto flag to demonstrate that anti-affinity and auto-recovery can be controlled independently.


$ cf ic group create --name libertygrp --ip 169.44.13.11 -p 9080 --anti --max 5 --desired 3 --min 2 registry.ng.bluemix.net/ibmliberty:latest
OK
The container group creation was requested.
The container group "libertygrp" (id: 3b6b1ffc-1ac5-4339-999e-44fee4dfa252) was created.
Minimum container instances: 2
Maximum container instances: 5
Desired container instances: 3

The binding is reflected in the ip list.


cf ic ip list
Number of allocated public IP addresses: 1
Listing IP addresses in current space...
IP Address          Container/Group ID
169.44.13.11 3b6b1ffc-1ac5-4339-999e-44fee4dfa252

And each of the selections we made (or didn’t make) is reflected in the group select.


$ cf ic group inspect libertygrp
{

“AntiAffinity”: true,
“Autorecovery”: false,

“Id”: “3b6b1ffc-1ac5-4339-999e-44fee4dfa252”,

“Loadbalancer”: {

“intermediate_ip_address”: “169.44.13.11”

},

“Name”: “libertygrp”,
“NumberInstances”: {

“CurrentSize”: 3,
“Desired”: 3,
“Max”: 5,
“Min”: 2

},
“Port”: 9080,

}

Discover more about IBM Containers and try it out for yourself by registering for the 30-day Bluemix trial below.

More How-tos stories
May 3, 2019

Kubernetes Tutorials: 5 Ways to Get You Building Fast

Ready to start working with Kubernetes? Want to build your Kubernetes skills? The five tutorials in this post will teach you everything you need to know about how to manage your containerized apps with Kubernetes.

Continue reading

May 3, 2019

Using Portworx to Deploy and Manage an HA MySQL Cluster on IBM Cloud Kubernetes Service

This tutorial is a walkthrough of the steps involved in deploying and managing a highly available MySQL cluster on IBM Cloud Kubernetes Service.

Continue reading

May 2, 2019

Kubernetes v1.14.1 Now Available in IBM Cloud Kubernetes Service

We are excited to announce the availability of Kubernetes v1.14.1 for your clusters that are running in IBM Cloud Kubernetes Service. IBM Cloud Kubernetes Service continues to be the first public managed Kubernetes service to support the latest upstream versions from the community.

Continue reading