Kubernetes - Objects - Deeper Dive

By Chetan Shah
Kubernetes Objects
K8S - Objects - Common Use Cases

This and following few slides highlight the use cases for the different K8S
objects:

Jobs

CronJobs

DaemonSets

StatefulSets
K8S - Jobs - Common Use Cases

Objects like the Deployments, ReplicaSets, StatefulSets, and DaemonSets solve

use-cases that require Pods to run forever.

Jobs on the other hand, just need to run to completion.

These are commonly used in:

● Video Rendering
● Database Maintenance (backup, purging, indexing)
● Sending bulk emails
● Scientific applications
K8S - CronJobs - Common Use Cases

Think of any activity that needs to be performed at an interval of time only:

salary calculation, daily / monthly / quarterly report creation, reminders etc.

● Consider a cron that runs once a week for 15 minutes.

● In any old environment, the machine running that cron is sitting idle 99.85%
of the time.
● With Kubernetes CronJob, compute resources (CPU, memory) are only
used during the lifetime of a cron invocation.
● The rest of the time, Kubernetes can efficiently use those resources to run
other CronJobs or scale down the cluster all together.
K8S - CronJobs - Common Use Cases

Other common use cases:

● BOD / EOD / BOM / EOM / BOY / EOY processing

● Database Maintenance (backup, purging, indexing)
● Sending bulk emails
● Scientific applications
K8S - DaemonSet - Common Use Cases
● Any activity that needs to be run on all or select nodes can be run as a
DaemonSet.
● DaemonSet helps to overcome any scheduling limitations.
● It makes sure that a specific app gets deployed on all the nodes within the
cluster.
● The deployed Pods usually contain background processes that need to be
disseminated throughout the entire cluster.

Commonly used for: Resource Monitoring, Log collection, Cluster Storage.

Ref: https://phoenixnap.com/kb/kubernetes-daemonset
K8S - StatefulSet - Common Use Cases
● Most of the applications considered are Stateless, where the PODs are
ephemeral, that is not permanent in nature.
● But, it many scenarios like Database PODs, ElasticSearch PODs, Splunk
PODs, the POD need to maintain the state.
K8S - StatefulSet - Common Use Cases
● Stateful applications typically involve some database, such as Cassandra,
MongoDB, or MySQL and processes a read and/or write to it. Typically, it
will involve requests being processed based on the information provided.
The prior request history impacts the current state; hence, the server must
access and hold onto state information generated during the processing of
the earlier request, which is why it is called stateful.
● Almost all the applications with modern workloads, such as AI/ML,
financial data, and genomics sequencing are stateful and require
persistent storage.
K8S - StatefulSet - Common Use Cases
Databases and messaging–Some applications recommend local flash for low
latency. Using local flash on the POD’s worker nodes will limit the capabilities of
moving containers between different worker nodes in the POD for additional
agility. That is the reason why a high-performance shared storage like Weka,
one that can provide the same or better latency while allowing for shared high
performance data, would allow effectively using applications such as these:
– Single-instance databases like MySQL, PostgreSQL, MariaDB
– NoSQL databases like Cassandra and MongoDB
– In-memory databases like Redis and MemSQL and KDB+
– Messaging apps like Kafka
– Business critical apps like Oracle, SQL server, and SAP
K8S - Init Containers - Common Use Cases
myapp.yaml
Init Containers are ones which run before any services.yaml
apiVersion: v1
other container in a POD. These are needed to kind: Pod ---
ensure some required services are running before metadata: apiVersion: v1
name: myapp-pod kind: Service
the PODs main application containers are running.
metadata:
labels:
app: myapp name: myservice
kubectl apply -f myapp.yaml spec:
spec:
kubectl get -f myapp.yaml ports:
containers:
kubectl describe -f myapp.yaml - name: myapp-container - protocol: TCP
port: 80
image: busybox:1.28
targetPort
kubectl apply -f services.yaml command: ['sh', '-c', 'echo The app is running! && sleep
3600'] : 9376
kubectl get -f myapp.yaml ---
initContainers:
apiVersion: v1
- name: init-myservice
image: busybox:1.28 kind: Service
command: ['sh', '-c', "until nslookup myservice.$(cat metadata:
name: mydb
/var/run/secrets/kubernetes.io/serviceaccount/namespace)
spec:
.svc.cluster.local; do echo waiting for myservice; sleep 2;
done"] ports:
- protocol: TCP
- name: init-mydb
port: 80
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat targetPort: 9377
/var/run/secrets/kubernetes.io/serviceaccount/namespace)
.svc.cluster.local; do echo waiting for mydb; sleep 2; done"]