Una de las maneras más sencillas de crear un entorno de desarrollo para Kubernetes es usando Vagrant y Ansible.

En el Vagrantfile definimos un conjunto de tres máquinas, llamadas node1, node2 y node3.

Una vez las máquinas están levantadas, desde el servidor de Ansible uso ssh-copy-id para habilitar el login sin password de Ansible en los nodos del clúster.

A partir de aquí, tanto la instalación de los prerequisitos como la inicialización del clúster funcionan sin problemas; sin embargo, al intentar desplegar una aplicación, los pods se quedan en el estado CreatingContainer.

Análisis de logs

Analizando los logs el problema apuntaba a un problema de red con Weave.net. Al parecer, cada pod de Weave Net obtiene una lista de los nodos que componen el clúster e intenta conectar con los pods que corren en cada nodo. Esto implica que también intenta conectar consigo mismo, lo que genera un error.

[...] connection shutting down due to error: Cannot connect to ourself

Sin embargo, este error es “normal” (hay alguna queja en internet).

Aunque el error al intentar conectar consigo mismo es inocuo, otro error debido a colisión de nombres no lo es:

[...] connection shutting down due to error: local and remote peer names collision

Junto al mensaje de error aparecen las MAC address de las interfaces de red generadas por Weave, que coincidían en los tres nodos del clúster.

Finalmente he encontrado la explicación y la solución en Quorum not being reached on machines with identical IDs

Causa

Las tres máquinas se han generado a partir de la misma imagen de Vagrant, por lo que el identificador de máquina en los ficheros /etc/machine-id y /var/lib/dbus/machine-id eran el mismo en los tres nodos.

De alguna manera, la MAC de la interfaz virtual weave se genera a partir del machine-id (que debería ser único). Pero en este caso, al ser el mismo en las tres máquinas virtuales, la MAC del interfaz weave también coincidía en los pods generados por Weave Net. Por este motivo se obtenía el error de colisión de nombres.

$ ip address show
...
6: weave: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue state UP group default qlen 1000
    link/ether 76:2f:d2:46:f8:94 brd ff:ff:ff:ff:ff:ff
    inet 10.44.0.1/12 brd 10.47.255.255 scope global weave
       valid_lft forever preferred_lft forever
...

Solución

La solución es elimnar el machine-id y generar uno nuevo:

sudo rm /etc/machine-id
sudo rm /var/lib/dbus/machine-id
sudo systemd-machine-id-setup

Tras reiniciar los nodos del clúster, el pod de prueba del clúster se ha iniciado con normalidad.

Update (2018-08-10)

En la documentación oficial de Kubernetes sobre cómo instalar kubeadm se incluye una sección específica sobre este tema: Verify the MAC address and product_uuid are unique for every node. Además, se hace referencia a que, en caso contrario, la instalación puede fallar, haciendo referencia a este bug documentado en GitHub que hace referencia a Weave.net: The product_uuid and the hostname should be unique across nodes.