Kubernetes

Manifest outline

apiVersion: apps/v1
kind: Deployment
metadata:
  name: solidway
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: solidway
          image: solidway/gateway:latest
          ports:
            - { name: http, containerPort: 8080 }
            - { name: console, containerPort: 8081 }
          livenessProbe:
            httpGet: { path: /health, port: http }
          readinessProbe:
            httpGet: { path: /ready, port: http }
          volumeMounts:
            - { name: config, mountPath: /etc/solidway, readOnly: true }
            - { name: state, mountPath: /var/lib/solidway }
          resources:
            requests: { cpu: 250m, memory: 128Mi }
            limits: { memory: 512Mi }
      volumes:
        - name: config
          configMap: { name: solidway-bootstrap }
        - name: state
          persistentVolumeClaim: { claimName: solidway-state }

The two volumes are not interchangeable

The ConfigMap holds the bootstrap file: listen address, public domain, console bind. It is small, changes rarely, and is safe to treat as ordinary configuration.

The PersistentVolumeClaim holds everything the console manages — providers, credentials, encrypted secrets, routes, policy, alert rules. Do not put this in a ConfigMap. It is written at runtime, it contains secrets, and losing it means re-entering every credential.

Replicas and shared state

With more than one replica, each pod needs the same state. Two options:

Approach	Trade-off
ReadWriteMany volume	Simplest, if your storage class supports it
One replica serving the console	Console changes are made on one pod; the others read the same volume
Enterprise clustering	State is replicated between nodes and health signals are shared

Without shared state, replicas can disagree about which targets exist. A hold is per-replica in that case, which is a deliberate trade: the cost of one extra probe against an unhealthy target is lower than the cost of coordinating health across a fleet.

Probes

Probe	Endpoint	Meaning
Liveness	/health	The process is up. A failure here restarts the container.
Readiness	/ready	State directory readable and at least one provider configured

Keep the liveness probe simple. A probe that depends on an upstream provider will restart your gateway when a provider has a bad minute.

Resource sizing

Sizing is driven by connection concurrency rather than by request history:

• CPU scales with requests per second
• Memory is bounded by the configured connection pools, not by traffic volume

Start with 250m CPU and 128Mi memory for a few hundred requests per second, and raise the memory limit only if you raise the pool sizes.

Next

• Configuration
• Metrics