In this lab, we will have a closer look at Kubernetes Replicasets. First, we will learn how ReplicaSets control, how many POD replicas are up and running at any time. We will learn, how ReplicaSets and PODs are connected: via labels. We will show that manually creating PODs with matching labels can have weird cuckoo's eggs effects. Moreover, a POD can be detached from a ReplicaSet without stopping it by manipulating its label.
In this Kubernetes lab, we will explore Kubernetes Jobs and CronJobs. Unlike Kubernetes Deployments, Kubernetes Jobs are designed to quit after they have accomplished the task (successful or not). Kubernetes CronJobs are the jobs that are repeated according to a schedule pattern Linux administrators know from crontab.
In this lab, we will explore the Kubernetes API. We will read and create PODs before we explore the API resources.
In this LSF458 lab (originally Excercise 4.3 and 4.4), we will explore how to manage maintenance modes of nodes in a Kubernetes cluster. For that, we will deploy a complex example, before we drain the node. Step 0: Enter Kubernetes…
This lab is concentrating on Kubernetes Resource Management. We will explore Limit Ranges applied to each container as well as Resource Quotas that limit the allowed sum resources of a namespace.
In part 3 of the Certified Kubernetes Administrator Labs Challenge, we will deploy a simple application by file and by command. Then we will expose and access the service from within the Kubernetes Cluster. After that, we will explore how Kubernetes Deployments helps us maintain the service by automatically restarting failed PODS through ReplicaSets. Last, but not least, we will discuss how to access the service from outside the Kubernetes cluster.
For the Certified Kubernetes Administrator Labs Challenge, I have decided to use the Katakoda Kubernetes Playground. This way, I do not need to install any Kubernetes cluster before starting the labs. This will be tested now.
The Challenge: perform all eleven labs of LSF558 as a path towards the Certified Kubernetes Administrator (CKA) exam within a day.
Three ways of installing Metricbeat (a performance monitoring solution) on Kubernetes are compared: native vs. helm with set options vs helm with values options. Metricbeat helps us monitoring performance indicators like CPU, Memory, Disk and many more on your Kubernetes nodes. We will show that (and why) installing Metricbeat via helm based on values file is the quickest way of installing Metricbeat. You just need to copy the Metricbeat chart's values file, adapt it to your needs and run a helm command in order to roll out the Metricbeat agent to all nodes of your Kubernetes cluster.