Skip to main content

Ingress and Egress Protocol

Ingress Traffic​

Ingress refers to network traffic entering a defined boundary, such as a network, a system, or a specific application. It's the incoming flow of data. Think of it as the entry point for external communication into your controlled environment.

Example: In a web server, ingress traffic would be requests coming from clients trying to access the website.

Use Cases Ingress Traffic​

1. Exposing Services​

The most common use case is exposing services running inside a private network (like a Kubernetes cluster or a VPC) to the outside world. Ingress acts as a reverse proxy and load balancer, routing external traffic to the appropriate internal services.

2. Traffic Management​

Ingress controllers can manage incoming traffic based on various rules, such as URL paths, hostnames, or HTTP headers. This allows you to route traffic to different services or versions of your application based on specific criteria.

3. Security​

Ingress can act as the first line of defense for your internal services. By terminating SSL/TLS connections at the ingress point, it can protect internal services from direct exposure to the internet. Ingress controllers can also implement authentication and authorization mechanisms.

4. API Gateway​

Ingress can function as an API gateway, providing a single entry point for all API requests. This simplifies client access and allows for centralized management of API traffic.

5. Load Balancing​

Ingress controllers distribute incoming traffic across multiple instances of a service, ensuring high availability and preventing overload.

Common Tools Use For Ingress Controller​

1. Ingress-Nginx​

https://github.com/kubernetes/ingress-nginx

the NGINX Ingress Controller acts as a smart reverse proxy and load balancer, dynamically configuring itself based on Ingress rules to route incoming traffic to the appropriate services within your Kubernetes cluster. This provides a single entry point for all your applications, simplifying external access and management.

Breakdown Explanation​
  1. Client Request: A client (like a web browser) initiates a request to access an application running inside the Kubernetes cluster.
  2. Load Balancer: The request first hits a Load Balancer. This could be a cloud provider's load balancer or a service like MetalLB running within the cluster. Its job is to distribute incoming traffic across the available NGINX Ingress Controller pods.
  3. NGINX Ingress Controller Pods: These pods are running instances of the NGINX web server, configured as a reverse proxy and load balancer. They receive the request from the Load Balancer.
  4. NGINX Ingress Controller Service: This service acts as an internal abstraction layer, providing a stable endpoint for the NGINX Ingress Controller pods. Even if pods are scaled up or down, the service IP remains consistent. The controller pod communicates with the controller service to get its configuration.
  5. NGINX Ingress Controller: This is the core component. It watches for changes in Ingress resources and IngressClass resources, which define routing rules for incoming traffic.
  6. IngressClass: This resource defines a specific "class" of Ingress, allowing you to have multiple Ingress controllers with different configurations within the same cluster. The NGINX Ingress Controller watches for Ingress resources of its specified class.
  7. Ingress: The Ingress resource defines the rules for routing traffic to different services based on hostnames, paths, etc. The controller watches for changes to these rules.
  8. Service: A Kubernetes Service groups together pods that perform the same function (your application). The Ingress Controller directs traffic to the appropriate Service based on the rules defined in the Ingress.
The flow of configuration and requests​
  1. Configuration (dashed lines): The NGINX Ingress Controller constantly monitors the Kubernetes API server for changes to Ingress and IngressClass resources. When a change is detected, the controller dynamically updates its configuration (provision & configure) to reflect the new rules, ensuring traffic is routed correctly. The controller uses the watch functionality to keep its configuration updated in the background.
  2. Requests (solid lines): Client requests flow through the Load Balancer, to the NGINX Ingress Controller pods, and finally to the correct Service pods based on the Ingress rules.
2. HAProxy Ingress​

Based on HAProxy, known for its performance.

3. Traefik​

A modern cloud-native edge router that can also act as an ingress controller

4. Ingress In AWS​

alt text

The diagram illustrates how an AWS ALB to manage ingress traffic to the Kubernetes cluster. The ALB routes traffic based on rules configured in listeners. The AWS ALB Ingress Controller keeps the ALB configuration synchronized with the Kubernetes Ingress resources. The traffic flows from the ALB to the Kubernetes nodes via NodePorts and finally reaches the appropriate application pods. This architecture provides a highly available and scalable way to expose the Kubernetes services to the end user

Kubernetes Cluster​

Any changes within the Kubernetes cluster, such as deployments or scaling events, are communicated to the AWS ALB Ingress Controller. The controller continuously watches for these changes (marked with a "1").

Application Load Balancer (ALB)​

This is the entry point for all incoming traffic. It acts as a reverse proxy and load balancer. It has listeners for both HTTP (port 80) and HTTPS (port 443) traffic, indicated by the "2" and accompanying text.

Target Groups​

The ALB uses target groups to route traffic to the appropriate backend services. Each target group represents a different service or set of pods in your Kubernetes cluster:

  1. TargetGroup: ServiceC (mode IP): Routes traffic based on the IP addresses of the pods in the target group ("3").
  2. TargetGroup: ServiceB (mode instance): Routes traffic based on the EC2 instances that the pods are running on (relevant if your Kubernetes cluster is on EC2). ("5" signifies this routing rule).
  3. TargetGroup: ServiceA (mode instance): Similar to ServiceB, routes based on EC2 instances. This one catches all other traffic ("/"). ("4" signifies the HTTP listener).
  4. Listeners and Rules: The ALB listeners are configured with rules that determine how traffic is routed to the target groups:
Listener: HTTP & HTTPS: Listens for incoming traffic on ports 80 and 443​
  1. Rule: /accounts: Traffic to the /accounts path is routed to TargetGroup: ServiceC.
  2. Rule: /products: Traffic to the /products path is routed to TargetGroup: ServiceB.
  3. Rule: / (Default): All other traffic is routed to TargetGroup: ServiceA.
  4. AWS ALB Ingress Controller: This controller is running inside your Kubernetes cluster. It acts as the bridge between the ALB and your Kubernetes services. It updates the ALB configuration based on changes in your Ingress resources (in Kubernetes).
NodePort Service​

The alb-ingress-controller exposes services using NodePort. This means that each node in the Kubernetes cluster exposes the service on a specific port. The ALB then directs traffic to these NodePorts ("NP: A" and "NP: B").

Pods​

Application's pods (PodA, PodB, PodC) run on the Kubernetes nodes. They receive traffic routed by the ALB through the NodePort service.

Nodes​

The worker machines in your Kubernetes cluster.

Egress Traffic​

Egress traffic is network traffic leaving a defined boundary, such as a network, system, or specific application. It's the outgoing flow of data—the opposite of ingress. Think of it as the exit point for communications originating from within your controlled environment.

Use Cases Egress Traffic​

1. Restricting Outbound Connections​

A primary use case is controlling which external services internal applications can access. This enhances security by preventing unauthorized outbound connections and limiting the potential impact of security breaches.

2. Traffic Monitoring & Analysis​

Monitoring egress traffic helps understand communication patterns, identify performance bottlenecks, and detect anomalies that might indicate security threats.

3. Compliance​

Some regulations require strict control over outgoing data, making egress filtering essential for compliance.

Tools For Egress Controller​

1. Firewalls​

Traditional firewalls are commonly used to implement egress rules. You can configure rules based on destination IP addresses, ports, protocols, and other criteria.

2. Kubernetes Network Policies​

In Kubernetes, NetworkPolicies provide fine-grained control over pod-to-pod and pod-to-external communication. You can define policies that allow or deny egress traffic based on various selectors.