容器化治理演进

演进过程

swarm

单集群，共享宿主机端口，服务发版有肯定工夫服务不可用。

k8s 原生控制器

多集群反对，反对简略的公布策略

次要为黑盒操作，即以批改 k8s 原生资源配置为主，无奈实现灰度公布，蓝绿公布等高级性能。

随着容器化的继续进行，越来越多的业务跑到 k8s 集群上，目前已有 6 个不同集群对外提供服务。

目前 k8s 社区非常沉闷，为了稳定性和安全性，版本升级较频繁，目前由 1.10,1.14,1.15,1.16 多个版本的集群并存。
此外，阿里云、公有云并行存在，基础设施不同。
多集群，私有云、多版本，集群差别较大，对立治理逻辑简单，保护艰难。

服务状态次要靠同步查问，难以渐进式管制公布过程。用户体验不够敌对，查看状态须要手动刷新。

边界不清晰，管理系统 (chons) 关注点太多，越来越简单，不好保护。

封装不够欠缺，裸露了较多 k8s 外部细节给前端、以及用户，减少其认知老本。

扩大不不便，每裸露一个配置项，都须要新加接口，老本高。

组件控制器

k8s 是一个平凡的我的项目，为很多服务治理过程中罕用的资源做了高度形象，并且 k8s 零碎高度通用、高度灵便，可能实现服务治理和保护的多种多样的需要。
因而同时 k8s 零碎也是一个较简单的零碎。除了 k8s 专家，不论是开发和运维同学，拿到 k8s 的资源配置文件都显得过于简单，搞得人一头雾水。

解决简单计算机系统的问题的一个通用的办法就是利用分层的思维，在简单零碎之上再形象出一层，分层治理：

• 高级编程语言在汇编语言之上
• 操作系统在驱动之上
• 网络七层模型层层形象

依照这个思路，为了依靠 k8s 生态为公司服务治理平台继续赋能，以及更好地解决多集群精细化治理的问题，咱们在 k8s 原生资源之上形象出组件层，并采纳 k8s CRD operator 的模式开发了组件控制器，每个控制器独立治理每个集群的服务：

• 屏蔽 Deployment, StatefulSet, Service, Ingress 等外部实现细节，升高研发人员心智累赘
• 集群治理与下层业务调度解耦
• 靠近 k8s 原生资源的保障
• 集群生命周期治理
• 靠近 k8s 原生资源的体验

设计思路

组件是一等公民

deployment 由 deployment controller 管制；
service 由 service controller 管制；
组件(component) 由 component controller 管制。

自定义 spec 以简洁的形式反对公司业务类型

采纳 Config As A Service 反对灵便扩大，缩小接口，缩小开发成本。

例如最简略的服务定义可能包含: 开发语言，服务类型，端口和镜像即可，如下 spec 局部所示。

apiVersion: component.luojilab.com/v1alpha1
kind: Component
metadata:
  name: nginx
spec:
  workloadType: Deployment
  developLanguage: python
  runType: server
  image: python-demo:latest
  port: 8080

在尽可能放弃简洁的根底上，如果用户有非凡需要，必须也能反对。

向下兼容

反对老服务无感降级

不便降级

须要可能不便的进行集群级别的批量调整，比方配置调整，性能优化等。

灵便扩容

性能有余时，需反对灵便扩容

资源定义

type(GVK):

• group(luojilab.com)
• version(v1alpha1)
• kind(Component)

meta:

• label
• annotation
• create_datetime
• update_datetime
• delete_datetime

spec:

控制器的根本本原理

reconcile

所有接口幂等性

触发机制

level based trigger

edge based trigger

level + edge based trigger

模板化治理

集群差别治理

负载类型模板

开发语言模板

部署发版流程

滚动公布

灰度公布

状态变更感知

status 变更
event 事件推送

controller 降级 / 灰度

annotation:
“component.luojilab.com/unmanaged”: true 则不会触发控制器，可用于抉择组件是否承受控制器治理

资源定义降级

每个资源定义都有一个 GVK，group version kind
通过通用的 hub 可实现版本主动转换

比方 component v1alpha 时咱们应用阿里云 slb 做负载平衡，在 v1beta 中咱们改为采纳自建 lb，可简略的通过定义一个转换器来实现。

component v1alpha
spec.svc.type = ‘aliyun-slb’

component v1beta
spec.svc.type = ‘luoji-slb’
并调用自建 lb 服务的接口创立并绑定新的 lb。

变更将在任何一次对资源的变更后主动触发，实现 spec 降级，同时切换至新的 lb，业务方无感知。

分布式 – 高可用

多备单活，抢占锁

主备每个服务保护一个 workqueue 队列，每次更新申请和状态变更同时向主备的队列中公布，而后拿到抢占锁的队列执行操作。

分布式 – 程度扩大

k8s 默认监听机制下，资源控制器会监听全副资源。
如果遇到性能瓶颈，能够增加 controller id 索引，不同资源应用不同的控制器。

监控

metrics

参考

OAM

将来瞻望

1 serverless

2 弹性伸缩

3 服务亲和力感知

4 容器主动创立 –> 主动增加 worker 节点 –> 集群主动搭建