{"id":307,"date":"2020-07-30T22:08:10","date_gmt":"2020-07-30T20:08:10","guid":{"rendered":"https:\/\/www.javisalas.com\/?p=307"},"modified":"2021-06-27T10:36:39","modified_gmt":"2021-06-27T08:36:39","slug":"instala-y-configura-k3s-en-ha-o-single-server","status":"publish","type":"post","link":"https:\/\/www.javisalas.com\/index.php\/2020\/07\/30\/instala-y-configura-k3s-en-ha-o-single-server\/","title":{"rendered":"Instala y configura K3s en HA o Single Master"},"content":{"rendered":"\n

Introducci\u00f3n<\/h2>\n\n\n\n

Continuamos con la instalaci\u00f3n de nuestro hosting privado. Llega el momento de desplegar el software de Kubernetes K3s<\/a>. Como ya coment\u00e9 en el primer art\u00edculo<\/a> de \u00e9sta colecci\u00f3n, aunque podr\u00edamos desplegar sin problemas el sistema de Google K8s<\/a>, \u00e9sta version lite<\/em> est\u00e1 optimizada para IOT<\/a> y sobre todo con un gran soporte para placas ARM.<\/p>\n\n\n\n

\u00bfAlta disponibilidad (HA) o Single Master?<\/h2>\n\n\n\n

No es una elecci\u00f3n crucial, en realidad, la primera version de mi cluster contaba con un solo nodo master<\/em> y cuatro workers<\/em>. Con el tiempo, y sobre todo, con al compra de placas nuevas fui cambiando la configuraci\u00f3n, pasando a dejar la placa con mas recursos como master<\/em> y el resto como workers<\/em>; sin embargo, tras observar como se comportaban, decid\u00ed que no hac\u00eda falta poner las placas mas potentes como master<\/em>, ya que una Raspberry 3 puede gestionar perfectamente el cluster y que merece la pena dejar las que tienen mas recursos para ejecutar los pods.<\/p>\n\n\n\n\n\n\n\n\n

Tener dos nodos master<\/em> no va a dotar a nuestra infraestructura de mas velocidad o capacidad de ejecutar pods, sin embargo si nos va a permitir tener una tolerancia a fallos en uno de los nodos maestros bien sea por un fallo hardware, un bug en el software o simplemente una actualizaci\u00f3n. Por lo tanto la decisi\u00f3n depende del numero de Raspberrys que tengamos; para un despliegue en HA recomendar\u00eda un m\u00ednimo de 4 placas: dos que har\u00edan las veces de master<\/em> y las dos restantes de workers<\/em>. \u00bfPodr\u00edamos tener solo un worker? definitivamente si, ya que podr\u00edamos activar la opci\u00f3n de ejecutar pods tambi\u00e9n en los nodos master<\/em> como ya veremos m\u00e1s adelante, pero personalmente no me parece una buena idea.<\/p>\n\n\n\n

Instalaci\u00f3n<\/h2>\n\n\n\n

Primero voy a detallar la instalaci\u00f3n de los Master Nodes<\/em> ya sea como Single Master<\/em> o bien en High Availability<\/em>. El despliegue de los Workers Nodes<\/em> ser\u00eda com\u00fan a ambos entornos.<\/p>\n\n\n\n

Single Master<\/h3>\n\n\n\n

La estructura de \u00e9sta instalaci\u00f3n ser\u00eda la que podemos ver a continuaci\u00f3n:<\/p>\n\n\n\n

\"\"
Despliegue de K3s con un solo master node<\/em><\/figcaption><\/figure>\n\n\n\n

Los elementos que constituyen la instalaci\u00f3n son:<\/p>\n\n\n\n

  1. K3sUser<\/strong>: Es nuestro servidor o port\u00e1til donde tenemos instalado kubectl, que es la utilidad de Kubernetes para gestionar el cluster por l\u00ednea de comandos.<\/li>
  2. SQLite<\/strong>: Es la base de datos donde se almacenan todos los datos del cluster, est\u00e1 embebida en el propio nodo. \u00c9sta ser\u00e1 la gran diferencia con la instalaci\u00f3n en HA.<\/li>
  3. Agent Nodes<\/strong>: O workers, donde vamos a ejecutar nuestros amplicativos<\/li>
  4. Load Balancer:<\/strong> En base a la carga del cluster, decide a que nodo nuestra petici\u00f3n.<\/li>
  5. External Traffic:<\/strong> Poco que a\u00f1adir, es nuestra petici\u00f3n que realizamos al cluster.<\/li><\/ol>\n\n\n\n

    Asuminendo que ya estamos dentro del nodo seleccionado, seguimos los siguientes pasos:<\/p>\n\n\n\n

    Establecer las variables de entorno<\/h4>\n\n\n\n
    $ export K3S_KUBECONFIG_MODE=\"644\"\n$ export INSTALL_K3S_EXEC=\" --no-deploy servicelb --disable traefik\"<\/pre>\n\n\n\n
    La primera linea nos permite manejar el cluster sin ser usuario root. La segunda necesita una peque\u00f1a explicaci\u00f3n; por defecto, K3s despliega un Load Balancer<\/em> y un Proxy<\/em> propio llamados servicelb<\/em> y traefik<\/em>. En su momento me encontr\u00e9 con bastantes problemas para hacerlo funcionar con mis pods, por lo que decid\u00ed utilizar metalb<\/a><\/em>  como Load Balancer<\/em> y el m\u00e1s que conocido Nginx<\/a><\/em> como Proxy<\/em>. Mediante esos flags, evitamos que se instalen esos servicios por defecto, para poder instalar despu\u00e9s de manera manual metalb<\/em> y nginx<\/em>.<\/p>\n\n\n\n
    Ejecutar el instalador<\/h4>\n\n\n\n
    Simple y directo, una sola l\u00ednea y \u00e9l se encarga de todo.<\/p>\n\n\n\n
    $ curl -sfL https:\/\/get.k3s.io | sh -\n\n[INFO]  Finding latest release\n[INFO]  Using v1.18.3+k3s as release\n[INFO]  Downloading hash https:\/\/github.com\/rancher\/k3s\/releases\/download\/v1.18.3+k3s\/sha256sum-arm.txt\n[INFO]  Downloading binary https:\/\/github.com\/rancher\/k3s\/releases\/download\/1.18.3+k3s\/k3s-armhf\n[INFO]  Verifying binary download\n[INFO]  Installing k3s to \/usr\/local\/bin\/k3s\n[INFO]  Creating \/usr\/local\/bin\/kubectl symlink to k3s\n[INFO]  Creating \/usr\/local\/bin\/crictl symlink to k3s\n[INFO]  Creating \/usr\/local\/bin\/ctr symlink to k3s\n[INFO]  Creating killall script \/usr\/local\/bin\/k3s-killall.sh\n[INFO]  Creating uninstall script \/usr\/local\/bin\/k3s-uninstall.sh\n[INFO]  env: Creating environment file \/etc\/systemd\/system\/k3s.service.env\n[INFO]  systemd: Creating service file \/etc\/systemd\/system\/k3s.service\n[INFO]  systemd: Enabling k3s unit\nCreated symlink \/etc\/systemd\/system\/multi-user.target.wants\/k3s.service \u2192 \/etc\/systemd\/system\/k3s.service.\n[INFO]  systemd: Starting k3s<\/pre>\n\n\n\n
    Verificar la instalaci\u00f3n<\/h4>\n\n\n\n
    El instalador crea un servicio que se puede usar para iniciar, parar, reiniciar y verificar su estado actual:<\/p>\n\n\n\n
    pi@noldork3sM:~ $ sudo systemctl status k3s\n\u25cf k3s.service - Lightweight Kubernetes\n   Loaded: loaded (\/etc\/systemd\/system\/k3s.service; enabled; vendor preset: enab\n   Active: active (running) since Sat 2020-07-04 17:16:24 CEST; 4h 16min ago\n     Docs: https:\/\/k3s.io\n  Process: 25865 ExecStartPre=\/sbin\/modprobe br_netfilter (code=exited, status=0\n  Process: 25866 ExecStartPre=\/sbin\/modprobe overlay (code=exited, status=0\/SUCC\n Main PID: 25867 (k3s-server)\n    Tasks: 15\n   Memory: 124.2M\n (...)<\/pre>\n\n\n\n
    Igualmente, el instalador despliega el  Kubernetes Command Line Tools<\/a> kubectl<\/code>, para que podemos interactuar con el cluster:<\/p>\n\n\n\n
    pi@noldork3sM:~ $ kubectl get nodes -o wide\nNAME          STATUS   ROLES    AGE   VERSION        INTERNAL-IP      \nnoldork3sm    Ready    master   5m   v1.18.3+k3s1   192.168.1.245   <\/pre>\n\n\n\n
    Tambi\u00e9n podemos ver los pods que se han desplegado con la instalaci\u00f3n:<\/p>\n\n\n\n
    $ kubectl get pods -A -o wide\n\nNAMESPACE     NAME                                      READY   STATUS    \nkube-system   metrics-server-7566d596c8-rgwgm            1\/1   Running   \nkube-system   local-path-provisioner-6d59f47c7-xh6t5     1\/1   Running   \nkube-system   coredns-8655855d6-pkxmp                    1\/1   Running   \n<\/pre>\n\n\n\n
    Alta Disponibilidad (HA)<\/h3>\n\n\n\n
    Nuestra instalaci\u00f3n en este caso, tendr\u00eda la siguiente estructura:<\/p>\n\n\n\n
    \"\"
    Despliegue de K3s en HA<\/figcaption><\/figure>\n\n\n\n
    Las diferencias notables entre \u00e9sta instalaci\u00f3n y la anterior son dos: la primera es que contamos con un o varios nodos que act\u00faan como master<\/em>s y la segunda, y m\u00e1s importante, es que la base de datos para a ser una base de datos externa. <\/p>\n\n\n\n
    Por lo tanto, si optamos por opci\u00f3n, deberemos tener lista otra raspberry (o placa arm por continuar con la misma arquitectura) externa donde se pueda ejecutar nuestro servidor de base de datos. <\/p>\n\n\n\n
    Una vez tengamos el servidor de base de datos listo, creamos nuestra base de datos, usuario y contrase\u00f1a mediante los siguientes comandos :<\/p>\n\n\n\n
    mysql> CREATE database <database>;\nmysql> CREATE USER <user>'@'%' IDENTIFIED BY '<password>';\nmysql> GRANT ALL ON <database>.* TO '<user>'@'%';\nmysql> flush privileges;<\/pre>\n\n\n\n
    Ahora solo nos resta continuar con los siguientes pasos que deberemos ejecutar en todos los nodos que vayan a ser Master<\/em>, y  que como ver\u00e9is son pr\u00e1cticamente los mismos que la instalaci\u00f3n Single Master<\/em> :<\/p>\n\n\n\n
    Establecer las variables de entorno<\/h4>\n\n\n\n
    $ NODE_TOKEN=$(echo $(hostname) $(date +%s) | shasum | base64) \n$ export K3S_KUBECONFIG_MODE=\"644\"\n$ export INSTALL_K3S_EXEC=\" -t ${NODE_TOKEN} --tls-san <hostname> --no-deploy servicelb --disable traefik --node-taint k3s-controlplane=true:NoExecute --datastore-endpoint mysql:\/\/<dbuser>:<dbpassword>@tcp(<dbhostname>:3306)\/<database>\"<\/pre>\n\n\n\n
    La primera linea no es una diferencia como tal, ya que la vamos a usar tambi\u00e9n en una instalaci\u00f3n Single Master<\/em> cuando vayamos a a\u00f1adir los workers<\/em>. Sin embargo, en esta modalidad, vamos a utilizar mas de un Master Node<\/em> por lo que necesitamos este token para crear nuestro cluster. Apuntar bien el valor de esa variable puesto que la necesitaremos m\u00e1s adelante, para ello ejecutamos este comando:<\/p>\n\n\n\n
    $ echo $NODE_TOKEN<\/pre>\n\n\n\n
    La segunda l\u00ednea es com\u00fan a la instalaci\u00f3n anterior. Sin embargo en la tercera l\u00ednea si encontramos diferencias: <\/p>\n\n\n\n