modificada estructura de la documentacion

This commit is contained in:
2025-07-24 18:23:13 +02:00
parent b934759ceb
commit 7fef3ea20b
9 changed files with 248 additions and 236 deletions

BIN
cephrook.pdf Normal file

Binary file not shown.

View File

@@ -475,222 +475,3 @@ Con esto podrás unir cualquier nodo extra como nuevo control-plane, incluso cua
* Reinstala CNI plugins
* Aplica Flannel
* Reinicia kubelet
# 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.
---
# 11. 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
```bash
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml
```
Esto crea el namespace `metallb-system` y los pods necesarios.
---
## b) Declara múltiples pools de IP
Puedes crear varios pools (por ejemplo, uno para producción y otro para test, o para diferentes VLANs/segmentos). Los pools se definen en el objeto `IPAddressPool`.
**Ejemplo: `metallb/ipaddresspool.yaml`**
```yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: pool-produccion
namespace: metallb-system
spec:
addresses:
- 192.168.1.100-192.168.1.110
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: pool-lab
namespace: metallb-system
spec:
addresses:
- 192.168.2.100-192.168.2.110
```
**Ejemplo: `metallb/l2advertisement.yaml`**
```yaml
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: advert-all
namespace: metallb-system
spec: {}
```
**Kustomization:**
```yaml
resources:
- ipaddresspool.yaml
- l2advertisement.yaml
```
Para aplicar:
```bash
kubectl apply -k metallb/
```
---
## c) Asigna un pool concreto a un Service (anotaciones)
Por defecto, los Services `LoadBalancer` usan cualquier pool disponible. Para forzar el uso de un pool específico, **añade esta anotación al Service**:
```yaml
apiVersion: v1
kind: Service
metadata:
name: ejemplo-prod
annotations:
metallb.universe.tf/address-pool: pool-produccion
spec:
selector:
app: ejemplo
ports:
- port: 80
targetPort: 80
type: LoadBalancer
```
* Cambia `pool-produccion` por el nombre de pool que quieras usar.
Al crear el Service, MetalLB le asignará una IP **solo de ese pool**.
---
## d) Comprobar el resultado
```bash
kubectl get svc
```
Verás la IP asignada en la columna `EXTERNAL-IP`.
---
> **Notas:**
>
> * Puedes definir tantos pools como necesites, uno por segmento/VLAN/uso.
> * Puedes versionar los manifiestos de MetalLB en una carpeta específica del repositorio (`metallb/`).
---

BIN
cluster_init.pdf Normal file

Binary file not shown.

View File

@@ -1,12 +1,19 @@
# **Comprobaciones y diagnóstico habitual**
### Estado de pods y despliegues
### Estado de nodos, pods y despliegues
```bash
kubectl get nodes -o wide # Estado y detalles de los nodos
kubectl describe node <nombre-nodo> # Info detallada, condiciones, taints, eventos
kubectl get pods -A # Todos los pods de todos los namespaces
kubectl get pods -n traefik # Sólo los pods de Traefik
kubectl get pods -n cert-manager # Sólo cert-manager
kubectl get deployments -A # Todos los deployments
kubectl get events -A | tail -20 # Últimos eventos del clúster (errores recientes)
```
*Todos los pods deben estar en estado `Running` o `Completed`. Si alguno está en `CrashLoopBackOff` o `Error`, inspecciona con:*
@@ -14,6 +21,13 @@ kubectl get deployments -A # Todos los deployments
```bash
kubectl describe pod <nombre-pod> -n <namespace>
kubectl logs <nombre-pod> -n <namespace>
kubectl logs -f <nombre-pod> -n <namespace> # Logs en streaming (útil en troubleshooting)
```
### Estado de los control-plane y componentes críticos
```bash
kubectl get pods -n kube-system -o wide # Componentes internos: etcd, coredns, apiserver, controller, etc.
kubectl logs -n kube-system <nombre-pod> # Logs de cualquier pod de kube-system
```
### Servicios, IPs y estado MetalLB
@@ -21,6 +35,7 @@ kubectl logs <nombre-pod> -n <namespace>
```bash
kubectl get svc -A # Todos los servicios, revisa columna EXTERNAL-IP
kubectl get svc -n traefik # Servicio LoadBalancer de Traefik debe tener IP de MetalLB
kubectl describe svc <nombre-svc> -n <ns> # Ver detalles de servicio, endpoints, ports, etc.
```
### Certificados, secrets y recursos cert-manager
@@ -28,9 +43,12 @@ kubectl get svc -n traefik # Servicio LoadBalancer de Traefik
```bash
kubectl get secrets -n traefik # Verifica el Secret TLS (ej: wildcard-cert)
kubectl describe secret wildcard-cert -n traefik
kubectl get certificate -A # (cert-manager) lista los recursos Certificate gestionados
kubectl describe certificate <name> -n <ns> # Ver detalle y posibles errores
kubectl get clusterissuer,issuer -A # Ver emisores de cert-manager (staging, prod, etc.)
kubectl describe clusterissuer <name> # Detalles y eventos del issuer global
```
### Ingress, dominios y rutas

BIN
comprobaciones.pdf Normal file

Binary file not shown.

BIN
kubevirt.pdf Normal file

Binary file not shown.

View File

@@ -1,8 +1,7 @@
# Guía Oficial de Instalación de Kubernetes en SUSE
# Guía de Instalación de Kubernetes en SUSE
Este repositorio contiene los **manifiestos, scripts y documentación oficial** para desplegar y gestionar un clúster Kubernetes basado en SUSE Linux.
Este repositorio contiene los **manifiestos, scripts y documentación** para desplegar y gestionar un clúster Kubernetes basado en SUSE Linux.
> **NOTA:** Todo el proceso está documentado paso a paso, con comprobaciones, consideraciones y mejores prácticas.
---
@@ -10,25 +9,24 @@ Este repositorio contiene los **manifiestos, scripts y documentación oficial**
| Documento | Descripción | Referencia |
| ------------------- | ------------------------------------------ | ------------------------ |
| `readme.md` | Índice y presentación general | (Este documento) |
| `comprobaciones.md` | Checklist y pruebas tras cada paso crítico | [Ver](comprobaciones.md) |
| `cephrook.md` | Instalación e integración de Ceph/Rook | [Ver](cephrook.md) |
| `Clusterkey.txt` | Clave actual del clúster y certificate-key | [Ver](Clusterkey.txt) |
| `kubevirt.md` | Despliegue de KubeVirt y gestión de VMs | [Ver](kubevirt.md) |
| `readme-suse.md` | Proceso de instalación detallado en SUSE | [Ver](readme-suse.md) |
| `cluster_init.md` | Proceso de inicializacion del cluster detallado en SUSE | [Ver](cluster_init.md) |
| `redes_internet.md` | MetalLB, Multus y demas | [Ver](redes_internet.md.md) |
| `cephrook.md` | Instalación e integración de Ceph/Rook | [Ver](./cephrook.md) |
| `kubevirt.md` | Despliegue de KubeVirt y gestión de VMs | [Ver](./kubevirt.md) |
| `comprobaciones.md` | Checklist y pruebas tras cada paso crítico | [Ver](./comprobaciones.md) |
---
## Estado actual de los documentos
## Estado actual de la instalación
| Documento | Estado | Comentario |
| ------------------- | -------------- | ------------------------------------- |
| `readme.md` | ✅ Completado | Actualizado |
| `comprobaciones.md` | ⚠️ En revisión | Añadir más pruebas específicas |
| `cluster_init.md` | ✅ Completado | Instalación básica validada |
| `redes_internet.md` | ⚠️ En revisión | Integración Ceph pendiente de validar |
| `cephrook.md` | ⚠️ En revisión | Integración Ceph pendiente de validar |
| `Clusterkey.txt` | ✅ Completado | Clave generada y aplicada |
| `kubevirt.md` | ⚠️ En revisión | Revisar últimas pruebas de VMs |
| `readme-suse.md` | ✅ Completado | Instalación básica validada |
| `comprobaciones.md` | ✅ Completado | Comandistica util para debugear, lista para usar |
---
@@ -38,6 +36,4 @@ Este repositorio contiene los **manifiestos, scripts y documentación oficial**
2. Comprueba cada paso con `comprobaciones.md`.
3. Consulta el resto de documentos según el despliegue requerido (Ceph, KubeVirt, etc).
---
¿Dudas, mejoras o sugerencias? Haz un pull request o abre un issue.

217
redes_internet.md Normal file
View File

@@ -0,0 +1,217 @@
# 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).
**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
```
---
# 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í.
```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).
---
# 3. 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.
---
# 4. 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
```bash
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml
```
Esto crea el namespace `metallb-system` y los pods necesarios.
---
## b) Declara múltiples pools de IP
Puedes crear varios pools (por ejemplo, uno para producción y otro para test, o para diferentes VLANs/segmentos). Los pools se definen en el objeto `IPAddressPool`.
**Ejemplo: `metallb/ipaddresspool.yaml`**
```yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: pool-produccion
namespace: metallb-system
spec:
addresses:
- 192.168.1.100-192.168.1.110
---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: pool-lab
namespace: metallb-system
spec:
addresses:
- 192.168.2.100-192.168.2.110
```
**Ejemplo: `metallb/l2advertisement.yaml`**
```yaml
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: advert-all
namespace: metallb-system
spec: {}
```
**Kustomization:**
```yaml
resources:
- ipaddresspool.yaml
- l2advertisement.yaml
```
Para aplicar:
```bash
kubectl apply -k metallb/
```
---
## c) Asigna un pool concreto a un Service (anotaciones)
Por defecto, los Services `LoadBalancer` usan cualquier pool disponible. Para forzar el uso de un pool específico, **añade esta anotación al Service**:
```yaml
apiVersion: v1
kind: Service
metadata:
name: ejemplo-prod
annotations:
metallb.universe.tf/address-pool: pool-produccion
spec:
selector:
app: ejemplo
ports:
- port: 80
targetPort: 80
type: LoadBalancer
```
* Cambia `pool-produccion` por el nombre de pool que quieras usar.
Al crear el Service, MetalLB le asignará una IP **solo de ese pool**.
---
## d) Comprobar el resultado
```bash
kubectl get svc
```
Verás la IP asignada en la columna `EXTERNAL-IP`.
---
> **Notas:**
>
> * Puedes definir tantos pools como necesites, uno por segmento/VLAN/uso.
> * Puedes versionar los manifiestos de MetalLB en una carpeta específica del repositorio (`metallb/`).
---

BIN
redes_internet.pdf Normal file

Binary file not shown.