2024 年过得很快，时间就像倾盆大雨时的雨滴，挡不住地从空中落在地上，然后消失在草地或者泥土里。这一年我经历了很多事情，也学到了很多事情，希望可以用这篇博客来总结和梳理一下自己的想法。主要还是围绕着与自己工作和兴趣相关的云原生、RAG 和 AI 三个方面展开。

背景

在近期的工作当中我大量接触 Kubernetes 集群以及容器化应用，在完成 Operator 拓展的开发和发布后，有海外用户反映在 OpenShift 平台上运行我们的容器化应用会遇到安全性问题，具体而言是我们的容器化应用默认需要 root 用户运行，而 OpenShift 平台如果不进行专门的设置是不允许容器使用 root 用户的。为了解决该用户的问题我们花费了一些功夫，正好我也想以此为契机进一步了解如何在 Kubernetes 中安全地运行应用。本文将记录我在调研和学习过程中的一些心得体会。

容器安全

Docker Init CLI

Docker Init 命令是用来创建遵循最佳实践的 Docker 配置文件的命令行工具。在使用时通过选择需要运行的应用类型（例如 Go、Python、Node、Rust 等），Docker 会自动帮助用户创建出符合最佳实践的 Dockerfile 和 compose.yaml 文件。

Operator 是 Kubernetes 用来拓展其 API 的一种开发范式（Pattern），其核心是定义若干的自定义资源及其对应的资源控制器，当这些资源发生变化时其对应的控制器对变化进行调解（Reconcile），最终使得实际状态与预期状态达成一致。K8s-sigs 推出的 kubebuilder 是一个用于构建 Operator 应用的框架，和 Operator-SDK 一样都依赖了 controller-runtime，提供了高级 API 和抽象，让开发者更直观地编写操作逻辑，并提供用于快速启动新项目的脚手架和代码生成工具。

截至目前我已经参与了两个 Operator 项目的搭建和维护，均采用了 kubebuilder 做基础脚手架。我目前对 CRD 的设计生成、Webhook 的校验机制和、Controller 的控制循环机制有了一定认识，接触时间稍长后在日常开发 Operator 项目时难免出现缺乏新意的情况，Operator 模式看久了和 CURD 之于后端有些许相似。但我乐观地估计通过观察下层实现可以收获一些启发。既然 kubebuilder 和 Operator-SDK 都依赖了 controller-runtime，那么就先从它出发吧。

翻译自 What happens when … Kubernetes edition!。我认为这篇文章写得生动有趣，且在关键位置都给出了有价值的链接，引导进一步的阅读学习，让我有了重读并翻译的冲动。

如果我希望往 Kubernetes 集群当中部署 nginx，我大概率会在命令行输入下面这样的命令并敲下回车键：

1

kubectl create deployment nginx --image=nginx --replicas=3

几秒之后，我应该能看到三个 nginx 的 pod 散布在集群的工作节点上。这很神奇！但这个过程背后究竟发生了什么？

关于 Kubernetes 的惊人的特点是，它通过用户友好的 API 处理工作负载的部署。其中的复杂性被简单的抽象隐藏起来。但为了充分理解它所提供的价值，了解其内部工作原理也是很有用的。本指南将引导您了解从客户端 kubectl 到 kubelet 的请求的完整生命周期，并在必要时链接到源代码（或者相关文档和博客）来进一步说明正在发生的事情。

这是一份不断修订的文档。如果您发现可以改进或重写的地方，欢迎贡献！