运行您自己的私有 Kubernetes 集群是否可行？

Question

是否有人曾经使用过自托管和自安装的 Kubernetes 集群，并对配置和管理此类集群所需的知识和时间给我一些评估？

在 GKE 和 EKS 出现之前，我已经运行了相当多的集群，不过我很庆幸我是在 IaaS 设置中运行的，这样我就不必将东西架起来，如果出了问题，我只需让云提供商将其关闭即可。你的问题有两个独立的部分，它们的工作量也不同：配置和管理

在机器准备好并启动并读取用户数据后，只需 30 分钟即可配置集群（我认为即使是裸机也有相应的云初始化方案，即使不太强调“云”部分），得益于完全的魔法kubeadm和它的朋友etcdadm

然而，在 Kubernetes 启动并运行之后，真正的工作才刚刚开始 —— 通常被称为“第二天”的操作，里面列满了需要监控的事情和可以进行的操作。

为了绝对清楚起见，我无意劝阻你：当集群处于良好状态时，它就像魔术一样，令人吃惊很多事情都能奏效™。但是，就像许多神奇的事情一样，当他们生气时，如果你还不熟悉警告信号或不认识他们的枪声，这可能会让令人沮丧的情况变得更加令人沮丧。

我想知道管理这样的系统（因为我是唯一的管理员）是否太费力。尤其是考虑到我对 Kubernetes 内部工作原理的了解并不多

我认为，最后一部分才是最难克服的障碍，因为——就像许多软件一样——一旦你理解了解它们是如何粘合在一起的，对它们进行故障排除通常是一个繁琐但容易处理的问题。然而，管理 Kubernetes本身只是维护 Kubernetes 所需工具集的一部分簇活：

systemd（是的，除非你使用一个非常非常深奥的机器镜像，直接启动到kubelet和，否则它仍然是必需的containerd）
- systemd 的 cgroups 管理与 docker 或 containerd 的 cgroups 管理如何对抗
docker （或containerd）
- 包括其身份验证系统，如果你有需要凭证才能拉取的图像
中央网络接口
- 以及你决定使用的 CNI 提供商的每一个细微差别，因为他们不可避免地会吐出问题，而扑灭这场大火是……很有趣的
等（!!!!!!!!!!!!!!!!!!）
- 会员管理
- 备份——只有经过测试，它们才是“备份”，因此一些灾难恢复演习对于减少凌晨 3 点的寻呼机呼叫次数大有帮助
- 虽然如果你的集群足够小，它可能不会对你造成影响，但分类 etcd 性能停滞也是一场噩梦
控制平面各部分所扮演的角色，以便根据观察到的行为知道要查看谁的日志：
- API 服务器
- 控制器管理器
- 调度程序
- kube-proxy
- 库贝莱特
对所有主要运动部件都有深入的了解，我的意思是全部，原版资源类型：Node，Pod，Deployment，Service，（包括的 4 个主要子类型）；ConfigMap是可选的，但有助于理解它们存在的原因SecretSecretStatefulSet
RBAC 子系统：Role，，，，，以及auth如何将其从 HTTPS 请求传递到 apiserver 的处理程序，然后转换为可以根据这些策略进行评估的，就像所有与“安全”相关的好东西一样RoleBindings，它本身就是无底洞，里面有需要了解的标准和需要排除故障的工具ClusterRoleClusterRoleBindingsSubject

虽然这可能不会影响你的裸机设置，通常kubernetes 通过 MetalLB 和 CNI IPAM 解决方案等与外界交互，排除故障需要了解 kubernetes期望让他们去做，然后让他们明白自己在做什么实际上正在做

我个人还没有采取肌酸激酶A但你至少应该通读一下课程，了解一下 CNCF 认为哪些主题是基本知识。如果你不害怕，那么，嘿，也许你也可以通过这个练习获得 CKA :-)

祝狩猎愉快！

Answer 1