本文 首发于 🌱 煎茶， 转载 请注明 来源。

阅读感悟

暂略

阅读摘录

《Helm学习指南：Kubernetes上的应用程序管理》

马特·布彻 马特·法里纳 乔什·多利茨基 32个笔记

1.1 云原生生态系统

◆ 有一项关键的技术提供了移动容器镜像的能力，即镜像登记站（image registry），这是一种专门的块存储技术，它容纳容器，使其可供主机使用。主机可以将容器镜像推送（push）到登记站，该动作会将各层传输到登记站。然后另一台主机可以将镜像从登记站拉取（pull）到该主机的环境中，如此一来该主机就可以执行此容器了。

◆ 。组合这些的标准格式是name:tag@digest，其中只有name是必需的。

◆ 2015年，时机已经成熟：Docker容器正在向企业进军。显然，此时需要一种工具来管理跨主机的容器调度和资源管理。多种技术相继登场：Mesos引入了Marathon；Docker创建了Swarm；Hashicorp发布了Nomad；Google创建了其内部Borg平台的开源兄弟，并将这项技术命名为Kubernetes（希腊语中的船长一词）。

◆ 每一个调度器都有其优点和缺点。但是Kubernetes引入了两个概念，使它与众不同：声明性基础设施（declarative infrastructure）和协调循环（reconciliation loop）。

◆ 在Kubernetes上安装一个容器更像是在说，“我希望这个容器在这个端口上运行，使用一定量的CPU并在文件系统的这个位置上安装一些存储”。Kubernetes在后台工作，根据我们对所需内容的声明来连接所有内容。

◆ 在协调循环中，调度程序说：“这是用户所需的状态。以下是当前状态。它们不一样，所以我将采取步骤来协调它们。”用户希望为容器提供存储空间。当前没有附加存储。因此Kubernetes创建了一个存储单元并将其附加到容器中。容器需要公共网络地址。现在也不存在。所以一个新的地址被附加到容器上。Kubernetes中的不同子系统开展工作以实现用户对所需状态的整体声明的各个部分。最终，Kubernetes要么成功地创建了用户想要的环境，要么得出了无法实现用户需求的结论。同时，用户只能被动地观察Kubernetes集群并等待它成功完成或将安装标记为失败。

◆ 一般一个pod只有一个容器。但有时有一些用于为主容器做预配置并在主容器联机之前退出的容器，这些被称为初始化容器（init container）。另外有一些与主容器同时运行并提供辅助服务的容器，这些被称为边车容器（sidecar container）。这些都被认为是同一个pod的一部分。

◆ 在前面的代码中，我们编写了Kubernetes Pod资源的定义。当用YAML或JSON表示时，这些定义称为清单（manifest）

◆ Secret在结构上类似于ConfigMap，只是data部分中的值必须是Base64编码的。

◆ Deployment由一些顶级配置数据以及构建副本pod的模板组成。

◆ Service是一种持久的网络资源（有点像静态IP），即使连接到它的一个或多个pod消失，它也会持久存在。这样，Kubernetes Pod可以来去自如，而网络层可以继续将流量路由到同一Service端点。

◆ 虽然Service是一个抽象的Kubernetes概念，但在幕后它可以实现为从路由规则到外部负载均衡器的任何东西

1.2 Helm的目标

◆ YAML。Helm的核心思想是，所有这些对象都可以打包在一起进行安装、更新和删除

◆ Kubernetes就像一个操作系统。在它的基础上，操作系统提供了执行程序的环境。它提供了存储、执行和监视程序生命周期所需的工具

◆ 它不执行程序，而是执行容器。但与操作系统类似，它提供了存储、执行和监视这些容器所需的工具

◆ 当我们将Kubernetes设想为一个操作系统时，很快就看到了对Kubernetes软件包管理器的需求

◆ 我们最初借鉴Homebrew（macOS的软件包管理器）和Apt（Debian的软件包管理器）对Helm进行设计。但随着Helm的成熟，我们已经尽可能多地借鉴不同的软件包管理器。

◆ 典型的操作系统和Kubernetes之间有一些区别。其中之一是Kubernetes支持运行同一应用程序的多个实例。

◆ 另一个在典型操作系统中很少见的概念是命名空间（namespace），但它是Kubernetes的核心。

◆ 这些只是Kubernetes与传统操作系统不同的几个方面。这些差异和其他差异对Helm的设计提出了挑战。我们不得不构建Helm来充分利用这些差异，但同时又不放弃关于我们的软件包管理比喻。

◆ 例如，Helm安装命令不仅需要软件包的名称，还需要用户提供的名称，通过用户提供的该名称可以引用该软件包的已安装版本

3.1 模板和试运行

◆ 换句话说，–set值覆盖传入的值文件中的设置，而传入的值文件又覆盖chart的默认values.yaml文件中的任何内容。

◆ helm install和helm upgrade等命令提供了一个名为–dry-run的标志。当在命令行中添加此标志时，将导致Helm逐步完成前四个阶段（加载chart、确定值、渲染模板、格式化为YAML）。但是当第四阶段结束时，Helm会将大量信息转储到标准输出，包括所有渲染的模板。然后它将退出，而不将对象发送给Kubernetes，也不创建任何发布记录。

◆ –dry-run标志的主要目的是让人们有机会在将输出发送到Kubernetes之前检查和调试输出

◆ 但在它被引入后不久，Helm维护人员就注意到了用户中的一种趋势：人们希望使用–dry-run将Helm用作模板引擎，然后使用其他工具（如kubectl）将渲染的输出发送到Kubernetes。但是编写–dry-run时没有考虑到这个用例，这导致了一些问题：1.–dry-run将非YAML信息与渲染的模板混合。这意味着在将数据发送到kubectl等工具之前，必须对其进行清理。2.–dry-run在升级时可能会产生与其安装时不同的YAML输出，这可能会让人困惑。3.它会联系Kubernetes API服务器进行验证，这意味着Helm必须拥有Kubernetes凭据，即使它只是用来试运行一个发行版本。4.它还将特定于集群的信息插入模板引擎。因此，某些渲染过程的输出可能是特定于集群的。为了解决这些问题，Helm维护人员引入了一个完全独立的命令：helm template。

◆ 虽然–dry-run是为调试而设计的，但helm template是为了将Helm的模板渲染过程与安装或升级逻辑隔离开来。

◆ 之前，我们研究了Helm安装或升级的5个阶段。template命令执行前4个阶段（加载chart、解析值、渲染模板、格式化为YAML）。

◆ ·在helm template执行期间，Helm从不联系远程Kubernetes服务器。·template命令的作用始终类似于安装。·通常需要联系Kubernetes服务器的模板函数和指令将只返回默认数据。·chart只能访问默认的Kubernetes类型。

3.2 了解发布版本信息

◆ 的5个Helm安装阶段：1.加载chart。2.解析值。3.执行模板。4.渲染YAML。5.把它发送到Kubernetes。

◆ 在最后一个阶段，Helm将数据发送给Kubernetes。然后二者“来回沟通”，直到发布版本被接受或拒绝。

3.3 历史记录和回滚

◆ 看到helm uninstall命令有一个名为–keep history的标志。通常，删除事件将销毁与该安装相关联的所有发布记录。但是当指定–keep history时，即使删除了安装，你也可以看到它的历史记录

3.4 深入了解安装和升级

◆ 使用–generate name标志，我们不再需要提供名称作为helm install的第一个参数。Helm根据chart名称和时间戳的组合生成名称

– 来自微信读书