Operations | Monitoring | ITSM | DevOps | Cloud

At Tigera, we spend a lot of time thinking about agent security: identity, policy, runtime controls, and the record left behind after an agent acts. Coding agents create an interesting problem because, in most organizations, they didn’t arrive through the front door. Few companies ran a platform evaluation and rolled Claude Code out to 500 developers. Developers installed it themselves.

The conversation around sovereign cloud in India is getting louder, which is welcome, but as more providers enter the space, I keep seeing the same architectural pattern, and it's worth being direct about what it misses. The pattern is familiar... take a cloud platform, host it in India, manage it end to end, call it sovereign, and let data residency carry the rest of the argument. That works for web apps and standard enterprise workloads.

Table of Contents Resource contention happens when workloads compete for more capacity than a node or cluster can provide. For CPU and memory, the symptoms are familiar: CPU throttling, OOM kills, and noisy neighbors slowing latency-sensitive services. These are largely solved problems, addressed by accurate requests and limits, Quality of Service classes, and autoscalers like VPA and HPA that adjust sizing and replicas as demand changes. GPU contention is different, and far more expensive to get wrong.

Table of Contents Autoscaling and policy-driven resource management are two sides of the same coin. Autoscaling adjusts capacity as demand changes, while policies define the boundaries it operates within: who can use how much, which workloads can be changed, and what safeguards must be respected. Without autoscaling, clusters are either overprovisioned or overwhelmed. Without policies, autoscaling can create runaway costs, noisy neighbors, or disruptive changes to critical services.

Replay and recap of our live session: an AI agent reads a Heroku Rails app and deploys the full stack to AWS through Qovery from one prompt. Chapters, timestamps, the four ways teams leave Heroku, and the steps a human should still own. Romaric founded Qovery to make Kubernetes accessible to every engineering team. He writes about platform strategy, developer experience, and the future of cloud infrastructure.

Monitoring Kubernetes in production is structurally different from monitoring traditional servers: pods are ephemeral, nodes autoscale, and the layered resource model—containers, pods, nodes, namespaces, deployments, services—creates an observability challenge that tools built for static infrastructure were never designed to handle.

This week marks the end of our fourth Civo Navigate London event, and it feels like a good moment to say that this one had a slightly different energy from the ones before it. Over the past four years, we have hosted 10 Civo Navigate events across North America, India, and Europe, and each one has taught us something new about what this community actually wants from a day like this. London 2026 was no exception, and I think this year's lineup pushed that a little further than usual.

Jamin Ball’s recent piece, “Systems of Record Won the SaaS Era — Clearinghouses Will Win the Agents Era,” is the cleanest articulation I’ve seen of where the durable moat goes next. His argument is simple and, I think, correct: the SaaS era rewarded whoever owned the system of record, and the agent era will reward whoever owns the clearinghouse.

We build agents to take work off engineers’ plates. Then we give those engineers a new manual job: reading failed runs and babysitting prompts. Agents will improve themselves automatically. We’re not there yet, but this is the future I’m betting on. We’ve been working on this ourselves at Komodor over the past year. We know how hard it is to turn a failure into an improvement that holds up beyond a few examples.

Kubernetes has become a standard foundation for modern containerized applications, but operating clusters still requires significant engineering work. In the CNCF’s 2025 annual cloud native survey, published in January 2026, 82% of container users reported running Kubernetes in production. As adoption matures, the question for many teams is no longer whether to use Kubernetes, but how much of the operational burden they want to own.

Table of Contents GPU sharing with NVIDIA hardware is becoming easier to adopt in Kubernetes but it hasn’t been easier to observe. Time-slicing lets multiple workloads share the same GPU. MPS allows CUDA workloads to execute concurrently. Schedulers like KAI make it easier to manage these shared environments. But sharing a GPU introduces a problem that is easy to underestimate.

Provision a fresh Docker Registry with Terraform, build your container image into it, and deploy to Kubernetes in one One pipeline. One click. It provisions a fresh Docker Registry with Terraform, builds your container image into it, and deploys that image to Kubernetes. Every run creates a uniquely named registry, so you never hit naming conflicts. Creating Docker registries by hand every time you spin up a new service or environment gets tedious fast.

Human approval is easy when you are sitting in front of the agent. For an agent running by itself in a cluster, almost none of that holds. You’re in a meeting and your agent is running in a cluster. It has a service account, it has been asked to keep a service healthy, and it has just worked out that the right fix is to roll back a database migration. Nobody is watching it. That was rather the point of deploying it. You want to get notified to approve such an important action.

Compare the best Kubernetes cost management tools for 2026, from Kubecost and OpenCost to CloudZero, on allocation depth, scale, and pricing model.

Distributed AI training workloads impose complex scheduling requirements that Kubernetes’s built-in scheduler can’t meet. Kubernetes schedules pods individually and independently, but distributed training introduces two requirements that break this model: Pods must land on hardware with the right inter-GPU bandwidth, and all pods must be scheduled simultaneously. If either requirement goes unmet, training stalls or runs far below the hardware’s potential.

Agent Tasks let you run one-time or scheduled AI agents on your own infrastructure, with network guardrails, centralized MCP access and custom agent environment. Alessandro leads product at Qovery. He drives the changelog, roadmap, and product strategy - turning customer feedback into platform capabilities.

In short, this is a beginner’s guide to deploying an AI agent on Kubernetes. You will containerize an agent, store its API key as a Kubernetes secret, write a deployment with health probes and resource limits, expose it with a service, and lock down its network egress, in that order, with a working manifest at every step. On a local kind cluster the whole walkthrough takes about an hour.

Table of Contents A few months ago, we introduced Kubex support for the KAI Scheduler to improve GPU sharing for production inference workloads. The basic model is simple: The KAI Scheduler handles placement and GPU sharing. Kubex continuously observes usage and adjusts those allocations as demand changes. KAI provides the scheduling foundation. It lets multiple workloads share a GPU while accounting for the amount of GPU each workload requests. Kubex then closes the loop.

The Civo Community Slack has become home to over 35,000 engineers, platform teams, students, and practitioners. It’s one of the things we’re most proud of, a genuine space where the people who use Civo and the people who built Civo are in the same room. Since starting the Civo Community Slack, we’ve shipped an entirely new brand, launched Konstruct, and expanded our AI infrastructure.

An honest 2026 comparison of Railway, Render, Fly.io and deploying into your own AWS, GCP, Azure or Scaleway account - with the six measurable signals you have outgrown managed PaaS, a priced cost model, and a four-step framework with if-then verdicts. Romaric founded Qovery to make Kubernetes accessible to every engineering team. He writes about platform strategy, developer experience, and the future of cloud infrastructure.

Table of Contents For most of Kubernetes’ history, memory management has been a blunt instrument. Cross your limit, and the kernel kills your container. There has been no equivalent to CPU throttling, no graceful backpressure, just a hard stop. With Kubernetes 1.37, that changes: Memory QoS, built on cgroups v2, graduates to Beta and is enabled by default.

Changing a Kubernetes resource request takes two numbers: what the workload requests, and what it uses. The CloudZero MCP server now returns both, by cluster, namespace, or workload. This gives you a number you can defend. Usage comes back as P95 over the date range you query, 30 days by default. When an engineering lead asks whether a service runs on a smaller request, that is the figure that settles it. Over-provisioning and under-provisioning show up on the same query.

Cycle recently went through a System and Organization Controls (SOC) 2 Type 1 audit and we've got the report. It’s an important step in our continuous commitment to data security and system availability. But are we just checking boxes for the sake of boxes or is there more behind it?