6.5 KiB
6.5 KiB
📘 README: Estructura típica de manifiestos Kubernetes
Este documento explica cómo funciona una estructura típica de manifiestos, usando como ejemplo el despliegue de Gitea. Se incluyen además recursos comunes como ConfigMap, Secret y RBAC.
📂 Estructura de carpetas
.
├── deployments/ # Definición de aplicaciones (Gitea, DB)
├── ingress/ # Reglas de entrada HTTP/HTTPS
├── pvc/ # Volúmenes persistentes
├── services/ # Servicios internos/externos
├── configmaps/ # ConfigMaps y Secrets
├── rbac/ # Roles, bindings y service accounts
├── namespace.yaml # Namespace dedicado
├── kustomization.yaml # Orquestación de todos los manifiestos
└── copypod.yaml # Pod auxiliar para pruebas
📦 Namespace
Un Namespace organiza recursos en espacios lógicos independientes.
apiVersion: v1
kind: Namespace
metadata:
name: gitea
💾 PVC (PersistentVolumeClaim)
-
Solicitan almacenamiento del clúster a través de un StorageClass.
-
Dos parámetros clave:
accessModes: RWO (ReadWriteOnce) o RWX (ReadWriteMany).storageClassName: backend de almacenamiento.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gitea-data
namespace: gitea
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: ceph-rbd
🚀 Deployment
Un Deployment gestiona pods de forma declarativa: cuántas réplicas, qué imagen usar y cómo actualizarlas.
- Pod: instancia única.
- Deployment: controla réplicas y actualizaciones.
- DaemonSet: asegura un pod en cada nodo.
apiVersion: apps/v1
kind: Deployment
metadata:
name: gitea
namespace: gitea
spec:
replicas: 1
template:
spec:
containers:
- name: gitea
image: gitea/gitea:latest
env:
- name: GITEA__database__HOST
value: "gitea-db:3306"
volumeMounts:
- name: gitea-data
mountPath: /data
volumes:
- name: gitea-data
persistentVolumeClaim:
claimName: gitea-data
🌐 Service
Los Services exponen pods a la red interna o externa.
- ClusterIP: acceso solo dentro del clúster.
- NodePort: expone un puerto fijo en cada nodo.
- LoadBalancer: IP externa asignada por un balanceador.
apiVersion: v1
kind: Service
metadata:
name: gitea
namespace: gitea
spec:
type: NodePort
selector:
app: gitea
ports:
- port: 3000
targetPort: 3000
nodePort: 30300
⚙️ ConfigMap y 🔐 Secret
Ambos permiten inyectar configuración en los pods:
- ConfigMap: datos no sensibles (ej. flags, configuración).
- Secret: datos sensibles (ej. contraseñas, tokens). Codificados en base64.
ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: gitea-config
namespace: gitea
data:
APP_NAME: "Gitea en Kubernetes"
DISABLE_REGISTRATION: "true"
Secret
apiVersion: v1
kind: Secret
metadata:
name: gitea-secret
namespace: gitea
type: Opaque
data:
MYSQL_PASSWORD: Z2l0ZWExMjM= # base64("gitea123")
Uso en Deployment
envFrom:
- configMapRef:
name: gitea-config
- secretRef:
name: gitea-secret
🌍 Ingress
Define reglas de acceso HTTP/HTTPS y certificados SSL.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: gitea
namespace: gitea
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/configuration-snippet: |
allow 192.168.0.0/24;
deny all;
spec:
ingressClassName: nginx
tls:
- hosts:
- git.c2et.net
secretName: gitea-tls
rules:
- host: git.c2et.net
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: gitea
port:
number: 3000
🔑 RBAC (Roles y permisos)
ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitea-sa
namespace: gitea
Role y RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: gitea
name: gitea-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: gitea-binding
namespace: gitea
subjects:
- kind: ServiceAccount
name: gitea-sa
namespace: gitea
roleRef:
kind: Role
name: gitea-role
apiGroup: rbac.authorization.k8s.io
ClusterRole y ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: view-nodes
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: gitea-nodes-binding
subjects:
- kind: ServiceAccount
name: gitea-sa
namespace: gitea
roleRef:
kind: ClusterRole
name: view-nodes
apiGroup: rbac.authorization.k8s.io
🧩 Kustomization
Agrupa todos los recursos:
resources:
- namespace.yaml
- pvc/gitea-data.yaml
- pvc/gitea-db.yaml
- deployments/gitea.yaml
- deployments/gitea-db.yaml
- services/gitea.yaml
- services/gitea-db.yaml
- ingress/ingress.yaml
- configmaps/gitea-config.yaml
- configmaps/gitea-secret.yaml
- rbac/
📊 Diagrama ASCII de relaciones
[Usuario]
│
▼
[Ingress] ──▶ [Service] ──▶ [Deployment] ──▶ [Pod]
│ │
│ ├── usa [PVC] para datos
│ ├── usa [ConfigMap] para config
│ └── usa [Secret] para credenciales
│
└── certificados gestionados por cert-manager
[RBAC] ──▶ controla acceso de ServiceAccounts al API
✅ Resumen
- Namespace → organiza recursos.
- PVC → almacenamiento abstracto.
- Deployment → despliegue controlado.
- Service → expone pods.
- ConfigMap → datos no sensibles.
- Secret → datos sensibles (base64).
- Ingress → dominios y certificados.
- RBAC → seguridad y permisos.
- Kustomization → despliegue orquestado.
➡️ Con esta estructura modular, los manifiestos son claros, seguros y reutilizables.