Kubernetes deployment settings

Nexo Edge runs in a customer-managed Kubernetes cluster. Treat deployment settings as workload policy: review them with the same care as pipeline behavior, database credentials, and network access.

Resource requests and limits

Set CPU and memory requests from measured steady-state load, then leave enough headroom for connection bursts, BSON processing, response transformation, and background telemetry.

• Requests must be present before CPU or memory utilization can drive an HPA reliably.
• A memory limit that is too low can restart the Proxy during large responses or traffic bursts.
• A CPU limit that is too low can appear as database latency even when MongoDB is healthy.
• Re-test resources when body logging, audit capture, masking, caching, or shadow traffic is enabled.

Start in an isolated environment, replay representative traffic, and record p95/p99 latency, memory high-water mark, throttling, connection count, and restart behavior.

Container security context

Nexo workload identities differ by workload. Edge management pods use UID and fsGroup 65534; current Operator-generated Proxy workloads use UID, GID, and fsGroup 65532. Do not copy one workload's identity into another workload's values.

Edge management chart values use:

podSecurityContext:
  runAsNonRoot: true
  runAsUser: 65534
  fsGroup: 65534
  seccompProfile:
    type: RuntimeDefault
securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

Operator-generated Proxy workloads use the same restricted container controls with a pod identity of 65532:

podSecurityContext:
  runAsNonRoot: true
  runAsUser: 65532
  runAsGroup: 65532
  fsGroup: 65532
  seccompProfile:
    type: RuntimeDefault
securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

Use only declared writable mounts such as /tmp. Do not relax the security context to work around an image, configuration, or file-permission error; correct the underlying deployment input.

Scheduling and placement

Use Kubernetes scheduling controls deliberately:

Control	Use
Node selector or affinity	Keep Nexo on approved worker pools or zones.
Tolerations	Permit scheduling only on intentionally tainted nodes.
Topology spread	Distribute replicas across zones and nodes.
Pod anti-affinity	Reduce the chance that all replicas share one failure domain.
Priority class	Protect critical data-path capacity during cluster pressure.

Keep Nexo close enough to MongoDB to meet latency goals while preserving the required network and residency boundaries.

Startup, readiness, and liveness

• Startup should allow dependency initialization without triggering premature restarts.
• Readiness controls whether a pod receives new client traffic. It must fail when the pod cannot safely serve the active configuration.
• Liveness should detect a stuck process, not transient MongoDB latency.
• Termination grace must allow readiness withdrawal and connection draining before the pod is killed.

Use the probe paths and timings published by the installed release. Do not copy values from a different chart or bundle without checking its templates and release notes.

Autoscaling and disruption

Horizontal scaling is useful only when the Service, session behavior, connection budgets, and upstream capacity can support additional replicas.

• Define an HPA from measured CPU or memory behavior.
• Set resource requests before enabling utilization-based scaling.
• Use a PodDisruptionBudget to preserve capacity during voluntary maintenance.
• Test node drain, rolling restart, scale-out, and scale-in with live connections.
• Coordinate replica count with MongoDB and connection-pool limits.

0.2.0 boundaries

The immutable 0.2.0 bundle is a Private Preview. Verify the chart-rendered probes, security context, replica behavior, and supported deployment profile before applying custom settings. Docker, Docker Compose, public VM binaries, and public air-gapped installation are not supported 0.2.0 deployment paths.

Pre-deployment review

1. Render the exact chart and values intended for the environment.
2. Confirm image, resources, security context, scheduling, probes, and disruption policy.
3. Verify NetworkPolicy, DNS, certificate, Secret, and registry access.
4. Exercise rolling restart and node drain.
5. Confirm the active Nexo version and pipeline revision after rollout.

Next steps

• Deployment topologies — choose the right deployment shape.
• Installation and deployment modes — obtain the authenticated install command.
• Production checklist — pre-go-live review.
• Operator CRD catalog — NexoProxy and NexoDeploymentProfile reference.
• Support — Private Preview support contacts.