Zato on Kubernetes

Run Zato under Kubernetes with the whole configuration managed from Git.

Zato runs on Kubernetes as one container per pod. You install it with Helm and manage all its configuration from Git - ConfigMaps deliver every change to the running servers without a pod restart. Kubernetes checks the health of each pod through probes.

The same quickstart image that runs under Docker runs under Kubernetes - there is no separate build.

Install with Helm

The chart is part of the Zato source repository:

git clone https://github.com/zatosource/zato
helm install zato ./zato/kubernetes/helm/zato --set password.value=mypassword

The first boot creates a complete quickstart environment inside the pod and takes a few minutes. Watch the progress and confirm that the server is up:

kubectl logs -f deployment/zato
kubectl port-forward svc/zato 17010
curl http://localhost:17010/zato/ping

The password that you provided is the Dashboard password:

kubectl port-forward svc/zato 8183

Dashboard: http://localhost:8183
Username: admin
Password: the value of password.value

To keep the password out of the command line, create a Secret first and point the chart to it:

kubectl create secret generic zato-password --from-literal=Zato_Password=mypassword
helm install zato ./zato/kubernetes/helm/zato --set password.existingSecret=zato-password

Health probes

The chart wires all three probe types to the server's ping endpoint on port 17010:

A startup probe that allows up to 10 minutes, because the first boot builds the whole environment
A readiness probe, so traffic only reaches the pod once the server answers
A liveness probe, so Kubernetes restarts a hung server

You do not configure any of this - /zato/ping is a channel that exists in every environment out of the box.

Deliver configuration through ConfigMaps

Your enmasse file - channels, security definitions, outgoing connections, scheduler jobs - lives in Git and reaches the servers as a ConfigMap:

kubectl create configmap zato-enmasse --from-file=enmasse.yaml
helm upgrade zato ./zato/kubernetes/helm/zato --reuse-values --set enmasse.configMap=zato-enmasse

The server imports the file when the pod starts and re-imports it when the ConfigMap changes - without a pod restart. Applying the same file any number of times is safe.

To apply a change, update the ConfigMap and the running server picks it up:

kubectl create configmap zato-enmasse --from-file=enmasse.yaml -o yaml --dry-run=client | kubectl apply -f -

Kubernetes syncs ConfigMap updates to running pods with a delay - allow up to a minute before the change is visible inside the pod.

Deploy services through ConfigMaps

Python services reach the pod through a ConfigMap as well:

kubectl create configmap zato-services --from-file=my_service.py
helm upgrade zato ./zato/kubernetes/helm/zato --reuse-values --set services.configMap=zato-services

The server deploys the services when the pod starts and redeploys them when the ConfigMap changes, without a pod restart.

The chart sets Zato_File_Listener_Observer=polling because ConfigMap updates arrive as atomic symlink swaps that inotify, the default file-watching method, does not report.

Run more than one replica

The chart deploys one pod, and before you run more than one, meet two conditions.

Every replica needs the same external databases. A pod using the default SQLite ODB has its own copy of the environment inside itself. Point every replica at the same MySQL or PostgreSQL ODB, and at the same audit log database, before raising the replica count.

Exactly one replica should run the scheduler. Every replica otherwise runs every scheduled job, so each job fires as many times as you have pods. Set Zato_Start_Scheduler=False on the replicas that should not run it, leaving it on for one - see multi-server environments and the environment variable reference for every Zato_* variable the image supports.

Turning the scheduler off in a pod turns off everything scheduler-driven in it - the alerting sweeps and the outgoing connection health checks as well as your own jobs. The pod that keeps the scheduler runs these jobs for the whole deployment, so do not turn the scheduler off everywhere.

Expose Zato outside the cluster

The chart does not choose how external traffic enters the cluster - it works with the routing controller your cluster already runs. Tested example manifests ship in the chart's examples/ directory:

ingress.yaml - a standard Ingress resource, one host for external API clients routed to the load balancer port 11223 and one for the Dashboard routed to 8183
httproute.yaml - the same routing expressed as Gateway API HTTPRoute resources

Terminate TLS at that routing layer or pass it through to Zato's own SSL ports - see the ports reference for what listens where.

Page	What it covers
Enmasse	The YAML configuration format the ConfigMaps deliver
Default ports	What listens on each port and which ports to publish
Multi-server environments	Scaling out, HA and where the scheduler runs
Environment variables	Every variable the image supports, grouped by subject