Kubernetes resources allow you to define the desired state for containerized workloads in a Kubernetes cluster. In this lab, you will have the opportunity to test your knowledge of the various ways to run these workloads. You will need to select the appropriate resource for each use case and use it to run Pods in the cluster.
Learning Objectives
Successfully complete this lab by achieving the following learning objectives:
- Run a Collection of Pods That Can Be Updated with Zero Downtime
We have a web application that needs multiple instances for reliability. These instances need to be able to scale easily, and we need to be able to roll out code changes with zero downtime. Luckily, the application itself is stateless, which should make this a bit easier.
Create an object called
webin thedefaultNamespace to manage this workload. You will need to determine the proper object type to use. Provide3replicas of the application. For now, you can just thenginx:stableimage.- Run a Collection of Stateful Pods That Need a Sticky Identity
We have another web application that is a little older. Unfortunately, it was built in a stateful fashion, and we haven’t had a chance to refactor it yet. This application will need to have a sticky identity, such as a fixed order and the sticky Pod names for all of its replicas.
Create an object called
legacyin thedefaultNamespace to run this workload, using whatever object type you think is appropriate given these requirements. It should have5replicas and use thenginx:stableimage.- Run a Containerized Task on a Schedule
Our final workload is a data cleanup task. It needs to run to completion once every minute.
Create an object called
data-cleanupin thedefaultNamespace. Once again, use the object type that you feel best meets the stated requirements. Use thebusybox:stableimage to run the commanddateonce every minute.
