Kubeadm 是个让我爱恨交加的东西，一方面，我不认为一个生产集群应该使用这样一个第三方工具进行在线安装，尤其是在目前这种网络环境之下；而另外一方面，K
将 Kubernetes 内的应用和集群外甚至互联网上的的 Consual 或者类似系统管理的服务连接起来，形成更好的协同效果。
如何在资源紧缺的情况下，保证 Node 的稳定性，是 Kubelet 需要面对的一个重要的问题。尤其对于内存和磁盘这种不可压缩的资源，紧缺就相当于不稳定。
在运行基于 K8S 的 CI/CD 过程中，经常有需求在容器中对 Kubernetes 的资源进行操作，其中隐藏的安全问题，目前推荐的最佳实践也就是使用 Service Account 了。而调试账号能力的最好方
因为一些莫可名状的原因，国内网络使用 Kubeadm 颇有难度，这里大概说一下过程中的一些坑。 主体流程遵循官网指南：https://kubernetes.i
原文：Advanced Scheduling in Kubernetes Kubernetes 的调度器能够满足绝大多数要求，例如保证 Pod 只在资源足够的节点上运行，会尝试把同一个集合的 Pod 分散在不同的节点上，还
GlusterFS 是个开源的分布式文件系统，而 Heketi 在其上提供了 REST 形式的 API，二者协同为 Kubernetes 提供了存储卷的自动供给能力。 一般对这个系统的介绍，都是基于 Docker 的容器内
RBAC 可以授权给用户，让用户有权进行授权管理，这样就可以无需接触节点，直接进行授权管理。RBAC 在 Kubernetes 中被映射为 API 资源和操作。
如果你在编写配置模板或者是一个可能在很多不同集群下运行的配置，要在其中包含持久存储，我们提供一些建议
概念 Chart：一个 Helm 包，其中包含了运行一个应用所需要的工具、资源定义等，还可能包含 Kubernetes 集群中的服务定义，类似 Homebrew 中的 formula，APT 的 dpkg