Última revisión de 14:17 15 mar 2016

Esta página tiene apuntes sobre mis indagaciones en esta tecnología. Muy probablemente esté incompleta la información y puede que haya algunos malentendidos.

Introducción

Kubernetes es una capa de administración de la ejecución de contenedores docker. Tiene una estructura de un master y varios servidores de ejecución de contenedores llamados minions. A través del master se gestiona la subida de imagenes y la ejecución de contenedores, y es el propipio master el que decide en que minion se va a ejecuar cada contenedor.

Los contenedores se agrupan en pods, y estos contenedores agrupados se ejecutan siempre en la mismo minion, lo cual es interesante cuando los contenedores tienen que compartir el mismo almacenamiento, o la misma red.

Como probarlo

En la página de Getting Started de kubernetes ofrecen varias formas de probarlo. La que me ha parecido más sencilla por estar más familiarizado es la de vagrant, que despliega un master y N minions para hacer pruebas. Explican muy bien como se hace la instalación y solo hace falta tener instalado Vagrant y Virtualbox para tener un cluster de kubernetes funcionando. Eso si, los servidores virtuales con el servicio de kubernetes son Fedora ,y se instalan usando Saltstack

Si trabajamos en un linux podemos montarnos un Kuberentes local de un solo nodo (nuestra máquina). En la página Kubernetes en local se explica como hacerlo.

Trabajando con Kubernetes

Para la plataforma de pruebas que se instala con Vagrant viene ya preparado con un comando para hacer las pruebas. El comando de control es

$ cluster/kubectl.sh 

Pero también podemos usar el kubectl que tengamos instalado de antes, ya que la configuración al final se almacena en ~/.kube/config.

Si tenemos instalado gcloud, como se explica en la página de Google Cloud Contenedores, ya tendremos el comando kubectl, y al ejecutar el vagrant tendremos una nueva configuración para "vagrant"

Kubectl

Es el comando para trabajar con kubernetes, independientemente de donde esté la infraestructura, ya sea en vagrant, en local, en google cloud, etc.

Las configuracines están en ~/.kube/config, y en este fichero se pueden hacer referencia a varios contextos de kubernetes. Desde línea de comandos podemos ver los diferentes contextos que tenemos configurados:

$ kubectl config view

Esa configuración está dividida en - clusters - users - contexts Cada contexto hace referencia a un cluster y a un usuario. Tambié hay un valor "current-context" que nos indica que contexto estamos usando por defecto cada vez que ejecutamos un comando kubectl. Si queremos cambiar de contexto solo tenemos que ejecutar:

$ kubectl config use-context <contexto>

Para borrar contextos que ya no estemos usando solo he encontrado la forma de editar a mano el fichero de configuración.

Ficheros de configuración de kuebernetes (kubeconfigs)

Son ficheros en formato .json o .yaml que definen objetos de kubernetes. Muy cómodos para tenerlos en un repositorio de versiones y ejecutarlos cunaod nos hagan falta.

De esa forma podemos tener versionados la forma en la que arrancar nuestra aplicaciones en kubernetes y podemos arrancarlas en cualquier cluster que tengamos disponible.

Estos ficheros se ejecutan con el comando

$ kubectl create -f <kubeconfig>[.json|.yaml]

El ejemplo del guestbook

Con el vagrant que nos hemos instalado vienen muchos ejemplos que nos pueden ser de utilidad. En mi caso me he fijado en el del Guest Book del que podemos seguir este "guiaburros"

Siguiéndolo lo primero que he hecho ha sido ejecutar el comando:

$ cluster/kubectl.sh create -f examples/guestbook/redis-master-controller.json

Recursos de kubernetes

Algunos de los que he ido descubriendo:

Pods

Este nombre viene de referirse a un grupo de contenedores de docker que corren como una unidad o una entidad única. Lo de Pod viene porque el logo de docker es una ballena, y los grupos de ballenas en ingles son pod of whales... que cachondos.

Cuando se define un pod se le pueden especificar varios contenedores que van a correr juntos, asegurandote que van a estar siempre corriendo en la mísma máquina del cluster de kubernetes

ReplicationController (rc)

Este recurso sirve para asegurarse que cierto numero de replicas de un Pod están arrancadas y funcionando, pero por la forma de trabajar de kubernetes te recomiendan que siempre uses un rc para levantar un pod (aunque sea uno solo).

Jobs

Los jobs se aseguran que ejecutan ciertos pods y estos terminan satisfactoraimente. Se diferencian de los RC en que en estos se espera que el pod termine (procesos), y en los RC se asegura de que los pods estén corriendo constantemente (orientado a servicios)

Services

Los servicios enlazan mediante una IP interna del cluster de kuberentes los servicios que exponen los pods que están arrancados. Los pods tienen una vida limitada, y cada vez que arrancan de nuevo es un contenedor diferente, y seguramente con IP diferentes.

En un servicio se define que puerto se quiere exponer al resto de contenedores y a donde redirige las peticiones que llegan mediante el uso de los selectores de los pods. El ejemplo más claro es cuando creas un RC con 5 replicas de un POD que levanta un servicio httpd. Cada uno de esos contenedores levanta su propio puerto 80, y cada uno tiene su IP. Con un servicio se puede crear un balanceo entre los diferentes contenedores y se reparte la carga de peticiones entre cada uno de ellos.

Además, definiendo un servicio también se consigue que el resto de contenedores que están arrancados en un cluster tengan una entrada de "hosts" ( o dns... por estudiar) que permita hacer referencia entre unos y otros. Por ejemplo, crear un servicio para un mysql y poder hacer referencia desde un contenedor que arranca php-fpm