Here is a dump of all of my notes from the CalTech Devops PGC certificate, they aren’t in any particular order. I will only be posting from the courses I found more relevant:

There were 8 lessons in this course:

Lesson_01: Core_Concepts_of_Kubernetes

Creating and Configuring a Kubernetes Cluster

This lesson provides a step-by-step walkthrough for building a Kubernetes cluster using kubeadm, kubelet, kubectl, and containerd. The process begins by configuring hostnames for the master and worker nodes, ensuring each system is properly identified within the cluster. The master node is then initialized using kubeadm init, creating the control plane components that manage cluster operations. Learners also configure kubeconfig settings so non-root users can interact with the cluster using kubectl commands.

The lesson continues by deploying a Container Network Interface (CNI) plugin using Calico, allowing communication between pods across nodes. Once networking is established, worker nodes join the cluster using a generated join token. Verification commands such as kubectl get nodes confirm that all nodes are successfully registered and operational. By the end of the exercise, students gain hands-on experience creating a fully functional Kubernetes cluster capable of hosting containerized workloads.

Executing crictl Commands

This lesson introduces crictl, a command-line tool used to interact directly with Kubernetes container runtimes such as containerd. Learners begin by configuring runtime and image endpoints, allowing crictl to communicate with the container runtime environment. After configuration, the lesson demonstrates how to verify runtime connectivity and inspect container runtime details, providing insight into the infrastructure operating beneath Kubernetes.

Students then perform common runtime administration tasks, including listing pods, viewing container images, displaying active and inactive containers, and accessing container logs. Commands such as crictl pods, crictl images, and crictl logs provide low-level visibility into container operations that complement higher-level Kubernetes management commands. This knowledge is valuable for troubleshooting, debugging, and understanding how Kubernetes interacts with the underlying container runtime.

Configuring Pods in the Kubernetes Cluster

This lesson focuses on creating and managing Kubernetes pods using YAML configuration files. Students define pod specifications that deploy Apache HTTP Server containers, including metadata, labels, container images, and exposed ports. After validating the YAML files, pods are deployed using kubectl create -f, demonstrating how declarative configurations simplify workload management within Kubernetes environments.

The lesson also covers service creation and application connectivity. A Kubernetes Service is configured to provide a stable access point for multiple Apache pods using label selectors. Learners modify application content inside running containers and verify service functionality through ClusterIP access and curl commands. This exercise highlights the relationship between pods and services while demonstrating basic load balancing and service discovery mechanisms within a Kubernetes cluster.

Creating and Configuring the Deployment

This lesson demonstrates how Kubernetes Deployments simplify application lifecycle management by automating pod creation and maintenance. Students create a deployment using an OpenShift container image and verify its successful operation by inspecting deployment and pod status through kubectl commands. The deployment abstraction ensures desired application state is maintained and automatically recreates failed pods when necessary.

The lesson also introduces Kubernetes Services as a mechanism for exposing applications running within deployments. Learners expose the deployment on port 8080, retrieve the assigned ClusterIP, and validate connectivity using curl commands. Through this process, students gain practical experience deploying containerized applications and making them accessible within the cluster network, reinforcing core Kubernetes application deployment concepts.

Using Basic Commands of Kubernetes

This lesson serves as a comprehensive introduction to essential Kubernetes administration commands. Learners create deployments, inspect pods and deployments, generate YAML manifests, expose services, and examine cluster resources using commands such as kubectl get, kubectl describe, and kubectl expose. The exercise emphasizes understanding Kubernetes resources and how they interact within a cluster environment.

Beyond deployment management, the lesson explores namespace creation, service inspection, scaling operations, and resource administration. Students learn how to generate deployment YAML files for modification, expose applications through services, and manage resources using declarative and imperative approaches. By mastering these foundational commands, administrators gain the practical skills needed to deploy, troubleshoot, and maintain Kubernetes workloads efficiently in both development and production environments.

Lesson_02: Kubernetes_Cluster

Managing and Administering a Kubernetes Cluster

This lab introduces the foundational administrative tasks required to manage a Kubernetes cluster. The exercise begins with validating cluster certificates using kubeadm certs check-expiration, which helps administrators monitor certificate health and avoid outages caused by expired security credentials. The lab then explores cluster visibility through commands such as kubectl cluster-info and kubectl cluster-info dump, providing detailed insight into the control plane components, services, and overall cluster configuration.

The second half of the lab focuses on namespace management and API access. Namespaces are used to logically separate workloads and resources, making cluster administration more organized and secure. Students learn how Kubernetes exposes cluster information through its API and how administrators can leverage these tools for troubleshooting and operational management. By completing this lab, learners gain practical experience with certificate validation, namespace creation, and accessing cluster information through Kubernetes administrative tools.

Working with Nodes

This lab focuses on managing worker nodes within a Kubernetes cluster. It begins by examining node status using kubectl get nodes and kubectl describe node, allowing administrators to review node health, labels, conditions, and assigned workloads. Understanding node status is essential for identifying resource bottlenecks, hardware failures, or scheduling issues that could affect application performance.

The lab continues by demonstrating how to remove and re-register worker nodes using Kubernetes manifests. Learners create a node definition file, register the node, and verify its successful integration into the cluster. The exercise concludes by inspecting node conditions, capacity, and allocatable resources, reinforcing how Kubernetes tracks available CPU, memory, and other resources for scheduling decisions. This provides a strong foundation for node lifecycle management and capacity planning.

Launching a Pod and Establishing an Associated Service

This lab introduces Kubernetes Deployments and Services, demonstrating how containerized applications are deployed and exposed within a cluster. Students create a deployment manifest that launches multiple replicas of an Apache HTTP server container. By defining replicas and labels, the deployment ensures application availability and scalability while simplifying lifecycle management.

The second portion of the exercise focuses on creating a Service object that uses label selectors to route traffic to the deployed pods. This abstraction allows clients to access applications without needing to know individual pod IP addresses, which can change frequently. The lab highlights the relationship between Deployments, Pods, and Services, providing a practical example of how Kubernetes enables reliable and scalable application delivery.

Working with kubeadm

This lab explores several administrative capabilities of kubeadm, the tool commonly used to bootstrap and manage Kubernetes clusters. Students generate new join tokens that can be used to add worker nodes to an existing cluster. The lab also demonstrates how to verify certificate expiration dates, helping administrators proactively manage cluster security and avoid service disruptions caused by expired credentials.

Additionally, the exercise covers retrieving certificate encryption keys and displaying default cluster initialization settings. These tasks provide insight into the internal configuration and security mechanisms used during cluster deployment and maintenance. By the end of the lab, learners gain familiarity with key kubeadm administrative functions that support cluster growth, certificate management, and operational troubleshooting.

Launching the Kubernetes Dashboard

This lab demonstrates how to deploy and configure the Kubernetes Dashboard, a web-based graphical interface used to monitor and manage cluster resources. Students deploy the dashboard using the official manifest and verify that all supporting pods, services, and deployments are created successfully. The dashboard provides a centralized view of workloads, namespaces, nodes, and other cluster components, making administration more accessible.

The lab also covers modifying the dashboard service from a ClusterIP to a NodePort configuration, enabling access from outside the cluster. Learners identify the node hosting the dashboard and use the assigned NodePort to access the interface through a web browser. This exercise illustrates how Kubernetes services can be exposed externally and how administrators can leverage graphical tools for monitoring and troubleshooting cluster operations.

Implementing RBAC Using Namespaces

This lab focuses on Role-Based Access Control (RBAC), one of Kubernetes’ most important security features. Students begin by creating a dedicated namespace and generating user credentials through RSA key pairs and certificate signing requests. These credentials are signed using the cluster’s certificate authority, creating a secure identity that can be used for authentication within Kubernetes.

The exercise continues by creating Roles and RoleBindings that define and assign permissions to the new user. Specific permissions are granted for managing deployments, pods, and services within a designated namespace. Finally, the user credentials and contexts are configured in Kubernetes, allowing access verification. This lab provides a practical introduction to least-privilege security principles and demonstrates how RBAC helps protect cluster resources by limiting user access to only what is required.

Backing up and Restoring Etcd Cluster Data

This lab explores the backup and recovery process for etcd, the distributed key-value store that serves as Kubernetes’ primary data repository. Students begin by installing the etcd client tools and locating the etcd pod running within the cluster. By identifying connection information and authentication details, administrators gain the ability to interact directly with the cluster’s configuration database.

The lab emphasizes the importance of creating backups for disaster recovery and operational resilience. Since etcd stores critical cluster state information—including deployments, services, and configuration data—regular backups are essential for recovering from failures or accidental changes. By learning how to access, back up, and restore etcd data, students develop skills that are critical for maintaining Kubernetes cluster reliability and business continuity.

Upgrading the Kubernetes Version of a Control Plane

This lab guides students through the process of upgrading Kubernetes cluster components while maintaining cluster stability. The exercise begins with upgrading the control plane by updating kubeadm, reviewing upgrade plans, and applying the desired version. Additional steps include draining the control plane node, upgrading kubelet and kubectl, and restarting services to ensure compatibility with the new release.

After upgrading the control plane, the lab focuses on worker node upgrades. Nodes are drained, upgraded, and returned to service in a controlled manner to minimize workload disruption. The final validation step involves creating a test pod to confirm that the upgraded cluster remains fully functional. This exercise highlights the importance of following a structured upgrade process to maintain cluster availability, security, and compatibility with modern Kubernetes features.

Deploying and Verifying Kubernetes Objects

This lab introduces the process of creating and validating Kubernetes objects such as Deployments, Pods, and Services. Students create an NGINX deployment and examine the generated pod definitions to understand how Kubernetes represents application workloads. The lab demonstrates how deployment objects automatically manage underlying pods and maintain the desired application state.

The exercise also covers exposing deployments through services and inspecting object definitions using YAML and JSONPath queries. By retrieving pod IPs, statuses, and start times, learners gain practical experience with extracting operational data from Kubernetes resources. The lab reinforces how deployments, pods, and services work together while introducing powerful command-line techniques for validation, troubleshooting, and automation.

Lesson_03: Understanding_Kubernetes_Workloads

Creating a Kubernetes Pod

This lab introduces the most fundamental Kubernetes object: the Pod. Students begin by creating a dedicated namespace and then defining a pod using a YAML manifest. The pod runs an NGINX web server and includes metadata such as labels, environment information, and container port definitions. Through this exercise, learners become familiar with the structure of Kubernetes manifests and how pods serve as the smallest deployable unit within a cluster.

The second half of the lab focuses on validating and inspecting the deployed pod. Using commands such as kubectl get pods and kubectl describe pod, students examine pod status, configuration details, networking information, and runtime events. This hands-on experience provides a practical understanding of the pod lifecycle and lays the groundwork for working with more advanced Kubernetes resources such as Deployments and StatefulSets.

Creating a Multi-Container Pod

This lab demonstrates how multiple containers can run together inside a single Kubernetes pod. Students create a pod containing both an NGINX web server container and a Redis container, showcasing how related services can share networking and storage resources within the same pod. This architecture is commonly used for sidecar, helper, or tightly coupled application patterns.

The exercise then explores container-specific management tasks. Learners execute commands directly inside individual containers and review logs separately using the -c flag. By interacting with each container independently, students gain insight into how Kubernetes manages multi-container workloads while maintaining clear operational visibility. This lab reinforces the concept that a pod can function as a logical application unit containing multiple cooperating services.

Configuring a Pod Using an Init Container

This lab introduces init containers, a powerful Kubernetes feature used to perform setup tasks before the main application starts. Students create a pod containing two init containers that wait for dependent services to become available before allowing the application container to launch. This approach ensures that required resources such as databases and backend services are ready before application startup.

The lab also demonstrates creating supporting services and verifying pod state transitions. By observing how init containers execute sequentially and must complete successfully before the primary workload begins, learners gain a deeper understanding of startup dependencies and application orchestration. This technique is particularly valuable for complex microservices deployments where service readiness is critical.

Managing Container Resources with a Resource Quota

This lab focuses on controlling resource consumption within Kubernetes namespaces through Resource Quotas. Students create a dedicated namespace and define CPU and memory limits that apply to workloads running within that environment. Resource Quotas help administrators prevent individual applications from monopolizing cluster resources and ensure fair allocation across teams and projects.

To validate the quota configuration, learners deploy pods with specific CPU and memory requests and limits. They then monitor quota usage and observe how Kubernetes tracks resource consumption against predefined thresholds. This exercise demonstrates how resource governance improves cluster stability and provides administrators with tools for capacity planning and multi-tenant resource management.

Managing Static Pods

This lab explores static pods, which are managed directly by the kubelet rather than through the Kubernetes API server. Students create a static Apache web server pod by placing a manifest file in the kubelet’s monitored manifest directory. Once the file is detected, the kubelet automatically launches and maintains the pod on the worker node.

A key lesson in this exercise is the operational independence of static pods. When learners attempt to delete the pod through the control plane, the kubelet immediately recreates it because the manifest still exists locally. Only by removing the manifest file from the worker node can the pod be permanently deleted. This lab highlights how Kubernetes control plane operations differ from node-level kubelet management.

Deploying Multitier Applications Using Kubernetes

This lab demonstrates how Kubernetes can host a complete multitier application consisting of WordPress and MySQL. Students first deploy a MySQL database using a Deployment resource and configure environment variables required for database initialization. They then deploy a WordPress frontend configured to communicate with the MySQL backend, creating a classic web application architecture.

The exercise continues by exposing both applications through Kubernetes Services and converting service types to NodePort for external access. Students verify connectivity and validate that the application stack functions correctly. This lab provides a practical introduction to deploying interconnected workloads and illustrates how Kubernetes simplifies application scalability, networking, and lifecycle management.

Deploying a Voting Application

This lab introduces application deployment using a real-world microservices example: a voting application. Students create a dedicated namespace, clone a sample application repository, and deploy multiple Kubernetes resources using predefined manifests. This demonstrates how Kubernetes can orchestrate an entire application stack from a collection of YAML specifications.

After deployment, learners verify pod, service, and deployment status within the namespace. By examining application components and networking resources, students gain experience managing a multi-service workload. The lab reinforces Kubernetes concepts such as namespaces, resource isolation, and application deployment while providing a practical example of containerized application orchestration.

Managing Kubernetes Deployments and Version Control

This lab focuses on application version management using Kubernetes Deployments. Students deploy an application using a specific container image version and record deployment history. Kubernetes automatically tracks rollout changes, providing administrators with visibility into application updates and configuration modifications.

The exercise then demonstrates upgrading the application image and reviewing rollout history before reverting to a previous version when necessary. This rollback capability is one of Kubernetes’ most valuable operational features, allowing administrators to quickly recover from failed releases. The lab highlights how Deployment objects support continuous delivery practices while reducing risk during application updates.

Creating and Configuring the Metrics Server

This lab introduces the Kubernetes Metrics Server, a critical component for monitoring resource utilization. Students first deploy a sample application and verify its operation before installing the Metrics Server. The Metrics Server collects CPU and memory metrics from nodes and pods, enabling administrators to monitor cluster health and resource consumption.

The lab also covers troubleshooting and patching the Metrics Server to ensure it reaches a healthy operational state. Once configured, learners can retrieve resource metrics and identify heavily utilized workloads. This exercise establishes the foundation for advanced monitoring and serves as a prerequisite for features such as Horizontal Pod Autoscaling.

Configuring a DaemonSet

This lab demonstrates how DaemonSets ensure that a specific pod runs on every node in a Kubernetes cluster. Students create a DaemonSet manifest that deploys an Apache web server container to all available nodes. Unlike Deployments, which focus on replica counts, DaemonSets guarantee node-wide coverage.

After deploying the DaemonSet, learners verify its status and observe how Kubernetes automatically schedules one pod per node. This deployment model is commonly used for logging agents, monitoring tools, security scanners, and networking services. The lab highlights how DaemonSets simplify cluster-wide application distribution and management.

Configuring ConfigMaps

This lab introduces ConfigMaps as a mechanism for separating configuration data from application code. Students create a ConfigMap containing database-related settings and deploy it into the cluster. By externalizing configuration values, Kubernetes enables applications to be easily adapted across different environments without modifying container images.

The lab then demonstrates injecting ConfigMap values into pods as environment variables and validating their availability within running containers. Students also explore creating services associated with these pods. This exercise highlights best practices for configuration management and demonstrates how ConfigMaps improve application portability, maintainability, and operational flexibility.

Creating Jobs

This lab focuses on Kubernetes Jobs, which are designed to execute finite tasks rather than continuously running services. Students create a Job resource that launches a container to calculate digits of Pi using a Perl script. Unlike Deployments, Jobs track task completion and terminate successfully once the workload finishes.

The exercise includes monitoring pod creation, validating Job execution, and reviewing generated logs. Students learn how Kubernetes handles retries using the backoffLimit setting and ensures reliable completion of batch workloads. This lab provides practical experience with one-time task execution and introduces concepts commonly used in data processing, automation, and scheduled operations.

Configuring Pods Using Liveness Probes

This lab demonstrates how liveness probes help Kubernetes maintain application health. Students create a pod configured with an exec-based liveness probe that periodically checks for the existence of a file within the container. When the file is removed, the probe fails and Kubernetes automatically restarts the container.

By examining pod events and status information, learners observe how Kubernetes detects unhealthy workloads and performs self-healing actions. This lab highlights the importance of health checks in production environments and shows how liveness probes improve application reliability by automatically recovering from failure conditions.

Configuring Horizontal Pod Autoscaling (HPA)

This lab introduces Horizontal Pod Autoscaling, a Kubernetes feature that automatically adjusts the number of pod replicas based on resource utilization. Students deploy a sample web application and define CPU resource requests that serve as the basis for scaling decisions. They then create an HPA resource that monitors CPU usage and scales replicas when utilization exceeds a defined threshold.

The exercise concludes by verifying the autoscaler configuration and monitoring deployment behavior. Learners see how Kubernetes dynamically responds to workload demand by increasing or decreasing pod counts. This lab demonstrates a key cloud-native capability that improves application performance, resource efficiency, and operational scalability without requiring manual intervention.

Lesson_04: Scheduling

Configuring Pods with nodeName and nodeSelector Fields

This lab introduces Kubernetes scheduling controls by demonstrating how to place pods on specific nodes using the nodeName and nodeSelector fields. Students create a pod that is explicitly assigned to a designated worker node using the nodeName parameter and then verify its placement using Kubernetes inspection commands. This approach provides direct control over pod scheduling and is useful for workloads that require dedicated hardware, licensing constraints, or specialized node resources.

The exercise then expands into label-based scheduling by assigning labels to nodes and creating pods that use nodeSelector to target those labels. Finally, learners explore node affinity using the NotIn operator to influence scheduling decisions based on node attributes. This lab provides a strong foundation in Kubernetes scheduling strategies and demonstrates how labels and affinity rules offer more flexible alternatives to hard-coded node assignments.

Configuring Pod Affinity and Anti-affinity in Kubernetes

This lab focuses on advanced pod placement using affinity and anti-affinity rules. Students begin by deploying a Redis cache application configured with pod anti-affinity rules that prevent Redis instances from being scheduled on the same node. By spreading replicas across multiple hosts, Kubernetes improves fault tolerance and reduces the risk of a single node failure impacting all application instances.

The second portion of the lab introduces pod affinity by deploying web server pods that are intentionally colocated with Redis cache instances. This placement strategy improves communication efficiency by keeping related workloads on the same nodes while still maintaining separation between identical workloads through anti-affinity rules. The exercise demonstrates how affinity policies can improve both resilience and application performance in distributed Kubernetes environments.

Working with a Kubernetes Security Context

This lab introduces Kubernetes Security Contexts, which allow administrators to define security settings for pods and containers. Students create a pod configured with specific user IDs, group IDs, filesystem group ownership, and restrictions such as disabling privilege escalation. These settings help enforce the principle of least privilege and improve container security by limiting what applications can do within the cluster.

After deploying the pod, learners access the running container and inspect process ownership, mounted volumes, and file permissions. By creating files and verifying user and group IDs from within the container, students gain hands-on experience with how Security Context settings influence runtime behavior. This lab highlights a critical Kubernetes security feature used to strengthen workload isolation and reduce operational risk.

Creating and Configuring Pod Priority

This lab demonstrates how Kubernetes prioritizes workloads through Priority Classes. Students create a custom PriorityClass resource with a defined scheduling value and descriptive metadata, then examine its configuration using Kubernetes management commands. Priority Classes allow administrators to classify workloads according to business importance and influence scheduling decisions when cluster resources become constrained.

The lab continues by assigning the custom priority class to a pod and verifying that the workload inherits the configured scheduling priority. Through this process, learners see how Kubernetes uses priority levels to determine which workloads should receive preference during scheduling and resource contention events. This capability is particularly important in production environments where mission-critical applications must remain available even when resources are limited.

Deploying the Flask Application with Redis

This lab provides a complete end-to-end example of building, containerizing, publishing, and deploying an application in Kubernetes. Students create a simple Flask web application that uses Redis as a backend data store to track page visits. They then build a custom Docker image, create a Dockerfile and requirements file, tag the image, authenticate with Docker Hub, and push the image to a container registry.

The second half of the exercise focuses on deploying both Redis and Flask into Kubernetes using Deployment and Service resources. Learners create separate deployments for the database and application tiers, expose them through Kubernetes services, and verify connectivity between the components. This lab ties together Docker image creation, container registries, Kubernetes deployments, and service networking, providing a practical example of how modern microservices applications are deployed and managed in cloud-native environments.

Lesson_05: Services_Load_Balancing_and_Networking

Deploying a Multi-Port Service Pod

This lab demonstrates how to deploy an application that listens on multiple ports and expose those ports through a Kubernetes Service. The exercise begins by creating an OpenShift deployment using a YAML manifest that defines a container with two exposed container ports, 8080 and 8888. After creating the deployment, the lab verifies that the pod and deployment are running successfully using standard Kubernetes commands.

The second part focuses on creating a multi-port Service that maps multiple service ports to the container ports running inside the pod. This is a common requirement for applications that provide different services or interfaces on separate ports. By completing the lab, administrators gain experience defining Service resources, understanding port mappings, and validating connectivity to applications through multiple network endpoints within a Kubernetes cluster.

Configuring the DNS for Kubernetes Services and Pods

This lab explores how Kubernetes DNS works and how CoreDNS provides name resolution services throughout the cluster. The exercise begins by examining the CoreDNS deployment, pods, services, and endpoints within the kube-system namespace. Understanding these components helps administrators troubleshoot service discovery issues and verify that DNS infrastructure is operating correctly.

The lab then demonstrates how DNS is used in practice by deploying an NGINX application and creating a service for it. Additional exercises cover DNS queries, DNS policies, and custom DNS configurations for pods. By the end of the lab, readers gain a practical understanding of Kubernetes service discovery, internal DNS resolution, and the mechanisms that allow applications to locate and communicate with one another using service names instead of IP addresses.

Configuring EndpointSlice

This lab introduces EndpointSlices, a modern Kubernetes resource designed to improve scalability and efficiency when tracking service endpoints. The exercise starts by deploying a frontend application with multiple replicas and exposing it through a Kubernetes Service. Participants then examine the automatically generated EndpointSlice resources and observe how Kubernetes associates backend pod endpoints with services.

The lab continues by creating a custom EndpointSlice using a YAML manifest. Users define endpoint addresses, ports, hostnames, and node information before applying the configuration to the cluster. Through this process, administrators learn how EndpointSlices provide a more scalable alternative to traditional Endpoints resources and how they support service discovery, load balancing, and traffic distribution in larger Kubernetes environments.

Setting up an Ingress Controller with Transport Layer Security

This lab demonstrates how to secure application access using an Ingress controller and TLS encryption. The exercise begins by deploying the NGINX Ingress Controller, verifying its components, and preparing the cluster to route external traffic into Kubernetes workloads. Participants then deploy two sample applications and expose them as services that will later be accessed through Ingress rules.

The second portion focuses on security by generating a self-signed SSL certificate and creating a Kubernetes TLS secret. An Ingress resource is then configured to terminate HTTPS traffic and route requests to the appropriate backend service. Through this lab, readers gain practical experience implementing encrypted application access, managing TLS certificates, and configuring Ingress resources to provide secure and centralized traffic management for Kubernetes applications.

Blocking All Traffic from an Application

This lab introduces Kubernetes Network Policies by implementing a deny-all policy for a specific application. The exercise begins by deploying an NGINX pod and exposing it as a service. Connectivity is verified using a temporary test pod to confirm that traffic can initially reach the application before any restrictions are applied.

Next, a NetworkPolicy is created with an empty ingress rule set, effectively blocking all incoming traffic to the targeted pod. The lab concludes by validating that communication attempts fail once the policy is enforced. This exercise highlights the importance of default-deny security models and demonstrates how Kubernetes Network Policies can be used to reduce attack surfaces and strengthen application security.

Limiting the Traffic to an Application

This lab expands on Network Policy concepts by implementing controlled access rather than completely blocking traffic. Participants deploy an API server application labeled with specific metadata and then create a NetworkPolicy that allows traffic only from pods matching designated labels. This approach introduces label-based access control within Kubernetes networking.

After applying the policy, the lab tests connectivity from both authorized and unauthorized pods. Requests originating from pods without the required labels are denied, while traffic from approved pods is allowed. Through this exercise, administrators learn how to create granular network segmentation rules that support least-privilege communication models while maintaining required application connectivity.

Blocking All the Traffic from Other Namespaces

This lab demonstrates namespace isolation using Kubernetes Network Policies. The exercise begins by deploying a web service in the default namespace and then creating a policy that allows communication only from pods within the same namespace. This configuration provides a simple but effective method of restricting cross-namespace communication.

To validate the policy, a new namespace is created and test pods are launched from both namespaces. The results show that traffic originating from the external namespace is blocked, while pods in the default namespace retain access to the service. By completing this lab, readers gain a practical understanding of namespace-based segmentation and how Network Policies can be used to establish stronger security boundaries between workloads running in different areas of a Kubernetes cluster.

Lesson_06: Storage

Sharing Data Between Containers in the Same Pod

This lab demonstrates how containers within the same Kubernetes pod can share data using an emptyDir volume. The exercise begins by creating a pod that contains two CentOS containers, each mounting the same shared volume at different mount points. Once the pod is deployed, Kubernetes automatically provisions the shared storage, allowing both containers to access the same files and directories during the pod’s lifecycle.

The second half of the lab validates data sharing by creating files from one container and confirming they are immediately visible from the other container. Additional tests involve writing data from one container and reading it from the other, proving that containers within a pod can collaborate through shared storage. This is a common pattern for sidecar containers, logging agents, and applications that require shared temporary data.

Mounting Pod Files to Host with hostPath

This lab introduces Kubernetes hostPath volumes, which allow a pod to mount a directory directly from the host node’s filesystem. The exercise starts by creating an Apache HTTPD pod and mounting the host directory /tmp/data into the container. This enables the container to read and write files directly to the underlying node’s storage.

After deploying the pod, files are created inside the mounted directory from within the container. The lab then verifies that those same files are visible on the host node where the pod is running. This demonstrates how hostPath volumes provide direct access between containers and host storage, making them useful for testing, local development, and certain node-specific workloads, while also highlighting the security and portability considerations associated with direct host access.

Creating a Deployment with ConfigMap as Volume

This lab focuses on using ConfigMaps to externalize application configuration from container images. The exercise begins by creating a ConfigMap containing configuration values such as database settings and service endpoints. Separating configuration from application code allows administrators to modify settings without rebuilding or redeploying container images.

The lab then creates a deployment that mounts the ConfigMap as a volume inside a container. By exposing configuration files directly through the filesystem, applications can consume configuration dynamically at runtime. This approach improves flexibility, simplifies configuration management, and supports more scalable application deployments by keeping configuration data separate from application binaries.

Creating and Using Secrets as a Volume

This lab demonstrates how Kubernetes Secrets can be used to securely store and distribute sensitive information such as passwords, API keys, and credentials. The exercise begins by creating a secret containing a database password and then examining the secret using Kubernetes commands to understand how secrets are stored and managed within the cluster.

The second portion creates a pod that mounts the secret as a volume, allowing applications to access sensitive information through files rather than embedding credentials directly in container images or application code. This method improves security and operational management while ensuring that confidential information can be updated independently of application deployments.

Configuring Pod Storage Using hostPath-Based PV and PVC

This lab introduces persistent storage management using Persistent Volumes (PVs) and Persistent Volume Claims (PVCs). The exercise begins by creating a hostPath-based Persistent Volume that allocates storage from a directory on the Kubernetes node. A Persistent Volume Claim is then created to request a portion of the available storage, demonstrating how applications consume storage resources through abstraction rather than direct infrastructure dependencies.

The lab continues by deploying a pod that uses the PVC and validating that the pod can successfully access the allocated storage. Additional testing confirms that data persists beyond the lifecycle of individual containers, illustrating one of the key advantages of persistent storage. By completing this exercise, readers gain practical experience with Kubernetes storage architecture and the relationship between PVs, PVCs, and application workloads.

Configuring Pod Using NFS-Based PV and PVC

This lab expands Kubernetes storage concepts by implementing shared storage through an NFS server. The exercise begins by configuring an NFS server on a worker node, exporting a shared directory, assigning permissions, and preparing client nodes with the necessary NFS packages. This setup creates a centralized storage location that can be accessed by multiple Kubernetes workloads.

Once the NFS infrastructure is configured, the lab creates a Persistent Volume backed by the NFS share and a matching Persistent Volume Claim. These resources are then used to support a MySQL deployment with persistent storage. The exercise demonstrates how NFS enables centralized, network-accessible storage that can be shared across nodes, making it ideal for stateful applications that require data persistence and cross-node accessibility.

Configuring Multi-Container Pods with RWX Access Using PV and PVC

This lab demonstrates how to provide shared storage access to workloads using the ReadWriteMany (RWX) access mode. The exercise begins by creating a Persistent Volume and Persistent Volume Claim configured for RWX access. Unlike ReadWriteOnce volumes, RWX storage allows multiple containers or pods to read from and write to the same storage simultaneously.

The lab then deploys a multi-container workload that consumes the shared PVC and performs various file operations to validate concurrent access. By observing how multiple containers interact with the same storage location, users gain a practical understanding of shared persistent storage architectures. This pattern is particularly useful for collaborative workloads, content-sharing applications, and environments where multiple services must access the same dataset concurrently.

Lesson_07: Troubleshooting_and_Kubernetes_Case_Studies

Troubleshooting Kubernetes Cluster

This lab introduces basic Kubernetes cluster troubleshooting techniques using built-in diagnostic commands. The exercise begins by verifying cluster node status with kubectl get nodes and obtaining overall cluster health information using kubectl cluster-info. These commands provide a quick overview of cluster availability, control plane status, and node readiness, making them valuable first steps when diagnosing cluster issues.

The lab then focuses on collecting detailed diagnostic information using kubectl cluster-info dump. Users learn how to generate comprehensive cluster dumps, access command help documentation, and limit diagnostic output to specific namespaces. Cluster dumps provide extensive information about workloads, services, events, and component states, making them an essential troubleshooting tool when investigating complex Kubernetes issues.

Inspecting Cluster and Node Logs

This lab demonstrates how to inspect logs from critical Kubernetes control-plane components and worker nodes. The exercise begins by navigating the /var/log/pods directory on the control-plane node and examining logs for the API server, controller manager, and etcd components. These logs provide visibility into cluster operations and are often the primary source of information when diagnosing failures or unexpected behavior.

The lab concludes by reviewing kubelet service logs on worker nodes using journalctl and exploring pod log directories. By learning where Kubernetes stores component logs and how to access them, administrators gain practical skills for monitoring cluster health, identifying errors, and troubleshooting both control-plane and worker-node issues.

Troubleshooting Node Readiness

This lab focuses on diagnosing and resolving node readiness problems in a Kubernetes cluster. The exercise intentionally simulates a node failure by stopping the kubelet service on a worker node. After a short period, the node transitions from Ready to NotReady, allowing users to observe how Kubernetes reports node health and availability.

To troubleshoot the issue, the lab uses commands such as kubectl describe node to examine node conditions and identify the root cause. The kubelet service is then restarted, restoring communication between the node and the control plane. This exercise provides a practical understanding of how Kubernetes monitors node health and how administrators can quickly diagnose and recover from node readiness failures.

Monitoring Container Logs

This lab introduces container-level monitoring using the crictl command-line utility. The exercise begins by locating container IDs on a worker node with crictl ps -a, which displays running and exited containers managed by the container runtime. This provides visibility into the underlying container infrastructure supporting Kubernetes workloads.

The lab then demonstrates how to retrieve container logs using crictl logs and view the most recent log entries with the –tail option. These commands allow administrators to investigate container behavior directly at the runtime layer, making them especially useful when Kubernetes-level tools are unavailable or when deeper troubleshooting is required.

Analyzing Pod Logs

This lab demonstrates application-level troubleshooting through Kubernetes pod logs. The exercise starts by creating an Nginx deployment and verifying that both the deployment and pod are successfully running within the cluster. This establishes a simple workload that can be monitored and analyzed.

After deployment, the lab uses kubectl logs to retrieve log output from the Nginx pod. Pod logs provide insight into application startup processes, runtime activity, and error conditions, making them one of the most commonly used troubleshooting tools in Kubernetes. By completing this exercise, users learn how to quickly access application output and diagnose workload-related issues.

Handling Component Failure Threshold

This lab focuses on gathering cluster health information to support failure analysis and capacity monitoring. The exercise begins by reviewing cluster nodes with kubectl get nodes to verify their operational status and ensure all components are functioning as expected.

The primary objective is to generate a comprehensive cluster health report using kubectl cluster-info dump > dump.json. The resulting file contains detailed information about cluster resources, configuration, status, and component health. By examining this diagnostic data, administrators can identify potential failures, monitor cluster conditions, and gather evidence for deeper troubleshooting investigations.

Troubleshooting Networking Issues

This lab explores Kubernetes service connectivity and network troubleshooting techniques. The exercise begins by creating an Apache HTTPD pod with specific labels and then creating a Kubernetes Service that uses label selectors to route traffic to the pod. This demonstrates the relationship between pods, labels, selectors, and services within the Kubernetes networking model.

The lab then validates connectivity by examining pod labels, service endpoints, and cluster IP addresses before testing access with the curl command. Additional troubleshooting steps include deleting and modifying service configurations to resolve networking issues caused by incorrect selectors or labels. Through these exercises, users gain practical experience diagnosing service discovery and pod-to-service communication problems in Kubernetes environments.

Lesson_08: DevSecOps_in_Kubernetes

Implementing Kubernetes Container Security

This lab provides a comprehensive approach to securing Kubernetes environments by addressing security at the network, node, pod, and container-image levels. The exercise begins by implementing a Kubernetes NetworkPolicy that restricts ingress and egress traffic to Nginx pods, allowing communication only from approved frontend workloads. This demonstrates the principle of least privilege and helps reduce the attack surface within the cluster by limiting unnecessary network access between workloads.

The lab continues by securing worker nodes through kubelet hardening, disabling anonymous access, enabling webhook authentication and authorization, and configuring certificate-based authentication. Pod security is enhanced using a Pod Security Policy (PSP) that requires containers to run as non-root users and limits filesystem group permissions. Finally, Trivy is introduced to scan container images for vulnerabilities before deployment. Together, these controls create a layered defense strategy that strengthens Kubernetes security and reduces the risk of unauthorized access, privilege escalation, and vulnerable workloads entering production environments.

Implementing a Pod Security Policy

This lab focuses on strengthening Kubernetes workload security through the implementation of a restrictive Pod Security Policy (PSP). The policy prohibits privileged containers, prevents privilege escalation, requires all Linux capabilities to be dropped, restricts host networking access, and enforces non-root execution. It also limits the types of storage volumes that pods can use and defines acceptable security contexts for user IDs, group IDs, and filesystem ownership. These controls help ensure that containers operate with the minimum permissions necessary to perform their intended functions.

After creating and applying the policy, the lab demonstrates how to associate it with workloads through RoleBindings and Service Accounts. A test pod is then deployed with a compliant security context to verify policy enforcement. The exercise highlights the importance of codifying security requirements within Kubernetes and validating that workloads adhere to organizational security standards before they are allowed to run in the cluster.

Scanning Kubernetes Cluster Resources Using the Trivy CLI

This lab demonstrates how to use Trivy to perform vulnerability and configuration assessments against Kubernetes workloads and cluster resources. The exercise begins by creating a dedicated namespace, deploying a sample React application, exposing it through a Kubernetes service, and verifying successful deployment. Users then install Trivy and prepare the environment for Kubernetes security scanning. This provides a realistic application environment for validating cluster security posture and identifying potential risks.

Once Trivy is installed, the lab performs vulnerability scans against Kubernetes namespaces using commands such as trivy k8s –include-namespaces react-app –report summary. Both summary and detailed reports are generated to identify vulnerabilities, misconfigurations, and runtime security concerns within application workloads and cluster components. By incorporating regular Trivy scans into operational processes, organizations can proactively identify security issues, improve compliance, and maintain a stronger Kubernetes security posture.

Enforcing Kubernetes Policies Using Gatekeeper

This lab introduces Open Policy Agent (OPA) Gatekeeper as a policy enforcement framework for Kubernetes. The exercise begins with installing Gatekeeper and verifying that its controllers are operational within the cluster. Users then create custom ConstraintTemplates using Rego policy language to define organizational security and governance requirements. The first policy enforces CPU and memory limits on pods, ensuring workloads cannot exceed predefined resource thresholds and helping prevent resource exhaustion within the cluster.

The lab continues by creating constraints that apply these policies across all pod resources and testing enforcement by attempting to deploy workloads that violate resource limits. Invalid pods are automatically rejected, while compliant workloads are successfully admitted. Additional namespace governance policies require namespace names to follow approved naming conventions, demonstrating how Gatekeeper can enforce standards beyond resource management. This exercise highlights how policy-as-code enables consistent governance, security, and operational controls across Kubernetes environments while reducing the need for manual review processes.