Q & A | 袁琳峰：使用 Operator 来扩展 Kubernetes

 | 为  |  容  |  器  |  技  |  术  |  而  |  生  |

袁琳峰 /沃趣科技产品研发部原型部门技术专家

背景回顾：11 月 15 日 20:00，K8sMeetup 中国社区线上课堂，邀请袁琳峰老师以直播的方式进行了一场以《使用 Operator 来扩展 Kubernetes》为题的线上讲解，反响热烈。

为更好地为学员整合问答，「K8sMeetup 中国社区」特别精选了网友提问，感谢袁琳峰老师百忙之中进行校对。

关注本公众号，回复：袁琳峰，获取 PPT 下载

戳“阅读原文”，看直播回放

Q  - 把操作细节实现到各种 Operator 里面，是不是和 Ansible 有点像？

A  - 前半句不对，后半需要更正一下，不是把操作的细节放在各种 Operator 里，是把各种操作细节放在一个 Operator 里，Operator 会根据资源的状态来执行相应应的“操作细节”。

Operator 和 Ansible 最大的区别是: Operator 是活的，它能够感知资源的状态并“努力”将有问题的资源的恢复，就像一个 24 小时值班的运维人员一样，你就是 Boss，只需要告诉它什么资源要保持状态就行了，怎么去创建运维，你不必关心。

而 Ansible 是死的，做的是一锤子的买卖，执行一次就退出了。它仅仅是按照要求把整个流程走一遍，设置主机 IP，配置密码等工作，你一样也少不了。它只是减少运维人员打命令做配置等工作，而中间某个步骤一旦出错，必须人为介入，你需要关心里面的实现细节，而且也不具备自愈等功能。

Ansible 是 Bare metal 时代的产物，而 Operator 是为 Cloud Native 时代的产物，两者不是同一个层次的东西。

Q  - 请有状态服务的话，跟 Service 的 Session Affinity 有什么区别？

A  - 我猜你说的应该是 Endless Service 吧？Endless Service 其实后端映射的不再是 Pod，而是一个Endpoint，这个 Endpoint 连接的是外部的有状态的服务，比如公有云 RDS 等，相当于给你搭了一座桥，让你使用 Kubernetes 外部的这些有状态的服务。而使用 Operator 是将有状态应用放在 Pod 中，Kubernetes 自己管理实现高可用的。

Q  - 采用 Yaml 编写，用 Operator 调用在 Kubernetes 里执行，是这么理解吗？

A  - 可以这么理解，编写配置文件只是通知 Kubernetes 的一种方式，你还可以使用 Restful Api 或者命令行的方式去设置，就跟使用 Kubernetes 原生的资源一样，采用 Yaml 文件只是为了方便管理和配置而已。

Q  - 应用的安全怎么做？

A  - 如果这里的应用是指应用的访问权限等，是应用自己去管理权限认证的，这跟你把应用部署在物理机上没有差别。同时 Kubernetes 里提供了 Secret 组件来集中管理密钥，非常的人性化，只要你的物理机不被攻破，你的应用就是安全的。同时 Kubernetes 在管理资源时还有组的概念，可以借此来实现不同用户资源的隔离。如果安全是指高可用，这一点你可以放心地交给 Operator。

Q  - 现在做 Kubernetes 的二次开发，使用的是 client-go 多还是 Restful Api 多？对于使用选型有哪些建议？

A  - 个人建议使用 client-go。

• 第一, client-go 和 Kubernetes 都是使用 Go 语言实现的，天生就能和 Kubernetes 无缝对接, 代码清晰语义明确，使用 Restful Api 会增加许多额外的工作；

• 第二, client-go 是 Kubernetes 官方提供的, 代码质量有保障；

• 第三, client-go 紧着 Kubernetes 的版本升级,可以很方便地使用 Kubernetes 的最新功能；

• 第四，最重要，Kubernetes 官方提供了周边工具能帮你自动生成 Kubernetes 那套陈述式的框架，你只需要关系自己的业务逻辑就好了，如果采用 Restful Api 用其他语言去实现的话，代码质量就不好说了。

在社区里面实现的开源的 Operator，基本上都是使用 client-go 来去做的，这也给我们写自己的 Operator 带来了很多参考。也有一些是使用 Python 去做的，你可以根据团队的技术栈做出合理的选择。

Q  - Openstack 有用到 Operator 么？比如安装。

A  - Operator 可以看成是一个类似 Tornado Web 框架一样的服务程序，它运行的时候会连接 Kubernetes，并且是一直运行的，它运行在什么地方其实都无所谓，只要它能够连接到 Kubernetes 上。因此，你需要的因此你需要在 Openstack 上先部署一套 Kubernetes，然后运行 Operator。

通常的做法是：将 Operator 当成一个普通的应用运行在 Kubernetes Pod 中，Pod 可以通过 Deployment 来管理，也可以将 Pod 的 Yaml 配置文件放在 Kubernetes 的 Master Node 上的 /etc/kubernetes/manifests 目录中，Operator Pod 就会自动在 Master Node 上创建。

Q  - Operator 不是 CoreOs 的一个框架吗？刚刚老师讲的这个不是 Kubernetes 自定义资源管理的方式吗？这两个是什么关系啊？

A  - Operator 其实是 CoreOs 在布道，本身不是一个创新出来的东西，是定义自己的资源，并将 Kubernetes 管理资源的那套方式一模一样地剥离出来用在我们自己定义的资源上，使之能够达到 Kubernetes 原生资源一样的使用体验。

推荐阅读：

END