Introduction

Presto is a distributed SQL engine, and Kubernetes is a platform for running distributed container workloads. Putting them together is a sensible deployment model when you want containerized operations, declarative configuration, and elastic worker management. The important design point is that Presto is not just another stateless web app: the coordinator and workers have different responsibilities, and resource tuning matters more than a generic deployment template.

Map Presto Roles to Kubernetes Objects

A Presto cluster normally has:

• one coordinator that accepts queries and plans execution
• multiple workers that process query fragments
• catalogs that define external data sources

On Kubernetes, a common layout is:

• a Deployment or StatefulSet for the coordinator
• a Deployment for the workers
• a Service for the coordinator endpoint
• 'ConfigMap objects for config.properties, jvm.config, and catalog files'

The coordinator is the stable entry point, so it normally gets a stable service name. Workers can scale horizontally more freely.

A Minimal Coordinator Deployment

This example shows the general pattern rather than every production knob.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: presto-coordinator
5spec:
6  replicas: 1
7  selector:
8    matchLabels:
9      app: presto-coordinator
10  template:
11    metadata:
12      labels:
13        app: presto-coordinator
14    spec:
15      containers:
16        - name: presto
17          image: prestodb/presto:latest
18          ports:
19            - containerPort: 8080
20          volumeMounts:
21            - name: config
22              mountPath: /opt/presto-server/etc
23      volumes:
24        - name: config
25          configMap:
26            name: presto-coordinator-config

A worker deployment looks similar, but the worker-specific config.properties differs. In Presto, role comes from configuration, not from a different binary.

Use ConfigMaps for Cluster Identity and Catalogs

The coordinator and workers must agree on cluster settings. A small configuration fragment might look like this:

1coordinator=true
2node-scheduler.include-coordinator=false
3http-server.http.port=8080
4query.max-memory=4GB
5query.max-memory-per-node=1GB

For workers:

coordinator=false
http-server.http.port=8080
query.max-memory-per-node=1GB

Catalog definitions also belong in configuration. For example, a Hive catalog file might be mounted as catalog/hive.properties.

connector.name=hive-hadoop2
hive.metastore.uri=thrift://hive-metastore:9083

This is where Kubernetes helps: catalogs, tuning, and environment-specific values can be updated declaratively.

Resource Requests and Limits Matter

Presto is memory-sensitive. If you underprovision memory or let Kubernetes evict workers unpredictably, query stability suffers.

A practical starting point is to define explicit requests and limits:

1resources:
2  requests:
3    cpu: "2"
4    memory: "4Gi"
5  limits:
6    cpu: "4"
7    memory: "8Gi"

Then align JVM heap settings and Presto memory settings with the container memory limit. Do not set Presto to assume more memory than the pod can actually use.

For analytics workloads, node autoscaling can help, but only if worker startup time and query behavior are acceptable for that elasticity model. Coordinator stability matters more than aggressive autoscaling.

Networking and Service Exposure

Clients usually talk only to the coordinator. That means:

• expose the coordinator through a Service
• optionally put an ingress or load balancer in front of it
• keep worker-to-coordinator communication inside the cluster

If users connect through HTTPS, terminate TLS either at ingress or in the service layer, depending on your platform requirements. Authentication and access control should be planned early, especially if the cluster serves multiple teams.

Operational Concerns

Running Presto on Kubernetes works well when observability is not treated as an afterthought. You want:

• readiness and liveness probes
• metrics collection from JVM and Presto endpoints
• centralized logs
• visibility into query failures and memory pressure

A readiness probe can be as simple as an HTTP check on the coordinator port. Logging and metrics will usually tell you more than Kubernetes restart counts when query behavior is poor.

Common Pitfalls

A common mistake is deploying Presto with generic web-service resource defaults. Presto needs deliberate memory and CPU tuning.

Another mistake is treating coordinator and workers as identical scaling targets. The coordinator is a control-plane component and should be handled more conservatively.

People also often forget that the real dependencies are outside the cluster: object stores, Hive metastores, and external catalogs. A healthy Kubernetes deployment still fails if those integrations are not stable.

Finally, avoid hiding all complexity behind Helm values without understanding the resulting Presto configuration. Kubernetes can orchestrate the pods, but it cannot choose sound query-engine settings for you.

Summary

• Presto maps naturally onto Kubernetes, but coordinator and worker roles should be configured separately
• Use ConfigMaps for Presto configuration and catalog definitions
• Set explicit CPU and memory requests, limits, and JVM tuning rather than relying on defaults
• Expose the coordinator as the main client entry point and keep worker traffic internal
• Monitor readiness, logs, and query memory behavior from the start
• Treat external systems such as Hive metastore and object storage as part of the deployment, not as afterthoughts