Instalación de Kubernetes: mini guía dedicada a la instalación local de Kubernetes

Instalar y lanzar Kubernetes localmente es la mejor manera de ver y comprender todos los componentes de Kubernetes.

Instalar y lanzar Kubernetes localmente es la mejor manera de ver y comprender todos los componentes de Kubernetes y la forma en que se integran.

Kubernetes funciona en casi todas partes, con diferentes versiones de Linux y gracias a diferentes servicios en la nube (link articolo «Servizi Cloud Kubernetes»). La compatibilidad de esta herramienta con diferentes sistemas operativos utilizados en todo el mundo representa uno de los principales puntos fuertes de este instrumento.

Si echas un vistazo a la web oficial de Kubernetes encontrarás una página con los documentos que resumen el estado de las diversas combinaciones de distribución del sistema, así como una serie de guías introductorias que pueden ayudarte a realizar una correcta instalación local de Kubernetes.

Dicho esto, Kubernetes se puede distribuir de forma autónoma, la única necesidad es tener Linux con Docker instalado en su propia máquina o en una máquina virtual.

Antes de entrar en detalle, vamos a repasar la arquitectura de Kubernetes porque será útil durante la lectura:

  • El maestro es el «plan de control» de Kubernetes y tiene una serie de componentes en cuanto a clústeres, incluyendo un servidor de API que es utilizado por las herramientas para interactuar con el propio clúster (por ejemplo kubectl).
  • Cada nodo tiene un servicio kubelet que recibe órdenes del maestro y un runtime en el contenedor (incluido pero no limitado por un Docker) con el que interactúa para gestionar las peticiones del contenedor. Veámoslo en acción y describamos más a fondo los componentes mientras los configuramos.

Instalación local de Kubernetes

Como se ha descrito anteriormente en la guía introductoria, solo hay tres pasos para obtener un clúster autónomo que esté activo y funcionando. Veámoslos juntos.

Paso uno: ejecutar el etcd

docker run -d \

    –net=host \

    gcr.io/google_containers/etcd:2.0.9 \

    /usr/local/bin/etcd \

        –addr=127.0.0.1:4001 \

        –bind-addr=0.0.0.0:4001 \

        –data-dir=/var/etcd/data

Kubernets almacena de forma fiable el estado principal y la configuración a través de etcd. Los diferentes componentes maestros «vigilan» estos datos y actúan en consecuencia, por ejemplo, lanzando un nuevo contenedor para mantener un número deseado de copias.

Segundo paso: ejecutar el maestro

docker run -d \

    –net=host \

    -v /var/run/docker.sock:/var/run/docker.sock \

    jetstack/hyperkube:v0.20.1 \

    /hyperkube kubelet \

        –api_servers=http://localhost:8080 \

        –v=2 \

        –address=0.0.0.0 \

        –enable_server \

        –hostname_override=127.0.0.1 \

        –config=/etc/kubernetes/manifests

Este paso ejecuta un contenedor kubelet, que en este despliegue local ejecuta a su vez los componentes en clúster que forman el «plano de control» principal de Kubernetes.

  • API del servidor: proporciona la API RESTful de Kubernetes para gestionar la configuración del clúster, con el apoyo del almacén de datos etcd.
  • Programador: coloca los pods en los nodos basándose en reglas (por ejemplo, etiquetas). En esta etapa, el programador es simple, pero, como la mayoría de los componentes de Kubernetes, es configurable.
  • Controller Manager: gestiona todas las funciones a nivel de clúster, incluyendo la creación/actualización de puntos finales, la detección, gestión y monitorización de nodos y la gestión de pods.

Tercer paso: ejecutar el proxy de servicio

docker run -d \

   –net=host \

   –privileged \

   jetstack/hyperkube:v0.20.1 \

   /hyperkube proxy \

        –master=http://127.0.0.1:8080 \

        –v=2

El proxy ( kube-proxy ) se ejecuta en cada nodo y proporciona un proxy de red simple y capacidades de equilibrio de carga. Este proxy permite exponer los servicios con una dirección de red y un nombre estables.

En este punto deberíamos tener un cluster Kubernetes ejecutable localmente. Para asegurarnos de que todo está bien, podemos utilizar Docker ps para comprobar las instancias de contenedor en ejecución; debería tener el aspecto que se ve en la siguiente imagen (se han omitido varias columnas por razones de brevedad):

IMAGENCOMANDO
jetstack/hyperkube:v0.20.1/hyperkube proxy
jetstack/hyperkube:v0.20.1/hyperkube scheduler
jetstack/hyperkube:v0.20.1/hyperkube apiserver
jetstack/hyperkube:v0.20.1/hyperkube controller
gcr.io/google_containers/pause:0.8.0/pause
jetstack/hyperkube:v0.20.1/hyperkube kubelet
gcr.io/google_containers/etcd:2.0.9/usr/local/bin/etcd

alt tag = Instalación de Kubernetes

Para interactuar con el clúster necesitamos utilizar la herramienta CLI kubectl. Se puede descargar pre-construida directamente desde Google (nota 0.20.1 es la última versión en el momento de escribir).

wget https://storage.googleapis.com/kubernetes-release/release/v0.20.1/bin/linux/amd64/kubectl

chmod u+x kubetctl

sudo  mv kubectl /usr/local/bin/

La forma más rápida de iniciar un contenedor en el clúster es utilizar el comando kubectl run. Así, por ejemplo, para iniciar un contenedor Nginx, puedes utilizar el comando y hacer referencia al nombre de la imagen del contenedor.

kubectl run web –image=nginx

Aunque esto es conveniente y adecuado para la experimentación, los recursos como los pods se crean generalmente utilizando artefactos de configuración que pueden tener ventajas por el hecho de que pueden ser versionados con GIT, facilitando así, por ejemplo, los rollbacks.

Si se usa YAML (o JSON), se declara un pod y su estado deseado; a continuación, el trabajo de Kubernetes es garantizar que este pod siempre exista de acuerdo con esta especificación hasta que se elimine.

Hay aquí un ejemplo sencillo de configuración de un pod para ese pod nginx (archivo nginx-pod.yml).

apiVersion: v1

kind: Pod

metadata:

 name: nginx

 labels:

   app: web

spec:

 containers:

   – name: nginx

     image: nginx

Esto ejecuta la misma imagen de contenedor (nginx) que la anterior, pero en este caso la configuración de recursos específica, algunos metadatos adicionales, por ejemplo, una etiqueta (par clave/valor) que asigna a este pod una etiqueta del tipo «app» de «web».

kubectl create -f nginx-pod.yml

Kubernetes, en segundo plano, instruirá a un nodo para que extraiga la imagen del contenedor iniciando el mismo contenedor a su vez.

En este punto volverá a utilizar kubectl unos instantes después y debería poder ver el pod de nginx en funcionamiento.

$ kubectl get pods

POD    IP              CONTAINER(S)  IMAGE(S)   HOST                     LABELS     STATUS    CREATED

web1   172.17.0.1      nginx         nginx      127.0.0.1/127.0.0.1      app=web  Running   About a minute web1
Como se ha solicitado, un contenedor Nginx se está ejecutando en un pod (web1-qtlc1 en este caso) y también se le ha asignado una dirección IP. En Kubernetes, a cada pod se le asigna una dirección IP de una red interna y esto significa que los pods pueden comunicarse entre sí, sin embargo, en este caso hemos desplegado Kubernetes con Docker usando la red del host (-net=host) y estas direcciones IP serán accesibles localmente.

Share: Facebook Twitter Linkedin

Comments