Please enable JavaScript.

Coggle requires JavaScript to display documents.

KUBERNETES - Coggle Diagram

- - - - Dirección IP única dentro del cluster.
      - Ephemeral: No están diseñados para ser persistentes; si un Pod muere, se reemplaza.
      - Recursos
        
        requests: Cantidad mínima de recursos (CPU, memoria) que un contenedor necesita. Usado por el scheduler y HPA.
        
        limits: Cantidad máxima de recursos que un contenedor puede usar.
      - Probes
        
        Liveness Probe (¿Estoy vivo?)
        
        Objetivo: Saber si la aplicación está corriendo.
        
        Acción al fallar: REINICIA el contenedor (CrashLoopBackOff si persiste).
        
        Cuándo usar: Para recuperar apps colgadas, deadlocks o bucles infinitos.
        
        Readiness Probe (¿Estoy listo?)
        
        Objetivo: Saber si la aplicación puede aceptar tráfico.
        
        Acción al fallar: AÍSLA el pod (quita su IP del Service/LoadBalancer).
        
        Cuándo usar: Durante el inicio (cargando caché) o si se satura temporalmente.
        
        Mejores Prácticas
        
        No las hagas iguales: El Liveness suele ser una comprobación ligera (ej. responder un ping), mientras que el Readiness puede ser más profunda (ej. verificar conexión a base de datos).
        
        Usa initialDelaySeconds: Dale tiempo a tu aplicación para arrancar antes de que las sondas empiecen a fallar y Kubernetes entre en un bucle de reinicios.
        
        Independencia en Liveness: Tu Liveness Probe no debe depender de servicios externos (como una base de datos caída). Si la DB cae, no quieres que se reinicien todos tus pods web, solo quieres que dejen de recibir tráfico (Readiness).
  - - - Rollouts (despliegues).
      - Rollbacks (revertir a una versión anterior).
      - Permite actualizaciones "rolling" (actualización gradual sin downtime).
      - Puede ser escalado manualmente (kubectl scale) o automáticamente por un HPA.
    - - RollingUpdate (predeterminado): Reemplaza Pods uno por uno.
      - Recreate: Destruye todos los Pods viejos antes de crear los nuevos.
  - - - Identificadores de red estables y únicos (ej., web-0, web-1). (DNS unico para cada instancia (aunque se reinicie))
      - Volúmenes persistentes estables (asociados al Pod por su ordinal).
      - Puede ser escalado manualmente o automáticamente por un HPA.
      - Útil para bases de datos (MongoDB, PostgreSQL), sistemas de colas (Kafka)
  - - - ClusterIP (predeterminado): Expone el Service en una IP interna del cluster (solo accesible desde dentro del cluster).
      - NodePort: Abre un puerto estático en cada Nodo, que redirige al Service (accesible desde fuera del cluster).
      - LoadBalancer: Provisiona un balanceador de carga externo del proveedor de la nube que expone el Service (solo para proveedores de nube).
      - ExternalName: Mapea un Service a un nombre DNS externo.
      - Headless Service
        
        Un Service sin ClusterIP (clusterIP: None).
        
        No balancea la carga ni asigna una IP única al servicio. Las consultas DNS resuelven directamente las IPs de los Pods backend.
        
        Uso: Esencial para StatefulSets y aplicaciones que requieren control granular sobre la conectividad de Pods individuales o descubrimiento directo de instancias.
  - - - Se define mediante podSelector (Usa Labels).
      - Si el selector está vacío {}, aplica a todos los pods del Namespace.
    - - Ingress: Tráfico entrante (hacia el pod).
      - Egress: Tráfico saliente (desde el pod).
    - - Nota: Por defecto, si existe una política, todo lo que no está permitido explícitamente se deniega.
      - Origen/Destino permitido
        
        podSelector: Pods específicos.
        
        namespaceSelector: Pods en namespaces específicos.
        
        ipBlock: Rangos de IP externos (CIDR).
      - Puertos: TCP, UDP, SCTP.
    - - Default Deny: Comienza creando una política de "Denegar todo" (Deny All) para Ingress y Egress en cada namespace para forzar el aislamiento por defecto.
      - Permitir DNS: Si bloqueas el tráfico de salida (Egress), recuerda explícitamente permitir el tráfico UDP/TCP al puerto 53 (CoreDNS), o tus pods no podrán resolver nombres de dominio.
      - Uso de Labels consistentes: Mantén una estrategia de etiquetado clara (app: frontend, role: db) para facilitar la creación de selectores.
      - Evitar rangos IP fijos internos: Usa podSelector y namespaceSelector en lugar de IPs fijas de pods, ya que estas son efímeras. Usa ipBlock solo para recursos externos al clúster.
- - - - apiVersion: Versión de la API de Kubernetes (ej., v1, apps/v1, autoscaling/v2).
      - kind: Tipo de recurso (ej., Pod, Deployment, Service, HorizontalPodAutoscaler).
      - metadata: Información del recurso (name, namespace, labels, annotations).
      - spec: Especificación del estado deseado del recurso (contenido principal).
      - status: Estado actual del recurso (gestionado por Kubernetes, no por el usuario).
  - - - kubectl apply -f <file.yaml>: Aplica o actualiza un recurso definido en un manifest.
      - kubectl get <resource>: Muestra recursos (ej., pods, deployments, svc, hpa). la opcion -o yaml muestra el detalle en formato yaml
      - kubectl describe <resource> <name>: Muestra detalles exhaustivos de un recurso.
      - kubectl logs <pod-name>: Muestra los logs de un contenedor en un Pod.
      - kubectl exec -it <pod-name> -- bash: Ejecuta un comando dentro de un contenedor en un Pod.
      - kubectl delete <resource> <name>: Elimina un recurso.
      - kubectl scale deployment/<name> --replicas=<count>: Escala un despliegue manualmente.
      - kubectl edit <resource> <name>: Edita un recurso directamente en el cluster (uso cuidadoso) (permite modificar el yaml y aplica los cambios realizados).
- - - - Montados como archivos en un volumen.
      - Inyectados como variables de entorno.
      - Pasados como argumentos de línea de comandos.
  - - - Montados como archivos en un volumen.
      - Inyectados como variables de entorno.
  - - - ReadWriteOnce (RWO): El volumen puede ser montado como lectura-escritura por un solo nodo.
      - ReadOnlyMany (ROX): El volumen puede ser montado como solo lectura por muchos nodos.
      - ReadWriteMany (RWX): El volumen puede ser montado como lectura-escritura por muchos nodos.
    - - Mecanismo para almacenar datos que pueden ser accesibles por los contenedores de un Pod.
      - Volúmenes Persistentes (PersistentVolume - PV)
        
        Recurso de almacenamiento en el cluster provisionado por un administrador o dinámicamente.
        
        Es independiente del ciclo de vida de un Pod.
        
        PV es una abstracción del almacenamiento real (ej., disco de la nube, NFS).
      - Reclamos de Volumen Persistente (PersistentVolumeClaim - PVC
        
        Una solicitud de almacenamiento por parte de un usuario o Pod
        
        Define los requisitos (tamaño, modos de acceso)
        
        Kubernetes vincula un PVC a un PV disponible.
      - StorageClasses
        
        Define "clases" de almacenamiento (ej., "fast-ssd", "standard-hdd").
        
        Permite el aprovisionamiento dinámico de PVs (Kubernetes crea el PV automáticamente cuando un PVC lo solicita).
- - - - Punto de entrada principal para interacciones con el cluster (RESTful API).
      - Todas las interacciones de kubectl, otros componentes y usuarios pasan por aquí.
    - - Base de datos clave-valor distribuida y consistente.
      - Almacena el estado deseado del cluster y los datos de configuración.
      - Único punto de verdad para Kubernetes.
    - - Selecciona un nodo para cada nuevo Pod que no tiene un nodo asignado.
      - Considera requisitos de recursos, políticas de affinity/anti-affinity, tolerancias, etc.
    - - Ejecuta controladores que observan el estado actual del cluster y lo acercan al estado deseado.
      - Controladores internos
        
        Node Controller: Responsable de notar y responder cuando los nodos dejan de estar disponibles.
        
        Replication Controller: Mantiene el número correcto de Pods para un ReplicaSet.
        
        HPA Controller (¡Nuevo!): Gestiona el Horizontal Pod Autoscaler, ajustando las réplicas de Deployments/StatefulSets.
        
        Entre otros
    - - Integra el cluster con la API de un proveedor de la nube (ej., AWS, GCP, Azure).
      - Maneja recursos específicos de la nube como Load Balancers y volúmenes de almacenamiento.
  - - - Agente que se ejecuta en cada nodo.
      - Se asegura de que los contenedores dentro de un Pod estén ejecutándose y saludables.
      - Se comunica con el kube-apiserver para recibir especificaciones de Pods.
      - Reporta el estado del Pod y del nodo.
    - - Agente de red en cada nodo.
      - Mantiene las reglas de red para permitir la comunicación entre Pods y Servicios.
      - Puede usar iptables, ipvs o eBPF.
      - Crucial para la implementación de Services.
    - - Software responsable de ejecutar contenedores (ej., Docker, containerd, CRI-O).
      - Kubernetes usa la Container Runtime Interface (CRI) para interactuar con él
    - - Recopila métricas de CPU y memoria de los Kubelets.
      - Esencial para que el Horizontal Pod Autoscaler pueda tomar decisiones de escalado.
- - - - helm install <name> <chart>: Despliega un Chart.
      - helm upgrade <name> <chart>: Actualiza una Release existente.
      - helm rollback <name> <revision>: Revierte una Release a una versión anterior.
- - - - Monitorea métricas (CPU, memoria, métricas personalizadas).
      - Compara las métricas con los objetivos definidos.
      - Calcula el número de réplicas necesarias.
      - Actualiza el campo replicas del Deployment (o StatefulSet/ReplicaSet).
      - El controlador del Deployment (o StatefulSet/ReplicaSet) crea/elimina Pods para igualar el nuevo número de réplicas.
    - - Metrics Server instalado para métricas de CPU/Memoria.
      - resource.requests definidos en los contenedores de los Pods (esencial para métricas de utilización de CPU/Memoria).
    - - minReplicas: Número mínimo de Pods.
      - maxReplicas: Número máximo de Pods.
      - target: Métrica objetivo (ej., averageUtilization: 50% para CPU).
- - - - Role: Define permisos dentro de un Namespace específico.
      - rules: Una lista de operaciones (verbs: get, list, create, delete) sobre recursos (resources: pods, deployments).
      - ClusterRole: Define permisos a nivel de cluster o para recursos no-namespaced.
      - RoleBinding: Concede los permisos definidos en un Role a un Subject (usuario, grupo, ServiceAccount) dentro de un Namespace.
      - ClusterRoleBinding: Concede los permisos definidos en un ClusterRole a un Subject a nivel de cluster.
      - ServiceAccount: Proporciona una identidad para los procesos que se ejecutan en Pods.
        Los Pods usan ServiceAccounts para autenticarse en la API de Kubernetes.