Kubernetes 之GVR与GVK详解

本文尝试从GVR与GVK对比、常见的GVR和GVK操作、GVK设计精髓、CRD工作流程等方面对GVK和GVR进行详细分析。希望对您有用！

一、Kubernetes 之GVR与GVK对比

在 Kubernetes 中，GVR 和 GVK 是两个重要的概念，用于唯一标识和操作不同的资源类型和实例。以下是它们的特点简介以及各自的应用场景。

GroupVersionResource (GVR)

特点简介

• Group：API 组的名称。例如，apps 组包含 Deployment 资源，batch 组包含 Job 资源。核心组的资源（如 Pod、Service 等）没有组名，默认使用空字符串。
• Version：资源的版本，例如 v1、v1beta1 等。
• Resource：资源的名称，通常是复数形式。例如，Pods 的资源名称是 pods，Deployments 的资源名称是 deployments。

GVR 用于唯一标识 Kubernetes 中的某种资源类型，特别是在动态客户端和操作工具中，以便精确指定和访问资源。

应用场景

1. 动态客户端操作：

   • 使用 GVR 在动态客户端中进行 CRUD（创建、读取、更新、删除）操作。

   • 例如，通过动态客户端获取一个特定命名空间中的所有 Deployments：

     gvr := schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}
     deployments, err := dynamicClient.Resource(gvr).Namespace("default").List(context.TODO(), metav1.ListOptions{})
     

2. 资源操作工具：

   • 使用 GVR 开发操作 Kubernetes 资源的工具，例如 kubectl 插件。

   • 例如，开发一个工具，列出所有命名空间中的 Pods：

     kubectl get pods.v1.
     

GroupVersionKind (GVK)

特点简介

• Group：API 组的名称。例如，apps 组包含 Deployment 资源，batch 组包含 Job 资源。核心组的资源（如 Pod、Service 等）没有组名，默认使用空字符串。
• Version：资源的版本，例如 v1、v1beta1 等。
• Kind：资源的种类，通常是单数形式。例如，Pod、Deployment、Service 等。

GVK 用于唯一标识 Kubernetes 中的某种资源类型，特别是在描述资源的元数据和处理特定类型的资源时使用。

应用场景

1. 资源定义和描述：

   • 使用 GVK 在代码中定义和描述特定类型的资源。例如，定义一个 Unstructured 对象并设置其 GVK：

     gvk := schema.GroupVersionKind{Group: "apps", Version: "v1", Kind: "Deployment"}
     unstructuredObj := &unstructured.Unstructured{}
     unstructuredObj.SetGroupVersionKind(gvk)
     

2. 资源转换和处理：

   • 使用 GVK 在不同版本的 API 之间进行资源转换和处理。

   • 例如，在控制器或操作器中，根据资源的 GVK 进行特定处理：

     switch gvk.Kind {
     case "Deployment":
         // 处理 Deployment 资源
     case "Pod":
         // 处理 Pod 资源
     }
     

3. 元数据操作：

   • 使用 GVK 操作资源的元数据，例如通过 GVK 获取资源的 schema 或进行元数据验证。
   • 例如，在 API 服务器中根据 GVK 获取资源的 OpenAPI schema 进行验证。

总结

• GVR 更侧重于资源的实际操作，特别是动态客户端和工具中使用，用于指定和操作特定类型的资源实例。
• GVK 更侧重于资源的定义和描述，特别是在控制器、操作器以及元数据操作中使用，用于唯一标识和处理特定类型的资源。

理解 GVR 和 GVK 的区别和应用场景，有助于在开发 Kubernetes 应用和工具时更有效地操作和处理不同类型的资源。

二、常见GVR操作

在 Kubernetes 中，GroupVersionResource（GVR）操作涉及对特定资源实例的创建、读取、更新和删除（CRUD）操作。以下是一些常见的 GVR 操作示例，以及如何使用这些操作管理 Kubernetes 资源。

常见的 GVR 操作

1. 创建资源（Create）
2. 读取资源（Read）
3. 更新资源（Update）
4. 删除资源（Delete）
5. 列出资源（List）

使用 Kubernetes 动态客户端进行 GVR 操作

以下示例使用 Kubernetes 动态客户端（dynamic.Interface）进行 GVR 操作。

导入必要的包

import (
    "context"
    "fmt"
    "k8s.io/client-go/dynamic"
    "k8s.io/client-go/kubernetes"
    "k8s.io/client-go/rest"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/apimachinery/pkg/runtime/schema"
    "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
)

创建 Kubernetes 客户端

// 创建动态客户端
config, err := rest.InClusterConfig()
if err != nil {
    panic(err.Error())
}
dynamicClient, err := dynamic.NewForConfig(config)
if err != nil {
    panic(err.Error())
}

定义 GVR

gvr := schema.GroupVersionResource{Group: "apps", Version: "v1", Resource: "deployments"}
namespace := "default"

1. 创建资源

deployment := &unstructured.Unstructured{
    Object: map[string]interface{}{
        "apiVersion": "apps/v1",
        "kind":       "Deployment",
        "metadata": map[string]interface{}{
            "name": "my-deployment",
        },
        "spec": map[string]interface{}{
            "replicas": 1,
            "selector": map[string]interface{}{
                "matchLabels": map[string]interface{}{
                    "app": "nginx",
                },
            },
            "template": map[string]interface{}{
                "metadata": map[string]interface{}{
                    "labels": map[string]interface{}{
                        "app": "nginx",
                    },
                },
                "spec": map[string]interface{}{
                    "containers": []interface{}{
                        map[string]interface{}{
                            "name":  "nginx",
                            "image": "nginx:1.14.2",
                        },
                    },
                },
            },
        },
    },
}

result, err := dynamicClient.Resource(gvr).Namespace(namespace).Create(context.TODO(), deployment, metav1.CreateOptions{})
if err != nil {
    panic(err.Error())
}
fmt.Printf("Created deployment %q.\n", result.GetName())

2. 读取资源

result, err := dynamicClient.Resource(gvr).Namespace(namespace).Get(context.TODO(), "my-deployment", metav1.GetOptions{})
if err != nil {
    panic(err.Error())
}
fmt.Printf("Found deployment %q.\n", result.GetName())

3. 更新资源

// 获取现有 Deployment
deployment, err := dynamicClient.Resource(gvr).Namespace(namespace).Get(context.TODO(), "my-deployment", metav1.GetOptions{})
if err != nil {
    panic(err.Error())
}

// 修改 Deployment 的副本数量
unstructured.SetNestedField(deployment.Object, int64(2), "spec", "replicas")

updatedDeployment, err := dynamicClient.Resource(gvr).Namespace(namespace).Update(context.TODO(), deployment, metav1.UpdateOptions{})
if err != nil {
    panic(err.Error())
}
fmt.Printf("Updated deployment %q.\n", updatedDeployment.GetName())

4. 删除资源

err = dynamicClient.Resource(gvr).Namespace(namespace).Delete(context.TODO(), "my-deployment", metav1.DeleteOptions{})
if err != nil {
    panic(err.Error())
}
fmt.Println("Deleted deployment.")

5. 列出资源

list, err := dynamicClient.Resource(gvr).Namespace(namespace).List(context.TODO(), metav1.ListOptions{})
if err != nil {
    panic(err.Error())
}
for _, d := range list.Items {
    fmt.Printf(" * %s\n", d.GetName())
}

这些示例展示了如何使用 Kubernetes 动态客户端执行常见的 GVR 操作。这些操作允许开发人员以编程方式管理 Kubernetes 集群中的资源，提供了高度的灵活性和自动化能力。

三、常见GVK操作

在 Kubernetes 中，GroupVersionKind（GVK）操作主要涉及对资源类型的定义、描述和处理。以下是一些常见的 GVK 操作示例，以及如何使用这些操作管理和操作 Kubernetes 资源类型。

常见的 GVK 操作

1. 定义和描述资源类型
2. 处理特定资源类型
3. 资源类型的转换
4. 控制器和操作器中处理资源
5. 验证和元数据操作

使用 Kubernetes 动态客户端和 Unstructured 对象进行 GVK 操作

以下示例使用 Kubernetes 动态客户端（dynamic.Interface）和 Unstructured 对象进行 GVK 操作。

导入必要的包

import (
    "context"
    "fmt"
    "k8s.io/client-go/dynamic"
    "k8s.io/client-go/kubernetes"
    "k8s.io/client-go/rest"
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
    "k8s.io/apimachinery/pkg/runtime/schema"
    "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
)

创建 Kubernetes 客户端

// 创建动态客户端
config, err := rest.InClusterConfig()
if err != nil {
    panic(err.Error())
}
dynamicClient, err := dynamic.NewForConfig(config)
if err != nil {
    panic(err.Error())
}

定义 GVK

gvk := schema.GroupVersionKind{Group: "apps", Version: "v1", Kind: "Deployment"}
namespace := "default"

1. 定义和描述资源类型

使用 GVK 定义一个 Unstructured 对象，并设置其 GVK。

deployment := &unstructured.Unstructured{
    Object: map[string]interface{}{
        "apiVersion": "apps/v1",
        "kind":       "Deployment",
        "metadata": map[string]interface{}{
            "name": "my-deployment",
        },
        "spec": map[string]interface{}{
            "replicas": 1,
            "selector": map[string]interface{}{
                "matchLabels": map[string]interface{}{
                    "app": "nginx",
                },
            },
            "template": map[string]interface{}{
                "metadata": map[string]interface{}{
                    "labels": map[string]interface{}{
                        "app": "nginx",
                    },
                },
                "spec": map[string]interface{}{
                    "containers": []interface{}{
                        map[string]interface{}{
                            "name":  "nginx",
                            "image": "nginx:1.14.2",
                        },
                    },
                },
            },
        },
    },
}
deployment.SetGroupVersionKind(gvk)

2. 处理特定资源类型

在控制器或操作器中，根据 GVK 进行特定处理。

switch gvk.Kind {
case "Deployment":
    fmt.Println("Handling Deployment resource")
    // 处理 Deployment 资源
case "Pod":
    fmt.Println("Handling Pod resource")
    // 处理 Pod 资源
}

3. 资源类型的转换

在不同版本的 API 之间进行资源转换。

oldGVK := schema.GroupVersionKind{Group: "apps", Version: "v1beta1", Kind: "Deployment"}
newGVK := schema.GroupVersionKind{Group: "apps", Version: "v1", Kind: "Deployment"}

deployment.SetGroupVersionKind(oldGVK)
// 转换逻辑
deployment.SetGroupVersionKind(newGVK)

4. 控制器和操作器中处理资源

在控制器中，使用 GVK 来处理特定类型的资源。

func handleResource(obj *unstructured.Unstructured) {
    gvk := obj.GroupVersionKind()
    switch gvk.Kind {
    case "Deployment":
        // 处理 Deployment 资源
    case "Pod":
        // 处理 Pod 资源
    }
}

5. 验证和元数据操作

使用 GVK 操作资源的元数据，例如通过 GVK 获取资源的 schema 或进行元数据验证。

func validateResource(gvk schema.GroupVersionKind, obj *unstructured.Unstructured) error {
    // 验证逻辑
    return nil
}

if err := validateResource(gvk, deployment); err != nil {
    fmt.Printf("Validation failed: %v\n", err)
} else {
    fmt.Println("Validation succeeded")
}

这些示例展示了如何使用 Kubernetes 动态客户端和 Unstructured 对象执行常见的 GVK 操作。这些操作允许开发人员以编程方式管理和操作 Kubernetes 中的资源类型，提供了高度的灵活性和自动化能力。

四、GVK设计精髓

设计精髓的 GVK（GroupVersionKind）在 Kubernetes 中主要体现在以下几个方面：

1. 唯一标识性：

   • Group：定义了资源所属的 API 组，例如 apps、batch 等。
   • Version：指定了资源的 API 版本，例如 v1、v1beta1 等。
   • Kind：描述了资源的种类，例如 Deployment、Pod、Service 等。

   GVK 的组合唯一确定了 Kubernetes 中的每一种资源类型，确保了资源在 API 中的唯一性和可识别性。

2. 代码和配置的一致性：

   • GVK 在 Kubernetes 中被广泛用于描述资源类型和处理资源对象。它在 Kubernetes API 对象的定义、客户端代码中的操作、控制器和操作器中的处理，以及 YAML 或 JSON 配置文件中的规范化表示中都有重要作用。
   • 这种一致性确保了在不同的开发和运维场景中，能够准确地理解和操作各种 Kubernetes 资源类型。

3. 版本控制和演进：

   • GVK 允许 Kubernetes API 对象进行版本控制和演进。通过定义不同的版本和 API 组，可以逐步引入新的特性和改进，同时保持对旧版本的兼容性和支持。
   • 这种设计允许 Kubernetes 在不同的发行版之间进行 API 的逐步演进，同时保持对现有用户和工具的兼容性。

4. 动态性和扩展性：

   • GVK 的设计使得 Kubernetes 能够支持动态扩展和自定义资源的添加。通过定义新的 API 组和版本，并指定新的 Kind，可以向 Kubernetes 集群中引入自定义的资源类型和控制器。
   • 这种灵活性允许 Kubernetes 在不断发展的应用场景中保持其可扩展性和适应性。

GVK 的设计精髓在于其清晰而灵活的资源标识和描述机制，通过组、版本和种类的结合，确保了 Kubernetes 在管理和操作资源时的一致性、可扩展性和版本控制能力。这种设计使得 Kubernetes 能够成为一个强大且灵活的容器编排平台，并支持广泛的应用场景和工作负载。

五、Kubernetes API组织结构

Kubernetes API 的组织结构可以通过 Mermaid 图表来表示其层次和关系。以下是一个简单的 Mermaid 图表示例，展示了 Kubernetes 中常见的 API 组、版本和资源类型的层次结构。

组织结构

解释说明

• API 组（API Groups）：每个 API 组都有相应的版本和资源类型。

  • Core API：包含核心的基础资源，如 Pod、Node、Service 等。
  • Apps API：包含应用管理相关的资源，如 Deployment、StatefulSet 等。
  • Batch API：包含批处理作业相关的资源，如 Job、CronJob 等。
  • Networking API：包含网络策略相关的资源，如 NetworkPolicy 等。
  • Storage API：包含存储管理相关的资源，如 StorageClass、PersistentVolumeClaim 等。
  • Authentication API：包含身份验证相关的资源，如 TokenReview 等。
  • Other API Groups：包含其他不同功能和扩展的 API 组，如 RBAC、Metrics 等。

• API 版本（API Versions）：每个 API 组可以有多个版本，每个版本定义了一组资源类型。

• 资源类型（Resources）：每个 API 版本定义了一组具体的资源类型，例如 Pod、Deployment 等，这些资源类型是 Kubernetes 中的基本构建块。

这种 Mermaid 图表可以帮助你更直观地理解 Kubernetes API 的组织结构，包括各 API 组、版本和资源类型之间的层次关系和依赖关系。

六、Kubernetes GVK历史演进

Kubernetes中的GVK代表Group-Version-Kind，是API对象的关键标识。它的历史演进可以简要总结如下：

1. 初始阶段：

   • Kubernetes最初版本中并没有GVK的概念。
   • 所有的API对象都是以单一的版本标识，例如 v1.Pod。

2. 引入Group和Version：

   • 随着Kubernetes的发展，引入了Group的概念，使得API对象可以根据其用途和领域进行组织。
   • 例如，apps/v1.Deployment中的 apps 是Group，v1 是Version，Deployment 是Kind。

3. 扩展机制的引入：

   • Kubernetes引入了自定义资源定义（Custom Resource Definitions，CRD），允许用户创建自己的自定义资源和控制器。
   • 这进一步推动了GVK的概念的扩展和普及，使得不同组织和项目可以定义和管理自己的API对象。

4. 演进和管理：

   • 随着Kubernetes的不断发展，GVK的管理和演进变得越来越重要。
   • 版本管理、兼容性和扩展性成为Kubernetes API设计的重要考虑因素，以支持各种工作负载和生态系统。

总体来说，GVK的演进反映了Kubernetes本身的发展，从最初的简单对象标识到支持复杂、多样化API对象和自定义资源的标准化和管理。

七、一种特殊的GVK–CRD

CRD（Custom Resource Definition）可以被看作是一种特殊的 Group-Version-Kind（GVK）的实现。在 Kubernetes 中，所有的 API 对象都由 GVK 组成，它们用于唯一标识和管理不同类型的资源。

具体来说：

• Kind（类型）： 在 CRD 的上下文中，Kind 指的是自定义资源的类型，例如 MyCustomResource。

• Group（组）： CRD 定义的时候指定了 Group，这样可以把自定义资源与 Kubernetes 原生资源区分开来，例如 example.com。

• Version（版本）： CRD 可以支持多个版本，每个版本都有自己的 API 结构定义（Spec），例如 v1、v2 等。

因此，CRD 可以被视为一种特殊的 GVK，它定义了一种新的 API 对象类型，使得用户可以像操作 Kubernetes 内置资源一样，操作和管理自定义资源。

CRD（Custom Resource Definition）在Kubernetes中的应用场景非常广泛，并且提供了许多优势。以下是一些典型的应用场景和优势：

应用场景

1. 自定义业务逻辑：

   • 用户可以根据业务需求定义特定的资源类型，例如电商平台的订单(Order)、库存(Inventory)等。

2. 扩展 Kubernetes 功能：

   • 第三方提供的控制器（如运营商、服务网格）可以使用CRD来扩展Kubernetes的功能，例如定义自定义的负载均衡策略、服务发现等。

3. 简化配置管理：

   • 用户可以使用CRD来封装复杂的配置和管理操作，例如数据库的备份和恢复、CI/CD流水线的定义等。

4. 应用编排：

   • 使用CRD来定义和管理复杂的应用程序，例如微服务架构中的服务依赖关系、滚动更新策略等。

5. 事件驱动架构：

   • 定义自定义事件和触发器，基于CRD实现事件驱动的自动化工作流和操作。

优势

1. 增强的可扩展性：

   • CRD允许用户定义和管理任意类型的资源，极大地增强了Kubernetes的可扩展性，能够满足多样化的业务需求。

2. 一致性和标准化：

   • 自定义资源的定义和管理遵循Kubernetes的API标准，保证了一致性和标准化，易于学习和使用。

3. 自动化和自愈能力：

   • 通过自定义控制器（operator）和CRD，可以实现自动化的管理和自愈能力，例如自动扩展、重启失败的实例等。

4. 与Kubernetes原生功能无缝集成：

   • CRD完全融入Kubernetes生态系统，可以与其他Kubernetes原生资源（如Pod、Service、ConfigMap）无缝集成，利用现有的功能和工具。

5. 丰富的生态系统支持：

   • Kubernetes社区和第三方提供了丰富的CRD和operator，实现了各种功能和应用场景，例如数据库操作、监控和告警、服务网格等。

6. 灵活的版本管理：

   • CRD支持多版本管理，使得用户可以在不同的版本之间进行平滑升级和迁移，确保应用的稳定性和兼容性。

示例

例如，一个常见的应用场景是使用CRD和operator来管理数据库的生命周期：

• 定义CRD： 创建一个自定义资源类型 Database，包含数据库配置、备份策略等。
• 编写控制器： 编写一个operator，监听 Database 资源的变化，并根据定义的配置自动创建、更新和删除数据库实例。
• 应用和管理： 用户可以通过 kubectl 命令创建和管理 Database 资源，operator 会自动执行相应的操作。

这个场景展示了CRD和operator如何简化和自动化复杂的管理任务，同时保持与Kubernetes原生功能的良好集成。

八、CRD工作流程图

以下是一个描述CRD工作流程的Mermaid图表，展示了CRD从定义到应用的各个步骤：

在这个图表中：

• 用户首先定义CRD，然后将其应用到Kubernetes集群中。
• 接着，用户创建自定义资源实例，并编写相应的控制器逻辑。
• 用户部署控制器，控制器开始监听自定义资源的变化。
• 当检测到资源变化时，控制器执行相应的操作，完成自动化管理。

这个流程展示了CRD在Kubernetes中的工作机制，从定义到应用，以及控制器如何实现自动化管理。

完。
希望对您有用！关注锅总，及时获得更多花里胡哨的运维实用操作！

九、一个秘密

锅总个人博客

https://gentlewok.blog.csdn.net/

锅总微信公众号