docker的原理_docker底层原理

简介

redHat: kubernetes operator 是一种封装、部署和管理 Kubernetes 应用的方法。

我们平时 使用kubernetes API (应用编程接口)和kubectl工具在kubernetes上部署并管理kubernetes应用。

而kubernetes operator 是一种特定于(定制)应用的控制器，可以扩展kubernetes API的功能，来代表kubernetes用户进行创建、配置和管理复杂应用的实例。

它基于基本 Kubernetes 资源和控制器概念构建，但又涵盖了特定于域或应用的知识，用于实现其所管理软件的整个生命周期的自动化。

我们平时使用k8s restAPI或者通过kubectl工具手动部署管理我们的应用，而operator是通过k8s restAPI 自动创建 配置管理我们的应用，而且是定制化的。

简单几个概念

• CRD Custom Resource Definition

    在k8s中一切皆是资源，资源就是CRD，用户自定义的k8s资源，是一个类型 ，默认自带的CRD比如deployment pod service等。 在yaml 中kind 名称就是crd名称

• CR Custom Resourse

    是实现CRD的 具体实例

• webhook webhook

    kubernetes 中的一种http回调，默认注册到kube-apiserver上，与apiserver进行绑定。webhook主要作用是进行资源的修改(mutating)和验证(validating) 。

    类似与Java中的过滤器，外部对CRD资源的变更，在Controller处理之前都会交给webhook提前处理，进行修改/验证。

    其实webhook 就是准入控制器。 深入理解 Kubernetes Admission Webhook 玩转K8S AdmissionWebhook

• 工作队列 controller 工作队列

    核心组件，它会监控集群内的资源变化，并把相关的对象，包括它的动作与 key，例如 Pod 的一个 Create 动作，作为一个事件存储于该队列中；

• **controller **

    controller是CRD实现业务逻辑的核心，它控制当前CRD运行管理动作。会持续监听集群状态变化，把跟自己有关的对象事件比如（create delete update ）放到工作 队列中，并且会持续把当前资源状态变成用户定义的spec期望状态。

• operator

    operator官方说是描述、管理和部署kubrenetes应用的一套机制，就是文档开头说的。总的来说operator= CRD+webhook+controller

工作原理

controller 工作原理：

在说Kubernetes Operator工作原理之前先了解controller 工作方式：

前方高能

首先我们知道想要获取某个资源的数据/状态，都需要进行List-Watch 向ApiServer发起请求 ，而发背后的实现真正查询的是apiserver向etcd发起的watch是没有条件的,只能知道某个数据发生了变化或创建、删除，但不能过滤具体的值,然后组件通过List-Watch进行数据的筛选获得自己关心的数据。

看上面图表述了controller执行流程：1.informer通过List-Watch获取跟踪某个资源状态，其实informer和apiserver通过长连接保证资源的实时通知的。informer感知到数据变化后先放入自己缓存中(localStore)中，然后把对象变化的事件流保存到FIFO队列。Callbacks 在FIFO队列中拿到资源对象的变化事件，放入controller的工作队列(workqueue)中。此时worker函数消费工作队列(workqueue)，根据事件进行状态操作，执行真正的业务逻辑。当前状态和期望状态的差别，然后通过client-go向API server发送请求，直到驱动资源变成用户期望的状态。

informer 组件说明：

List/Watch：List是列举apiserver中对象的接口，Watch是监控apiserver资源变化的接口；

Reflector：我习惯成称之为反射器，实现对apiserver指定类型对象的监控，其中反射实现的就是把监控的结果实例化成具体的对象；

DeltaIFIFO：将Reflector监控的变化的对象形成一个FIFO队列

LocalStore：指的就是Indexer的实现cache，这里面缓存的就是apiserver中的对象(其中有一部分可能还在DeltaFIFO中)，此时使用者再查询对象的时候就直接从cache中查找，减少了apiserver的压力；

Callbacks：通知回调函数，Infomer感知的所有对象变化都是通过回调函数通知使用者(Listener)；

Kubernetes Operator 工作原理

在kuberntes 中，控制平面的控制器(kube-controller-manager)实施控制循环，反复比较集群的理想状态和实际状态。如果集群的实际状态于理想状态不符，控制器将采取措施解决 此问题。

Kubernetes Operator 监视 CR 类型并采取特定于应用的操作，确保当前状态与该资源的理想状态相符。

Kubernetes Operator 通过自定义资源定义引入新的对象类型。Kubernetes API 可以像处理内置对象一样处理自定义资源定义，包括通过 kubectl 交互以及包含在基于角色的访问权限控制（RBAC）策略中。

Kubernetes Operator 会持续监控正在运行的应用，可备份数据，从故障中恢复，以及随着时间的推移自动升级应用。

Kubernetes Operator 几乎可执行任何操作：扩展复杂的应用，应用版本升级，甚至使用专用硬件管理计算集群中节点的内核模块。

通俗来讲： 用户创建一个CRD自定义资源，apiserver把CRD转发给webhook，webhook 进行缺省值配置 验证配置和修改配置，webhook处理完成，把配置存入etcd中 ，返回给用户。controller 会监测到CRD，按照预先写的业务逻辑，进行处理这个CRD，比如创建pod。controller会 持续监听这个CRD的变化，保证运行的状态跟期望的一致。

operator-framework

operator-framework 是kubernetes operator的开发框架，框架的主要内容是为开发人员提供了webhook 和controller 实现，开发人员只需要关心controller业务逻辑实现。

目前比较出名的项目：

    - kubebuiler https://cloudnative.to/kubebuilder/

    - operator-sdk https://sdk.operatorframework.io/

    两者本身没有区别，都是使用controller-tools和controller-runtime，细节上kubebuilder相应的测试、部署、代码生成脚手架比较完善。如Makefile和Kustomize等工具的集成；operator-sdk则支持与ansible operator、operator Lifecycle Manager helm的集成。
后面文章里我们通过kubebuilder进行演示。

今天的文章docker的原理_docker底层原理分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。