# cncamp/101: a Kubernetes study guide arranged as numbered modules

> The cncamp/101 repository is a set of written modules, manifests and scripts for learning Kubernetes from cluster installation through control plane internals to production operation, application migration and Istio. It is aimed at engineers who want a structured reading path rather than a task-oriented tutorial for one problem.

**cncamp/101** — A basic instruction for Kubernetes setup and understanding.

- Repository: https://github.com/cncamp/101
- Stars: 916 · Forks: 814
- Language: Python
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/cncamp-101

## A curriculum, not a cookbook

The repository describes itself as a basic instruction for Kubernetes setup and understanding, and the README is a table of modules rather than a set of instructions. The first row is the Install Kubernetes Cluster module with a guide directory named `k8s-install`, and the module ID for it is a dash, which reads as a starting point rather than a numbered step.

That structure is the project's identity. The content is organised as a path with an explicit order: Docker Core Technology as module 3, Kubernetes Architecture Principles and Object Design as module 4, then one module per control plane component, etcd in module 5, the APIServer in module 6, the Scheduler and Controller in module 7, and Lifecycle Management and Service Discovery in module 8. From there it moves to Managing Production-ready Kubernetes Clusters in module 9, DevOps with Kubernetes in Production in module 10, and Migrating apps to Kubernetes in module 11. Module 12 covers Advanced Traffic Management with Istio.

The numbering implies there were modules 1 and 2 before the ones listed, which points at this being part of a larger course series rather than a standalone handbook. That also explains the audience. Someone with a Kubernetes cluster already running will not learn much from the install module, while someone who has only used a managed service will find the control plane modules the point of the whole thing.

One small thing worth reporting, because it is the kind of detail you hit when you actually click through. The Module 12 row for Advanced Traffic Management with Istio links to `module11`, the same target as the DevOps and migration rows, while its guide column says `module12`. The link in that row does not match the module it names.

## The topics it stops short of

It is worth being clear about what the table does not contain, since a study guide's shape is defined as much by its edges.

Networking, in the sense of Kubernetes network policy and cluster networking, is handled outside the module list. The README has a Network section with a single link, a Network Step by Step document hosted on an external note-taking service rather than in the repository. That is a real limitation for a guide meant to be self contained, because the most fragile part of understanding Kubernetes is how pods reach each other and how traffic leaves the cluster.

The microservice material is also handled separately. The README links a single file, `3.microservice.md`, for the microservice topic, and then a separate section covers Istio with two files, `istio-setup.md` and `understand-istio.md`.

So the numbered module directories and the loose top level markdown files are two different styles of material sitting side by side. The module directories look like they are written as self contained units with their own material, while the top level files are shorter references that assume you already know the context.

The repository layout also extends past the table. Alongside `module3/` through `module12/` there are `module13/`, `module14/`, `module15/` and `module16/`, plus `multi-tenant/`, `source-code-reading/`, and the `helloworld/` directory. The table was therefore not updated to cover everything the repository contains, which is a hint about how the material evolved.

## Runnable artifacts next to the prose

The repository is not only markdown. There is a set of manifests and scripts that you can apply directly, and they are the practical half of the material.

At the top level you can see `minikube_start.sh`, which is the local cluster entry point, and `envoy_default.yaml` for the Istio service mesh side of module 12. There are manifests for stateful workloads and for secrets, `stateful-nginx.yaml`, `statefulset-with-pvc.yaml`, `secret-with-string-data.yaml` and `pod-secret-volume.yaml`, and a pod with more than one container in `multiple-container-pod.yaml`.

There is also `helm.md`, a document rather than a chart, and a packaged Helm chart, `helloworld-0.1.0.tgz`, with the `helloworld/` directory beside it, which is the example you would deploy to see whether your cluster can run a real workload end to end.

The `multi-tenant/` directory is the one that stands out as a design topic rather than a mechanics topic. Multi-tenancy is where the interesting Kubernetes questions live, because it is about namespace boundaries, resource quotas, network policy and RBAC rather than about how a Deployment behaves, and having it as a dedicated directory suggests the author treated it as a subject in its own right rather than a footnote in the production module.

Taken together, the artifacts tell you the intent of the guide. You are meant to run things. Each concept is accompanied by the object you can apply to see it work, which is a much better way to understand a control plane than reading about it.

## Reading the Kubernetes source with a Go module

There is a `source-code-reading/` directory, and the repository ships a Go module, which is unusual for a documentation project and points at how the source reading is meant to be done.

The go.mod declares the module as `github.com/cncamp/101`, requires Go 1.17, and pins a small set of direct dependencies:

```go
require (
	github.com/google/go-github v17.0.0+incompatible
	golang.org/x/oauth2 v0.0.0-20211005180243-6b3c2da341f1
	k8s.io/api v0.22.2
)
```

`k8s.io/api` at v0.22.2 is the important one. That is the Kubernetes API types package for a specific Kubernetes version, which is exactly what you want when the exercise is to read the source of the API machinery rather than the source of the scheduler or the controller manager. The dependency list alone does not establish what the GitHub library is used for or whether source examples are pinned to a particular revision. Check the actual exercises before relying on them.

It also dates the material. `k8s.io/api` v0.22.2 corresponds to Kubernetes 1.22, and the oauth2 and go-github pins are from late 2021. Whatever is in `source-code-reading/` reflects that era, and the prose will describe the control plane as it was then rather than as it is now.

## MkDocs for the site, index.md for the entry point

The repository is built as a documentation site. There is an `mkdocs.yml` at the top level and an `index.md` that acts as the landing page, alongside `readme.MD` for the GitHub view. The `mkdocs.yml` is what turns the module directories and markdown files into a navigable site, which is why the module directories are named `module3` through `module16` rather than something descriptive: they are directory sections in the site, not independent packages.

A separate `.github/` directory and a `.gitignore` complete the standard set of repository files.

The presence of `mkdocs.yml` also implies that the docs are served from GitHub Pages or a similar host, and that navigation lives in the configuration rather than in the markdown files. If you fork this repository, the navigation table at the top of the README and the site navigation are two separate places that have to be kept in step, which is exactly the kind of duplication that produces a mismatch. The Module 12 link pointing at `module11` is what that looks like in practice.

One loose end in the top level listing is `poc-rce-test.txt`. Its purpose is not established by its name alone; inspect its contents and history before deciding whether it is relevant to a fork.

## No licence, no releases, and a spring 2026 push

Two facts about the repository's metadata are worth knowing before you plan to use it.

The first is the licence. The repository's licence field is listed as unknown, and there is no LICENSE file among the top level entries. The absence of a licence is not the same as permission. The absence of a stated open-source licence does not by itself grant general reuse rights; applicable law and platform terms may allow limited uses. If you want to reuse these modules in your own team's documentation, the safe path is to ask the author, or to write your own material based on the topics listed here.

The second is the release history. The repository has no GitHub releases, and the last push was on 2026-05-07. There is no version to pin and no changelog to read, so the way to know whether a module is current is to read it and check the version it describes.

Neither of those facts makes the material less useful. A structured twelve-module path through Kubernetes, with the control plane broken into one module per component and the manifests to match, is a substantial piece of work that you cannot get from the official documentation alone. But it is a community study resource with no published terms and no versioned releases, and treating it that way, as a map of where to look rather than a specification to follow, is how you get the most out of it without inheriting its gaps.

## Conclusion

Adopt cncamp/101 as a reading path when you are learning Kubernetes end to end and want the sequence, from a local cluster to the control plane components to running in production, laid out in one repository with the manifests you need alongside each topic. Skip it if you need a maintained, versioned reference for a specific Kubernetes release, since the material is a teaching collection rather than a tracked product, and note that the repository carries no licence classification, so treat the prose and manifests as reference material rather than something to vendor. Verify first which Kubernetes version the manifests and the pinned `k8s.io/api` dependency target before you apply them to a live cluster. The last push was on 2026-05-07 and the repository has no GitHub releases.

## FAQ

### What is the cncamp/101 repository?

It is a set of written modules, manifests and scripts described as a basic instruction for Kubernetes setup and understanding. The README indexes the modules from installing a Kubernetes cluster through Docker Core Technology, the control plane components, production operations, application migration and Istio.

### Which Kubernetes topics does cncamp/101 cover?

The module list covers cluster installation, Docker Core Technology, Kubernetes architecture principles and object design, and one module each for etcd, the APIServer, the Scheduler and Controller, and Lifecycle Management and Service Discovery, followed by production-ready cluster management, DevOps in production, migrating applications and Istio traffic management.

### Does cncamp/101 include runnable examples?

Yes. The repository ships `minikube_start.sh`, `envoy_default.yaml`, manifests such as `stateful-nginx.yaml`, `statefulset-with-pvc.yaml`, `secret-with-string-data.yaml`, `pod-secret-volume.yaml` and `multiple-container-pod.yaml`, a `helloworld/` Helm chart with its packaged `helloworld-0.1.0.tgz`, and a `multi-tenant/` directory.

### How does cncamp/101 approach reading the Kubernetes source?

There is a `source-code-reading/` directory, and the repository includes a Go module pinning `k8s.io/api` at v0.22.2 along with `github.com/google/go-github` and `golang.org/x/oauth2`, requiring Go 1.17. The pinned API version means the material reflects the Kubernetes 1.22 era.

### What licence does cncamp/101 use?

The repository licence field is listed as unknown and there is no LICENSE file in the top level entries. The README invites forks and pull requests, but the material should be treated as reference rather than something to redistribute without asking the author.

## Sources

- [cncamp/101 on GitHub](https://github.com/cncamp/101)
- [Issues](https://github.com/cncamp/101/issues)
- [README](https://github.com/cncamp/101/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cncamp-101