The Power of Kubernetes Services

Application Labels and Services

A very interesting aspect of Kubernetes is Labels. The way Kubernetes uses labels with respect to Servicescreates tremendous possibilities.

At the heart of Kubernetes is a pod. A pod has running instances of Containers. When a pod is deployed in Kubernetes, typically, apart from other specifications the pod can be given labels. Ideally a pod is given a label such that one can identify which part of the overall application does the pod belong to. For e.g, if the pod being deployed is for the application frontend and within frontend the pod is running code for the login part. When the pod gets deployed it can be given that label [app=frontned, label= login]. Any other pods that may be deployed a part of this app tier are given the same labels.

By Nature pods deployed in Kubernetes are deployed on a overlay network , two pods across Kubernetes nodes or any external/ingress traffic cannot directly access pods unless a Service type resources is defined .Services enable Kubernetes to route traffic to pods. The way Services are defined is by giving the Service a label of the app to which the service should route traffic to. So when a service gets created with label login,the service will start sending traffic to pods that are part of the login app based on the label match. Services are needed both for East-West communication, when two pods with different apps need to talk to each other. Services are also needed for North-South communication, when external traffic ( outside of cluster) needs to talk to pods. Kubernetes has different Service types to address both scenarios. Some of the common services referred are below.

Service Type	Depends on	What it Does	Traffic Type Handled
Cluster IP	Cluster Network	Uses the Cluster Network to MAP pod IP/port	Internal to the Cluster
Node Port	Cluster IP	Uses a port on Kubernetes Node + creates a mapping of Node port to the Cluster -IP	External
Load Balancer	Cluster IP/Node Port	Creates an External Load Balancer that maps to either a Cluster IP/Node Port	External

The services resource constructs in Kubernetes is what generally/loosely gets referred to as Microservices. The ability to break down apps into modular components and the fact that these modules talk to each other within a Kubernetes cluster through Services probably gave birth to the term Microservices.

Time-Out: Services in Context

Before you move on to the example below, take a time-out from reading to check out this video, which breaks down the notion of services in the context of Kubernetes in five minutes:

Example

A deployment of an app 'Hello World' is below. Notice lines 4-9. These line indicate the label for the deployment.

#Hello World Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  selector:
    matchLabels:
      app: helloworld
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      containers:
      - name: helloworld
        image: boskey/helloworld
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        

A corresponding Service definition for the Deployment can be as shown below. Notice lines 5 onwards. With the selector as "app: hellowowrld" the service will forward traffic coming to port 80 on the cluster network to pods that match that label at port 80.

apiVersion: v1
kind: Service
metadata:
  name: helloworld
spec:
  selector:
    app: helloworld
  ports:
  - port: 80
    targetPort: 80
      

The Power of Services

Kubernetes Services along with label matching opens up a world of very powerful use cases. Because of label matching there is no need to understand IP addressing of pods in order to load balance traffic. As a result

• Load balancing traffic across multiple pods simplifies.

• Updating an app ( in a pod)can be as simple as

  • Deploying apps with new version labels ( e.g, v.1.5)

  • Waiting for all deployments to complete

  • Updating the corresponding Service's labels to match the new pods

• Traffic shaping: With Ingress, incoming app traffic can be split between multiple labels, making it super simple to do things like A/B testing