Challenge, Medium,  on  Kubernetes, Networking

Extend the Cluster with an Additional Service CIDR for the dev Team

Omkar Shelke
by  Omkar Shelke

Scenario

The cluster currently allocates all Service ClusterIPs from a single default range. The dev team needs its own dedicated pool of Service IPs, but reconfiguring the cluster's existing default Service CIDR is disruptive — it requires editing the kube-apiserver manifest, restarting the apiserver, and potentially recreating every existing Service.

Modern Kubernetes (1.33+) solves this with the ServiceCIDR API object — an additional, completely separate IP range can be added for Services without touching the default range or restarting anything.

A web-app Deployment is already running in the dev namespace, but it has no Service yet.

Task

  1. Add a new ServiceCIDR object named dev-team-cidr for 192.168.0.0/24, without modifying the existing default ServiceCIDR. Wait for it to report Ready: True
  2. Create a Service named web-app-svc in the dev namespace that selects pods with the label app: web-app. Configure spec.clusterIP with a valid IP address from the 192.168.0.0/24 Service CIDR. Do not use the network address (192.168.0.0) or the broadcast address (192.168.0.255).
  3. Confirm from inside a pod that DNS resolves web-app-svc.dev.svc.cluster.local to the Service's ClusterIP and that the application responds with its custom message.
Hint 1 — Inspect the Existing Default ServiceCIDR First

Before creating anything new, take a look at what the cluster already has. There is a built-in ServiceCIDR object that was created automatically at cluster bootstrap — find it, read its CIDR, and make sure you understand its name. You'll need to leave it completely untouched.

kubectl get servicecidr
kubectl get servicecidr <name> -o yaml

Documentation

Hint 2 — Create a New ServiceCIDR Object

A ServiceCIDR is a cluster-scoped resource under networking.k8s.io/v1. Create one named dev-team-cidr that covers 192.168.0.0/24. The relevant field to set is spec.cidrs.

After applying it, don't move on immediately — check its status.conditions and wait until the Ready condition shows True. Only then will the API server accept Service IPs from this range.

kubectl describe servicecidr dev-team-cidr

Documentation

Hint 3 — Think Carefully About How Kubernetes Assigns ClusterIPs

This is the trickiest part of the challenge. The Kubernetes IP allocator does not prefer a newly added ServiceCIDR over the default one — it picks from a shared pool, so a Service created without a specific IP will almost certainly land in the default range, not 192.168.0.0/24.

To guarantee the Service gets an IP from the new range, pick any valid ClusterIP from inside 192.168.0.0/24 and set it explicitly on the Service using the spec.clusterIP field. The valid ClusterIP range for a /24 is .1 through .254 — avoid .0 (network address) and .255 (outside the usable range).

Documentation

Hint 4 — Verify DNS and Connectivity from Inside the Cluster

Always verify DNS and connectivity from a pod running inside the cluster — not from the host — since that is the actual path real workloads use. Use a temporary busybox pod for the DNS lookup and a curlimages/curl pod for the HTTP request, both in the dev namespace so they share the same DNS search domain as the Service:

kubectl run dns-test --rm -it --restart=Never \
  --image=busybox:latest -n dev -- nslookup web-app-svc.dev.svc.cluster.local

kubectl run curl-test --rm -it --restart=Never \
  --image=curlimages/curl:latest -n dev -- \
  curl http://web-app-svc.dev.svc.cluster.local

Documentation

⚒ Test Cases

How to Author Challenges on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull challenge content

labctl content pull challenge extend-the-cluster-with-an-additional-service-cidr-for-the-dev-team-5251bc66

This will create a local copy of the challenge content in a directory named extend-the-cluster-with-an-additional-service-cidr-for-the-dev-team-5251bc66. You only need to do this once per challenge.

Stream your changes

labctl content push -fw challenge extend-the-cluster-with-an-additional-service-cidr-for-the-dev-team-5251bc66

Run this command in a separate terminal to continuously upload your changes to the server while editing the challenge in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help

Start challenge