61 artículos con esta etiqueta.
El plano de control, los nodos de trabajo y los componentes centrales que hacen que un cluster se comporte como un sistema programable.
Cómo Kubernetes descarga imágenes, delega ejecución a runtimes y permite que los Pods pidan comportamiento distinto de runtime.
Los objetos que describen aplicaciones corriendo: Pods, controladores, estrategia de rollout, workloads con estado y jobs batch.
Cómo los Pods se encuentran, reciben tráfico y aplican límites de red dentro y fuera del cluster.
Las abstracciones de storage que separan el ciclo de vida del contenedor del ciclo de vida de los datos.
Cómo se representan settings de aplicación, valores sensibles, contratos de recursos y acceso al cluster.
Cómo los Pods se ubican, se mueven, son expulsados y se protegen contra disrupción voluntaria e involuntaria.
Los controles de acceso, identidad, workload y admisión que evitan que el cluster sea una zona plana de confianza.
La capa operativa: ciclo de vida, addons, logging, métricas y hábitos de mantenimiento.
Las APIs y patrones de extensión que permiten que Kubernetes se vuelva una plataforma para tus propias operaciones.
Un laboratorio de Kubernetes y platform engineering para construir infraestructura personal confiable desde documentación oficial y operación real.
Un cluster de Kubernetes no es un solo daemon. Es un sistema operativo distribuido pequeno con una API, una base de datos, reconciliadores y agentes en cada maquina.
El plano de control es el cerebro y el libro contable del cluster. Acepta estado deseado, lo guarda y corre loops que empujan la realidad hacia ese estado.
Un nodo solo es útil si kubelet puede reportar salud y pedirle al runtime de contenedores que corra Pods.
Kubernetes funciona porque los controladores comparan estado deseado con estado observado. Ese loop es el producto.
El cluster base está incompleto a propósito. DNS, ingress, métricas, storage y policy son decisiones que compones.
Una imagen es un artefacto de supply chain. Kubernetes puede descargarla, pero tú sigues siendo dueño de versionado, procedencia, tamaño y rollback.
kubelet no corre contenedores directamente. Habla por Container Runtime Interface con un runtime como containerd.
RuntimeClass permite que un Pod pida un entorno de ejecución distinto sin cambiar la forma general del manifest.
Un Pod es la unidad desplegable mínima: una identidad de red, una decisión de scheduling y un contexto local compartido para contenedores.
Un Deployment es un controlador de rollout. ReplicaSets es la maquinaria que usa para mantener vivos los Pods correctos.
StatefulSet da identidad estable y comportamiento ordenado a Pods. Es para software que nota quién es.
Un DaemonSet corre una copia de un Pod en nodos seleccionados. Así los servicios de nodo se vuelven servicios de cluster.
Jobs son para completar trabajo, no para servir tráfico. CronJobs agregan reloj a ese contrato.
Autoscaling es un loop de feedback. Necesita métricas, resource requests y un workload que soporte cambios de replicas.
Kubernetes asume que Pods pueden hablar con Pods sin NAT. La implementacion CNI vuelve real esa promesa.
Un Service es un contrato estable sobre Pods inestables: nombre, IP virtual y reglas de selección.
EndpointSlices son la lista escalable de destinos reales a los que puede ir el tráfico de un Service.
DNS convierte objetos de Kubernetes en nombres de los que humanos y aplicaciones pueden depender.
Ingress y Gateway API son capas de manejo de tráfico encima de Services. Deciden como tráfico HTTP externo llega a backends internos.
NetworkPolicy es un modelo de firewall para Pods, pero solo si el plugin de red lo aplica.
Un Volume es storage montado dentro de un Pod. Su vida y backend dependen del tipo de volumen.
PersistentVolume es oferta. PersistentVolumeClaim es demanda. El binding conecta necesidades de app con capacidad de storage.
StorageClass es una opción de menu. Provisioning dinámico convierte un PVC en storage backend sin crear PVs a mano.
Storage efímero es espacio local útil con memoria corta. Es para necesidades de runtime, no para verdad durable.
Snapshots son un limite API de storage, no una garantía universal de restore.
ConfigMaps separan configuración no secreta de imágenes para que el mismo artefacto corra en distintos entornos.
Un Secret de Kubernetes es un objeto API para material sensible. No es automáticamente un programa completo de gestión de secretos.
Requests son promesas para scheduling. Limits son fronteras de enforcement. Confundirlos crea clusters ruidosos.
kubeconfig es la tabla de rutas local para tu acceso humano a clusters, usuarios y namespaces.
El scheduler elige nodo para Pods que aún no tienen uno. Filtra nodos imposibles y puntúa el resto.
La asignación a nodos es como los workloads expresan dónde pueden o deben correr.
Taints repelen Pods. Tolerations permiten que Pods acepten esa repulsión. Affinity atrae o separa por labels.
Cuando la capacidad escasea, Kubernetes necesita reglas para quién se agenda y quién sale.
Un disruption budget le dice a Kubernetes cuanta disrupción voluntaria tolera una app.
Cada acción importante en Kubernetes se vuelve una solicitud API que debe autenticarse, autorizarse y pasar admisión.
Service accounts son identidades de workload. RBAC define que pueden hacer esas identidades.
Pod security controla la forma de los workloads antes de que corran: privilegio, acceso host, usuarios, capabilities y filesystem.
Admission es la puerta entre una solicitud API válida y una solicitud que el cluster realmente debe aceptar.
Manejo de secretos es un ciclo completo: creacion, storage, acceso, rotación, exposición y eliminación.
Planear un cluster es decidir que fallas estas dispuesto a absorber y que complejidad estas dispuesto a operar.
El ciclo de vida del cluster es la ruta repetible para instalar, actualizar, reparar y reemplazar la plataforma.
Los addons dejan de ser opcionales cuando los workloads dependen de ellos. Se vuelven parte del SLO de plataforma.
Logs son evidencia distribuida. Kubernetes te da streams; tú decides retención, routing y búsqueda.
Metricas convierten comportamiento del cluster en senales que humanos y controladores pueden usar.
Un Custom Resource agrega una nueva forma de API. Se vuelve útil cuando un controlador lo reconcilia.
Un operator empaqueta conocimiento operativo en un controlador. Debe volver repetibles las buenas operaciones.
Admission webhooks permiten que código externo participe en decisiones de API al escribir.
Plugins permiten que Kubernetes entienda capacidades que no posee directamente: GPUs, hardware y networking custom.
Las APIs de Kubernetes evolucionan. Buen trabajo de plataforma sabe de que versiones depende y cuando vienen migraciones.
Explorando Tailscale para dar redundancia a un homelab y exponer servicios de forma segura: una alternativa limpia para arquitecturas multi-cloud.