Bird
Raised Fist0
Kubernetesdevops~5 mins

ClusterIP service type in Kubernetes - Commands & Configuration

Choose your learning style10 modes available
Introduction
Sometimes, you want your app inside a Kubernetes cluster to talk to each other but not be visible outside. ClusterIP service type helps by giving your app a private address inside the cluster for communication.
When you want to let different parts of your app talk inside the cluster but keep them hidden from the internet.
When you run a database inside Kubernetes and only your app should access it, not outside users.
When you have multiple microservices that need to connect to each other securely inside the cluster.
When you want to load balance traffic between pods but only inside the cluster network.
When you want to test internal communication between services without exposing them externally.
Config File - clusterip-service.yaml
clusterip-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
  namespace: default
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

This file creates a Service named my-app-service in the default namespace.

The selector matches pods with label app: my-app.

The service listens on port 80 and forwards traffic to port 8080 on the pods.

The type: ClusterIP means the service is only reachable inside the cluster.

Commands
This command creates the ClusterIP service in Kubernetes using the configuration file.
Terminal
kubectl apply -f clusterip-service.yaml
Expected OutputExpected
service/my-app-service created
This command checks that the service was created and shows its ClusterIP address inside the cluster.
Terminal
kubectl get services my-app-service
Expected OutputExpected
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-app-service ClusterIP 10.96.123.45 <none> 80/TCP 10s
This command shows detailed information about the service, including endpoints and ports.
Terminal
kubectl describe service my-app-service
Expected OutputExpected
Name: my-app-service Namespace: default Labels: <none> Annotations: <none> Selector: app=my-app Type: ClusterIP IP: 10.96.123.45 Port: 80/TCP TargetPort: 8080/TCP Endpoints: 10.244.1.5:8080,10.244.1.6:8080 Session Affinity: None Events: <none>
Key Concept

If you remember nothing else from this pattern, remember: ClusterIP service type exposes your app only inside the Kubernetes cluster for secure internal communication.

Common Mistakes
Setting the service type to NodePort or LoadBalancer instead of ClusterIP when internal-only access is needed.
This exposes the service outside the cluster, which can cause security risks or unwanted access.
Always use type: ClusterIP for services that should only be reachable inside the cluster.
Not matching the selector labels with the pod labels correctly.
The service will not find any pods to send traffic to, so it will have no endpoints and no traffic will flow.
Ensure the selector labels in the service exactly match the labels on the pods.
Trying to access the ClusterIP service from outside the cluster directly.
ClusterIP addresses are internal and not reachable from outside the cluster network.
Use port forwarding, a proxy, or change service type if external access is needed.
Summary
Create a ClusterIP service with a YAML file specifying selector, ports, and type ClusterIP.
Apply the service with kubectl apply and verify it with kubectl get services.
Use kubectl describe to see detailed info and confirm the service routes traffic to pods inside the cluster.

Practice

(1/5)
1. What is the primary purpose of a ClusterIP service in Kubernetes?
easy
A. To create a load balancer outside the cluster
B. To expose the service to the internet with a public IP
C. To assign a static external IP to the service
D. To provide an internal IP for pods to communicate within the cluster

Solution

  1. Step 1: Understand ClusterIP service role

    ClusterIP is designed to create an internal IP address accessible only inside the Kubernetes cluster.
  2. Step 2: Compare with other service types

    Other types like NodePort or LoadBalancer expose services externally, but ClusterIP does not.
  3. Final Answer:

    To provide an internal IP for pods to communicate within the cluster -> Option D
  4. Quick Check:

    ClusterIP = internal communication [OK]
Hint: ClusterIP is for internal pod communication only [OK]
Common Mistakes:
  • Confusing ClusterIP with LoadBalancer or NodePort
  • Thinking ClusterIP exposes service externally
  • Assuming ClusterIP assigns static external IP
2. Which of the following YAML snippets correctly defines a ClusterIP service?
easy
A. apiVersion: v1 kind: Pod metadata: name: my-service spec: containers: - name: myapp image: nginx
B. apiVersion: v1 kind: Service metadata: name: my-service spec: type: NodePort selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 8080
C. apiVersion: v1 kind: Service metadata: name: my-service spec: type: ClusterIP selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 8080
D. apiVersion: v1 kind: Service metadata: name: my-service spec: type: LoadBalancer selector: app: myapp ports: - protocol: UDP port: 80 targetPort: 8080

Solution

  1. Step 1: Check service type and selector

    apiVersion: v1 kind: Service metadata: name: my-service spec: type: ClusterIP selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 8080 uses type: ClusterIP and has a proper selector and ports defined.
  2. Step 2: Validate other options

    apiVersion: v1 kind: Service metadata: name: my-service spec: type: NodePort selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 8080 uses NodePort, not ClusterIP. apiVersion: v1 kind: Pod metadata: name: my-service spec: containers: - name: myapp image: nginx is a Pod, not a Service. apiVersion: v1 kind: Service metadata: name: my-service spec: type: LoadBalancer selector: app: myapp ports: - protocol: UDP port: 80 targetPort: 8080 uses type: LoadBalancer, not ClusterIP.
  3. Final Answer:

    YAML with type ClusterIP, selector, and TCP port -> Option C
  4. Quick Check:

    Correct YAML = apiVersion: v1 kind: Service metadata: name: my-service spec: type: ClusterIP selector: app: myapp ports: - protocol: TCP port: 80 targetPort: 8080 [OK]
Hint: ClusterIP service YAML must specify type: ClusterIP [OK]
Common Mistakes:
  • Using wrong service type like NodePort
  • Confusing Pod definition with Service
  • Omitting service type field
3. Given this service YAML with type ClusterIP, what will be the output of kubectl get svc my-service?
medium
A. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP 10.96.0.1 <none> 80/TCP 5m
B. NAME TYPE EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 192.168.1.1 80/TCP 5m
C. Error: service not found
D. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service NodePort 10.96.0.1 <none> 80:30080/TCP 5m

Solution

  1. Step 1: Understand ClusterIP service output

    ClusterIP services show a cluster internal IP and no external IP.
  2. Step 2: Match output format

    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP 10.96.0.1 <none> 80/TCP 5m shows ClusterIP type with a cluster IP and <none> external IP, matching expected output.
  3. Final Answer:

    Service listed with ClusterIP and no external IP -> Option A
  4. Quick Check:

    ClusterIP service output = NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service ClusterIP 10.96.0.1 <none> 80/TCP 5m [OK]
Hint: ClusterIP services have no external IP in kubectl output [OK]
Common Mistakes:
  • Expecting external IP for ClusterIP service
  • Confusing LoadBalancer or NodePort output
  • Assuming service not found error
4. You created a ClusterIP service but pods cannot reach it. Which YAML mistake could cause this?
medium
A. Using type: LoadBalancer instead of ClusterIP
B. Missing or incorrect selector labels in the service spec
C. Specifying targetPort as a string instead of a number
D. Omitting the metadata section

Solution

  1. Step 1: Identify service selector role

    The selector connects the service to the correct pods. If missing or wrong, no pods match.
  2. Step 2: Evaluate other options

    Type LoadBalancer changes exposure but doesn't block pod access. targetPort as string is accepted. metadata omission causes other errors but not pod reachability.
  3. Final Answer:

    Missing or incorrect selector labels -> Option B
  4. Quick Check:

    Selector connects pods = Missing or incorrect selector labels in the service spec [OK]
Hint: Check selector labels to link service and pods [OK]
Common Mistakes:
  • Ignoring selector labels importance
  • Blaming service type for pod connectivity
  • Confusing metadata omission with connectivity issues
5. You want to expose a web app only inside your Kubernetes cluster using a ClusterIP service. Which combination of YAML fields ensures this?
hard
A. spec: type: ClusterIP selector: app: webapp ports: - port: 80 targetPort: 8080
B. spec: type: NodePort selector: app: webapp ports: - port: 80 targetPort: 8080
C. spec: type: LoadBalancer selector: app: webapp ports: - port: 80 targetPort: 8080
D. spec: ports: - port: 80 targetPort: 8080

Solution

  1. Step 1: Confirm service type for internal exposure

    ClusterIP is the default and only exposes service inside the cluster.
  2. Step 2: Verify selector and ports

    Selector must match pods, and ports must map correctly for traffic routing.
  3. Final Answer:

    YAML with type ClusterIP, correct selector, and ports -> Option A
  4. Quick Check:

    ClusterIP + selector + ports = spec: type: ClusterIP selector: app: webapp ports: - port: 80 targetPort: 8080 [OK]
Hint: Use type ClusterIP with correct selector for internal-only service [OK]
Common Mistakes:
  • Using NodePort or LoadBalancer for internal-only access
  • Omitting service type defaults to ClusterIP but unclear
  • Incorrect or missing selector causing no pod matching
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard