Table of Contents
Helm guide
๐ **Complete Configuration Files Walkthrough**
Here's a step-by-step guide to understand every configuration file and how they interconnect:
**๐๏ธ Phase 1: Foundation Files**
**Step 1.1: Service Account** (`service-account.yaml`)
- snippet.yaml
# Purpose: Defines the IAM identity for all pods apiVersion: v1 kind: ServiceAccount metadata: name: llm-trace-langfuse-svc # โ Referenced by all deployments annotations: iam.gke.io/gcp-service-account: 'xdev-llm-trace-langfuse-svc@xhr-development.iam.gserviceaccount.com' argocd.argoproj.io/sync-wave: "-5" # โ Deploys first
๐ Connections:
- Referenced by: All deployment files (spec.serviceAccountName)
- Depends on: GCP IAM service account must exist
- Purpose: Provides cloud permissions for database/cache access
**Step 1.2: External Secrets** (`external-secret-db.yaml`, `external-secret.yaml`)
- snippet.yaml
# Purpose: Pulls secrets from GCP Secret Manager into Kubernetes apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: llm-trace-langfuse-db spec: secretStoreRef: name: gcp-secret-manager # โ References cluster secret store target: name: llm-trace-langfuse-db # โ Creates this k8s secret data: - secretKey: database_url # โ Maps to GCP secret remoteRef: key: xdev-llm-trace-langfuse-database-url
๐ Connections:
- Creates: Kubernetes secrets (llm-trace-langfuse-db, llm-trace-langfuse)
- Referenced by: All deployments via secretRef in envFrom
- Depends on: GCP secrets must exist before deployment
**๐ญ Phase 2: Infrastructure Layer**
**Step 2.1: PostgreSQL Infrastructure** (`base/infra/postgres/`)
- snippet.yaml
# kustomization.yaml - Defines PostgreSQL deployment helmCharts: - name: postgresql # โ Deploys Bitnami PostgreSQL valuesInline: auth: existingSecret: llm-trace-langfuse-postgres # โ References secret above primary: persistence: enabled: false # โ No persistent disk for dev
๐ Connections:
- Depends on: external-secret.yaml for database credentials
- Creates: PostgreSQL deployment, service, and persistent storage
- Referenced by: Application deployments for database connections
**Step 2.2: Redis Infrastructure** (`base/infra/redis/`)
- snippet.yaml
# kustomization.yaml - Defines Redis deployment helmCharts: - name: redis # โ Deploys Bitnami Redis valuesInline: auth: existingSecret: llm-trace-langfuse-redis # โ References secret above
๐ Connections:
- Depends on: external-secret.yaml for Redis credentials
- Creates: Redis deployment and service for caching
- Referenced by: Application for session storage and caching
**๐ฏ Phase 3: Application Layer**
**Step 3.1: ConfigMap** (`configmap.yaml`)
- snippet.yaml
# Purpose: Application configuration via environment variables apiVersion: v1 kind: ConfigMap metadata: name: config-map-llm-trace-langfuse data: LANGFUSE_HOST: "0.0.0.0" # โ Application binding OTEL_SERVICE_NAME: "llm-trace-langfuse" # โ Monitoring service name REDIS_HOST: "redis-service" # โ References Redis service
๐ Connections:
- Referenced by: All deployments via configMapRef in envFrom
- References: Redis service name for connection
- Purpose: Non-sensitive configuration that can be version controlled
**Step 3.2: Service Definition** (`rest-service.yaml`)
- snippet.yaml
# Purpose: Defines network service for load balancing apiVersion: v1 kind: Service metadata: name: llm-trace-langfuse spec: selector: app: llm-trace-langfuse # โ Matches deployment labels ports: - port: 8080 # โ Service port targetPort: 8080 # โ Container port
๐ Connections: - Referenced by: Istio VirtualService for routing - References: Deployment pod labels for pod selection - Purpose: Provides stable network endpoint for the application
**Step 3.3: Main Deployment** (`rest-deployment.yaml`)
- snippet.yaml
# Purpose: Defines the main application pods apiVersion: apps/v1 kind: Deployment metadata: name: llm-trace-langfuse spec: selector: matchLabels: app: llm-trace-langfuse # โ Must match service selector template: spec: serviceAccountName: llm-trace-langfuse-svc # โ References service account containers: - name: llm-trace-langfuse-container image: llm-trace-langfuse:latest # โ Your Docker image envFrom: # โ References all config sources - configMapRef: name: config-map-llm-trace-langfuse - secretRef: name: llm-trace-langfuse - secretRef: name: llm-trace-langfuse-db
๐ Connections: - References: ServiceAccount, ConfigMap, Secrets, Services - Referenced by: Service (via labels), KEDA ScaledObject, Istio - Purpose: Defines how application pods are created and configured
**Step 3.4: Auth Proxy Deployments** (`*-authproxyworkload.yaml`)
- snippet.yaml
# Purpose: Security layer in front of each component apiVersion: apps/v1 kind: Deployment metadata: name: llm-trace-langfuse-rest-auth-proxy spec: template: spec: containers: - name: auth-proxy env: - name: BACKEND_HOST value: "llm-trace-langfuse" # โ Routes to main deployment - name: BACKEND_PORT value: "8080"
๐ Connections: - References: Main deployment service name for routing - Referenced by: Istio VirtualService as entry point - Purpose: Provides authentication and request validation
**Step 3.5: Consumer & Migration** (`consumer-deployment.yaml`, `migration-deployment.yaml`)
- snippet.yaml
# Purpose: Background processing and database migrations spec: template: spec: containers: - name: consumer-container command: ["python", "-m", "app.consumer"] # โ Different entry point env: - name: CONSUMER_MODE value: "true" # โ Enables consumer-specific logic
๐ Connections: - Similar to: Main deployment but with different configurations - References: Same ConfigMaps and Secrets as main deployment - Purpose: Handle background jobs and database schema updates
**๐ Phase 4: Traffic Management**
**Step 4.1: Virtual Service** (`virtual-service.yaml`)
- snippet.yaml
# Purpose: Defines Istio traffic routing rules apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: llm-trace-langfuse spec: hosts: - llm-trace-langfuse # โ Service discovery name http: - route: - destination: host: llm-trace-langfuse-rest-auth-proxy # โ Routes to auth proxy first
๐ Connections: - References: Auth proxy deployment for routing - Referenced by: Istio Gateway for external access - Purpose: Controls how external traffic reaches the service
**Step 4.2: Auto-scaling** (`rest-scaled-object.yaml`)
- snippet.yaml
# Purpose: KEDA configuration for automatic scaling apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: llm-trace-langfuse-scaled-object spec: scaleTargetRef: name: llm-trace-langfuse # โ Scales main deployment triggers: - type: prometheus # โ Uses Prometheus metrics metadata: serverAddress: http://victoria-metrics-k8s-stack:8428 # โ Metrics source
๐ Connections: - References: Main deployment for scaling target - Depends on: Victoria Metrics for scaling decisions - Purpose: Automatically adjusts replica count based on load
**๐๏ธ Phase 5: Environment Customization**
**Step 5.1: Environment Kustomization** (`envs/dev/app/kustomization.yaml`)
- snippet.yaml
# Purpose: Environment-specific customizations apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - ../../../base/app # โ Includes all base configurations patchesStrategicMerge: - configmap.yaml # โ Overrides base config for dev - rest-deployment.yaml # โ Dev-specific resource limits
๐ Connections: - Includes: All base configurations as foundation - Overrides: Base settings with environment-specific values - Purpose: Customizes the service for development environment
**Step 5.2: Environment Patches** (`envs/dev/app/*.yaml`)
- snippet.yaml
# Purpose: Environment-specific modifications apiVersion: apps/v1 kind: Deployment metadata: name: llm-trace-langfuse # โ Patches base deployment spec: replicas: 1 # โ Dev-specific: single replica template: spec: containers: - resources: requests: cpu: "100m" # โ Dev-specific: lower resources memory: "512Mi"
๐ Connections: - Patches: Base deployment with dev-optimized settings - Strategic Merge: Only overrides specified sections - Purpose: Optimizes resource usage for development
**๐ Complete Dependency Chain**
**Deployment Order:**
1. Service Account (sync-wave: -5) 2. External Secrets (sync-wave: -5) 3. Infrastructure (PostgreSQL + Redis) 4. ConfigMaps and Services 5. Application Deployments 6. Auth Proxy Deployments 7. Virtual Services and Scaling
**Runtime Dependencies:**
Application Pods โโโ Service Account (IAM permissions)
โโโ External Secrets (database credentials)
โโโ ConfigMap (application config)
โโโ PostgreSQL Service (database connection)
โโโ Redis Service (cache connection)
Auth Proxy Pods โโโ Application Services (request routing)
Virtual Services โโโ Auth Proxy Services (traffic routing)
Scaled Objects โโโ Application Deployments (auto-scaling)
**๐ Key Reference Patterns**
**Label Matching:**
- snippet.yaml
# Services find pods by labels Service selector: app: llm-trace-langfuse Deployment labels: app: llm-trace-langfuse # โ Must match!
**Service Discovery:**
- snippet.yaml
# Auth proxy finds application service BACKEND_HOST: "llm-trace-langfuse" # โ Kubernetes service name
**Secret Injection:**
- snippet.yaml
# Pods get secrets as environment variables secretRef: name: llm-trace-langfuse-db # โ Created by external-secret
This interconnected web of configuration files creates a robust, scalable, and secure microservice architecture where each component has a clear purpose and well-defined relationships with other components.