Ingress Overview

Harshal ShahPune Kubernetes Meetup 06-Jan-2018

Services Recap

Expose application running in pods to other entities running within or outside the

cluster.

Services provide a stable endpoint for clients.

Services Type : External Name

Maps internal DNS name to an external entity

Example: Map an internal name “mysql.local” to an RDS instance for PROD but

local setup for Dev envs and so on.

Services Type : ClusterIP

Not exposed outside cluster.

Suitable for communication within cluster

Example: A frontend application talking to a backend without exposing the

backend outside the cluster.

Services Type : NodePort

Wraps over a ClusterIP

Exposed via a Port on the worker nodes

Nodes need to have public IP

Example: Allow a physical Load Balancer to access service

Services Type : LoadBalancer

Wraps over a NodePort

Cloud specific implementation

Each public facing service having a dedicated load balancer can get expensive.

Example: Expose public facing service to the internet

Services Type : Headless service

No endpoint created

A list of pod IPs matching selector is returned

Application needs to handle routing logic.

Example: Use list of MongoDB pods in a mongodb replicaset in an application.

Ingress Controller and Resource definition

Ingress resource defines routing conditions to a

service.

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: go-app-ingress

spec:

rules:

- host: demo.infracloud.space

http:

paths:

- backend:

serviceName: demo-go-app-svc

servicePort: 80

Ingress controller is a controller which watches

for Ingress resources and updates its rules to

satisfy routing conditions mentioned in Ingress

resource

Common Ingress Controllers:

● Nginx

● Traefik

● HAproxy

● Envoy

Routing in IngressName based routing

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: go-app-ingress

namespace: ingress-nginx

spec:

rules:

- host: demo.infracloud.space

http:

paths:

- backend:

serviceName: demo-go-app-svc

servicePort: 80

---

Path based routing

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: path-based-ing

namespace: ingress-nginx

spec:

rules:

- host: ingresstest.infracloud.space

http:

paths:

- path: /prod

backend:

serviceName: demo-go-app-svc

servicePort: 80

- path: /canary

backend:

serviceName: demo-go-app-svc-canary

servicePort: 80

Default Backend

This is a catch-all feature that is mandated by ingress controller specification.

Any request which is not handled by ingress resource rules will get routed to the default backend.

Ingress Resource and Controller

Ingress Controller deployment

Application deployment

Ingress Service

Type:

LoadBalancer

Application

Service

Type:

ClusterIP

Load Balancer

for Ingress

Ingress

Resource

Watches

Updates

Routes

Request

arrives

Demohttps://github.com/infracloudio/ingress-demo.git

Ingress Advantages

● One Load Balancer for multiple services

● Name based and Path based routing

● SSL termination

● Worker nodes can remain in a private subnet

Thank You!