DEV Community: Joseph Cardillo

Understanding Service Labels in Kubernetes: A Simple Guide to Swapping Backends

Joseph Cardillo — Wed, 18 Sep 2024 17:40:45 +0000

I’ve always found the best way to grasp Kubernetes concepts is through real-world analogies and hands-on practice. Today, let's dive into how service labels work in Kubernetes by walking through a practical example. We'll see how labels can help us easily switch the backend of a NodePort service from one pod to another.

The Name Tag Analogy

Think of labels in Kubernetes like name tags at a conference. Each attendee wears a tag that shows their role or interest, such as 'Developer,' 'Designer,' or 'Manager'. These tags help people quickly identify and group attendees with similar interests. In Kubernetes, labels work the same way, acting as tags on resources, like pods and services, to help organize and manage them more easily.

Step 1: Create an NGINX Pod

First, create a pod running NGINX:

kubectl run nginx-pod --image=nginx

Verify the pod is running:

kubectl get pods

NAME                               READY   STATUS    RESTARTS        AGE
nginx-pod                          1/1     Running   0               8s

Step 2: Expose the Pod via a NodePort Service

Now, let's expose this pod so we can access it from outside the cluster.

kubectl expose pod nginx-pod --type=NodePort --port=80

Check the service details:

kubectl get services

NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx-pod         NodePort    10.109.46.128   <none>        80:32303/TCP   6s

Step 3: Add a Selector Label to the Service

Our service currently doesn't have a specific selector label, or "nametag". Let's add role: developer to the service so it knows to send traffic to pods with this label.

First, add the label to the pod:

kubectl label pod nginx-pod role=developer

Now, edit the service to include the same selector:

kubectl edit service nginx-pod

This will open a text editor. Find the selector section and modify it as follows:

  selector:
    role: developer

Step 4: Access the NGINX Service

To access the nginx pod via the NodePort, get the NodePort number:

kubectl get service nginx-pod

Output:

k get svc nginx-pod
NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx-pod   NodePort   10.109.46.128   <none>        80:32303/TCP   3m37s

In this example, the NodePort is 32303. Now, curl the service using the node's IP address (replace NODE_IP with your node's actual IP, which can be found with ip a | grep eth0):

curl NODE_IP:32303

You should see the default NGINX welcome page HTML.

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Step 5: Create a New Pod Using the HTTPD Image

Now, let's bring in our second conference attendee by creating a new pod with the HTTPD image.

kubectl run httpd-pod --image=httpd

Label this pod accordingly:

kubectl label pod httpd-pod role=manager

Step 6: Update the Service Selector to Point to the New Pod

Edit the service again:

kubectl edit service nginx-pod

Change the selector to:

  selector:
    role: manager

Step 7: Access the Updated Service

Curl the service again:

curl NODE_IP:32303
<html><body><h1>It works!</h1></body></html>

Wrapping Up

By simply changing the label selector in our service, we redirected traffic from one pod to another without changing the service's endpoint or port. This is the power of labels in Kubernetes—they allow you to dynamically manage and route traffic between different pods.

An Introduction to Working with Network Policies in Kubernetes

Joseph Cardillo — Mon, 16 Sep 2024 19:17:52 +0000

As I've started to study for my CKAD certification, I thought it would be helpful to start writing again, as a way to help solidify my understanding of certain concepts. In this article I'll start with Network Policies.

To illustrate this, we'll set up an nginx webserver, apply a network policy to restrict all traffic, modify that policy, and see how each affects traffic to the nginx application.

Note: This article assumes a working kubernetes instance or cluster, a basic understanding of Kubernetes concepts, and the use of kubectl for managing your cluster.

What are Network Policies?

I like to think of Network Policies as a sophisticated mail sorting system in a large office. They determine which departments (pods) can send and receive mail (network traffic), through which mailboxes (ports), and with whom they can correspond (other pods or external services).

Similarly, Network Policies control the flow of network traffic between pods.

By default, all pods in a Kubernetes cluster can communicate with each other freely. Network Policies allow you to restrict this communication, enhancing your cluster's security.

Setting Up Our Example

Let's start by creating a simple nginx webserver deployment:

kubectl create deploy nginx-webserver --image=nginx

To view the objects we've created, run:

kubectl get pods
kubectl get deployments.apps

Now, let's expose our deployment via a NodePort:

kubectl expose deploy nginx-webserver --type=NodePort --port=80

To get the NodePort's IP and port, run the following command:

kubectl get svc

You should see output similar to this:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
nginx-webserver        NodePort       10.96.173.63     <none>        80:30092/TCP     2m23s

Now, let's test our nginx server by curling the cluster IP from your control plane node:

curl http://10.96.173.63:80

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

You can also access the page publicly at the control plane IP:30092. For example:

http://172.243.237.107:30092/

Creating a Network Policy

Next, let's create a Network Policy to block all traffic to pods in this deployment. We'll call it blockall:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: blockall
spec:
  podSelector:
    matchLabels:
      app: nginx-webserver
  policyTypes:
  - Ingress
  - Egress

Save this as blockall.yaml and apply it:

kubectl apply -f blockall.yaml

Testing the Network Policy

To test if our policy is working, curl the nginx-webserver IP again:

curl http://10.96.173.63:80

If you wait long enough, you should see a timeout:

curl: (28) Failed to connect to 10.96.173.63 port 80 after 129428 ms: Connection timed out

This means our Network Policy is working. It's as if we've instructed the mail room to return all correspondence addressed to our nginx server (mailbox) as 'Address Unknown'. No matter what department tries to send a message, it won't reach its destination.

Allowing Specific Traffic

Now, let's modify our policy to allow incoming traffic on port 80:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: blockall
spec:
  podSelector:
    matchLabels:
      app: nginx-webserver
  policyTypes:
  - Ingress
  - Egress
  ingress:
    - ports:
      - protocol: TCP
        port: 80

Update the policy with this command:

kubectl replace -f blockall.yaml

Now when we curl our nginx server, we should see the nginx welcome page again:

curl http://10.96.173.63:80

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

Conclusion

Network Policies in Kubernetes are like building a custom firewall around your applications. They give you fine-grained control over who can talk to whom in your cluster, enhancing your security posture.

Creating effective Network Policies requires a good understanding of your application's communication patterns and needs. It's recommended to start with restrictive policies and gradually open up communication as needed, rather than starting wide open and trying to lock things down.

In taking the time to understand Network Policies, you're adding a powerful tool to your Kubernetes security toolkit.

Image credit: Photo by Pedro Forester Da Silva on Unsplash