Durante mis intentos de que los servicios en el cluster puedan tener persistencia encontre varias opciones que parecian
prometedoras es el caso del plugin Mayastor que apesar de mis intentos
no pude hacer que funcionara en LXD, buscando otras alernativas me decidí por NFS que desde el primer momento
no me dio errores y me ahorro bastante tiempo. Aqui los pasos de como usarlo con Microk8s
Instalación del servidor NFS en el equipo host
Dependiento la distribución Linux que se esté usando se debe instalar la paqueteria necesaria pero las opciones mas
importantes se encuentran en los archivos /etc/nfs.conf y /etc/exports veamos el primero:
1
2
3
4
5
|
# archivo /etc/nfs.conf
...
[nfsd]
host = 10.239.143.1
...
|
En este archivo solo es necesario indicar la ip que el servicio NFSD usará. La IP 10.239.143.1 corresponde a la interfaz lxdbr0 que es la interfaz que nos permite comunicarnos con el clúster
si usamos el comando:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
$ lxc list
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
| master | RUNNING | 10.239.143.98 (eth0) | fd42:e01c:70e5:5c30:216:3eff:fe89:cb44 (eth0) | CONTAINER | 1 |
| | | 10.1.219.64 (vxlan.calico) | | | |
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
| node2 | RUNNING | 10.239.143.172 (eth0) | fd42:e01c:70e5:5c30:216:3eff:fe82:ca09 (eth0) | CONTAINER | 0 |
| | | 10.1.104.0 (vxlan.calico) | | | |
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
| node3 | RUNNING | 10.239.143.235 (eth0) | fd42:e01c:70e5:5c30:216:3eff:fe6f:8e95 (eth0) | CONTAINER | 0 |
| | | 10.1.135.0 (vxlan.calico) | | | |
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
| node4 | RUNNING | 10.239.143.95 (eth0) | fd42:e01c:70e5:5c30:216:3eff:fe61:9890 (eth0) | CONTAINER | 0 |
| | | 10.1.3.64 (vxlan.calico) | | | |
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
| node5 | RUNNING | 10.239.143.104 (eth0) | fd42:e01c:70e5:5c30:216:3eff:fec1:b451 (eth0) | CONTAINER | 0 |
| | | 10.1.33.128 (vxlan.calico) | | | |
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
| node6 | RUNNING | 10.239.143.17 (eth0) | fd42:e01c:70e5:5c30:216:3eff:fe74:7a90 (eth0) | CONTAINER | 0 |
| | | 10.1.139.0 (vxlan.calico) | | | |
+--------+---------+----------------------------+-----------------------------------------------+-----------+-----------+
|
Veremos que las IPs de los nodos del cluster están en el mismo segmento de la IP de la interfaz lxdbr0.
El segundo archivo /etc/exports contiene los directorios que se usarán para el almacenamiento NFS:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
$ mkdir -p /srv/nfs/kube
$ chmod -R 0777 /srv/nfs
$ cat /etc/exports
# /etc/exports - exports(5) - directories exported to NFS clients
#
# Example for NFSv3:
# /srv/home hostname1(rw,sync) hostname2(ro,sync)
# Example for NFSv4:
# /srv/nfs4 hostname1(rw,sync,fsid=0)
# /srv/nfs4/home hostname1(rw,sync,nohide)
# Using Kerberos and integrity checking:
# /srv/nfs4 *(rw,sync,sec=krb5i,fsid=0)
# /srv/nfs4/home *(rw,sync,sec=krb5i,nohide)
#
# Use `exportfs -arv` to reload.
/srv/nfs 10.239.143.0/24(rw,sync,crossmnt,fsid=0)
/srv/nfs/kube 10.239.143.0/24(rw,sync,no_subtree_check,no_all_squash)
$ exportfs -arv
|
Como se puede observar se tiene 2 directorios compartidos solo en la red 10.239.143.0/24 y los permisos de esos directorios son:
1
2
3
4
5
|
$ ls -alh /srv/nfs
total 12K
drwxrwxrwx 3 root root 4,0K ene 21 01:32 .
drwxr-xr-x 5 root root 4,0K ene 21 01:32 ..
drwxrwxrwx 2 root root 4,0K ene 21 01:32 kube
|
No fue necesario cambiar los permisos a nobody:nobody y es toda la configuración necesaria en el host. Podemos realizar una prueba montando el directorio /srv/nfs desde un nodo del cluster con el comando:
1
2
3
4
5
|
$ mkdir /tmp/test
$ mount -t nfs 10.239.143.1:/srv/nfs /tmp/test
# verificamos
$ mount | grep nfs
|
Podemos crear un archivo en /tmp/test para verificar los permisos de escritura.
Instalación del addon NFS en el clúster
Ya que estamos seguros de que el servicio NFS funciona correctamente en el host y en los nodos del cluster instalamos el addon NFS siguiendo la guìa oficial de Microk8s todo en el nodo master.
La guía oficial de NFS
La guía oficial del addon NFS tambien muestra como instalar y configurar el servidor NFS.
No olvidemos que este addon funcionarà correctamente solo si tenemos los paquetes NFS instalados en cada nodo del clúster. En la
primera parte de la instalación del clúster se instalo el paquete nfs-utils
en el nodo master y como se usó el snapshot de ese nodo todos los nodos del cluster tienen nfs instalado.
Creación del Storage Class
Segun la guía oficial el Storage Class que se muestra deberia funcionar correctamente lo cual en la práctica no sucedió y estube muchas horas tratando de encontrar la causa. El Storage Class que funcionó es este:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-csi
provisioner: nfs.csi.k8s.io
parameters:
server: 10.239.143.1
share: /srv/nfs
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
- soft
- nolock
- nfsvers=3
|
Las opciones soft,nolock,nfsvers=3 eran las correctas. Ajustando el Storage Class ahora cada servicio tendra persistencia desde cualquier nodo del cluster y ya podemos realizar las pruebas sugeridas
en la guia oficial.
