kubernetes三大核心数据结构.pdf
免费下载
深入 Kubernetes 内核：三大核心数据结构解密（系列开篇）
当我们执行
kubectl get pods
时，可曾想过这条简单的命令背后，
Kubernetes
是如何精准识别并管理数百种资源类型的？答案就藏在它的三大核心数据结构
中。
kubectl get pods
流程图如下：
从图中得知：
1. GVR
是访问路径：
kubectl
将命令转换基为
GVR
的
REST API
请求。
2. GVK 是内部标识：API Server 需将 GVR 映射为 GVK，以找到正确的资源定
义（
Schema
）来处理请求。
3. 数据持久化：最终操作的是存储在 ETCD 中的资源对象数据。
4.
控制器模式：控制器通过
Watch
特定的
GVR
的端点来监听资源变化，并驱
动系统向期望状态改变。
在云原生日常使用中，我们经常看到这样的配置：
apiVersion: apps/v1
kind: Deployment
但你是否真正理解：
1) apps/v1 背后的 Group 和 Version 设计哲学？
2) Deployment
作为
Resource
在
API
层是如何被描述的？
3) 为什么需要内外版本？
本系列将带你深入
Kubernetes API Machinery
的核心，从
Group,Version,Resource 这三大基石出发，逐步解开 Kubernetes 资源管理体系的
神秘面纱。
如图：
1) 层次结构：展示了 Group->Version->Resource 的从属关系
2) 多版本共存：如 apps 组下同时存在 v1 和 v2beta1 版本，体现了 API 的演进和能力。
3) 核心组： 想 Pod 这样的核心资源位于没有组名的核心组
4) 内部版本：所有外部版本在 API Server 内部都会转换成统一的内部版本进行处理，实现了
多版本兼容和稳定。
Kubernetes 三大核心数据结构组成
1) Group
：被称为资源组，在
kubernetes API Server
中也可以称其为
APIGroup
。
2) Version：被称为资源版本，在 kubernetes API Server 中也可称其为 APIVersions。
3) Resource
：被称为资源，在
kubernetes API Server
中也可称其为
APIResource
。
4) Kind：资源种类，描述 Resource 的种类，与 Resource 为同一级别。
kubernetes
系统支持多个
Group
，每个
Group
支持多个
Version
，每个
Version
支持多个 Ressource，其中部分资源同时会拥有自己的子资源（即 SubResource）。
例如
Deployment
资源拥有
Status
子资源。如下图：
of 5
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论