菜宝钱包（caibao.it）是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。
靠山
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}
)
,,菜宝钱包（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.
以上就是使用自界说控制器的基本开发流程。
网友评论