From Running Kubernetes to Creating Value: Lessons from KubeCon + CloudNativeCon Japan 2026

by Ngo Sach Nhat (Chen)

Hi, I am Chen, a platform engineer at Money Forward.

KubeCon + CloudNativeCon Japan returned to Yokohama in 2026, bringing together the people building, operating, and adopting cloud native technologies. I joined the event on July 29 and 30 and came away with a stronger impression that our industry is entering a new phase.

Kubernetes itself is no longer the main story. The more important questions are now: How do we turn platform capabilities into business value? How do we let teams move independently without weakening safety? How should GitOps evolve for large fleets? And how can AI help operators while remaining bounded, explainable, and auditable?

The opening keynote, Keep Cloud Native Moving: Building Japan’s Platform for Open Innovation, emphasized sustaining momentum in cloud native and set the tone for a conference focused on the next stage of the ecosystem.

Opening keynote screen at KubeCon Japan 2026

The opening screen at KubeCon + CloudNativeCon Japan 2026. Photo by the author and included for event-reporting context.

This article shares the seven lessons that felt most relevant to our work on a service platform.

1. Start with customer and business outcomes

One of my clearest takeaways came from Turning Platform Engineering Work into Business Value Leadership Understands. Platform teams often describe their work through technical outputs: a new controller, a cluster upgrade, an automated workflow, or a self-service API. These outputs matter, but they are rarely the reason the company invests in a platform.

The session reduced the message to three practical points:

Frame the business case around customer needs rather than technical novelty.
Connect technical objectives to the business goals they support.
Use financial and operational evidence when making decisions.

For a service platform, success should therefore be expressed in outcomes such as shorter lead time, fewer support requests, reduced operational toil, safer releases, better resource utilization, and faster recovery. “We automated a process” is an implementation result. “A service team can now complete the process safely in minutes without waiting for an operator” is a value statement.

This framing also changes prioritization. The most technically interesting feature is not always the most valuable one. We should first identify where users lose the most time or face the most risk, establish a baseline, and then measure whether the platform actually improves that experience.

2. Self-service requires strong guardrails

Self-service was a recurring theme, but speakers did not present it as simply giving application teams more permissions. Effective self-service combines autonomy, safe defaults, clear documentation, and feedback when reality no longer matches the intended state.

In Scaling In Kubernetes Safely on On-Prem KaaS Across 1,300+ Clusters and 40,000+ Nodes, Shota Yoshimura shared an instructive distinction between two kinds of guardrails:

Admission policies check an individual resource before it enters the cluster. They are appropriate for static requirements such as required fields or security settings.
Alerts evaluate dynamic, cluster-wide conditions that cannot be judged from a manifest in isolation.

A PodDisruptionBudget (PDB) is a good example. With three replicas and minAvailable: 70%, Kubernetes rounds 2.1 up to three. That can leave disruptionsAllowed at zero and prevent node removal without obvious feedback when the manifest is admitted. The manifest looks reasonable, but its runtime consequence is visible only when the controller evaluates the current workload state. Static validation and runtime alerting therefore solve different parts of the safety problem.

The operational model around those guardrails was equally important. Each known scenario should have a discoverable runbook explaining the impact, likely causes, and recovery steps. Product teams can then resolve routine issues themselves, while the platform team maintains the guardrails and improves the platform instead of becoming the permanent first responder for every service.

This is a useful standard for our own platform capabilities: a feature is not truly self-service until users can understand its failure modes and recover without depending on private knowledge held by the platform team.

3. Build a platform, not only a portal or a tool

The Evolution of GitOps in Platform Engineering touched on a broader distinction between installing tools and building a platform. Deploying Backstage is not the same as building an internal developer platform. Backstage is a framework and a valuable interface, but the platform remains our responsibility.

This idea connects directly to the business-value lesson. A platform is a product for internal customers. Its quality is determined by the end-to-end journey: discovering a capability, requesting it, receiving a safe result, observing it in production, and recovering when something goes wrong. A polished user interface cannot compensate for fragmented automation or unclear ownership underneath it.

The practical approach is to begin with a real, high-friction journey, automate it end to end, document it, measure the improvement, and only then generalize it into a golden path. This avoids creating a broad abstraction before we understand the problem it must solve.

4. GitOps is evolving from a repository pattern into a delivery system

Multi-cluster operation makes the limits of a simple “one repository plus one controller” model increasingly visible. The conference showed several fleet patterns: hub-and-spoke management, dedicated control planes, virtual clusters, and combinations selected according to isolation and scale requirements.

The more thought-provoking question was not which topology wins, but where deployment intent should live.

In OCI is not Git: Rethinking the GitOps Source of Truth for a Kubernetes-Native World, Michael Crenshaw and Robin Lieb compared Git and OCI artifacts. Git provides human collaboration features such as history, review, blame, and readable diffs. OCI provides immutable, content-addressed artifacts that are easy to distribute, promote, verify, and use in disconnected environments.

For a multi-cluster platform, the useful direction may be a combination: keep human-authored intent and review in Git, then render and sign a versioned artifact in CI. That identical artifact can be promoted through environments. The controller should then reconcile the artifact and expose the real applied state. This can reduce rendering differences between environments while preserving the review process that makes GitOps trustworthy.

The key is not to adopt “Gitless GitOps” as a slogan. It is to make every transition from authored intent to rendered artifact to live state traceable and understandable to operators.

5. AI for operations must present evidence, not confidence

AI appeared throughout the conference, but the most relevant operational message was about trust.

From Tool Calls to Context Fabric: Building AI-Native Observability for Platform Engineering described the difficulty of investigating why a service is failing. Ownership data, metrics, logs, alerts, and runbooks live in different systems. Giving an agent unrestricted access to every system does not automatically produce a reliable investigation.

The proposed approach was to prepare stable context in advance: service relationships, owners, valid metric and log labels, documentation, and access policies. The agent then queries live systems only for the evidence required by a scoped investigation. Each responsibility, including metrics, logs, and operational knowledge, can be exposed through a bounded Model Context Protocol (MCP) service. MCP is an open protocol that connects AI applications to external tools and data sources through a consistent interface.

The operator should receive more than a generated root-cause claim. A useful response should show:

what operational question is being investigated and the scope of the incident;
the metrics, log lines, and sources used as evidence;
what is confirmed and what remains provisional;
who should act next; and
how the decision or remediation can be reversed.

This is a strong design principle for AI-assisted operations. The goal is not maximum autonomy at the beginning. The goal is a bounded and auditable investigation that helps a human make a safer decision. Once a path has been verified repeatedly, it can be reused and carefully expanded.

6. Kubernetes is becoming workload-aware AI infrastructure

The AI infrastructure sessions also showed why traditional CPU- and memory-based assumptions are insufficient for inference workloads.

In From Model Serving to Distributed Inference: How llm-d Evolves AI Platforms on Kubernetes, the architecture combined inference-aware routing, KV-cache awareness, workload-specific metrics, and local model caches. Instead of scaling only on CPU or memory, the platform can consider queue depth, running and waiting requests, and cache utilization. Routing can also prefer an endpoint that already has the relevant prefix in its KV cache, improving time to first token and total throughput.

At a larger physical scale, Beyond the DC Walls: Building a Nationwide GPU Fabric with KubeVirt and Wide-Area L2 explored a Kubernetes cluster spanning data centers from Sapporo to Fukuoka over a wide-area Layer 2 network. The nationwide GPU fabric was a striking example of cloud native control extending beyond a single data center while still needing to account for physical constraints such as latency, power, topology, and heterogeneous GPUs.

The broader lesson is that Kubernetes is evolving from a generic container scheduler into a control plane that understands increasingly specialized workloads. Platform teams will need to expose that specialization through simple interfaces without hiding the operational and cost trade-offs.

7. Security improvements must be verifiable and incremental

I attended three sessions that approached cloud native security from two connected directions: trustworthy software artifacts and secure cluster networking.

SBOMit: Making SBOMs Accurate with Attestations addressed a basic weakness in software bills of materials. Static analysis and package manifests can miss dependencies downloaded dynamically or introduced during a build. SBOMit instead uses build-time attestations to record filesystem access, process execution, and outbound network connections. The resulting SBOM is based on observed build behavior and can be cryptographically verified, making it stronger evidence for software supply chain decisions.

The two Cilium sessions showed both the value and the operational reality of adopting secure networking. A Decade of Cilium Around the World covered how Cilium’s eBPF-powered stack supports networking, load balancing, network policy, and runtime security. The Road to Cilium: Migrating 150+ Kubernetes Clusters at Airbnb then provided a large-scale migration perspective. Its lessons included performance testing, understanding IP address management and workload identity bottlenecks, and choosing incremental rollout boundaries across clusters, nodes, and pods.

Together, these sessions reinforced that a security feature is not complete merely because it exists. Supply chain data must be derived from verifiable evidence, and network security changes must be introduced without destabilizing the workloads they protect. For a service platform, this means treating attestations, network policies, rollout safety, and operational visibility as parts of one security system.

What I want to bring back to our platform work

The sessions covered very different areas, but the same operating model appeared repeatedly:

Start with a real user problem and define the business outcome.
Encode safe defaults and guardrails in the platform.
Make the standard path self-service and document its recovery path.
Preserve evidence and traceability across delivery and operations.
Automate gradually, expanding only after operators can verify the result.

For our service platform, this suggests several practical questions. Can we connect each roadmap item to reduced lead time, risk, toil, or cost? Do our policies cover both static configuration and dynamic runtime conditions? Can service teams resolve common operational issues from documented evidence? Is promotion across clusters reproducible and traceable? If we introduce AI into operations, can an engineer see exactly why it reached its conclusion?

These questions matter more than adopting any individual tool shown at the conference.

Closing thoughts

My strongest impression from KubeCon + CloudNativeCon Japan 2026 was that cloud native engineering is becoming more outcome-oriented. The ecosystem continues to expand into AI, distributed infrastructure, and new delivery models, but the fundamentals remain consistent: understand the customer, design for safe operation, keep the system observable, and make decisions from evidence.

The next stage of platform engineering is not simply running more clusters or adding more automation. It is building a platform that people can trust and demonstrating, with data, that the trust creates value.

The views in this article are the author’s own. Session descriptions and speaker names are based on the official KubeCon + CloudNativeCon Japan 2026 schedule.

References

Individual session links point to Sessionize. If they become unavailable, use the official schedule below or the CNCF YouTube channel.