写点什么

当我们聊 Kubernetes Operator 时,我们在聊些什么

  • 2019-05-16
  • 本文字数:3243 字

    阅读完需:约 11 分钟

当我们聊 Kubernetes Operator 时,我们在聊些什么

不聊什么

在开始聊 Operator 前,先说说这篇文章里我们不聊什么。我们这里不聊 Operator 的具体实现,不聊 Operator 的由来历史,不聊 Operator 的 hello world。如果想了解这些,其实可以从别的很多文章中可以查找到。这里我们把一些常见的概念,如 Docker、Controller、Helm、编排等,与 Operator 进行一下对比,从这些概念的不同角度来聊聊 Operator,并聊聊在我眼中的 Operator 的核心价值。

Operator 与 Docker


我们先聊一聊 Docker。Docker 有非常多的优点,比如隔离、执行效率等等。但是在我看来,Docker 的核心价值,或者说颠覆性的成果就是设计了镜像流程,提供标准化的交付方式。就从单个的应用实例来讲,标准化、一致性的环境解决了应用的 runtime 的问题,将应用的部署、应用的依赖进行了统一的封装。将应用的部署方式从手工作坊的部署方式带入了标准化的工业时代。当然这也带来了一定的磁盘额外损耗。但是在硬件飞速发展的今天,这点磁盘损耗几乎不成问题。而且借助于联合文件系统和镜像优化,磁盘的损耗问题几乎不用考虑。


时至今日,越来越少的项目采用源码进行部署。以前一个开源项目往往配上一篇冗长的安装文档,教你如何安装、如何运行。现在,基本上活跃的开源项目都提供了基于容器的部署方式,你只需要拉下镜像 run 一下就可以使用。Docker 大大提升了交付的效率,降低了使用的门槛,有效避免了部署的故障。


Operator 跟 Docker 是相似的,而其主要的交付对象从单个的应用实例,扩展到了多实例、分布式的系统上。以往部署一个分布式系统需要启动多个容器,然后进行复杂的配置,而现在只要创建一个 CRD。Operator 将自动进行分布式系统中需要的各个资源的创建和部署。从这个角度上来说,Operator 的目标是实现分布式系统的标准化交付

Operator 与编排/Helm

现在我们一般意义上的编排,也就是 orchestration,还有另一种翻译就是编配。在维基百科的定义为描述复杂计算机系统、中间件(middleware)和业务的自动化的安排、协调和管理。根据我个人的经验,总结编排的典型特征主要包括服务的版本管理、服务的生命周期管理、多个资源多种资源的管理、参数化以及模板化。


最早接触编排概念,是通过 OpenStack 的 Heat 项目。Openstack 中从计算、存储到网络有很多的系统。而如果部署一个完整的应用虚拟机,需要多种资源的协同参与。Heat 项目就是为此目标而生。其通过模板和参数对多种资源进行编排,实现了对一个完整服务的创建、部署、修改、删除等生命周期管理。



在 Kubernetes 中,也有许多编排项目,目前比较热门的是包管理工具 Helm。如果说 Docker 是奠定的单实例的标准化交付,那么 Helm 则是集群化多实例、多资源的标准化交付。


Operator 的管理不仅限于容器(Pod),也可以是多个资源(比如 SVC 域名等等),从这个角度上来说,Operator 跟 Helm 一样,也是具有编排的能力的。从编排角度来看,在初学者看来,Helm 跟 Operator 有非常多的共性,很难对两者的作用进行区分。Helm 也可以完成分布式系统的部署。那么 Operator 跟 Helm 又有什么样的区别呢?Helm 的侧重点在于多种多个的资源管理,而对生命周期的管理主要包括创建更新和删除。Helm 通过命令驱动整个的生命周期。


而 Operator 对于资源的管理则不仅是创建和交付。由于其可以通过 watch 的方式获取相关资源的变化事件,因此可以实现高可用、可扩展、故障恢复等运维操作。因此 Operator 对于生命周期的管理不仅包括创建,故障恢复,高可用,升级,扩容缩容,异常处理,以及最终的清理等等。


那你说这些功能能不能用 Helm 来实现,其实我觉得有一部分功能应该也是可以的。但是这里面就涉及到一个问题,就是这些功能无法在编排中直接实现,就需要通过脚本或者程序的方式固化到镜像中。大量的运维代码被脚本化。会导致维护这些脚本的复杂度提高,可读性变差。除此之外,还有一个潜在的风险无法解决的就是,当这些容器实例全部挂掉的时候,则完全无法自动恢复了,即使有备份数据。这时候最终还会依赖于人工的介入,仍然无法达到自动化、智能化的目标。


Operator 则在实现自动化的同时实现了智能化。其主要的工作流程是根据当前的状态,进行智能分析判断,并最终进行创建、恢复、升级等操作。而位于容器中的脚本,因为缺乏很多全局的信息,仅靠自身是无法无法达实现这些全部的功能的。而处于第三方视角的 Operator,则可以解决这个问题。他可以通过侧面的观察,获取所有的资源的状态和信息,并且跟预想/声明的状态进行比较。通过预置的分析流程进行判断,从而进行相应的操作,并最终达到声明状态的一个目的。这样所有的运维逻辑就从镜像中抽取出来,集中到 Operator 里去。层次和逻辑也就更加清楚,容易维护,也更容易交付和传承。


如果把 Helm 比作 RPM,那么 Operator 就是 Systemd。RPM 负责应用的安装、删除,而 Systemd 则负责应用的启动、重启等等操作。当然二者并不是互斥的,目前 Operator 一种比较便捷的部署方式就是通过 Helm 进行部署。

Operator 与 Controller


Operator 可以说是另外一种 Controller。目前的 Controller Manager 集合的主要是基础的、通用的资源概念,比如 RS/Deployment,而对于特定的应用或者服务(如 etcdcluster,都可以认为是一种资源),则放权给了第三方,也就是 CRD。用户可以通过自定义的资源描述,以及自研的 Controller/Operator 进行接入。因此 Controller 和 Operator 的关系有点类似于标准库和第三方库的关系。


一般来说,对于不同的应用一般来说需要不同的 Operator 进行处理。这时我们再来想下,以 ReplicaSet Controller 为例。RS 的主要功能是保持副本数。当有 Pod 因某种原因挂掉/删除,对于无状态的应用来说,恢复的方式就是再增加对应的 Pod 数量。那么从这个角度来说,对于无状态的应用来说,RS Controller 其实就是无状态应用的 Operator。

Operator 的核心价值

我们原先常常讲 DevOps,就是运维和开发的结合,提升开发交付的效率和质量。这也带来了一个趋势,就是运维和开发一体化。比如原来开发应用的人,通过 docker 镜像的制作,将应用的部署启动等固化在了 dockerfile/镜像中,分担了运维的许多部署工作。但是实际上运维的工作内容和范围其实非常广,特别是现在的分布式的系统,包括集群化部署、高可用、故障恢复、系统升级等等工作。而这些是无法仅用 dockerfile/镜像进行固化的。


Operator 提供了一种可能,或者说是提供了一个很好的框架,就是把运维的经验沉淀为代码,实现运维的代码化、自动化、智能化。以往的高可用、扩展收缩,以及故障恢复等等运维操作,都通过 Operator 进行沉淀下来。从长期来看,将会推进 Dev、Ops、DevOps 的深度一体化。将运维经验、应用的各种方案和功能通过代码的方式进行固化和传承,减少人为故障的概率,提升整个运维的效率。


Operator 的许多理念并不是现在才有的。在 Yarn 中的 Application Manager,Mesos 中的 Framework,都可以寻找到 Operator 的一些蛛丝马迹。而之所以说 Operator 将可能成为 Docker 之后的又一项重大变革,其另外一个重要的因素就是 Operator 是站在 Kubernetes 的巨人肩膀上


Kubernetes 强化了基础资源的封装,并保持了灵活性和可定制性。Kubernetes 从传统的资源(CPU/MEM)的交付,转为了 Pod/SVC/PV/PVC 等资源的交付,扩展了资源的概念,将域名、负载均衡、存储等等必要或相关的概念也都进行了封装。而 Operator 这些公共的资源基础上,将应用集群也视为了一种资源,可以向用户提供。并且借助于 Kubernetes 已有的工作机制和框架,从而更为便捷灵活的实现。


Operator 的变革虽然重大,但是由于分布式应用主要限于工业生产领域,因此对一般的开发而言可能最终使用场景有限。因此我判断从全局看,Operator 的最终影响力有限,但在许多分布式应用的垂直领域,会产生巨大的影响。




作者简介


徐新坤,京东 JDOS 团队架构师。2013 年加入京东,2014 年开始从事容器化方面工作。目前主要从事 JDOS 2.0 及阿基米德调度平台的研发和架构,当前主要关注领域为大规模/超大规模的容器集群管理与调度。


2019-05-16 15:028441

评论 1 条评论

发布
用户头像
ok现在我们算一算要学的技术栈,docker,k8s,k8s opreator,istio,knative,天啊
2019-05-17 09:01
回复
没有更多了
发现更多内容

云图说丨初识数据工坊DWR

华为云开发者联盟

大数据 数据处理 算子 数据工坊 工作流编排

天翼云与龙芯完成产品兼容适配加速国产化云平台发展

天翼云开发者社区

经典的两阶段提交算法原理及缺陷

KunlunBase昆仑数据库

分布式数据库

穿透、击穿、雪崩…Redis这么多问题,如何解决?

华为云开发者联盟

redis 缓存 缓存穿透 缓存击穿 缓存雪崩

“养老”变“享老”,老龄人口高峰与养老产业爆发催生金融需求

易观分析

养老服务 养老金融

CRM系统改善业务的方法

低代码小观

CRM 客户关系管理 企业管理系统 CRM系统 企业管理工具

如何高效完成ECS多环境部署?

阿里云云效

阿里云 云原生 开发 部署与维护 ECS

史上最通俗,彻底搞懂字符乱码问题的本质

WorkPlus

昆仑分布式数据库架构介绍

KunlunBase昆仑数据库

数据库 分布式数据库

天翼云TeleDB数据库为实现自主可控全面亮剑

天翼云开发者社区

广电行业如何上云?来抄作业!

天翼云开发者社区

云管理平台有哪些?建议选择哪家?

行云管家

云计算 多云 云管理

Linux下C++后台服务器开发

Linux服务器开发

C/C++ 后端开发 Linux服务器开发 C++后台开发 Linux后台开发

JavaScript 基础(一):语法和程序结构

devpoint

JavaScript 函数 数据类型 3月月更

企业IM首选移动数字化平台WorkPlus

WorkPlus

C++ 内存管理中内存泄漏问题产生原因以及解决方法

Linux服务器开发

C/C++ 内存管理 内存泄漏 Linux服务器开发 Linux后台开发

昆仑分布式数据库技术特点

KunlunBase昆仑数据库

分布式数据库 国产数据库

10分钟快速玩转kunlun cluster

KunlunBase昆仑数据库

分布式数据库

无所不云,开启你的美好旅行新体验!

天翼云开发者社区

Linux之ss命令

入门小站

Linux

声网崩溃数据的自动化闭环处理

声网

自动化 测试 Dev for Dev

第九周作业

lv

海外主机是什么意思?与国内主机有什么区别?

行云管家

服务器 主机 服务器运维 海外 主机运维

应用环境能力 | 阿里巴巴DevOps实践指南

阿里云云效

阿里巴巴 阿里云 研发效能 开发

主流移动端账号登录方式的原理及设计思路

WorkPlus

为什么要选择昆仑分布式数据库?

KunlunBase昆仑数据库

国产数据库

昆仑分布式数据库技术优势

KunlunBase昆仑数据库

分布式数据库 国产数据库

恒源云(GpuShare)_加速pytorch训练的方法来喽~

恒源云

深度学习 PyTorch

墨天轮国产数据库沙龙 | 胡津铭:时序数据库DolphinDB,从量化金融到万物互联

墨天轮

数据库 时序数据库 DolphinDB 国产数据库

【51单片机】独立按键控制LED灯(四种形式)

謓泽

3月月更

Promise静态四兄弟,你学会了吗?

战场小包

JavaScript 前端 Promise 3月月更

  • 扫码添加小助手
    领取最新资料包
当我们聊 Kubernetes Operator 时,我们在聊些什么_云原生_徐新坤_InfoQ精选文章