我乐了的博客

ConfigMap 和 Secret 是 Kubernetes 常用的保存配置数据的对象，你可以根据需要选择合适的对象存储数据。通过 Volume 方式挂载到 Pod 内的，kubelet 都会定期进行更新。但是通过环境变量注入到容器中，这样无法感知到 ConfigMap 或 Secret 的内容更新。目前如何让 Pod 内的业务感知到 ConfigMap 或 Secret 的变化，还是一个待解决的问题。但是我们还是有一些 Workaround 的。如果业务自身支持 reload 配置的话，比如。

现在我们就总结下 StatefulSet 的特点：具备固定的网络标记，比如主机名，域名等；支持持久化存储，而且最好能够跟实例一一绑定；可以按照顺序来部署和扩展；可以按照顺序进行终止和删除操作；在进行滚动升级的时候，也会按照一定顺序。借助 StatefulSet 的这些能力，我们就可以去部署一些有状态服务，比如 MySQL、ZooKeeper、MongoDB 等。你可以跟着这个教程在 Kubernetes 中搭建一个 ZooKeeper 集群。

每一个 Pod 都是应用的，但是通常来说你不会直接在 Kubernetes 中创建和运行单个 Pod。因为 Pod 的生命周期是短暂的，即“理解这一点很重要，这也是“”这一理念在 Kubernetes 中的最佳实践。同样，对于你后续进行业务改造和容器化上云也具有指导意义。

其实作为 Kubernetes 内部最核心的对象之一，Pod 承载了太多的功能。为了增加可扩展、可配置性，Kubernetes 增加了各种 Probe、Hook 等，以此方便使用者进行接入配置。所以在一开始使用的时候，会觉得 Pod 中配置项太多。但是不要害怕，这些配置项都是有一定目的的。通过上面合理地归类和示例，可以很好地帮助你理解 Pod Spec 中的一些定义。下一节课开始，我们就要学习如何部署高可用业务。如果你对本节课有什么想法或者疑问，欢迎你在留言区留言，我们一起讨论。

基础设施会变得越来越脆弱、敏感，一些小的改动都有可能引发大的不可预知的结果，这令广大开发者和环境管理员异常抓狂，他们需要凭借自己丰富的技术积累，耗费大量的时间去排查解决。正如我们 01 课时所说，云计算的出现降低了环境标准化的成本，但是业务的交付管理成本依然很高。，是从 v1.12 版本开始开发的，到 v1.14 版本变为 beta 可用版本，在 v1.17 的时候已经正式 GA 了，它要用于 node 汇报心跳（我们在第一节课已经解释过了心跳的概念），每一个节点都会有一个对应的 Lease 对象。

所以你可以只使用 Kubeadm 的部分功能，比如使用 Kubeadm 帮你生成各个组件的证书，也可以基于 kubeadm 开发专属的集群部署工具，比如通过 Ansible 借助于 Kubeadm 的子功能来定制 Kubernetes 集群的搭建。因此，即使最微小的集群变更也要非常小心，慎重操作，最好通过“到这里，我们就知道了证书的签发并不是那么随意，而想要从零开始搭建一套安全性高的集群，其难度远不止如此，我们这里还需要额外考虑到，譬如证书的有效期、过期替换、证书签发的密钥类型、签名算法等等问题。

Google 内部一个中等规模的 Cell 可以管理 1 万台左右的服务器，这些服务器的配置可以是异构的，比如内存差异、CPU 差异、磁盘空间等。Cell 内的这些机器是通过高速网络进行连通的，以此保证网络的高性能。Cluster 即集群，一个数据中心可以同时运行一个或者多个集群，每个集群又可以有多个 Cell，比如一个大 Cell 和多个小 Cell。通常来说尽量不要让一个 Cell 横跨两个机房，这样会带来一些性能损失。

我们就开始正式进入Kubernetes 的学习，或许你已经听过或简单了解过 Kubernetes，它是一款由 Google 开源的容器编排管理工具，而我们想要深入地掌握 Kubernetes 框架，就不得不先了解 Kubernetes 的前世今生，而这一切都要从“云计算”的兴起开始讲起。