关于k8s:面向K8s设计误区

K8s设计模式

Kubernetes是一个具备普遍意义的容器编排工具，它提供了一套基于容器构建分布式系统的根底依赖，其意义等同于Linux在操作系统中的位置，能够认为是分布式的操作系统。

自定义资源

K8s提供了Pod、Service、Volume等一系列根底资源定义，为了更好提供扩展性，CRD 性能是在1.7 版本被引入。

用户能够依据本人的需要增加自定义的 Kubernetes 对象资源（CRD）。值得注意的是，这里用户本人增加的 Kubernetes 对象资源都是 native 的都是一等公民，和 Kubernetes 中自带的、原生的那些 Pod、Deployment 是同样的对象资源。在 Kubernetes 的 API Server 看来，它们都是存在于 etcd 中的一等资源。同时，自定义资源和原生内置的资源一样，都能够用 kubectl 来去创立、查看，也享有 RBAC、平安性能。用户能够开发自定义控制器来感知或者操作自定义资源的变动。

Operator

在自定义资源根底上，如何实现自定义资源创立或更新时的逻辑行为，K8s Operator提供了相应的开发框架。Operator通过扩大Kubernetes定义Custom Controller，list/watch 对应的自定义资源，在对应资源发生变化时，触发自定义的逻辑。

Operator 开发者能够像应用原生 API 进行利用治理一样，通过申明式的形式定义一组业务利用的冀望终态，并且依据业务利用的本身特点进行相应控制器逻辑编写，以此实现对利用运行时刻生命周期的治理并继续保护与冀望终态的一致性。

艰深的了解

CRD是K8s标准化的资源扩大能力，以java为例，int、long、Map、Object是java内置的类，用户能够自定义Class实现类的扩大，CRD就是K8s中的自定义类，CR就是对应类的一个instance。

Operator模式 = 自定义类 + 观察者模式，Operator模式让大家编写K8s的扩大变得非常简单快捷，逐步成为面向K8s设计的规范。

Operator提供了标准化的设计流程：

应用 SDK 创立一个新的 Operator 我的项目
通过增加自定义资源（CRD）定义新的资源 API
指定应用 SDK API 来 watch 的资源
自定义Controller实现K8s协调（reconcile）逻辑
有了锤子，看到的只有钉子
咱们团队（KubeOne团队）始终在致力于解决简单中间件利用如何部署到K8s，天然也是Operator模式的践行者。经验了近2年的开发，初步解决了中间件在各个环境K8s的部署，以后两头也走了很多弯路，踩了很多坑。

KubeOne内核也经验3个大版本的迭代，前2次开发过程根本都是follow Operator规范开发流程进行开发设计。遵循一个规范的、典型的Operator的设计过程，看上去一切都是这么的完满，然而每次设计都十分苦楚，践行Operator模式之后，最值得反思和借鉴的就是”有了锤子，看到的只有钉子“，简略总结一下就是4个所有：

所有设计皆yaml
所有皆合一
所有皆终态
所有交互皆cr
误区1 所有设计皆yaml
K8s的API是yaml格局，Operator设计流程也是让大家首先定义crd，所以团队开始设计时间接采纳了yaml格局。

案例

依据标准化流程，团队面向yaml设计流程大体如下：

先依据已知的数据初步整顿一个大而全的yaml，做一下初步的分类，例如利用大略蕴含根底信息，依赖服务，运维逻辑，监控采集等，每个分类做一个子局部
开会讨论具体的内容是否能满足要求，后果每次散会都难以造成共识
因为总是有新的需要满足不了，在探讨A时，就有人提到B、C、D，一直有新的需要
每个局部的属性十分难对立，因为不同的实现属性差别较大
了解不统一，雷同名字但应用时每个人的了解也不同
因为工期很紧，只能长期斗争，做一个两头态，前面再进一步优化
后续优化降级，雷同的流程再来一遍，还是很难造成共识
这是第2个版本的设计：

apiVersion: apps.mwops.alibaba-inc.com/v1alpha1
kind: AppDefinition
metadata:
labels:

app: "A"

name: A-1.0 //chart-name+chart-version
namespace: kubeone
spec:
appName: A //chart-name
version: 1.0 //chart-version
type: apps.mwops.alibaba-inc.com/v1alpha1.argo-helm
workloadSettings: //注 workloadSettings 标识type应该应用的属性

- name: "deployToK8SName"  value: ""- name: "deployToNamespace"  value: ${resources:namespace-resource.name}

parameterValues: //注 parameterValues标识业务属性

- name: "enableTenant"  value: "1"- name: "CPU"  value: "1"- name: "MEM"  value: "2Gi"- name: "jvm"  value: "flag;gc"- name: vip.fileserver-edas.ip  value: ${resources:fileserver_edas.ip}- name: DB_NAME  valueFromConfigMap:    name: ${resources:rds-resource.cm-name}    expr: ${database}- name: DB_PASSWORD  valueFromSecret:      name: ${instancename}-rds-secret      expr: ${password}- name: object-storage-endpoint  value: ${resources:object-storage.endpoint}- name: object-storage-username  valueFromSecret:      name: ${resources:object-storage.secret-name}      expr: ${username}- name: object-storage-password  valueFromSecret:      name: ${resources:object-storage.secret-name}      expr: ${password}- name: redis-endpoint  value: ${resources:redis.endpoint}- name: redis-password  value: ${resources:redis.password}

resources:

  - name: tolerations    type: apps.mwops.alibaba-inc.com/tolerations    parameterValues:       - name: key         value: "sigma.ali/is-ecs"       - name: key         value: "sigma.ali/resource-pool"  - name: namespace-resource    type: apps.mwops.alibaba-inc.com/v1alpha1.namespace    parameterValues:      - name: name        value: edas  - name: fileserver-edas    type: apps.mwops.alibaba-inc.com/v1alpha1.database.vip    parameterValues:      - name: port        value: 21,80,8080,5000      - name: src_port        value: 21,80,8080,5000      - name: type        value: ClusterIP      - name: check_type        value: ""      - name: uri        value: ""      - name: ip        value: ""  - name: test-db    type: apps.mwops.alibaba-inc.com/v1alpha1.database.mysqlha    parameterValues:      - name: name        value: test-db      - name: user        value: test-user      - name: password        value: test-passwd      - name: secret        value: test-db-mysqlha-secret  - name: service-slb    type: apps.mwops.alibaba-inc.com/v1alpha1.slb    mode: post-create    parameterValues:      - name: service        value: "serviceA"      - name: annotations        value: "app:a,version:1.0"      - name: external-ip        value:   - name: service-resource2    type: apps.mwops.alibaba-inc.com/v1alpha1.service    parameterValues:       - name: second-domain        value: edas.console      - name: ports        value: "80:80"      - name: selectors        value: "app:a,version:1.0"      - name: type        value: "loadbalance"  - name: service-dns    type: apps.mwops.alibaba-inc.com/v1alpha1.dns    parameterValues:      - name: domain        value: edas.server.${global:domain}      - name: vip        value: ${resources:service-resource2.EXTERNAL-IP}  - name: dns-resource    type: apps.mwops.alibaba-inc.com/v1alpha1.dns    parameterValues:      - name: domain        value: edas.console.${global:domain}      - name: vip        value: “127.0.0.1”  - name: cni-resource    type: apps.mwops.alibaba-inc.com/v1alpha1.cni    parameterValues:      - name: count        value: 4      - name: ip_list        value:   - name: object-storage    type: apps.mwops.alibaba-inc.com/v1alpha1.objectStorage.minio    parameterValues:      - name: namespace        value: test-ns      - name: username        value: test-user      - name: password        value: test-password      - name: storage-capacity        value: 20Gi      - name: secret-name        value: minio-my-store-access-keys      - name: endpoint        value: minio-instance-external-service  - name: redis    type: apps.mwops.alibaba-inc.com/v1alpha1.database.redis    parameterValues:      - name: cpu        value: 500m      - name: memory        value: 128Mi      - name: password        value: i_am_a_password      - name: storage-capacity        value: 20Gi      - name: endpoint        value: redis-redis-cluster   - name: accesskey    type: apps.mwops.alibaba-inc.com/v1alpha1.accesskey    parameterValues:      - name: name        value: default      - name: userName        value: ecs_test@aliyun.com

exposes:

- name: dns  value: ${resources:dns-resource.domain}- name: db-endpoint  valueFromConfigmap:    name: ${resources:rds-resource.cm-name}    expr: ${endpoint}:3306/${database}- name: ip_list  value: ${resources:cni-resource.ip_list}- name: object-storage-endpoint  value: ${resources:object-storage.endpoint}.${resource:namespace-resource.name}- name: object-storage-username  valueFromSecret:      name: ${resources:object-storage.secret-name}      expr: ${username}- name: object-storage-password  valueFromSecret:      name: ${resources:object-storage.secret-name}      expr: ${password}- name: redis-endpoint  value: ${resources:redis.endpoint}.${resource:namespace-resource.name}- name: redis-password  value: ${resources:redis.password}

反思

这样的苦楚难以用语言表达，感觉所有都脱离了掌控，没有对立的判断规范，设计标准，公说公有理婆说婆有理，内容始终加，字段始终改。事不过三，第三次设计时，咱们个体探讨反思为什么这么难造成共识？为什么每个人了解不同？为什么总是在改？

论断很统一，没有面向yaml的设计，只有面向对象的设计，设计语言也只有UML，只有这些历经考验、成熟的设计方法论，才是最简略也是最高效的。

从下面那个一个微小无比的yaml大家能够领会咱们设计的简单，然而这还是不是最苦楚的。最苦楚的是大家摈弃了原有的设计流程及设计语言，试图应用一个凋谢的Map来形容所有。当设计没有对象，也没有关系，只剩下Map里一个个属性，也就无所谓对错，也无所谓优劣。最初争来争去，最初不过是再加一个字段，争了一个寂寞。

适用范围

那Operator先设计CRD，再开发controller的形式不正确吗？

答案：局部正确

实用场景

与Java Class雷同，简略对象不须要通过简单的设计流程，间接设计yaml简略高效。

不实用场景

在设计一个简单的体系时，例如：利用治理，蕴含多个对象且对象之间有简单的关系，有简单的用户故事，UML和面向对象的设计就显得十分重要。

设计时只思考UML和畛域语言，设计实现后，CRD能够认为是java的Class，或者是数据库的表构造，只是最终要实现时的一种抉择。而且有很多对象不须要长久化，也不须要通过Operator机制触发对应的逻辑，就不须要设计CRD，而是间接实现一个controller即可。

yaml是接口或Class申明的一种格式化表白，惯例yaml要尽可能小，尽可能职责繁多，尽可能形象。简单的yaml是对简略CRD资源的一种编排后果，提供相似一站式资源配套方案。

在第3个版本及PaaS-Core设计时，咱们就采取了如下的流程：

UML 用例图
梳理用户故事
基于用户故事对齐Domain Object，确定要害的业务对象以及对象间关系
须要Operator化的对象，每个对象形容为一个CRD，当然CRD不足接口、继承等面向对象的能力，能够通过其余形式曲线表白
不须要Operator化的对象，间接编写Controller
误区2 所有皆合一
为了保障一个利用的终态，或者为了应用gitops治理一个利用，是否应该把利用相干的内容都放入一个CRD或一个IAC文件？依据gitops设计，每次变更时须要下发整个文件？

案例

案例1: 利用WordPress，须要依赖一个MySQL，终态如何定义?

apiVersion: apps.mwops.alibaba-inc.com/v1alpha1
kind: AppDefinition
metadata:
labels:

app: "WordPress"

name: WordPress-1.0 //chart-name+chart-version
namespace: kubeone
spec:
appName: WordPress //chart-name
version: 1.0 //chart-version
type: apps.mwops.alibaba-inc.com/v1alpha1.argo-helm
parameterValues: //注 parameterValues标识业务属性

- name: "enableTenant"  value: "1"- name: "CPU"  value: "1"- name: "MEM"  value: "2Gi"- name: "jvm"  value: "flag;gc"- name: replicas    value: 3- name: connectstring  valueFromConfigMap:    name: ${resources:test-db.exposes.connectstring}    expr: ${connectstring}- name: db_user_name  valueFromSecret:      ....

resources:

    - name: test-db //创立一个新的DB    type: apps.mwops.alibaba-inc.com/v1alpha1.database.mysqlha    parameterValues:      - name: cpu        value: 2      - name: memory        value: 4G      - name: storage        value: 20Gi       - name: username        value: myusername      - name: password        value: i_am_a_password        - name: dbname        value: wordPress     exposes:      - name: connectstring      - name: username      - name: password

exposes:

- name: dns  value: ...

上方的代码是wordPress利用的终态吗？这个文件蕴含了利用所须要的DB的定义和利用的定义，只有一次下发就能够先创立对应的数据库，再把利用拉起。

案例2：每次变更时，间接批改整个yaml的局部内容，批改后间接下发到K8s，引起不必要的变更。例如：要从3个节点扩容到5个节点，批改下面yaml文件的replicas之后，须要下发整个yaml。整个下发的yaml通过二次解析成底层的StatefulSet或Deployment，解析逻辑降级后，可能会产生不合乎预期的变动，导致所有pod重建。

反思

先答复第一个问题，上方yaml文件不是利用的终态，而是一个编排，此编排蕴含了DB的定义和利用的定义。利用的终态只应该蕴含本人必须的依赖援用，而不蕴含依赖是如何创立的。因为这个依赖援用能够是新创建的，也能够是一个已有的，也能够是手工填写的，依赖如何创立与利用终态无关。

apiVersion: apps.mwops.alibaba-inc.com/v1alpha1
kind: AppDefinition
metadata:
labels:

app: "WordPress"

name: WordPress-1.0 //chart-name+chart-version
namespace: kubeone
spec:
appName: WordPress //chart-name
version: 1.0 //chart-version
name: WordPress-test
type: apps.mwops.alibaba-inc.com/v1alpha1.argo-helm
parameterValues: //注 parameterValues标识业务属性

- ....

resources:

- name: test-db-secret    value: "wordPress1Secret" //援用已有的secret

exposes:

- name: dns  value: ...

创立一个利用，就不能先创立db，再创立利用吗？

能够的，多个对象之间依赖是通过编排实现的。编排有单个利用创立的编排，也有一个简单站点创立的编排。以Argo为例。

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: wordPress-
spec:
templates:

name: wordPress
steps:
# 创立db
- - name: wordpress-db
    template: wordpress-db
    arguments:
```
 parameters: [{name: wordpress-db1}]
```
创立利用
- - name:
    template: wordpress
    arguments:
    parameters: [{db-sercet: wordpress-db1}]

针对第2个案例，是否每次交互都须要下发全副残缺的yaml？

答案：

编排是一次性的配置，，编排文件下发一次之后，后续操作都是操作单个对象，例如：变更时，只会独自变更wordPress，或独自变更wordPressDB，而不会一次性同时变更2个对象。
独自变更利用时，是否须要下发整个终态yaml，这个要依据理论状况进行设计，值得大家思考。前面会提出针对整个利用生命周期状态机的设计，外面有具体的解释。
适用范围

实用场景

CRD或Iac定义时，单个对象的终态只应该蕴含本身及对依赖的援用。与面向对象的设计雷同，咱们不应该把所有类的定义都放到一个Class外面。

不实用场景

多个对象要一次性创立，并且须要依照程序创立，存在依赖关系，须要通过编排层实现。

误区3 所有皆终态
体验了K8s的终态化之后，大家在设计时言必称终态，好像不能用上终态设计，不下发一个yaml申明对象的终态就是掉队，就是上一代的设计。

案例

案例1：利用编排还是以WordPress为例，将WordPressDB和WordPress放在一起进行部署，先部署DB，再创立利用。示例yaml同上。

案例2：利用公布利用第一次部署及后续的降级间接下发一个残缺的利用yaml，零碎会主动帮你达到终态。但为了可能细粒度管制公布的流程，致力在Deployment或StatefulSet上下功夫，进行partition的管制，试图在终态里减少一点点的交互性。

反思

说到终态，必然要提到命令式、申明式编程，终态其实就是申明式最终的执行后果。咱们先回顾一下命令式、终态式编程。

命令式编程

命令式编程的次要思维是关注计算机执行的步骤，即一步一步通知计算机先做什么再做什么。

比方：如果你想在一个数字汇合 collection(变量名) 中筛选大于 5 的数字，你须要这样通知计算机：

第一步，创立一个存储后果的汇合变量 results；
第二步，遍历这个数字汇合 collection；
第三步：一个一个地判断每个数字是不是大于 5，如果是就将这个数字增加到后果汇合变量 results 中。

代码实现如下：

List results = new List();
foreach(var num in collection)
{
if (num > 5)
results.Add(num);
}
很显著，这个样子的代码是很常见的一种，不论你用的是 C, C++ 还是 C#, Java, Javascript, BASIC, Python, Ruby 等等，你都能够以这个形式写。

申明式编程

申明式编程是以数据结构的模式来表白程序执行的逻辑。它的次要思维是通知计算机应该做什么，但不指定具体要怎么做。

SQL 语句就是最显著的一种申明式编程的例子，例如：

SELECT * FROM collection WHERE num > 5
除了 SQL，网页编程中用到的 HTML 和 CSS 也都属于申明式编程。

通过观察申明式编程的代码咱们能够发现它有一个特点是它不须要创立变量用来存储数据。

另一个特点是它不蕴含循环管制的代码如 for， while。

换言之

• 命令式编程：命令“机器”如何去做事件(how)，这样不论你想要的是什么(what)，它都会依照你的命令实现。

• 申明式编程：通知“机器”你想要的是什么(what)，让机器想出如何去做(how)。

当接口越是在表白“要什么”，就是越申明式；越是在表白“要怎么”，就是越命令式。SQL就是在表白要什么（数据），而不是表白怎么弄出我要的数据，所以它就很“申明式”。

简略的说，接口的表述形式越靠近人类语言——词汇的串行连贯（一个词汇实际上是一个概念）——就越“申明式”；越靠近计算机语言——“程序+分支+循环”的操作流程——就越“命令式”。

越是申明式，意味着上层要做更多的货色，或者说能力越强，也意味着效率的损失。越是命令式，意味着下层对上层有更多的操作空间，能够依照本人特定的需要要求上层依照某种形式来解决。

简略的讲，Imperative Programming Language (命令式语言)个别都有control flow, 并且具备能够和其余设施进行交互的能力。而Declarative Programming language (申明式语言) 个别做不到这些。

基于以上的剖析，编排或工作流实质是一个流程性管制的过程，个别是一次性的过程，无需强行终态化，而且建站编排执行完结后，不能放弃终态，因为后续会依据单个利用进行公布和降级。案例1是一个典型的编排，只是一次性的创立了2个对象DB和利用的终态。

利用公布其实是通过一个公布单或工作流，管制2个不同版本的利用节点和流量的终态化的过程，不应该是利用终态的一部分，而是一个独立的管制流程。

适用范围

申明式或终态设计

实用场景

无过多交互，无需关注底层实现的场景，即把申明提供给零碎后，零碎会自动化达到申明所要求的状态，而不须要人为干涉。

不实用场景

一次性的流程编排，有频繁交互的管制流程

命令式和申明式本就是2种互补的编程模式，就像有了面向对象之后，有人就鄙视面向过程的编程，当初有了申明式，就开始鄙视命令式编程，那一屋！

误区4 所有交互皆cr
因为K8s的API交互只能通过yaml，导致大家的设计都以cr为核心，所有的交互都设计为下发一个cr，通过watch cr触发对应的逻辑。

案例

调用一个http接口或function，须要下发一个cr
利用crud都下发残缺cr
反思

案例1

是否所有的逻辑都须要下发一个cr？

下发cr其实做了比拟多的事件，流程很长，效率并不高，流程如下：

通过API传入cr，cr 保留到etcd
触发informer
controller接管到对应的事件，触发逻辑
更新cr状态
清理cr，否则会占用etcd存储

如果须要频繁的调用对应的接口，尽量通过sdk间接调用。

案例2

K8s 对yaml操作命令有 create、apply、patch、delete、get等，但一个利用的生命周期状态机不只是这几个命令能够涵盖，咱们比拟一下利用状态机（上）和yaml状态机（下）：

不同的有状态利用，在收到不同的指令，须要触发不同的逻辑，例如：MQ在收到stop指令时，须要先停写，检查数据是否生产实现。如果只是通过yaml状态机是无奈涵盖利用状态机相干的event，所以咱们必须突破下发cr的模式。对于利用来说，现实的交互方式是通过event driven 利用状态机的变动，状态产生变换时触发对应的逻辑。

适用范围

实用场景

须要长久化，放弃终态的数据

不实用场景

高频的服务调用，无需长久化的数据

简单状态机的驱动

总结
K8s给咱们关上了一扇门，带给了咱们很多优良的设计，优良的理念，然而这些设计和理念也是有本人的实用的场景，并不是放之四海而皆准。咱们不应该盲从，试图所有都要follow k8s的设计和规定，而摈弃之前的优良设计理念。

软件设计经验了10多年的倒退，造成了一套卓有成效的设计方法论，k8s也是在这些设计方法论的反对下设计进去的。取其精华去其糟粕，是咱们程序员应该做的事件。
原文链接
本文为阿里云原创内容，未经容许不得转载。