Kubernetes Operator 技术下沉,体验上浮

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 本文以个人观点的维度讲解了Kubernetes Operator概念应用的设计模式和实现思考。同时也提出了Operator在目前逐步大量应用过程中的问题和难点,提出了Operator标准化、规范化的一些想法。并描绘了对Kubernetes Operator 技术下沉,体验上浮的寄望。

讲在前面

今天谈谈Kubernetes生态中目前非常活跃的一个概念“Operator”。是的,我认为它是一个概念,一个设计模式。它并不是一个开发框架,一种资源或者说一个项目,这个概念由CoreOS提出。Operator的概念是从Kubernetes的CRD(Custom Resource Definition)自定义资源衍生而来。Kubernetes 的API设计是跨时代的,这种面向资源模型的声明式API体系,使得其能够在分布式体系管理各种资源。CRD的提出更是为开发者打开了创新的大门,从最开始的分布式应用部署,到更广阔的应用开发/发布场景,再到各类云服务场景。各类型资源都接入到Kubernetes API中有效协同管理。Operator的概念在这个过程中推波助澜,我们可以从 awesome-operators 这里看到,各种Operator实现种类齐全。

Operator模式与实践

Operator是一个设计模式,那它到底是一种什么样的模式。要分析这个问题我们可以先理解理解在Kubernetes中Deployment这个资源是如何设计和工作的。Deployment作为我们在Kubernetes中部署无状态应用的标准化方式,其实它的完整工作方式也是Operator设计模式的一种官方实践。在通过其他的标准Operator设计实践来进行理解。我们从以下两个方面来说明Operator模式。

资源定义

Deployment是一种资源,它有完整的定义和Kubernetes API原生的支持。资源的定义中大致分为三个部分:

  • Metadata
  • Specification
  • Status

我们先给它名一个名,资源三剑客,事实上不管是Statefulset等官方资源和CRD都是按照这样的三剑客模式定义。Metadata部分定义这个资源最基础的信息,版本、类型、名称、标签等等。这些信息会告诉所有人这个资源是什么,可以通过什么方式查询获取到它;Specification部分,简称Spec,该资源的规范性定义。这部分通俗的讲就是告知所有人这个资源要做的事和做事需要的条件。比如Deployment这部分的定义基本上就是需要创建Pod,至于创建多少,怎么创建,创建需要的信息都在Spec里定义了;Status部分就是体现当前资源的工作状态或者结果了。比如Deployment这里就体现Pod创建好没有,创建了多少,分别运行状态是什么一类的状态信息。

我们再从另外一个维度来理解资源定义,Metadata和Specification部分一般是由资源创建者来提供数据,或者由资源完善控制器来做部分数据完善。Status部分由资源控制器来响应和赋值。这里出现了两类角色,资源创建者,资源控制器。

Operator实践时,我们通过CRD来定义我们需要的资源类型,举个例子,Rainbond-Operator 项目目的是为了在Kubernetes集群中实现Rainbond 所有的组件安装和运维。那么我们定义了一个资源来描述Rainbond 的组件。

type RbdComponent struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   RbdComponentSpec    `json:"spec,omitempty"`
    Status *RbdComponentStatus `json:"status,omitempty"`
}

使用Golang 语言对这个资源进行定义的化它大概是这样的。满足上诉讲的三剑客原则。资源定义完成后使用operator sdk相关代码生成工具即可生成CRD资源定义。

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: rbdcomponents.rainbond.io
spec:
  group: rainbond.io
  names:
    ...
  scope: Namespaced
  subresources:
    status: {}
  validation:
    ...
  version: v1alpha1
  versions:
  - name: v1alpha1
    served: true
    storage: true

它大概是这样的,注意这里是局部代码。

控制器与状态维护

控制器负责完成对资源实例的生命周期维护,资源实例的生命周期一般包括:创建、更新、删除。上面讲了资源定义,资源定义在Kubernetes中的概念可以对应为CRD,资源实例那就是对应的CR。CRD的作用域是Kubernetes API,CR的主要作用域就是控制器。每一个CR的控制器实现基本上都是遵循1对多原则,及一个控制器支持管理多个CR。比如etcd-operator-controller 可以支持多个CR,创建出多个etcd集群。每一个CR在由控制器管理的过程类似于流水线一样。由CR的每一次状态变更或定时时钟驱动控制器完成相关的控制动作。基于这种类似的场景operator-sdk当然就给出了通用性开发框架来实现这个过程。

还是举两个例子,Deployment 的控制器在Kube-controller-manage中内置实现,Deployment的每次数据变更或特殊操作(更新)驱动控制器来判断此资源需要的下级资源(包括ReplicaSet )是否符合资源需求。如果需要创建、删除、更新相应的二级资源,由控制器驱动完成,然后更新状态到Deployment的status中。同样的上文讲到的rainbond-operator中的RbdComponent对应的控制器也一样。根据不同的组件定义创建出不同的二级资源,再形成资源的相关状态。

借用一下网络中的一张图来展示一下资源、控制器的工作流程。

kenzan-k8s-2.png

Operator协同

Operator这种模式目前应用中我们各类高级运维场景中,实现各种自动化运维特征。以Mysql数据库运维为例,或许会存在Mysql集群部署Operator,Mysql数据库数据备份Operator,Mysql数据库监控、日志分析Operator等等。我们是否可以想到这样一个问题,在同一个集群中各种各样的Operator同时存在时,会不会产生冲突、重复等等问题。比如一个Operator实现负责扩容,一个Operator实现负责缩容,他们共同作用于一类资源类型,如何协同将成为首要问题。

Operator模式的实现定义是不受约束的。其实在整个体系中,CRD定义、Operator模式实现,helm打包工具等等都是没有规范可循的,没有规范的资源和功能定义越来越多的时候我们想要让其能够协同工作将越来越困难。

我们想要的状态肯定是可以像搭积木一样选择各类Operator协同工作,因此我们需要上升一个维度,去探索Operator能否一定层面的标准规范化。

Operator标准化、规范化

标准化三个字在Kubernetes体系中针对物理资源管理层面来说效果显著。针对网络接入提出并实现了CNI规范,针对存储系统接入提出CSI规范,针对运行时接入提出CRI规范等等。这些规范提出都是为了解决异构的资源提供方以一种统一的、标准的方式接入Kubernetes体系的问题。

回到Operator上来,在Operator的实现上实现方式、使用方式越来越多。那么我们是否可以有一种较为规范的方式对Operator的实现进行准入。我们举一个例子,helm工具作为目前kubernetes app最常用的部署管理工具,但我认为其有一个最大的问题点在于不能体现app的实际状态。我们使用helm list 类的命令查询app列表时只能获取到它的部署状态,无法获取其真实状态,这就是由于资源状态定义没有规范导致(当然,不是说这种设计有问题,有缺陷,相反我们上文说了这种设计是大家各种各样创建的基础)。当Operator越来越多时我们需要一种管理工具可以有效管理和协同使用各种Operator实现。

我认为Operator的规范化将体现在下述几个方面:

  1. 资源状态体现规范化。
  2. 功能、能力边界规范化。
  3. 协同方式规范化。

愿景:Operator技术下沉,体验上浮

所有的技术都是为业务服务的,我们都有一个追求目标,把复杂的技术实现往下沉,让用户可以最简单的方式体验到Operator模式的能力。我们希望可以逐步打造一种工具或是形成一种规范,让广大的开发者能够发挥创新能力创造各种Operator,让后将其共享出来。对于大多数的用户可以便捷的选择需要的功能,像搭积木一样注入到自己的集群环境,应用于业务应用运维中。或许体验是这样的:
从一种平台中,我们可以一目了然的知道当前集群中有哪些应用运维能力,比如可以部署etcd集群,可以进行mysql数据备份,可以创建阿里云RDS,可以进行大数据计算等待。有了这些能力我们在部署和运维应用的同时可以方便的选择需要的运维功能,而不需要去关注它是如何实现。甚至这样的应用发布到其他环境去部署时依然可以找到对应的运维功能实现。

相关项目:

Rainbond 是以企业云原生应用开发、架构、运维、共享、交付为核心的Kubernetes多云赋能平台, 向下结合Kubernetes云原生资源管理模式,对接管理各类基础设施,通过多维度的软件定义屏蔽了底层资源的差异,甚至包括CPU架构差异和操作系统差异,从而对上层提供以应用为中心的基础设施; 向上定义了标准应用模型(RAM,OAM),内置ServiceMesh微服务架构框架, 提供用户基于源码/已有镜像构建服务组件的能力,编排服务组件的能力,发布共享完整应用模型的能力,交付运维业务应用的能力。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1月前
|
Kubernetes Cloud Native 开发者
云原生技术入门:Kubernetes和Docker的协作之旅
【10月更文挑战第22天】在数字化转型的浪潮中,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,引领读者步入云原生的世界,着重介绍Kubernetes和Docker如何携手打造弹性、可扩展的云环境。我们将从基础概念入手,逐步深入到它们在实际场景中的应用,以及如何简化部署和管理过程。文章不仅为初学者提供入门指南,还为有一定基础的开发者提供实践参考,共同探索云原生技术的无限可能。
45 3
|
2月前
|
Kubernetes Cloud Native 云计算
云原生时代的技术演进:Kubernetes与微服务架构的完美融合
随着云计算技术的飞速发展,云原生概念逐渐深入人心。本文将深入探讨云原生技术的核心——Kubernetes,以及它如何与微服务架构相结合,共同推动现代软件架构的创新与发展。文章不仅剖析了Kubernetes的基本工作原理,还通过实际案例展示了其在微服务部署和管理中的应用,为读者提供了一条清晰的云原生技术应用路径。
81 2
|
2月前
|
运维 Kubernetes Cloud Native
云原生技术入门:Kubernetes的奇妙之旅
【9月更文挑战第34天】在数字化浪潮中,云原生技术如Kubernetes已经成为IT行业的重要力量。本文旨在通过浅显易懂的方式,向初学者揭示Kubernetes的核心概念、架构设计及其在实际业务中的应用价值,帮助读者快速理解并掌握这一技术,为进一步深入学习和实践打下坚实基础。
56 1
|
3月前
|
Cloud Native 持续交付 Docker
云原生技术入门与实践:Docker容器化部署示例
【9月更文挑战第25天】在数字化转型的浪潮下,云原生技术成为推动企业创新的重要力量。本文旨在通过浅显易懂的语言,为初学者揭示云原生技术的核心概念及其应用价值。我们将以Docker容器为例,逐步引导读者了解如何将应用程序容器化,并在云端高效运行。这不仅是对技术趋势的跟随,更是对资源利用和开发效率提升的探索。
62 4
|
3月前
|
Kubernetes 负载均衡 Cloud Native
探索云原生技术:Kubernetes的魔法
【9月更文挑战第24天】 在数字化浪潮中,云原生技术如同现代航海的罗盘,指引着企业航向灵活、高效的未来。本文将深入剖析云原生世界的璀璨明星——Kubernetes,揭秘其如何在容器化的基础上,实现复杂应用的自动化部署、扩展和管理。从概念到实践,我们将一同领略Kubernetes如何简化运维、提高资源利用率,并推动微服务架构的发展。通过实际的代码示例,我们将手把手教你如何在云上构建和运行第一个Kubernetes集群,让理论与实践相结合,开启云原生之旅。
|
2月前
|
Kubernetes Cloud Native 调度
深入探讨容器化技术:Kubernetes 的魅力
【10月更文挑战第6天】深入探讨容器化技术:Kubernetes 的魅力
85 0
|
3月前
|
Kubernetes 负载均衡 监控
深入云原生技术:Kubernetes集群部署与管理
【9月更文挑战第17天】在数字化转型的浪潮中,云原生技术以其灵活性和可扩展性成为企业新宠。本文将引导读者探索云原生的核心组件——Kubernetes,通过实际案例分析其部署与管理流程,旨在帮助技术从业者和企业决策者理解如何利用Kubernetes提升应用的可用性和性能。从基础概念到操作实践,我们将一同见证云原生技术的变革力量。
|
3月前
|
Cloud Native 持续交付 Docker
云原生技术实践:Docker容器化部署教程
【9月更文挑战第4天】本文将引导你了解如何利用Docker这一云原生技术的核心工具,实现应用的容器化部署。文章不仅提供了详细的步骤和代码示例,还深入探讨了云原生技术背后的哲学,帮助你理解为何容器化在现代软件开发中变得如此重要,并指导你如何在实际操作中运用这些知识。
|
3月前
|
存储 Kubernetes Docker
深入探索容器化技术:Docker 实战与 Kubernetes 管理
深入探索容器化技术:Docker 实战与 Kubernetes 管理
76 0
|
3月前
|
Kubernetes Cloud Native Java
探索未来编程新纪元:Quarkus带你秒建高性能Kubernetes原生Java应用,云原生时代的技术狂欢!
Quarkus 是专为 Kubernetes 设计的全栈云原生 Java 框架,凭借其轻量级、快速启动及高效执行特性,在 Java 社区脱颖而出。通过编译时优化与原生镜像支持,Quarkus 提升了应用性能,同时保持了 Java 的熟悉度与灵活性。本文将指导你从创建项目、编写 REST 控制器到构建与部署 Kubernetes 原生镜像的全过程,让你快速上手 Quarkus,体验高效开发与部署的乐趣。
44 0