There are three ways to expose your Kubernetes application to external users:
- Use a Kubernetes service of type NodePort to expose the application on a port across all nodes.
- Use a Kubernetes service of type LoadBalancer to create an external load balancer that points to a service in your cluster.
- Use a Kubernetes Ingress resource to define host- or URL-based HTTP routing rules that specify how external users access services running in your cluster.
This article discusses each of these methods and when it Is most appropriate then goes into greater detail about Ingress resources and how to configure them in Yipee.io.
When you expose your application using a NodePort service, the specified port is open on every node in your cluster. Kubernetes routes all incoming traffic on that port to your service, even if your application is running on a different node. NodePort services are best suited for use in higher-level ingress models (such as load balancers) but are also useful during development when you don’t need a production URL.
When you use a LoadBalancer service, Kubernetes automatically deploys an external load balancer. This external load balancer is associated with a specific IP address and routes external traffic to a service in your cluster. If you’re in an environment that supports the LoadBalancer service type, this is probably the simplest way to route your traffic.
An Ingress resource allows you to define a collection of rules that allow inbound connections to reach your application. The Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, offer name-based virtual hosting, and more. Ingress resources define the routing rules. The routing rules are implemented by an Ingress Controller, such as NGINX, which must also be running in the cluster and typically works in conjunction with an load balancer.
As with all things Docker and Kubernetes, you’d normally have to define a bunch of complex YAML to add an Ingress resource to your application. As with all things Yipee.io, it’s much easier to add and define an Ingress resource to your Kubernetes application model:
- Click the Ingress button at the top of the Modeler:
- Enter the name and, optionally, a description of the Ingress in the New Ingress window that appears then click Create.
The Ingress resource is added to your application and appears, selected, in the Canvas with its properties (currently undefined) displayed in the to the right:
- You can see immediately that you need to specify a Default Backend service capable of servicing requests that don’t match any rule.
- Specify rules and other properties that define how you want to route requests.
Don’t worry, I’m not going to leave you hanging – read on for a couple of simple example Ingress definitions.
Example Single-Service Ingress Resource Definition
Although you don’t need to use an Ingress to expose a single-service application, you can do so by simply selecting that service as the Default Backend. For example:
Example Simple Fanout Ingress Resource Definition
Because the IP addresses of Kubernetes pods are only visible on the cluster network, you need something like a load balancer at the edge to proxy ingress traffic to the right endpoints. Configure an Ingress to keep the number of required load balancers down to a minimum.
For example, to implement a setup like the following:
foo.bar.com -> 220.127.116.11 -> / foo fooservice:80 / bar barservice:80
Configure an Ingress resource with the following properties:
- Name: foobaringress
- Annotations: (Configures the NGINX Ingress Controller)
- Name: nginx.ingress.kubernetes.io/rewrite-target
- Value: /
- Host: bar.com
- Path: /foo; Service: fooservice; Port:80
- Path: /bar; Service: barservice; Port:80
For more general information about Ingress resources and Controllers, see the Kubernetes documentation. For detailed information about how to define its properties, see the comprehensive tooltips in the Yipee.io user interface.