Skip to content

How K8s Works - from an application perspective

How Ingresses Work

The following text was provided by Google Gemini 2.0. The pictures were drawn by Gary Zeien. The output was reviewed.

This diagram illustrates how applications running in a Kubernetes cluster (specifically on Google Kubernetes Engine - GKE) are accessed from external clients (like browsers or mobile devices). It focuses on the role of the Ingress Controller and related components in routing external traffic to the correct pods within the cluster.

Major Components:

  • Pods (1): The smallest deployable units in Kubernetes. They contain one or more containers running your application.
  • Services (3): An abstraction that exposes a set of Pods as a network service. Services provide a stable IP address and DNS name for accessing the Pods, even if the Pods are restarted or rescheduled. The diagram shows two services: one for the UI and one for the backend service (bss).
  • Ingress Definition (3): A Kubernetes resource that defines how external traffic should be routed to Services within the cluster. It acts as a set of routing rules. It specifies hostnames, paths, and backend Services.
  • Ingress Controller (4): A component that implements the Ingress Definition. It typically runs as a Pod within the cluster and uses a load balancer (or other mechanisms) to expose the Services externally. It configures the load balancer based on the Ingress Definition.
  • Load Balancer (5): A component that distributes incoming network traffic across multiple servers (in this case, the Ingress Controller). It provides a single external IP address for accessing the application.
  • DNS (6): The Domain Name System translates human-readable domain names (like stuff.garyzeien.com) into IP addresses.
  • Browser/Mobile (2): The external clients that initiate requests to the application.
  • VPC Network: The Virtual Private Cloud network provides the network infrastructure for the GKE cluster within the hyperscaler (GCP in this case).

Flow (Numbered Steps):

  1. Application Deployed: Pods are deployed within the Kubernetes cluster, and Services are created to expose them internally. The diagram shows two Services: one for the UI and one for the backend service (bss).
  2. User Accesses Application: A user uses a browser or mobile device to access the application using a domain name (e.g., https://stuff.garyzeien.com/ or https://stuff.garyzeien.com/api/v1/catalog).
  3. Ingress Definition and Service Definition: The Ingress Definition contains routing rules that map incoming requests based on hostnames and paths to specific Services. The Service definition points to the Pods that constitute a certain service.
  4. Ingress Controller Configuration: The Ingress Controller reads the Ingress Definition and configures the Load Balancer accordingly.
  5. Load Balancer Creation: The Ingress Controller triggers the creation of a Load Balancer in the cloud provider (GCP in this case). The Load Balancer gets an external IP address.
  6. DNS Resolution: The DNS server resolves the domain name (e.g., stuff.garyzeien.com) to the external IP address of the Load Balancer via a DNS record.
  7. Request Routing: The user's request is routed to the Load Balancer based on the DNS resolution. The Load Balancer forwards the request to the Ingress Controller. The Ingress Controller consults the Ingress Definition and routes the request to the appropriate Service based on the path (e.g., / for the UI, /api/v1/catalog for the backend).
  8. Service to Pod: The Service then forwards the request to one of the Pods backing the service.

Key Concepts Illustrated:

  • External Access: How external traffic reaches applications running in a Kubernetes cluster.
  • Ingress Controller's Role: The central role of the Ingress Controller in routing external traffic based on defined rules.
  • Load Balancing: The use of a Load Balancer to distribute traffic and provide a single entry point.
  • DNS Resolution: The importance of DNS in mapping domain names to IP addresses.
  • Path-Based Routing: The ability to route requests based on different URL paths to different backend services.
  • SSL Termination: The Ingress Controller can handle SSL termination, decrypting incoming HTTPS traffic before forwarding it to the backend Services. This is mentioned in the annotation "The Ingress Controller can terminate all SSL Connections."

This diagram provides a good overview of the key components and flow involved in exposing applications running in Kubernetes to the outside world.

How microservices communicate in K8s

The following was provided by Google Gemini 2.0

This diagram illustrates how microservices running within a Kubernetes cluster communicate with each other. It focuses on the configuration and operational flow of one microservice (Component A, referred to as "Blue") calling a method on another microservice (Component B, referred to as "Red").

Key Points Summarized:

  1. Independent Deployment (1): The diagram emphasizes that the microservices (Blue and Red) are built and deployed independently. This is a core principle of microservices architecture.

  2. Container Images (2): Each microservice is packaged as a container image. These images are stored in a container registry and used to create the running containers within Pods.

  3. Deployment Definition (3, 5): A Kubernetes Deployment defines how many replicas of a Pod should be running and how they should be updated. It specifies the container image to use, resource requirements, and other configuration. There are two deployment definitions, one for the Blue deployment and one for the Red deployment.

  4. Service Definition (4): A Kubernetes Service provides a stable network endpoint (a DNS name and IP address) for accessing a set of Pods. This decouples the calling service (Blue) from the specific Pods running the target service (Red). The service definitions include the name of the service, the selector used to identify the pods belonging to the service, and the port the service is exposed on.

  5. Environment Variables (3): The Deployment for the Blue service includes an environment variable called REDSERVICEADDR. This variable is crucial for inter-service communication. It is set to RedService:3000, where RedService is the name of the Kubernetes Service for the Red component and 3000 is the port it exposes.

  6. Deployment to Kubernetes (6): The kubectl apply -f file.yaml command is used to deploy the defined configuration objects (Deployments and Services) to the Kubernetes cluster.

  7. DNS Resolution within Kubernetes (7, 9): When the Blue container needs to call the Red service, it uses the value of the REDSERVICEADDR environment variable. Kubernetes' internal DNS service resolves RedService to the Cluster IP address of the Red Service. This allows the Blue container to discover the Red service without needing to know the IP addresses of the individual Red Pods.

  8. Service Call (8, 10): The Blue container makes a call to RedService:3000.getCatalog(). This call is routed to one of the Pods backing the Red Service. The getCatalog() method is then executed within the Red container.

  9. Kubernetes etcd (9): The Kubernetes configuration store (etcd) holds information about all Kubernetes objects, including Deployments, Services, and Pods. This is how Kubernetes knows the IP addresses of the Pods backing the Red Service.

In essence, the diagram shows how Kubernetes facilitates communication between microservices by:

  • Abstracting Pod IPs: Services provide a stable endpoint, so the calling service doesn't need to know the IP addresses of individual Pods.
  • DNS Resolution: Kubernetes' internal DNS resolves Service names to Cluster IPs.
  • Environment Variables: Environment variables are used to pass the Service name and port to the calling service.

This approach ensures that microservices can communicate reliably even if Pods are scaled up, scaled down, or restarted.

How a Service Mesh changes the flow above

The following was provided by Google Gemini 2.0

In the previous scenario, Kubernetes Services and DNS handled service discovery and basic load balancing. With Istio, the flow changes significantly as Istio takes over many of these responsibilities, providing more advanced features. Here’s how the flow would change:

1. Sidecar Proxies (Envoy) Injection:

  • Istio uses Envoy proxies as sidecars, which are injected into each Pod. This means each Pod will have an additional container running the Envoy proxy alongside the application container.
  • All network traffic to and from the application container is intercepted by the Envoy proxy.

2. Service Discovery and Load Balancing:

  • Istio's control plane (primarily Pilot) takes over service discovery. It receives information about Services and Pods from the Kubernetes API server.
  • Instead of the application directly using the Kubernetes Service DNS name, the Envoy proxy intercepts the request.
  • Pilot provides the Envoy proxy with configuration about available services and their endpoints.
  • Envoy performs intelligent load balancing based on the configuration provided by Pilot. This can include more advanced load balancing algorithms than Kubernetes' basic round-robin.

3. No More Direct Service DNS Lookup:

  • The application code no longer needs to be aware of the Kubernetes Service DNS name or perform DNS lookups. It simply makes calls to a local port.
  • The Envoy proxy intercepts these calls and routes them to the appropriate service based on Istio's configuration.

4. Enhanced Traffic Management:

  • Istio introduces advanced traffic management features like:
    • Routing rules: Fine-grained control over traffic routing based on various criteria (e.g., headers, paths, weights).
    • Traffic splitting: Gradual rollout of new versions of a service by splitting traffic between different versions.
    • Fault injection: Injecting delays or errors to test the resilience of the application.
    • Retries and timeouts: Automatic retries and timeouts for failed requests.

5. Security:

  • Istio provides features like mutual TLS (mTLS) to secure communication between services. This ensures that only authorized services can communicate with each other.
  • Authorization policies can be defined to control access to services based on various attributes.

6. Observability:

  • Istio collects detailed telemetry data (metrics, logs, traces) about service communication. This data can be used to monitor the performance and health of the application.

Changes to the Diagram:

  • Each Pod would have an additional container representing the Envoy proxy.
  • The direct call from the Blue container to RedService:3000 would be intercepted by the Envoy proxy in the Blue Pod.
  • The REDSERVICEADDR environment variable would become less critical, as the application would rely on the Envoy proxy for routing.
  • The diagram would need to illustrate Istio's control plane (Pilot) and its role in configuring the Envoy proxies.

In summary: With Istio, the communication flow becomes more abstract. The application code is decoupled from service discovery and networking logic. Istio's sidecar proxies and control plane handle these complexities, providing advanced features for traffic management, security, and observability.**

Last update: January 15, 2025
Back to top