Fundamentos de redes en Kubernetes

Welcome! Kubernetes networking can seem complex, but it's designed to make distributed applications work seamlessly.

In this lesson, we'll explore how different parts of a Kubernetes cluster communicate. You'll learn about Pods, Services, and Ingress.

In Kubernetes, a Pod is the smallest deployable unit. Each Pod gets its own unique IP address within the cluster.

Containers inside the same Pod share this network namespace, meaning they can communicate with each other using localhost.

A core principle of Kubernetes networking is that all Pods can communicate with each other directly, without NAT (Network Address Translation).

This communication works even if Pods are on different worker nodes. It's like they're all on one flat network, making application design simpler.

How does Kubernetes achieve this "flat network" for Pods? It uses the Container Network Interface (CNI) standard.

CNI provides a specification for network plugins to configure network interfaces for containers. Examples include Calico, Flannel, and Cilium.

• CNI Plugin: Implements the CNI specification.
• kubelet: Uses the CNI plugin to assign IP addresses and configure networking for Pods.

Pods are designed to be ephemeral. They can be created, destroyed, or rescheduled at any time, changing their IP addresses.

This makes direct access to a Pod's IP unreliable. This is where Services come in. Services provide a stable network endpoint for a group of Pods.

The most common Service type is ClusterIP. It exposes the Service on an internal IP address within the cluster.

This IP is only reachable from within the cluster. It's perfect for backend services that only need to be accessed by other applications inside Kubernetes.

To expose a Service to the outside world, you can use a NodePort Service.

This type opens a specific port on *every* Node in your cluster. External traffic can reach your Service by hitting NodeIP:NodePort.

• Pros: Simple external access.
• Cons: Fixed port on all nodes, often in a high range (e.g., 30000-32767).

For cloud providers (like AWS, GCP, Azure), the LoadBalancer Service type is ideal.

It provisions an external cloud load balancer, which then routes traffic to your Service. This gives you a dedicated, public IP address for your application.

• Managed: Cloud provider handles the load balancer.
• Public IP: Easy external access with a well-known IP.

While Services handle basic network exposure, Ingress provides more advanced HTTP and HTTPS routing.

Ingress lets you define rules for incoming traffic based on hostname or URL path, directing it to different Services. Think of it as a smart router for web traffic.

Great job! You've covered the essentials of Kubernetes networking.

• Pods: Get unique IPs, communicate directly.
• CNI: Enables Pod networking.
• Services: Provide stable endpoints for ephemeral Pods (ClusterIP, NodePort, LoadBalancer).
• Ingress: Manages external HTTP/HTTPS routing to Services.

These components work together to provide robust and flexible networking for your containerized applications.