欢迎进入UG环球官网(环球UG)!

usdt无需实名买入卖出(www.caibao.it):Kubernetes CRD开发实践

admin2个月前69

USDT自动充值API接口

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

原题目:Kubernetes CRD开发实践

靠山

Kubernetes的最大亮点之一必定是它的声明式API设计,所谓的声明式就是告诉Kubernetes你要什么,而不是告诉它怎么做下令。我们一样平常使用Kubernetes做编排事情的时刻,经常会接触Deployment、Service、Pod等资源工具,我们可以很天真地确立其界说设置,然后执行kubectl apply下令,Kubernetes总能为我们确立相关资源工具并完成资源的注册,进而执行资源所卖力的功效。

然则我们有没想过,一样平常营业开发历程中,虽然通例的资源基本知足需求,然则这些通例的资源大多仅仅是代表相对底层、通用的观点的工具, 某些情形下我们总是想凭据营业定制我们的资源类型,而且行使Kubernetes的声明式API,对资源的增删改查举行监听并作出详细的营业功效。随着Kubernetes生态系统的持续发展,越来越多高层次的工具将会不停涌现,比起现在使用的工具,新工具将加倍专业化。

有了自界说资源界说API,开发者将不需要逐一举行Deployment、Service、ConfigMap等步骤,而是确立并关联一些用于表述整个应用程序或者软件服务的工具。除此,我们能使用自界说的高阶工具,并在这些高阶工具的基础上确立底层工具。例如:我们想要一个Backup资源,我们确立它的工具时,就希望通过spec的界说举行一样平常的备份操作声明,当提交给Kubernetes集群的时刻,相关的Deployment、Service资源会被自动确立,很大水平让营业扩展性加大。

在Kubernetes 1.7之前,要实现类似的自界说资源,需要通过TPR(ThirdPartyResource ) 工具方式界说自界说资源,但由于这种方式十分庞大,一度并不被人重视。到了Kubernetes 1.8版本,TPR最先被停用,被官方推荐的CRD(CustomResourceDefinitions)所取代。

CRD,称之为自界说资源界说,本质上,它的表现形式是一段声明,用于界说用户界说的资源工具而已。单单通过它还不能发生任何收益,由于开发者还要针对CRD界说提供关联的CRD工具CRD控制器(CRD Controller)。CRD控制器通常可以通过Golang举行开发,只需要遵照Kubernetes的控制器开发规范,并基于client-go举行挪用,并实现Informer、ResourceEventHandler、Workqueue等组件逻辑即可。听起来感受很庞大的样子,不外实在真正开发的时刻,并不难题,由于大部门繁琐的代码逻辑都能通过Kubernetes的code generator代码天生出来。关于若何举行CRD控制器的开发,下面我们会通过一个例子慢慢地深入,希望通过实践来明白CRD的原理。

CRD界说类型

与其他资源工具一样,对CRD的界说也使用YAML设置举行声明。下面先来看下本文的Demo例子的CRD界说。

本文的crddemo源码为:https://github.com/domac/crddemo

mydemo.yaml

apiVersion: apiextensions.k8s.io/v1beta1

kind: CustomResourceDefinition

name: mydemos.crddemo.k8s.io

group: crddemo.k8s.io

version: v1

names:

kind: Mydemo

plural: mydemos

scope: Namespaced

CRD界说中的要害字段如下:

在这个CRD中,我指定了group: crddemo.k8s.io,version: v1这样的API信息,也指定了这个CR的资源类型叫作Mydemo,复数(plural)是 mydemos。

我们先别着急使用kubectl create确立资源界说,我们接下来要做的是再基于这个CRD的界说确立响应的详细自界说工具。

example-mydemo.yaml

apiVersion: crddemo.k8s.io/v1

kind: Mydemo

name: example-mydemo

ip:

port: 8080

这个资源工具跟界说Pod差不多,它的主要信息都是泉源上面的界说,Kind是Mydemo,版本是v1,资源组是crddemo.k8s.io

除了这些设置,还需要在spec端设置响应的参数,一样平常是开发者自界说定制的,在这里,我定制了两个属性:ip和port。以是整个工具我要告诉Kubernetes,我期待监听处置一个叫example-mydemo的程序,它的地址是127.0.0.1,端口是8080。固然,这里只是一个demo,没有什么严酷的属性约束,开发者照样凭据自己的营业需要自行界说吧。为了不影响本文的先容,临时以为这两个属性是异常主要的。

到这里为止,相对轻松的事情已经完成,我们已经完成CRD的“设计图”事情,下面我们最先着手构建这个CRD控制器的编码事情了。

CRD控制器原理

在正式编码之前,我们先明白一下自界说控制器的事情原理,如下图:

CRD控制器的事情流,可分为监听、同步、触发三个步骤:

一、Controller首先会通过Informer (所谓的Informer,就是一个自带缓存和索引机制),从Kubernetes的API Server中获取它所体贴的工具,举个例子,也就是我编写的Controller获取的应该是Mydemo工具。值得注重的是Informer在构建之前,会使用我们天生的client(下面编码阶段会提到),再透过Reflector的ListAndWatch机制跟API Server确立毗邻,不停地监听Mydemo工具实例的转变。在ListAndWatch 机制下,一旦 APIServer 端有新的 Mydemo 实例被确立、删除或者更新,Reflector都市收到“事宜通知”。该事宜及它对应的API工具会被放进一个Delta FIFO Queue中。

二、Local Store此时完成同步缓存操作。

三、Informer凭据这些事宜的类型,触发我们编写并注册号的ResourceEventHandler,完成营业动作的触发。

上面图中的Control Loop现实上可以通过code-generator天生,下面也会提到。总之Control Loop中我们只体贴若何拿到“现实状态”,并与“期待状态”对比,从而详细的差异处置逻辑,只需要开发者自行编写即可。

CRD开发历程

下面会通过一个简朴的例子,最先我们的CRD代码的编写, 完整代码:https://github.com/domac/crddemo

自界说资源代码编写

首先,Kubernetes涉及的代码天生对项目目录结构是有要求的,以是我们先确立一个结构如下的项目。

├── controller.go

├── crd

│ └── mydemo.yaml

├── example

│ └── example-mydemo.yaml

├── main.go

└── pkg

└── apis

└── crddemo

├── register.go

└── v1

├── doc.go

├── register.go

├── types.go

可见要害部门的pkg目录就是API组的URL结构,如下图:

v1下面的types.go文件里,则界说了Mydemo工具的完整形貌。

1、我们首先开看pkg/apis/crddemo/register.go,这个文件主要用来存放全局变量,如下:

package crddemo

const (

GroupName =

Version =

)

2、pkg/apis/crddemo/v1下的doc.go 也是比较简朴的:

// +k8s:deepcopy-gen=package

// +groupName=crddemo.k8s.io

package v1

在这个文件中,你会看到+k8s:deepcopy-gen=package和+groupName=crddemo.k8s.io,这就是Kubernetes举行代码天生要用的Annotation气概的注释。

  • +groupName=crddemo.k8s.io,则界说了这个包对应的crddemo API组的名字。

可以看到,这些界说在doc.go文件的注释,起到的是全局的代码天生控制的作用,以是也被称为Global Tags。

3、pkg/apis/crddemo/types.go的作用就是界说一个Mydemo类型到底有哪些字段(好比,spec字段里的内容)。这个文件的主要内容如下所示:

package v1

import (

metav1

)

// +genclient

// +genclient:noStatus

// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

// Mydemo 形貌一个Mydemo的资源字段

Mydemo struct {

metav1.TypeMeta `json: `

metav1.ObjectMeta `json: `

Spec MydemoSpec `json: `

}

//MydemoSpec 为Mydemo的资源的spec属性的字段

MydemoSpec struct {

Ip string `json: `

Port int `json: `

}

// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

//复数形式

MydemoList struct {

metav1.TypeMeta `json: `

metav1.ListMeta `json: `

Items []Mydemo `json: `

}

上面的代码,可以开的我们的Mydemo可续界说方式跟Kubernetes工具一样,都包含了TypeMeta和ObjectMeta字段,而其中比较主要的是 Spec 字段,就是需要我们自己界说的部门:界说了IP和Port两个字段。

此外,除了界说Mydemo类型,你还需要界说一个MydemoList类型,用来形貌一组Mydemo工具应该包罗哪些字段。之以是需要这样一个类型,是由于在Kubernetes中,获取所有某工具的List方式,返回值都是List类型,而不是某类型的数组。以是代码上一定要做区分。

关于上面代码的几个主要注解,下面说明一下:

  • +genclient这段注解的意思是:请为下面资源类型天生对应的Client代码。
  • +genclient:noStatus的意思是:这个API资源类型界说里,没有Status字段,由于Mydemo才是主类型,以是+genclient要写在Mydemo之上,不用写在MydemoList之上,这时要仔细注重的。
  • +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object的意思是,请在天生DeepCopy的时刻,实现Kubernetes提供的runtime.Object接口。否则,在某些版本的Kubernetes里,你的这个类型界说会泛起编译错误。

4、pkg/apis/crddemo/register.go作用就是注册一个类型(Type)给APIServer。

package v1

import (

metav1

)

var SchemeGroupVersion = schema.GroupVersion{

Group: crddemo.GroupName,

Version: crddemo.Version,

}

var (

SchemeBuilder = runtime.NewSchemeBuilder(addKnownTypes)

AddToScheme = SchemeBuilder.AddToScheme

)

func Resource(resource string) schema.GroupResource {

SchemeGroupVersion.WithResource(resource).GroupResource

}

func Kind(kind string) schema.GroupKind {

SchemeGroupVersion.WithKind(kind).GroupKind

}

//Mydemo资源类型在服务器端的注册的事情,APIServer会自动帮我们完成

//但与之对应的,我们还需要让客户端也能知道Mydemo资源类型的界说

func addKnownTypes(scheme *runtime.Scheme) error {

scheme.AddKnownTypes(

SchemeGroupVersion,

&Mydemo{},

&MydemoList{},

)

// register the the scheme

metav1.AddToGroupVersion(scheme, SchemeGroupVersion)

nil

}

有了addKnownTypes这个方式,Kubernetes就能够在后面天生客户端的时刻,知道Mydemo以及MydemoList类型的界说了。

好了,到这里为止,我们有关界说的代码已经写好了,正如controller原理图所示,接下来我们需要通过Kubernetes提供的代码天生工具,为上面的Mydemo资源类型天生clientset、informer和lister。

关于若何使用代码天生,这里我已经编写了一个脚步,只需只需本脚步即可。

代码天生

详细可以挪用我提供的shll剧本:code-gen.sh

-x

ROOT_PACKAGE=

CUSTOM_RESOURCE_NAME=

CUSTOM_RESOURCE_VERSION=

GO111MODULE=off

[[ -d /src/k8s.io/code-generator ]] || go get -u k8s.io/code-generator/...

/src/k8s.io/code-generator && ./generate-groups.sh all

当只需代码天生脚步后,可以发现我们的代码事情目录也发送了转变,多出了一个client目录。

client

├── clientset

│ └── versioned

│ ├── clientset.go

│ ├── doc.go

│ ├── fake

│ │ ├── clientset_generated.go

│ │ ├── doc.go

│ │ └── register.go

│ ├── scheme

│ │ ├── doc.go

│ │ └── register.go

│ └── typed

│ └── crddemo

│ └── v1

│ ├── crddemo_client.go

│ ├── doc.go

│ ├── fake

│ │ ├── doc.go

│ │ ├── fake_crddemo_client.go

│ │ └── fake_mydemo.go

│ ├── generated_expansion.go

│ └── mydemo.go

├── informers

│ └── externalversions

│ ├── crddemo

│ │ ├── interface.go

│ │ └── v1

│ │ ├── interface.go

│ │ └── mydemo.go

│ ├── factory.go

│ ├── generic.go

│ └── internalinterfaces

│ └── factory_interfaces.go

└── listers

└── crddemo

└── v1

├── expansion_generated.go

└── mydemo.go

其中,pkg/apis/crddemo/v1下面的zz_generated.deepcopy.go文件,就是自动天生的DeepCopy代码文件。下面的三个包(clientset、informers、 listers),都是Kubernetes为Mydemo类型天生的client库,这些库会在后面编写自界说控制器的时刻用到。

自界说控制器代码编写

Kubernetes的声明式API并不像“下令式API”那样有着显著的执行逻辑。这就使得基于声明式API的营业功效实现,往往需要通过控制器模式来“监视”API 工具的转变,然后以此来决议现实要执行的详细事情。

main.go

package main

import (

clientset

informers

)

//程序启动参数

var (

flagSet = flag.NewFlagSet( , flag.Exit)

master = flag.String( , , )

kubeconfig = flag.String( , , )

onlyOneSignalHandler = make(chan struct{})

shutdownSignals = []os.Signal{os.Interrupt, syscall.SIGTERM}

)

,

Usdt第三方支付接口

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

,

//设置信号处置

func setupSignalHandler (stopCh <-chan struct{}) {

close(onlyOneSignalHandler)

stop := make(chan struct{})

c := make(chan os.Signal, 2)

signal.Notify(c, shutdownSignals...)

go {

<-c

close(stop)

<-c

os.Exit(1)

}

stop

}

func {

flag.Parse

//设置一个信号处置,应用于优雅关闭

stopCh := setupSignalHandler

cfg, err := clientcmd.BuildConfigFromFlags(*master, *kubeconfig)

err != nil {

glog.Fatalf( , err.Error)

}

kubeClient, err := kubernetes.NewForConfig(cfg)

err != nil {

glog.Fatalf( , err.Error)

}

mydemoClient, err := clientset.NewForConfig(cfg)

err != nil {

glog.Fatalf( , err.Error)

}

//informerFactory工厂类, 这里注入我们通过代码天生的client

//clent主要用于和API Server举行通讯,实现ListAndWatch

mydemoInformerFactory := informers.NewSharedInformerFactory(mydemoClient, time.Second*30)

//天生一个crddemo组的Mydemo工具传递给自界说控制器

controller := NewController(kubeClient, mydemoClient,

mydemoInformerFactory.V1.Mydemos)

go mydemoInformerFactory(stopCh)

err = controller.Run(2, stopCh); err != nil {

glog.Fatalf( , err.Error)

}

}

接下来,我们来看跟营业最慎密的控制器Controller的编写。

controller.go部门主要代码:

… …

func NewController(

kubeclientset kubernetes.Interface,

mydemoslientset clientset.Interface,

mydemoInformer informers.MydemoInformer) *Controller {

// Create event broadcaster

// Add sample-controller types to the default Kubernetes Scheme so Events can be

// logged sample-controller types.

utilruntime.Must(mydemoscheme.AddToScheme(scheme.Scheme))

glog.V(4).Info( )

eventBroadcaster := record.NewBroadcaster

eventBroadcaster.StartLogging(glog.Infof)

eventBroadcaster.StartRecordingToSink(&typedcorev1.EventSinkImpl{Interface: kubeclientset.CoreV1.Events( )})

recorder := eventBroadcaster.NewRecorder(scheme.Scheme, corev1.EventSource{Component: controllerAgentName})

//使用client和前面确立的Informer,初始化了自界说控制器

controller := &Controller{

kubeclientset: kubeclientset,

mydemoslientset: mydemoslientset,

demoInformer: mydemoInformer.Lister,

mydemosSynced: mydemoInformer.Informer.HasSynced,

workqueue: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter,

recorder: recorder,

}

glog.Info(" Setting up mydemo event handlers”)

//mydemoInformer注册了三个Handler(AddFunc、UpdateFunc和DeleteFunc)

// 划分对应API工具的“添加”“更新”和“删除”事宜。而详细的处置操作,都是将该事宜对应的API工具加入到事情行列中

mydemoInformer.Informer.AddEventHandler(cache.ResourceEventHandlerFuncs{

AddFunc: controller.enqueueMydemo,

UpdateFunc: func(old, new interface{}) {

oldMydemo := old.(*samplecrdv1.Mydemo)

newMydemo := new.(*samplecrdv1.Mydemo)

oldMydemo.ResourceVersion == newMydemo.ResourceVersion {

}

controller.enqueueMydemo(new)

},

DeleteFunc: controller.enqueueMydemoForDelete,

})

controller

}

… …

通过上面Controller的代码实现,我们基本实现了控制器ListAndWatch的事宜注册逻辑:通过APIServer的LIST API获取所有最新版本的API工具;然后,再通过WATCH-API来监听所有这些API工具的转变。通过监听到的事宜转变,Informer就可以实时地更新内陆缓存,而且挪用这些事宜对应的EventHandler了。

下面,我们再来看原理图中的Control Loop的部门。

func (c *Controller) Run(threadiness int, stopCh <-chan struct{}) error {

defer runtime.HandleCrash

defer c.workqueue.ShutDown

// 纪录最先日志

glog.Info( )

glog.Info( )

ok := cache.WaitForCacheSync(stopCh, c.mydemosSynced); !ok {

fmt.Errorf( )

}

glog.Info( )

i := 0; i < threadiness; i++ {

go wait.Until(c.runWorker, time.Second, stopCh)

}

glog.Info( )

<-stopCh

glog.Info( )

nil

}

可以看到,启动控制循环的逻辑异常简朴,就是同步+循环监听义务。而这个循环监听义务就是我们真正的营业实现部门了。

//runWorker是一个不停运行的方式,而且一直会挪用c.processNextWorkItem从workqueue读取和读取新闻

func (c *Controller) {

c. {

}

}

//从workqueue读取和读取新闻

func (c *Controller) processNextWorkItem bool {

obj, shutdown := c.workqueue.Get

shutdown {

}

err := func(obj interface{}) error {

defer c.workqueue.Done(obj)

var key string

var ok bool

key, ok = obj.(string); !ok {

c.workqueue.Forget(obj)

runtime.HandleError(fmt.Errorf( , obj))

nil

}

err := c.syncHandler(key); err != nil {

fmt.Errorf( , key, err.Error)

}

c.workqueue.Forget(obj)

glog.Infof( , key)

nil

}(obj)

err != nil {

runtime.HandleError(err)

}

}

//实验从Informer维护的缓存中拿到了它所对应的Mydemo工具

func (c *Controller) syncHandler(key string) error {

namespace, name, err := cache.SplitMetaNamespaceKey(key)

err != nil {

runtime.HandleError(fmt.Errorf( , key))

nil

}

mydemo, err := c.demoInformer.Mydemos(namespace).Get(name)

//从缓存中拿不到这个工具,那就意味着这个Mydemo工具的Key是通过前面的“删除”事宜添加进事情行列的。

err != nil {

errors.IsNotFound(err) {

//对应的Mydemo工具已经被删除了

glog.Warningf( ,

namespace, name)

glog.Infof( , namespace, name)

nil

}

runtime.HandleError(fmt.Errorf( , namespace, name))

err

}

glog.Infof( , mydemo)

c.recorder.Event(mydemo, corev1.EventTypeNormal, SuccessSynced, MessageResourceSynced)

nil

}

代码中的demoInformer,从namespace中通过key获取Mydemo工具这个操作,实在就是在接见内陆缓存的索引,现实上,在Kubernetes的源码中,你会经常看到控制器从种种Lister里获取工具,好比:podLister、nodeLister等等,它们使用的都是Informer和缓存机制。

而若是控制循环从缓存中拿不到这个工具(demoInformer返回了IsNotFound错误),那就意味着这个Mydemo工具的Key是通过前面的“删除”事宜添加进事情行列的。以是,只管行列里有这个Key,然则对应的Mydemo工具已经被删除了。而若是能够获取到对应的Mydemo工具,就可以执行控制器模式里的对比“期望状态(用户通过YAML文件提交到APIServer里的信息)”和“现实状态(我们的控制循环需要通过查询现实的Mydemo资源情形”的功效逻辑了。不外在本例子中,就不做过多的营业假设了。

至此,一个完整的自界说API工具和它所对应的自界说控制器,就编写完毕了。

部署测试

代码编码后,我们准备最先代码的公布,可以使用提供Makefile举行编译。

$ make

... …

gofmt -w .

go -v .

? github.com/domac/crddemo [no files]

mkdir -p releases

GOOS=linux GOARCH=amd64 go build -mod=vendor -ldflags -v -o releases/crddemo *.go

github.com/golang/groupcache/lru

k8s.io/apimachinery/third_party/forked/golang/json

k8s.io/apimachinery/pkg/util/mergepatch

k8s.io/kube-openapi/pkg/util/proto

k8s.io/client-go/tools/record/util

k8s.io/apimachinery/pkg/util/strategicpatch

k8s.io/client-go/tools/record

-line-arguments

go clean -i

... ...

编译完成后,会天生crddemo的二进制文件,我们要做把crddemo放到Kubernetes集群中,或者内陆也行,只要能接见到apiserver和具备kubeconfig。

可以看到,程序运行的时刻,一最先会报错。这是由于,此时Mydemo工具的CRD还没有被确立出来,以是Informer去APIServer里获取Mydemos工具时,并不能找到Mydemo这个API资源类型的界说。

接下来,我们执行我们自界说资源的界说文件:

$ kubectl apply -f crd/mydemo.yaml

customresourcedefinition.apiextensions.k8s.io/mydemos.crddemo.k8s.io created

此时,考察crddemo的日志输出,可以看到Controller的日志恢复了正常,控制循环启动乐成。

然后,我们可以对我们的Mydemo工具举行增删改查操作了。

提交我们的自界说资源工具:

$ kubectl apply -f example-mydemo.yaml

mydemo.crddemo.k8s.io/example-mydemo created

确立乐成够,看Kubernetes集群是否乐成存储起来:

$ kubectl get Mydemo

NAME AGE

example-mydemo 2s

这时刻,查看一下控制器的输出:

可以看到,我们上面确立example-mydemo.yaml的操作,触发了EventHandler的添加事宜,从而被放进了事情行列。紧接着,控制循环就从行列里拿到了这个工具,而且打印出了正在处置这个Mydemo工具的日志。

我们这时刻,实验修改资源,对对应的port属性举行修改。

apiVersion: crddemo.k8s.io/v1

kind: Mydemo

name: example-mydemo

ip:

port: 9090

手动执行修改:

$ kubectl apply -f example-mydemo.yaml

此时,crddemo新增出来的日志如下:

可以看到,这一次,Informer 注册的更新事宜被触发,更新后的Mydemo工具的Key被添加到了事情行列之中。

以是,接下来控制循环从事情行列里拿到的Mydemo工具,与前一个工具是差别的:它的ResourceVersion的值从10818363变成了10818457;而Spec里的Port字段,则变成了9080。最后,我再把这个工具删除掉:

$ kubectl delete -f example-mydemo.yaml

mydemo.crddemo.k8s.io deleted

这一次,在控制器的输出里,我们就可以看到,Informer注册的“删除”事宜被触发,输出如下:

然后,Kubernetes集群的资源也被清除了:

$ kubectl get Mydemo

No resources found default namespace.

以上就是使用自界说控制器的基本开发流程。

上一篇 下一篇

猜你喜欢

网友评论

随机文章
热门文章
热评文章
热门标签