DEV Community

Cover image for POD Design
Deepak Porwal
Deepak Porwal

Posted on

POD Design

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

# 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
Enter fullscreen mode Exit fullscreen mode

DEMO:

kubectl label

Selectors

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

Suppose you only want to see the prod server

kubectl get pods -l env=prod

#similarly to dev
kubectl get pods -l env=dev
Enter fullscreen mode Exit fullscreen mode

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

kubectl get pods env!=prod
Enter fullscreen mode Exit fullscreen mode

Labels In YAML file

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    env: prod
    app: nginx
spec:
  containers:
  - name: nginx
    image: democontainer
    ports:
      - containerPort: 8080
Enter fullscreen mode Exit fullscreen mode

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.

kubectl apply -f replicaset.yaml
kubectl get pods --show-labels
kubectl delete rs dporwal-replicaset
Enter fullscreen mode Exit fullscreen mode
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
Enter fullscreen mode Exit fullscreen mode

Replicaset

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

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
Enter fullscreen mode Exit fullscreen mode

Deployment

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

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
Enter fullscreen mode Exit fullscreen mode

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

Here is a strategy of rolling-out the changes.

25% max unavailable, 25% max surge

kubectl describe deployment
Enter fullscreen mode Exit fullscreen mode

Rolling strategy

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.

kubectl rollout history deployment.v1.apps/dporwal-deployment
Enter fullscreen mode Exit fullscreen mode

describe deployment version

Rollback

Lets rollback it to revision 1.

kubectl rollout undo deployment.v1.apps/dporwal-deployment --to-revision=1
Enter fullscreen mode Exit fullscreen mode

rollback

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.

$ 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
Enter fullscreen mode Exit fullscreen mode

References:
Official Documentation
Udemy Course
Getting Started with Kubernetes
Kubernetes PODs

Credit:
Zeal Vora

Top comments (0)