Mastering Kubernetes Services: From Creation to External Exposure
This guide walks through Kubernetes Service fundamentals, including creating services, configuring session affinity, exposing multiple ports, using named ports, discovering services via environment variables and DNS, managing Endpoints, and exposing services externally through NodePort, LoadBalancer, and Ingress with TLS support.
Service Overview
Kubernetes Service provides a stable virtual IP and port that load‑balances traffic to a set of Pods matching a label selector. The Service IP (ClusterIP) and port remain constant while the backing Pods may be created or destroyed.
Creating a Service
apiVersion: v1
kind: Service
metadata:
name: kubia
spec:
selector:
app: kubia
ports:
- port: 80 # Service port
targetPort: 8080 # Container portApply the manifest: kubectl create -f kubia-svc.yaml The Service receives a ClusterIP (e.g., 10.96.191.193) that can be accessed from any Pod using curl or other clients.
Session Affinity
To keep all requests from the same client IP on the same backend Pod, set sessionAffinity: ClientIP:
apiVersion: v1
kind: Service
metadata:
name: kubia
spec:
sessionAffinity: ClientIP
selector:
app: kubia
ports:
- port: 80
targetPort: 8080Multiple Ports
A Service can expose several ports that map to the same or different container ports:
apiVersion: v1
kind: Service
metadata:
name: kubia
spec:
selector:
app: kubia
ports:
- name: http
port: 80
targetPort: 8080
- name: https
port: 443
targetPort: 8080Named Ports
Define a name for the container port in the Pod (or ReplicationController) spec and reference that name in the Service targetPort:
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia
spec:
replicas: 3
selector:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: ksfzhaohui/kubia
ports:
- name: http
containerPort: 8080 apiVersion: v1
kind: Service
metadata:
name: kubia
spec:
selector:
app: kubia
ports:
- port: 80
targetPort: http # reference by nameService Discovery
Environment Variables
If a Service exists before a Pod starts, the Pod receives environment variables such as KUBIA_SERVICE_HOST and KUBIA_SERVICE_PORT that contain the Service IP and port.
DNS
Kubernetes runs a DNS server (kube‑dns / CoreDNS). Pods can resolve a Service by its fully qualified domain name <service>.<namespace>.svc.cluster.local or simply by <service> when in the same namespace.
Endpoints
Endpoints map a Service to the actual IP addresses and ports of the backing Pods. When a Service has no selector, you must create an Endpoints object manually.
apiVersion: v1
kind: Endpoints
metadata:
name: external-service
subsets:
- addresses:
- ip: 172.17.0.9
- ip: 172.17.0.10
ports:
- port: 8080Exposing Services Outside the Cluster
NodePort
Assign a static port on every node. Clients connect to <node‑IP>:<nodePort>, which forwards to the Service.
apiVersion: v1
kind: Service
metadata:
name: kubia-nodeport
spec:
type: NodePort
selector:
app: kubia
ports:
- port: 80
targetPort: 8080
nodePort: 30123Retrieve the node IP with kubectl get nodes -o wide and access the Service via <node‑IP>:30123.
LoadBalancer
In cloud environments, type: LoadBalancer provisions an external load balancer with its own public IP.
apiVersion: v1
kind: Service
metadata:
name: kubia-loadbalancer
spec:
type: LoadBalancer
selector:
app: kubia
ports:
- port: 80
targetPort: 8080Minikube does not allocate a real external IP; the EXTERNAL-IP remains pending.
Ingress
An Ingress controller routes HTTP/HTTPS traffic based on host and path rules, allowing many Services to share a single external IP.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kubia
spec:
rules:
- host: kubia.example.com
http:
paths:
- path: /
backend:
serviceName: kubia-nodeport
servicePort: 80Enable an Ingress controller (e.g., minikube addons enable ingress) before creating the Ingress resource.
TLS for Ingress
Generate a certificate and key, store them in a TLS secret, and reference the secret in the Ingress tls section.
# Generate key and cert
openssl genrsa -out tls.key 2048
openssl req -new -x509 -key tls.key -out tls.cert -days 365 -subj "/CN=kubia.example.com"
# Create secret
kubectl create secret tls tls-secret --cert=tls.cert --key=tls.key
# Ingress with TLS
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kubia
spec:
tls:
- hosts:
- kubia.example.com
secretName: tls-secret
rules:
- host: kubia.example.com
http:
paths:
- path: /
backend:
serviceName: kubia-nodeport
servicePort: 80External Traffic Policy (Local)
To avoid an extra network hop when accessing a NodePort, set externalTrafficPolicy: Local so that traffic is only forwarded to Pods running on the same node that received the request.
apiVersion: v1
kind: Service
metadata:
name: kubia-nodeport-onlylocal
spec:
type: NodePort
externalTrafficPolicy: Local
selector:
app: kubia
ports:
- port: 80
targetPort: 8080
nodePort: 30124External Services
Manual Endpoints (internal IPs)
If a Service has no selector, create an Endpoints object with the desired IPs and ports.
apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
ports:
- port: 80
targetPort: 80 apiVersion: v1
kind: Endpoints
metadata:
name: external-service
subsets:
- addresses:
- ip: 172.17.0.9
- ip: 172.17.0.10
ports:
- port: 8080ExternalName Service
Map a Service to an external DNS name using type: ExternalName:
apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
type: ExternalName
externalName: api.ksfzhaohui.com
ports:
- port: 80Pod Readiness Probes
Readiness probes determine whether a Pod is ready to receive traffic. Types include exec, httpGet, and tcpSocket. Pods that fail the probe are removed from Service endpoints until they become ready.
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia
spec:
replicas: 3
selector:
app: kubia
template:
metadata:
labels:
app: kubia
spec:
containers:
- name: kubia
image: ksfzhaohui/kubia
ports:
- containerPort: 8080
readinessProbe:
exec:
command:
- ls
- /var/readyWhen a Pod is deleted, a new Pod with the probe is created; until the probe succeeds, the READY column shows 0/1.
Summary
The article covers the fundamentals of Kubernetes Services, Service discovery via environment variables and DNS, the role of Endpoints, and three primary methods—NodePort, LoadBalancer, and Ingress—to expose Services to external clients, including TLS configuration and readiness probing.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
