GovernanceMode on k3s

How a request reaches a service

The app is served on the bare IP over plain HTTP at http://84.8.125.207/governance_mode/ (no domain yet). Everything enters through one Ingress; the app's own nginx inside the web pod does the routing, the same file the compose stack used.

What runs, and what it uses

Measured with kubectl top about 10 minutes after the switch, at idle. Every pod has a health check, and Kubernetes restarts a pod that fails it.

Can compose and k3s run at the same time?

Not usefully, and it isn't recommended. Memory alone would almost fit, but two other things block it:

• Memory: at idle the two together reach ~78%, just under the 80% line where the gm-watchdog starts stopping things. One export or image build would cross it.
• Ports: both need port 80 and 7002 on the same IP. Compose would have to move to other ports. The built SPA calls http://84.8.125.207 and :7002, so a compose front end on other ports would still talk to the k3s backend unless its web image is rebuilt.
• Data: each stack has its own copy of Mongo and uploads. Running both means two copies drifting apart.

Data and secrets

Images come from registry.servers.advancedcontrols.tech/governance-mode/*:3.0.0-20261101. Every tag is pinned, the chart refuses to render without one, and the push script refuses to overwrite an existing tag.

Day-to-day operations

The kit lives in ~/gm-k3s on the host (chart, site values, scripts, pinned k3s/helm/ingress files). RUNBOOK.txt there has every step.

# state
kubectl -n governance-mode get pods
kubectl -n governance-mode top pods

# full smoke test through the public IP (asks for the Admin1 password;
# creates one test regulator and removes it again)
BASE=http://84.8.125.207 WS_HOST=84.8.125.207 bash ~/gm-k3s/scripts/30-validate.sh

# new build: rebuild gm3/*, bump global.image.tag in site/84.8.125.207.yaml, then
bash ~/gm-k3s/scripts/05-push-images.sh
sudo bash ~/gm-k3s/scripts/20-deploy.sh

# changed a .env? same deploy; the pods roll
sudo bash ~/gm-k3s/scripts/20-deploy.sh

Rollback to compose

sudo k3s kubectl -n governance-mode scale deploy,sts --all --replicas=0
sudo k3s kubectl -n ingress-nginx  scale deploy --all --replicas=0
sudo k3s kubectl -n governance-mode delete svc notification-reverb     # frees :7002
sudo k3s kubectl -n ingress-nginx  delete svc ingress-nginx-controller # frees :80/:443
cd ~/datamode/docker-stack-v3 && docker compose up -d

Compose comes back with its data as of the switch (2026-11-01 15:42 UTC). Anything changed on k3s after that is not in it.

Guard rails

• gm-watchdog (systemd on the host): at 80% RAM, disk or sustained CPU it first stops GovernanceMode batch jobs (builds, pushes, imports, helm). Then it scales this namespace to 0, then stops compose. It never touches ITSM.
• kubelet eviction: pods are evicted before the node runs out of memory (<800 Mi) or disk (<10%). 1 GiB is reserved for the system.
• Health checks: each PHP service is checked on the RoadRunner status port (:2114) and by the image's own healthcheck script (scheduler and queue still running). The gateway is checked on /up, Mongo with a ping, Redis with PING.
• Never two copies: deployments use the Recreate strategy. A second copy of a service would share its files and its scheduler.

Known limits

• A single node, with no high availability. If the VM goes down, the app does too.
• Plain HTTP on the IP only. A domain needs a DNS record first. After that, the chart can get a Let's Encrypt certificate with two value changes (global.domain, global.tls.mode), and the web image has to be rebuilt for the new URL.
• Mongo runs without authentication, the same as compose and the reference host. Only the NetworkPolicy keeps it inside the namespace.
• Business Continuity (continuity) is off until its repo is fixed.
• Exports always come back as "queued" (HTTP 202). The service goes async on its own, and the file arrives as an in-app notification. The email copy fails because the admin's address isn't deliverable.