【k8s相关资源api操作】

长安归故里♬

已于 2024-02-29 09:41:50 修改

阅读量849

点赞数 29

文章标签： kubernetes 容器云原生

于 2024-02-26 23:45:00 首次发布

本文链接：https://blog.csdn.net/m0_55928120/article/details/136291515

版权

k8s相关资源api操作

api

Admissionregistration

MutatingWebhookConfiguration 是 Kubernetes 系统中的一种准入控制器机制的配置对象，它允许集群管理员定义自定义的 webhook 服务，这些 webhook 在 API 请求处理流程中的“准入控制”阶段被调用。具体来说，在 Kubernetes 集群中创建、更新或删除资源对象（如 Pod、Deployment 等）时，Mutating Admission Webhook 会在这些操作实际被执行并写入 etcd 存储之前有机会对请求体中的对象进行修改。
通过 MutatingWebhookConfiguration，你可以指定一组规则（rules），包括针对哪些 API 组（apiGroups）、资源类型（resources）和操作类型（operations）来触发 webhook 的调用。当 webhook 被触发时，Kubernetes 会向你在配置中提供的服务发送一个 HTTP POST 请求，并附带请求的详细信息。webhook 服务可以根据需要修改请求中的资源对象，并将修改后的对象返回给 Kubernetes，从而影响集群内部资源的实际状态。
例如，一个 Mutating Admission Webhook 可能用于自动注入 sidecar 容器到每个新建的 Pod 中，或者在 Pod 规范中添加默认的环境变量等。这种机制为 Kubernetes 提供了极大的灵活性和可扩展性，使得集群能够根据组织特定的安全策略、治理需求或最佳实践自动修改资源对象。
ValidatingWebhookConfiguration 是 Kubernetes 集群中另一种准入控制器机制的配置对象，它与 MutatingWebhookConfiguration 类似，但作用和目的不同。在 Kubernetes 的 API 请求处理流程中，Validating Admission Webhook 在 Mutating Admission Webhook 之后执行，并且主要负责对请求中的资源对象进行验证。
通过 ValidatingWebhookConfiguration，集群管理员可以定义一组自定义 webhook 服务，这些 webhook 会在 Kubernetes 资源对象（如 Pod、Deployment 等）创建、更新或删除操作实际被执行前对其进行校验。当一个 webhook 根据配置规则被触发时，Kubernetes 会向你指定的服务发送一个 HTTP POST 请求，包含待修改资源对象的详细信息。webhook 服务根据预定义的策略或业务逻辑对资源对象进行验证，并返回一个成功的响应（允许变更）或者一个错误响应（拒绝变更），从而防止不满足特定条件的资源对象被创建或修改。
例如，Validating Admission Webhook 可用于确保每个新建的 Pod 都遵循了组织的安全策略，比如检查容器镜像是否来自可信仓库，或者确保资源规格不超过预先设定的限制等。这种机制增强了集群的数据一致性，有助于保证集群内部资源始终符合特定的业务规则和安全要求。
对于校验配置的一些PolicyStatus、PolicyBinding、policy 来进行crud

Apiextension

CustomResourceDefinition（CRD）是 Kubernetes 中的一项核心功能，它允许用户扩展集群的 API 以支持自定义资源类型。在 Kubernetes 中，原生支持了一组标准资源对象（如 Deployment、Pod、Service 等），但通过 CRD，您可以根据自身业务需求创建新的资源类型，并且这些新类型的资源同样可以享受到与原生资源相似的生命周期管理能力。
CRD 的主要作用和特点包括：
扩展 API：用户可以通过创建 CustomResourceDefinition 来添加自己的 API 资源，这样就可以直接使用 kubectl 或者 Kubernetes API 与自定义资源进行交互。
自定义控制器：为了使自定义资源具有实际的功能，通常需要配合编写一个或多个自定义控制器（例如 Operator），这些控制器会监听自定义资源的变化，并执行相应的动作来满足资源定义中描述的状态期望。
集成 webhook：CRD 可以配置 admission webhook，包括 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration，以便在自定义资源的创建、更新过程中执行准入控制操作。
版本化和存储策略：CRD 支持定义不同的版本，可以在不同版本之间迁移，同时还可以指定自定义资源的数据序列化和存储方式。
定制元数据：自定义资源可以拥有自定义的字段和标签，从而更好地符合业务逻辑的需求。
总之，CustomResourceDefinition 是 Kubernetes 对于平台可扩展性的重要支持，使得 Kubernetes 不仅是一个容器编排系统，更是一个可以构建复杂应用生态系统的基础平台。
对于支持自定义资源类型的一些CustomResourceDefinition、CustomResourceDefinitionStatus 来进行crud

Apiregistration

APIService主要功能：扩展 Kubernetes 的 API 服务器的功能，允许将自定义资源（CRD）或第三方 API 注册到 Kubernetes 的核心 API 中，实现聚合API的功能。这意味着通过 APIService 可以将自定义资源或外部服务的行为与原生 Kubernetes API 集成在一起，从而让客户端能够像操作标准 Kubernetes 资源那样操作这些扩展资源。
作用范围：主要用于集群管理和 API 扩展层面，与 Service 不同的是，它并不直接涉及服务间或者服务与外部客户端之间的网络通信，而是针对 API 层面的统一管理和服务注册。 APIService 则更关注于扩展 Kubernetes 核心 API 的能力，以适应更多的自定义资源和外部 API 的集成需求。

AppsV1Api

AppsV1Api 是 Kubernetes 官方客户端库中的一个 API 类，它提供了与 Kubernetes 集群中 apps/v1 API 版本交互的方法和接口。这个 API 对象主要用于操作和管理 Kubernetes 中的应用程序资源，主要包括以下几种核心资源类型：
Deployment：用于定义、更新和回滚应用实例的副本集数量及配置。
DaemonSet：确保在每个节点上仅运行一个副本或者每个节点上都有一个副本的服务。
StatefulSet：用于有序部署和扩展有状态应用，例如数据库集群等需要持久存储和固定标识的应用实例。
ReplicaSet：是 Deployment 的内部实现机制，用来保证指定数量的 Pod 副本正常运行。
通过使用 AppsV1Api，开发者可以编写代码来创建、查询、更新和删除这些应用程序相关的 Kubernetes 资源对象，从而自动化或半自动化地管理 Kubernetes 集群中的应用生命周期。
ReplicaSet： 副本控制器
StatefulSet：管理有状态应用
DaemonSet：控制pod在node上的分布
ReplicationController (RC)：被替代产品ReplicaSet提供了更为灵活的标签选择器功能。ReplicationController同样可以确保集群中始终存在一定数量的相同Pod副本，但它不具备像Deployment那样的滚动更新策略。
对于一些Namespaced、StatefulSet、DaemonSet、Deployment、ReplicaSet、ReplicationController (RC)：被替代产品 来进行crud

AutoscalingV1Api

NamespacedHorizontalPodAutoscaler是 Kubernetes 中 HorizontalPodAutoscaler 资源在特定命名空间（Namespace）内的实例。每个 NamespacedHorizontalPodAutoscaler 都是针对其所在命名空间内某个工作负载（如 Deployment、StatefulSet 或 ReplicaSet）进行自动水平扩展或收缩的配置对象。
具体来说，当创建一个 NamespacedHorizontalPodAutoscaler 时，您需要指定以下关键信息：
目标资源类型和名称：通过 scaleTargetRef 字段指定要自动扩缩的目标工作负载。
命名空间：HPA 实例会作用于该命名空间下的目标资源。
最小副本数与最大副本数：设置 Pod 数量可以在什么范围内自动调整。
监控指标：可以基于 CPU 使用率、内存使用率或自定义度量指标来决定是否以及如何调整 Pod 数量。
NamespacedHorizontalPodAutoscaler 的主要功能是根据预设策略监控并动态调整目标工作负载中的 Pod 数量，以确保应用程序可以根据实际负载需求高效利用集群资源。
对于一些需要做监控管理的来实现自动水平最大化利用pod 来进行crud

BatchV1Api

BatchV1Api 是 Kubernetes API 中的一个接口，用于与 batch/v1 版本的批处理相关资源进行交互。这个版本的 API 主要提供了对批处理工作负载的支持，其中核心资源类型包括：
Jobs：
Jobs 是一次性任务，保证指定数量的任务 Pod 成功完成（即使在某些 Pod 失败的情况下）。当所有 Pods 都成功运行或者达到最大重试次数后，Job 将停止创建新的 Pods。
CronJobs：
CronJobs 是基于时间调度的工作负载，可以根据 Cron 表达式定期启动 Jobs。它主要用于执行周期性或定时任务。
通过 BatchV1Api，您可以实现以下操作：
创建、读取、更新和删除 Jobs 和 CronJobs。
查询 Job 或 CronJob 的状态以及相关的 Pods 状态。
控制 CronJob 的执行策略，如暂停、恢复和重置。
对于一些CronJob、Job 来进行crud

CertificatesApi 证书相关

CoordinationV1Api

NamespacedLease 是 Kubernetes API 中的一个操作，用于在特定命名空间下创建一个新的 Lease 资源对象。Lease API 通常用于实现分布式锁和 Leader 选举机制。
在 Kubernetes 中，Lease 资源类型主要用于服务或控制器声明对某个资源或状态的临时独占控制权，通过定期更新 Lease 对象来维持其有效性。例如，在多个副本的 StatefulSet 或 Deployment 控制器中，它们可以使用 Lease 来竞争成为主副本（Leader）并执行相应的管理任务。

最重要的`CoreV1Api` !!!

CoreV1Api 是 Kubernetes 官方客户端库中用于与 core/v1 版本的 Kubernetes API 进行交互的一个关键接口。这个版本的 API 包含了 Kubernetes 集群中最基础、最核心的一系列资源对象，包括但不限于：
1、Pods：
定义单个容器或一组容器及其运行时配置（如镜像、环境变量、命令、端口映射等）。
作为 Kubernetes 最小的可部署单元，Pods 是容器的直接运行载体。
2、Services：
提供一个稳定的网络标识符（DNS 名称）和负载均衡能力，将流量转发到后端关联的一组 Pods 上。
支持多种类型的访问策略，例如 ClusterIP（集群内部访问）、NodePort（通过节点端口暴露服务）、LoadBalancer（云提供商提供的负载均衡器）以及 ExternalName（DNS 映射）。
3、Nodes：
表示 Kubernetes 集群中的工作节点（worker nodes），即实际运行容器的物理机或虚拟机。
包含节点的状态信息（如条件、容量、分配给该节点的 Pod 等）。
4、Namespaces：
在逻辑上隔离不同的资源集合，方便项目或团队组织和管理各自的资源。
支持资源配额管理和权限控制。
PersistentVolumes (PV) 和 PersistentVolumeClaims (PVC)：
5、PV：由集群管理员提供，表示可供使用的持久化存储资源。
6、PVC：由用户创建，用于请求特定大小和访问模式的存储资源。PVC 可以绑定到已有的 PV 上，从而实现对持久化存储的动态供给和需求匹配。
7、ConfigMaps：
存储非敏感的应用配置数据，可以用来传递环境变量、挂载为卷文件或者注入到容器的启动命令中。
8、Secrets：
安全地存储敏感信息，如密码、密钥或其他认证凭据。
类似于 ConfigMap，但内容被加密且有更严格的访问控制。
9、Endpoints：
记录了 Kubernetes Service 后端 Pods 的 IP 地址和端口列表，是 Service 实际指向的具体目标地址集合。
10、Events：
记录集群内发生的各种事件信息，包括对象创建、更新、删除操作以及状态变化等。
有助于监控集群的健康状况并进行问题排查。

注意：CoreV1Api 和 AppsV1Api 都是 Kubernetes 官方客户端库中用于与不同 API 组和版本的资源进行交互的接口，它们的主要区别在于所管理资源类型的范围和功能：
CoreV1Api：
管理的是 Kubernetes 核心、基础级别的资源对象，这些资源通常涉及集群的基本操作和组件。
包含了如 Pod、Service、Node、Namespace、PersistentVolume、PersistentVolumeClaim、ConfigMap、Secrets、Endpoints 以及 Events 等核心资源类型。
这些资源类型对于运行容器化应用至关重要，但不包含高级的管理和部署抽象。
AppsV1Api：
主要关注于应用程序部署和生命周期管理相关的资源对象。
提供对 Deployment、DaemonSet、StatefulSet、ReplicaSet 等资源类型的创建、查询、更新和删除等操作支持。
这些资源类型提供了更高级别的抽象，旨在简化复杂的应用程序部署、升级、回滚和扩展等操作。
总结来说，CoreV1Api 更偏向于底层基础设施管理，而 AppsV1Api 则更多地关注于应用程序在 Kubernetes 上的全生命周期管理。

CustomObjectsApi

基于已定义的 CRD，用户可以在某个命名空间内创建实际的自定义对象实例，这些实例遵循 CRD 中定义的 schema，并可以通过 Kubernetes 的标准 CRUD 操作进行管理。
基于 CRD进行crud 操作

DiscoveryV1Api

NamespacedEndpointSlice
DiscoveryV1Api 是 Kubernetes 官方客户端库中用于集群发现（discovery）功能的一个 API 接口。它主要用于查询和获取 Kubernetes 集群中支持的 API 组、版本以及资源列表等信息，以便于客户端能够正确地与集群进行交互。
具体作用包括：
获取集群所有可用的 API 组及其版本。
查询特定 API 组下所有的资源类型及其详细信息，例如资源名称、类别（Kind）、可执行的操作（如 GET, POST, PUT, DELETE 等）以及每个资源类型的短名称和全名称。
通过这些信息，开发者可以了解到集群支持哪些自定义资源定义（CRDs）或其他核心资源，并据此编写符合集群规范的请求来操作或查询相应的资源对象。
总之，DiscoveryV1Api 对于开发自动化工具、Kubernetes 插件或者需要动态适应不同集群配置的应用程序来说非常重要，它提供了集群内部结构和能力的基础发现机制。

EventsV1Api

Kubernetes 中的 Event 是一种资源对象，用于记录集群中发生的事件信息，如 Pod 启动、停止、重启，或者某个资源的状态变化等。
每个 Event 都与一个具体的资源（如 Pod、Deployment 等）和对应的命名空间关联，也就是说，每个 Event 都是 namespaced 的，属于特定的命名空间。

FlowcontrolApiserverApi

FlowcontrolApiserver 是 Kubernetes 中用于实现API服务器流量控制（API Priority and Fairness，简称 APF）的组件。APF 是 Kubernetes 从 1.21 版本开始引入的一项功能，旨在提高 API 服务器在高负载场景下的稳定性和服务质量。
当集群中的请求量过大时，API Server 可能会因为处理不过来而导致响应延迟甚至拒绝服务。为了缓解这一问题，Kubernetes 引入了 APF，通过流量控制策略对不同优先级和来源的请求进行调度和公平分配资源，从而避免单个用户或客户端占用过多的 API 服务器资源，保证整体系统的稳定运行。
FlowcontrolApiserver 实现了 APF 功能的核心逻辑，它包含了一系列的配置选项和策略，可以用来设置不同的流控阈值、优先级队列以及配额管理等。通过启用 APF，Kubernetes 集群能够更好地应对突发流量压力，提供更加稳定的 API 服务。

InternalApiserver

用于集群内部服务间通信、协调工作流程或管理内部状态的 API 服务器。这类 API Server 主要服务于以下目的：
私有资源管理：处理不对外公开的自定义资源（Custom Resources），这些资源仅对集群内的某些服务或控制器开放。
内部组件交互：提供接口供集群内部的组件如控制器、调度器等进行通信，执行如状态同步、任务调度、监控数据上报等操作。
安全控制与隔离：通过创建内部 API 服务器，可以实现更细粒度的安全控制和权限隔离，确保只有经过授权的内部服务才能访问和修改关键资源。
性能优化：为了减轻主 API Server 的负载，也可以设置内部 API 服务器来处理一部分集群内部的高频请求，从而提升整个集群的性能和稳定性。

NetworkingV1

Networking API 版本
NetworkingV1 可能是指 Kubernetes 网络相关的 API 资源的 v1 版本。例如，在 Kubernetes 的网络策略（NetworkPolicy）资源中，有一个 networking.k8s.io/v1 API 组，其中定义了用于控制命名空间内 Pod 间网络通信规则的标准资源类型。这个版本是稳定版，提供了创建、更新和管理网络策略的能力。
CNI 插件或组件版本
在某些情况下，NetworkingV1 可能也指代某个容器网络接口（CNI, Container Network Interface）插件或其组件的特定版本。CNI 是一个标准化的接口，允许不同的网络解决方案与 Kubernetes 集成以提供 Pod 间的网络连接。一些 CNI 插件可能会有自己的版本编号体系，比如 Calico NetworkingV1 或类似的表述可能代表 Calico 网络插件的一个具体版本。
无论是哪种情况，请根据实际上下文理解 NetworkingV1 的含义。

NodeV1Api

node.k8s.io/v1/RuntimeClass：
用途：RuntimeClass 资源主要用来定义和选择容器运行时（如 runc、containerd、gVisor 等）的配置，允许用户在 Kubernetes 集群中为不同的 Pod 设置不同的容器运行时策略。通过这种方式，可以控制不同 Pod 的安全性和性能特性。
示例操作：例如，当您创建一个具有特定 runtimeClassName 字段的 Pod 时，Kubernetes 会根据这个字段找到对应的 RuntimeClass 对象，并使用其定义的容器运行时配置来启动 Pod 中的容器。

core API 组（通常是 v1 版本）：
用途：core API 组是 Kubernetes 中的核心 API 组，包含了一系列基础且重要的资源对象，比如 Node、Pod、Service、Namespace、ConfigMap、Secret、PersistentVolume、PersistentVolumeClaim 等等。这些资源用于描述集群的基本组件和功能。
示例操作：如创建/删除 Pod、管理节点状态、配置服务发现与负载均衡等。
总结来说，两者的主要区别在于它们所管理的资源类型和目的。node.k8s.io/v1/RuntimeClass 是针对容器运行时层面进行更细致管理和配置的资源，而 core API 组则涵盖了更多元化且基础的集群资源管理需求。

PolicyV1Api

制集群中 Pod 创建和运行时安全限制的特性

RbacAuthorizationV1Api

RbacAuthorizationV1Api 是用于操作基于角色的访问控制（Role-Based Access Control, RBAC）资源的 API 接口。在 Kubernetes 中，RBAC 是一种强大的授权机制，它允许管理员精细地管理集群内不同用户和组对各种资源的操作权限。
通过 RbacAuthorizationV1Api，您可以执行以下操作：
创建、读取、更新和删除不同的 RBAC 资源，例如：
ClusterRoles：定义了一组可以在集群范围内使用的权限集合。
Roles：与 ClusterRoles 类似，但仅限于特定命名空间内的资源。
ClusterRoleBindings：将 ClusterRoles 绑定到用户、组或服务账户，使得这些主体能继承所绑定 ClusterRole 的权限。
RoleBindings：类似于 ClusterRoleBindings，但作用范围限定在特定的命名空间内，使用这个 API 接口可以编写代码来动态创建和管理 Kubernetes 集群中的 RBAC 规则，确保只有具有适当权限的主体才能进行相应的操作。这对于大型组织或需要精细化权限管理的集群尤为重要。

ResourceV1alpha2Api

PodSchedulingContext 相关方法：用于创建、读取、更新、删除和列出 Pod 调度上下文资源。调度上下文可能包含了特定于 Pod 调度策略的相关信息。
ResourceClaim 和 ResourceClaimTemplate 相关方法：这两个资源类型看起来是自定义的扩展资源，用于表示对集群内某种资源（比如存储或计算能力）的声明和模板化管理。相关方法包括了它们在指定命名空间下的 CRUD 操作以及全集群范围内的列举操作。
ResourceClass 相关方法：这个资源类型可能代表了一组预定义的资源类别，例如不同的存储类或者计算资源等级。对应的方法用来进行 ResourceClass 的创建、读取、更新、删除及列举等操作。

SchedulingV1Api

createPriorityClass：通过 POST 请求创建新的 PriorityClass 对象，定义一个新的调度优先级策略。
deleteCollectionPriorityClass：发送 DELETE 请求批量删除多个 PriorityClass 对象。
deletePriorityClass：通过 DELETE 请求删除指定名称的单个 PriorityClass 对象。
getAPIResources：GET 请求，获取当前版本（v1）下的所有可用资源类型及其相应的 CRUD 方法列表。
listPriorityClass：GET 请求，列出集群中所有的 PriorityClass 对象。
patchPriorityClass：使用 PATCH 方法更新指定名称的 PriorityClass 对象的部分属性。
readPriorityClass：GET 请求，读取并返回指定名称的 PriorityClass 对象的详细信息。
replacePriorityClass：PUT 请求，替换整个指定名称的 PriorityClass 对象，即完全更新其内容。
这些接口提供了对 PriorityClass 资源进行全生命周期管理的能力，包括创建、读取、更新和删除等操作。调度器会参考这些优先级类来决定如何在节点之间分配和调度 Pod。

StorageV1Api

对于一些挂载的数据进场crud对pv pvc sc 以及外部存储做了一些操作
StorageClass：定义了持久卷（PersistentVolume）的动态供应策略。管理员可以创建多个 StorageClass 对象来提供不同性能、可用性和成本的存储选项，Pod 可以通过在其 PersistentVolumeClaim 中指定 StorageClass 来请求特定类型的存储。
VolumeAttachment：表示节点与持久卷之间的连接关系，主要用于外部或节点级别的存储设备。
StorageV1Api 提供了对 Kubernetes 存储相关的多个资源类型进行操作的方法，这些方法包括但不限于：
PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)：虽然 StorageV1Api 不直接管理 PV 和 PVC（如前所述），但它通过创建和管理 StorageClass 来间接影响它们。StorageClass 中的策略定义了动态持久卷供应的方式。
CSIDriver：与 Container Storage Interface (CSI) 驱动程序相关，用于注册 CSI 存储驱动到集群中，以支持使用 CSI 插件提供的外部存储系统。
CSINode：表示节点上注册的 CSI 驱动信息，包含关于该节点可用 CSI 驱动及其状态的详细内容。
CSIStorageCapacity：从 Kubernetes 1.21 版本开始引入，用于报告 CSI 卷插件在特定命名空间或整个集群中的存储容量情况。
StorageClass：用于定义如何动态地提供 PersistentVolumes 的策略，用户可以通过创建、读取、更新和删除 StorageClass 对象来管理存储策略。
VolumeAttachment：表示节点与外部存储设备之间的连接关系，允许 Kubernetes 管理员或者自动化流程管理节点级别的存储挂载。