Session 5 - Application Deployment, Resources & Healthcheck Probes

Types of Workloads: https://kubernetes.io/docs/concepts/workloads/controllers/

Deployment:
- Replicaset
Statefulset:
Daemonset:
Jobs / CronJob

1.Deployment:

One Deployment -> One Replicaset -> Multiple Pods

A Deployment owns and manages one or more ReplicaSets. And Replica Set manages the basic units in Kubernetes, which is the Pods.

Kubernetes creates a new ReplicaSet each time after the new Deployment config is deployed and also keeps the old ReplicaSet so that it can Rollback. And there is only one ReplicaSet is in active state at any one time.

Labels are nothing more than custom key-value pairs that are attached to objects and are used to describe and manage different Kubernetes resources. Labels can be used by both Kubernetes and homo-sapiens to organize and to select subsets of objects. When dealing with Kubernetes config files, labels are always added under the “metadata” section of the manifest.

Copied to clipboard!

apiVersion: v1

kind: Deployment

metadata:

name: label-demo

labels:

environment: qa

app: nginx

release: stable

tier: backend

partition: customerA

What are selectors?

A label selector is just a fancy name of the mechanism that enables the client/user to target (select) a set of objects by their labels.

apiVersion: v1

kind: Deployment

metadata:

name: app

labels:

env: prod

spec:

replicas: 3

selector:

matchLabels:

component: eshop

https://gitlab.com/jayaramk/springboot/-/blob/main/deployment/basic-java-deployment.yaml

2.Resource Requests and Limits

https://gitlab.com/jayaramk/springboot/-/blob/main/deployment/deployment-with-resources.yaml

resources:

requests:

memory: "64Mi"

cpu: "100m"

limits:

memory: "512Mi"

cpu: "500m"

4.Liveness, Readiness and Startup Health Check Probes :

https://gitlab.com/jayaramk/springboot/-/blob/main/deployment/deployment-probes.yaml

Configure Probes

Probes have several fields that you can use to more precisely control the behavior of liveness and readiness checks:

initialDelaySeconds: Number of seconds after the container has started before liveness or readiness probes are initiated.
Defaults to 0 seconds. The minimum value is 0.
periodSeconds: How often (in seconds) to perform the probe.
Default to 10 seconds. The minimum value is 1.
timeout seconds: Number of seconds after which the probe times out.
Defaults to 1 second. The minimum value is 1.
success threshold: Minimum consecutive successes for the probe to be considered successful after having failed.
Defaults to 1. Must be 1 for liveness. The minimum value is 1.
failure threshold: Minimum consecutive fails for the probe to be considered restarting the container. In the case of readiness probe, the Pod will be marked Unready.
Defaults to 3. The minimum value is 1.

livenessProbe:

httpGet:

path: /

port: 8081

failureThreshold: 1

periodSeconds: 30

# Check for livenss every 30 seconds

startupProbe:

httpGet:

path: /

port: 8081

failureThreshold: 2

# it is OK to fail twice at startup

initialDelaySeconds: 10

# Longer Initial delay of 10 seconds

periodSeconds: 10

readinessProbe:

httpGet:

path: /

port: 8081

failureThreshold: 1

periodSeconds: 10