Geekly articles weekly

Cree una granja de servidores preparada para la red para Kubernetes con LTSP


En este artículo, me gustaría mostrarle una tecnología genial, la uso con éxito para Kubernetes. Puede ser realmente útil para construir grandes grupos.


De ahora en adelante, ya no tendrá que pensar en instalar el sistema operativo y paquetes separados para cada nodo. Por qué ¡Puede hacer todo esto automáticamente a través del Dockerfile!


¡El hecho de que pueda comprar cientos de nuevos servidores, agregarlos a su entorno de trabajo y casi de inmediato prepararlos para su uso es realmente increíble!


Intrigado? Ahora hablemos de todo en orden.


Resumen


Para comenzar, necesitamos entender exactamente cómo funciona este circuito.


Brevemente, para todos los nodos estamos preparando una sola imagen con el sistema operativo, Docker, Kubelet y todo lo demás.
CI crea automáticamente esta imagen del sistema junto con el núcleo utilizando el Dockerfile.
Los nodos finales cargan el sistema operativo y el núcleo desde esta imagen directamente a través de la red.


Los nodos utilizan overlayfs como el sistema de archivos raíz, por lo que en caso de reinicio, se perderán los cambios (así como en el caso de los contenedores acoplables).
Hay una configuración principal, en ella puede describir los puntos de montaje y algunos comandos que deben ejecutarse cuando se carga el nodo (por ejemplo, un comando para agregar una clave ssh y kubeadm join )


Proceso de preparación de imagen


Utilizaremos el proyecto LTSP porque nos brinda todo lo que necesitamos para organizar el arranque de la red.
En general, LTSP es un paquete de scripts de shell que hace nuestra vida mucho más fácil.


Proporciona un módulo initramfs, varios scripts de ayuda y algún tipo de sistema de configuración que prepara el sistema en una etapa temprana de carga, incluso antes de invocar init.


Así es como se ve el procedimiento de preparación de la imagen:


  • Implemente el sistema base en un entorno chroot.
  • Hacemos los cambios necesarios, instalamos software.
  • Ejecute el comando ltsp-build-image

Justo después de eso, obtendrá una imagen comprimida de este chroot con todo el software instalado dentro.
Cada nodo descargará esta imagen en el momento del arranque y la usará como rootfs.
Para actualizar, simplemente reinicie el nodo, la nueva imagen se descargará y se usará para rootfs.


Componentes del servidor


La parte del servidor de LTSP en nuestro caso incluye solo dos componentes:


  • Servidor TFTP : TFTP es un protocolo de inicialización, se usa para cargar el núcleo, initramfs y la configuración principal - lts.conf.
  • Servidor NBD: protocolo NBD utilizado para entregar una imagen rootfs comprimida a los clientes. Este es el método más rápido, pero si lo desea, puede reemplazarse con NFS o AoE.

También necesitas tener:


  • Servidor DHCP : distribuirá la configuración de IP y varias opciones adicionales que nuestros clientes necesitarán para que puedan arrancar desde nuestro servidor LTSP.

Proceso de carga de nodos


Descripción del proceso de carga del nodo


  • Primero, el nodo solicitará la dirección IP de DHCP y las opciones para el next-server , filename .
  • Luego, el nodo aplicará la configuración y descargará el gestor de arranque (pxelinux o grub)
  • El gestor de arranque descargará y cargará la configuración con el kernel y initramfs.
  • Luego cargará el núcleo e initramfs con opciones específicas especificadas para el núcleo.
  • En el momento del arranque, los módulos initramfs procesarán los parámetros desde cmdline y realizarán algunas acciones, como conectar un dispositivo nbd, preparar rootfs superpuestos, etc.
  • Después de eso, en lugar del init habitual, se llamará a un ltsp-init especial.
  • Los scripts ltsp-init prepararán el sistema antes de que se llame al init principal. Básicamente, las opciones de lts.conf (el archivo de configuración principal) se usan aquí: esto es actualizar registros en fstab y rc.local, etc.
  • Luego habrá una llamada al init principal (systemd), que cargará el sistema ya configurado como de costumbre, montará recursos compartidos desde fstab, lanzará objetivos y servicios, y ejecutará comandos desde rc.local.
  • Como resultado, obtenemos un sistema totalmente configurado y cargado, listo para una acción adicional.

Preparación del servidor


Como dije, preparo el servidor LTSP con la imagen aplastada automáticamente usando el Dockerfile. Este método no es malo, porque todos los pasos para compilar se pueden describir en su repositorio git. Puede controlar versiones, usar etiquetas, aplicar CI y todo lo mismo que usaría para la preparación de proyectos Docker habituales.


Por otro lado, puede implementar el servidor LTSP manualmente siguiendo todos los pasos manualmente, esto puede ser bueno para fines de capacitación y para comprender los principios básicos.
Ejecute los comandos enumerados en el artículo manualmente si solo desea probar LTSP sin el Dockerfile.


Lista de parches usados


Por el momento, LTSP tiene algunos defectos, y los autores del proyecto no están muy dispuestos a aceptar correcciones. Afortunadamente, LTSP es fácilmente personalizable, así que preparé algunos parches para mí, los daré aquí.
Quizás algún día madure en la bifurcación si la comunidad acepta calurosamente mi decisión.


  • feature-grub.diff
    Por defecto, LTSP no es compatible con EFI, por lo que preparé un parche que agrega GRUB2 con soporte EFI.
  • feature_preinit.diff
    Este parche agrega la opción PREINIT a lts.conf, que le permite ejecutar comandos arbitrarios antes de invocar el init principal. Esto puede ser útil para modificar unidades systemd y configuraciones de red. Cabe destacar que todas las variables del entorno de arranque se guardan, y puede usarlas en sus scripts llamados a través de esta opción.
  • feature_initramfs_params_from_lts_conf.diff
    Resuelve el problema con la opción NBD_TO_RAM deshabilitada, después de este parche puede especificarlo en lts.conf dentro de chroot. (no el que está en el directorio tftp)
  • nbd-server-wrapper.sh
    Esto no es un parche, sino solo un script de shell, le permite ejecutar el servidor nbd en foregroud, lo necesitará si desea ejecutar el servidor nbd dentro del contenedor Docker.

Etapas de Dockerfile


Utilizaremos la construcción de escenarios en nuestro Dockerfile para guardar solo las partes necesarias de nuestra imagen acoplable, las partes restantes no utilizadas se excluirán de la imagen final.


 ltsp-base (    ltsp ) | |---basesystem | ( chroot-     ) | | | |---builder | | (    ,  ) | | | '---ltsp-image | (  , docker, kubelet   squashed ) | '---final-stage ( squashed ,   initramfs   stage)

Etapa 1: base ltsp


OK, comencemos, esta es la primera parte de nuestro Dockerfile:


 FROM ubuntu:16.04 as ltsp-base ADD nbd-server-wrapper.sh /bin/ ADD /patches/feature-grub.diff /patches/feature-grub.diff RUN apt-get -y update \ && apt-get -y install \ ltsp-server \ tftpd-hpa \ nbd-server \ grub-common \ grub-pc-bin \ grub-efi-amd64-bin \ curl \ patch \ && sed -i 's|in_target mount|in_target_nofail mount|' \ /usr/share/debootstrap/functions \ #   EFI   Grub (#1745251) && patch -p2 -d /usr/sbin < /patches/feature-grub.diff \ && rm -rf /var/lib/apt/lists \ && apt-get clean

Por el momento, nuestra imagen acoplable ya tiene instalado lo siguiente:


  • Servidor NBD
  • Servidor TFTP
  • Scripts LTSP con soporte de arranque de grub (para EFI)

Etapa 2: sistema base


En esta etapa, prepararemos el entorno chroot con el sistema base e instalaremos el software principal con el núcleo.
Utilizaremos el debootstrap habitual en lugar de ltsp-build-client para preparar la imagen, porque ltsp-build-client instalará la GUI y algunas otras cosas innecesarias que obviamente no serán útiles para implementar servidores.


 FROM ltsp-base as basesystem ARG DEBIAN_FRONTEND=noninteractive #    RUN mkdir -p /opt/ltsp/amd64/proc/self/fd \ && touch /opt/ltsp/amd64/proc/self/fd/3 \ && debootstrap --arch amd64 xenial /opt/ltsp/amd64 \ && rm -rf /opt/ltsp/amd64/proc/* #   RUN echo "\ deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse\n\ deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse\n\ deb http://archive.ubuntu.com/ubuntu xenial-security main restricted universe multiverse" \ > /opt/ltsp/amd64/etc/apt/sources.list \ && ltsp-chroot apt-get -y update \ && ltsp-chroot apt-get -y upgrade #   LTSP RUN ltsp-chroot apt-get -y install ltsp-client-core #   initramfs # 1:    /etc/lts.conf    (#1680490) # 2:   PREINIT   lts.conf ADD /patches /patches RUN patch -p4 -d /opt/ltsp/amd64/usr/share < /patches/feature_initramfs_params_from_lts_conf.diff \ && patch -p3 -d /opt/ltsp/amd64/usr/share < /patches/feature_preinit.diff #  LTSP_NBD_TO_RAM    ,     ram: RUN echo "[Default]\nLTSP_NBD_TO_RAM = true" \ > /opt/ltsp/amd64/etc/lts.conf #   RUN echo 'APT::Install-Recommends "0";\nAPT::Install-Suggests "0";' \ >> /opt/ltsp/amd64/etc/apt/apt.conf.d/01norecommend \ && ltsp-chroot apt-get -y install \ software-properties-common \ apt-transport-https \ ca-certificates \ ssh \ bridge-utils \ pv \ jq \ vlan \ bash-completion \ screen \ vim \ mc \ lm-sensors \ htop \ jnettop \ rsync \ curl \ wget \ tcpdump \ arping \ apparmor-utils \ nfs-common \ telnet \ sysstat \ ipvsadm \ ipset \ make #   RUN ltsp-chroot apt-get -y install linux-generic-hwe-16.04

Tenga en cuenta que algunos paquetes, como lvm2, pueden experimentar problemas. No están completamente optimizados para la instalación en un chroot sin privilegios. Sus scripts posteriores a la instalación intentan invocar comandos privilegiados que pueden fallar y bloquear la instalación de todo el paquete.


Solución:


  • Algunos se pueden instalar sin problemas si los instala antes de instalar el núcleo (por ejemplo, lvm2)
  • Pero para algunos de ellos, deberá usar esta solución alternativa para instalar sin un script posterior a la instalación.

Etapa 3: constructor


En esta etapa, podemos recopilar todo el software necesario y los módulos del núcleo de las fuentes, es genial que sea posible hacerlo en esta etapa, en modo totalmente automático.
Omita este paso si no necesita recolectar nada de los artistas.


Daré un ejemplo de instalación de la última versión del controlador MLNX_EN:


 FROM basesystem as builder #  cpuinfo (   ) RUN cp /proc/cpuinfo /opt/ltsp/amd64/proc/cpuinfo #    Mellanox driver RUN ltsp-chroot sh -cx \ ' VERSION=4.3-1.0.1.0-ubuntu16.04-x86_64 \ && curl -L http://www.mellanox.com/downloads/ofed/MLNX_EN-${VERSION%%-ubuntu*}/mlnx-en-${VERSION}.tgz \ | tar xzf - \ && export \ DRIVER_DIR="$(ls -1 | grep "MLNX_OFED_LINUX-\|mlnx-en-")" \ KERNEL="$(ls -1t /lib/modules/ | head -n1)" \ && cd "$DRIVER_DIR" \ && ./*install --kernel "$KERNEL" --without-dkms --add-kernel-support \ && cd - \ && rm -rf "$DRIVER_DIR" /tmp/mlnx-en* /tmp/ofed*' #    RUN ltsp-chroot sh -c \ ' export KERNEL="$(ls -1t /usr/src/ | grep -m1 "^linux-headers" | sed "s/^linux-headers-//g")" \ && tar cpzf /modules.tar.gz /lib/modules/${KERNEL}/updates'

Etapa 4: ltsp-image


En esta etapa estableceremos lo que hemos recopilado en el paso anterior:


 FROM basesystem as ltsp-image #    COPY --from=builder /opt/ltsp/amd64/modules.tar.gz /opt/ltsp/amd64/modules.tar.gz #    RUN ltsp-chroot sh -c \ ' export KERNEL="$(ls -1t /usr/src/ | grep -m1 "^linux-headers" | sed "s/^linux-headers-//g")" \ && tar xpzf /modules.tar.gz \ && depmod -a "${KERNEL}" \ && rm -f /modules.tar.gz'

Ahora haremos cambios adicionales para completar nuestra imagen LTSP:


 #  docker RUN ltsp-chroot sh -c \ ' curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - \ && echo "deb https://download.docker.com/linux/ubuntu xenial stable" \ > /etc/apt/sources.list.d/docker.list \ && apt-get -y update \ && apt-get -y install \ docker-ce=$(apt-cache madison docker-ce | grep 18.06 | head -1 | awk "{print $ 3}")' #    docker RUN DOCKER_OPTS="$(echo \ --storage-driver=overlay2 \ --iptables=false \ --ip-masq=false \ --log-driver=json-file \ --log-opt=max-size=10m \ --log-opt=max-file=5 \ )" \ && sed "/^ExecStart=/ s|$| $DOCKER_OPTS|g" \ /opt/ltsp/amd64/lib/systemd/system/docker.service \ > /opt/ltsp/amd64/etc/systemd/system/docker.service #  kubeadm, kubelet  kubectl RUN ltsp-chroot sh -c \ ' curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - \ && echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" \ > /etc/apt/sources.list.d/kubernetes.list \ && apt-get -y update \ && apt-get -y install kubelet kubeadm kubectl cri-tools' #    RUN rm -f /opt/ltsp/amd64/etc/apt/apt.conf.d/20auto-upgrades #   apparmor RUN ltsp-chroot find /etc/apparmor.d \ -maxdepth 1 \ -type f \ -name "sbin.*" \ -o -name "usr.*" \ -exec ln -sf "{}" /etc/apparmor.d/disable/ \; #    (cmdline) RUN KERNEL_OPTIONS="$(echo \ init=/sbin/init-ltsp \ forcepae \ console=tty1 \ console=ttyS0,9600n8 \ nvme_core.default_ps_max_latency_us=0 \ )" \ && sed -i "/^CMDLINE_LINUX_DEFAULT=/ s|=.*|=\"${KERNEL_OPTIONS}\"|" \ "/opt/ltsp/amd64/etc/ltsp/update-kernels.conf"

Ahora haga una imagen cuadriculada de nuestro chroot:


 #   RUN rm -rf /opt/ltsp/amd64/var/lib/apt/lists \ && ltsp-chroot apt-get clean #  squashed  RUN ltsp-update-image

Etapa 5: etapa final


En la etapa final, solo guardamos nuestra imagen aplastada y el núcleo con initramfs


 FROM ltsp-base COPY --from=ltsp-image /opt/ltsp/images /opt/ltsp/images COPY --from=ltsp-image /etc/nbd-server/conf.d /etc/nbd-server/conf.d COPY --from=ltsp-image /var/lib/tftpboot /var/lib/tftpboot

Ok, ahora tenemos una imagen acoplable que incluye:


  • Servidor TFTP
  • Servidor NBD
  • gestor de arranque configurado
  • kernel con initramfs
  • imagen de rootfs aplastada

Uso


Bien, ahora que nuestra imagen de Docker con el servidor LTSP, kernel, initramfs y rootfs aplastados está completamente lista, podemos ejecutar la implementación con ella.


Podemos hacer esto como de costumbre, pero hay otro problema que tenemos que resolver.
Desafortunadamente, no podemos usar el servicio Kubernetes habitual para nuestra implementación, porque en el momento del arranque los nodos no son parte del clúster Kubernetes y necesitan usar externalIP, pero Kubernetes siempre usa NAT para externalIP y actualmente no hay forma de cambiar este comportamiento.


Conozco dos formas de evitar esto: usar hostNetwork: true o usar tuberías , la segunda opción también nos proporcionará tolerancia a fallas, como en caso de falla, la dirección IP se moverá a otro nodo con el contenedor. Lamentablemente, la tubería no es un método nativo y menos seguro.
Si conoce alguna solución más adecuada, infórmenos al respecto.


Aquí hay un ejemplo de implementación con hostNetwork:


 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: ltsp-server labels: app: ltsp-server spec: selector: matchLabels: name: ltsp-server replicas: 1 template: metadata: labels: name: ltsp-server spec: hostNetwork: true containers: - name: tftpd image: registry.example.org/example/ltsp:latest command: [ "/usr/sbin/in.tftpd", "-L", "-u", "tftp", "-a", ":69", "-s", "/var/lib/tftpboot" ] lifecycle: postStart: exec: command: ["/bin/sh", "-c", "cd /var/lib/tftpboot/ltsp/amd64; ln -sf config/lts.conf ." ] volumeMounts: - name: config mountPath: "/var/lib/tftpboot/ltsp/amd64/config" - name: nbd-server image: registry.example.org/example/ltsp:latest command: [ "/bin/nbd-server-wrapper.sh" ] volumes: - name: config configMap: name: ltsp-config

Como habrás notado, el mapa de configuración con el archivo lts.conf también se usa aquí.
Como ejemplo, daré parte de mi configuración:


 apiVersion: v1 kind: ConfigMap metadata: name: ltsp-config data: lts.conf: | [default] KEEP_SYSTEM_SERVICES = "ssh ureadahead dbus-org.freedesktop.login1 systemd-logind polkitd cgmanager ufw rpcbind nfs-kernel-server" PREINIT_00_TIME = "ln -sf /usr/share/zoneinfo/Europe/Prague /etc/localtime" PREINIT_01_FIX_HOSTNAME = "sed -i '/^127.0.0.2/d' /etc/hosts" PREINIT_02_DOCKER_OPTIONS = "sed -i 's|^ExecStart=.*|ExecStart=/usr/bin/dockerd -H fd:// --storage-driver overlay2 --iptables=false --ip-masq=false --log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5|' /etc/systemd/system/docker.service" FSTAB_01_SSH = "/dev/data/ssh /etc/ssh ext4 nofail,noatime,nodiratime 0 0" FSTAB_02_JOURNALD = "/dev/data/journal /var/log/journal ext4 nofail,noatime,nodiratime 0 0" FSTAB_03_DOCKER = "/dev/data/docker /var/lib/docker ext4 nofail,noatime,nodiratime 0 0" # Each command will stop script execution when fail RCFILE_01_SSH_SERVER = "cp /rofs/etc/ssh/*_config /etc/ssh; ssh-keygen -A" RCFILE_02_SSH_CLIENT = "mkdir -p /root/.ssh/; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBSLYRaORL2znr1V4a3rjDn3HDHn2CsvUNK1nv8+CctoICtJOPXl6zQycI9KXNhANfJpc6iQG1ZPZUR74IiNhNIKvOpnNRPyLZ5opm01MVIDIZgi9g0DUks1g5gLV5LKzED8xYKMBmAfXMxh/nsP9KEvxGvTJB3OD+/bBxpliTl5xY3Eu41+VmZqVOz3Yl98+X8cZTgqx2dmsHUk7VKN9OZuCjIZL9MtJCZyOSRbjuo4HFEssotR1mvANyz+BUXkjqv2pEa0I2vGQPk1VDul5TpzGaN3nOfu83URZLJgCrX+8whS1fzMepUYrbEuIWq95esjn0gR6G4J7qlxyguAb9 admin@kubernetes' >> /root/.ssh/authorized_keys" RCFILE_03_KERNEL_DEBUG = "sysctl -w kernel.unknown_nmi_panic=1 kernel.softlockup_panic=1; modprobe netconsole netconsole=@/vmbr0,@10.9.0.15/" RCFILE_04_SYSCTL = "sysctl -w fs.file-max=20000000 fs.nr_open=20000000 net.ipv4.neigh.default.gc_thresh1=80000 net.ipv4.neigh.default.gc_thresh2=90000 net.ipv4.neigh.default.gc_thresh3=100000" RCFILE_05_FORWARD = "echo 1 > /proc/sys/net/ipv4/ip_forward" RCFILE_06_MODULES = "modprobe br_netfilter" RCFILE_07_JOIN_K8S = "kubeadm join --token 2a4576.504356e45fa3d365 10.9.0.20:6443 --discovery-token-ca-cert-hash sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBSLYRaORL2znr1V4a3rjDn3HDHn2CsvUNK1nv8 + CctoICtJOPXl6zQycI9KXNhANfJpc6iQG1ZPZUR74IiNhNIKvOpnNRPyLZ5opm01MVIDIZgi9g0DUks1g5gLV5LKzED8xYKMBmAfXMxh / nsP9KEvxGvTJB3OD + / + bBxpliTl5xY3Eu41 VmZqVOz3Yl98 + X8cZTgqx2dmsHUk7VKN9OZuCjIZL9MtJCZyOSRbjuo4HFEssotR1mvANyz + + BUXkjqv2pEa0I2vGQPk1VDul5TpzGaN3nOfu83URZLJgCrX 8whS1fzMepUYrbEuIWq95esjn0gR6G4J7qlxyguAb9 admin @ kubernetes' >> /root/.ssh/authorized_keys" apiVersion: v1 kind: ConfigMap metadata: name: ltsp-config data: lts.conf: | [default] KEEP_SYSTEM_SERVICES = "ssh ureadahead dbus-org.freedesktop.login1 systemd-logind polkitd cgmanager ufw rpcbind nfs-kernel-server" PREINIT_00_TIME = "ln -sf /usr/share/zoneinfo/Europe/Prague /etc/localtime" PREINIT_01_FIX_HOSTNAME = "sed -i '/^127.0.0.2/d' /etc/hosts" PREINIT_02_DOCKER_OPTIONS = "sed -i 's|^ExecStart=.*|ExecStart=/usr/bin/dockerd -H fd:// --storage-driver overlay2 --iptables=false --ip-masq=false --log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5|' /etc/systemd/system/docker.service" FSTAB_01_SSH = "/dev/data/ssh /etc/ssh ext4 nofail,noatime,nodiratime 0 0" FSTAB_02_JOURNALD = "/dev/data/journal /var/log/journal ext4 nofail,noatime,nodiratime 0 0" FSTAB_03_DOCKER = "/dev/data/docker /var/lib/docker ext4 nofail,noatime,nodiratime 0 0" # Each command will stop script execution when fail RCFILE_01_SSH_SERVER = "cp /rofs/etc/ssh/*_config /etc/ssh; ssh-keygen -A" RCFILE_02_SSH_CLIENT = "mkdir -p /root/.ssh/; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBSLYRaORL2znr1V4a3rjDn3HDHn2CsvUNK1nv8+CctoICtJOPXl6zQycI9KXNhANfJpc6iQG1ZPZUR74IiNhNIKvOpnNRPyLZ5opm01MVIDIZgi9g0DUks1g5gLV5LKzED8xYKMBmAfXMxh/nsP9KEvxGvTJB3OD+/bBxpliTl5xY3Eu41+VmZqVOz3Yl98+X8cZTgqx2dmsHUk7VKN9OZuCjIZL9MtJCZyOSRbjuo4HFEssotR1mvANyz+BUXkjqv2pEa0I2vGQPk1VDul5TpzGaN3nOfu83URZLJgCrX+8whS1fzMepUYrbEuIWq95esjn0gR6G4J7qlxyguAb9 admin@kubernetes' >> /root/.ssh/authorized_keys" RCFILE_03_KERNEL_DEBUG = "sysctl -w kernel.unknown_nmi_panic=1 kernel.softlockup_panic=1; modprobe netconsole netconsole=@/vmbr0,@10.9.0.15/" RCFILE_04_SYSCTL = "sysctl -w fs.file-max=20000000 fs.nr_open=20000000 net.ipv4.neigh.default.gc_thresh1=80000 net.ipv4.neigh.default.gc_thresh2=90000 net.ipv4.neigh.default.gc_thresh3=100000" RCFILE_05_FORWARD = "echo 1 > /proc/sys/net/ipv4/ip_forward" RCFILE_06_MODULES = "modprobe br_netfilter" RCFILE_07_JOIN_K8S = "kubeadm join --token 2a4576.504356e45fa3d365 10.9.0.20:6443 --discovery-token-ca-cert-hash sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"

  • KEEP_SYSTEM_SERVICES : durante el arranque, LTSP elimina automáticamente algunos servicios, esta variable es necesaria para evitar este comportamiento para los servicios enumerados aquí.
  • PREINIT_ * : los comandos enumerados aquí se ejecutarán antes de ejecutar systemd (esta característica se agregó mediante el parche feature_preinit.diff )
  • FSTAB_ * : las líneas enumeradas aquí se agregarán al /etc/fstab .
    Puede notar que estoy usando la opción nofail , da el siguiente comportamiento, que si la sección no existe, la descarga continúa sin errores.
  • RCFILE_ * : estos comandos se agregarán al archivo rc.local , que systemd llamará en el momento del arranque.
    Aquí cargo los módulos de kernel necesarios, ejecuto algunas configuraciones de sysctl y luego ejecuto el comando kubeadm join , que agrega el nodo al clúster kubernetes.

Puede obtener información más detallada sobre todas las variables en la página del manual lts.conf .


Ahora puede configurar su DHCP. Esencialmente, lo que necesita allí es especificar las next-server opciones de next-server y filename .


Estoy usando un servidor ISC-DHCP, daré un ejemplo de dhcpd.conf :


 shared-network ltsp-netowrk { subnet 10.9.0.0 netmask 255.255.0.0 { authoritative; default-lease-time -1; max-lease-time -1; option domain-name "example.org"; option domain-name-servers 10.9.0.1; option routers 10.9.0.1; next-server ltsp-1; # write ltsp-server hostname here if option architecture = 00:07 { filename "/ltsp/amd64/grub/x86_64-efi/core.efi"; } else { filename "/ltsp/amd64/grub/i386-pc/core.0"; } range 10.9.200.0 10.9.250.254; }

Puede comenzar con esto, pero en cuanto a mí, tengo varios servidores LTSP y para cada nodo configuro una dirección IP estática separada y las opciones necesarias usando un libro de jugadas Ansible.


Intente iniciar su primer nodo y si todo se hizo correctamente, obtendrá un sistema cargado en él. El nodo también se agregará al clúster de Kubernetes.


Ahora puedes intentar hacer tus propios cambios.


Si necesita algo más, tenga en cuenta que LTSP se puede personalizar muy fácilmente para satisfacer sus necesidades. Siéntase libre de mirar la fuente, allí puede encontrar muchas respuestas.


Únase a nuestro canal de Telegram: @ltsp_ru .

Source: https://habr.com/ru/post/es423785/

More articles:


All Articles