Kubernetes Workloads¶
Overview¶
Kubernetes workloads are the objects that run your containerized applications. There are several different types of workloads, each with their own use cases and configuration options. This lesson will cover the following workload types:
- Pods
- Deployments
- StatefulSets
- DaemonSets
- Jobs
- CronJobs
- ReplicaSets
- Horizontal Pod Autoscalers
- PodDisruptionBudgets
Objectives¶
- Understand the different types of Kubernetes workloads
- Understand the use cases for each workload type
- Understand the configuration options for each workload type
Outline¶
- ReplicaSets
ReplicaSets are the primary method of managing Pod replicas and their lifecycle. This includes their scheduling, scaling, and deletion.
Their job is simple, always ensure the desired number of replicas that match the selector are running.
manifests/replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: example-rs
spec:
replicas: 3
selector:
matchLabels:
app: nginx
env: prod
template:
metadata:
labels:
app: nginx
env: prod
spec:
containers:
- name: nginx
image: nginx:stable-alpine
ports:
- containerPort: 80
Command
$ kubectl create -f manifests/rs-example.yaml
Watch the ReplicaSet's Pods come up:
$ kubectl get pods -l app=nginx,env=prod --watch
Scale the ReplicaSet:
$ kubectl scale replicaset example-rs --replicas=5
Create an independent Pod manually with the same labels as the one targeted by rs-example from the manifest manifests/pod-rs-example.yaml
manifests/pod-rs-example.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-example
labels:
app: nginx
env: prod
spec:
containers:
- name: nginx
image: nginx:stable-alpine
ports:
- containerPort: 80
Command
kubectl create -f manifests/pod-rs-example.yaml
Deployments¶
Deployments are a declarative method of managing Pods via ReplicaSets. They provide rollback functionality in addition to more granular update control mechanisms.
Exercise: Using Deployments¶
Objective: Create, update and scale a Deployment as well as explore the relationship of Deployment, ReplicaSet and Pod.
1) Create a Deployment deploy-example
. Configure it using the example yaml block below or use the manifest
manifests/deploy-example.yaml
. Additionally pass the --record
flag to kubectl
when you create the Deployment.
The --record
flag saves the command as an annotation, and it can be thought of similar to a git commit message.
manifests/deployment-example.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: deploy-example
spec:
replicas: 3
revisionHistoryLimit: 3
selector:
matchLabels:
app: nginx
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:stable-alpine
ports:
- containerPort: 80
Command
$ kubectl create -f manifests/deploy-example.yaml --record
2) Check the status of the Deployment.
$ kubectl get deployments
3) Once the Deployment is ready, view the current ReplicaSets and be sure to show the labels.
$ kubectl get rs --show-labels
pod-template-hash
label of the newly created ReplicaSet. The created ReplicaSet's name will
include the pod-template-hash
.
4) Describe the generated ReplicaSet.
$ kubectl describe rs deploy-example-<pod-template-hash>
Labels
and the Selectors
fields. The pod-template-hash
value has automatically been added to
both the Labels and Selector of the ReplicaSet. Then take note of the Controlled By
field. This will reference the
direct parent object, and in this case the original deploy-example
Deployment.
5) Now, get the Pods and pass the --show-labels
flag.
$ kubectl get pods --show-labels
pod-template-hash
.
6) Describe one of the Pods.
$ kubectl describe pod deploy-example-<pod-template-hash-<random>
Controlled By
field. It will contain a reference to the parent ReplicaSet, but not the parent Deployment.
Now that the relationship from Deployment to ReplicaSet to Pod is understood. It is time to update the
deploy-example
and see an update in action.
7) Update the deploy-example
manifest and add a few additional labels to the Pod template. Once done, apply the
change with the --record
flag.
$ kubectl apply -f manifests/deploy-example.yaml --record
< or >
$ kubectl edit deploy deploy-example --record
deploy
can be substituted for deployment
when using kubectl
.
8) Immediately watch the Pods.
$ kubectl get pods --show-labels --watch
strategy
stanza. For specific documentation this feature, see
the Deployment Strategy Documentation.
9) Now view the ReplicaSets.
$ kubectl get rs --show-labels
10) Now, scale the Deployment up as you would a ReplicaSet, and set the replicas=5
.
$ kubectl scale deploy deploy-example --replicas=5
11) List the ReplicaSets.
$ kubectl get rs --show-labels
12) Just as before, describe the Deployment, ReplicaSet and one of the Pods. Note the Events
and Controlled By
fields. It should present a clear picture of relationship between objects during an update of a Deployment.
$ kubectl describe deploy deploy-example
$ kubectl describe rs deploy-example-<pod-template-hash>
$ kubectl describe pod deploy-example-<pod-template-hash-<random>
Summary: Deployments are the main method of managing applications deployed within Kubernetes. They create and
supervise targeted ReplicaSets by generating a unique hash called the pod-template-hash
and attaching it to child
objects as a Label along with automatically including it in their Selector. This method of managing rollouts along with
being able to define the methods and tolerances in the update strategy permits for a safe and seamless way of updating
an application in place.
Exercise: Rolling Back a Deployment¶
Objective: Learn how to view the history of a Deployment and rollback to older revisions.
Note: This exercise builds off the previous exercise: Using Deployments. If you have not, complete it first before continuing.
1) Use the rollout
command to view the history
of the Deployment deploy-example
.
$ kubectl rollout history deployment deploy-example
revisionHistoryLimit
attribute in the Deployment spec.
2) Look at the details of a specific revision by passing the --revision=<revision number>
flag.
$ kubectl rollout history deployment deploy-example --revision=1
$ kubectl rollout history deployment deploy-example --revision=2
3) Choose to go back to revision 1
by using the rollout undo
command.
$ kubectl rollout undo deployment deploy-example --to-revision=1
--to-revision
flag can be omitted if you wish to just go back to the previous configuration.
4) Immediately watch the Pods.
$ kubectl get pods --show-labels --watch
5) Describe the Deployment deploy-example
.
$ kubectl describe deployment deploy-example
Summary: Understanding how to use rollout
command to both get a diff of the different revisions as well as
be able to roll-back to a previously known good configuration is an important aspect of Deployments that cannot
be left out.
Clean Up Command
kubectl delete deploy deploy-example
---¶
DaemonSets¶
DaemonSets ensure that all nodes matching certain criteria will run an instance of the supplied Pod.
They bypass default scheduling mechanisms and restrictions, and are ideal for cluster wide services such as log forwarding, or health monitoring.
Exercise: Managing DaemonSets¶
Objective: Experience creating, updating, and rolling back a DaemonSet. Additionally delve into the process of how they are scheduled and how an update occurs.
1) Create DaemonSet ds-example
and pass the --record
flag. Use the example yaml block below as a base, or use
the manifest manifests/ds-example.yaml
directly.
manifests/ds-example.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ds-example
spec:
revisionHistoryLimit: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
nodeSelector:
nodeType: edge
containers:
- name: nginx
image: nginx:stable-alpine
ports:
- containerPort: 80
Command
$ kubectl create -f manifests/ds-example.yaml --record
2) View the current DaemonSets.
$ kubectl get daemonset
3) Label the kind-control-plane
node with nodeType=edge
$ kubectl label node kind-control-plane nodeType=edge
4) View the current DaemonSets once again.
$ kubectl get daemonsets
ds-example
deployed.
5) View the current Pods and display their labels with --show-labels
.
$ kubectl get pods --show-labels
controller-revision-hash
label. This is used like the pod-template-hash
in a
Deployment to track and allow for rollback functionality.
6) Describing the DaemonSet will provide you with status information regarding it's Deployment cluster wide.
$ kubectl describe ds ds-example
ds
can be substituted for daemonset
when using kubectl
.
7) Update the DaemonSet by adding a few additional labels to the Pod Template and use the --record
flag.
$ kubectl apply -f manifests/ds-example.yaml --record
< or >
$ kubectl edit ds ds-example --record
8) Watch the Pods and be sure to show the labels.
$ kubectl get pods --show-labels --watch
strategy
in the form of
updateStrategy
. The defaults are generally suitable, but other tuning options may be set. For reference, see the
Updating DaemonSet Documentation.
Summary: DaemonSets are usually used for important cluster-wide support services such as Pod Networking, Logging,
or Monitoring. They differ from other workloads in that their scheduling bypasses normal mechanisms, and is centered
around node placement. Like Deployments, they have their own pod-template-hash
in the form of
controller-revision-hash
used for keeping track of Pod Template revisions and enabling rollback functionality.
Optional: Working with DaemonSet Revisions¶
Objective: Explore using the rollout
command to rollback to a specific version of a DaemonSet.
Note: This exercise is functionally identical to the ExerciseRolling Back a Deployment. If you have completed that exercise, then this may be considered optional. Additionally, this exercise builds off the previous exercise Managing DaemonSets and it must be completed before continuing.
1) Use the rollout
command to view the history
of the DaemonSet ds-example
$ kubectl rollout history ds ds-example
revisionHistoryLimit
attribute in the DaemonSet spec.
2) Look at the details of a specific revision by passing the --revision=<revision number>
flag.
$ kubectl rollout history ds ds-example --revision=1
$ kubectl rollout history ds ds-example --revision=2
3) Choose to go back to revision 1
by using the rollout undo
command.
$ kubectl rollout undo ds ds-example --to-revision=1
--to-revision
flag can be omitted if you wish to just go back to the previous configuration.
4) Immediately watch the Pods.
$ kubectl get pods --show-labels --watch
5) Describe the DaemonSet ds-example
.
$ kubectl describe ds ds-example
Summary: Being able to use the rollout
command with DaemonSets is import in scenarios where one may have
to quickly go back to a previously known-good version. This becomes even more important for 'infrastructure' like
services such as Pod Networking.
Clean Up Command
kubectl delete ds ds-example