服务治理 之 平台与应用服务解耦

服务治理之 平台与应用服务解耦

原则

业务完成微服务改造（计算存储分离、控制数据分离），以Kubernetes做运行时生命周期管理， 并可以在水平扩缩容、驱逐操作对业务无损的云原生化

1 首要原则：遏制应用无止境的使用operator来控制应用

遏制应用无止境的使用operator来控制应用，
建议使用hpa、vpa 和 自带ingress-controller crds来控制 南北、东西 流量变化或者依赖服务可用性做调整

2 平台资源调用

2.1 禁止将 configmap 当 metaserver 服务使用

configmap只作为静态数据使用，不作为源数据服务使用。
举个例子：

• configmap中配置服务其中基础配置: 日志等级、启动模式、功能开关等；
• 不能将服务直接的 分布式锁、Pod实例之间业务数据同步使用

2.2 禁止将 configmap 当 配置中心 使用

configmap只作为静态数据使用，不作为config center使用。

举个例子：

• configmap中只配置需要访问远程配置中心：URL地址、认证方式、请求策略等；
• 不能直接用作pod的flag 配置开关；

2.3 禁止将 secret 当 证书中心 使用

secret只作为静态的少量敏感信息例如密码、令牌或密钥的对象，不作为证书中心使用。

举个例子：

• secret中配置 TLS 证书
• 不能将secret作为证书ca 管理中心，频繁变更和下发证书；

2.4 禁止将 etcd服务 直接当 服务注册中心 使用

K8s 源数据etcd服务只作为Kubernetes底层数据使用，不能直接自定义CRD、自定义的configmap和secret来做服务注册发现

可以使用方式：通过KubeDNS+Kubernetes Service做服务发现；

2.5 禁止将 对象的label 当做容器运行时的metaserver使用

Label 只能做 key-value tag标签使用. 不能在pod 容器运行时，动态管理业务自用数据；

Label 的变更，只能是运维态做变更

2.6 禁止将 对象的annotation 当做容器运行时的metaserver使用

2.7 遏制将 对象的annotation 当做容器运行时的metaserver使用

annotation 只能做 key-value tag标签使用. 遏制在 pod 容器运行时，动态管理业务自用数据；
annotation 的变更，只能是运维态做变更 和 控制面组件 patch 使用；

3 安全性

3.1 遏制申请 特权容器

遏制 特权容器 申请； 引伸 业务服务化，减少 os 工具封装到Container中执行；

3.2 遏制避免挂在 host os 配置，在Pod中进行更改

遏制 host OS资源 挂载到Pod，扩大异常影响半径；
举例：
case：将iptable-storge相关资源挂载pod中，做xtable锁操作；

3.3 遏制rabc最小授权原则，遏制 全局/资源全部类型申请

1. 减少ClusterRole和ClusterRoleBinding全局资源类型申请；
2. 禁止资源权限全局申请

  rules:
  - apiGroups:
    - '*'
    resources:
    - '*'
    verbs:
    - '*'

4 业务依赖client-go应用

纯微服务、纯业务应用不应该会用到 client-go/java SDK

4.1 要求业务依赖client-go应用版本不小于 Kubernetes apiserver version 2个大版本

版本问题：

• 如果apiserver版本为v1.18.x, 那么依赖的client-go版本不能小于v0.16.x版本.
• 如果apiserver版本为v1.18.x, client-go 使用版本大于v0.18.x原则上是可以的（需要测试验证功能）

4.2 要求对于依赖client-go应用，部署态显示配置QPS和Burst等

4.3 限制轮训 list all pod/node/configmap/secret等

限制全局轮训list all接口。 可以跟换为以下两种方式：

1. 通过watch 方式添加add、delete、update 3这种event回调；
2. 其中中添加opt.metav1(xxx) 设置条件：比如namespace选择、单次请求大小（500个）、filter tag不符合规范的object等

4.4 限制direct etcd请求，通过apiserver cache informer方式请求

4.5 要求对于watch资源，通过InformerFactory方式watch

4.6 遏制对apiserver 聚合aggregation api调用

5. 高可用

5.1 要求服务驱逐时，长/短链接、流量（东西、南北）无损

长/短链接:

• 长链接：长链接主动connect close. 通过client 链接重新选实例建立，将链接全部驱逐掉；
• 短链接：确保本次处理结束。优雅关闭链接；

流量:
通过设置 perStop + 实例分Step变更，实现流量无损；

5.2 建议无状态多实例部署；有状态实例支持sharding；

• 有状态实例实例sharding比较考验业务架构，可选择"多活+数据同步"

6. 健康检查

6.1 健康检查中，首选 HTTP 探测，备选脚本探测，尽量避免 TCP 探测

6.2 要求所有容器 ReadinessProbe，谨慎使用 LivenessProbe

如果业务应用实例重启、驱逐敏感， 谨用 LivenessProbe

6.3 要求对于服务支持优雅重启，避免异常导致僵尸进程

支持容器信号量处理。

7. 其他

7.1 建议部署态，亲和/反亲和设置

7.2 建议通过service、内部DNS 或 南北项LB方式服务直接调用