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:
- No Load Balancing: Unlike
a normal service, a headless service does not distribute traffic among its
pods.
- Direct Pod Access:
Instead of exposing a single service IP, it returns the individual pod IPs
when queried through DNS.
- 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
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