Udostępnianie aplikacji za pomocą usług

When you deploy applications in Kubernetes, your Pods can come and go. They get new IPs, they scale up or down, and they might even crash and restart.

This creates a challenge: how do other parts of your application, or external users, consistently find and communicate with these ever-changing Pods?

Kubernetes Services solve this problem by providing a stable network abstraction over a set of Pods. Think of a Service as a single, unchanging IP address and DNS name for your application.

• Services act as load balancers, distributing traffic to healthy Pods.
• They ensure your application remains reachable even if individual Pods change or fail.

Services don't directly manage Pods. Instead, they use labels and selectors to find the Pods they should route traffic to. When a Pod matches a Service's selector, it becomes an endpoint for that Service.

• Labels: Key-value pairs attached to objects (like Pods) for identification.
• Selectors: Rules defined in a Service to match Pod labels.

The ClusterIP Service type is the default. It exposes the Service on an internal IP address within the cluster. This means the Service is only reachable from inside the cluster.

It's perfect for internal communication between different services in your application, like a frontend talking to a backend database.

Here's a YAML definition for a ClusterIP Service. It targets Pods with the label app: my-app and exposes port 80, routing traffic to container port 8080.

Apply it with kubectl apply -f service.yaml.

A NodePort Service opens a specific port on all worker nodes in your cluster. External traffic can reach your Service by contacting any node's IP address on that specific port (e.g., NodeIP:NodePort).

This is useful for exposing services to the outside world, especially in small setups or for development, without needing a cloud load balancer.

This NodePort Service will expose port 80 of your application on a high port (typically 30000-32767) on every node. You can specify a nodePort or let Kubernetes assign one.

After applying, find the assigned port with kubectl get svc.

A LoadBalancer Service is primarily used when running Kubernetes on a cloud provider (like AWS, GCP, Azure). It automatically provisions an external cloud load balancer.

This provides a dedicated, stable external IP address and often integrates with cloud-specific features like SSL termination and advanced routing.

When deployed on a cloud provider, this Service will automatically create and configure an external load balancer, assigning it an external IP address.

The external IP will be visible via kubectl get svc once provisioned.

Let's quickly compare the primary Service types:

• ClusterIP: Internal access only, within the cluster.
• NodePort: External access via a specific port on each node.
• LoadBalancer: External access via a cloud provider's load balancer, stable external IP.

Choosing the right type depends on whether your application needs to be accessible internally or externally, and your deployment environment.

Which Kubernetes Service types provide a direct mechanism for external traffic to reach applications running inside the cluster?

Great job! You've learned how Kubernetes Services abstract network access to your Pods and make your applications reachable. We explored three main types:

• ClusterIP: For internal-only communication within the cluster.
• NodePort: Exposes services on a static port across all nodes for external access.
• LoadBalancer: Integrates with cloud providers to provision an external load balancer, providing a stable external IP.

Understanding these Service types is fundamental for designing accessible and robust applications in Kubernetes.