This document provides an overview of Ingress in Kubernetes, including: 1) It describes the different types of Kubernetes services - ClusterIP, NodePort, LoadBalancer, ExternalName, and Headless - and examples of using each type. 2) It explains that Ingress resources define routing rules to services, and Ingress controllers watch for Ingress resources and update rules to satisfy conditions. 3) Ingress allows for name-based and path-based routing to services, and controllers provide a default backend for requests not handled by Ingress rules.

1. Ingress Overview
Harshal Shah
Pune Kubernetes Meetup
06-Jan-2018

2. Services Recap
Expose application running in pods to other entities running within or outside the
cluster.
Services provide a stable endpoint for clients.

3. 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.

4. 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.

5. 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

6. 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

7. 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.

8. 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

9. Routing in Ingress
Name 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

10. 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.

11. 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

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

13. Ingress Advantages
● One Load Balancer for multiple services
● Name based and Path based routing
● SSL termination
● Worker nodes can remain in a private subnet

14. Thank You!