When scaling up the number of applications you manage, it can feel like there's a lot of moving parts to ensure that your APIs are going through securely to the right applications.

IBM Cloud Kubernetes exposes various API integrations, which are already available through the CLI and Terraform, to make this easier.

We are excited to announce that these features are now accessible through the UI!

Ingress Overview

First, let's do a review of what the relevant Ingress components are.

When clients send requests to an endpoint, the traffic is directed from the domain to the respective load balancer. The load balancer forwards these requests to the Ingress controller, where they undergo request termination using a TLS secret. The requests are then distributed across the available service pods.

Our suite of managed integrations offer APIs to automate cluster setup and management:

1. Domains: Link a custom domain to your cluster's load balancer by leveraging IBM Cloud Internet Services. This integration ensures automatic renewal of corresponding TLS certificates.

2. Ingress Controller (ALB): Manage your Application Load Balancers (ALBs) with features such as version control, custom configurations, and both horizontal and vertical scaling capabilities.

3. Secrets: Securely store managed TLS certificates and secrets in your IBM Cloud Secrets Manager instance, with automatic synchronization to your Kubernetes secrets.

The following table outlines the actions available for each API. Use these actions to streamline your cluster management.

Configuring a Multi-Tenant Microservices Environment in IBM Cloud

Let's dive into a practical scenario: Imagine you're assigned the task of configuring a multi-tenant environment within IBM Cloud to support a new product built on a microservices architecture, catering to various teams. The architecture is best depicted in the high-level diagram below.

Each team operates distinct microservices that serve specific components. These services are deployed within individual team namespaces, with "echo" representing one team's namespace and "foxtrot" dedicated to another. You've implemented a production cluster to make services accessible to users. After careful consideration, you've decided that employing an Ingress Controller, specifically an Application Load Balancer (ALB), is the optimal choice to serve as the API gateway for your team's requirements.

The "echo" team has reached out, seeking your assistance in establishing a new microservice to be accessible in the production environment via any requests at the "echo" endpoint at techcorp.com/echo/*. Their application is currently operational within the "echo" namespace, exposed behind the "echo" service. In the following example, we'll examine the configuration of an Ingress resource to understand how to securely expose this API endpoint within your cluster.

> kubectl get ingress echo-ingress -o yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  annotations:

    kubernetes.io/ingress.class: public-iks-k8s-nginx // 2. ALB

  generation: 1

  name: echo-ingress

  namespace: echo-namespace

spec:

  rules:

  - host: techcorp.com // 1. Domain

    http:

      paths:

      - backend:

          service:

            name: echo-service

            port:

              number: 8080

        path: /echo

        pathType: Prefix

  tls:

  - hosts:

    - techcorp.com

    secretName: echo-secret // 3. Secret

Begin by navigating to your IBM Cloud clusters and selecting the correct cluster to access the cluster overview page. Note the cluster-wide default Ingress configurations.

From the left-hand navigation, you select the "Ingress" tab. You note that all your Ingress components in the overview page are currently healthy.

1. The first step is to set up the domain for your Ingress host. If you have already set up a Cloud Internet Services (CIS) instance and have an active domain (for guidance on creating one, refer to this getting started guide), configure the necessary service-to-service IAM authorization and designate it as the default domain for your cluster. This ensures all future ALB changes are automatically reflected in your domain configuration and will generated managed TLS certificates.

2. You navigate to the ALBs tab and see an enabled public ALB. You verify that the Ingress class in the Ingress resource maps to the managed ALB. You verify that the "autoupdate" feature is enabled by default by attempting to Update version. This will allow you to promptly address any known vulnerabilities.  If this is a private application, you can enable a private ALB and link it to your domain.

3. The “echo-secret” needs to live in the “echo-namespace”. You navigate to the secrets tab and take note of the "techcorp" TLS secret.  To copy the managed TLS secret into the “echo-namespace”,  you create a secret in  the "echo-namespace".

- Note: If a secret ID doesn't exist within the secret detail, ensure that a default instance is registered.

4. You test the techcorp.com/echo endpoint and confirm that the application is correctly exposed at the "echo" endpoint.

5. You configure monitoring for your ALB traffic (setup monitoring guide) which enables to monitor the load and traffic on your ALB, facilitating informed decisions regarding scaling.

With everything configured in the cluster, you are now ready to start serving your users!

Contact us

This blog serves as a primer to showcase the benefits and functionality of using these integration in the UI. We hope that it helped you gain an understanding around the capabilities in the UI regarding your Ingress resources.

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