Docker & Kubernetes : NodePort vs LoadBalancer vs Ingress

bogotobogo.com site search:

Introduction

In this post, we'll clarify confusing Kubernetes network terminologies such as pod networks, service networks, cluster IPs, container ports, host ports, and node ports. We'll do so while we are investing service types: NodePort, LoadBalancer, and Ingress.

For more on Pods and Services, please check my another post: Pods and Service definitions

Cluster Networking

There are 4 distinct networking problems to solve in Kubernetes:

Highly-coupled container-to-container communications:
this is solved by pods and localhost communications. Each Pod is assigned a unique IP address (so, we do not need to explicitly create links between pods and we almost never need to deal with mapping container ports to host ports). Every container in a Pod shares the network namespace (all the containers in a pod can reach each other on localhost), including the IP address and network ports. Containers inside a Pod can communicate with one another using localhost
Pod-to-Pod communications.
Pod-to-Service communications.
External-to-Service communications.

NodePort vs LoadBalancer vs Ingress

Refs:

https://kubernetes.io/docs/concepts/services-networking/service/.

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

Picture source: Kinvolk Tech Talks: Introduction to Kubernetes Networking with Bryan Boreham.

In Kubernetes, there are three general approaches (service types) to expose our application.

We've been using the NodePort type for all the services that require public access. Kubernetes arrange things with the NodePort and it's on every node in our cluster (Kubernetes cluster, by default, supports NodePort). So, if we hit a node that the service is not running, it will bounce across to our nodes. Internally, it's done via iptables.

When we create a Service of type NodePort, Kubernetes gives us a nodePort value. Then the Service is accessible by using the IP address of any node along with the nodePort value. In other words, when a user sets the Service type field to NodePort, the Kubernetes master allocates a static port from a range, and each Node will proxy that port (the same port number on every Node) into our Service.

The NodePort can be used as a building block for higher-level ingress models (e.g., load balancers) and it is handy for development purposes, however, NodePorts are not designed to be directly used for production.

In this Django post, we'll use Load Balancer service type (deploy/django/service.yaml):

kind: Service
apiVersion: v1
metadata:
  name: django-service
spec:
  selector:
    pod: django
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8000
  type: LoadBalancer

Internally, it uses NodePort to bounce across to the machine that the service is running on. Note that this is on Layer 4 (Ingress is on Layer 7). Also note that the exact implementation of a LoadBalancer is dependent on the cloud provider. So, unlike the NodePort service type, not all cloud providers support the LoadBalancer service type.

Ingress works on layer 7 (http/https only) and Ingress can provide load balancing, SSL termination and name-based virtual hosting (host based or URL based HTTP routing).