Skip to content

Kubernetes Deployment

CHAOTICA can be deployed on Kubernetes using standard Kubernetes manifests. While there's no official Helm chart yet, the example manifests below provide a complete deployment.

Prerequisites

  • Kubernetes cluster (1.19+)
  • kubectl configured to access your cluster
  • PostgreSQL database (can be deployed in-cluster or external)
  • Redis instance (optional, for caching)
  • Persistent storage for media files
  • Load balancer or ingress controller

Architecture

The Kubernetes deployment consists of: - Deployment: CHAOTICA Django application - Service: Internal cluster service - Ingress: External access routing - ConfigMap: Non-sensitive configuration - Secret: Sensitive configuration (passwords, keys) - PersistentVolumeClaim: Storage for media files

Deployment Manifests

Namespace

apiVersion: v1
kind: Namespace
metadata:
  name: chaotica

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: chaotica-config
  namespace: chaotica
data:
  DEBUG: "0"
  DJANGO_ENV: "Production"
  DJANGO_ALLOWED_HOSTS: "chaotica.example.com"
  SITE_DOMAIN: "chaotica.example.com"
  SITE_PROTO: "https"
  TZ: "Europe/London"

  # Database Configuration
  SQL_ENGINE: "django.db.backends.postgresql"
  RDS_DB_NAME: "chaotica"
  RDS_USERNAME: "chaotica"
  RDS_HOSTNAME: "postgresql.chaotica.svc.cluster.local"
  RDS_PORT: "5432"

  # Email Configuration
  EMAIL_BACKEND: "django.core.mail.backends.smtp.EmailBackend"
  EMAIL_HOST: "smtp.example.com"
  EMAIL_PORT: "587"
  EMAIL_USE_TLS: "True"
  DEFAULT_FROM_EMAIL: "CHAOTICA <noreply@example.com>"

Secret

apiVersion: v1
kind: Secret
metadata:
  name: chaotica-secrets
  namespace: chaotica
type: Opaque
data:
  SECRET_KEY: <base64-encoded-django-secret-key>
  RDS_PASSWORD: <base64-encoded-db-password>
  EMAIL_HOST_PASSWORD: <base64-encoded-smtp-password>
  # Optional: Azure AD integration
  ADFS_CLIENT_SECRET: <base64-encoded-client-secret>
  # Optional: AWS S3
  AWS_STORAGE_ACCESS_KEY_ID: <base64-encoded-access-key>
  AWS_STORAGE_SECRET_ACCESS_KEY: <base64-encoded-secret-key>

PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: chaotica-media
  namespace: chaotica
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard # Adjust for your cluster

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: chaotica
  namespace: chaotica
  labels:
    app: chaotica
spec:
  replicas: 2
  selector:
    matchLabels:
      app: chaotica
  template:
    metadata:
      labels:
        app: chaotica
    spec:
      containers:
      - name: chaotica
        image: brainthee/chaotica:latest
        ports:
        - containerPort: 8000
        envFrom:
        - configMapRef:
            name: chaotica-config
        - secretRef:
            name: chaotica-secrets
        volumeMounts:
        - name: media-storage
          mountPath: /app/mediafiles
        livenessProbe:
          httpGet:
            path: /health/
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health/
            port: 8000
          initialDelaySeconds: 5
          periodSeconds: 5
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "1Gi"
            cpu: "500m"
      volumes:
      - name: media-storage
        persistentVolumeClaim:
          claimName: chaotica-media

Service

apiVersion: v1
kind: Service
metadata:
  name: chaotica-service
  namespace: chaotica
spec:
  selector:
    app: chaotica
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8000
  type: ClusterIP

Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: chaotica-ingress
  namespace: chaotica
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # If using cert-manager
spec:
  tls:
  - hosts:
    - chaotica.example.com
    secretName: chaotica-tls
  rules:
  - host: chaotica.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: chaotica-service
            port:
              number: 80

Database Setup (PostgreSQL)

If you don't have an external PostgreSQL instance, you can deploy one in-cluster:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgresql
  namespace: chaotica
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      containers:
      - name: postgresql
        image: postgres:15
        env:
        - name: POSTGRES_DB
          value: "chaotica"
        - name: POSTGRES_USER
          value: "chaotica"
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: chaotica-secrets
              key: RDS_PASSWORD
        volumeMounts:
        - name: postgres-data
          mountPath: /var/lib/postgresql/data
        ports:
        - containerPort: 5432
      volumes:
      - name: postgres-data
        persistentVolumeClaim:
          claimName: postgres-data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
  namespace: chaotica
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgresql
  namespace: chaotica
spec:
  selector:
    app: postgresql
  ports:
  - port: 5432

Deployment Steps

  1. Create namespace and apply basic resources:

    kubectl apply -f namespace.yaml
    kubectl apply -f configmap.yaml
    kubectl apply -f secret.yaml
    kubectl apply -f pvc.yaml
    

  2. Deploy database (if using in-cluster PostgreSQL):

    kubectl apply -f postgresql.yaml
    

  3. Deploy CHAOTICA application:

    kubectl apply -f deployment.yaml
    kubectl apply -f service.yaml
    

  4. Setup ingress:

    kubectl apply -f ingress.yaml
    

  5. Initialize database:

    kubectl exec -it deployment/chaotica -n chaotica -- python manage.py migrate
    kubectl exec -it deployment/chaotica -n chaotica -- python manage.py createsuperuser
    kubectl exec -it deployment/chaotica -n chaotica -- python manage.py collectstatic --noinput
    

Scaling and High Availability

Horizontal Pod Autoscaler

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: chaotica-hpa
  namespace: chaotica
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: chaotica
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Pod Disruption Budget

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: chaotica-pdb
  namespace: chaotica
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: chaotica

Monitoring

Health Check Endpoint

CHAOTICA provides a /health/ endpoint for Kubernetes health checks. The liveness and readiness probes in the deployment use this endpoint.

Logging

Configure log aggregation to collect Django logs:

# Add to container spec
env:
- name: LOGGING_CONFIG
  value: "kubernetes"

Backup Strategy

  1. Database Backups:

    kubectl exec -it deployment/postgresql -n chaotica -- \
      pg_dump -U chaotica chaotica > backup-$(date +%Y%m%d).sql
    

  2. Media Files Backup: Use your storage provider's backup solution or create a backup job:

    kubectl create job --from=cronjob/backup-media backup-media-manual -n chaotica
    

Troubleshooting

  1. Check pod status:

    kubectl get pods -n chaotica
    kubectl logs -f deployment/chaotica -n chaotica
    

  2. Database connectivity:

    kubectl exec -it deployment/chaotica -n chaotica -- \
      python manage.py dbshell
    

  3. Configuration issues:

    kubectl describe configmap chaotica-config -n chaotica
    kubectl describe secret chaotica-secrets -n chaotica
    

Production Considerations

  • Use external managed database services (AWS RDS, Google Cloud SQL, etc.)
  • Implement proper backup and disaster recovery procedures
  • Use secrets management solutions (AWS Secrets Manager, Azure Key Vault, etc.)
  • Configure monitoring and alerting (Prometheus, Grafana)
  • Set up log aggregation (ELK stack, Fluentd)
  • Use network policies for security
  • Implement resource limits and requests appropriately
  • Consider using a service mesh for advanced traffic management