POD Design
Tags: kubernetes, devops, docker, opensource
Published: 2022-01-28 07:19:26

### Labels

Labels are nothing but the tags to the kubernetes object for the identification. Doubtfulness of the servers would lead to mistakes on stopping or terminating.
_AWS TAG_ = _Labels_

Labels are key/value pairs that are attached to objects, such as pods.

eg: 
name: dporwal-server
env: prod

#### Set Labels to the kubernetes objects

```shell
# creating pods
kubectl run nginx --image=nginx
kubectl run nginx2 --image=nginx

#give label to pods
kubectl label pods nginx env=dev
kubectl label pods nginx2 env=prod

#see labels of pods
kubectl get pods --show-labels
```

DEMO:

![kubectl label](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4o2q08kv5b1iubg1zh1g.gif)

### Selectors

Basically to filter-out the k8s objects is the functionality of selectors.

Suppose you only want to see the prod server

```shell
kubectl get pods -l env=prod

#similarly to dev
kubectl get pods -l env=dev
```

Suppose you want to get all the pods that are not prod.

```shell
kubectl get pods env!=prod
```

#### Labels In YAML file

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    env: prod
    app: nginx
spec:
  containers:
  - name: nginx
    image: democontainer
    ports:
      - containerPort: 8080
```

### ReplicaSets (_AWS = Auto Scalling_)

A ReplicaSet purpose is to maintain a stable set of replica Pods running at any given of time.

Desired State - Number of Pods you want
Current State - Number of Pods are currently running

It always try to maintain the Desired State with the current state.

We will create YAML file to launch our first ReplicaSet.

```shell
kubectl apply -f replicaset.yaml
kubectl get pods --show-labels
kubectl delete rs dporwal-replicaset
```


```yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: dporwal-replicaset
spec:
  replicas: 5
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
        - name: php-redis
          image: gcr.io/google_samples/gb-frontend:v3
```

![Replicaset](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z7oqpklmc80ynquqtbzj.png)

### Deployments

Suppose replicaset is having 3 desired tomorrow you need 5, then every time we need to have make changes on replicaset.yaml. Here Deployments come for this solution

Benefits is Rolling out changes, which make the replicaset and deploy the latest version and then redirect from older version replicaset to latest version replicaset.

#### Creating first Deployment set

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dporwal-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
        - name: php-redis
          image: gcr.io/google_samples/gb-frontend:v3
```

![Deployment](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rdjd7l8tfqtknmgm21qa.png)

Now lets suppose we made the changes and bring-up the new version.
we changed image from _gcr.io/google_samples/gb-frontend:v3_ to _nginx_

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dporwal-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
        - name: php-redis
          image: nginx
```

Now, when we will run this yaml file, it will bring the previous version replicaset down and will create a new replicaset.
let me show you.

![new revision Deployment](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xaxnuv0d5mqb2gjlf3p5.png)
 
Here is a strategy of rolling-out the changes.

***25% max unavailable, 25% max surge***

```shell
kubectl describe deployment
```

![Rolling strategy](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/687lipdn5k5xdsjl5e74.png)
 
Here Deployment ensures that only certain number of pods are down which the changes are rolling out. By default it ensures that *least 25% of desired pods are up(25% max unavailable).*
Deployments keep the history of the version that are made.
 

To check the revisions of the deployment.

```shell
kubectl rollout history deployment.v1.apps/dporwal-deployment
```

![describe deployment version](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ulx4nbigbjwp26vyt5fh.png)

### Rollback 
Lets rollback it to revision 1.

```shell
kubectl rollout undo deployment.v1.apps/dporwal-deployment --to-revision=1
```

![rollback](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8zf1ei0hh9jxkfu7wg6g.png)
 

### Deployment Configuration

There are 2 main configs for the deployments.
1. maxSurge - Max number of pods can be scheduled above the existing pods.
2. maxUnavailable - Max number of pods that can be unavailable during the update.

for eg: 
maxUnavailable=0 and maxSurge=20% << Full Capacity is maintained
maxUnavailable=10% and maxSurge=0 << Update with no extra capacity, In-place update.

Default:
maxSurge: 25%
maxUnavailable: 25%

You can edit the deployement config, by following command.

```shell
$ kubectl edit deployment dporwal-deployment

#making the changes to the deployment set and apply it
$ kubectl set image deployment dporwal-deployment nginx=nginx:alpine

#To scale Pods for the deployments
$ kubectl scale deployment dporwal-deployment --replicas=10
```

References:
[Official Documentation](https://kubernetes.io/docs/home/)
[Udemy Course](https://www.udemy.com/course/certified-kubernetes-administrator/)
[Getting Started with Kubernetes](https://dev.to/dporwal/getting-started-with-kubernetes-4mdc)
[Kubernetes PODs](https://dev.to/dporwal/kubernetes-pods-3mk5)

Credit:
[Zeal Vora](https://in.linkedin.com/in/zealvora)