Why Services provide stable networking in Kubernetes - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to create a Kubernetes Service that exposes pods on port 80.

Kubernetes

kubectl expose pod mypod --port=[1] --target-port=8080

Drag options to blanks, or click blank then click option'

A8080

B80

C443

D3000

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing target port with service port

Using pod port instead of service port

The --port flag defines the port the Service will expose. Port 80 is the standard HTTP port.

2fill in blank

medium

Complete the code to select pods with label app=web for the Service.

Kubernetes

kubectl expose pod mypod --port=80 --selector=[1]

Drag options to blanks, or click blank then click option'

Aapp=web

Bapp:web

Capp_web

Dweb=app

Attempts:

3 left

💡 Hint

Common Mistakes

Using colon instead of equals

Swapping key and value

The selector uses key=value format to match pods with label app=web.

3fill in blank

hard

Fix the error in the Service YAML to ensure stable networking by specifying the correct type.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: [1]

Drag options to blanks, or click blank then click option'

AClusterIP

BNodePort

CExternalName

DLoadBalancer

Attempts:

3 left

💡 Hint

Common Mistakes

Using NodePort when internal stability is needed

Using ExternalName which is for DNS aliasing

ClusterIP is the default Service type that provides stable internal networking within the cluster.

4fill in blank

hard

Fill both blanks to complete the Service YAML that ensures stable networking and selects pods correctly.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: stable-service
spec:
  type: [1]
  selector:
    app: [2]
  ports:
  - port: 80
    targetPort: 8080

Drag options to blanks, or click blank then click option'

AClusterIP

BNodePort

Cmyapp

Dwebapp

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong service type

Selector not matching pod labels

Using ClusterIP ensures stable internal networking. The selector app: myapp matches the pods to route traffic.

5fill in blank

hard

Fill all three blanks to create a Service YAML that provides stable networking, selects pods, and exposes port 80.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: [1]
spec:
  type: [2]
  selector:
    app: [3]
  ports:
  - port: 80
    targetPort: 8080

Drag options to blanks, or click blank then click option'

Astable-service

BClusterIP

Cmyapp

DNodePort

Attempts:

3 left

💡 Hint

Common Mistakes

Using NodePort instead of ClusterIP

Incorrect selector label

Missing service name

The service name is stable-service, type ClusterIP ensures stable networking, and selector app: myapp matches the pods.

Practice

1. Why do Kubernetes Services provide stable networking for pods?

easy

A. They keep a fixed IP address that does not change even if pods are replaced.

B. They assign a new IP address to each pod every time it restarts.

C. They disable networking for pods to avoid conflicts.

D. They require manual IP configuration for each pod.

Solution

1. Step 1: Understand pod IP volatility

   Pods can be created and destroyed dynamically, so their IP addresses can change frequently.

2. Step 2: Role of Services in networking

   Services provide a stable IP address that stays the same, routing traffic to the current pods matching the selector.

3. Final Answer:

   They keep a fixed IP address that does not change even if pods are replaced. -> Option A

4. Quick Check:

   Stable IP = Service fixed address [OK]

Hint: Services keep one IP, pods can change IPs [OK]

Common Mistakes:

• Thinking pods keep the same IP always
• Believing Services assign new IPs to pods
• Assuming manual IP setup is needed

2. Which of the following is the correct way to define a Service selector in a Kubernetes YAML file?

easy

A. select: app == myapp

B. select: { app: myapp }

C. selector: app = myapp

D. selector: { app: myapp }

Solution

1. Step 1: Check correct YAML key for selectors

   The correct key to specify pod labels for routing is 'selector'.

2. Step 2: Verify syntax for selector values

   Selectors use key-value pairs inside curly braces with colon syntax, e.g., { app: myapp }.

3. Final Answer:

   selector: { app: myapp } -> Option D

4. Quick Check:

   Correct key and syntax = selector: { app: value } [OK]

Hint: Use 'selector' key with colon syntax in YAML [OK]

Common Mistakes:

• Using 'select' instead of 'selector'
• Using equal signs instead of colon in YAML
• Incorrect key-value syntax in selector

3. Given a Service with selector { app: frontend } and three pods labeled app=frontend, what happens if one pod is deleted?

medium

A. The Service continues routing traffic to the remaining pods without IP change.

B. The Service stops routing traffic until the pod is recreated.

C. The Service IP changes to a new address.

D. The Service deletes all pods automatically.

Solution

1. Step 1: Understand Service selector behavior

   The Service routes traffic to all pods matching the selector label.

2. Step 2: Effect of pod deletion on Service

   If one pod is deleted, the Service still routes traffic to the remaining pods with matching labels without changing its IP.

3. Final Answer:

   The Service continues routing traffic to the remaining pods without IP change. -> Option A

4. Quick Check:

   Service IP stable, routes to available pods [OK]

Hint: Service IP stays same; routes to existing pods [OK]

Common Mistakes:

• Thinking Service IP changes on pod deletion
• Believing Service stops routing if pods reduce
• Assuming Service deletes pods automatically

4. You created a Service but it is not routing traffic to pods. Which of these is the most likely cause?

medium

A. The Service IP address is manually set incorrectly.

B. The Service selector labels do not match any pod labels.

C. Pods have static IPs that conflict with the Service IP.

D. The Service type is set to ExternalName.

Solution

1. Step 1: Check Service selector and pod labels

   If the selector labels do not match any pod labels, the Service has no endpoints to route traffic to.

2. Step 2: Understand Service IP and type roles

   Service IP is assigned automatically; manual IP setting is uncommon. ExternalName type routes outside cluster, not to pods.

3. Final Answer:

   The Service selector labels do not match any pod labels. -> Option B

4. Quick Check:

   Selector mismatch = no routing [OK]

Hint: Match selector labels exactly to pod labels [OK]

Common Mistakes:

• Manually setting Service IP address
• Ignoring selector label mismatch
• Confusing Service types and their routing

5. You want to ensure your app pods can be replaced without changing the address clients use to connect. Which Kubernetes feature should you use and why?

hard

A. Assign static IPs to pods manually to keep addresses stable.

B. Use StatefulSets without Services to keep pod IPs stable.

C. Use a Service with a selector to provide a stable IP and DNS name.

D. Use HostNetwork mode on pods to share node IPs.

Solution

1. Step 1: Identify the need for stable networking

   Pods can be replaced or restarted, changing their IPs, so clients need a stable address to connect.

2. Step 2: Evaluate Kubernetes features for stable access

   Services provide a stable IP and DNS name that routes to pods matching selectors, hiding pod IP changes.

3. Step 3: Consider alternatives and their drawbacks

   Manual static IPs are hard to manage; StatefulSets keep stable pod identities but still use Services for stable networking; HostNetwork shares node IP but not pod-level stability.

4. Final Answer:

   Use a Service with a selector to provide a stable IP and DNS name. -> Option C

5. Quick Check:

   Service = stable IP + routing [OK]

Hint: Services give stable IPs despite pod changes [OK]

Common Mistakes:

• Trying to assign static IPs to pods manually
• Ignoring the role of Services in networking
• Confusing StatefulSets with stable networking