Cloud Native 28 min read

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.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Mastering Kubernetes Services: From Creation to External Exposure

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 port

Apply 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: 8080

Multiple 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: 8080

Named 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 name

Service 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: 8080

Exposing 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: 30123

Retrieve 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: 8080

Minikube 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: 80

Enable 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: 80

External 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: 30124

External 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: 8080

ExternalName 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: 80

Pod 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/ready

When 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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeKubernetesServiceIngressNodePortloadbalancerEndpoints
IT Architects Alliance
Written by

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.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.