Kubernetes 核心数据结构GVR - Group

系列文章目录

Kubernetes 核心数据结构GVR
Kubernetes 核心数据结构GVR - Version
Kubernetes 核心数据结构GVR - Resource

---

概述

Kubernetes 是一个完全以资源为中心的系统。其本质是一个资源控制系统，注册、管理、调度资源并维护资源的状态。

一、Group 是什么？

Kubernetes 将资源进行分组和版本化，形成了 Group（资源组）、Version（资源版本）、Resource（资源）。以下简称为 GVR。

Group：资源组，在 Kubernetes API Server 中也称其为 APIGroup。

二、APIGroup 数据结构

1.源码分析

github 地址

代码如下：

// APIGroup contains the name, the supported versions, and the preferred version
// of a group.
type APIGroup struct {
	TypeMeta `json:",inline"`
	// name is the name of the group.
	Name string `json:"name" protobuf:"bytes,1,opt,name=name"`
	// versions are the versions supported in this group.
	Versions []GroupVersionForDiscovery `json:"versions" protobuf:"bytes,2,rep,name=versions"`
	// preferredVersion is the version preferred by the API server, which
	// probably is the storage version.
	// +optional
	PreferredVersion GroupVersionForDiscovery `json:"preferredVersion,omitempty" protobuf:"bytes,3,opt,name=preferredVersion"`
	// a map of client CIDR to server address that is serving this group.
	// This is to help clients reach servers in the most network-efficient way possible.
	// Clients can use the appropriate server address as per the CIDR that they match.
	// In case of multiple matches, clients should use the longest matching CIDR.
	// The server returns only those CIDRs that it thinks that the client can match.
	// For example: the master will return an internal IP CIDR only, if the client reaches the server using an internal IP.
	// Server looks at X-Forwarded-For header or X-Real-Ip header or request.RemoteAddr (in that order) to get the client IP.
	// +optional
	ServerAddressByClientCIDRs []ServerAddressByClientCIDR `json:"serverAddressByClientCIDRs,omitempty" protobuf:"bytes,4,rep,name=serverAddressByClientCIDRs"`
}

资源组数据结构字段描述如下

• Name：资源组名称
• Versions：资源组下所支持的资源版本。
• PreferredVersion：首选版本。如果一个资源组内存在多个资源版本时，Kubernetes API Server 在使用资源时，会选择一个首选版本作为当前版本。

当前系统中，支持两类资源组，如下所示：

• 拥有组名的资源组：其表现形式为 $<$group$>$/$<$version$>$/$<$resource$>$，例如：apps/v1/deployments。
• 没有组名的资源组：被称为 Core Groups（即核心资源组）或 Legacy Groups，也可被称为 GroupLess（即无组）。其表现形式为 /$<$version$>$/$<$resource$>$，例如 /v1/pods。

两类资源组表现形式不同，形成的 HTTP PATH 路径也不同。

• 拥有组名的资源组的 HTTP PATH 以 /apis 为前缀，表现形式为 /apis/$<$group$>$/$<$version$>$/$<$resource$>$，例如：http://localhost:8080/apis/apps/v1/deployments。
• 没有组名的资源组的 HTTP PATH 以 /api 为前缀，表现形式为 /api/$<$version$>$/$<$resource$>$，例如：http://localhost:8080/api/v1/pods。

三、APIGroup 特点

Group 资源组，其特点如下：

• 将众多资源按照功能划分成不同的资源组，并允许单独启用/禁用资源组。当然也可以单独启用/禁用资源组中的资源。
  • 示例：资源组包括：apps/core/networking/extensions 等
• 支持不同资源组中拥有不同的资源版本。这方便组内的资源根据版本进行迭代升级。
  • 示例：资源版本包括：v1, v1beta2,v1beta1 等
• 支持同名的资源种类（即Kind）存在于不同的资源组内。
  • 示例：ingress 资源，在 k8s v1.16 版本之前存在于 extensions/v1beta1 中；在 k8s v1.16 版本之后也存在于 networking/v1 中。
• 资源组与资源版本通过 Kubernetes API Server 对外暴露，允许开发者通过HTTP协议进行交互并通过动态客户端（即DynamicClient）进行资源发现。
  • 示例：资源发现的四种方式：RESTClient/ClientSet/DynamicClient/DisconveryClient
• 支持 CRD 自定义资源扩展。
  • 示例：在 CRD 资源中，Group 可以自定义，比如：“apiextensions.k8s.io”。
• 用户交互简单，例如在使用kubectl命令行工具时，可以不填写资源组名称。
  • 示例：kubectl get deployments

四、实战练习

前提：你需要有一个正常运行的 Kubernetes 集群

// 查询 deployments
curl --cert ./client.pem --key ./client-key.pem --cacert ./ca.pem https://10.27.141.79:6443/apis/apps/v1/deployments

// 查询 pods
curl --cert ./client.pem --key ./client-key.pem --cacert ./ca.pem https://10.27.141.79:6443/api/v1/pods

注：关于 --cert --key --cacert 的设置，可以参考：如何利用curl命令访问Kubernetes API server

---

总结

本文介绍了 Kubernetes 核心数据结构GVR - Group 资源组的数据结构，列举了其特点，并举以示例加深了理解，最后给与了实战练习，让用户更好的理解 Group 的概念。

参考

• [1] Kubernetes 源码剖析
• [2] Kubernetes github 源码
• [3] 如何利用curl命令访问Kubernetes API server