Principales API Groups en Kubernetes

La diferencia entre v1 y apps/v1 en Kubernetes se debe a la evolución de la API y la naturaleza de los recursos que representan. A continuación, analizaremos en detalle cada uno de ellos.

1. API Version v1 (Core API)

Los Pods son un recurso básico en Kubernetes y pertenecen al API Group Core (Núcleo), que no tiene un prefijo de grupo explícito en su apiVersion (solo v1).

Ejemplo:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest

Razón: Los Pods son un recurso fundamental y más simple, por lo que están en el núcleo del sistema. Desde las primeras versiones de Kubernetes, los Pods han sido gestionados por la API principal.

2. API Version apps/v1 (API Group Apps)

Por ejemplo, los Deployments son recursos más avanzados que pertenecen al grupo apps, una API especializada para gestionar aplicaciones. apps es uno de los API Groups introducidos para organizar y evolucionar las funcionalidades más complejas.

Ejemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: nginx
          image: nginx:latest

Razón: Los Deployments y otros recursos como StatefulSets o DaemonSets son conceptos de nivel superior que dependen de grupos específicos como apps para ofrecer más funcionalidad (por ejemplo, gestión de réplicas, actualizaciones rolling, etc.).

Diferencia Clave entre los Grupos

• Core API (v1): Contiene los recursos básicos como Pods, Services, ConfigMaps, Secrets, PersistentVolumes, Namespaces.

• Grouped APIs (como apps/v1): Se introdujeron para añadir funcionalidades avanzadas y permitir la evolución de ciertos recursos sin afectar la API principal.

Otros Principales API Groups en Kubernetes

Además del grupo Core y el grupo apps, Kubernetes tiene múltiples API Groups que gestionan diferentes tipos de recursos y funcionalidades. Estos grupos amplían la funcionalidad de Kubernetes y están diseñados para modularizar y evolucionar la API sin afectar la compatibilidad general.

1. Core API (v1):

• Recursos: Pods, Services, ConfigMaps, Secrets, PersistentVolumes, Namespaces.

• Ejemplo:

  apiVersion: v1
  kind: Pod

2. apps/v1:

• Recursos: Deployments, StatefulSets, DaemonSets, ReplicaSets.

• Ejemplo:

  apiVersion: apps/v1
  kind: Deployment

3. batch/v1:

• Recursos: Jobs, CronJobs.

• Uso: Gestión de tareas temporales o programadas.

• Ejemplo:

  apiVersion: batch/v1
  kind: Job

4. autoscaling/v1, autoscaling/v2 y autoscaling/v2beta2:

• Recursos: HorizontalPodAutoscaler (HPA).

• Uso: Escalado automático basado en métricas.

• Ejemplo:

  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler

5. networking.k8s.io/v1:

• Recursos: NetworkPolicies, Ingress, IngressClass.

• Uso: Gestión de políticas de red e Ingress (control de acceso HTTP/HTTPS).

• Ejemplo:

  apiVersion: networking.k8s.io/v1
  kind: Ingress

6. policy/v1:

• Recursos: PodDisruptionBudget (PDB).

• Uso: Define políticas para evitar interrupciones de Pods más allá de un límite tolerable.

• Ejemplo:

  apiVersion: policy/v1
  kind: PodDisruptionBudget

7. rbac.authorization.k8s.io/v1:

• Recursos: Role, RoleBinding, ClusterRole, ClusterRoleBinding.

• Uso: Control de acceso basado en roles (RBAC).

• Ejemplo:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role

8. apiextensions.k8s.io/v1:

• Recursos: CustomResourceDefinition (CRD).

• Uso: Definir recursos personalizados que amplían las capacidades de Kubernetes.

• Ejemplo:

  apiVersion: apiextensions.k8s.io/v1
  kind: CustomResourceDefinition

9. admissionregistration.k8s.io/v1:

• Recursos: MutatingWebhookConfiguration, ValidatingWebhookConfiguration.

• Uso: Configurar webhooks para validar o modificar solicitudes a la API de Kubernetes.

• Ejemplo:

  apiVersion: admissionregistration.k8s.io/v1
  kind: MutatingWebhookConfiguration

10. storage.k8s.io/v1:

• Recursos: StorageClass, VolumeAttachment.

• Uso: Gestión de volúmenes de almacenamiento dinámico.

• Ejemplo:

  apiVersion: storage.k8s.io/v1
  kind: StorageClass

11. scheduling.k8s.io/v1:

• Recursos: PriorityClass.

• Uso: Establecer prioridades para los Pods en el clúster.

• Ejemplo:

  apiVersion: scheduling.k8s.io/v1
  kind: PriorityClass

Ventajas de la Separación por API Groups

1. Modularidad: Los recursos avanzados pueden evolucionar sin romper compatibilidad con los recursos básicos.

2. Escalabilidad: Las aplicaciones complejas pueden ser gestionadas en grupos especializados (como apps) en lugar de sobrecargar la API principal.

3. Organización Clara: Los recursos se agrupan por funcionalidad, lo que facilita su comprensión y mantenimiento.

Cómo Identificar la apiVersion Correcta

• Usa kubectl explain para explorar los recursos disponibles y sus apiVersion.

  kubectl explain deployment

• Usa kubectl api-resources para listar todos los recursos disponibles y sus respectivos apiVersion.

  kubectl api-resources