Day 29 - Summary

本文将於赛後同步刊登於笔者部落格
有兴趣学习更多 Kubernetes/DevOps/Linux 相关的资源的读者，欢迎前往阅读
更多相关科技的技术分享，欢迎追踪 矽谷牛的耕田笔记

过去的 28 篇文章我们从头到尾探讨了以下这张图片的种种议题，包含了

1. 如何管理 Kubernetes 应用程序，Helm/Kustomize/原生 Yaml

2. 本地开发者如果有 Kubernetes 使用的需求，那可以怎麽做

3. Pipeline 该怎麽选择， SaaS 与自架各自的优劣

4. CI Pipeline 可以怎麽做，如果有 Kubernetes 的需求，那可以怎麽设计

5. CI pipeline 要如何对 Kubenretes 应用程序进行测试， Yaml 可以测试针对语法，语意等进行测试

6. CD pipeline 有哪一些做法，配上 Kubernetes 之後有哪些参考作法

7. GitOps 是什麽，相对於过往的部署方式，有什麽优劣

8. GitOps 与 Kubernetes 的整合，有哪些解决方案可以使用

9. Container Registry 的选择，SaaS 与自架各自的优劣

10. 自架的 Container Registry 要怎麽与 Kubernetes 整合，有哪些点要注意

11. Secret 机密资讯於自动部署上要怎处理

12. Secret 机密部署与 Kubernetes 要如何处理

事实上，上面每个议题都有跳不完的坑，每个议题都有好多的解决方案，不论是开源解决方案，或是商业付费方案，每个都有不同的场景，以及不同的时机去使用。

踏入一个新技术想要尝试导入时，往往最困难的就是要如何在包山包海的选择中，挑出一个最後的答案。

这部分吃的除了是技术的洞察力，透过观察不同软件的架构来判断问题外，还有对於自己团队工作流程的掌握力，一时之间选不出来的时

候，可能还需要针对不同专案进行尝试，透过实际操作去观察实际运用的情况，再加以辅佐来进行判断。

就如同 CNCF End User Technology Radar 关於 Continuouse Delivery 调查报告中所说，很多人使用 Jenkins 是因为旧系统已经正在使用，实在是没有什麽理由硬要把它拔掉，优劣权衡之後就决定旧系统继续使用 Jenkins，但是对於很多全新的专案，因为是全新的环境，

就可以开始尝试不同的解决方法。

该文章也提到，很多公司都尝试过至少10个以上的解决方案在评估，最後就收敛到 3-4 个继续稳定使用的专案，几乎没有公司是一个专案打天下，甚至很多大公司发现解决方案解决不了问题的时候，就会自己动手实作符合自己工作情境的软件，甚至将其开源贡献。