Explora el clúster de Kubernetes

Introducción

En este laboratorio, explorarás un clúster local de Kubernetes utilizando Minikube. Iniciarás el clúster, verificarás su configuración y examinarás recursos básicos del clúster, como pods y despliegues (deployments). Esta experiencia práctica te ayudará a comprender los componentes y comandos fundamentales de un entorno de Kubernetes, sentando las bases para una mayor exploración y desarrollo.

Comenzarás configurando un clúster de Minikube en tu máquina local, asegurándote de que el clúster esté en funcionamiento y listo para usar. Luego, verificarás la configuración y el estado del clúster utilizando comandos esenciales de kubectl, como kubectl cluster-info y kubectl get nodes. Finalmente, examinarás los recursos básicos del clúster, incluyendo pods y despliegues (deployments), para familiarizarte con el modelo de objetos de Kubernetes y el estado general del clúster.

Iniciar un clúster local de Kubernetes

En este paso, iniciarás y verificarás un clúster local de Kubernetes utilizando Minikube, que ofrece una forma sencilla de configurar un entorno de Kubernetes de un solo nodo para aprendizaje y desarrollo.

Primero, navega al directorio del proyecto:

cd ~/project

Inicia el clúster de Minikube:

Nota: Los usuarios gratuitos no pueden conectarse a Internet, por lo que Minikube ya está pre-iniciado cuando se inicia el laboratorio. Puedes saltar a la sección de código a continuación para verificar el estado del clúster. Actualiza a un usuario Pro para practicar el inicio del clúster por ti mismo.

Solo para usuarios Pro

minikube start

Ejemplo de salida:

😄  minikube v1.29.0 on Ubuntu 22.04
✨  Automatically selected the docker driver
📌  Using Docker driver with root permissions
🔥  Creating kubernetes in kubernetes cluster
🔄  Restarting existing kubernetes cluster
🐳  Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀  Launching Kubernetes...
🌟  Enabling addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace

Verifica el estado del clúster utilizando múltiples comandos:

minikube status

Ejemplo de salida:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Verifica los nodos del clúster:

kubectl get nodes

Ejemplo de salida:

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   1m    v1.26.1

Estos comandos confirman que:

Minikube se ha iniciado correctamente.
El clúster local de Kubernetes está en funcionamiento.
El clúster está listo para usar.
Tienes un clúster de un solo nodo con capacidades de plano de control.

El clúster de Minikube proporciona un entorno completo de Kubernetes en tu máquina local, lo que te permite desarrollar y probar aplicaciones sin necesidad de un clúster multi-nodo completo.

Visión general de la arquitectura de Kubernetes

Kubernetes opera bajo un modelo cliente-servidor, con un plano de control (Control Plane) centralizado que gobierna el estado del clúster y un conjunto de nodos (Nodes) trabajadores que ejecutan las cargas de trabajo. A un nivel general, un usuario (a menudo un desarrollador) interactúa con el clúster de Kubernetes a través de herramientas de línea de comandos o APIs. El plano de control toma decisiones sobre qué debe ejecutarse y dónde, monitorea la salud del clúster y se asegura de que se alcance el estado deseado. Los nodos trabajadores alojan tus aplicaciones en pods (grupos de uno o más contenedores) y ofrecen los recursos de cálculo y almacenamiento necesarios para ejecutarlas.

Plano de control (Control Plane)

Este es el “cerebro” del clúster, compuesto por varios componentes que trabajan juntos para gestionar todo el sistema:

kube-apiserver (API): Sirve como la puerta principal del clúster. Todos los comandos administrativos y solicitudes de recursos pasan a través de él.
etcd (Almacén de pares clave-valor): Almacena todos los datos de configuración y el estado actual del clúster. Si se pierden los datos de etcd, se pierde el estado del clúster.
kube-scheduler (SCH): Asigna los pods a los nodos en función de los requisitos de recursos, restricciones y políticas.
kube-controller-manager (CTLM): Ejecuta una variedad de controladores que ajustan continuamente el estado del clúster, asegurando que el estado real coincida con el estado deseado definido por tus despliegues y configuraciones.

Nodos (Máquinas trabajadoras)

Los nodos son donde se ejecutan las cargas de trabajo. Cada nodo tiene:

kubelet (KLT): Un agente a nivel de nodo que se comunica con el plano de control. Se asegura de que los pods estén en ejecución y les informa su estado al plano de control.
Tiempo de ejecución de contenedores (Container Runtime - CR): Software que ejecuta y gestiona contenedores (por ejemplo, Docker o containerd). Crea y gestiona aplicaciones en contenedores dentro de los pods.

Pods

Un pod es la unidad desplegable más pequeña en Kubernetes, que generalmente representa una instancia única de una aplicación en ejecución. Los pods pueden contener uno o más contenedores que comparten el mismo espacio de nombres de red y volúmenes de almacenamiento.

Servicios

Un servicio es una abstracción que define un conjunto lógico de pods y una política sobre cómo acceder a ellos. Los servicios proporcionan direcciones IP estáticas, nombres DNS y equilibrio de carga, asegurando que los consumidores externos y otros componentes del clúster puedan conectarse de forma confiable a tus aplicaciones, incluso cuando los pods se mueven entre nodos o se reemplazan durante el escalado o las actualizaciones graduales.

Interacción con el clúster

Los desarrolladores y administradores interactúan con el clúster a través del kube-apiserver, a menudo utilizando kubectl u otros clientes de Kubernetes.
Cuando se despliega una nueva aplicación, los componentes del plano de control (programador, controladores) trabajan para colocar los pods en los nodos adecuados.
El kubelet en cada nodo se asegura de que los pods estén saludables y en ejecución según se indica.
Los servicios enrutan el tráfico a los pods correctos, lo que permite a los clientes acceder a las aplicaciones sin tener que seguir los cambios de ubicación de los pods.

flowchart TB

    %% User interacting with the cluster
    User((Developer))
    User -->|kubectl CLI| API[kube-apiserver]

    %% Control Plane Components
    subgraph ControlPlane[Control Plane]
        API
        ETCD[etcd - Key Value Store]
        SCH[kube-scheduler]
        CTLM[kube-controller-manager]

        API --> ETCD
        API --> SCH
        API --> CTLM
    end

    %% Worker Node 1
    subgraph Node1[Worker Node]
        KLT1[kubelet]
        CR1[Container Runtime]
        subgraph Pods1[Pods]
            P1[Pod]
            P2[Pod]
        end

        KLT1 --> CR1
        CR1 --> P1
        CR1 --> P2
    end

    %% Worker Node 2
    subgraph Node2[Worker Node]
        KLT2[kubelet]
        CR2[Container Runtime]
        subgraph Pods2[Pods]
            P3[Pod]
            P4[Pod]
        end

        KLT2 --> CR2
        CR2 --> P3
        CR2 --> P4
    end

    %% Connections between Control Plane and Nodes
    API --> KLT1
    API --> KLT2

    %% Service connecting to Pods across different Nodes
    Service[Service]
    Service --> P1
    Service --> P2
    Service --> P3
    Service --> P4

En el diagrama:

El desarrollador interactúa con el kube-apiserver (API) a través de una herramienta de línea de comandos como kubectl.
Los componentes del plano de control (API, etcd, Programador, Gestor de controladores) gestionan el estado del clúster y orquestan las cargas de trabajo.
Cada nodo trabajador ejecuta un kubelet y un tiempo de ejecución de contenedores, alojando múltiples pods.
Un servicio enruta el tráfico externo o interno a los pods correctos, proporcionando un punto final estático que abstrae la complejidad del ciclo de vida de los pods y los cambios de IP.

Este modelo mental te ayuda a entender lo que estás viendo cuando inspeccionas el estado del clúster, verificas la salud de los nodos, enumeras los pods y consultas los servicios, conceptos que aplicarás mientras continúas explorando Kubernetes con comandos de kubectl.

Verificar la configuración del clúster

En este paso, aprenderás cómo verificar la configuración y la salud de tu clúster de Kubernetes utilizando comandos esenciales de kubectl. Estos comandos te ayudarán a entender el estado actual y la conectividad del clúster.

Primero, verifica la información del clúster:

kubectl cluster-info

Ejemplo de salida:

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'

Este comando proporciona detalles sobre el plano de control de Kubernetes y servicios principales como CoreDNS.

A continuación, obtén una vista detallada de los nodos del clúster:

kubectl get nodes -o wide

Ejemplo de salida:

NAME       STATUS   ROLES           AGE    VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION
minikube   Ready    control-plane   15m    v1.26.1   192.168.49.2   <none>        Ubuntu 22.04 LTS    5.15.0-72-generic

Examinemos los detalles del nodo de manera más exhaustiva:

kubectl describe node minikube

Ejemplo de salida (parcial):

Name:               minikube
Roles:              control-plane
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=minikube
                    kubernetes.io/os=linux
                    minikube.k8s.io/commit=86a3b7e45a9a35cdcf8f4c80a4c6a46d20dda00f
Annotations:        node.alpha.kubernetes.io/ttl: 0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  [Current Timestamp]
Capacity:
  cpu:                2
  ephemeral-storage:  17784212Ki
  memory:             1947748Ki
  pods:               110
Allocatable:
  cpu:                2
  ephemeral-storage:  16388876Ki
  memory:             1845348Ki
  pods:               110

Principales conclusiones de estos comandos:

Verifica que el plano de control del clúster esté en funcionamiento.
Comprueba el estado del nodo (Listo/No listo).
Entiende los recursos y la configuración del nodo.
Confirma la versión de Kubernetes y los detalles del nodo.

Inspeccionar los recursos básicos del clúster

En este paso, inspeccionarás recursos básicos de Kubernetes, como pods, despliegues (deployments) y servicios, en todos los espacios de nombres (namespaces). Al utilizar la bandera -A (o --all-namespaces), verás cómo se organizan los recursos en todo el clúster. Esta es una excelente oportunidad para introducir y comprender el concepto de espacios de nombres (namespaces) en Kubernetes.

Espacios de nombres (Namespaces): Aislamiento de recursos

Los espacios de nombres son particiones lógicas dentro de un clúster de Kubernetes que ayudan a organizar y gestionar recursos. Proporcionan una forma de agrupar objetos relacionados y aplicar políticas, controles de acceso y cuotas de recursos a un nivel granular. Al separar los recursos en diferentes espacios de nombres, puedes:

Mejorar la organización: Agrupar cargas de trabajo relacionadas (por ejemplo, por proyecto, equipo o entorno, como desarrollo, prueba y producción).
Mejorar la seguridad y el control de acceso: Restringir qué usuarios o cuentas de servicio pueden ver o modificar recursos en un espacio de nombres en particular.
Simplificar la gestión de recursos: Aplicar límites de recursos, políticas de red y otras configuraciones a nivel de clúster de manera más efectiva.

Cuando listas recursos con la bandera -A (o --all-namespaces), notarás que los componentes pertenecientes al sistema de Kubernetes residen en el espacio de nombres kube-system, que está dedicado a la infraestructura a nivel de clúster. Las aplicaciones creadas por el usuario generalmente residen en el espacio de nombres default u otros espacios de nombres personalizados que definas.

Espacios de nombres y recursos

flowchart LR

    %% User interacts with the cluster via kube-apiserver
    User((Developer))
    User -->|kubectl get pods -A| API[kube-apiserver]

    %% Control Plane Subgraph
    subgraph ControlPlane[Control Plane]
        API
        ETCD[etcd]
        SCH[kube-scheduler]
        CTLM[kube-controller-manager]
    end

    API --> ETCD
    API --> SCH
    API --> CTLM

    %% kube-system namespace
    subgraph kube-system[Namespace: kube-system]
        SysDeployment[Deployment: coredns]
        SysPod1[Pod: coredns-xxx]
        SysService[Service: kube-dns]

        SysDeployment --> SysPod1
        SysService --> SysPod1
    end

    %% default namespace (renamed to avoid parse issues)
    subgraph defaultNs[Namespace: default]
        DefDeployment[Deployment: my-app]
        DefPod1[Pod: my-app-pod1]
        DefPod2[Pod: my-app-pod2]
        DefService[Service: my-app-service]

        DefDeployment --> DefPod1
        DefDeployment --> DefPod2
        DefService --> DefPod1
        DefService --> DefPod2
    end

    %% dev namespace
    subgraph dev[Namespace: dev]
        DevDeployment[Deployment: dev-app]
        DevPod[Pod: dev-app-pod]
        DevService[Service: dev-app-service]

        DevDeployment --> DevPod
        DevService --> DevPod
    end

    %% Demonstration of communication
    API --> kube-system
    API --> defaultNs
    API --> dev

En el diagrama:

El plano de control (Control Plane) gestiona todo el clúster, comunicándose con los nodos y controlando las cargas de trabajo.
Los espacios de nombres (Namespaces) (como kube-system, default y dev) separan lógicamente los recursos dentro del clúster.
- kube-system contiene componentes a nivel de sistema como CoreDNS y kube-dns.
- default se utiliza comúnmente para cargas de trabajo generales, aquí representado por un despliegue my-app.
- dev podría representar un entorno de desarrollo, aislado de las cargas de trabajo de producción.

Al ver los recursos en todos los espacios de nombres, obtienes una comprensión integral de cómo estas particiones lógicas ayudan a mantener un clúster organizado y seguro.

Ejemplos:

Listar todos los pods en todos los espacios de nombres:

kubectl get pods -A

Ejemplo de salida:

NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-787d4945fb-j8rhx           1/1     Running   0             20m
kube-system   etcd-minikube                      1/1     Running   0             20m
kube-system   kube-apiserver-minikube            1/1     Running   0             20m
kube-system   kube-controller-manager-minikube   1/1     Running   0             20m
kube-system   kube-proxy-xb9rz                   1/1     Running   0             20m
kube-system   kube-scheduler-minikube            1/1     Running   0             20m
kube-system   storage-provisioner                1/1     Running   1 (20m ago)   20m

Aquí, se ven todos los pods relacionados con el sistema que se ejecutan en el espacio de nombres kube-system. Si tuvieras otros despliegues o servicios en diferentes espacios de nombres, también aparecerían en esta lista, cada uno claramente delimitado por su espacio de nombres.

Listar todos los despliegues en todos los espacios de nombres:

kubectl get deployments -A

Ejemplo de salida:

NAMESPACE     NAME      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   coredns   1/1     1            1           20m

El despliegue coredns reside en el espacio de nombres kube-system.

Obtener una vista completa de todos los recursos en todos los espacios de nombres:

kubectl get all -A

Este comando muestra una vista general de pods, servicios y despliegues en diferentes espacios de nombres, lo que te ayuda a entender cómo se distribuyen estos recursos en todo el clúster.

Conclusiones clave:

Los espacios de nombres (Namespaces) proporcionan aislamiento y organización lógica dentro de un clúster de Kubernetes.
Diferentes componentes y recursos de Kubernetes se organizan en espacios de nombres específicos (por ejemplo, kube-system para servicios principales, default para cargas de trabajo generales y espacios de nombres adicionales que crees).
Al utilizar -A para ver los recursos en todos los espacios de nombres, obtienes información sobre cómo está estructurado tu clúster y cómo los espacios de nombres actúan como límites para la organización de recursos y el control de acceso.

Al entender cómo los espacios de nombres funcionan como entornos lógicos, puedes navegar, aislar y gestionar mejor tus cargas de trabajo y los recursos relacionados del clúster, especialmente a medida que escales tus despliegues e introduzcas más complejidad en tu entorno de Kubernetes.

Resumen

En este laboratorio, has iniciado y verificado un clúster local de Kubernetes utilizando Minikube, que ofrece una forma sencilla de configurar un entorno de Kubernetes de un solo nodo para aprendizaje y desarrollo. Has confirmado que el clúster de Minikube se ha iniciado correctamente, que el clúster local de Kubernetes está en funcionamiento, que el clúster está listo para usar y que tienes un clúster de un solo nodo con capacidades de plano de control. También has aprendido cómo verificar la configuración y la salud de tu clúster de Kubernetes utilizando comandos esenciales de kubectl, como kubectl cluster-info y kubectl get nodes, que te han ayudado a entender el estado actual y la conectividad del clúster.