Service discovery via DNS in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a Kubernetes Service that uses DNS for service discovery.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: [1]

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

A8080

B3000

C443

D80

Attempts:

3 left

💡 Hint

Common Mistakes

Using a port number that does not match the pod's container port.

Confusing port and targetPort.

The targetPort should match the port on the pods that the service routes to. Here, port 80 is used for simplicity.

2fill in blank

medium

Complete the command to get the DNS name of a service in the default namespace.

Kubernetes

kubectl get svc [1] -o jsonpath='{.spec.clusterIP}'

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

Adefault

Bmy-service

Ckube-dns

Dmy-pod

Attempts:

3 left

💡 Hint

Common Mistakes

Using pod names instead of service names.

Using namespace names instead of service names.

The command fetches the Cluster IP of the service named my-service, which is used for DNS-based service discovery.

3fill in blank

hard

Fix the error in the DNS query command to resolve the service name inside a pod.

Kubernetes

nslookup [1].default.svc.cluster.local

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

Akube-system

Bmy-pod

Cmy-service

Dlocalhost

Attempts:

3 left

💡 Hint

Common Mistakes

Using pod names instead of service names in DNS queries.

Using incorrect namespaces.

The DNS name for a service includes the service name, namespace, and cluster domain. Here, my-service is the correct service name to query.

4fill in blank

hard

Fill both blanks to create a headless service for DNS-based service discovery.

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: headless-service
spec:
  clusterIP: [1]
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: [2]

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

Anull

B8080

C80

D0.0.0.0

Attempts:

3 left

💡 Hint

Common Mistakes

Using a normal cluster IP instead of null for headless services.

Mismatching the target port with the container port.

Setting clusterIP to null creates a headless service, which allows direct DNS queries to pods. The targetPort should match the pod's port, here 8080.

5fill in blank

hard

Fill all three blanks to create a DNS SRV record query for a service in Kubernetes.

Kubernetes

dig +short SRV _[1]._tcp.[2].svc.[3]

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

Ahttp

Bmy-service

Ccluster.local

Ddefault

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing service name with namespace.

Using wrong cluster domain.

Omitting the underscore prefix in SRV queries.

The SRV record query format is _service._protocol.namespace.svc.cluster-domain. Here, http is the service protocol, default is the namespace, and cluster.local is the default cluster domain.

Practice

1. What does Kubernetes use to help applications find each other without hardcoding IP addresses?

easy

A. Manual IP configuration

B. DNS-based service discovery

C. Static routing tables

D. Load balancer IPs only

Solution

1. Step 1: Understand service discovery basics

   Kubernetes provides a way for apps to find each other by name instead of IP, which can change.

2. Step 2: Identify the mechanism Kubernetes uses

   Kubernetes automatically creates DNS entries for services, enabling DNS-based discovery.

3. Final Answer:

   DNS-based service discovery -> Option B

4. Quick Check:

   Service discovery = DNS-based [OK]

Hint: Kubernetes uses DNS names, not fixed IPs, for service discovery [OK]

Common Mistakes:

• Thinking IPs are fixed and manually configured
• Confusing load balancers with service discovery
• Assuming static routing is used

2. Which of the following is the correct DNS name format to access a Kubernetes service named myapp in namespace prod?

easy

A. prod.myapp.svc.cluster.local

B. myapp.svc.prod.cluster.local

C. myapp.prod.svc.cluster.local

D. svc.myapp.prod.cluster.local

Solution

1. Step 1: Recall Kubernetes DNS naming convention

   The format is <service>.<namespace>.svc.cluster.local.

2. Step 2: Match the service and namespace

   For service myapp in namespace prod, the DNS name is myapp.prod.svc.cluster.local.

3. Final Answer:

   myapp.prod.svc.cluster.local -> Option C

4. Quick Check:

   Service.Namespace.svc.cluster.local = B [OK]

Hint: Service DNS = service.namespace.svc.cluster.local [OK]

Common Mistakes:

• Swapping service and namespace order
• Omitting 'svc' in the DNS name
• Using incorrect domain suffix

3. Given a pod in namespace dev trying to reach a service named backend, what DNS name should the pod use to connect to the service?

medium

A. backend.dev.svc.cluster.local

B. backend.svc.dev.cluster.local

C. dev.backend.svc.cluster.local

D. backend.dev.cluster.local

Solution

1. Step 1: Understand the DNS naming pattern

   Kubernetes services are accessible via service.namespace.svc.cluster.local.

2. Step 2: Apply the pattern for service backend in namespace dev

   The correct DNS name is backend.dev.svc.cluster.local.

3. Final Answer:

   backend.dev.svc.cluster.local -> Option A

4. Quick Check:

   Service.Namespace.svc.cluster.local = A [OK]

Hint: Use service.namespace.svc.cluster.local for full DNS name [OK]

Common Mistakes:

• Mixing up namespace and service order
• Leaving out 'svc' in the DNS name
• Using incomplete domain suffix

4. A pod tries to connect to db.prod.svc.cluster.local but fails. Which of these is the most likely cause?

medium

A. The pod is using the IP address instead of DNS name

B. The pod is in the same namespace as the service

C. The cluster DNS is disabled but service exists

D. The service db does not exist in namespace prod

Solution

1. Step 1: Check if the service exists in the namespace

   If the service db is missing in prod, DNS lookup fails.

2. Step 2: Consider DNS and pod namespace

   Using DNS name requires the service to exist; pod namespace or IP usage doesn't cause DNS failure.

3. Final Answer:

   The service db does not exist in namespace prod -> Option D

4. Quick Check:

   Missing service = DNS failure [OK]

Hint: Check service existence in namespace if DNS lookup fails [OK]

Common Mistakes:

• Assuming DNS is always enabled
• Confusing pod namespace with service namespace
• Thinking IP use breaks DNS resolution

5. You have a multi-namespace Kubernetes cluster with services named api in namespaces dev and prod. How can a pod in dev namespace connect to the api service in prod namespace using DNS?

hard

A. Use the full DNS name api.prod.svc.cluster.local

B. Use just api since it resolves across namespaces

C. Use api.dev.svc.cluster.local and specify namespace in config

D. Use the IP address of the prod service directly

Solution

1. Step 1: Understand cross-namespace DNS resolution

   Within a namespace, service names resolve locally; cross-namespace requires full DNS name.

2. Step 2: Apply full DNS name for cross-namespace access

   To reach api in prod from dev, use api.prod.svc.cluster.local.

3. Final Answer:

   Use the full DNS name api.prod.svc.cluster.local -> Option A

4. Quick Check:

   Cross-namespace = full DNS name [OK]

Hint: Cross-namespace access needs full DNS name service.namespace.svc.cluster.local [OK]

Common Mistakes:

• Assuming service name alone resolves across namespaces
• Using wrong namespace in DNS name
• Relying on IP addresses which can change