Cómo construir un clúster doméstico de Turing Pi 2

Tabla de contenido

• La historia
• El plan
  • Turing Pi 2
• La configuración
• El parpadeo
  • El almacenamiento
  • Los Kubernetes
• Las aplicaciones
• La construcción final
• El futuro
• El fin

La historia

En junio de 2022, me encontré con un Kickstarter sobre una placa capaz de tener hasta 4 módulos de cómputo Raspberry Pi 4 a la vez.

Sin pensarlo mucho, decidí respaldar el proyecto y comprar la placa.

Dos años después, mi Turing Pi 2 todavía estaba sin abrir en su caja en un estante. La vida se había interpuesto en mi camino y no estaba seguro de por qué lo había comprado en primer lugar.

Sin embargo, finalmente decidí intentarlo. Quería aprender más sobre clustering y nunca antes había creado un cluster de Kubernetes completo desde cero. Entonces, me puse a gastar y adquirí tres Raspberry Pi 4 (8 GB de RAM, 8 GB de almacenamiento interno) y una Nvidia Jetson Nano (4 GB).

Dada la versatilidad de la placa, pude combinar distintos módulos de cómputo. Decidí incluir un Jetson Nano, pensando que podría permitirme experimentar con controladores CUDA en el futuro y profundizar en el aprendizaje automático. ¿Quién sabe? Quizás incluso termine alojando mi propio asistente GPT en este clúster de Kubernetes.
(Spoilers: It didn't happen)

El plan

Mi plan inicial incluía las 3 Pi 4 CM y el Jetson Nano alojados en la placa. Además, tenía pensado utilizar una unidad SSD de 1 TB para el almacenamiento y una tarjeta Wi-Fi para el acceso a Internet. Sin embargo, después de encontrarme con numerosas dificultades con el proceso de configuración del Jetson Nano y su mala documentación, decidí devolverlo. En su lugar, opté por una cuarta Raspberry Pi 4.

Además, tenía una vieja Raspberry Pi 4 con 4 GB de RAM, así que decidí incorporarla como un quinto nodo.

Turing Pi 2

La Turing Pi 2 es una placa con formato Mini ITX que puede alojar hasta cuatro módulos de cómputo Raspberry Pi (también compatible con Jetson Nanos y un módulo de cómputo Turing). Cuenta con un puerto PCI Express, dos puertos NVME, dos puertos SATA y un puerto USB para flashear los módulos de cómputo.

• Nodo 1 :

  • Puerto USB 2.0 (para flashear los módulos de cómputo)

  • Puerto HDMI (para depuración)

  • Puerto PCI Express (para la tarjeta Wi-Fi)

    
    

• Nodo 2 :

  • Usaría este para almacenamiento NVME, pero no es compatible con Raspberry Pi 4s.

    
    

• Nodo 3 :

  • Sin embargo, aquí se pueden utilizar los puertos SATA, por lo que este nodo tendrá la unidad compartida NFS.

    
    

• Nodo 4 :

  • Puertos USB 3.0 (si alguna vez los necesito).

    
    

• Mi vieja frambuesa :

  • Sería el nodo maestro de Kubernetes. No hay ninguna razón especial; puedo pensar mejor en mi configuración de esta manera

  
  

En última instancia, la idea es alojar un servidor multimedia con algunos complementos.

La configuración

Ha pasado un tiempo desde que armé una computadora y fue la primera vez que jugué con módulos de cómputo y sus adaptadores, así que fue muy divertido el fin de semana. Como mi billetera estaba caliente pero no quemando, pensé: ¿por qué diablos no agregarle una linda carcasa?

Dado el formato Mini ITX de la placa, pude colocarla en cualquier elegante caja ITX que pudiera encontrar en Amazon. La Qube 500 me ayudó a superarlo. Ya estaba armando un clúster DIY, y la mejor caja para algo así era una DIY también.

También agregué una fuente de alimentación de 650 W (una exageración total), una pequeña tarjeta Wi-Fi Mini PCI Express y un SSD SATA de 1 TB.

El montaje del "objeto" fue bastante sencillo. Un poco de pasta térmica entre los módulos de cómputo y sus disipadores de calor y unirlos con sus adaptadores antes de colocarlos en orden en la placa Turing;

Mencioné el orden porque era una parte importante del proyecto. El Turing Pi 2 ofrece la gestión de sus puertos distribuidos en todos los módulos de cómputo. En este caso, el PCI Express 1 fue administrado por el primer nodo, mientras que la unidad SSD fue administrada por el tercero. El segundo podría manejar el puerto NVME y el cuarto el otro SSD, si mal no recuerdo, pero no los necesitaba en ese momento.

El parpadeo

He instalado Raspberry Pis antes, pero nunca módulos de cómputo. El Turing Pi 2 tiene un puerto USB en la parte posterior que se utiliza para instalar los módulos de cómputo.

Lamentablemente, intenté usar un cable USB A a USB A que no era un cable de transferencia de datos, así que mientras esperaba que Amazon me entregara un cable, encontré otra forma de flashear los módulos de cómputo.

El Turing Pi 2 tiene una herramienta CLI que puede usarse no solo para actualizar los módulos de cómputo sino también para administrar su energía, reiniciarlos, verificar algunas estadísticas, etc.

El comando utilizado para instalar los módulos de cómputo fue:

 tpi flash -i /path/to/image -n {nodes 1 to 4}

Pensé que era un proceso bastante sencillo antes de darme cuenta de que la imagen de Raspbian no viene con SSH habilitado de forma predeterminada.

Por supuesto, esto no es responsabilidad de Turing. Debería haber esperado a que llegara ese cable, pero bueno.

Para solucionarlo, tuve que montar la imagen en mi máquina local y agregar un archivo vacío llamado ssh en la partición de arranque. Esto habilitaría SSH de manera predeterminada.

 sudo mkdir /mnt/pi-boot sudo mount /dev/sdX1 /mnt/pi-boot sudo touch /mnt/pi-boot/ssh sudo umount /mnt/pi-boot

Ahora, todos mis pis estaban listos para usarse. Los conecté a la red y comencé a configurarlos. Había poco que configurar ya que los iba a usar como nodos de Kubernetes.

Pero cosas como vim y actualizar el sistema eran necesarias.

Esto también me dio la oportunidad de aprender a usar Tmux , la mejor herramienta que he aprendido en mucho tiempo.

El almacenamiento

Si recuerdas algunos párrafos más arriba, mencioné que el tercer nodo se usaría para la unidad compartida NFS. Tenía la unidad SSD de 1 TB que iba a usar para este propósito. Tuve que formatearla y montarla en el tercer nodo.

Pero también necesitaba instalar el servidor NFS en este nodo y configurarlo en los demás nodos. ¿Es recomendable para un entorno de producción? No, pero es un clúster doméstico, así que no me preocupa demasiado.

Estos son los pasos que seguí para configurar el servidor NFS:

 pi@turing-03:/mnt/ssd/data $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 953.9G 0 disk /mnt/ssd mmcblk0 179:0 0 7.3G 0 disk ├─mmcblk0p1 179:1 0 512M 0 part /boot/firmware └─mmcblk0p2 179:2 0 6.8G 0 part / mmcblk0boot0 179:32 0 4M 1 disk mmcblk0boot1 179:64 0 4M 1 disk

Primero, verifiqué que la unidad estuviera montada correctamente. Luego instalé el servidor NFS:

 sudo mkdir /mnt/nfs_share sudo mount /dev/sda /mnt/nfs_share

Lo agregué al archivo fstab para asegurarme de que estuviera montado en el arranque:

(agregando la siguiente línea al archivo /etc/fstab )

 echo '/dev/sda /mnt/ssd ext4 defaults 0 0' | sudo tee -a /etc/fstab

Ahora, instalando nfs-kernel-server:

 sudo apt update sudo apt install nfs-kernel-server

Y agregando mi unidad al archivo /etc/exports :

 echo '/mnt/ssd *(rw,sync,no_subtree_check,no_root_squash)' | sudo tee -a /etc/exports

Ahora, en los otros nodos, tuve que instalar nfs-common:

 sudo apt update sudo apt install nfs-common

Y conectando la unidad a cada nodo:

 sudo mount -t nfs {IP-for-the-drives-node}:/mnt/ssd /mnt

Neofetch está instalado en todos los nodos porque soy elegante.

El clúster de Kubernetes

Nunca había configurado un clúster de Kubernetes desde cero antes, pero he estado viendo muchos videos de Jeff Geerling sobre el tema... Esto es experiencia suficiente, ¿verdad?

Jeff me llevó a K3s usando Ansible , una distribución liviana de Kubernetes que es perfecta para mi clúster doméstico y una forma predefinida de instalarlo porque no tengo requisitos previos ni la idea de cómo configurarlo de otra manera.

La instalación fue bastante sencilla. Tuve que instalarlo en todos los nodos, pero me aseguré de que el nodo maestro fuera el primero en instalarse.

Primero, cloné el repositorio k3s-ansible:

 git clone https://github.com/k3s-io/k3s-ansible.git

Luego tuve que configurar el archivo de inventario. Mi nodo maestro, como mencioné antes, era mi antigua Raspberry Pi 4. Por lo tanto, tuve que asegurarme de que fuera el primero en el archivo de inventario. También tuve que asegurarme de que los otros nodos estuvieran en los grupos correctos:

 k3s_cluster: children: server: hosts: 192.168.2.105: agent: hosts: 192.168.2.101: 192.168.2.102: 192.168.2.103: 192.168.2.104:

En ese mismo archivo, tuve que configurar un token de cifrado. El archivo indica cómo hacerlo, por lo que no entraré en detalles aquí.

Luego tuve que ejecutar el libro de jugadas:

 cd k3s-ansible ansible-playbook playbooks/site.yml -i inventory.yml

Eso es todo. En cuanto a la instalación, tenía un clúster de Kubernetes en funcionamiento. Tuve que instalar K9s en mi máquina local para administrar el clúster y vincularlo al archivo ./kube/config .

Las aplicaciones

Por último, tuve que instalar las aplicaciones que quería ejecutar en el clúster. Tenía algunas ideas sobre lo que quería.

• Quería tener un servidor multimedia con descargas programadas.

• Una instancia de Pi-hole al DNS de mi red y bloquea todos los anuncios en todos los dispositivos en casa.

• Una instancia de Retroarch para jugar algunos juegos antiguos y compartir los juegos guardados en la red de mi casa (te estoy mirando a ti, Megaman Battle Network 6 en todos mis dispositivos)

Ahí es donde entra mi repositorio .

Para el servidor multimedia, decidí utilizar:

• Sonar
• Radar
• Merodeador
• Medusa
• Qbittorrent

A modo de ejemplo, te mostraré cómo instalé Sonarr con kubectl . Las demás aplicaciones se instalaron de forma similar.

Para cada aplicación, creé 3 archivos:

• deployment.yaml es la configuración para cada uno de los pods que ejecutan la aplicación

   apiVersion: apps/v1 kind: Deployment metadata: name: sonarr spec: replicas: 1 selector: matchLabels: app: sonarr template: metadata: labels: app: sonarr spec: containers: - name: sonarr image: linuxserver/sonarr ports: - containerPort: 8989 env: - name: PUID value: "911" - name: PGID value: "911" - name: TZ value: "Europe/Amsterdam" volumeMounts: - mountPath: /data name: data - name: config mountPath: /config volumes: - name: data persistentVolumeClaim: claimName: nfs-pvc - name: config persistentVolumeClaim: claimName: nfs-config-pvc

• service.yaml es la configuración del servicio que expondrá la aplicación al clúster

   apiVersion: v1 kind: Service metadata: name: sonarr spec: selector: app: sonarr ports: - port: 80 targetPort: 8989 type: ClusterIP

• ingress.yaml y esta es la configuración para el ingreso que expondrá la aplicación a mi red

  
  

Luego los implementamos todos usando kubectl :

 kubectl apply -f sonarr/deployment.yaml kubectl apply -f sonarr/service.yaml kubectl apply -f sonarr/ingress.yaml

Como puedes ver, estoy usando almacenamiento persistente respaldado por NFS para los datos y la configuración de las aplicaciones.

En el repositorio, puedes encontrar los archivos nfs-pv.yaml y nfs-pvc.yaml que utilicé para crear el almacenamiento NFS.

Además, creé otro reclamo de volumen persistente para la configuración de las aplicaciones.

La construcción final

Aunque la carcasa se ve increíble, es un poco demasiado grande para un Raspberry Pi Cluster. Una carcasa Mini ITX también habría sido adecuada para mis necesidades, pero tengo que admitir que soy un fanático de las cosas caseras.

Además, soy un fanático de los LED en general. No agregué más luces a la caja, pero creo que la placa ya hace un buen trabajo. Desafortunadamente, los pines del ventilador no eran compatibles con la placa y no compré un controlador de ventilador ni un pin para la placa base. Es posible que lo haga en el futuro.

A veces, simplemente hay que sentarse y disfrutar de la vista.

Y finalmente, el Turing Pi 2 Home Cluster está en funcionamiento, y mi casa ya no es un desastre.

El futuro

Sólo el tiempo dirá qué haré con este cluster.

Sin embargo, he estado pensando en agregar Prometheus y Grafana para tener algunas métricas y gráficos agradables para verificar en el clúster.

Migrar todos mis archivos de Kubernetes a Helm también sería una buena idea.

Por último, la instancia de Retroarch todavía está en desarrollo. Tal vez decir "en desarrollo" sea un poco optimista, dado que el módulo se encuentra en estado CrashLoopBackOff. Pero llegaré allí.

El fin

Si has llegado al final de esta publicación, te agradezco el tiempo que me has dedicado. Espero que la hayas disfrutado tanto como yo, tanto armando el cluster como escribiendo sobre él.