cby-chen/Kubernetes and the long form of a manual cluster install

This is a document, not a tool

The repository description says it plainly: binary installation of Kubernetes, that is k8s, with a high availability setup. The primary language is Shell, but the shape of the project is closer to a long technical manual than to a piece of software. The top level is a doc/ directory holding one document per minor version, plus yaml/ manifests, calico/, cilium-test/, dashboard/, metrics-server/, ingress-yaml/, pki/, bootstrap/ and shell/ directories of the pieces a cluster needs.

The audience is specific and it is stated in the first section: people who want a highly available cluster assembled by hand, primarily on CentOS, in an environment where pulling images from foreign registries is difficult. The opening advice is to open the document and use find and replace to swap the example IPs for your own hosts, which tells you exactly how the document is meant to be consumed.

The author is also blunt about the difficulty. Manual deployment is described as complex, and the recommendation that follows is to prefer an automated deployment tool whenever one is available, to avoid the complexity of manual steps that are easy to get wrong. The project links kubeasz as an automated deployment tool and includes a kubeadm installation guide of its own. A guide that tells you to use something else is unusual, and it tells you how to judge the rest of the material.

Three masters, two workers, and an offline package

The document filenames describe the topology and the constraints at once, with names like v1.36.0-CentOS-binary-install-IPv6-IPv4-Three-Masters-Two-Slaves-Offline.md. Every recent version follows that pattern, and the older 1.25.x and 1.24.x documents use shorter variants such as IPv6-IPv4-Three-Masters-Two-Slaves.md and IPv6-IPv4.md, which shows the project growing the dual stack and offline story over time.

So the deployment this describes is three control plane nodes and two worker nodes, on CentOS, with IPv4 and IPv6, installed from packages you already have. That combination is not arbitrary. A binary install means you assemble the components yourself, which lets you point them at whatever binary distribution you can reach, and it is the usual answer to the problem of an environment that cannot pull container images or release tarballs from the usual places.

The offline angle is the reason the packages are hosted where they are. Alongside the GitHub releases there is a 123 cloud drive link, and the guide opens with a warning that Docker and other repository images have been blocked in mainland China, that existing images can no longer be pulled directly and that a domestic mirror source or proxy arrangement is needed. That constraint drives much of the rest of the design, from the offline package layout to the recommendation to use a domestic mirror source or a proxy.

Dual stack and Docker is where the guide warns you off

The most valuable section of the README is the compatibility note about the container runtime. It says that in the latest IPv4 and IPv6 dual stack environments, using Docker as the container runtime can cause kubectl exec into a container to fail and cause abnormal network connections. The stated root cause is a defect in cri-dockerd's dual stack compatibility, and the stated solution is that Kubernetes has formally deprecated the Docker shim, so containerd is strongly recommended as the default runtime in production for more stable support.

This is a real, specific failure mode rather than a general preference, and it is the kind of thing that costs a day if you hit it blind. The project also covers the opposite direction: a separate document for using the Docker runtime on Kubernetes 1.24 and 1.25, and a section on enabling IPv6 or disabling it on an IPv4 cluster, plus a Minikube initialisation guide for local work.

The version table reinforces the point. Versions 1.24.x and below are marked as maintenance, with the note that the Docker shim was removed in 1.24. The lines from 1.25.x to 1.35.x are marked stable, and 1.36.x is marked as the latest and recommended, with the note that a document for one minor version applies across that series, so the 1.26.0 document installs any 1.26.x release once you download the matching package.

The troubleshooting list names four failures you will probably hit

A section on common exceptions is worth more than any amount of setup prose, and this one is concrete.

The first is hosts configuration. The symptom is that nodes fail to communicate with each other, and the fix is to check /etc/hosts and make sure hostnames and IP addresses correspond correctly. In a three master cluster where every component talks to the others by name, a wrong hosts entry breaks the whole thing at once, and the error you see will not tell you that.

The second is the bootstrap secret. The symptom is a node failing to join the cluster, and the fix is to execute a specific command in section 7.2 of the document:

kubectl create -f bootstrap.secret.yaml

The guide underlines this one, which suggests it is the step people forget.

The third is the kubelet service, where the symptom is that the cluster misbehaves after a server reboot, and the diagnostic is the standard systemd status call:

systemctl status kubelet.service

The fourth is CentOS 7, where a container runtime error means runc and libseccomp need to be upgraded, with a pointer to the networking plugin chapter of the 1.25.0 document. The pattern across all four is worth noting: three of them are about state that lives outside the cluster, in files and services the cluster cannot repair for you.

The scripts were retired, the documents kept going

The project has been reorganised over its life and the README records how. The current repository is the manual deployment project, while two older script projects are listed with a note that they are no longer maintained: Binary_installation_of_Kubernetes and kube_ansible. Both are still linked, which is helpful for anyone who followed the project years ago, but the maintenance note means their scripts should be treated as historical artefacts rather than current tooling.

What kept moving is the documentation. The index lists the newest documents first, with a kubeadm installation guide for V1.32 and CentOS binary install documents for v1.36.0 and v1.35.0, then a long historical section going back one document at a time to v1.21.13. Alongside them sit the other technical documents, including the kube-proxy certificate permission fix, the kubeadm initialisation guide for dual stack clusters, the guide to enabling or disabling IPv6 on an IPv4 cluster, the Kubernetes cluster upgrade guide, the Minikube guide, the Docker runtime document for 1.24 and 1.25 and the Cilium installation guide.

The version coverage is broad enough that most teams will find their target. The naming is a little inconsistent, and the guide itself flags that the v1.23.3 release was named badly because later updates had not been considered, with subsequent versions corrected. Small, but it is the kind of detail that matters when you are copying a file path from a document into a script.

GPL-3.0, a September 2026 last push, and a mid year release

The project is licensed under GPL-3.0, with the licence text in the LICENSE file at the root. For a collection of documentation and shell scripts, the practical implication is limited, and the more relevant licence question is the one about redistribution of modified versions, which matters if you fork the material for an internal runbook.

The repository is not archived. The last push was on 2026-09-29, and the release history shows v1.36.0 published on 2026-05-11, v1.35.0 on 2025-12-19 and v1.34.0 on 2025-08-31. The spacing between those releases, roughly four to five months, which is consistent with a project whose work follows the release cycle of the platform it documents rather than leading it.

The homepage is oiox.cn, and the project is also mirrored on Gitee under the cby-inc organisation, which matters in the environment the guide is written for. The README closes with an appeal for stars, and the author explains the reasoning in the description, that open source work is not easy and that a star is a way to support it. That is a small detail, but it tells you the project is a personal contribution maintained alongside other work, which is a fair expectation to set before you depend on it for a production cluster.

Editorial conclusion

Adopt this project if you are in mainland China, you need a cluster installed from offline packages on CentOS, and you want a highly available topology with IPv4 and IPv6 dual stack already worked out in a document. Do not adopt it if you can run kubeadm, because the repository's own first recommendation is to use an automated deployment tool instead. Verify three things first: that the minor version you want has a document in doc/, that containerd rather than Docker is your runtime, since the guide flags dual stack failures with the Docker shim, and that the bootstrap secret was created with kubectl create -f bootstrap.secret.yaml, which the troubleshooting list names as the most common cause of a node failing to join. The last push was on 2026-09-29 and the newest release is v1.36.0 from 2026-05-11.

Frequently asked questions

Official sources

1. cby-chen/Kubernetes on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases