As you navigate through your application’s development stages and consider Kubernetes deployment, understanding how components connect internally and externally becomes essential.

“Knowledge you will get from this article also covers ‘services & networking’ part of CKAD exam, which currently takes 13% of the certification exam curriculum.”

Services

Kubernetes services enable networking between cluster components and external systems. The article covers three main types:

NodePort — Exposes pods through a node’s port, involving three port layers:

• targetPort (application listening port)
• Port (service port)
• NodePort (external access port, range 30000-32767)

Example NodePort service:

apiVersion: v1
kind: Service
metadata:
 name: k8s-nodeport-service
spec:
 type: NodePort
 ports:
 - targetPort: 6379
   port: 6379
   NodePort: 30666
selector:
 db: redis

Services use selectors to link to pod sets, functioning as load balancers distributing traffic randomly across matching pods.

ClusterIP — Provides internal cluster communication through unified IP/name for pod groups, preventing instability from pod recreation and eliminating manual load-balancing complexity.

apiVersion: v1
kind: Service
metadata:
 name: api-1
spec:
 type: ClusterIP
ports:
- targetPort: 9090
  port: 9090
selector:
 app: api-1
 type: backend

ClusterIP serves as the default service type when unspecified.

LoadBalancer — Provisions external cloud load balancers with advanced features and standard port mapping. Each exposed service requires its own load balancer, potentially increasing complexity and costs.

apiVersion: v1
kind: Service
metadata:
 name: lb1
spec:
 externalTrafficPolicy: Local
 type: LoadBalancer
 ports:
 - port: 80
   targetPort: 80
   protocol: TCP
   name: http
 - port: 443
   targetPort: 443
   protocol: TCP
   name: https
 selector:
   app: lb1

“The external traffic will not be equally load balanced across pods, but rather equally balanced at the node level.”

Ingress

Managing multiple web servers with different pod sets using traditional services becomes complex in real-world scenarios. This complexity motivated Kubernetes to introduce Ingress as a Layer 7 load balancer solution.

Ingress provides load balancing, SSL termination, and name-based virtual hosting for HTTP/HTTPS traffic.

Ingress Controller Setup

Two components are necessary:

1. Ingress Controller — Manages ingress rules (nginx, GCE officially supported)
2. Ingress Resources — Defines HTTP routing rules

Example nginx ingress controller deployment:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: nginx-ingress-controller
spec:
 replicas: 1
 selector:
  matchLabels:
   name: nginx-ingress
 template:
  metadata:
   labels:
    name: nginx-ingress
  spec:
   containers:
   - name: nginx-ingress-controller
     image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller
     args:
     - /nginx-ingress-controller
     - configMap=$(POD_NAMESPACE)/ingress-config
     env:
     - name: POD_NAME
       valueFrom:
         fieldRef:
          fieldPath: metadata.name
     - name: POD_NAMESPACE
       valueFrom:
        fieldRef:
         fieldPath: metadata.namespace
     ports:
     - name: http
       containerPort: 80
     - name: https
       containerPort: 443

ConfigMap deployment:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configuration

A NodePort service exposes the ingress controller:

apiVersion: v1
kind: Service
metadata:
 name: nginx-ingress
spec:
 type: NodePort
 ports:
 -targetPort: 80
  port: 80
  protocol: TCP
  name: http
 -targetPort: 433
 port: 433
 protocol: TCP
 name: https
selector:
 name: nginx-ingress

Service accounts require specific permissions:

apiVersion: v1
kind: ServiceAccount
matadata:
 name: nginx-ingress-serviceaccount

Ingress Resources

Simple ingress routing all traffic to one service:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: simple-api-ingress
spec:
 backend:
  serviceName: simple-api-service
  servicePort: 8080

Path-based routing example:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: proper-api-ingress
spec:
 rules:
 -http:
   paths:
   -path: /api/search
    backend:
     serviceName: search-api-service
     servicePort: 8081
   -path: /api
    backend:
     serviceName: api-service
     servicePort: 8080
   -path: /
    backend:
     serviceName: frontend-service
     servicePort: 8082

Host-based routing with subdomains:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: proper-api-ingress
spec:
 rules:
 -host: api.example.com
  http:
   paths:
   -path: /search
    backend:
     serviceName: search-api-service
     servicePort: 8081
   -path: /
    backend:
     serviceName: api-service
     servicePort: 8080
 -host: app.example.com
  http:
   paths:
   -path: /
    backend:
     serviceName: frontend-service
     servicePort: 8082

The article emphasizes maintaining all configurations as code in version control repositories, following infrastructure-as-code principles for application reliability.