Golang人性化Kubernetes资源对象创建库。极简,无额外心智负担。
go get -u github.com/yulibaozi/beku
- 极简的JSON和YAML输入/输出
- 自动判断资源对象的必要字段
- 人性化的资源对象关联发布
- 严谨的QOS等级设置
- 准确的字段自动填充
- 写意的链式调用
beku的诞生来源于对现实工作上的不满, 资源对象配置繁琐, 本身大量的字段已经让人难以忍受, 何况层级又带来了额外的心智负担, 还有多个资源对象重复劳动带来的低效能工作, 这三者的纠缠催生了beku, 这实在令人欢欣鼓舞。
beku的使用场景是对接Kubernetes的客户端(eg:client-go), 当然, 也可以使用beku生成json或者yaml供命令行创建。另外,beku库中存在Kubernetes一些源代码,这对于beku的实现提供了极大的帮助,这非常值得尊敬。
- beku的使用习惯是以NewXXX()开始链式调用, 最终以调用Finish()表示调用结束, 从而得到完整的kubernetes资源对象配置信息。
- 所有的填写都以SetXXX()开头, 所有的获取都以GetXXX()开头。
- 在使用beku时, 尽量不使用强转的方式来满足函数所需要的变量类型, 这会引发未知错误。
- 在使用beku时, 如果有函数的参数不知道填什么, 实现函数的注释中有相关阐述。
- 在beku的应用场景中, Pod中的第一个container往往有至高地位, 拥有优先设置的权利, 随着序列的变大越显得平凡, 比如:第一次设置环境的时候, 只会为第一个container设置, 而不会为第二个设置, 当你第二次调用设置环境变量方法时, 才会设置第二container的环境变量, 以此类推。
- 如果某结构体存在union字符时, 那么说明会同时创建两个Kubernetes资源对象, 例如:Deployment和Service的联合,PersistentVolume和PersistentVolumeClaim的联合
如何快速创建一个Service(svc)?
正如你所见:
func howToNewSvc() {
svc, err := beku.NewSvc().SetNamespaceAndName("roc", "mysql-svc").
SetSelector(map[string]string{"app": "mysql"}).SetServiceType(beku.ServiceTypeNodePort).
SetPort(beku.ServicePort{Port: 3306, TargetPort: 3306}).Finish()
if err != nil {
panic(err)
}
yamlbyts, err := beku.ToYAML(svc)
jsonbyts, err := beku.ToJSON(svc)
if err != nil {
panic(err)
}
}
ToYAML
apiVersion: v1
kind: Service
metadata:
creationTimestamp: null
name: mysql-svc
namespace: roc
spec:
ports:
- port: 3306
protocol: TCP
targetPort: 3306
selector:
app: mysql
type: NodePort
status:
loadBalancer: {}
ToJSON
{
"kind":"Service",
"apiVersion":"v1",
"metadata":
{
"name":"mysql-svc",
"namespace":"roc",
"creationTimestamp":null
},
"spec":
{
"ports":
[
{
"protocol":"TCP",
"port":3306,
"targetPort":3306
}
],
"selector":
{
"app":"mysql"
},
"type":"NodePort"
},
"status":
{
"loadBalancer":{}
}
}
更多示例如: Example.md
资源对象 | 简称 | 版本 |
---|---|---|
namespace | ns | core/v1 |
service | svc | core/v1 |
deployment | - | apps/v1 |
statefulset | sts | apps/v1 |
secret | - | core/v1 |
persistentVolumeClaim | pvc | core/v1 |
persistentVolume | pv | core/v1 |
daemonSet | ds | apps/v1 |
configMap | cm | core/v1 |
-
当某个资源对象存在多个版本时, 只会实现其中一个版本, 版本的选择的首要条件是按照稳定性来选择的, 而不是功能多样性, 这可能导致实现的版本稍延后于最新流行的版本, 但, 没关系, 稳定可用才是第一前提, 另一方面, 在选择版本的优先级版本方面如下(优先级越高越在前面)。
- core/v1
- apps/v1 ...
-
当某资源对象缺少稳定级版本时, 在实现kubernetes resouce object时, 不会实现Alpha, Beta级别的资源对象, 如果k8s某资源对象不存在stable版本, beku会选择放弃实现, 原因是其他不稳定版本或者较稳定版本存在更改的风险较大, 稳定性会降低。
-
关于API版本的参考资料如下: Kubernetes API 概述
在过去的工作经历中,我发现kubernetes资源对象的配置甚似繁琐, 除去配置字段本身复杂外, 配置需要的额外心智负担也存在, 简单归纳如下:
- 配置字段那些是必要, 那些是可需要, 这是个问题;
- Kubernete资源对象层级较深, 配置字段该放在json/yaml的哪个位置, 这是个问题;
- yaml配置时, 需要考虑缩进, 容易出错;
- 实现多个资源对象, 上述的问题会N次重现, 头发掉一地谁买单, 这是个问题。
现阶段, 在实现上还有许多不足, 例如:某种资源对象的的字段有多种填写策略, 为了简便, 我们实现了其中常用的填写方式而隐藏了复杂的填写策略, 这可能会导致kubernetes资源对象本身就支持的多种填写策略被阉割, 如果您觉得是常用的, 必不可少的, 您可以提交pr或者issue来共同探讨。另一方面, 还有些功能还趋待完善, 我们可以共同成长。
在未来,期望能够消灭掉上述的三点不足和遵照以下目标前进
- 调用方提供必要的字段,不需要考虑那些字段需要还是不需要;
- 调用方提供无层级的配置字段,免去这些额外负担;
- 调用方提供必要的字段后,生成完整的json/yaml配置信息。
- 调用方提供单一字段后,自动补充相关联的其他字段。
- 当提供的必要字段不完整时,返回相关字段缺少,引导调用方逐步填写完整。