1 2 3 4 5 6 7 8 9 10 Next »

Kubernetes Ingress 101: NodePort, Load Balancers, and Ingress Controllers

Create Date: October 03, 2019 at 03:34 PM         Tag: KUBERNETES         Author Name: Sun, Charles

Kubernetes Ingress 101: NodePort, Load Balancers, and Ingress Controllers

This article will introduce the three general strategies in Kubernetes for ingress, and the tradeoffs with each approach. I’ll then explore some of the more sophisticated requirements of an ingress strategy. Finally, I’ll give some guidelines on how to pick your Kubernetes ingress strategy.

What is Kubernetes ingress?

Kubernetes ingress is a collection of routing rules that govern how external users access services running in a Kubernetes cluster. However, in real-world Kubernetes deployments, there are frequently additional considerations beyond routing for managing ingress. We’ll discuss these requirements in more detail below.

Ingress in Kubernetes

In Kubernetes, there are three general approaches to exposing your application.

NodePort

A NodePort is an open port on every node of your cluster. Kubernetes transparently routes incoming traffic on the NodePort to your service, even if your application is running on a different node.

Every Kubernetes cluster supports NodePort, although if you’re running in a cloud provider such as Google Cloud, you may have to edit your firewall rules. However, a NodePort is assigned from a pool of cluster-configured NodePort ranges (typically 30000–32767). While this is likely not a problem for most TCP or UDP clients, HTTP or HTTPS traffic end up being exposed on a non-standard port.

The NodePort abstraction is intended to be a building block for higher-level ingress models (e.g., load balancers). It is handy for development purposes, however, when you don’t need a production URL.

Load Balancer

Using a LoadBalancer service type automatically deploys an external load balancer. This external load balancer is associated with a specific IP address and routes external traffic to a Kubernetes service in your cluster.

The exact implementation of a LoadBalancer is dependent on your cloud provider, and not all cloud providers support the LoadBalancer service type. Moreover, if you’re deploying Kubernetes on bare metal, you’ll have to supply your own load balancer implementation. That said, if you’re in an environment that supports the LoadBalancer service type, this is likely the safest, simplest way to route your traffic.

Ingress Controllers and Ingress Resources

Kubernetes supports a high level abstraction called Ingress, which allows simple host or URL based HTTP routing. An ingress is a core concept (in beta) of Kubernetes, but is always implemented by a third party proxy. These implementations are known as ingress controllers. An ingress controller is responsible for reading the Ingress Resource information and processing that data accordingly. Different ingress controllers have extended the specification in different ways to support additional use cases.

Ingress is tightly integrated into Kubernetes, meaning that your existing workflows around kubectl will likely extend nicely to managing ingress. Note that an ingress controller typically doesn’t eliminate the need for an external load balancer — the ingress controller simply adds an additional layer of routing and control behind the load balancer.

Real-world ingress

We’ve just covered the three basic patterns for routing external traffic to your Kubernetes cluster. However, we’ve only discussed how to route traffic to your cluster. Typically, though, your Kubernetes services will impose additional requirements on your ingress. Examples of this include:

Unless you’re running a very simple cloud application, you’ll likely need support for some or all of these capabilities. And, importantly, many of these requirements may need to be managed at the service level, which means you want to manage these concerns inside Kubernetes.

Start with a load balancer

Regardless of your ingress strategy, you probably will need to start with an external load balancer. This load balancer will then route traffic to a Kubernetes service (or ingress) on your cluster that will perform service-specific routing. In this set up, your load balancer provides a stable endpoint (IP address) for external traffic to access.

Both ingress controllers and Kubernetes services require an external load balancer, and, as previously discussed, NodePorts are not designed to be directly used for production.

Service-specific ingress management

So the question for your ingress strategy is really about choosing the right way to manage traffic from your external load balancer to your services. What are your options?

Assuming you don’t want to deploy your own, how do you choose between an ingress controller and an API gateway? It comes down to actual capabilities.

So how do you choose between an ingress controller and an API gateway deployed as a Kubernetes service? Surprisingly, there are no fundamental differences!

The original motivation behind ingress was to create a standard API to manage how external traffic is routed to cluster services. However, the reality is that ingress isn’t actually a portable standard. The standard is imprecise (different ingress controllers have different semantics, e.g., behavior of trailing / is not specified in the standard). The ingress standard has also focused on lowest common denominator functionality, so many ingress controllers have extended the ingress resource with custom annotations, creating additional fragmentation.

After some active discussion in the Kubernetes Network SIG, there was recognition that ingress (despite its beta tag) had become a de facto standard. Thus, the decision was made in January 2019 to move ingress to a permanent API group (networking.v1beta1), clean up the ingress API to resolve some ambiguities in the specification, and prepare to make a cleaned up ingress API GA. More details of this rationale can be found in this KEP. The KEP also notes some of the challenges in making a consistent standard for ingress across multiple implementations.

So, at the end of the day, your choice for service-specific ingress management should depend on your specific requirements, and a specific implementation’s ability to meet your requirements. Different ingress controllers will have different functionality, just like API Gateways. Here are a few choices to consider:

Summary

Kubernetes ingress is a work-in-progress. Organizations appear to be converging on an external load balancer that sends external traffic to a service router (API Gateway, ingress controller). This service router is declaratively configured via Kubernetes annotations. If you’re interested in following the evolution of Kubernetes ingress, check out the Kubernetes Network SIG and the current plan in this KEP.

Kubernetes ingress with Ambassador

Ambassador is an open source, Kubernetes-native API Gateway built on the Envoy Proxy. Ambassador is easily configured via Kubernetes annotations, and supports all the use cases mentioned in this article. Deploy Ambassador to Kubernetes in just a few simple steps.

This article was last updated in June 2019 to reflect the updated state of ingress on Kubernetes.

New Comment

Installing and Configuring Kubernetes

Create Date: July 11, 2019 at 10:33 PM         Tag: KUBERNETES         Author Name: Sun, Charles

Where to install Kubernetes?

Intallation Considerations (con't)

 

 

 

New Comment

Kubernetes - introduction

Create Date: July 11, 2019 at 08:57 PM         Tag: KUBERNETES         Author Name: Sun, Charles

What is Kubernetes?

benefits of using kubernetes:

Kubernetes principles:

Kubernetes API server:

Kubernetes API objects:

cluster components:

Kubernetes networking requirements

 

 

New Comment
1 2 3 4 5 6 7 8 9 10 Next »