Shashikant shah

Saturday, 8 February 2025

What is headless service, External-IP and ExternalName.

 What is headless service:-



A Headless Service in Kubernetes is a special type of service that does not use a ClusterIP (or has None as its ClusterIP). Only DNS is automatically configured. When you run a DNS query for headless service, you will get the list of the Pods IPs, and usually, client DNS chooses the first DNS record.

Features of a Headless Service:

  1. No Load Balancing: Unlike a normal service, a headless service does not distribute traffic among its pods.

  2. Direct Pod Access: Instead of exposing a single service IP, it returns the individual pod IPs when queried through DNS.

  3. Useful for Stateful Applications: Commonly used for databases (e.g., MySQL, Cassandra) or distributed applications where each pod needs to be uniquely identified.

i) Create 3 pods with nginx replicaSet.

# vim deployment_nginx.yaml











# kubectl apply -f deployment_nginx.yaml

ii). Create a headless service.

# vim headless-service.yaml

# kubectl apply -f headless-service.yaml








Check the service name.

# kubectl get svc




Check Ips for all pods.

# kubectl get pods -o wide



 

Port 80 map to endpoints port 8080 and ClusterIp is None.

# kubectl describe svc headless-svc












Now we will check the headless service.

 all pods ips showing from other pods.

# kubectl run temporary --image=radial/busyboxplus:curl -i --tty

# nslookup  my-headless-service







Response received from the headless web service.

# curl -I <headless_service_name>

#curl -I   my-headless-service








OR

# curl -I <headless_service_name>.<namespace>.svc.cluster.<domain>

# curl -I   my-headless-service.default.svc.cluster.local






Response received from single pods.

# curl -I  <pods_name>.<headless_service_name>.<namespace>.svc.cluster.<domain>

# curl -I 192-168-1-9.my-headless-service.default.svc.cluster.local








What is ExternalName ?

ExternalName Service is a special type of Service that maps a Kubernetes Service to an external DNS name instead of forwarding traffic to internal pods. This allows you to create a Kubernetes-friendly alias for external resources like APIs, databases, or services outside the cluster.

Suppose you have an external database at db.example.com and want to access it using a Kubernetes service.

Mysql à external_service à pods (access).

ExternalName service Flow:

Define the ExternalName Service

This service will act as an alias for an external MySQL database running at mysql.example.com.

i)mysql DB pods is running with ClusterIP .

# kubectl  get pods



 # kubectl  get svc




 

 ii) Create a externalName service.

# vim  externalname-mysql-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: external-mysql

spec:

  type: ExternalName

  externalName: mysql.default.svc.cluster.local  # The actual database hostname

 

iii)  format :- <service_name>.<Namespace>.svc.cluster.<domain>

This makes external-mysql resolve to mysql.default.svc.cluster.local  inside Kubernetes.

Apply the Service

# kubectl apply -f externalname-mysql-service.yaml


iv) Deploy a MySQL Client Pod.

# vim mysql-client.yaml

apiVersion: v1

kind: Pod

metadata:

  name: mysql-client

spec:

  containers:

    - name: mysql-client

      image: mysql:latest  

      command: ["sleep", "3600"]


# kubectl apply -f mysql-client.yaml


iiv) access db external-mysql name from mysql-client pods.

#  kubectl exec -it mysql-client -- bash

# mysql -h external-mysql -u root -p








Port Forwarding for External Access.

If you need to access a pod from outside the cluster, use kubectl port-forward:


# kubectl port-forward pod/my-app-replicaset-xyz 8080:80


Now, access it from your local machine:

# curl http://localhost:8080


External IPs :- 

when you create a Service, it is assigned an external IP address that is reachable from outside the cluster. This may expose the application to security risks by allowing unauthorized access without ingress nginx.

Note :- Public IP assigned to service, nodes, and ingress.

Assign an External IP to the Node

  • Ensure the Node has an external IP address configured at the network level (e.g., a public IP assigned to the VM or physical machine).

Security:

  • Exposing Nodes with external IPs can be a security risk. Ensure proper firewall rules and network policies are in place to restrict access.

Load Balancing:

  • If you have multiple Nodes with external IPs, you may need an external load balancer to distribute traffic across them.

Cloud Environments:

  • In cloud environments (e.g., AWS, GCP, Azure), Nodes typically do not have public IPs by default. Instead, you would use a LoadBalancer Service or an Ingress Controller to expose Services.

On-Premises/Bare-Metal:

  • In on-premises or bare-metal setups, EXTERNAL-IP is commonly used because Nodes often have direct external IPs.

 

External IPs :- 

when you create a Service, it is assigned an external IP address that is reachable from outside the cluster. This may expose the application to security risks by allowing unauthorized access without ingress nginx.

Note :- Public IP assigned to service, nodes, and ingress.

Assign an External IP to the Node

  • Ensure the Node has an external IP address configured at the network level (e.g., a public IP assigned to the VM or physical machine).

Security:

  • Exposing Nodes with external IPs can be a security risk. Ensure proper firewall rules and network policies are in place to restrict access.

Load Balancing:

  • If you have multiple Nodes with external IPs, you may need an external load balancer to distribute traffic across them.

Cloud Environments:

  • In cloud environments (e.g., AWS, GCP, Azure), Nodes typically do not have public IPs by default. Instead, you would use a LoadBalancer Service or an Ingress Controller to expose Services.

On-Premises/Bare-Metal:

  • In on-premises or bare-metal setups, EXTERNAL-IP is commonly used because Nodes often have direct external IPs.




apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  selector:

    app: my-app

  ports:

    - protocol: TCP

      port: 80

      targetPort: 8080

  externalIPs:

    - 203.0.113.42  # Replace with your external IP

 



 

\

Node :- Assign an External IP to the Node

Ensure the Node has an external IP address configured at the network level (e.g., a public IP assigned to the VM or physical machine).



# kubectl get node <node-name> -o wide

Create a NodePort Service:

apiVersion: v1

kind: Service

metadata:

  name: my-service

spec:

  type: NodePort

  selector:

    app: my-app

  ports:

    - port: 80

      targetPort: 8080

      nodePort: 30080

 

#  kubectl get node <node-name> -o wide





# curl -I http://<external-ip>:30080


ExternalName vs Headless Service in Kubernetes.

ExternalName Service (DNS Alias for External Services).

Use Case: When you want to access an external database, API, or service using a Kubernetes-friendly DNS name.

 1.Does not create a ClusterIP, Pod, or Endpoints.
 2.Works as a CNAME (DNS alias) to an external service.
 3.Used for external services like AWS RDS, external MySQL, APIs, etc.
 4.No internal load balancing (DNS resolves to external IP).

 

Headless Service (Cluster-internal DNS without LoadBalancer).

A Headless Service is a service that does not have a ClusterIP and directly exposes Pod IPs.

Use Case: When you need direct access to pods (e.g., databases, StatefulSets, or service discovery).

 1.No ClusterIP, uses None instead.
 2.Returns Pod IPs directly in DNS lookup.
 3.Used for internal communication (e.g., databases like MySQL, PostgreSQL).
 4.Supports service discovery (e.g., coredns).
 5.Works with StatefulSets to provide stable DNS names for each pod.

Feature

Headless Service

ExternalName Service

ClusterIP

None (no ClusterIP)

No ClusterIP

Traffic Flow

Direct to Pod IPs

Direct to external hostname

Use Case

Internal Service Discovery (e.g., MySQL, StatefulSets)

External Services (e.g., AWS RDS, external APIs)

DNS Resolution

Returns Pod IPs

Returns CNAME (external DNS)

Load Balancing

No Kubernetes load balancing, clients handle it

No load balancing, only DNS resolution

Works with StatefulSet?

Yes

No

Works with External Services?

No

Yes

 

No comments:

Post a Comment