Kubernetes: Ingress

Kubernetes Ingress allows external access to services within a cluster by following traffic direction rules defined in Ingress resources. Ingress controllers implement these rules by configuring the underlying load balancer or reverse proxy. Note that Ingress controller is not built-in in Kubernetes. Ingress can be compared to a restaurant entrance, with Ingress resources acting as a seating chart and Ingress controller as a host managing traffic flow.

Kubernetes: Ingress

Table of Contents

· Ingress
  ∘ Ingress Resources
  ∘ Ingress Controller
  ∘ Analogy
· Short Name: ing
· Ingress with YAML
  ∘ path-based routing
  ∘ hostname-based routing

Ingress

Ingress is an API object that allows you to expose HTTP and HTTPS routes from outside the cluster to services within the cluster. It acts as a gateway between external traffic and the services running inside the cluster. The Ingress controller is responsible for implementing the routing rules defined in the Ingress resource by configuring the underlying load balancer or reverse proxy. With Ingress, you can define routing rules, SSL certificates, and load balancing policies for effective traffic management.

Without Ingress, external traffic routing to Kubernetes services can be challenging. Managing services with a separate Service object is impractical for larger deployments. Ingress provides a centralized and flexible approach to manage external access to services, allowing more efficient and granular traffic routing

ingress

Ingress Resources

Ingress resources are a set of rules that define how incoming traffic should be directed to backend services. These rules can include path-based and hostname-based routing, as well as TLS termination. The backend services can be Kubernetes services or external services.

Type of Ingress

Ingress Controller

Ingress controller is a separate software component responsible for implementing the rules defined in the Ingress configuration. It automatically configures the underlying load balancer or reverse proxy to route traffic to the appropriate services by monitoring changes in the Ingress API object.

It’s important to note that this controller is not built-in to Kubernetes by default. Instead, users can choose from several open-source ingress controllers, such as NGINX, Traefik, and Istio, to customize their Kubernetes cluster according to their needs.

Analogy

ingress analogy

Ingress can be compared to the main entrance of a restaurant, where customers come in and out. Similarly, Ingress is the main entry point to a Kubernetes cluster where external traffic is routed to the appropriate services and pods.

Ingress resources can be compared to the seating chart at a restaurant. Just as the seating chart determines where customers are assigned to sit based on various rules (e.g. party size, reservations, etc.), Ingress resources define the rules that specify how incoming traffic should be routed to the appropriate backend services and pods in a Kubernetes cluster.

Ingress controller acts like a restaurant host or hostess who manages the flow of customers and ensures they are properly seated at their respective tables based on a seating chart. Similarly, Ingress controller manages the flow of incoming traffic and routes it to the appropriate backend services based on the rules defined in the Ingress resources.

Short Name: ing

$ kubectl api-resources
NAME        SHORTNAMES   APIVERSION             NAMESPACED   KIND
ingresses   ing          networking.k8s.io/v1   true         Ingress

Ingress with YAML

path-based routing

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: <Ingress_name>
spec:
  rules:
  - host: <hostname>
    http:
      paths:
      - path: <path1>   
        pathType: Prefix
        backend:
          service:
            name: <service1_name>
            port:
              number: <port1>
      - path: <path2>     
        pathType: Prefix
        backend:
          service:
            name: <service2_name>
            port:
              number: <port2>

rules: Specify the rules for routing incoming traffic.

pathType: Specify how the path field should be interpreted.

• Exact: The path field must match the URL path of the incoming request exactly.
• Prefix: The path field matches the URL path of the incoming request if it is a prefix of the request path.
• ImplementationSpecific: It is up to the Ingress controller to decide how to handle it.

If the incoming request path starts with <path1>, the traffic will be routed to <service1_name> at port <port1>. Similarly, if the incoming request path starts with <path2>, the traffic will be routed to <service2_name> at port <port2>.

hostname-based routing

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: <Ingress_name>
spec:
  rules:
  - host: <service1_domain>
    http:
      paths:
      - path: <path1>
        pathType: Prefix
        backend:
          service:
            name: <service1_name>
            port:
              number: <port1>
  - host: <service2_domain>
    http:
      paths:
      - path: <path2>
        pathType: Prefix
        backend:
          service:
            name: <service2_name>
            port:
              number: <port2>

The first rule specifies that traffic for <service1_domain> should be routed to <service1_name> when the incoming request path starts with <path1>. The second rule specifies that traffic for <service2_domain> should be routed to <service2_name> when the incoming request path starts with <path2> .

These are my personal notes for CKA exam preparation on Kubernetes. Please feel free to correct me if you notice any errors. 😊

Reference:

Ingress

Ingress Controllers