KubeCon Japan 2026: the CNCF Briefing and Lightning Talks

Around midday on 29 July 2026, after the morning keynotes I covered in KubeCon Japan 2026 Keynotes: AI Platforms at Scale, I moved from the Main Hall to a much smaller room. The backdrop read “KubeCon + CloudNativeCon Japan 2026 Press Conference, July 29, 2026, Yokohama, Japan”. I was attending KubeCon Japan as a media partner, so this was one of the sessions I came for. It was a press conference, and I was in the audience.

Several people presented. My photos don’t show who presented every slide, so below I describe what was on the slides and only name a presenter where a slide does. In the afternoon I also went to the lightning talks, which close this post.

”Cloud Native & AI: CNCF Perspective on Japan”

The CNCF section opened with a title slide: “Cloud Native & AI: CNCF Perspective on Japan”, Jonathan Bryce, Executive Director, CNCF.

The title slide of the CNCF section of the briefing.

The first slide after it was “Japan’s Cloud Native Footprint, By the Numbers”, based on the CNCF report State of Cloud Native Development in Japan:

• 950K cloud native developers in Japan (Q1 2026).
• 41% of Japanese developers are cloud native, against a 39% global average.
• 24% → 41%: the cloud native share of Japan’s developers from Q1 2024 to Q1 2026.
• ~100K of Japan’s cloud native developers work on AI.

The CNCF and SlashData published the report the same day. Their announcement gives the same figures, and the full report is free to download.

Japan’s footprint by the numbers, and why AI is now driving Kubernetes adoption.

The next slide was “AI Is Now the Reason to Adopt Kubernetes”. Globally, it said, 82% of container users run Kubernetes in production, 66% of organisations use Kubernetes to host generative AI workloads, and Kubeflow has grown into a top-30 CNCF project. In Japan, 57% of organisations surveyed have adopted Kubernetes or container orchestration, against 72% globally. The slide called Japan “ahead of the curve” on PyTorch (69%) and AI foundation models (66%), and named the gap: “Japan’s AI ambition is outrunning its infrastructure”.

”Japan Is Not Behind on AI — It’s Waiting”

The slide I found most useful came earlier in the briefing, before the CNCF title slide: “Japan Is Not Behind on AI — It’s Waiting”. It was presented by a different speaker.

“The barrier is activation, not belief.”

It split the picture in two:

• What looks like a lag: Kubernetes and container orchestration adoption at 57% against 72% globally. Enterprise AI activity gains trail the rest of the world by about 16 points.
• What it actually is: AI is already a net-positive hiring driver in Japan, with +54% expected in 2026 against +26% globally. 100% of Japanese organisations plan to use AI, against 96% in the rest of the world. “Hiring is up 54%, but supply is constrained — training is the throttle.” The barrier is activation, not belief.

The footer gave the pattern: “Strong intent and hiring momentum, but execution is still catching up”. The sources listed were the CNCF Japan report and Linux Foundation Research’s 2026 State of Tech Talent Japan.

Two more slides followed. “The Sovereign AI Imperative” said that U.S. hyperscalers provide 70–80% of the cloud infrastructure capacity used in Japan today. It said leaders want to host defence, financial, police and personal data domestically, and that Japan is still defining “sovereign cloud”, trailing Europe. Its principle: sovereignty requires infrastructure that is open source, vendor-neutral and interoperable, and “sovereignty requires sovereign skills”. “Physical AI: Japan’s Distinct Path” contrasted U.S. AI investment, which is concentrated in software, cloud services and consumer or enterprise AI, with Japan’s focus on physical systems. Its examples were automotive (Toyota, Honda), consumer electronics (Sony, Panasonic) and infrastructure (Hitachi, trains and power plants).

Sovereignty needs open infrastructure and local skills. Japan’s AI edge is in physical systems.

My take: “Japan is behind on AI” is a common assumption outside Japan. These slides argue that the gap is in execution, not in intent, and I agree with that diagnosis. The consequence for platform teams is practical. If training is the bottleneck, a platform that hides GPU scheduling, tenancy and conformance behind a paved road matters more than any single model choice.

A framework, and Kubernetes AI Conformance as the concrete model

A three-step “Framework for AI Activation” (infrastructure foundation, talent as a strategy, sovereignty and scale) led to “A Concrete Model: Kubernetes AI Conformance”. According to the slide, the programme:

• defines what a Kubernetes platform needs to run AI workloads reliably: training, inference and agentic workloads;
• aims for “an AI application that works on one conformant platform works on others, with fewer ‘it works on my cluster’ surprises”;
• builds on base Kubernetes conformance, adding AI-specific requirements across accelerators, networking, scheduling, observability, security and operator support.

On sovereignty, the slide called it “a vendor-neutral, community-led standard, not owned or controlled by any single hyperscaler”, with certification that is “public and reviewable” through a self-assessment and evidence submitted as a GitHub pull request. The programme is in the cncf/k8s-ai-conformance repository.

Kubernetes AI Conformance, presented as the concrete model for sovereign AI infrastructure.

Project news: graduations, incubations and sandboxes

The project slides were the most concrete part of the briefing.

“CNCF Graduation Milestones: Buildpacks & Kubeflow.” Cloud Native Buildpacks turns application source code into OCI container images without Dockerfiles. Kubeflow “provides the foundation for AI platforms on Kubernetes”, unifying training, tuning, pipelines and model serving. CNCF later announced both graduations formally: Cloud Native Buildpacks on 11 August and Kubeflow on 17 August.

Two graduations, and two smaller projects aimed at AI costs and agent safety.

“Open Source Projects Solving Real AI Problems” highlighted two smaller projects. KubeElasti scales AI inference pods to zero when idle “without waking them for routine health checks”, which cuts GPU costs. Lima offers lightweight local VMs, “now with AI sandboxing for safely running AI agents”.

“HAMi & Confidential Containers Join CNCF Incubation.”

• HAMi is open source, cloud native GPU virtualisation middleware for Kubernetes that “slices physical accelerators with hard runtime isolation”. The slide listed 550+ contributing organisations and 2,687 contributors (up 43% year on year). It integrates with Volcano and Koordinator, and recent work includes gang scheduling, DRA monitoring and expanded AMD/PPU device support.
• Confidential Containers protects data in use with hardware-based Trusted Execution Environments. The slide listed Azure, Intel, AMD, IBM and Red Hat as supporters, 1,000+ GitHub stars and 150+ active contributors. Its main components are CoCo pods (unmodified TEE containers), Trustee attestation services, operator lifecycle automation and multi-vendor hardware abstraction.

HAMi for GPU sharing, Confidential Containers for data in use.

The slide cited the CNCF blog posts as its sources: HAMi becomes a CNCF incubating project (15 July 2026) and Confidential Containers becomes a CNCF incubating project (22 July 2026).

“Sandbox Projects Revolutionizing the AI Stack” covered two sandbox projects. CoHDI enables Composable Disaggregated Infrastructure for Kubernetes nodes by attaching and detaching GPUs and PCIe devices through DRA without OS reboots. The slide called this crucial for LLM prefill (compute-bound) and decode (memory-bound) phases, which need different resources. llm-d delivers Kubernetes-native distributed inference with disaggregated (xPyD) serving, tiered prefix caching and multi-accelerator support.

CNCF and the IOWN Global Forum

The last project slide was news announced that day: “CNCF Deepens Ties With the IOWN Global Forum”. It listed three points: an expanded partnership between CNCF and the IOWN Global Forum, announced at KubeCon + CloudNativeCon Japan 2026; CoHDI integrating into IOWN’s All-Photonics Network (APN) to share disaggregated hardware across optical networks; and “Scale-Across” AI, helping AI data centres get past the physical limits of a single site.

CoHDI and llm-d in the sandbox, and CoHDI heading onto IOWN’s All-Photonics Network.

The IOWN Global Forum’s own press release, “IOWN Global Forum Expands Partnership with Cloud Native Computing Foundation”, is dated 29 July 2026 in Yokohama. It describes an amended memorandum of understanding and quotes CNCF CTO Chris Aniszczyk. CNCF links to coverage of it from its newsroom. If you want the hardware side of this, I wrote about photonic networks on the show floor in Photonic Networks: the Standout Tech at KubeCon Japan 2026.

My take: composable disaggregated infrastructure came up three times on day 1: in the Fujitsu keynote abstract, as the CoHDI sandbox project, and in the IOWN partnership. Composable GPUs are still a niche idea. When a sandbox project is already part of a cross-industry partnership with a photonics forum, though, it’s worth watching.

Community momentum

The briefing closed with “Community Momentum in Japan”. CNCF, Linux Foundation Education and Udemy have partnered on one training path covering CKA, CKAD, CKS and CNPE. Under Kubestronaut growth, the slide showed “+170% YoY growth” and “Reached 170 total Kubestronauts”. It said Japan holds 20.8% of APAC’s Golden Kubestronauts, with an 18.2% conversion rate against a 10.4% APAC average. Female representation was 15.3% against a 7.6% Asia-wide average. It also recognised Subaru as winner of the CNCF End User Case Study Contest: image pulls for 30 GB+ ML/CUDA images went from about three hours to about three minutes.

Training, Kubestronauts and the Subaru case study.

More on Subaru in Cloud Native in the Real World. For comparison with the year before, see my write-up of the KubeCon Japan 2025 press conference coverage.

Lightning talk: understanding Kubernetes from logs

In the afternoon I went up to Room 313+314 for the lightning talks block (14:50 to 15:16, emcee Hoon Jo according to the room sign). Just before the block started I also looked in on the hands-on tutorial in Room 315, “Your First Kubernetes Contribution: A Hands-on Guide to Documentation Localization”. The screen showed the “K8s Docs l10n Hands-on Lab”: copy the English file to the same path in your language folder, then translate the prose and leave code blocks, shortcodes and front matter alone.

The documentation localisation lab: a practical first contribution.

Back in 313+314, the talk I’ll remember was by Kakeru Ishii, Senior Technical Solutions Engineer, Google Cloud, as his intro slide described him. He is the author of the Kubernetes History Inspector log visualiser. On the schedule it was “Learning Kubernetes From Logs: Building a Foundation for Future Troubleshooting”. His slides were titled “Understanding K8s from logs”.

The premise: everyone learns that a Deployment creates ReplicaSets, a ReplicaSet creates Pods, and a Pod creates and starts containers. “But do you truely understand them from Logs?” The talk then followed one demo Deployment through four phases, showing a log at each step:

1. Resource creation: kube-apiserver audit logs record “when”, “who”, “what request” was sent and “what the outcome” was. They are useful for finding the historical state of resources.
2. Reconciling resources: kube-controller-manager logs show the deployment controller adding the Deployment, creating a ReplicaSet (“Too few replicas … creating 1”) and the ReplicaSet creating the Pod.
3. Scheduling: the kube-scheduler log line “Successfully bound pod to node”.
4. Procedures on nodes: the kubelet mounts volumes via CSI, creates the PodSandbox via CRI, sets up the network via CNI, and creates and starts containers via CRI.

The question the talk set out to answer, and phase 1: the audit log.

The most practical slide was “Accessing Non-Container Logs”. It showed how to read logs from components that don’t run as containers, using only kubectl:

# 1. API server audit log on a control plane node
kubectl get --raw "/api/v1/nodes/<cp node name>/proxy/logs/apiserver/audit.log"
# 2. Direct access to syslog
kubectl get --raw "/api/v1/nodes/<node name>/proxy/logs/syslog"
# 3. Kubelet logs (like journalctl -u kubelet.service)
kubectl get --raw "/api/v1/nodes/<node name>/proxy/logs/?query=kubelet"

The slide noted that the kubelet query needs NodeLogQuery enabled in the kubelet config (KEP-2258), and that log paths vary with node configuration.

Reading node logs through the API server, and phase 2 in the controller-manager log.

Phase 4: what the kubelet does once a Pod lands on a node.

My take: five minutes, and the most reusable content of my afternoon. The node log proxy via kubectl get --raw is the kind of thing you’d want during an incident, when SSH to a node is locked down. I’d make the four-phase walk part of any platform team’s onboarding.

Related

• KubeCon Japan 2026 Keynotes: AI Platforms at Scale
• Photonic Networks: the Standout Tech at KubeCon Japan 2026
• Open Source Building Blocks for AI Platforms (KubeCon Japan 2026)
• Security, Isolation & Sovereign AI on Kubernetes (KubeCon Japan 2026)
• KubeCon Japan 2025 Shows Japan’s Cloud Native Moment