xavor/kubernetes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
fbdbf20b81aac096cae6aaf21007fee38d400e24
kubernetes/readme-suse.md
xavor 3c1aa221a4 Actualizar readme-suse.md
2025-07-21 18:54:51 +00:00

12 KiB
Raw Blame History

0. Ejemplo de configuración de red en SUSE con NetworkManager

Aquí defines cómo se conectará tu servidor físicamente a la red en openSUSE/SLES: enlaces redundantes (bonding), VLANs para segmentar el tráfico, y bridges para conectar máquinas virtuales y pods a distintas redes. Esta configuración es la base para un clúster flexible y segmentado.

Pre-requisitos:

  • openSUSE/SLES con NetworkManager activo.
  • Interfaces físicas: em1 y em2 (ajusta según tu hardware).

1. Crear el bond (LACP 802.3ad, rápido, hash layer3+4)

nmcli con add type bond ifname bond0 mode 802.3ad
nmcli con mod bond0 bond.options "mode=802.3ad,miimon=100,updelay=200,downdelay=200,lacp_rate=fast,xmit_hash_policy=layer3+4"

2. Añadir interfaces físicas al bond

nmcli con add type ethernet ifname em1 master bond0
nmcli con add type ethernet ifname em2 master bond0

3. Crear VLANs sobre el bond

nmcli con add type vlan ifname vlan10 dev bond0 id 10
nmcli con add type vlan ifname vlan20 dev bond0 id 20
nmcli con add type vlan ifname vlan30 dev bond0 id 30 ip4 192.168.3.2/24
nmcli con add type vlan ifname vlan40 dev bond0 id 40 ip4 192.168.4.2/24

4. Crear bridges y unirlos a las VLANs

# Bridge de administración (br-admin) sobre vlan10
nmcli con add type bridge ifname br-admin
nmcli con add type bridge-slave ifname vlan10 master br-admin
nmcli con mod br-admin ipv4.addresses 192.168.0.42/24
nmcli con mod br-admin ipv4.method manual
nmcli con mod br-admin ipv4.gateway 192.168.0.1
nmcli con mod br-admin ipv4.dns "192.168.0.1 1.1.1.1 8.8.8.8"

# Bridge de servicios (br-srv) sobre vlan20
nmcli con add type bridge ifname br-srv
nmcli con add type bridge-slave ifname vlan20 master br-srv
nmcli con mod br-srv ipv4.addresses 192.168.200.2/22
nmcli con mod br-srv ipv4.method manual

5. Sube todas las conexiones (en orden: bond, VLANs, bridges)

nmcli con up bond0
nmcli con up vlan10
nmcli con up vlan20
nmcli con up vlan30
nmcli con up vlan40
nmcli con up br-admin
nmcli con up br-srv

Guía rápida: Instalar Kubernetes en openSUSE/SLES

Esta guía cubre todos los pasos necesarios para instalar Kubernetes en openSUSE Leap, Tumbleweed o SLES, usando containerd como runtime y gestionando todo con zypper. Sigue el orden de los pasos para evitar problemas.

1. Prerrequisitos del sistema (SUSE)

Este paso parte de una instalación limpia de openSUSE/SLES actualizada y con permisos de administrador. Instala utilidades básicas, configura el repositorio oficial de Kubernetes y desactiva SWAP, igual que harías en Ubuntu, pero con comandos adaptados a zypper y la gestión de repositorios en SUSE.

a) Actualiza el sistema y paquetes básicos

sudo zypper refresh
sudo zypper update
sudo zypper install -y curl ca-certificates gnupg2

b) Añade el repositorio oficial de Kubernetes

Crea el archivo de repositorio para Kubernetes (v1.33). Puedes cambiar la versión por otra si lo necesitas:

cat <<EOF | sudo tee /etc/zypp/repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.33/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.33/rpm/repodata/repomd.xml.key
EOF

Actualiza la caché de repositorios y acepta la clave GPG cuando se te pida (recomendado: pulsa 'a' para confiar siempre en la clave):

sudo zypper refresh
sudo zypper update

Cuando veas el aviso sobre la clave GPG, pulsa 'a' para aceptar siempre.

2. Instala containerd (runtime recomendado)

containerd es el motor que gestiona los contenedores en el clúster. Kubernetes necesita un “runtime” para crear y controlar los pods, y containerd es la opción oficial y más estable.

sudo zypper install -y containerd
sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

3. Desactiva SWAP (requisito para Kubernetes)

Kubernetes requiere que el intercambio de memoria (swap) esté desactivado. Esto evita problemas de rendimiento y estabilidad.

sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

4. Prepara el kernel y sysctl

En este paso se habilitan módulos y parámetros de red necesarios para que Kubernetes gestione correctamente el tráfico entre pods y nodos.

sudo modprobe overlay
sudo modprobe br_netfilter
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF
sudo sysctl --system

5. Instala los componentes de Kubernetes (kubectl, kubelet, kubeadm)

Instala en un solo paso las utilidades principales:

sudo zypper install -y kubectl kubelet kubeadm

Activa kubelet para que se inicie automáticamente:

sudo systemctl enable kubelet
sudo systemctl start kubelet

Es normal que el servicio kubelet falle en bucle hasta que inicialices el clúster con kubeadm init. El error más frecuente es:

  • "failed to load Kubelet config file, path: /var/lib/kubelet/config.yaml"

Tras ejecutar kubeadm init, kubelet arrancará correctamente.

5b. (Opcional) Habilita cgroup v2 (solo SLES si necesario)

Si necesitas cgroup v2 en SLES, añade esto al arranque del kernel (edita /etc/default/grub):

GRUB_CMDLINE_LINUX_DEFAULT="systemd.unified_cgroup_hierarchy=1 ..."

Y regenera el grub:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Reinicia para aplicar los cambios.

6. Inicializa el clúster (openSUSE/SLES)

Este paso crea el clúster de Kubernetes en el nodo principal (control-plane) sobre openSUSE/SLES. Aquí defines la red interna para los pods y la interfaz/VLAN física para el tráfico overlay del clúster, según tu diseño.

a) Inicializa el clúster especificando red de pods y la IP interna

Importante:

  • Usa la opción --apiserver-advertise-address para forzar que el nodo control-plane escuche en la IP de la VLAN interna de clúster (ejemplo: 192.168.4.x en tu VLAN 40).
  • Usa --pod-network-cidr=10.244.0.0/16 si vas a usar Flannel como CNI (compatible con la mayoría de setups, pero ajusta según tu CNI si es distinto).
sudo kubeadm init \
  --apiserver-advertise-address=192.168.4.2 \
  --pod-network-cidr=10.244.0.0/16
  • Cambia 192.168.4.2 por la IP real de VLAN 40 (la que conecta los nodos de tu clúster).
  • Si tienes varias VLANs/interfaces, asegúrate que todos los nodos pueden conectarse entre sí por esa red.

b) Configura kubectl para tu usuario

Permite usar el comando kubectl como usuario normal copiando la configuración de administración del clúster a tu carpeta personal.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

7. Instala la red de pods (Flannel) usando la VLAN interna del clúster

Kubernetes solo define la infraestructura; necesitas un complemento de red (CNI) para que los pods puedan comunicarse entre sí. Flannel es la opción más sencilla y compatible, y puedes configurarla para usar una interfaz/VLAN específica para el tráfico overlay (muy recomendable si segmentas redes en tu clúster).

a) Descarga el manifiesto oficial de Flannel

wget https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

b) Edita el manifiesto para usar la interfaz de la VLAN 40

Abre kube-flannel.yml en tu editor favorito y localiza la sección del contenedor principal (kube-flannel):

      containers:
      - args:
        - --ip-masq
        - --kube-subnet-mgr
        # <-- Añade la línea siguiente
        - --iface=bond0.40
        command:
        - /opt/bin/flanneld

⚠️ Sustituye bond0.40 por el nombre exacto de la interfaz de tu VLAN interna del clúster (puede ser br-cluster, vlan40, etc., según tu configuración real).

Así, todo el tráfico de pods entre nodos irá solo por la red interna de clúster (VLAN 40), aislándolo de la red de gestión o de servicios.

c) Aplica el manifiesto editado

kubectl apply -f kube-flannel.yml

d) Comprueba que Flannel funciona y usa la interfaz correcta

kubectl -n kube-flannel get pods -o wide
  • Todos los pods deben estar en estado Running.
  • Puedes verificar qué interfaz usa flanneld en los logs de los pods:
kubectl -n kube-flannel logs <nombre-pod-flannel>

Busca una línea parecida a:

Using interface with name bond0.40 and address 192.168.4.x

Porqué: Si tienes varias interfaces de red y no usas --iface, Flannel puede elegir la “incorrecta” (gestión, pública, etc.). Es recomendable SIEMPRE fijar la interfaz en entornos segmentados o con VLANs.

8. Instala Multus (opcional, para múltiples redes)

Multus permite que un pod tenga más de una interfaz de red (multi-homed), útil para appliances, firewalls, balanceadores, gateways, etc. Instálalo si necesitas conectar pods a varias redes físicas o VLANs (por ejemplo, mediante bridges y NADs).

Instalación:

kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml

Verifica:

kubectl get pods -n kube-system | grep multus

9. (Opcional) Quita el taint del nodo master para poder programar pods en él

Por defecto, Kubernetes no programa pods de usuario en el nodo principal (control-plane). Elimina este bloqueo para poder desplegar aplicaciones ahí.

kubectl taint nodes --all node-role.kubernetes.io/control-plane-
kubectl taint nodes --all node-role.kubernetes.io/master-

Nota: Uso de taints en nodos control-plane (alta disponibilidad y ejecución de cargas)

¿Qué es un taint?

  • Un taint en Kubernetes es una marca especial que se pone a un nodo para evitar que los pods se programen ahí, salvo que declaren una “toleration” explícita.

  • Se usa para reservar nodos solo para tareas especiales (por ejemplo, el control-plane).

  • Por defecto, los nodos control-plane llevan un taint:

    • node-role.kubernetes.io/control-plane:NoSchedule

¿Por qué quitar el taint?

  • Si quieres que los nodos control-plane puedan ejecutar pods de usuario (además del plano de control), necesitas quitar el taint.
  • Esto es común en clústeres pequeños o medianos, donde todos los nodos cumplen doble función (alta disponibilidad y ejecución de cargas).

Comandos para quitar el taint de todos los nodos control-plane:

kubectl taint nodes --all node-role.kubernetes.io/control-plane-
kubectl taint nodes --all node-role.kubernetes.io/master-
  • El - final indica “quitar”.
  • Ejecuta ambos para máxima compatibilidad entre versiones.

Comando para añadir el taint (dejar el nodo solo como control-plane):

kubectl taint nodes NOMBRE_DEL_NODO node-role.kubernetes.io/control-plane=:NoSchedule
  • Así, ese nodo solo ejecuta el plano de control (salvo pods con toleration específica).

10. Test rápido de Multus (NAD + pod con 2 interfaces)

Puedes comprobar que Multus funciona creando una red secundaria y un pod de prueba con dos interfaces (una por defecto, una secundaria).

En la carpeta multus/ de tu repositorio, debes tener:

  • multus/nad-br-servicios.yaml (NetworkAttachmentDefinition)
  • multus/test-multus-pod.yaml (pod Alpine multi-homed)

Despliega la NAD:

kubectl apply -f multus/nad-br-servicios.yaml

Despliega el pod de test:

kubectl apply -f multus/test-multus-pod.yaml

Comprueba las interfaces:

kubectl exec -it multus-test -- sh
ip a
  • El pod debe mostrar una interfaz extra (además de la de Flannel), conectada a tu red secundaria (br-servicios, etc.).

Para limpiar:

kubectl delete pod multus-test

Nota: Puedes crear tantas NADs (NetworkAttachmentDefinition) como bridges/VLANs quieras conectar a pods específicos (con Multus), ideal para appliances de red, gateways, SDN, pruebas de seguridad, etc.