# 📘 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

```bash
.
├── 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.

```yaml
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.

```yaml
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.

```yaml
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.

```yaml
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

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: gitea-config
  namespace: gitea
data:
  APP_NAME: "Gitea en Kubernetes"
  DISABLE_REGISTRATION: "true"
```

### Secret

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: gitea-secret
  namespace: gitea
type: Opaque
data:
  MYSQL_PASSWORD: Z2l0ZWExMjM=   # base64("gitea123")
```

### Uso en Deployment

```yaml
envFrom:
  - configMapRef:
      name: gitea-config
  - secretRef:
      name: gitea-secret
```

---

## 🌍 Ingress

Define reglas de acceso HTTP/HTTPS y certificados SSL.

```yaml
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

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitea-sa
  namespace: gitea
```

### Role y RoleBinding

```yaml
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

```yaml
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:

```yaml
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

```text
   [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.