This Kubernetes project list is mostly a table of contents, and four of the lessons live in the repo

Thirty three numbered projects, one learning path

The repository presents itself as practical, real-world hands-on projects to practice and learn Kubernetes implementations, and the project list is numbered from 1 to 33 and grouped into subject areas.

The stated purpose is to take you from beginner to advanced, by engaging in hands-on exercises that give real-world experience in deploying, managing and scaling containerized applications inside Kubernetes. The three reasons the project gives for the repository's existence are hands-on learning through practical implementations, a structured path through fundamental to advanced concepts, and certification preparation for CKA, CKAD and CKS.

The grouping is the useful part, because the order is a curriculum. Cluster setup comes first, with Kubernetes the Hard Way on AWS as project 1, a self-hosted kubeadm cluster as project 2, and a Minikube install tutorial as project 3. Networking follows, covering the Gateway API, Nginx Ingress with cert-manager, TLS and SSL ingress configuration, and the AWS Cloud Controller Manager. Then secret management, then infrastructure, then monitoring, then application deployment, then autoscaling.

The sequencing tells you what the author believes the dependencies are. Ingress and cert-manager before secrets, secrets and CI before monitoring, monitoring before you scale an application. That is a defensible order for someone who has never touched a cluster.

Most projects are links, only four are directories

Here is the thing to understand before you plan your study with this repository. The project list is a list of links, and most of those links point to articles on devopscube.com rather than to anything in the repository.

Only project 1 links into the repository itself, to the directory 01-kubernetes-the-hard-way-aws. The top level of the tree holds four directories: 01-kubernetes-the-hard-way-aws, 03-java-app-deployment, 04-wordpress-deployment, and observability. The other two, the Java app and the WordPress deployment, correspond to projects 27 and 28 in the list, and the observability directory is where the monitoring lessons live.

So the repository holds the hands-on work for cluster bootstrapping, one application deployment, another application deployment and the observability work, and the remaining two dozen or so projects are written guides hosted elsewhere. The primary language of the repository is recorded as HCL, which is consistent with that: the in-repo work is Terraform style infrastructure for the AWS cluster.

That is not a criticism of the project, it is a description of its shape. But it changes what you are adopting. You are adopting a syllabus with an index, and a set of labs that you will clone. Whether a given project is a repository you read or a blog post you follow, you have to look at the link to find out.

The secret management block is where the project list gets specific

Five consecutive projects cover secrets, and the specific tool choices are the most useful thing in that section.

Project 8 is encrypting Kubernetes secrets with Sealed Secrets, project 9 is setting up Vault in Kubernetes, project 10 is the External Secrets Operator on EKS, project 11 is the Vault Agent Injector to inject secrets into pods, and project 12 is the Secrets Store CSI Driver on AWS EKS.

Five different approaches to the same problem, in order, is a deliberate pedagogical choice. Sealed Secrets is the encrypt-at-rest-in-Git answer, Vault is the central server answer, the External Secrets Operator is the sync-from-a-store answer, the Vault Agent Injector is the sidecar answer, and the Secrets Store CSI Driver is the filesystem mount answer. Seeing all five in one place is more useful than seeing any one of them in depth, because the trade-off between them is the thing you have to make.

The same pattern appears in monitoring, which runs from project 17 to 26 and covers Loki, Prometheus, the Prometheus JMX Exporter, Grafana, the Node Exporter, the EFK stack for logging, audit logging and analysis, Alertmanager, a Kubernetes logging guide, and Sensu monitoring with a sidecar.

The two most specific entries are the ones that name a deployment target. External Secrets Operator on EKS and Secrets Store CSI Driver on AWS EKS are not generic, and the Secrets Store one has a typo in the link path that you will hit when you click it.

Infrastructure and CI projects, with Jenkins running three ways

The infrastructure deployment block covers Jenkins and Argo CD, and the Jenkins entries are three separate projects because running Jenkins on Kubernetes has three genuinely different shapes.

Project 13 is setting up Jenkins on Kubernetes, project 14 is Jenkins as a StatefulSet, and project 15 is Jenkins build agents on Kubernetes. A plain deployment loses its workspace on restart, a StatefulSet gives it stable storage and an identity, and build agents on Kubernetes means the workers themselves are pods that come and go with the queue. Those are different operational problems, and the project treats them as different lessons rather than as one topic.

Argo CD, project 16, is the GitOps piece of that section, set up with Helm.

The application deployment block that follows moves from infrastructure to workloads. Project 27 deploys a Java app with MySQL, and project 28 deploys WordPress with Nginx and MySQL. The two that are not finished are marked in development: deploying a Python Flask app with PostgreSQL, and deploying a Node.js app with MongoDB. Both are marked in development in the list itself, so the numbering goes past 28 and the two unfinished entries are visible rather than hidden.

The scaling block opens with the Horizontal Pod Autoscaler, also in development, then the Vertical Pod Autoscaler, and then the Cluster Autoscaler on EKS.

Half the page is certification marketing

A fair amount of the project page is not about Kubernetes.

There is a note at the top pointing to a paid Complete Kubernetes and CKA course with a discount code, and a section offering certification vouchers for CKA, CKAD, CKS and KCNA with a second discount code and links to bundle pages. Another section repeats the course pitch with a third code, and there is a note about a one year validity window to appear for the exam after registration. A repository of Kubernetes vouchers sits at a separate GitHub address.

The community section invites readers to a DevOpsCube Discord channel for discussion with experienced Kubernetes people, and a separate note asks for a star so the project is easier to find.

None of this is hidden, and the training projects stand on their own. But it does tell you what the project is for. This is a teaching brand with a repository attached, and the repository's own list of 33 projects is the syllabus that leads to the paid course and the certification exam vouchers.

That matters for how you judge the projects. The project list is arranged around the CKA, and the projects are picked to cover the objectives of that exam rather than to be the most useful things to learn about running Kubernetes in production. If your goal is the certification, that ordering is exactly right. If your goal is running your own cluster well, the list is a starting point and not a curriculum, and you will want to add the parts it does not cover, such as cluster upgrades, backup and restore of etcd, or debugging a stuck workload.

What to expect from the four directories that actually exist

Given that only part of the list is in the repository, it is worth knowing what the in-repo part contains.

01-kubernetes-the-hard-way-aws is the cluster setup project, and it is the one the project list itself links to as a directory. The hard way exercise is the one that avoids managed control planes and builds the cluster piece by piece, so its manifests are the ones that show you how the components fit together rather than how a managed service arranges them. The recorded primary language being HCL fits: the AWS side of it is provisioned as code.

03-java-app-deployment and 04-wordpress-deployment are the two application projects, and they are numbered 27 and 28 in the wider list, which tells you the repository is not organised by directory name in list order. The Java one pairs an application with MySQL, and the WordPress one pairs WordPress with Nginx and MySQL, so both are stateful multi-component deployments rather than a single stateless pod, which is the harder and more useful case.

The observability/ directory is the fourth, and it corresponds to the monitoring block. There is no further documentation in the tree beyond the project page, so the directory contents are the only guide to what each of these contains.

The .github/ directory holds the workflow definitions for the repository, and the project page carries a build badge for it, so the in-repo work is checked in continuous integration.

Licence, cadence and what you are really depending on

The project metadata records the licence as one that GitHub cannot classify, and the repository has no LICENSE file at the top level. That is worth resolving before you copy any of the Terraform or manifests from those directories into a codebase of your own.

The repository is not archived and the last push was on 2026-10-15, and there are no GitHub releases, so there is no version to pin and no changelog to read. What you learn from is whatever is on the main branch on the day you clone it, and the article links point to pages on an external site that can change independently of the repository.

There is also a documentation-consistency problem that only shows up when you follow the links. The list numbers projects 1 through 33, and the list is truncated in the project page itself, so the tail of the scaling section, and anything after it, is not visible there. The repository has a .github/ directory for its own CI, and a wiki link, but the wiki content is not part of what the project page shows.

None of this argues against using it. It argues for using it the way it is meant to be used: as an index to read, with the four in-repo projects cloned and worked through, and the article links treated as guides that you re-verify against your own cluster version before you trust them in production.

Editorial conclusion

kubernetes-projects fits a learner who wants an ordered map of what to study next, since the 33 projects are grouped by cluster setup, networking, secrets, infrastructure, monitoring, application deployment and scaling, and the numbering tells you which to attempt first. It does not fit someone who expects to clone a repository and work through self contained labs, because only a handful of the projects exist in the tree and the rest are links to articles, and it does not fit a team that needs a maintained, version pinned training environment. Before adopting it as a study plan, open the four directories that are actually in the repository to see the depth of the in repo work, check the article links for the projects you care about, and treat the certification preparation and discount sections as marketing rather than as part of the curriculum.

Frequently asked questions

Official sources

1. Issues
2. README
3. techiescamp/kubernetes-projects on GitHub