Actualizar redes_internet.md
This commit is contained in:
xguefer
@@ -1,4 +1,6 @@
|
||||
# 1. Instala Multus (opcional, para múltiples redes)
|
||||
# 1. Guía avanzada de Multus en Kubernetes
|
||||
|
||||
## 1.1 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).
|
||||
|
||||
@@ -16,7 +18,7 @@ kubectl get pods -n kube-system | grep multus
|
||||
|
||||
---
|
||||
|
||||
# 2. (Opcional) Quita el taint del nodo master para poder programar pods en él
|
||||
## 1.2 (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í.
|
||||
|
||||
@@ -24,92 +26,141 @@ Por defecto, Kubernetes no programa pods de usuario en el nodo principal (contro
|
||||
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:**
|
||||
## 1.3 Crea el bridge físico en todos los nodos
|
||||
|
||||
Para que Multus pueda conectar pods a una red física o VLAN, debes crear un bridge Linux con el mismo nombre en **todos** los nodos del clúster. Ejemplo usando NetworkManager/nmcli:
|
||||
|
||||
```bash
|
||||
kubectl taint nodes --all node-role.kubernetes.io/control-plane-
|
||||
kubectl taint nodes --all node-role.kubernetes.io/master-
|
||||
# 1. Crear el bridge (br-srv) y ponerle IP si quieres conectividad L3
|
||||
nmcli con add type bridge ifname br-srv con-name br-srv
|
||||
nmcli con mod br-srv ipv4.addresses 192.168.200.1/22
|
||||
nmcli con mod br-srv ipv4.method manual
|
||||
nmcli con up br-srv
|
||||
|
||||
# 2. Crear la VLAN asociada (vlan20) sobre el bond
|
||||
nmcli con add type vlan ifname vlan20 dev bond0 id 20 con-name vlan20
|
||||
nmcli con mod vlan20 ipv4.method disabled ipv6.method ignore
|
||||
nmcli con mod vlan20 master br-srv connection.slave-type bridge
|
||||
nmcli con up vlan20
|
||||
```
|
||||
|
||||
* 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).
|
||||
* **IMPORTANTE:** Repite en todos los nodos, y asigna una IP distinta del mismo rango a cada uno si es posible.
|
||||
* El bridge debe estar **UP y con IP activa** para funcionar correctamente a nivel L2/L3.
|
||||
|
||||
---
|
||||
|
||||
# 3. Test rápido de Multus (NAD + pod con 2 interfaces)
|
||||
## 1.4 Crea la NetworkAttachmentDefinition (NAD)
|
||||
|
||||
Puedes comprobar que Multus funciona creando una red secundaria y un pod de prueba con dos interfaces (una por defecto, una secundaria).
|
||||
Ejemplo:
|
||||
|
||||
En la carpeta `/opt/cni/bin/multus/` de tu repositorio, debes tener:
|
||||
```yaml
|
||||
apiVersion: "k8s.cni.cncf.io/v1"
|
||||
kind: NetworkAttachmentDefinition
|
||||
metadata:
|
||||
name: br-srv
|
||||
namespace: default
|
||||
spec:
|
||||
config: '{
|
||||
"cniVersion": "0.3.1",
|
||||
"type": "bridge",
|
||||
"bridge": "br-srv",
|
||||
"ipam": {
|
||||
"type": "host-local",
|
||||
"subnet": "192.168.200.0/22",
|
||||
"rangeStart": "192.168.200.100",
|
||||
"rangeEnd": "192.168.200.200"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
* `multus/nad-br-servicios.yaml` (NetworkAttachmentDefinition)
|
||||
* `multus/test-multus-pod.yaml` (pod Alpine multi-homed)
|
||||
|
||||
**Despliega la NAD:**
|
||||
Despliega:
|
||||
|
||||
```bash
|
||||
kubectl apply -f multus/nad-br-servicios.yaml
|
||||
```
|
||||
|
||||
**Despliega el pod de test:**
|
||||
---
|
||||
|
||||
```bash
|
||||
kubectl apply -f multus/test-multus-pod.yaml
|
||||
## 1.5 Despliega pods multi-homed de prueba
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: multus-test
|
||||
annotations:
|
||||
k8s.v1.cni.cncf.io/networks: br-srv
|
||||
spec:
|
||||
containers:
|
||||
- name: alpine
|
||||
image: alpine
|
||||
command: ["sleep", "infinity"]
|
||||
securityContext:
|
||||
capabilities:
|
||||
add: ["NET_ADMIN"]
|
||||
```
|
||||
|
||||
**Comprueba las interfaces:**
|
||||
---
|
||||
|
||||
## 1.6 Verifica la conectividad L2/L3 entre pods
|
||||
|
||||
```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.).
|
||||
* Deberías ver dos interfaces: una de Flannel (eth0) y una de la red secundaria (net1).
|
||||
* **IMPORTANTE:** Si el bridge físico (`br-srv`) está up pero SIN IP, la conectividad entre pods en nodos diferentes **NO funcionará**. Los bridges deben tener una IP asignada y activa.
|
||||
|
||||
**Para limpiar:**
|
||||
### **¿Por qué es necesario que el bridge tenga IP?**
|
||||
|
||||
* El bridge sólo se comporta como una red L2 completa entre nodos cuando está “activo”, es decir, con una IP asociada en todos los hosts.
|
||||
* Si no tiene IP, sólo funcionará el tráfico entre pods del mismo nodo (unicast y broadcast entre nodos puede no funcionar).
|
||||
* Al asignar una IP al bridge, Linux activa la tabla ARP y gestiona correctamente los vecinos y el reenvío entre interfaces del bridge.
|
||||
|
||||
---
|
||||
|
||||
## 1.7 Limpieza de recursos
|
||||
|
||||
```bash
|
||||
kubectl delete pod multus-test
|
||||
kubectl delete pod multus-test2
|
||||
kubectl delete -f multus/nad-br-servicios.yaml
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **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.
|
||||
## 1.8 Ejemplo de estructura de archivos
|
||||
|
||||
```
|
||||
multus/
|
||||
├── nad-br-servicios.yaml
|
||||
├── test-multus-pod.yaml
|
||||
├── test-multus-pod2.yaml
|
||||
└── readme.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4. Instalación y configuración de MetalLB (LoadBalancer local)
|
||||
## 1.9 Resumen rápido
|
||||
|
||||
* Multus + bridge = pods multi-homed en redes físicas.
|
||||
* El bridge **debe estar vivo y con IP** en todos los nodos.
|
||||
* Sin IP en el bridge, no hay tráfico entre pods en nodos distintos.
|
||||
* Puedes crear tantas NAD como bridges/VLANs requieras.
|
||||
|
||||
---
|
||||
|
||||
# 2. Instalación y configuración de MetalLB (LoadBalancer local)
|
||||
|
||||
MetalLB permite asignar IPs flotantes de tu red LAN a servicios `LoadBalancer`, igual que hacen los clústeres en la nube. Es fundamental si quieres exponer servicios como ingress, dashboards, etc., accesibles desde tu red local.
|
||||
|
||||
---
|
||||
|
||||
## a) Instala MetalLB
|
||||
## 2.1 Instala MetalLB
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml
|
||||
@@ -119,7 +170,7 @@ Esto crea el namespace `metallb-system` y despliega los pods necesarios.
|
||||
|
||||
---
|
||||
|
||||
## b) Define un pool con múltiples rangos
|
||||
## 2.2 Define un pool con múltiples rangos
|
||||
|
||||
En lugar de crear múltiples `IPAddressPool` por separado, puedes declarar varios rangos de IP en un **solo** `IPAddressPool`. Esto simplifica la gestión.
|
||||
|
||||
@@ -164,7 +215,7 @@ kubectl apply -k metallb/
|
||||
|
||||
---
|
||||
|
||||
## c) Asignar una IP concreta al Service (`loadBalancerIP`)
|
||||
## 2.3 Asignar una IP concreta al Service (`loadBalancerIP`)
|
||||
|
||||
Puedes indicar directamente la IP deseada usando el campo `loadBalancerIP`, y MetalLB la asignará si pertenece a uno de los rangos definidos.
|
||||
|
||||
@@ -207,7 +258,7 @@ MetalLB seleccionará automáticamente una IP libre de **cualquier** rango decla
|
||||
|
||||
---
|
||||
|
||||
## d) Verificar los resultados
|
||||
## 2.4 Verificar los resultados
|
||||
|
||||
```bash
|
||||
kubectl get svc
|
||||
|
||||
Reference in New Issue
Block a user