1.2 [kustz] 简介和设计思路

如果要在 Kubernets 发布一个应用， 并对外提供服务， 需要配置诸如 Dep, Ing, Svc 等 Config API。
他们之间又是通过 Label 组合选择而实现的 松耦合。

1. 如果想要这些 Config API 之间的关系更加紧密， 我们可以自己再向上抽象， 通过自己的配置将他们整合在一起。
2. 更重要的是， 我们可以通过这层抽象， 屏蔽不同版本 API 之间差异。 实现同一个 kustz.yml 配置兼容多版本集群， 实现部署或迁移的丝滑。

Kustomize

kustomize: https://kubectl.docs.kubernetes.io/guides/introduction/kustomize/

现在这个官网的引导页面看起来已经有点乱了。

简单的说， 以下是一个最基本的 kustomization.yaml 文件。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: demo-demo
resources:
  - deployment.yml
  - service.yml
  - ingress.yml

1. ApiVersion 和 Kind : 对文件的作用定义
2. Namespace : 服务部署的运行环境。
3. Resources : 从外部引入的资源， 最终由 kustomize 统一渲染管理。 比如 patch 操作等。

Deployment, Pod 和 Container

先来说说 Deployment， 这个应该是最常见的 工作负载 workload， 定义 Pod 状态 。

我们都知道， Pod 是 Kubernetes 中最小的 调度 单元， 定义网络、存储、权限等信息。

换而言之， 最小的 执行 单元其实还是 Container， 定义了执行

通过 kubectl 命令

$ kubectl create deployment my-nginx --image nginx:alpine --dry-run=client -o yaml

生成的最简单的 Deployment 模版。

1. 最外层红色是 deployment.
2. 中间层蓝色是 pod.
3. 最内存绿色是 container.

没错， 他们之间的关系就是套娃， 一层套一层。

kustz

kustz 的作用就如同 Deployment 一样， 将 应用 视作一个整体， 通过 某种 组织方式， 在一个文件中定义一个 应用/服务。

1. 将所有的配置都集中到 同一个文件 中， 多个资源更方便管理。
2. 将原本复杂的 API 结构 语义化， 配置起来更简单。

# kustz.yml

namespace: demo-demo # 运行的命名空间

service:  # 定义一个应用
  name: srv-webapp-demo
  image: docker.io/library/nginx:alpine
  replicas: 1
  envs:   # 容器变量配置
    pairs:
      key1: value1-123
  resources:
    cpu: 10m/20m
    memory: 10Mi/20Mi

  probes: # 容器探针
    liveness:
      action: http://:80/liveness

  ports: # Service 端口
    - "80:80"       # cluster ip

## 对外暴露
ingress:
  - http://www.example.com/*

注意: 以上配置文件结构，可能会随着代码开发进行调整。

如此这边，我们就可以通过 kustz.yml 定义完成一个服务的 完整配置定义 ， 之后再通过 kustz 工具将起转化为 kustomization.yml, deployment.yml ... 等文件， 最后通过 kubectl 工具进行发布管理。