K8S——应用为中心的封装:Kustomize与Helm

K8S——应用为中心的封装:Kustomize与Helm

关于命令式和声明式的区别。

命令式

把碗洗了

把盘子也

把锅洗了

洗完的东西擦干

把洗菜池池底清理干净

把洗菜池擦干

把吧台水擦干

把洗完的碗筷盘子擦干

声明式

我需要一个整洁的厨房,如图所示。

我会花两节课的时间,给你介绍一下最近几年容器封装的两种主流思路,你可以从中理解容器“以应用为中心的封装”这个理念在不同阶段的内涵变化,这也是对“应用”这个概念的不断扩展升华的过程。

今天这节课呢,我们就先来了解下 Kustomize 和 Helm,它们是封装“无状态应用”的典型代表。

  • 额外知识:无状态应用

    无状态应用与有状态应用的区别无状态应用(Stateless Application)与有状态应用(Stateful Application)说的是应用程序是否要自己持有其运行所需的数据,如果程序每次运行都跟首次运行一样,不依赖之前任何操作所遗留下来的痕迹,那它就是无状态的;反之,如果程序推倒重来之后,用户能察觉到该应用已经发生变化,那它就是有状态的。下一讲要介绍的 Operator 与 OAM 就是支持有状态应用的封装方式,这里你可以先了解一下。

    比如查询应用是无状态服务,随掉随用

    数据库是有状态应用,每次新启一个数据库没有数据查不出东西。

Kustomize

最初,由 Kubernetes 官方给出的“如何封装应用”的解决方案是“用配置文件来配置文件”,这不是绕口令,你可以把它理解为是一种针对 YAML 的模版引擎的变体。

Kubernetes 官方认为,应用就是一组具有相同目标的 Kubernetes 资源的集合,如果逐一管理、部署每项资源元数据太麻烦啰嗦的话,那就提供一种便捷的方式,把应用中不变的信息与易变的信息分离开,以此解决管理问题;把应用所有涉及的资源自动生成一个多合一(All-in-One)的整合包,以此解决部署问题。这有点类似于springboot的自动装配的思想。

而完成这项工作的工具就叫做Kustomize,它原本只是一个独立的小程序,从 Kubernetes 1.14 起,被纳入了 kubectl 命令之中,成为随着 Kubernetes 提供的内置功能。Kustomize 使用Kustomization 文件来组织与应用相关的所有资源,Kustomization 本身也是一个以 YAML 格式编写的配置文件,里面定义了构成应用的全部资源,以及资源中需根据情况被覆盖的变量值。

Kustomize 的主要价值是根据环境来生成不同的部署配置。只要建立多个 Kustomization 文件,开发人员就能以基于基准进行派生(Base and Overlay)的方式,对不同的模式(比如生产模式、调试模式)、不同的项目(同一个产品对不同客户的客制化)定制出不同的资源整合包。

在配置文件里,无论是开发关心的信息,还是运维关心的信息,只要是在元数据中有描述的内容,最初都是由开发人员来编写的,然后在编译期间由负责 CI/CD 的产品人员针对项目进行定制。最后在部署期间,由运维人员通过 kubectl 的补丁(Patch)机制更改其中需要运维去关注的属性,比如构造一个补丁来增加 Deployment 的副本个数,构造另外一个补丁来设置 Pod 的内存限制,等等。

k8s
 ├── base
 │     ├── deployment.yaml
 │     ├── kustomization.yaml
 │     └── service.yaml
 └── overlays
       └── prod
       │     ├── load-loadbalancer-service.yaml
       │     └── kustomization.yaml
       └── debug
             └── kustomization.yaml

从上面这段目录结构中,我们可以观察到一个由 kustomize 管理的应用结构,它主要由 base 和 overlays 组成。Kustomize 使用 Base、Overlay 和 Patch 生成最终配置文件的思路,与 Docker 中分层镜像的思路有些相似,这样的方式既规避了以“字符替换”对资源元数据文件的入侵,也不需要用户学习额外的 DSL 语法(比如 Lua)。

从效果来看,使用由 Kustomize 编译生成的 All-in-One 整合包来部署应用是相当方便的,只要一行命令就能够把应用涉及的所有服务一次安装好,一定本机或者租云服务器自己动手实践一下​。

但是,毕竟 Kustomize 只是一个“小工具”性质的辅助功能,对于开发人员来说,Kustomize 只能简化产品针对不同情况的重复配置,它其实并没有真正解决应用管理复杂的问题,要做的事、要写的配置,最终都没有减少,只是不用反复去写罢了;而对于运维人员来说,应用维护不仅仅只是部署那一下,应用的整个生命周期,除了安装外还有更新、回滚、卸载、多版本、多实例、依赖项维护等诸多问题,都很麻烦。

所以说,要想真正解决这些问题,还需要更加强大的管理工具,比如下面我要介绍的主角 Helm。不过 Kustomize 能够以极小的成本,在一定程度上分离了开发和运维的工作,不用像 Helm 那样需要一套独立的体系来管理应用,这种轻量便捷,本身也是一种可贵的价值。

Helm 与 Chart

Helm是由Deis 公司开发的一种更具系统性的管理和封装应用的解决方案,它参考了各大 Linux 发行版管理应用的思路,应用格式是 Chart。(相当于yum之于CentOs,apt-get之于Ubuntu)

Helm 一开始的目标就很明确:如果说 Kubernetes 是云原生操作系统的话,那 Helm 就要成为这个操作系统上面的应用商店与包管理工具。

我相信,Linux 下的包管理工具和封装格式,如 Debian 系的 apt-get 命令与 dpkg 格式、RHEL 系的 yum 命令与 rpm 格式,你肯定不会陌生。有了包管理工具,你只要知道应用的名称,就可以很方便地从应用仓库中下载、安装、升级、部署、卸载、回滚程序,而且包管理工具掌握着应用的依赖信息和版本变更情况,具备完整的自管理能力,每个应用需要依赖哪些前置的第三方库,在安装的时候都会一并处理好。

Helm 模拟的就是这种做法,它提出了与 Linux 包管理直接对应的 Chart 格式和 Repository 应用仓库,另外针对 Kubernetes 中特有的一个应用经常要部署多个版本的特点,也提出了 Release 的专有概念。

Chart 用于封装 Kubernetes 应用涉及到的所有资源,通常是以目录内的文件集合的形式存在的。目录名称就是 Chart 的名称(没有版本信息),比如官方仓库中 WordPress Chart 的目录结构是这样的:

WordPress
 ├── templates
 │     ├── NOTES.txt
 │     ├── deployment.yaml
 │     ├── externaldb-secrets.yaml
 │     └── 版面原因省略其他资源文件
 │     └── ingress.yaml
 └── Chart.yaml
 └── requirements.yaml
 └── values.yaml

其中有几个固定的配置文件:Chart.yaml 给出了应用自身的详细信息(名称、版本、许可证、自述、说明、图标,等等),requirements.yaml 给出了应用的依赖关系,依赖项指向的是另一个应用的坐标(名称、版本、Repository 地址),values.yaml 给出了所有可配置项目的预定义值。

可配置项就是指需要部署期间由运维人员调整的那些参数,它们以花括号包裹在 templates 目录下的资源文件中。当部署应用时,Helm 会先将管理员设置的值覆盖到 values.yaml 的默认值上,然后以字符串替换的形式,传递给 templates 目录的资源模版,最后生成要部署到 Kubernetes 的资源文件。

由于 Chart 封装了足够丰富的信息,所以 Helm 除了支持命令行操作外,也能很容易地根据这些信息自动生成图形化的应用安装、参数设置界面。

我们再来说说 Repository 仓库。它主要是用于实现 Chart 的搜索与下载服务,Helm 社区维护了公开的 Stable 和 Incubator 的中央仓库(界面如下图所示),也支持其他人或组织搭建私有仓库和公共仓库,并能够通过 Hub 服务,把不同个人或组织搭建的公共仓库聚合起来,形成更大型的分布式应用仓库,这也有利于 Chart 的查找与共享。

K8S——应用为中心的封装:Kustomize与Helm_第1张图片

所以整体来说,Helm 提供了应用全生命周期、版本、依赖项的管理能力,同时,Helm 还支持额外的扩展插件,能够加入 CI/CD 或者其他方面的辅助功能。

如此一来,它的定位就已经从单纯的工具升级到应用管理平台了,强大的功能让 Helm 收到了不少支持,有很多应用主动入驻到官方的仓库中。而从 2018 年起,Helm 项目被托管到 CNFC,成为其中的一个孵化项目。

总而言之,Helm 通过模仿 Linux 包管理器的思路去管理 Kubernetes 应用,在一定程度上确实是可行的。不过,在 Linux 与 Kubernetes 中部署应用还是存在一些差别,最重要的一点是在 Linux 中 99% 的应用都只会安装一份,而 Kubernetes 里为了保证可用性,同一个应用部署多份副本才是常规操作。

所以,Helm 为了支持对同一个 Chart 包进行多次部署,每次安装应用都会产生一个 Release,Release 就相当于该 Chart 的安装实例。对于无状态的服务来说,靠着不同的 Release 就已经足够支持多个服务并行工作了,但对于有状态的服务来说,服务会与特定资源或者服务产生依赖关系,比如要部署数据库,通常要依赖特定的存储来保存持久化数据,这样事情就变得复杂起来了。

既然 Helm 无法很好地管理这种有状态的依赖关系,那么这一类问题就是 Operator 要解决的痛点了。这也是我在下一节课要给你重点介绍的工具。

小结

今天,我给你介绍了两种比较常用,也较为具体的应用封装方式,分别是 Kubernetes 官方推出的 Kustomize,以及目前在 Kubernetes 上较为主流的“应用商店”格式 Helm 与 Chart。这样的封装对于无状态应用已经足够了,但对于有状态应用来说,仍然不能满足需要。在下节课,我们将继续应用封装这个话题,一起来探讨如何为有状态应用提供支持。

一课一思

你是否尝试过在 Kubernetes 中部署一些需共享状态的集群应用?比如 Etcd、Easticsearch 等等?你是自己编写 YAML,定义它们所需的各种资源的吗?

你可能感兴趣的:(kubernetes,java,容器)