个人理解

想到了命令式语言与声明式语言。
SQL 是命令式语言，写 SQL 时不需要关心 SQL 具体的执行流程，只需要声明想要查询什么。
Kubernete 是声明式系统，那么说明使用 Kubernete 创建服务时，不需要关注 Kubernete 具体的细节，只要声明最终的服务。这个声明是通过 yaml 来实现的。—— 我的理解应该是准备的，这也是看到一些 Kubernete 的管理员称自己为 yaml 工程师。

文章摘要

  • 面向 Kubernetes 编程： Kubernetes 是下一代操作系统

    软件交付的历史

    1. 交付「源代码」： 这应该是最早的时代，客户现场的环境（操作系统、机型）都不同，需要带着代码到客户现场编译，然后运行软件。
    2. 交付 「可运行文件」：像 Java 提出的 “Build once, run everywhere” 概念，在这个时代，我们可以面向一个运行时虚拟机交付软件。或者我们都面向 Linux 交付，我们的使用 Go 编译的二进制，能顺利的部署到大多数的 Linux OS 上。但是这种方案也强依赖客户现场需要装上指定版本的 Java 虚拟机，或者 Linux 特定的版本(应用依赖 Linux 内核特性)。
    3. 交付 镜像：交付镜像，最大可能的屏蔽了底层 OS, Java 虚拟机的差异。在镜像里面，我们把自己需要的 OS 基础 和 Java 虚拟机也装上了。不再依赖客户现场的 OS 和 Java 虚拟机版本了。

交付镜像就是交付 Docker 镜像了，但是在作者看来，交付镜像也不完美。

在我眼里，镜像做的事情完全不够。原因无非也是这么些：

  1. 怎么配置启动参数，要交付人员辛苦的读懂启动参数配置说明说吗？
  2. 怎么做分布式应用的组网、服务发现
  3. 怎么做容灾
  4. 怎么做部署的元数据录入： 今天我在客户现场把 A 应用部署到了 节点1 上面，我要把这个信息记在哪儿？
  5. 自己亲自去做进程拉起、副本健康检查、副本保持等功能。

我非常赞同，当初同事说使用镜像时，我就非常坚持需要写文档，不然镜像如何启动。部署了 Docker 镜像，还是需要配置 Nginx，做监控检查，还需要关心每个节点的副本是不是会挂，也挺烦的。

面向 Kubernetes 交付软件

  • CRD，Custom Resource Defines。？？？
  • CR，Custom Resoures，客户资源。CRD 的实例，实际上也就是一个 yaml 文件；
  • Operator，即 CRD + CR。—— 这就是声明式？？

image.png

Operator

  • Observe, 观察。当用户提交了 CR 时或者 pod 发生故障时，Observe 就会监控到；
  • Analyze 分析，根据 Observe 观察的结果进行分析；
  • Action 行动，创建 Pod。

image.png