历经公司内部近两年的实践和优化，今天终于把自研的云原生CD工具开源了~开心~
背景
大概从2022年下半年起，为了满足公司容器化部署应用的持续交付需求，我就开始在市面上寻找相应的项目和工具。做云原生部署，当然首选CNCF的项目。
ArgoCD
从CNCF的毕业项目开始，我第一个找的就是ArgoCD。背靠Argo这个大项目，ArgoCD确实是一个功能无比强大的CD平台，以GitOps为核心，将用户期望的工作负载状态以声明式yaml存放于Gitlab，通过Operator控制器实现应用实际状态和用户声明的状态保持一致。确实是经典的玩法，但这个玩法在我所在的部门却并不适用，原因主要是两点：
- 我所在的业务部门并不是K8S平台的管理和运营方，我们作为使用方，只有namespace级别的权限。而且公司内部使用的是青云的KubeSphere，KubeSphere的多租户做的非常好。对于普通用户，我们只能通过KS界面访问到有权限的企业空间和namespace（KS里叫项目空间），无法拿到kubeconfig，没有clusterrole，也不知道apiserver地址。CNCF里类似ArgoCD这样的项目，打底都需要部署CRD+Operator，没有集群权限根本无法玩儿。
- GitOps在我司实际使用中会有各种各样的问题。我承认将应用的manifests维护在Gitlab是比较好的一个方法，作为应用资源的一部分可以被版本管理和回退，但我们一个项目每天可能会部署好几十次，每次发布应用都必须提交Gitlab有点没必要，大多数情况下就是更新一个image，image本身有镜像仓库管理，并不需要版本管理，也不会从Gitlab做回退。一般CI流水线之后接部署只需要做一个
set image的动作。
KubeVela
Pass掉ArgoCD以后，我又找到了KubeVela，这是一个CNCF的孵化项目，他提出了一个很新颖的概念——OAM(Open Application Model)，它将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”。这玩意听起来逼格很高啊，但闭着眼睛想都知道，为了实现它的OAM，必然需要CRD，仔细研读它的官网，不出所料，各种控制器直接就把我劝退了。
和ArgoCD一样，对于对接多集群，KubeVela使用的也是kubeconfig（参见多集群应用交付)，难道没有kubeconfig，作为一个普通用户就没有资格做CD了吗？我只是需要一个小小的CD，用不上这么多高大上的功能啊。
公司内部平台
将视线转移到公司内部提供的部署平台，公司当然不能让业务部门的应用无法在容器部署，IT部门不就是为了业务部门服务嘛。但，公司的部署平台在性能、可扩展性、定制化程度各方面还是不能满足我的需求。
自己搞
以上的各种问题促使我必须要自己开发一个CD功能，解决的痛点直接瞄准我所在部门的切实需求。
经过两周开发，我基于client-go封装的K8S接口上线了，通过K8S的更新策略StrategicMergePatchType可以实现对工作负载yaml字段的局部更新，以实现set image。后来我又陆陆续续加入了重启（rollout restart）、scale（通过set replicas）、获取资源定义yaml、通过yaml更新资源等一系列功能，而这，就是LizardCD的前身。
稳定使用了一年半时间，日均部署400余次，前前后后修了不少bug，终于我觉得时机成熟，本着开源奉献的精神，不如将此项目丰富一下共功能后开源，梦想一下借助广大开发者共同帮助这个项目进步和发展。
LizardCD
LizardCD是一个轻量级的云原生持续交付项目，基于server-agent模式运行，支持多集群环境应用交付。
名称由来
仿照各类CNCF项目的logo都是一个小动物（比如go是一个小鼹鼠），我也从各种动物里面找，觉得蜥蜴这个动物比较贴近我的想法，lizardcd-agent像一个蜥蜴一样吸附于K8S集群中，完成各种资源操作任务。
解决痛点
- 不同于ArgoCD之类的项目，LizardCD没有使用CRD，也没有Operator，因此部署的时候不需要clusterrole
- agent可以以
In-Cluster模式，作为deployment部署于集群中，通过serviceaccount使用少量的rbac权限（一个namespace级别，仅需create/patch/list deployments/statefulsets等role即可）。因此无需kubeconfig、无需clusterrole、无需apiserver地址，特别适用于只能通过dashboard访问某些namespace的用户场景 - 对接多集群也不需要kubeconfig，在要接入集群的namespace中部署一个或多个agent即可
特性
- 云原生应用部署，同时支持实体机以及通过HTTP接口对接第三方部署/自动化平台，理论上可支持任意提供HTTP接口的平台/系统，如 ArgoCD、Ansible/AWX
- 无需
kubeconfig、ClusterRole，也无需知道 APIServer 地址、证书，agent 支持InCluster模式部署，特别适合于非容器集群管理员的普通用户进行应用部署 - 支持多集群管理，通过统一的
ui和cli集中查看、管理、操作多个集群的工作负载，并进行应用部署 - agent 可以在启动时自动地注册到服务注册中心，只要网络端口可达。之后 server 会自动发现已注册并且网络端口可达的 agent，就此完成纳管过程
- 以应用为中心，提供完善的应用管理。无论应用部署于容器或是实体机，或是在第三方平台创建的一个部署对象，lizardcd 均支持对其进行持续交付
- 对于部署了服务网格（如
Istio）的集群，Lizardcd 支持将其接入，并结合应用管理实现灰度发布、流量控制等操作（例如基于 header 或权重） - 支持完整的
Helm Cli功能，包括 Repo 添加、删除，Release 安装、卸载、更新、历史记录，README 和 values 文件查看、编辑等 - 内置
Prometheus Metrics指标监控，以及基于Opentelemetry和Jaeger的链路跟踪功能
架构
使用方法
项目地址：https://github.com/hongyuxuan/lizardcd
项目提供二进制文件和Helm Charts两种部署方式。使用二进制文件部署时必须提前准备好注册中心，支持etcd、nacos、consul，默认使用etcd。需要注册中心和agent、server网络端口可达。使用Helm Charts时可勾选是否同时安装注册中心。具体用法详见 lizardcd官方文档
欢迎各路云原生大神指正，并提出你们新的需求~
