401 lines
12 KiB
Markdown
401 lines
12 KiB
Markdown
# 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)
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
nmcli con add type ethernet ifname em1 master bond0
|
|
nmcli con add type ethernet ifname em2 master bond0
|
|
```
|
|
|
|
## 3. Crear VLANs sobre el bond
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
# 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)
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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):
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
sudo zypper install -y kubectl kubelet kubeadm
|
|
```
|
|
|
|
Activa kubelet para que se inicie automáticamente:
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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).
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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):
|
|
|
|
```yaml
|
|
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
|
|
|
|
```bash
|
|
kubectl apply -f kube-flannel.yml
|
|
```
|
|
|
|
---
|
|
|
|
## d) Comprueba que Flannel funciona y usa la interfaz correcta
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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:**
|
|
|
|
```bash
|
|
kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/deployments/multus-daemonset.yml
|
|
```
|
|
|
|
**Verifica:**
|
|
|
|
```bash
|
|
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í.
|
|
|
|
```bash
|
|
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:**
|
|
|
|
```bash
|
|
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):**
|
|
|
|
```bash
|
|
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:**
|
|
|
|
```bash
|
|
kubectl apply -f multus/nad-br-servicios.yaml
|
|
```
|
|
|
|
**Despliega el pod de test:**
|
|
|
|
```bash
|
|
kubectl apply -f multus/test-multus-pod.yaml
|
|
```
|
|
|
|
**Comprueba las interfaces:**
|
|
|
|
```bash
|
|
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:**
|
|
|
|
```bash
|
|
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.
|
|
|
|
|