Skip to main content

聊聊 K8S 中的 Sidecar 设计模式·第 2 篇

· 阅读需要 1 分钟

介绍

在前一篇文章 聊聊 K8S 中的Sidecar设计模式·第 1 篇中,我们介绍了土话说的三蹦子的 Sidecar 设计模式。本文尝试用 KCL 这种现代化的类型安全的配置语言,来展示 Pod 资源的描述,在后续的文章中,我们将以 KCL 来介绍 Sidecar 这种模式的实际应用。

1. Pod 的 OpenAPI 定义

先回到最开始最简单的 Nginx 例子,其 YAML 文件几乎是相同的模式:

apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- image: nginx
name: main-container
ports:
- containerPort: 80

这里的 Pod 数据满足 Kubernetes 规范 中 io.k8s.api.core.v1.Pod 模型的定义。完整的 OpenAPI 定义请 参考。仔细分析可以发现,apiVersion 和 kind 信息都是比较常见的默认配置,我们需要更现代的配置语言来简化。

2. 使用 KCL 定义 Pod 资源

KCL 是一门面向云原生领域配置策略语言,详细资料可参考语言官网

基本的 KCL 配置程序仍然遵循 K=V 的形式, YAML 比较相似。比如,我们可以用下面的 KCL 代码来重写 Nginx 容器的配置:

import k8s.api.core.v1 as k8core

k8core.Pod {
metadata.name = "web-app"
spec.containers = [{
name = "main-container"
image = "nginx"
ports = [{containerPort: 80}]
}]
}

其中 import 导入了 k8s 包中的 k8s/api/core/v1 包,其中的 Pod 结构定义对应 Pod 模型,其中已经包含了 apiVersion 和 kind 的默认值,因此只需要添加 metadata.namespec.containers 属性(KCL 也针对一些多级嵌套的属性提供了的语法糖)。

我们可以通过包管理工具创建一个 KCL 程序来定义一个 Pod 资源。并执行这个程序来得到对应的 YAML。

# 1. 初始化一个 kcl 程序包 hello.
kpm init hello

# 2. 编辑 hello 包内的 main.k 文件,
# 将前文中提到的 KCL 配置代码添加到 hello/main.k 中
cat <<EOF > hello/main.k
import k8s.api.core.v1 as k8core

k8core.Pod {
metadata.name = "web-app"
spec.containers = [{
name = "main-container"
image = "nginx"
ports = [{containerPort: 80}]
}]
}
EOF

# 3. 进入到 hello 包内,添加 k8s 依赖,并且运行 hello 包。
cd hello && kpm add k8s && kpm run

可以得到如下 YAML 输出:

apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- image: nginx
name: main-container
ports:
- containerPort: 80

3. 小结

这一篇文章我们简要介绍了如何通过 KCL 构建出 Pod 配置来获得更灵活、更健壮的配置。后续文章中我们将通过 KCL 来提炼和抽象最佳的 Sidecar 模式实践,包括使用 KCL 对 Sidecar 模型进行抽象以及使用 KCL 对已存在的上游 YAML 配置进行 Sidecar 注入。