# 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 `Services`creates tremendous possibilities.&#x20;

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.&#x20;

![](https://1428106809-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lgdm3UFnV6WaB2JJ10k%2F-Li9eP_MLlpf-pSOpVsJ%2F-Li9edz5X3UlTNjX-52H%2FScreen%20Shot%202019-06-24%20at%2011.04.51%20AM.png?alt=media\&token=4b558baa-3084-46d7-ac87-498046983fac)

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.&#x20;

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

{% embed url="https://www.youtube.com/watch?v=PH-2FfFD2PU" %}

## Example

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

```yaml
#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.

```yaml
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.&#x20;
* **Updating an app** ( in a pod)can be as simple as
  * &#x20;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

