Ingress Controllers and Kubernetes Services

Overview of Kubernetes Services

• Abstract way of exposing applications running as pods.
• Example: Checkout application deployed in a Kubernetes cluster as a pod with an IP address.
• Problem: IP addresses are dynamic, leading to potential connection issues (e.g., receiving a 404 error).
• Solution: Use Kubernetes Services to provide stable networking interfaces for pods.

Types of Kubernetes Services

1. ClusterIP
   • Default type, accessible only within the cluster.
   • Not suitable for direct external access.
2. NodePort
   • Opens a specific port on each node to allow external access.
   • Drawbacks: Limited port range, security concerns with exposed ports.
3. Load Balancer
   • Allocates an external IP address for accessing services.
   • Typically used with cloud providers (AWS, Azure, etc.) but also possible on bare metal with projects like MetalLB.

Introduction to Ingress

• Ingress can manage multiple services using a single IP address.
• Provides routing rules for HTTP and HTTPS traffic.
• Advantages over NodePort and Load Balancer:
  • Cost-effective for large-scale applications.
  • Supports advanced routing features (path-based, host-based routing).

Ingress Controller

• A necessary component that watches and implements the rules defined by Ingress resources.
• Examples: Nginx, HAProxy, others.
• Ingress resources need an IngressController to function.

Practical Examples of Ingress

1. Basic Ingress Resource

   • Define routing rules using hostnames and paths.
   • Example: Use host foo.bar.com to access a service.

2. Path-based Routing

   • Route requests based on URL path (e.g., /first or /second).

3. Wildcard Host

   • Use wildcards in host definitions for flexible access control.

4. Basic Authentication

   • Secure services by requiring user authentication.

Securing Ingress with TLS

• SSL Passthrough: Directly forwards encrypted traffic, minimal load balancing features.
• SSL Offloading: Decrypts traffic at the load balancer, faster but less secure.
• SSL Bridging: Decrypts, processes, and re-encrypts traffic for secure end-to-end connections.

Comparison of SSL Methods

• SSL Passthrough: Secure, minimal load balancing features.
• SSL Offloading: Reduces latency, less secure due to plain HTTP traffic.
• SSL Bridging: Secure, allows load balancer capabilities, but can introduce latency.

OpenShift Routes

• Different naming conventions: Edge termination, re-encrypt, and passthrough.
• OpenShift routes have limitations like not supporting TLS secrets natively.

Conclusion

• Ingress provides a flexible and scalable way to manage external access to Kubernetes services.
• Different SSL termination methods offer varying levels of security and performance.
• Real-world applications may require configuring multiple ingress controllers with specific rules and certificates.

Additional Notes

• Various ingress controller implementations exist due to competition and feature differences.
• Manifest files and practical examples shared in the session will be available on GitHub for further exploration.