In this article, we will explain how you can expose an application to the Internet with the Ingress application load balancer (ALB).
There are three options to expose an application if you are using a standard classic Kubernetes cluster (the NodePort is the only option if you are using a free Kubernetes cluster):
- NodePort
- Network Load Balancer (NLB)
- Ingress application load balancer (ALB)
Ingress is a Kubernetes service that balances network traffic workloads in your cluster by forwarding public or private requests to your apps. You can use Ingress to expose multiple app services to the public or to a private network by using a unique public or private route:
Prerequisites
- IBM Cloud account
- IBM Cloud Container Registry
- IBM Cloud Kubernetes Service (you need a standard classic cluster)
Deploying an application
Deploy a sample Hello World app into a Kubernetes pod in your project.
1. Create a new namespace for your project:
2. Set the namespace preference so that you don’t need to specify the namespace for all subsequent kubectl commands in that context:
3. Clone the source code for the sample Hello World app:
4. Build a Docker image (Note: You need to have the Docker image running locally):
5. To pull images into a non-default Kubernetes namespace in IBM Cloud Kubernetes Service, you must add a new secret in your new namespace. You can copy the existing default secret into the new namespace. See more details here:
6. Verify that the secret copied:
7. Create a deployment to deploy the app:
8. Verify the deployment—hello-world-deployment
—and the app are running on a pod:
9. Scale up the number of replicas. Running three instances makes the app more highly available than just one instance:
Creating an Ingress service
The following diagram shows how Ingress directs communication from the Internet to an app in a classic single-zone cluster.
The ALB checks if a routing rule for the myapp
path in the cluster exists. If a matching rule is found, the request is proxied according to the rules that you defined in the Ingress resource to the pod where the app is deployed. The source IP address of the package is changed to the IP address of the worker node where the app pod runs. If multiple app instances are deployed in the cluster, the ALB load balances the requests between the app pods.
See more details in the doc: How does a request get to my app in a classic cluster?
Use the following steps to create an Ingress application load balancer (ALB) service to expose your app.
1. Create a ClusterIP service
Create a Kubernetes ClusterIP service for the app deployment that you want to expose. Your app can be exposed by a Kubernetes service to be included in the Ingress load balancing:
Make sure to include a label to your deployment in the metadata section of your configuration file—such as app=hello-world-deployment
. This label is needed to identify all pods where your app runs so that the pods can be included in the Ingress load balancing.
2. Select an app domain
You can choose the domain through which your apps will be accessible. You can use the IBM-provided domain, such as mycluster-<hash>-0000.us-south.containers.appdomain.cloud/myapp
, to access your app:
3. Select TLS termination
You can choose whether to use TLS termination. The ALB load balances HTTP network traffic to the apps in your cluster. To also load balance incoming HTTPS connections, you can configure the ALB to decrypt the network traffic and forward the decrypted request to the apps that are exposed in your cluster. If you use the IBM-provided Ingress subdomain, you can use the IBM-provided TLS certificate, which is stored as a Kubernetes secret in the default
namespace.
4. Create the Ingress resource
Create an Ingress configuration file that is named—for example, myingress.yaml
—to define the routing rules that the ALB uses to route traffic to your app service.
Ensure that the resource deploys into the same namespace as the app services that you specified in the resource. If your apps are exposed by services in different namespaces in one cluster, add a wildcard subdomain to the beginning of the domain, such as subdomain1.custom_domain.net or subdomain1.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
. Use a unique subdomain for each Ingress resource that you create in the cluster.
See more details to add the Ingress annotations here.
Example configuration for the Ingress resource:
Apply the Ingress configuration to create:
Verify that the Ingress resource was created successfully. If messages in the events describe an error in your resource configuration, change the values in your resource file and reapply the file for the resource:
Access your app with the Ingress subdomain and the path—https://<ingress_subdomain>/<app_path>:
5. Set up a custom domain
If you choose a custom domain, you can set it up through the following steps:
- Register a custom domain by working with your Domain Name Service (DNS) provider or by using IBM Cloud DNS.
- Define an alias for your custom domain by specifying the IBM-provided subdomain as a Canonical Name record (CNAME).
- Change the host name with your custom domain in the Ingress configuration.
Example configuration for the Ingress resource:
You can access with your customer domain:
Cleanup
1. Check all your resources that have the app=hello-world-deployment label:
2. Then, you can delete all the resources with the label:
3. Delete the Ingress resource and the namespace:
Summary
I hope that you now understand how you can expose an application to the outside of your Kubernetes cluster with the Ingress application load balancer (ALB) so that users can access the app from the Internet.
For more more information, you can see the following: