Kubernetes：API组和资源，它们有什么关系？

Question

当应用程序需要调用事件API来获取其集群的所有事件时，作为程序员我可能会定义这样的角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["events"]
  verbs: ["list"]

让我感到困惑的是apiGroups，我可以使用“events.k8s.io”，或者简单地使用“”，或者“events.k8s.io”和“”两者......

这个 apiGroups 是什么东西？我尝试阅读官方文档，但我发现的是：

API groups make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the apiVersion field of a serialized object.

There are several API groups in Kubernetes:

The core (also called legacy) group is found at REST path /api/v1. The core group is not specified as part of the apiVersion field, for example, apiVersion: v1.

The named groups are at REST path /apis/$GROUP_NAME/$VERSION and use apiVersion: $GROUP_NAME/$VERSION (for example, apiVersion: batch/v1). You can find the full list of supported API groups in the Kubernetes API reference.

这并不能帮助我理解它......为什么有命名组和核心组，为什么我可以一起使用“”和“events.k8s.io”？

如果我的资源是events，为什么我需要明确告诉K8s有一个名为“events.k8s.io”的API组，就好像events“events.k8s.io”中和events资源中是两个不同的东西......这个问题困扰我好几天了

Answer 1

为什么有命名组和核心组

原因是历史性的。Kubernetes 首先将某些资源视为核心组的一部分，也就是说 Kubernetes 的核心就是由这些资源构成的（核心组中的资源包括 Pod、Event）。

命名 API 组（或命名空间）（例如events.k8s.io）的目的是按主题对资源进行分组。您将拥有networking.k8s.io与网络相关的资源。
“核心”资源被认为是 Kubernetes 不可或缺的一部分，以至于它们不需要组（我正在简化）。

为什么我可以一起使用“”和“events.k8s.io”？

如果我的资源是事件，为什么我需要明确告诉 K8s 有一个名为“events.k8s.io”的 API 组，就好像“events.k8s.io”中的事件和资源中的事件是两个不同的东西一样。 。

API 并不完全相同。在API 参考中，您可以看到在 中您可以看到一些以which areevents.k8s.io开头的字段。因此，根据您使用的端点，API 语义并不完全相同（但 Kubernetes 具有从一个版本转换为另一个版本的机制）。由于某些工具可能依赖于核心版本并且尚未迁移到，因此两者都需要存在。deprecateddeprecated field(s) assuring backward compatibility with core.v1 Event typev1events.k8s.io/v1

还有其他类似的“群体迁移”，特别是从该extensions群体到其他群体（Ingress迁移到networking.k8s.io、Deployment到apps）