Image source - https://events.linuxfoundation.org/
I attended KubeCon + CloudNativeCon India 2026 for the first time this year. Rather than documenting every session, I wanted to capture the ideas, technologies, and trends that stood out.
The talks I attended largely fell into three buckets:
What became apparent throughout the conference, however, was that these domains are increasingly converging.
Below are my notes and takeaways.
Traditional load balancers assume all replicas are equal.
For LLM workloads, that’s often not true.
LLMd proposes routing inference requests based on:
Instead of blindly distributing traffic, requests can be routed to pods that already contain relevant context, reducing recomputation and improving GPU utilization.
Takeaway: The best destination for an AI request is not always the least-loaded pod.
This session focused on understanding three concepts that increasingly appear together:
Rather than viewing them independently, the talk showed how they combine to form adaptive AI platforms.
One particularly interesting idea was using agents to influence infrastructure decisions dynamically, allowing workloads to optimize GPU allocation and scheduling in real time.
Kubernetes is no longer just hosting AI workloads.
AI workloads are beginning to participate in infrastructure decisions themselves.
Takeaway: Kubernetes is becoming a platform increasingly managed by AI systems.
One recurring theme throughout KubeCon was that an AI application is much more than an LLM endpoint.
Production systems require:
The session also emphasized LangChain4J as a Java-native framework for building agent workflows.
Interesting orchestration patterns included:
As systems evolve from:
1 Service
1 Model
to:
N Services
M Models
K Agents
the challenge shifts away from prompting and toward orchestration, state management, and reliability.
Takeaway: Agentic systems should be treated as distributed systems.
A long-standing container security problem is that root inside a container often maps to root on the host.
Kubernetes User Namespaces address this by mapping container root to an unprivileged user on the host.
Benefits include:
The session also demonstrated how this mitigates several container escape scenarios.
Takeaway: Root inside a container should not imply root on the host.
The moment an AI system executes generated code, it effectively becomes a remote code execution platform.
The challenge is obvious:
The session focused on building production-grade sandboxes using:
The emphasis was not only on security but also on operational challenges such as startup latency, observability, and scaling thousands of short-lived execution environments.
Takeaway: Treat AI-generated code exactly like code submitted by an unknown internet user.
This session demonstrated how a Next.js RCE vulnerability can evolve into a Kubernetes security incident.
Attack progression:
Application RCE
↓
Container Access
↓
Payload Download
↓
Crypto Mining
↓
Resource Abuse
Defensive controls included:
Patching is necessary, but it is rarely sufficient.
The real outcome depends on the controls available after compromise.
Takeaway: Defense-in-depth determines the blast radius of a successful attack.
Every AI request creates a chain of data movement.
A seemingly simple prompt may involve:
Organizations often know where their databases reside but cannot explain where a prompt traveled.
The proposed concept was an AI Receipt using OpenTelemetry traces to reconstruct the full lifecycle of an AI request.
As AI adoption increases, data sovereignty and governance become observability problems.
Questions such as:
need verifiable answers.
Takeaway: AI observability must include data lineage, not just application telemetry.
As SBOM requirements become more common, organizations face a difficult tradeoff:
The proposed solution used Merkle-tree commitments to separate verification from disclosure.
Instead of sharing an entire SBOM:
This introduces the concept of selective disclosure for compliance.
Organizations can prove integrity without exposing their entire software composition.
Takeaway: Compliance may increasingly rely on cryptographic proofs rather than trust-based reporting.
One of the more practical sessions focused on translating compliance requirements directly into machine-enforceable policies.
The model consisted of three layers:
Catch violations during CI/CD.
Block non-compliant workloads from reaching production.
Continuously gather evidence and monitor environments.
Compliance often becomes a periodic audit exercise.
Policy-as-Code shifts compliance into the software delivery lifecycle itself.
Takeaway: Compliance should be an engineering capability, not an audit event.
Flipkart shared how they built a centralized chaos engineering platform on top of LitmusChaos.
Interesting implementation details included:
The platform transformed chaos engineering from isolated experiments into a reusable organizational capability.
Takeaway: Reliability practices become impactful when they are self-service and repeatable.
Cluster-wide policies provide strong governance but also create large blast radii.
A single policy mistake can impact every workload in a cluster.
The session explored namespace-scoped policy models that provide:
Not every policy needs to be cluster-wide.
Many application-specific controls are better managed closer to the workloads they govern.
Takeaway: Policy scope is a security decision.
This lightning talk framed software supply chain security around five trust boundaries:
Recommended controls included:
The message was simple:
Security failures often occur between stages rather than within stages.
Takeaway: Secure the entire software delivery lifecycle, not just the Kubernetes cluster.
Most vulnerability management programs still rely heavily on version matching.
This session argued that many kernel vulnerabilities may not be exploitable because the vulnerable code:
The proposed approach maps CVEs to vulnerable functions and performs reachability analysis using:
This can significantly reduce vulnerability noise while helping teams focus on vulnerabilities that represent practical risk.
Takeaway: Risk should be based on reachability, not simply the presence of vulnerable code.
This keynote was less about technology and more about the people responsible for maintaining it.
Security discussions often focus on:
What is often ignored is the human effort required to:
The session explored how AI may simultaneously increase and reduce this burden.
Takeaway: Every vulnerability has a CVSS score, but every vulnerability also has a human cost.
Across AI, security, and platform engineering sessions, three ideas surfaced repeatedly.
The conversation is no longer about calling LLM APIs.
It is about:
Kubernetes is rapidly becoming the default platform for AI systems.
Several talks focused on proving security properties instead of assuming them.
Examples included:
The common theme was verifiable security.
Whether the topic was:
the goal was consistent:
Move operational complexity into the platform so application teams can focus on delivering business value Overall, KubeCon 2026 reinforced that Kubernetes is no longer just a container orchestration platform. It is increasingly becoming the operating system for AI, security, compliance, and modern platform engineering.
If any of these topics interest you, feel free to reach out. I would be happy to share session links, references, and more detailed notes.