xavor/kubernetes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

modificada estructura de la documentacion

Browse Source
This commit is contained in:
xavor
2025-07-24 18:23:13 +02:00
parent b934759ceb
commit 7fef3ea20b
9 changed files with 248 additions and 236 deletions
Download Patch File Download Diff File Expand all files Collapse all files

BIN
cephrook.pdf Normal file
View File

Binary file not shown.

219
readme-suse.md → cluster_init.md
View File

@@ -475,222 +475,3 @@ Con esto podrás unir cualquier nodo extra como nuevo control-plane, incluso cua
* Reinstala CNI plugins * Reinstala CNI plugins
* Aplica Flannel * Aplica Flannel
* Reinicia kubelet * 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
View File

Binary file not shown.

20
comprobaciones.md
View File

@@ -1,12 +1,19 @@
# **Comprobaciones y diagnóstico habitual** # **Comprobaciones y diagnóstico habitual**
### Estado de pods y despliegues
### Estado de nodos, pods y despliegues
```bash ```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 -A # Todos los pods de todos los namespaces
kubectl get pods -n traefik # Sólo los pods de Traefik kubectl get pods -n traefik # Sólo los pods de Traefik
kubectl get pods -n cert-manager # Sólo cert-manager kubectl get pods -n cert-manager # Sólo cert-manager
kubectl get deployments -A # Todos los deployments 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:* *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 ```bash
kubectl describe pod <nombre-pod> -n <namespace> kubectl describe pod <nombre-pod> -n <namespace>
kubectl logs <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 ### Servicios, IPs y estado MetalLB
@@ -21,6 +35,7 @@ kubectl logs <nombre-pod> -n <namespace>
```bash ```bash
kubectl get svc -A # Todos los servicios, revisa columna EXTERNAL-IP 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 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 ### Certificados, secrets y recursos cert-manager
@@ -28,9 +43,12 @@ kubectl get svc -n traefik # Servicio LoadBalancer de Traefik
```bash ```bash
kubectl get secrets -n traefik # Verifica el Secret TLS (ej: wildcard-cert) kubectl get secrets -n traefik # Verifica el Secret TLS (ej: wildcard-cert)
kubectl describe secret wildcard-cert -n traefik kubectl describe secret wildcard-cert -n traefik
kubectl get certificate -A # (cert-manager) lista los recursos Certificate gestionados kubectl get certificate -A # (cert-manager) lista los recursos Certificate gestionados
kubectl describe certificate <name> -n <ns> # Ver detalle y posibles errores 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 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 ### Ingress, dominios y rutas

BIN
comprobaciones.pdf Normal file
View File

Binary file not shown.

BIN
kubevirt.pdf Normal file
View File

Binary file not shown.

28
readme.md
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 | | Documento | Descripción | Referencia |
| ------------------- | ------------------------------------------ | ------------------------ | | ------------------- | ------------------------------------------ | ------------------------ |
| `readme.md` | Índice y presentación general | (Este documento) | | `cluster_init.md` | Proceso de inicializacion del cluster detallado en SUSE | [Ver](cluster_init.md) |
| `comprobaciones.md` | Checklist y pruebas tras cada paso crítico | [Ver](comprobaciones.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) | | `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) |
| `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) |
| `readme-suse.md` | Proceso de instalación detallado en SUSE | [Ver](readme-suse.md) |
--- ---
## Estado actual de los documentos ## Estado actual de la instalación
| Documento | Estado | Comentario | | Documento | Estado | Comentario |
| ------------------- | -------------- | ------------------------------------- | | ------------------- | -------------- | ------------------------------------- |
| `readme.md` | ✅ Completado | Actualizado | | `cluster_init.md` | ✅ Completado | Instalación básica validada |
| `comprobaciones.md` | ⚠️ En revisión | Añadir más pruebas específicas | | `redes_internet.md` | ⚠️ En revisión | Integración Ceph pendiente de validar |
| `cephrook.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 | | `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`. 2. Comprueba cada paso con `comprobaciones.md`.
3. Consulta el resto de documentos según el despliegue requerido (Ceph, KubeVirt, etc). 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
View File

Binary file not shown.