Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >Kubernetes对象深入学习之一:概览

Kubernetes对象深入学习之一:概览

作者头像
程序员欣宸
发布于 2023-07-10 09:39:11
发布于 2023-07-10 09:39:11
34600
代码可运行
举报
文章被收录于专栏:实战docker实战docker
运行总次数:0
代码可运行

欢迎访问我的GitHub

这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos

关于《Kubernetes对象深入学习》系列

  • 在client-go的学习和使用过程中,不可避免涉及到对象相关的代码,经常面临一个尴尬的现象:平时代码能读懂七七八八,一旦写的时候就感觉无从下手,甚至抄都不知道去哪抄,例如:拿到一个runtime.Object类型的接口该如何处理,它的具体实现可能有哪些?如何取得它的name、label、annonation等信息?
  • 为了解决这些问题,必须对kubernetes的对象及其相关的代码有足够了解,然而面对大量代码和知识点,如何将其梳理清晰,合理拆分为多个重点,进行系统的学习,这就是《Kubernetes对象深入学习》系列的主要任务
  • 写这个系列的过程,也是欣宸自己的学习过程,整个系列会包含丰富的图示、表格、实战等元素加入,这些都是欣宸原创的特色,总之就是手段齐出,尽可能将知识点清晰立体的传达给您

本篇概览

  • 本文是《Kubernetes对象深入学习》系列的开篇,咱们先从整体上说清楚这个系列讲的是哪些内容,涉及哪些知识点,还要理清它们之间的关系,后续的文章会聚焦这些知识点深入学习,如此一来,从入门到精通也不是没有可能[dog]
  • 接下来会从对象定义开始,再展开与之相关的接口和实现类进行分析,最后结合实际的kubernetes资源来分析,这样就完成了对kubernetes对象的初步了解

核心知识点

  • 为了便于理解,这里将核心知识浓缩为几下几点
  1. 与对象有关的大部分源码在k8s.io/apimachinery这个module中
  2. 对象的根源是runtime.Object,官方描述如下
  1. 这里将对象相关的知识按照不同侧重点梳理出三条线,以便咱们逐个击破,避免那种面对大量知识点无从下手的困境,具体的三条线如下图所示,分别是:对象类型、属性、列表属性,每个知识点都有明确的接口和实现
  • 从上图可见,runtime.Object是个接口,其真实的实现可能是单个对象,也可能是列表对象,但无论是哪种都实现了类型接口schema.ObjectKind,然后就是它们各自的特有接口:单个对象有metav1.Object,列表对象有metav1.Listinterface
  • 注意:上图是学习路线,不是UML!

关于metav1

  • 在kubernetes源码中,metav1是k8s.io/apimachinery/pkg/apis/meta/v1这个package的别名,如下所示,因此文中都用metav1来表示完整的包
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

源码位置

  • 为了便于翻阅源码,这里用列表将其整理好以便随时用到(可以看出内容确实不少,这些kubernetes的基础知识,是不推荐速成的,还是认真深入学习逐个掌握吧)

接口&对象

类型

文件位置

说明

runTime.Object

接口

runtime/interfaces.go

kubernetes的对象都实现了此接口

schema.ObjectKind

接口

runtime/schema/interfaces.go

对象类型相关的接口

metav1.Object

接口

apis/meta/v1/meta.go

属性相关的接口

metav1.ListInterface

接口

apis/meta/v1/meta.go

对象列表相关的接口

metav1.TypeMeta

实现类

apis/meta/v1/types.go

ObjectKind接口的实现类,负责类型的逻辑

metav1.ObjectMeta

实现类

apis/meta/v1/types.go

Object接口的实现类,负责属性的逻辑

metav1.ListMeta

实现类

apis/meta/v1/types.go

ListInterface接口的实现类,负责列表的逻辑

  • 有了上面的表格,那么多interface和struct终于不显得混乱了,再捋一捋会更清晰:
  1. 除了类型接口比较特殊,属于schema包,其余所有接口和实现类都在metav1包中
  2. 实现类的名字都是xxxMeta

runtime.Object和metav1.TypeMeta的关系(非常重要!

  • runtime.Object和metav1.TypeMeta的关系需要尽早理清楚,后面的学习会顺利很多
  • 先看runtime.Object的源码,如下所示,非常简单的接口,只定义了两个方法
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
type Object interface {
	GetObjectKind() schema.ObjectKind
	DeepCopyObject() Object
}
  • 再看schema.ObjectKind接口
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
type ObjectKind interface {
	// SetGroupVersionKind sets or clears the intended serialized kind of an object. Passing kind nil
	// should clear the current setting.
	SetGroupVersionKind(kind GroupVersionKind)
	// GroupVersionKind returns the stored group, version, and kind of an object, or an empty struct
	// if the object does not expose or provide these fields.
	GroupVersionKind() GroupVersionKind
}
  • 最后看metav1.TypeMeta的代码,把runtime.Object和schema.ObjectKind定义的方法都实现了(注意,弄清楚这一点非常重要
  • 也就是说metav1.TypeMeta实现了runtime.Object的GetObjectKind方法,至于另一个方法DeepCopyObject,咱们来看看Pod的源码就一目了然了
  • 关于上图黄色箭头1指向的deepcopy-gen,涉及到代码生成工具,此工具在编译时会把代码生成在kubernetes源码目录中,再用于编译,举个例子,pod有关的生成代码如下
  • 通过上面对Pod代码的分析,得到这么一个规律:如果一个数据结构内嵌了TypeMeta,并且用deepcopy-gen工具生成DeepCopyObject方法,那么这个数据结构就是runtime.Object接口的实现类(非常重要!
  • 按照这个规则去找一个列表对象看看,就选PodList吧,这是kubernetes用来表达Pod对象列表的数据结构,如下图所示,和Pod一样的套路
  • 现在对最基础的runtime.Ojbect算是有了一定的了解,接下来分别观察单个对象和列表对象,即要看它们和通用接口TypeMeta的关系,也要看它们各自特有的接口:ObjectMeta和ListMeta

单个对象实现的接口:TypeMeta和ObjectMeta

  • 虽然用表格和关系图做了梳理,但还是有些抽象,所以这里来举个具体的例子,把前面那些对象、接口、实现的关系做个说明
  • 在kubernetes开发中,pod应该是最常见的对象了,它的数据结构源码在kubernetes仓库中的apis/core/types.go文件
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
// 1. 代码生成器来生成runtime.Object接口的实现
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

// Pod is a collection of containers, used as either input (create, update) or as output (list, get).
type Pod struct {
	// 2. 这样就实现了schema.ObjectKind接口
	metav1.TypeMeta
	
	// 3. 这样就实现了metav1.Object接口
	// +optional
	metav1.ObjectMeta

	// Spec defines the behavior of a pod.
	// +optional
	Spec PodSpec

	// Status represents the current information about a pod. This data may not be up
	// to date.
	// +optional
	Status PodStatus
}
  • 从上述代码可见,Pod数据结构嵌入了metav1.TypeMeta、metav1.ObjectMeta,这就实现了schema.ObjectKind和metav1.Object接口
  • 如果上面对Pod源码的分析还不够具体,您依然对TypeMeta和ObjectMeta没有形象具体的认识,那就再找个更具体例子吧
  • 在kubernetes环境执行kubectl get pod kube-apiserver-hedy -n kube-system -o yaml,作用是以yaml格式的名义查看api-server的pod详情,内容如下图所示,属于TypeMeta和ObjectMeta部分的内容用黄色箭头标识出来了
  • 现在您应该对metav1.TypeMeta、metav1.ObjectMeta有了大致认识,也发现了一个问题:不是分了三条学习线路吗?还有个metav1.ListInterface呢?

列表对象实现的接口:TypeMeta和ListMeta

  • 为了说清楚metav1.ListInterface,还是以Pod为例吧,它有自己专属的列表对象PodList,源码如下
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
type PodList struct {
	metav1.TypeMeta
	// +optional
	metav1.ListMeta

	Items []Pod
}
  • 也就是说,kubernetes在表达Pod列表的时候,并不是简单的使用Pod切片,而是使用了PodList对象,列表的真实数据存储在Items字段中
  • PodList内嵌了metav1.TypeMeta,这和Pod是一致的,因此这里得出一个重要结论:PodList也是runtime.Object接口的的具体实现,这很重要!
  • 请务必注意:当一段代码中出现runtime.Object时,它的真实对象可能是一个资源实例,例如Pod,也可能是个列表对象,例如PodList
  • 还剩一个问题:PodList和ListInterface有啥关系呢?很简答:PodList内嵌了metav1.ListMeta,metav1.ListMeta又是ListInterface的实现类,因此PodList也是ListInterface的实现类
  • 至此,本篇算是完成了,咱们算是对kubernetes的对象和相关接口有了基本的了解,至少它们关系已经理清楚,读kubernetes源码的时候可以对的上号了,接下来的内容就会聚焦到每个知识点的深度上,再配上丰富的编码实战,咱们有信心学好kubernetes知识

你不孤单,欣宸原创一路相伴

  1. Java系列
  2. Spring系列
  3. Docker系列
  4. kubernetes系列
  5. 数据库+中间件系列
  6. DevOps系列
本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2023-07-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
K8s源码分析(4)-Resource Model
在上一篇文章中我们主要介绍了 kubernetes 世界中的各种 resource 的 version,其中包括了资源的内部 internal version 和外部非 internal version,以及引入 internal version 来方便各种 resource 持续渐进演化的设计初衷。另外也从源码的角度分析了其中各个资源 group 的对外 version 和 internal version 都定义在哪些源文件之中,在这里我们主要介绍 kubernetes 中各种 resource 的基本定义 model。
TA码字
2021/10/08
5740
深入 kubernetes API 的源码实现
很多同学应该像我一样,第一次打开 Github 上面 kubernetes 项目源码的时候就被各种仓库搞晕了,kuberentes 组织下有很多个仓库,包括 kubernetes、client-go、api、apimachinery 等,该从哪儿仓库看起?kubernetes 仓库应该是 kubernetes 项目的核心仓库,它包含 kubernetes 控制平面核心组件的源码;client-go 从名字也不难看出是操作 kubernetes API 的 go 语言客户端;api 与 apimachinery 应该是与 kubernetes API 相关的仓库,但它们俩为啥要分成两个不同的仓库?这些代码仓库之间如何交互?apimachinery 仓库中还有 api、apis 两个包,里面定义了各种复杂的接口与实现,清楚这些复杂接口对于扩展 kubernetes API 大有裨益。所以,这篇文章就重点关注 api 与 apimachinery 这两个仓库。
米开朗基杨
2021/04/02
1.2K0
Operator示例:通过Operator+CRD实现部署自动化
在上一篇通过Operator自动暴露集群内部服务中,遗留了一个问题:开发人员or业务上游是需要关注k8s内建资源,例如deployment如何定义,这和K8S自动化的目标背道而驰。 本篇文章将采用CRD(CustomResourceDefinition)来屏蔽底层K8S资源,让开发人员只需要按照我们制定的规则来定义CR即可。至于创建deployment,service,ingress等操作就可以交给Operator来完成,从而实现部署自动化。 而自动化就可以对接业务系统,使其实现业务价值。例如根据授权信息,创建租户购买的产品服务,当授权到期时,自动删除对应资源。
Yuyy
2024/01/22
7630
Operator示例:通过Operator+CRD实现部署自动化
图解K8s源码 - k8s核心数据结构
在上一章中阿巩和大家分享了k8s组件之一kube-apiserver,在我自己阅读代码时发现k8s整体结构复杂,而且由于参与的开发者众多代码结构不免有些混乱,我往往容易陷入到某个细节而无法从整体视角梳理流程。在查阅官网文档及相关书籍后,我决定换个思路,先理解k8s核心数据结构设计,这样能够在阅读源码时做到事半功倍。好的,日拱一卒,我们开始吧!
才浅Coding攻略
2022/12/12
1K0
图解K8s源码 - k8s核心数据结构
Kubernetes对象深入学习之二:细说schema.ObjectKind
程序员欣宸
2023/07/10
3390
Kubernetes对象深入学习之二:细说schema.ObjectKind
Controller Runtime 的四种使用姿势
随着云原生生态的不断发展,目前大多数基于 Kubernetes 的云原生技术,几乎都采用了 CRD + Controller 的模式。即使没有自定义 CRD,也会有需要 Controller 来检测自己感兴趣的资源,在其状态发生变更时,做一些业务所需工作。
CS实验室
2022/04/27
3K0
Controller Runtime 的四种使用姿势
Kubernetes对象深入学习之三:对象属性
程序员欣宸
2023/07/24
3010
Kubernetes对象深入学习之三:对象属性
kubebuilder实战之五:operator编码
欢迎访问我的GitHub 这里分类和汇总了欣宸的全部原创(含配套源码):https://github.com/zq2599/blog_demos 系列文章链接 kubebuilder实战之一:准备工作 kubebuilder实战之二:初次体验kubebuilder kubebuilder实战之三:基础知识速览 kubebuilder实战之四:operator需求说明和设计 kubebuilder实战之五:operator编码 kubebuilder实战之六:构建部署运行 kubebuilder实战之七
程序员欣宸
2022/05/06
5310
kubebuilder实战之五:operator编码
kubebuilder实战之四:operator需求说明和设计
Spec是用来保存用户的期望值的,也就是小欣手里的三个参数(docker镜像、单个pod的QPS、总QPS),再加上端口号:
程序员欣宸
2022/05/06
4850
kubebuilder实战之四:operator需求说明和设计
使用code-generator创建crd controller
在 pkg/apis/{GROUP}/{VERSION}/types.go中使用,使用 // +genclient标记对应类型生成的客户端, 如果与该类型相关联的资源不是命名空间范围的(例如PersistentVolume), 则还需要附加 // + genclient:nonNamespaced标记,
有点技术
2020/07/13
3.5K0
k8s自定义controller三部曲之二:自动生成代码
本文是《k8s自定义controller三部曲》的第二篇,上一篇我们在k8s环境注册了API对象Student,此时如果创建Student对象就会在etcd保存该对象信息;
程序员欣宸
2019/05/29
1.3K0
k8s自定义controller三部曲之二:自动生成代码
mac 上学习k8s系列(20)CRD (part II)
Kubernetes目前常使用CRD+Controller的方式扩展API,官方提供了CRD代码的自动生成器code-generator。
golangLeetcode
2022/08/02
7500
mac 上学习k8s系列(22)rbac 源码学习(part II)
kubernetes中角色分为Role和ClusterRole,Role是namespace级别的,ClusterRole是集群级别的。回想下mac 上学习k8s系列(17)rbac 源码学习(part I)中的类图:
golangLeetcode
2022/08/02
3350
mac 上学习k8s系列(22)rbac 源码学习(part II)
快速上手 K8S Operator
如果你想要对 K8S 做二次开发或者说在原有的基础上封装一些功能让开发者更加好用,那么 Operator 的用法你可必须掌握。
LinkinStar
2023/10/18
2.6K1
Operator3-设计一个operator
前置知识Operator-1初识Operator,Operator-2从pod开始简单operator。
对你无可奈何
2022/07/28
8100
【k8s开发必备技能】使用client-go包访问Kubernetes CRD
Kubernetes API服务器可通过自定义资源定义轻松扩展。但是,用client-go库访问这些资源有点麻烦,官方也没有完整的文档。如kubebuilder operator-framework都能很方便的帮助我们去创建实现一个controller,但是封装的过于好导致我们并不清楚内部是怎么调用client-go的,很多场景我们是需要自己去调用接口操作CRD的而不是在controller中去访问CRD。
sealyun
2019/09/18
6.7K0
【k8s开发必备技能】使用client-go包访问Kubernetes CRD
利用 CRD 实现一个 mini-k8s-proxy
实现一个可以通过配置 host 拦截到匹配的请求域名,将流量代理转发到具体的 service 中(通过配置 serviceName,namespace,port,scheme)的极简网络代理工具。其中,配置通过 CRD 创建,代理程序可以通过控制器监听配置变化,动态更新,无需重启。(PS:其实就是简单模拟了 Traefik IngressRoute 的实现)
gopher云原生
2021/10/18
6180
kubernetes-api-machinery
http server 或者 rpc server 要解决的一个问题是:如何解析用户的请求数据,并把他反序列化为语言中的一个具体的类型。反序列化的程序需要知道具体的类型(这在收到请求的时候就已经知道一些信息了,比如 用户访问的是 EchoService,那么请求肯定是 EchoRequest,不管是 EchoRequestV1,还是 EchoRequestV2), 同时反序列化程序即 decode 程序,还需要知道 他对应的语言里面的具体结构的信息,以便新建这个结构,填充数据,提交给上层处理。以一个 EchoService 为例,decode 程序需要从用户请求(如 post http://echo ) 文本或者二进制数据中创建出 EchoRequestV1,提供给上层处理,同时这个 decode 函数需要足够通用,他返回的是可能是一个 Message Interface, 里面是 EchoRequestV1,decode 相关的细节要么通过代码生成的技术提供给 decoder,要么在 二进制或者文本请求数据(或者 header等元数据)中携带这部分信息。
王磊-字节跳动
2019/10/12
4K0
Kubernetes CRD 自定义控制器
上文我们学习了如何使用 code-generator 来进行代码自动生成,通过代码自动生成可以帮我们自动生成 CRD 资源对象客户端访问的 ClientSet、Informer、Lister 等工具包,接下来我们来了解下如何编写一个自定义的控制器。
我是阳明
2020/10/26
2.3K0
Kubernetes CRD 自定义控制器
K8s源码分析(3)-Resource Version
在上一篇文章中我们主要介绍了 kubernetes 中的 resource meta,以及相关的定义,在这里我们主要介绍 kubernetes resource 的 version。众所周知,在 kubernetes 中所有的 resource 都是基于 group 分组的,例如 apps group 中定义了我们熟悉并常用的 deployment, statefullset, daemonset 等 resource,rbac group 中定义了我们经常用到的 role, role binding, clusterrole, clusterrolebinding 等等 resource。对于不同的 group 中的 resource 又有不同的 version,例如 apps group 中又分为 v1, v1beta1, v1beta2 等不同版本。所以在 kubernetes 中去定位一种 resource 我们就会需要 group (例如 apps), version (例如 v1),kind (例如 deployment),也就是我们常常说的 GVK,如下图例。
TA码字
2021/09/14
1.1K0
K8s源码分析(3)-Resource Version
相关推荐
K8s源码分析(4)-Resource Model
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验