Services (zop-helm deployment chart)
What does zop.dev create for Services (zop-helm deployment chart)?
zop.dev deploys a service as a Helm release from zopdev/helm-charts with about 45 inputs covering the Deployment, HPA, PodDisruptionBudget, ingress, probes, and mounts, and 4 infra alerts fire out of the box: unavailable replicas, pod restarts, HPA nearing max, and memory or CPU utilisation.
| Field | Value |
|---|---|
| Cloud | cross-provider |
A service in zop.dev is a containerized application deployed to a namespace with production defaults: autoscaling, health probes, alerts, and ingress are part of the spec, not an afterthought.
One Helm release covering deployment to alerts
A Helm release from zopdev/helm-charts covering the Deployment, HPA, PodDisruptionBudget, Service, ingress, probes, config and secret mounts, and alert rules.
Ports, probes, scaling limits, and mounts
About 45 inputs: image, replicas, cli_service, http/metrics/rpc ports, min/max CPU and memory, HPA limits, PDB min_available, readiness and liveness probes, env, command, configmaps and secrets, volumes including pvc_badger, db_ssl_enabled, pub_sub, infra_alerts and custom_alerts, heartbeat_url. Application-level flags: database, redis, pubsub, badgerDB, ingress, basicAuth, datastoreConnections, minPod/maxPod, defaultImage.What infra_alerts watches by default
infra_alerts cover unavailable replicas, pod restarts, HPA nearing max, and memory/CPU utilisation out of the box.
Alerting is part of the deploy
Every service ships with infra_alerts active before anyone writes a dashboard: unavailable
replicas, pod restarts, HPA nearing its ceiling, and memory/CPU utilisation. That
ordering is the point: the alert exists from the first deploy, so the first bad rollout pages
someone instead of being discovered by users. custom_alerts and heartbeat_url extend the
same channel to application-level signals, and cronjob-style dead-man switches, without a
separate monitoring setup per team.
Requests are the real bill
The min/max CPU and memory inputs do double duty: they bound each pod, and in aggregate they
drive cluster autoscaling, since requested-but-unused capacity still forces nodes into existence.
The HPA limits and minPod/maxPod flags then multiply whatever per-pod appetite was
declared. When a cluster’s node bill climbs without traffic growth, over-requested services
are the usual cause, and the fix is in these fields rather than in the node pools.
The HPA and PDB work as a pair
Autoscaling handles load; the PodDisruptionBudget (min_available) handles survival during
node drains and upgrades. Configured together, as the spec encourages, a service scales up
under pressure and cannot be drained below its floor during maintenance. Configured apart, the
classic failure appears: an HPA-scaled service reduced to a single pod at the exact moment a
node upgrade evicts it.
State and wiring are opt-in flags
The spec carries deliberate escape hatches: pvc_badger for embedded-database volumes,
db_ssl_enabled and datastoreConnections for database wiring, pub_sub for messaging,
config and secret mounts for the rest. Each flag pulls real infrastructure behavior into an
otherwise stateless deployment. Flip them consciously, since a service with a PVC
stops being freely reschedulable the day the volume binds.