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

Why there are named groups and core groups

原因是历史性的。 Kubernetes首先考虑的是一些资源属于一个核心组，也就是说Kubernetes的核心就是由这些资源构成的(核心组中的资源包括Pods、Events)。

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

why I can use "" and "events.k8s.io" together?

If my resource is events, why do I need to explicitly tell K8s that there is an API group named "events.k8s.io" as if the events in "events.k8s.io" and events in resources are two different things...

API 并不完全相同。在API reference你可以看到，在 events.k8s.io 中，你可以看到一些字段以 deprecated 开头，这是 deprecated 字段，确保与 core.v1 向后兼容事件类型。因此，根据您使用的端点，API 语义并不完全相同(但 Kubernetes 具有从一个版本转换为另一个版本的机制)。由于某些工具可能依赖于核心 v1 版本并且尚未迁移到 events.k8s.io/v1，因此两者都需要存在。

还有其他类似的“组迁移”，特别是从 extensions 组到其他组(Ingress 迁移到 networking.k8s.io, 部署到apps)