本章我们将学习 Helm，Kubernetes 的包管理器。 每个成功的软件平台都有一个优秀的打包系统，比如 Debian、Ubuntu 的 apt，Redhat、Centos 的 yum。而 Helm 则是 Kubernetes 上的包管理器。 本章我们将讨论为什么需要 Helm，它的架构和组件，以及如何使用 Helm。 Why Helm Helm 到底解决了什么问题？为什么 Kubernetes

Secret 可以为 Pod 提供密码、Token、私钥等敏感数据；对于一些非敏感数据，比如应用的配置信息，则可以用 ConfigMap。 ConfigMap 的创建和使用方式与 Secret 非常类似，主要的不同是数据以明文的形式存放。 与 Secret 一样，ConfigMap 也支持四种创建方式： 通过 --from-literal： kubectl create configmap myconfigmap

通过 Volume 使用 Secret，容器必须从文件读取数据，会稍显麻烦，Kubernetes 还支持通过环境变量使用 Secret。 Pod 配置文件示例如下： 创建 Pod 并读取 Secret。 通过环境变量 SECRET_USERNAME 和 SECRET_PASSWORD 成功读取到 Secret 的数据。 需要注意的是，环境变量读取 Secret 很方便，但无法支撑 Secret 动态更新。

Pod 可以通过 Volume 或者环境变量的方式使用 Secret，今天先学习 Volume 方式。 Pod 的配置文件如下所示： ① 定义 volume foo，来源为 secret mysecret。 ② 将 foo mount 到容器路径 /etc/foo，可指定读写权限为 readOnly。 创建 Pod 并在容器中读取 Secret： 可以看到，Kubernetes 会在指定的路径 /etc/foo

kubectl get secret 查看存在的 secret。 显示有两个数据条目，kubectl describe secret 查看条目的 Key： 如果还想查看 Value，可以用 kubectl edit secret mysecret： 然后通过 base64 将 Value 反编码： 下节学习如何在 Pod 中使用 Secret。

应用启动过程中可能需要一些敏感信息，比如访问数据库的用户名密码或者秘钥。将这些信息直接保存在容器镜像中显然不妥，Kubernetes 提供的解决方案是 Secret。 Secret 会以密文的方式存储数据，避免了直接在配置文件中保存敏感信息。Secret 会以 Volume 的形式被 mount 到 Pod，容器可通过文件的方式使用 Secret 中的敏感数据；此外，容器也可以环境变量的方式使用这些数据。

本节演示如何为 MySQL 数据库提供持久化存储，步骤为： 创建 PV 和 PVC。 部署 MySQL。 向 MySQL 添加数据。 模拟节点宕机故障，Kubernetes 将 MySQL 自动迁移到其他节点。 验证数据一致性。 首先创建 PV 和 PVC，配置如下： mysql-pv.yml mysql-pvc.yml 创建 mysql-pv 和 mysql-pvc： 接下来部署 MySQL，配置文件如下：

前面的例子中，我们提前创建了 PV，然后通过 PVC 申请 PV 并在 Pod 中使用，这种方式叫做静态供给（Static Provision）。 与之对应的是动态供给（Dynamical Provision），即如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。 动态供给是通过 StorageClass

当不再需要使用 PV，可以删除 PVC 回收 PV。 当 PVC mypvc1 被删除后，我们发现 Kubernetes 启动了一个新 Pod recycler-for-mypv1，这个 Pod 的作用就是清除 PV mypv1 的数据。此时 mypv1 的状态为 Released，表示已经解除了与 mypvc1 的 Bound，正在清除数据，不过此时还不可用。 当数据清除完毕，mypv1 的状态重新变为

上一节我们介绍了 PV 和 PVC，本节通过 NFS 实践。 作为准备工作，我们已经在 k8s-master 节点上搭建了一个 NFS 服务器，目录为 /nfsdata： 下面创建一个 PV mypv1，配置文件 nfs-pv1.yml 如下： ① capacity 指定 PV 的容量为 1G。 ② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有： ReadWriteOnce

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。 拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息： 当前 Volume 来自 AWS EBS。 EBS Volume 已经提前创建，并且知道确切的 volume-id。 Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息： 要么询问管理员。

如果 Kubernetes 部署在诸如 AWS、GCE、Azure 等公有云上，可以直接使用云硬盘作为 Volume，下面是 AWS Elastic Block Store 的例子： 要在 Pod 中使用 ESB volume，必须先在 AWS 中创建，然后通过 volume-id 引用。其他云硬盘的使用方法可参考各公有云厂商的官方文档。 Kubernetes Volume 也可以使用主流的分布式存，比如

hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。大部分应用都不会使用 hostPath Volume，因为这实际上增加了 Pod 与节点的耦合，限制了 Pod 的使用。不过那些需要访问 Kubernetes 或 Docker 内部数据（配置文件和二进制库）的应用则需要使用 hostPath。 比如 kube-apiserver

本章将讨论 Kubernetes 如何管理存储资源。 首先我们会学习 Volume，以及 Kubernetes 如何通过 Volume 为集群中的容器提供存储；然后我们会实践几种常用的 Volume 类型并理解它们各自的应用场景；最后，我们会讨论 Kubernetes 如何通过 Persistent Volume 和 Persistent Volume Claim 分离集群管理员与集群用户的职责，并实践

上一节讨论了 Health Check 在 Scale Up 中的应用，Health Check 另一个重要的应用场景是 Rolling Update。试想一下下面的情况： 现有一个正常运行的多副本应用，接下来对应用进行更新（比如使用更高版本的 image），Kubernetes 会启动新副本，然后发生了如下事件： 正常情况下新副本需要 10 秒钟完成准备工作，在此之前无法响应业务请求。

这篇文章是接着前面《IT人士如何避免中年危机？》和《我所参加的最贵的培训》的思路来的。 《IT人士如何避免中年危机？》讨论了价值投资的必要性，并给出了方法论： 找到优质的公司 在它股价合理或低估的时候买入 耐心等待其升值 《我所参加的最贵的培训》具体讨论了如何通过上市公司的财务报表筛选优质的企业，并计算股价的合理区间，给出了价值投资的具体实践方法。 今天要讨论的问题是：该拿多少钱来做投资？ 什么是资产配置？

对于多副本应用，当执行 Scale Up 操作时，新副本会作为 backend 被添加到 Service 的负责均衡中，与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段，比如加载缓存数据，连接数据库等，从容器启动到正真能够提供服务是需要一段时间的。我们可以通过 Readiness 探测判断容器是否就绪，避免将请求发送到还没有 ready 的 backend。 下面是示例应用的配置文件。

上一篇《IT人士如何避免中年危机？》得到了很多关注，留言赞赏也创了本公众号（cloudman6）的记录。 这个结果既在意料之中，也在意料之外。 意料之中是因为这确实是个能够引发共鸣的话题。每个人的职业生涯有40多年，总会有低谷，总会遭遇风雨，只有未雨绸缪，提前做准备才能从容应对。 意料之外是因为作为一个 IT 工程师，我没学过专业的投资理论，也没有傲人的投资成就，只是喜欢多了解世界，求知欲稍强，多些好奇心而已。

除了 Liveness 探测，Kubernetes Health Check 机制还包括 Readiness 探测。 用户通过 Liveness 探测可以告诉 Kubernetes 什么时候通过重启容器实现自愈；Readiness 探测则是告诉 Kubernetes 什么时候可以将容器加入到 Service 负载均衡池中，对外提供服务。 Readiness 探测的配置语法与 Liveness

今天咱们不谈技术，来聊点别的。 这也可能是比学习具体技术更重要的话题 - 投资。 我把投资分成两类： 投资股票、期货、现货、黄金这类常见投资品种。 投资自己。比如看书、学习、参加培训。当然《每天5分钟玩转 Kubernetes》也算。 从见效周期看，第一类很快，盈亏都是立即反馈；而第二类见效慢，但好处是不管怎样都是赚！ 所以建议大家多做第二类投资。 无论第一类还是第二类，都是越早开始越好。