feat: cicd - k8s

kubernetes/continous-delivery/README.md

@@ -2,8 +2,24 @@
 
 在这个领域，目前社区主要就是 flagger 跟 argo-rollouts 两个工具。
 
-但是这两个工具对 CD 的支持，感觉都还比较初级，实际应用上，可能仅适合初创公司。对于复杂场景的支持是不够的。
+## 我目前的使用体验
+
+我大概的使用体验是，flagger 的发布流程太过自动化了，通过 prometheus 等自动化检测能发现的问题有限。
+
+当然这不是说它不好，而是说它实际要求服务在发布之前就已经基本能保证质量，
+也就是说服务在发布之前，就必须已经经过了一系列完善的测试，包括单元测试、集成测试、压力测试等。
+
+这对大厂来说可能没什么问题，组织架构与发布流程完善，也有足够的人力财力去完善测试流程。
+但对小厂而言，更可能使用短平快的发布流程，在做完最基础的单元测试跟集成测试后，就直接发布了。
+但是会先切小部分流量到新版本，然后再观察一段时间，确认各种指标都正常后，再逐渐切更多流量到新版本，直到最终发布完成。
+
+flagger 太过自动化，对于这种发布流程，就显得不太适合。
+
+云原生社区足够庞大，有很多同类的同居，但它们的定位不同，适合的场景也不同。
+
+目前我感觉 fluxcd 的这一套 gitops 工具（flagger/flux2），追求的是完全自动化的发布流程，以及 Git 仓库与集群状态的绝对一致性，**适合专业且流程规范的团队，对其用户有比较高的要求**。
+
+而 ArgoCD/ArgoRollouts 则更适合追求灵活性的团队，它对半自动化的发布流程提供了很好的支持，另外可视化的界面也更加友好，适合希望发布流程更可控、更灵活的团队，比如说流程中还存在比较多手工操作的团队。
 
-比如说支持多版本共存、金丝雀发布的暂停/继续/取消逻辑、自定义 Istio 的 VirtualService/DestinationRule 配置、自定义 Deployment 配置等等。