K8s中Operator的运行时是什么？Operator是Docker进程吗？

对应提问 #

原始英文问题：

What is runtime of operator in k8s? The operator in k8s is a docker process ?
What is runtime of operator in k8s? The operator in k8s is a docker process ?

中文翻译：

K8s环境中Operator的运行时具体是什么？K8s里的Operator是否属于Docker进程？

问题答复 #

1. Operator的运行时说明 #

Operator本质是**封装了特定领域运维逻辑的自定义Kubernetes控制器+配套自定义资源定义（CRD）**的组合，不存在专属的特殊运行时，运行逻辑和集群内其他普通业务工作负载完全一致：

• 从应用程序层面：Operator就是普通的用户态应用，目前主流实现是Go语言编写的静态编译二进制文件，不需要额外依赖语言级运行时；如果是Java、Python等其他语言开发的Operator，则对应依赖JVM、CPython等对应语言的标准运行环境。
• 从集群运行层面：Operator会被打包为标准OCI格式容器镜像，以Pod为单位被K8s调度到集群节点上运行，Pod的生命周期由集群配置的符合CRI（容器运行时接口）标准的容器运行时负责管理，当前主流默认容器运行时为containerd，也有部分集群使用CRI-O，早期K8s版本默认使用Docker作为容器运行时。

2. Operator不属于Docker进程 #

答案是否定的，核心原因如下：

• Docker只是容器运行时的其中一种可选实现，K8s从1.24版本开始正式移除了内置的dockershim适配组件，当前大量生产环境集群根本没有部署Docker组件，这类环境下Operator和Docker没有任何关联。
• 即使集群使用Docker作为容器运行时，Operator进程也是运行在Docker创建的隔离容器命名空间内的业务进程，和宿主机上运行的Docker守护进程dockerd是完全隔离、相互独立的两个实体，二者不能划等号。
• Operator的核心工作逻辑是通过和K8s API Server交互，监听资源变化、执行预设的运维动作，全程不需要依赖Docker进程参与业务逻辑处理。

内容的提问来源于stack exchange，提问作者Winsom