kubernetes源码剖析读后感(三)

注:结合书中的大概内容以及笔者自身的k8s经验 总结学到的一些新知识每一篇篇幅不会很长
书很棒强烈推荐买一本读

本次读书来自于《kubernetes源码剖析》 作者郑东旭

总结中包含部分书中内容 包含部分笔者读书学习到的知识点以及根据笔者结合书的一些总结

第三章 kubernetes核心数据结构

1.Group Version Resource核心数据结构
Group:资源组 也可以称之为APIGroup
Version:资源版本 也可以称之为APIVersion
Resource: 资源 也可以称之为APIResource
Kind:资源种类与Resource同一级别
熟悉k8s的都了解 k8s支持多个Group,Group又支持多个Version,每一个Version又支持多个Resource
Resouce
在这里插入图片描述
Version
在这里插入图片描述
Resouce完整表现形式为<GROUP>/<VERSION>/<RESOURCE>/<SUBRESOURCE> 比如deployment apps/v1/deployment/status
每一个资源都拥有一定数量的操作方法即Verbs 资源操作方法用于etcd中存储对资源的增删改查操作,目前k8s支持8中操作分别是create、delete、deletecollection、get、list、patch、update、watch
每一个资源都至少有两个版本分别是外部版本(External Version)和内部版本(Internal Version)外部版本用于对外暴露给用户请求的接口所使用的资源对象,而内部版本不对外暴露尽在内部使用

资源版本跟资源内外部版本概念是不同的

k8s资源也可以分为两种Kubernetes Resource内置资源和Custom Resource(自定义资源简称CR)。通过CRD即Custom Resource Definitis 可以实现自定义资源 可以把自定义资源提交至k8s系统中并且像内置资源一样使用
2.ResourceList

GroupVersionResource(GVR) 描述资源组 资源版本 资源
GroupVersion(GV) 描述资源组 资源版本
GroupResource(GR) 描述资源组 资源
GroupVersionKind(GVK) 描述资源组 资源版本 资源种类
GroupVersions(GVS) 描述资源组内多个资源版本
GroupKind(GK) 描述资源组 资源种类

3.Group

  • 按照不同功能做了api的组别划分 允许单独开启/禁用资源组 以及单独开启/禁用资源组的中的资源
  • 支持同资源组拥有不同的资源版本,方便组内资源根据版本迭代升级
  • 支持同名的资源种类kind存在于不同的资源组内
  • 资源组与资源版本通过api对外暴露允许开发者通过http协议进行交互并通过动态客户端即(DynamicClient第五章client-go会说到)进行资源发现
  • 支持CRD自定义资源扩展
  • 用户交互简单kubectl可以不写资源组名称

4.Version
版本分为3中Alpha、Beta、Stable
迭代的顺序为Alpha->Beta->Stable
Alpha 测试版本 存在缺陷跟漏洞 会被随时放弃 一般为v1alph1、v1alph2
Beta相对稳定的版本 在迭代中可能被更改但不会被删除v1beta1
Stable正式发布的版本,默认全部开启,例如v1 v2
5.Resource
所有资源对象都是Entity(实体)k8s使用Entity表示当前状态,可以通过api对每一个资源对象查询和更新,目前支持2中Entity
持久性实体(Persistent Entity) 如deployment创建后持久地保持存在
短暂性实体(Ephemeral Entity)如pod创建后因为某些原因不会被再分配

type APIResource struct {
	Name string  //资源名称
	SingularName string  //资源单数名称例如pod单数为pod复数为pods
	Namespaced bool //是否拥有ns
	Group string  //资源所在资源组
	Version string //资源所在资源版本
	Kind string //资源种类
	Verbs Verbs//资源操作方法列表
	ShotNames []string  //资源简称例如pod  po  
	...
}

6.内置资源全图(图太大非常全)可以考虑买本书看看
7.runtime.Object
runtime.Object作为资源的通用对象被设计为interface接口类型
提供了2个方法
(1)GetObjectKind 用于设置并返回GVK
(2)DeepCopyObject用于深复制当前对象并返回
那么如何证明它可以转换为runtime.Object这种通用对象呢,那么我们只需要判断是否实现了上述2个接口则可以判断
8.Unstructured数据
数据可以分为结构化数据(Structured Data)和非结构化数据(Unstructured Data)
结构话数据就比如一个json

{
	"id":1,
	"name":2
}

我们要通过这个json来转换为struct那么我们需要定义

type User struct {
	id int
	name int
}

但是如果我们都不知道json里面有什么样的格式 我们如何让他来解析 这就是非结构化数据
client-go的DynamicClient实现了Unstructured类型第五章会介绍到

9.Scheme资源注册表
就比如win安装一些软件会添加注册表 k8s同理
每一种资源一个资源类型要有统一的注册 存储 查询管理等机制,目前的话就是注册到了scheme资源注册表中 是一个内存性的资源注册表具备了

  • 支持注册多种资源类型,包括内部外部版本
  • 支持多种版本转换机制
  • 支持不同资源的序列化反序列化机制

10.Codec编解码器
虽然在运维或者其他操作k8s过程我们实在写yaml 但是提交给api的时候是转换为json的 那么codec这里就提供了yaml跟json以及等等的编解码工具
11.Converter资源版本转换器
这里主要是提供了版本转换
就比如1.16版本之前的k8s deployment会有v1 v1beta1
那么我们就可以吧deployment 从v1退化到v1beta1 或者从v1beta1转换为v1
他其中是有一个内部版本在作为转换的中介的
简单介绍
在这里插入图片描述
他的外部版本v1跟v1beta1都公用了一个相同的内部版本 在转换的过程中我们需要判断是否转换前的版本跟转换后的版本共用了同一个内部版本,以及不同版本某些字段会有差异,就比如v1beta1 转换为v1 那么v1有些字段是必备的,v1beta1却没有要求那么就需要加上这些必备字段,这样我们可以做版本转换,个人看法是如果做k8s升级的时候比如我们从1.15升级1.16会发现1.16的k8s 的deployment,没有了v1beta1 而且v1需要加一些字段,我们就可以使用这种方法做版本间的转换

第三章整体的感觉是在资源资源组之间的关系,让我们更加深入的了解资源类型以及k8s的一些核心的数据结构,为了后面更加方便地使用client-go来交互的操作k8s亦或者我们自己开发crd的时候也需要了解这些知识,总而言之书非常棒,个人看法,就算对go可能了解不多但是你工作中用到了k8s以及你对k8s也有了一定的了解程度,那么此书还是要读以下的最后再次附一张书图

在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/weixin_45413603/article/details/107170116