Skip to content

Platform Administration

Task-oriented guides for the people who install, upgrade, monitor, secure, and recover a Cloud-Native DCS deployment. If you are a platform engineer, SRE, or infrastructure owner responsible for keeping the DCS itself running, start here.

If you are a process engineer or operator running batches, go to Batch Operations instead.

Requirements you must meet vs one way to meet them

The Platform Administration section separates what a deployment must satisfy (in this repo) from one verified way to satisfy it (in the cndcs-deploy-demo sibling repo). The split keeps requirements honest -- they are the contract the platform owes the chart, regardless of whether you provision with Terraform, OpenTofu, ClickOps, or hand-rolled Ansible -- while letting the worked example evolve without forcing every customer to adopt that exact toolchain.

Requirement (this repo) One worked example (cndcs-deploy-demo)
Storage class with capacity enforcement flux/clusters/demo/apps/dcs-release.yaml -- DigitalOcean Block Storage CSI on the demo
Cluster topology and admission-webhook HA terraform/modules/digitalocean/ -- droplet sizing, Talos machine config, DNS
Capacity planning math flux/clusters/demo/apps/dcs-release.yaml chart values calibrated to the demo's tag count
Required Prometheus alerts flux/clusters/demo/apps/kube-prometheus-stack.yaml -- HelmRelease wiring kube-prometheus-stack to the chart's ServiceMonitor + PrometheusRule
Operator hardening (priorityClass, replicas, failurePolicy) flux/clusters/demo/apps/cnpg-operator.yaml -- CNPG operator HelmRelease
Backup and DR strategy The reference deployment intentionally does not enable backups; production deployments override historian.backup values
Security hardening (OIDC, mTLS, network policies) terraform/modules/auth0/ -- OIDC tenant provisioning
Bootstrapping a fresh cluster scripts/bootstrap.sh -- end-to-end provision + Flux install

When the worked example does something the requirement docs do not mandate (picking DigitalOcean, picking Auth0, picking Talos), it is a worked-example choice -- not a requirement on you. Your environment may have its own storage CSI, IdP, and Kubernetes distribution.

Documentation Coverage

The core operational paths -- install and upgrade, monitoring, backup and recovery, and security hardening -- each have a complete, step-by-step runbook. A few deeper runbooks (capacity planning, DR drills) are still outlines: they carry an explicit Status callout at the top stating what is and isn't covered, and they live under the Roadmap (outlines in progress) group in the sidebar. They are published as outlines rather than hidden so you can see exactly what an evaluation can and can't lean on before you commit to it.

The control-plane contract underneath these runbooks does not churn release-to-release: the ISA-88 state machine, the operator reconcilers, the CRD schemas, and the audit trail are the stable surfaces the Helm chart and your manifests depend on. Where a runbook is still an outline, it is the operational procedure around that contract that is being filled in -- not the contract itself.

Sections

  • Install and Upgrade -- deploy, upgrade, roll back, and plan capacity for a cluster. Start with Deploy Your Own for a single-cluster install, then read Production Deployment before sizing a customer-grade environment.
  • Operations -- monitor, debug, and maintain a running system. High availability and failure-mode references live here.
  • Backup and DR -- back up stateful components and recover from disasters with tested restore procedures.
  • Security -- harden the platform, rotate secrets and certificates, and operate day-to-day security tasks.
  • Device Fleet -- register and manage the edge devices that host unit runtimes.