Operations | Monitoring | ITSM | DevOps | Cloud

Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a vendor’s cloud. Someone on the data team deployed a LangGraph service to a VM with a database key in an environment variable, and someone else is running an agent framework on a laptop with production credentials in a dotfile. Each of these is a hosting decision.

Somewhere in most production setups there is a container that stays awake all week to do one job on Friday. Maybe it re-indexes a database. Maybe it runs a batch report, or a data migration that only matters at month end. Either way, the resources are billed for seven days. Task containers close that gap. They are ephemeral, API-triggered containers that spin up inside an Upsun Cloud environment, run exactly one command, and remove themselves when that command exits. Nothing sits idle between runs.

Kubernetes normally excels at preserving uptime during maintenance tasks, but it’s not always perfect. Even something as benign as consolidating nodes after a traffic spike could take your application offline if not done carefully. This is where PodDisruptionBudgets (PDBs) come in. In this blog, we’ll explain why PDBs are important, what the risks are of not implementing them, and how you can find out which of your own deployments are missing PDB definitions. ‍

If you've ever inherited a cluster that nobody fully understands, or watched two teams solve the same infrastructure problem in completely different ways, you've already felt the cost of not having a template strategy. It's not always dramatic; it starts with a different CNI here, a missing cert-manager version there, but it compounds. Six months later, cluster configuration is tribal knowledge, and the platform team has become the bottleneck.

A practitioner's category-by-category breakdown of the best tools for automating Kubernetes deployments in 2026 - Argo CD, Flux CD, Helm, Kustomize, KEDA, Kyverno, OPA Gatekeeper, Karpenter, Cluster Autoscaler, Rancher, Portainer, Terraform and Crossplane - plus which 3 to 5 you actually need, and how a platform like Qovery automates the whole chain from cluster creation to upgrades in under 15 minutes. Romaric founded Qovery to make Kubernetes accessible to every engineering team.

Function containers on Cycle have always been the efficient way to run batch jobs and workloads, with far more customization than traditional FaaS or serverless. What they couldn't do was run themselves. Over the past year, team after team told us the same thing: they wanted these functions on a schedule without standing up and babysitting a cron service. As of this release, Cycle fully supports CRON scheduled function containers.

The OpenTelemetry Operator changed how teams approach telemetry collection in Kubernetes. The core appeal of zero-code instrumentation is that you can bring up telemetry inside application containers to collect traces, metrics, and logs without touching your source code or rebuilding your container images. However, if you follow the default OpenTelemetry Operator documentation, you quickly run into a heavy operational prerequisite: the Instrumentation CRD.

Table of Contents Kubernetes resource optimization appears to be a single problem, but the platforms that address it disagree on almost every design decision, starting with how they analyze workload demands. Some set CPU and memory requests from live signals, while others learn a workload’s historical pattern and provision ahead of it.