Services (zop-helm deployment chart)
What does zop.dev create for Services (zop-helm deployment chart)?
ZopDay deploys each service as a Helm release of the `zop/service` chart (version 0.0.31). It sets the image, port, replica count, environment variables, a liveness path that turns on both probes, CPU and memory bounds, and an ingress host or load balancer. The chart's own alert rules cover crash-loop, not-ready and high CPU or memory.
| 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
ZopDay sets: name (plus serviceName and fullnameOverride on the deploy-job path), image, httpPort, minReplicas, env, imagePullSecrets, heartbeatURL plus liveness and readiness probes (when a liveness path is given), minCPU, maxCPU, minMemory, maxMemory, nginx host, TLS secret name and annotations for ingress class, TLS issuer and any you add (when exposed through ingress), serviceType (when exposed through a load balancer). Every other chart value stays at the chart default.What the chart’s alerts watch by default
The chart’s own alert rules cover crash-loop, not-ready, and high CPU or memory out of the box.
Alerting is part of the deploy
Every service ships with the chart’s alert rules active from the first deploy: crash-loop, not-ready, and high CPU or memory. They run on the cluster’s prometheus-operator stack, which the deploy baseline installs when the cluster has none. To get them through ZopDay’s notification channels, turn on Service Alerts for the space; a per-service override can switch one noisy service off. That ordering is the point: the alert exists from the first deploy, so once Service Alerts is on, the first bad rollout pages someone instead of being discovered by users. A failed deploy raises its own alert as well.
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 replica count then multiplies 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.
What ZopDay leaves at chart defaults
The chart carries more values than ZopDay sets, such as embedded-database volumes, database SSL and messaging flags. ZopDay does not send them, so they stay at the chart’s defaults. Keep that in mind when reading the chart’s documentation: a value listed there is not necessarily a field you can set from ZopDay.