Skip to main content
Version: 1.0

Advanced Configuration

The Setup Guide and Configuration Guide cover getting a service deployed and configured; this page covers the parts of a deployment's manifests that matter once a service is already running in production — resource governance, availability during voluntary disruptions, and per-environment overlay differences.

Vertical scaling recommendations​

Most services deploy with a VerticalPodAutoscaler in recommendation mode (updateMode: "Off") rather than actively resizing pods — it observes real usage and computes what the CPU/memory requests and limits should be, but never applies a change automatically. This is a deliberate middle ground: automatic vertical resizing restarts pods to apply a new size, which is disruptive for a stateful or latency-sensitive workload, so the recommendation is left for an operator to review and apply deliberately (usually by bumping the values in the service's own deployment.yaml and letting Flux roll it out normally) rather than have the cluster resize things unattended.

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

Staying available during voluntary disruptions​

Every service that runs with more than one replica carries a PodDisruptionBudget guaranteeing a minimum number of pods stay available during a voluntary disruption — a node drain for a Kubernetes upgrade, or a rolling deploy — rather than allowing Kubernetes to take down every replica at once. The frontend, for example, requires at least one of its two replicas to remain available at all times:

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

Per-environment overlays​

Every service's manifests are split into a base/ directory (the parts identical across every environment) and an overlays/{development,staging,production}/ directory applying whatever legitimately differs — typically replica counts, resource requests, and environment-specific configuration values, via Kustomize's patch mechanism rather than duplicating the whole manifest per environment. If a service needs to behave differently in production than in development — a larger connection pool, a stricter rate limit, a different log level — that difference belongs in its overlay, not as a runtime environment-variable toggle, so the difference is visible and reviewable in Git rather than living only in a deployed cluster's state.

Next Steps​