### Overview
In Kubernetes, exposing containerized applications outside the cluster can be achieved using Services. However, managing numerous services, especially of type LoadBalancer, can become inefficient and costly. Ingress Controllers and Ingress Rules provide a more efficient way to route external traffic to internal services based on request host or path, centralizing many services to a single entry point.
### Ingress Controller
An Ingress Controller is different from other controllers as it does not run as part of the kube-controller-manager. Instead, it runs as a separate daemon inside a Pod, watching the /ingresses endpoint on the API server. This daemon manages traffic to and from the cluster based on configured rules. Multiple Ingress Controllers can be deployed, each with unique configurations.
### nginx Ingress Controller
The nginx Ingress Controller is one of the most popular and widely used controllers. Deploying it is simplified through provided YAML files available on GitHub, specifically in the ingress-nginx/docs/deploy repository. Configuration can be customized using ConfigMaps, annotations, or custom templates.
Key points for deploying nginx Ingress Controller:
- Easy integration with RBAC.
- Uses the annotation `kubernetes.io/ingress.class: "nginx"`.
- Supports Layer 7 traffic and requires the `proxy-real-ip-cidr` setting.
- Bypasses kube-proxy to allow session affinity.
- Requires the host field to be defined for TLS.
### Google Load Balancer Controller (GLBC)
The GLBC requires several objects to be created, including a ReplicationController with a single replica, three services for the application Pod, and an Ingress with two hostnames and three endpoints. The backend is managed by an Instance Group.
The traffic path for GLBC:
- Global Forwarding Rule -> Target HTTP Proxy -> URL map -> Backend Service -> Instance Group
### Ingress API Resources
Ingress resources are part of the `networking.k8s.io` API group and are still in beta. A typical Ingress object looks like this:
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ghost
spec:
rules:
- host: ghost.192.168.99.100.nip.io
http:
paths:
- backend:
service:
name: ghost
port:
number: 2368
path: /
pathType: ImplementationSpecific
```
### Deploying the Ingress Controller
To deploy an Ingress Controller, you can use kubectl to create it from a YAML file. For example:
```bash
$ kubectl create -f backend.yaml
```
This command results in a set of Pods managed by a ReplicationController and some internal services. You will notice a default HTTP backend serving 404 pages.
### Creating an Ingress Rule
To expose an application using Ingress, first create a deployment and expose it with an internal ClusterIP service:
```bash
$ kubectl run ghost --image=ghost
$ kubectl expose deployments ghost --port=2368
```
Next, create an Ingress resource to route traffic to the service:
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ghost-ingress
spec:
rules:
- host: ghost.192.168.99.100.nip.io
http:
paths:
- backend:
service:
name: ghost
port:
number: 2368
path: /
pathType: ImplementationSpecific
```
### Multiple Rules
You can define multiple rules in the same Ingress resource, each forwarding traffic to a specific service:
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: multi-ingress
spec:
rules:
- host: ghost.192.168.99.100.nip.io
http:
paths:
- backend:
service:
name: ghost
port:
number: 2368
path: /
pathType: ImplementationSpecific
- host: nginx.192.168.99.100.nip.io
http:
paths:
- backend:
service:
name: nginx
port:
number: 80
path: /
pathType: ImplementationSpecific
```
### Intelligent Connected Proxies
For more complex traffic management, service discovery, rate limiting, and advanced metrics, consider implementing a service mesh. A service mesh uses edge and embedded proxies to handle traffic based on control plane rules.
### Service Mesh Options
- **Envoy**: A modular and extensible proxy, often used as a data plane under other service mesh tools.
- **Istio**: A powerful toolset leveraging Envoy proxies via a multi-component control plane, built to be platform-independent.
- **linkerd**: An ultralight, fast, and easy-to-deploy service mesh.
### Conclusion
Ingress Controllers and Ingress Rules provide efficient and flexible ways to route traffic to your Kubernetes services, centralizing traffic management and reducing the need for multiple LoadBalancer services. Tools like nginx and GLBC offer robust solutions for different environments, while service meshes like Istio and linkerd enhance capabilities for advanced traffic management.
Continue: [[11-Scheduling]]