Knative Serving 进阶: Knative Serving SDK


作者 |阿里云智能事业群技术专家 牛秋霖(冬岛)导读:通过前面的一系列文章你已经知道如何基于 kubectl 来操作 Knative 的各种资源。但是如果想要在项目中集成 Knative 仅仅使用 kubectl 这种命令的方式是不够的,还需要在代码中基于 Knative Serving SDK 进行集成开发。本篇文章中,阿里云智能事业群技术专家冬岛将从 Knative Serving SDK 入手,介绍如何基于 Knative SDK 进行 serverless 开发。在正式开始介绍 Knative Serving SDK 之前,我们先简单介绍一下 Golang Context 的机理。因为在 Knative Serving 中 client、Informer 的初始化和信息传递完全是基于 Golang Context 实现的。Golang 是从 1.7 版本开始引入的 Context ,Golang 的 Context 可以很好的简化多个 goroutine 之间以及请求域间的数据传递、取消信号和截至时间等相关操作。Context 主要有两个作用:Context 本身是一个接口。这个接口中定义了四个方法,下面分别介绍:关于 Context 主要记住一点:可以通过 Value 传递数据,Value 是一个键值对结构。更多详细的介绍可以参见下面这些文章:在 Context 的这些特性中,Knative Serving 中重度依赖的是 Value 功能。以 Service 的 Informer 初始化为例进行说明,这里可以看到源码。Informer “构造函数”是在 init 函数中自动注册到 injection.Default 中的。当 Informer “构造函数”被调用之后会自动把生成的 Informer 注入到 Context 中 context.WithValue(ctx, Key{}, inf), inf.Informer()。从上图中可以看到:Informer 初始化的时候需要调用 factory,而 factory 本身是从 Context 中获取的。下面我们再看看 factory 是怎么初始化的。factory 的初始化。
上图可以发现,factory 也是把“构造函数”注册到 injection.Default 中,并会将生成的 SharedInformerFactory 注入到 Context 中。而且 factory 中使用的 client (链接 kube-apiserver 使用的对象)也是从 Context 获取到的。可以说 Knative Serving SDK 初始化的过程是面向 Context 编程的。关键对象是自动注入到 Context,在使用的时候从 Context 中取出。顺带提一点,Knative Serving 的日志对象也是在 Context 保存的,当需要打印日志的时候先通过 logger := logging.FromContext(ctx) 从 Context 中拿到 logger,然后就可以使用了。这样做的好处是可以通过管理 logger 对象,比如做 trace 功能。如下所示是基于 logger 打印出来的日志,可以看到对于同一个请求的处理是可以通过 traceID 进行追踪的。下面这段日志都是对 577f8de5-cec9-4c17-84f7-f08d39f40127 这个 trace 的处理。介绍完 Knative Serving client 的初始化过程,下面我们看一下应该如何在代码中用 Knative Serving SDK 进行编码。
示例参见:https://github.com/knative-sample/serving-controller/blob/v0.1/cmd/app/app.go这个示例中首先使用配置初始化 *zap.SugaredLogger对象,然后基于 ctx := signals.NewContext() 生成一个 Context。signals.NewContext()作用是监听 SIGINT 信号,也就是处理 CTRL+c 指令。这里用到了 Context 接口的 Done 函数机制。接着使用 ctx, informers := injection.Default.SetupInformers(ctx, cfg) 构造出所有的 informer,然后调用下面这段代码执行注入,把 informer 注入到 Context 中。实例代码: https://github.com/knative-sample/serving-controller/blob/v0.1/pkg/controller/controller.go如上所示,所有的 informer 都是从 Context 中获取的。最后 Controller 初始化一个 Reconciler 接口,接口的定义如下, 里面只有一个 Reconcile 函数。这个使用方式和 sigs.k8s.io/controller-runtime 使用的逻辑是一样的。如果你之前写过 Operator 之类的功能,对这个操作应该不会陌生。代码示例: https://github.com/开发云主机域名knative-sample/serving-controller/blob/v0.1/pkg/controller/service.go现在就可以在 Reconcile 中通过 c.serviceLister.Services(namespace).Get(name) 这种方式直接操作 Seving 资源了。至此,我们已经把基于 Knative Seving 开发 Serverless 应用的关键脉梳理了一遍。更详细的代码示例请参见:https://github.com/knative-sample/serving-controller ,这里面有完整可以运行的代码。本文从 Knative Serving client 的初始化过程开始展开,介绍了 Knative informer 的设计以及使用方法。通过本文你可以了解到:

相关推荐: 自定义FreeBSD12镜像拉起ECS报错后的处理过程

今天帮客户做了个FreeBSD12的自定义镜像,使用自定义镜像后创建ECS后,缺发现机器启动异常,然后使用VNC去登录系统:1、将自定义的FreeBSD镜像上传到云平台的环境中后,使用自定义镜像创建虚拟机,无法正常访问,使用vnc远程机器登录,发现卡在moun…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 05/13 17:29
下一篇 05/13 17:29

相关推荐