API Groups

Como já falamos várias vezes, qualquer interação com o servidor é feita por meio de uma API que é gerenciada pelo kube-apiserver.

Para facilitar o estudo e não precisar ficar passando certificados diretamente toda vez que fazemos uma requisição direta ao kube-apiserver usando REST, vamos criar um proxy.

O comando inicia um servidor proxy local na porta 6443 que permite acessar o API Server do Kubernetes. Poderia ser qualquer porta, usei a mesma 6443 só saber que é a porta server. Dessa forma podemos ver tudo pelo navegador.

kubectl proxy --port=6443 &  
[1] 1735417
➜  files git:(main) ✗ Starting to serve on 127.0.0.1:6443

# Se não quiser passar a porta apenas faça o comando abaixo que ele já irá colocar na porta 8001
kubectl proxy

kubectl proxy não é a mesma coisa que kube-proxy. Kube-proxy é um componente do Kubernetes que gerencia os serviços. Nesse caso é apenas um comando que facilita a vida.

Vamos observar o que temos aqui.

curl http://127.0.0.1:6443  
{
  "paths": [
    "/.well-known/openid-configuration",
    "/api",
    "/api/v1",
    "/apis",
    "/apis/",
    "/apis/admissionregistration.k8s.io",
    "/apis/admissionregistration.k8s.io/v1",
    "/apis/apiextensions.k8s.io",
    "/apis/apiextensions.k8s.io/v1",
    "/apis/apiregistration.k8s.io",
    "/apis/apiregistration.k8s.io/v1",
    "/apis/apps",
    "/apis/apps/v1",
    "/apis/authentication.k8s.io",
    "/apis/authentication.k8s.io/v1",
    "/apis/authorization.k8s.io",
    "/apis/authorization.k8s.io/v1",
    "/apis/autoscaling",
    "/apis/autoscaling/v1",
    "/apis/autoscaling/v2",
    "/apis/batch",
    "/apis/batch/v1",
    "/apis/certificates.k8s.io",
    "/apis/certificates.k8s.io/v1",
    "/apis/coordination.k8s.io",
    "/apis/coordination.k8s.io/v1",
    "/apis/discovery.k8s.io",
    "/apis/discovery.k8s.io/v1",
    "/apis/events.k8s.io",
    "/apis/events.k8s.io/v1",
    "/apis/flowcontrol.apiserver.k8s.io",
    "/apis/flowcontrol.apiserver.k8s.io/v1",
    "/apis/flowcontrol.apiserver.k8s.io/v1beta3",
    "/apis/networking.k8s.io",
    "/apis/networking.k8s.io/v1",
    "/apis/node.k8s.io",
    "/apis/node.k8s.io/v1",
    "/apis/policy",
    "/apis/policy/v1",
    "/apis/rbac.authorization.k8s.io",
    "/apis/rbac.authorization.k8s.io/v1",
    "/apis/scheduling.k8s.io",
    "/apis/scheduling.k8s.io/v1",
    "/apis/storage.k8s.io",
    "/apis/storage.k8s.io/v1",
    "/healthz",
    "/healthz/autoregister-completion",
    "/healthz/etcd",
    "/healthz/log",
    "/healthz/ping",
    "/healthz/poststarthook/aggregator-reload-proxy-client-cert",
    "/healthz/poststarthook/apiservice-discovery-controller",
    "/healthz/poststarthook/apiservice-openapi-controller",
    "/healthz/poststarthook/apiservice-openapiv3-controller",
    "/healthz/poststarthook/apiservice-registration-controller",
    "/healthz/poststarthook/apiservice-status-available-controller",
    "/healthz/poststarthook/bootstrap-controller",
    "/healthz/poststarthook/crd-informer-synced",
    "/healthz/poststarthook/generic-apiserver-start-informers",
    "/healthz/poststarthook/kube-apiserver-autoregistration",
    "/healthz/poststarthook/priority-and-fairness-config-consumer",
    "/healthz/poststarthook/priority-and-fairness-config-producer",
    "/healthz/poststarthook/priority-and-fairness-filter",
    "/healthz/poststarthook/rbac/bootstrap-roles",
    "/healthz/poststarthook/scheduling/bootstrap-system-priority-classes",
    "/healthz/poststarthook/start-apiextensions-controllers",
    "/healthz/poststarthook/start-apiextensions-informers",
    "/healthz/poststarthook/start-cluster-authentication-info-controller",
    "/healthz/poststarthook/start-kube-aggregator-informers",
    "/healthz/poststarthook/start-kube-apiserver-admission-initializer",
    "/healthz/poststarthook/start-kube-apiserver-identity-lease-controller",
    "/healthz/poststarthook/start-kube-apiserver-identity-lease-garbage-collector",
    "/healthz/poststarthook/start-legacy-token-tracking-controller",
    "/healthz/poststarthook/start-service-ip-repair-controllers",
    "/healthz/poststarthook/start-system-namespaces-controller",
    "/healthz/poststarthook/storage-object-count-tracker-hook",
    "/livez",
    "/livez/autoregister-completion",
    "/livez/etcd",
    "/livez/log",
    "/livez/ping",
    "/livez/poststarthook/aggregator-reload-proxy-client-cert",
    "/livez/poststarthook/apiservice-discovery-controller",
    "/livez/poststarthook/apiservice-openapi-controller",
    "/livez/poststarthook/apiservice-openapiv3-controller",
    "/livez/poststarthook/apiservice-registration-controller",
    "/livez/poststarthook/apiservice-status-available-controller",
    "/livez/poststarthook/bootstrap-controller",
    "/livez/poststarthook/crd-informer-synced",
    "/livez/poststarthook/generic-apiserver-start-informers",
    "/livez/poststarthook/kube-apiserver-autoregistration",
    "/livez/poststarthook/priority-and-fairness-config-consumer",
    "/livez/poststarthook/priority-and-fairness-config-producer",
    "/livez/poststarthook/priority-and-fairness-filter",
    "/livez/poststarthook/rbac/bootstrap-roles",
    "/livez/poststarthook/scheduling/bootstrap-system-priority-classes",
    "/livez/poststarthook/start-apiextensions-controllers",
    "/livez/poststarthook/start-apiextensions-informers",
    "/livez/poststarthook/start-cluster-authentication-info-controller",
    "/livez/poststarthook/start-kube-aggregator-informers",
    "/livez/poststarthook/start-kube-apiserver-admission-initializer",
    "/livez/poststarthook/start-kube-apiserver-identity-lease-controller",
    "/livez/poststarthook/start-kube-apiserver-identity-lease-garbage-collector",
    "/livez/poststarthook/start-legacy-token-tracking-controller",
    "/livez/poststarthook/start-service-ip-repair-controllers",
    "/livez/poststarthook/start-system-namespaces-controller",
    "/livez/poststarthook/storage-object-count-tracker-hook",
    "/logs",
    "/metrics",
    "/metrics/slis",
    "/openapi/v2",
    "/openapi/v3",
    "/openapi/v3/",
    "/openid/v1/jwks",
    "/readyz",
    "/readyz/autoregister-completion",
    "/readyz/etcd",
    "/readyz/etcd-readiness",
    "/readyz/informer-sync",
    "/readyz/log",
    "/readyz/ping",
    "/readyz/poststarthook/aggregator-reload-proxy-client-cert",
    "/readyz/poststarthook/apiservice-discovery-controller",
    "/readyz/poststarthook/apiservice-openapi-controller",
    "/readyz/poststarthook/apiservice-openapiv3-controller",
    "/readyz/poststarthook/apiservice-registration-controller",
    "/readyz/poststarthook/apiservice-status-available-controller",
    "/readyz/poststarthook/bootstrap-controller",
    "/readyz/poststarthook/crd-informer-synced",
    "/readyz/poststarthook/generic-apiserver-start-informers",
    "/readyz/poststarthook/kube-apiserver-autoregistration",
    "/readyz/poststarthook/priority-and-fairness-config-consumer",
    "/readyz/poststarthook/priority-and-fairness-config-producer",
    "/readyz/poststarthook/priority-and-fairness-filter",
    "/readyz/poststarthook/rbac/bootstrap-roles",
    "/readyz/poststarthook/scheduling/bootstrap-system-priority-classes",
    "/readyz/poststarthook/start-apiextensions-controllers",
    "/readyz/poststarthook/start-apiextensions-informers",
    "/readyz/poststarthook/start-cluster-authentication-info-controller",
    "/readyz/poststarthook/start-kube-aggregator-informers",
    "/readyz/poststarthook/start-kube-apiserver-admission-initializer",
    "/readyz/poststarthook/start-kube-apiserver-identity-lease-controller",
    "/readyz/poststarthook/start-kube-apiserver-identity-lease-garbage-collector",
    "/readyz/poststarthook/start-legacy-token-tracking-controller",
    "/readyz/poststarthook/start-service-ip-repair-controllers",
    "/readyz/poststarthook/start-system-namespaces-controller",
    "/readyz/poststarthook/storage-object-count-tracker-hook",
    "/readyz/shutdown",
    "/version"
  ]
}

Analisando o primeiro nível temos um conjunto.

• /api : Core groups
• /apis : Named groups
• /healthz (deprecated) : Mesma coisa que o livez. Está obsoleto, está aqui por uma questão de retrocompatibilidade por enquanto.
• /livez : Usado para monitorar a saúde do cluster
• /logs : Usada para integrar com aplicações extração de log de terceiros
• /metrics : Usado para monitorar a saúde do cluster
• /openapi : Documentação
  • A especificação OpenAPI define uma interface legível por máquina para APIs RESTful, permitindo que os desenvolvedores entendam facilmente a estrutura e a funcionalidade das APIs disponíveis.
• /openid : Documentação
• /readyz : Usado para monitorar a saúde do cluster
• /version : Usado para identificar informações sobre a versão do cluster

livez e readyz apenas retornam ok que é um código 200 para cada um desses path. Eles têm propósitos diferentes.

Começando pelo mais simples o version.

/version

curl http://127.0.0.1:6443/version
{
  "major": "1",
  "minor": "29",
  "gitVersion": "v1.29.1",
  "gitCommit": "bc401b91f2782410b3fb3f9acf43a995c4de90d2",
  "gitTreeState": "clean",
  "buildDate": "2024-02-02T01:12:58Z",
  "goVersion": "go1.21.6",
  "compiler": "gc",
  "platform": "linux/amd64"
}

## E se eu quisesse ver no kubectl
kubectl get --raw /version  
{
  "major": "1",
  "minor": "29",
  "gitVersion": "v1.29.1",
  "gitCommit": "bc401b91f2782410b3fb3f9acf43a995c4de90d2",
  "gitTreeState": "clean",
  "buildDate": "2024-02-02T01:12:58Z",
  "goVersion": "go1.21.6",
  "compiler": "gc",
  "platform": "linux/amd64"
}

# Que seria a mesma coisa do comando
kubectl version -o yaml
clientVersion:
  buildDate: "2024-01-17T13:49:03Z"
  compiler: gc
  gitCommit: be3af46a4654bdf05b4838fe94e95ec8c165660c
  gitTreeState: clean
  gitVersion: v1.28.6
  goVersion: go1.20.13
  major: "1"
  minor: "28"
  platform: linux/amd64
kustomizeVersion: v5.0.4-0.20230601165947-6ce0bf390ce3
serverVersion:
  buildDate: "2024-02-02T01:12:58Z"
  compiler: gc
  gitCommit: bc401b91f2782410b3fb3f9acf43a995c4de90d2
  gitTreeState: clean
  gitVersion: v1.29.1
  goVersion: go1.21.6
  major: "1"
  minor: "29"
  platform: linux/amd64

/livez e /readyz

Uma rápida passada pelo livez que serve para verificar se o servidor está operacional e respondendo às solicitações.

O endpoint livez é a somatório do OK de todos os outros endpoints abaixo dele. Se algo estiver errado não estará OK.

kubectl get --raw='/livez'  
ok

# Se quiser uma saída mais verbosa com tudo que ele executou, como se fosse o log
kubectl get --raw='/livez?verbose'
[+]ping ok
[+]log ok
[+]etcd ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/priority-and-fairness-config-consumer ok
[+]poststarthook/priority-and-fairness-filter ok
[+]poststarthook/storage-object-count-tracker-hook ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/start-service-ip-repair-controllers ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/priority-and-fairness-config-producer ok
[+]poststarthook/start-system-namespaces-controller ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-apiserver-identity-lease-controller ok
[+]poststarthook/start-kube-apiserver-identity-lease-garbage-collector ok
[+]poststarthook/start-legacy-token-tracking-controller ok
[+]poststarthook/aggregator-reload-proxy-client-cert ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]poststarthook/apiservice-openapiv3-controller ok
[+]poststarthook/apiservice-discovery-controller ok
livez check passed

O readyz também serve para monitoramento mas com propósito verificar se o servidor Kubernetes está pronto para aceitar tráfego de aplicativos. O endpoint ready é a somatório do OK de todos os outros endpoints abaixo dele. Se algo estiver errado não estará OK.

kubectl get --raw='/readyz'
ok

kubectl get --raw='/readyz?verbose'
[+]ping ok
[+]log ok
[+]etcd ok
[+]etcd-readiness ok
[+]informer-sync ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/priority-and-fairness-config-consumer ok
[+]poststarthook/priority-and-fairness-filter ok
[+]poststarthook/storage-object-count-tracker-hook ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/start-service-ip-repair-controllers ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/priority-and-fairness-config-producer ok
[+]poststarthook/start-system-namespaces-controller ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-apiserver-identity-lease-controller ok
[+]poststarthook/start-kube-apiserver-identity-lease-garbage-collector ok
[+]poststarthook/start-legacy-token-tracking-controller ok
[+]poststarthook/aggregator-reload-proxy-client-cert ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]poststarthook/apiservice-openapiv3-controller ok
[+]poststarthook/apiservice-discovery-controller ok
[+]shutdown ok
readyz check passed

/openapi

Todos os endpoints em openapi possui um documento json que descreve as apis disponíveis juntamente com os detalhes sobre os paths, parâmetros, tipos de retorno e outras informações relevantes sobre cada endpoint.

O objetivo principal do endpoint /openapi é fornecer aos desenvolvedores uma descrição padronizada e automatizada das APIs disponíveis no cluster Kubernetes. Isso é especialmente útil ao construir ferramentas, clientes ou automações que interagem com o Kubernetes, pois permite uma integração mais fácil e robusta com as APIs do cluster.

---

Agora vamos pro conteúdo principal,

/api

Essa esse grupo contém todas as funcionalidades centrais, observe que o v1 tem tudo a ver com a o apiVersion que colocamos nos manifestos, sendo ele um subgroup de api

# Removi um pouco da saída colocando ... e deixando só os nomes. Somente em pods deixei para uma análise melhor
kubectl get --raw='/api/v1'
{
  "kind": "APIResourceList",
  "groupVersion": "v1",
  "resources": [
    {
      "name": "bindings",
       ...
    },
    {
      "name": "componentstatuses",
      ...
    },
    {
      "name": "configmaps",
      ...
      "storageVersionHash": "qFsyl6wFWjQ="
    },
    {
      "name": "endpoints",
      ...
    },
    {
      "name": "events",
      ...
    },
    {
      "name": "limitranges",
      ...
    },
    {
      "name": "namespaces",
      ...
    },
    {
      "name": "namespaces/finalize",
      ...
    },
    {
      "name": "namespaces/status",
      ...
    },
    {
      "name": "nodes",
      ...
    },
    {
      "name": "nodes/proxy",
      ...
    },
    {
      "name": "nodes/status",
      ...
    },
    {
      "name": "persistentvolumeclaims",
      ...
    },
    {
      "name": "persistentvolumeclaims/status",
      ...
    },
    {
      "name": "persistentvolumes",
      ...
    },
    {
      "name": "persistentvolumes/status",
      ...
    },
    {
      "name": "pods",
      "singularName": "pod",
      "namespaced": true, #<<< Se esse recurso está a nível de namespace. True = namespaced ; False = Cluster
      "kind": "Pod",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "shortNames": [
        "po"
      ],
      "categories": [
        "all"
      ],
      "storageVersionHash": "xPOwRZ+Yhw8="
    },
    {
      "name": "pods/attach",
      ...
    },
    {
      "name": "pods/binding",
      ...
    },
    {
      "name": "pods/ephemeralcontainers",
      ...
    },
    {
      "name": "pods/eviction",
      ...
    },
    {
      "name": "pods/exec",
      ...
    },
    {
      "name": "pods/log",
      ...
    },
    {
      "name": "pods/portforward",
      ...
    },
    {
      "name": "pods/proxy",
      ...
    },
    {
      "name": "pods/status",
      "singularName": "",
      "namespaced": true,
      "kind": "Pod",
      "verbs": [
        "get",
        "patch",
        "update"
      ]
    },
    {
      "name": "podtemplates",
      ...
    },
    {
      "name": "replicationcontrollers",
      ...
    },
    {
      "name": "replicationcontrollers/scale",
      ...
    },
    {
      "name": "replicationcontrollers/status",
      ...
    },
    {
      "name": "resourcequotas",
      ...
    },
    {
      "name": "resourcequotas/status",
      ...
    },
    {
      "name": "secrets",
      ...
    },
    {
      "name": "serviceaccounts",
      ...
    },
    {
      "name": "serviceaccounts/token",
      ...
    },
    {
      "name": "services",
      ...
    },
    {
      "name": "services/proxy",
      ...
    },
    {
      "name": "services/status",
      ...
    }
  ]
}

Esses recursos são os principais do core do kubernetes. Muitos deles já vimos aqui.

Fazendo uma lista mais resumida temos e se o seu escopo está em nível de namespace ou cluster.

• bindings : Namespace
• componentstatuses : Cluster
• configmaps : Namespace
• endpoints : Namespace
• events : Namespace
• limitranges : Namespace
• namespaces : Cluster
• nodes : Cluster
• persistentvolumeclaims : Namespace
• persistentvolumes : Cluster
• pods : Namespace
• podtemplates : Namespace
• replicationcontrollers : Namespace
• resourcequotas : Namespace
• secrets : Namespace
• serviceaccounts : Namespace
• services : Namespace

Observando em pods podemos ver que temos verbos (ações) que podemos executar nos recursos. Os verbos são diferentes dependendo do recurso.

Os possíveis verbos são os listados no recurso principal como em pods.

• create
• delete
• deletecollection
• get
• list
• patch
• update
• watch

Já em pod/status não temos alguns verbos.

O mesmo vale para services e service/* ou persistentvolumeclain e persistentvolumeclain/*.

Observe que esses verbos são muito usados no próprio comando kubectl.

Para ver os possíveis apigroups temos o comando.

kubectl get --raw='/?-k'
# ou
curl http://127.0.0.1:6443 -k

/apis

Já em apis os grupos são mais organizados e vão agregar os recursos mais novos disponibilizados para o Kubernetes. No primeiro níveis somente encontramos mais grupos.

kubectl get --raw='/apis' | jq  
{
  "kind": "APIGroupList",
  "apiVersion": "v1",
  # Cada grupo precisa ser nomeado com o nome as versões disponíveis e a versão preferida que seria a default
  "groups": [
    {
      "name": "apiregistration.k8s.io",
      "versions": [
        {
          "groupVersion": "apiregistration.k8s.io/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "apiregistration.k8s.io/v1",
        "version": "v1"
      }
    },
    ## Deixei esse grupo completo para observar
    {
      "name": "apps",
      "versions": [
        {
          "groupVersion": "apps/v1", #Já usamos isso antes
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "apps/v1",
        "version": "v1"
      }
    },
    {
      "name": "events.k8s.io",
      ...
    },
    {
      "name": "authentication.k8s.io",
      ...
    },
    {
      "name": "authorization.k8s.io",
      ...
    },
    # Um caso com mais de uma versão e mostrando que existe uma versão default
    # Nesse caso é usado para suportar retrocompatibilidade até que seja depreciado
    {
      "name": "autoscaling",
      "versions": [
        {
          "groupVersion": "autoscaling/v2",
          "version": "v2"
        },
        {
          "groupVersion": "autoscaling/v1",
          "version": "v1"
        }
      ],
      "preferredVersion": {
        "groupVersion": "autoscaling/v2",
        "version": "v2"
      }
    },
    {
      "name": "batch",
      ...
    },
    {
      "name": "certificates.k8s.io",
      ...
    },
    {
      "name": "networking.k8s.io",
      ...
    },
    {
      "name": "policy",
      ...
    },
    {
      "name": "rbac.authorization.k8s.io",
      ...
    },
    {
      "name": "storage.k8s.io",
      ...
    },
    {
      "name": "admissionregistration.k8s.io",
      ...
    },
    {
      "name": "apiextensions.k8s.io",
      ...
    },
    {
      "name": "scheduling.k8s.io",
    },
    {
      "name": "coordination.k8s.io",
      ...
    },
    {
      "name": "node.k8s.io",
      ...
    },
    {
      "name": "discovery.k8s.io",
      ...
    },
    {
      "name": "flowcontrol.apiserver.k8s.io",
      ...
    }
  ]
}

Fazendo um resumo temos os subgrupos abaixo e dentro de cada um deles temos mais recursos do kubernetes.

• apps : Namespace
• events.k8s.io : Namespace
• authentication.k8s.io : Cluster
• authorization.k8s.io : Cluster e Namespace
• autoscaling : Namespace
• batch : Namespace
• certificates.k8s.io : Cluster
• networking.k8s.io : Namespace
• policy : Namespace
• rbac.authorization.k8s.io : Namespace
• storage.k8s.io : Namespace
• admissionregistration.k8s.io : Namespace
• apiextensions.k8s.io : Namespace
• scheduling.k8s.io : Namespace
• coordination.k8s.io : Namespace
• node.k8s.io : Namespace
• discovery.k8s.io : Namespace
• flowcontrol.apiserver.k8s.io : Namespace

Vamos analisar apps, mas o que vou fazer valeria para cada um dos grupos acima. Da mesma maneira vou diminuir a saída para ficar mais fácil a leitura. Igualmente temos os verbos.

kubectl get --raw='/apis/apps/v1' | jq
{
  # Aqui os que se espera que tenha em cada um dos recursos
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "apps/v1",
  "resources": [
    {
      "name": "controllerrevisions",
      "singularName": "controllerrevision",
      "namespaced": true,
      "kind": "ControllerRevision",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "storageVersionHash": "85nkx63pcBU="
    },
    {
      "name": "daemonsets",
      ...
    {
      "name": "daemonsets/status",
       ...
    {
      "name": "deployments",
      "singularName": "deployment",
      "namespaced": true,
      "kind": "Deployment",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],
      "shortNames": [
        "deploy"
      ],
      "categories": [
        "all"
      ],
      "storageVersionHash": "8aSe+NMegvE="
    },
    {
      "name": "deployments/scale",
      ...
    {
      "name": "deployments/status",
     ...
    {
      "name": "replicasets",
      ...
    {
      "name": "replicasets/scale",
      ...
    {
      "name": "replicasets/status",
      ...
    {
      "name": "statefulsets",
      ...
    {
      "name": "statefulsets/scale",
      ...
    {
      "name": "statefulsets/status",
      ...
    }
}

Se fossemos resumir encontraríamos em apps.

• apps
  • v1
    • daemonsets
    • deployments
    • replicasets
    • statefulset

Vamos preencher então as coisas os grupos e o que encontraríamos dentro deles. Lembrando que não está completo, somente o recurso principal. Vou dar ênfase em mostrar qual o escopo possui para entender melhor alguns conceitos depois.

• apps
  • v1
    • daemonsets : Namespace
    • deployments : Namespace
    • replicasets : Namespace
    • statefulset : Namespace
• events.k8s.io
  • v1
    • events : Namespace
• authentication.k8s.io
  • v1
    • selfsubjectreviews : Cluster
    • tokenreviews : : Cluster
• authorization.k8s.io
  • v1
    • localsubjectaccessreviews : Namespace
    • selfsubjectaccessreviews : Cluster
    • selfsubjectrulesreviews : Cluster
    • subjectaccessreviews : Cluster
• autoscaling
  • v1
    • horizontalpodautoscalers : Namespace
  • v2
    • horizontalpodautoscalers : Namespace
• batch
  • v1
    • cronjobs : Namespace
    • jobs : Namespace
• certificates.k8s.io
  • v1
    • certificatesigningrequests: Cluster
• networking.k8s.io
  • v1
    • ingresses : Namespace
    • ingressclasses : Cluster
    • networkpolicies : : Namespace
• policy
  • v1
    • poddisruptionbudgets : Namespace
• rbac.authorization.k8s.io
  • v1
    • clusterroles : Cluster
    • clusterrolebindings : Cluster
    • roles : Namespace
    • rolebindings : Namespace
• storage.k8s.io
  • v1
    • storageclasses : Cluster
    • volumeattachments : Cluster
    • csidrivers : Cluster
    • csinodes : Cluster
    • csistoragecapacities : Namespace
• admissionregistration.k8s.io
  • v1
    • mutatingwebhookconfigurations : Cluster
    • validatingwebhookconfigurations : Cluster
• apiextensions.k8s.io
  • v1
    • customresourcedefinitions : Cluster
• scheduling.k8s.io
  • v1
    • priorityclasses : Cluster
• coordination.k8s.io
  • v1
    • leases : Namespace
• node.k8s.io
  • v1
    • runtimeclasses : Cluster
• discovery.k8s.io
  • v1
    • endpointslices : Namespace
• flowcontrol.apiserver.k8s.io
  • v1
    • flowschemas : Cluster
    • prioritylevelconfigurations : Cluster
  • v1beta3
    • flowschemas : Cluster
    • prioritylevelconfigurations : Cluster

O que tirar disso tudo?

Todos os recursos do kubernetes estão agrupados em diferentes apigroups. No top level temos o /api com o core do kubernetes e /apis com os grupos nomeados. Dentro de cada grupo temos diferentes recursos e os verbos associados que são um conjunto de ações possíveis que serão usadas para permitir ou negar um usuário de fazer alguma coisa e se um recurso é de nível cluster ou namespace.

O comando kubectl api-resources trará todos os recursos do kubernetes.

# Recursos a nivel de cluster
kubectl api-resources  --namespaced=false -o name

# Recursos a nivel de namespace
kubectl api-resources  --namespaced=true -o name