Compute Services

IBM Cloud Kubernetes Service Deployment Patterns #2: Multi-Zone Cluster—ALB/Ingress Controller

Share this post:

Deployment Patterns #2: Multi-Zone Cluster, App exposed via ALB/Ingress Controller

In my previous post, “IBM Cloud Kubernetes Service: Deployment Patterns for Maximizing Throughput and Availability,” I briefly described a few cluster deployment patterns that should be considered when you are looking to deploy IBM Cloud Kubernetes Service clusters. When choosing the right pattern, you must consider the requirements of the application you are running (including scale), the SLA target, and the budget. In this pattern, you can observe the default behavior of a multi-zone IBM Cloud Kubernetes Service cluster and the application load balancer (ALB).

Example deployment pattern

We are going to go through the steps to deploy an example application with the following deployment pattern:


  1. Sign up and create a multi-zone IKS cluster using the IBM Cloud Console. Please read the documentation on deploying a cluster and specifically how multi-zone clusters work. Important: You have to use the paid tier in order to use ALBs.
  2. Check if everything came up and the ALBs are running fine. You can find useful commands on the IBM Cloud Kubernetes Service Ingress Cheatsheets.
  3. Download, edit, and apply the following example Deployment and Ingress resource yaml, which will expose the echoserver application via the ALB/Ingress controller on both port 80(http) and 443(https):
    $ kubectl apply -f iks_single_or_multi-zone_cluster_app_via_ALB.yaml
    Note: Do not forget to edit theHost and secretName part.

Test the app

  1. To test, load the host you specified in your browser or initiate curlcommands (like my example):
    $ curl
  2. You should see a response similar to the following:
Response to a successful curl delivered via the IKS ALB

Response to a successful curl delivered via the IBM Cloud Kubernetes Service ALB

Notice that in the x-forwarded-for and x-real-ip header, you see the IP address of the worker node. This happens because kube-proxy is doing source NAT within the Kubernetes cluster and masks the original source IP of the client.

If you want to enable source IP preservation, you have to patch the IBM Cloud Kubernetes Service ALB (you can find further documentation about this step here). To set up source IP preservation for all public ALBs in your cluster, run the following command:

$ kubectl get svc -n kube-system |grep alb | awk '{print $1}' |grep "^public" |while read alb; do kubectl patch svc $alb -n kube-system -p '{"spec": {"externalTrafficPolicy":"Local"}}'; done

Once the patch is applied, you will see the original source IP address of the client showing up in the x-forwarded-for and x-real-ip header:

Finding the right pattern

As you learn more about your workload, you can adjust and even switch between patterns as needed. Different applications will require different patterns; please let us help you decide which is right!

You can learn more about the various deployment patterns in the following posts:

Contact us

If you have questions, engage our team via Slack by registering here and joining the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.

Chief Architect, Networking – IBM Cloud Kubernetes Service

More Compute Services stories
March 21, 2019

VIDEO – What is a GPU?

In this video, Alex Hudak covers the basics of GPUs, including the differences between a GPU and CPU, the top GPU applications (including industry examples), and why it’s beneficial to use GPUs on cloud infrastructure.

Continue reading

March 21, 2019

Knative on IBM Cloud Kubernetes Service: Your First App… Now Even Easier!

We're excited to bring you a change to how IBM Cloud Kubernetes Service exposes Knative. The process has been simplified greatly and will make your life much easier.

Continue reading

March 18, 2019

Kubernetes Clusters: Architecture for Rapid, Controlled Cloud App Delivery

Kubernetes clusters are the building blocks of Kubernetes, and they provide the architectural foundation for the platform. The modularity of this building block structure enables availability, scalability, and ease of deployment.

Continue reading