Solutions · DevOps & SRE

Ship upgrades, not outages

Plural takes the toil out of day-2: version upgrades, add-on compatibility, safe workload drains, and incident triage, all through PRs your team reviews.

Book a demo Try the drain simulator

Trusted by platform teams at

Sound familiar?

Why upgrades take a quarter

01 · Downtime

Every node reboots

A node-by-node drain restarts pods without knowing which deployment owns them. Apps that don’t tolerate restarts go down.

02 · Breakage

Upgrade risk is scattered

Upgrade insights live in every AWS account and region, and risky add-ons stay hidden until upgrade day.

03 · Toil

Only seniors can do it

Upgrades land on principal engineers, cluster by cluster, while the roadmap waits.

Upgrade insights

Every cluster’s upgrade risk, in one place

Plural pulls EKS upgrade insights from every account and region, adds its own upgrade intelligence, and flags add-ons that could block your next version.

No switching between AWS accounts and regions
Cloud provider and Plural insights, combined
EKS add-ons flagged as latent upgrade risks
Permissions set up automatically at bootstrap

Read the docs

“We reduced our k8s upgrade cycles from 3 months to 1 day.”

Director of DevOps
Global cybersecurity provider

Upgrade insights · all accountsrefreshed every 10m

CLUSTER	ACCOUNT · REGION	VERSION	EKS INSIGHTS	ADD-ON RISK	READINESS
prod-us-east	acct-prod · us-east-1	1.31 → 1.32	2 issues	vpc-cni	● Blocked
prod-eu	acct-prod · eu-west-1	1.31 → 1.32	clear	none	● Ready
staging	acct-stage · us-west-2	1.31 → 1.32	1 issue	coredns	● Fix PR open
dev-ap	acct-dev · ap-south-1	1.32 → 1.33	clear	none	● Ready

→ 2 of 4 clusters ready · fix PRs opened for the rest

Cluster drain management

Move workloads without downtime

Instead of rebooting node by node, Plural gracefully restarts each opted-in deployment, statefulset, and daemonset using the rollout policy your developers already tuned.

Opt in by label, per workload
Cap concurrent restarts
Order restarts in waves

Read the docs

cluster-drain.yaml

kind: ClusterDrain
spec:
  flowControl:
    maxConcurrency: 10
  labelSelector:
    matchLabels:
      deployments.plural.sh/drainable: "true"

Pipelines

Roll out across the fleet, in order

Promote upgrades from dev to staging to prod through PRs, with approval gates and a full audit trail in Git.

dev✓ upgradedstaging● drainingprod○ awaiting approval

Workbenches

Let agents take the pager first

When an alert fires, an always-on agent investigates, finds root cause, and opens the fix as a PR. Your on-call reviews instead of digging.

Meet Workbenches

alert · KubePodCrashLooping · payments-api

observability › restarts, OOMKilled

infra › limit lowered in v43

code › PR: restore 512Mi

✓ ready for review in 9 min

Try it

Watch a drain, two ways

Same cluster, same upgrade. Compare a node-by-node drain with Plural’s wave-based ClusterDrain.

ingress-nginxwave 0● running
cert-managerwave 0● running
authwave 0● running
payments-apiwave 1● running
checkoutwave 1● running
cartwave 1● running
orderswave 1● running
searchwave 1● running
notificationswave 2● running
reportingwave 2● running
workerwave 2● running
cronwave 2● running

Service availability

100%

Progress

0 of 12 workloads restarted

Workloads restart in waves, two at a time, through their own rolling update. Old pods serve traffic until new ones are ready.

From the docs and the blog

DocsUpgrade insights DocsAdd-on compatibilities GuideKubernetes probe types: liveness, readiness, startup GuideCVE response guide for Kubernetes fleets

Your next upgrade, in a day

Book a demo