Advanced Configuration

Once KubeOpera is running, a few settings make the difference in production: how services are sized, how they stay available during maintenance, and how environments differ. This guide covers all three.

Sizing services

Every KubeOpera service ships with a VerticalPodAutoscaler that watches its real usage and recommends CPU and memory requests. By default it runs in recommendation mode — it suggests, you decide:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: kubeopera-frontend
  namespace: kubeopera-core
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: kubeopera-frontend
  updatePolicy:
    updateMode: "Off"

To review and apply recommendations:

1. Read the recommendation:

   kubectl get vpa kubeopera-frontend -n kubeopera-core \
     -o jsonpath='{.status.recommendation.containerRecommendations}'

2. Update the requests and limits in the service's overlay for your environment.

3. Commit — Flux rolls the change out gradually.

Why not let VPA resize automatically? Applying a new size restarts pods. Reviewing first keeps restarts deliberate. For stateless services you're comfortable restarting, you can set updateMode: "Auto" in that service's overlay.

Staying available during disruptions

Every service that runs more than one replica has a PodDisruptionBudget, so node drains, cluster upgrades and rolling deploys never take all of its pods down at once:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: kubeopera-frontend
  namespace: kubeopera-core
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: kubeopera-frontend

For production we recommend:

• at least two replicas of every user-facing service (the dashboard, kubeopera-api, auth-service);
• replicas spread across availability zones with topologySpreadConstraints;
• the default PodDisruptionBudgets left in place.

Per-environment overlays

Each service's manifests are split into base/ (identical everywhere) and overlays/<environment>/ (what differs). Use overlays for anything environment-specific — replicas, resources, connection pools, log levels, hostnames:

# fluxcd/apps/kubeopera-api/overlays/production/kustomization.yaml
resources:
  - ../../base
patches:
  - target: { kind: Deployment, name: kubeopera-api }
    patch: |
      - op: replace
        path: /spec/replicas
        value: 3
  - path: config.yaml       # production-specific settings

Keeping differences in overlays means they're visible and reviewable in Git, and a new environment can be created by adding one more overlay.

Next steps

• Configuration — every setting and where it lives.
• Monitoring — watch the platform's own health.
• Setup — how environments are structured.