Cloud Native Telecom Meetup Japan 2026 at NTT DOCOMO Open Lab Odaiba: My Recap

Why I was there

I spent today at the Cloud Native Telecom Meetup Japan 2026, a community event co-located with KubeCon + CloudNativeCon Japan 2026, held at docomo R&D Open Lab Odaiba (12F, 2-3-2 Daiba, Minato-ku, Tokyo). The schedule on the side screen ran from a 13:30 welcome, through two blocks of sessions and a lightning-talk block from 16:30, to closing remarks at 18:00 and a networking reception from 18:30. The closing slides listed the CNCF, LF Networking and the SODA Foundation as supporting organisations, and Nokia, F5 and Huawei as supporting companies.

It was exactly the kind of focused, operator-level gathering I look for: real telecom use cases on Kubernetes, cloud-native network functions (CNFs), platform engineering for telco workloads, and CNCF projects applied to 5G/6G. I arrived for the second session block, so this recap covers the two sessions from 15:00 and the lightning talks that followed.

This one mattered to me for a second reason. I’m collaborating with Dell Technologies in Europe on a common OpenShift AI project, and a lot of what was presented (autonomous Day-0/Day-1/Day-2 operations, agents that reason over Kubernetes, SOP-driven remediation) maps directly onto the questions we’re asking about running AI on telco-grade infrastructure. So this wasn’t tourism; it was field research.

The throughline: from manual Day-0/Day-1 to agentic operations

The first session I saw was a joint NTT DOCOMO and AWS talk. The speaker slide introduced Aya Tsurusaki (Lead Architect of telecom platform, NTT DOCOMO) and Awaiz Khan (Principal Solutions Architect, AWS). It opened with docomo’s own pain, told honestly on stage. The Current Status of Docomo Day-0/Day-1 Operation slide is the kind of number that should make every platform team wince:

• Each platform or application change forces a roughly 10-month, largely manual Day-0/Day-1 cycle.
• With the lifecycle now about one year (containers move faster than the VMs they replaced), repeating that error-prone effort every year is “very difficult.”
• The flowchart itself is a wall of manual steps: automation-tool updates, hardware parameter design, supplier kitting, racking/cabling, platform and VNF parameter design, app onboarding, instantiation, service launch, with red brackets marking where human effort dominates.
• Day-2 is no better: automation tools only cover the repetitive parts; “most of the analysis and work still falls to people.”

The strategic slide, The Industry’s Answer: Desired-State Operations Driven by Agentic AI, frames the escape route. It cites the TM Forum definition of the Autonomous Network: humans stop scripting fixed scenarios and instead define a desired state, and AI maintains the network from Day 0 to Day 2. The open question on the slide is the one every regulated operator is wrestling with: how do you keep the quality that strict manuals used to guarantee once a non-deterministic AI is in the loop?

The architecture: ANO and three agents across the lifecycle

The answer presented has a name: ANO (Autonomous Network Operations), and its centerpiece is three agents across the full lifecycle:

• Day 0, ANPA (Provisioning Agent): bare-metal discovery (Redfish/BMC), OS install via Tinkerbell, register EKS Hybrid Nodes, hardware validation and burn-in. Produces a PhysicalTopology CRD.
• Day 1, ANDA (Deployment Agent): 5G network functions (AMF · SMF · UPF · gNB), 3GPP-compliant dependency ordering, drain-aware zero-downtime upgrades, rollback on SOP-defined thresholds. Produces a ServiceTopology CRD.
• Day 2, ANRA (Remediation Agent): cross-layer alarm correlation, anomaly detection on KPIs, auto-remediation via SOP runbooks, escalation when confidence is low. Produces an ImpactMap CRD.

The pragmatic kicker: it’s delivered as an EKS Community Add-on through the native EKS Add-ons API (console / CLI / IaC), built on the open-source Strands Agents SDK + Amazon Bedrock, and it runs on clusters operators already use for 5G, including EKS Hybrid Nodes on-prem. No new infrastructure required. Several of these slides carried a “Cloud Native Telco Day • KubeCon + CloudNativeCon Japan 2026 • PACIFICO Yokohama” footer, so the same material is aimed at the main conference too.

Why CRDs, not a message broker

This is the part I’d put in front of any platform team building multi-agent systems. The Multi-Agent Coordination: CRDs as Inter-Agent Contract slide made the case that coordination happens over minutes, not milliseconds, so you don’t need Kafka/NATS/SQS between agents. Using Kubernetes CRDs as the inter-agent contract gets you:

• Crash recovery: CRs persist in etcd, the pod just resumes
• Audit / compliance: kubectl get is regulatory proof
• Schema validation: admission control at write time
• Access control: RBAC per agent, per resource
• Observability: etcd watches feed existing dashboards
• Replay / debug: kubectl apply -f re-triggers

What they explicitly didn’t build: a message broker, a service mesh for agent discovery, custom auth/mTLS, a separate observability stack, a persistence layer. What they used instead: etcd, the K8s API server, RBAC, CRD schema validation, and kubectl, all already running. The slide’s bottom line: $0 new infrastructure.

SOP-grounded agents: the LLM reasons, it doesn’t execute

The most important architectural principle of the day, and the one I’ll carry into the Dell/OpenShift AI work: the LLM is the reasoning engine, not the executor.

The Problem with Raw LLMs in Production Networks slide is a clean two-column contrast:

• Raw LLM (freeform reasoning): non-deterministic (unacceptable for live traffic), can invent CLI commands and config values, generates procedures that don’t exist, not auditable, no reproducibility guarantees.
• SOP-grounded agent: every action traced to an approved SOP, SOPs are version-controlled markdown runbooks, the LLM selects the step but execution is deterministic, fully auditable for telco compliance, and ISV-agnostic (the knowledge lives in the SOP).

How SOP-Grounded Agents Work (Observe → Reason → Execute, deterministically) breaks it down:

• SOP = shippable deliverable: vendor runbooks become markdown SOPs, GitOps-managed with the workflows you already use, agent code stays ISV-agnostic, reviewed and approved once then deployed everywhere. “SOPs are the CNF-specific knowledge layer.”
• Dynamic SOP enrichment (closed loop): embed real network topology (CRDs) into context, closed-loop evals validate correctness, corrections feed back so SOPs improve over time.

The live demo: ANRA remediating a 5G Core alarm

Then came the Live Demo: ANRA Remediating a 5G Core Alarm. The scenario: SMF pod OOM-killed → AMF detects session loss → alarm fires → ANRA auto-remediates. The remediation pipeline runs six stages:

1. COLLECT: 6 sources, 30s
2. DETECT: 14 rules + 3σ
3. CORRELATE: NetworkX, 4 layers
4. RESOLVE: 19 SOPs + generate
5. ENRICH: Bedrock + environment context
6. EXECUTE: Strands agent

The ANRA live demo slide: the six-stage remediation pipeline and what to watch for on the dashboard.

On the dashboard we watched the “watch for” cues play out: the KPI cards turned red when the alarm fired, correlation suppressed related alarms, the agent selected an SOP from 19 candidates, Bedrock enriched it with cluster topology, and the Strands agent executed the steps. Under the hood: the agent reads the ImpactMap CRD for topology context, does cross-layer correlation (infra → NF → service), renders SOP markdown into deterministic steps, and each step is a kubectl, helm, or API call. The live activity feed streamed every reasoning step. Active alarms 0, SOPs executed 1, success rate 100%: a clean demo run.

Built-in trust: graduated autonomy via Strands evals

Trust was the closing theme, and it’s the right one. Built-In Trust: Graduated Autonomy via Strands Evals lays out an evaluation framework that gates autonomy:

• Tool Usage: right SOP, right parameters?
• Grounding: faithful to the SOP, not hallucinated?
• Goal Success: did the Day 0/1/2 task complete?
• Resilience: behavior under injected failures
• Deterministic: code-based assertions for CI/CD
• Simulators: multi-turn scenarios pre-production

Mapped against TM Forum Autonomy Levels: L1 Assisted (does most work) → L2 Partial (approves each step) → L3 Conditional (exceptions only) → L4 High (oversight only) → L5 Full (autonomous). The target on screen: L3→L4 in 2026 for known failure patterns. And the rule that makes it credible: built on the open-source Strands Agents SDK, results stream to Amazon CloudWatch + Bedrock, AgentCore observability, and deterministic evals gate CI/CD: a failing eval blocks promotion, just like a failing test.

Zero downtime at scale: docomo’s 2026 vRAN upgrade

The second session was the most concrete Kubernetes operations talk of the day: “Zero-Downtime at Scale: Lessons from NTT DOCOMO’s 2026 vRAN Infrastructure Upgrade” by Kosuke Taniguchi (Assistant Manager, Telecom Platform Orchestration Team) and Hiroaki Suenaga (Telecom Platform Team), both NTT DOCOMO. It covered docomo’s first commercial container-platform upgrade on the RAN.

Kosuke Taniguchi and Hiroaki Suenaga opening the vRAN upgrade talk.

The virtualization timeline on the introduction slide puts it in context: a VM platform commercially launched on the core network in 2015, large-scale core upgrades in 2019 and 2022–2023, a container platform launched on the RAN in 2025, and in 2026 the first commercial container-platform upgrade on the RAN, Kubernetes 1.29 → 1.33.

The design slide explained the shape of the estate:

• ZeTA (Zero Touch Automation) runs in a public cloud region and centrally manages on-premises servers and clusters.
• Regional data centres, one per prefecture (approximately 50 DCs, around 200 nodes each), host the management cluster and the vCU clusters, with each prefecture’s cluster lifecycle managed by Cluster API (CAPI).
• Edge data centres (over 1,000 nationwide, 1–3 nodes each) run vDU workers, up to 495 nodes per vDU cluster.
• vCU and vDU are deployed in a C-RAN design, and the whole thing scales to 10,000+ servers.

“Upgrading at production scale”: roughly 350 clusters across three cluster types, realistically 10,000+ nodes.

Challenge 1: keeping up with the Kubernetes release cadence

The VM platform had long-term support and major upgrades every few years. Kubernetes ships a minor release roughly every four months with a short support window, and telecom must always run a supported version. Running a full end-to-end integration test with the applications every four months would be prohibitive. docomo’s answer:

• Multi-version upgrades. Validate and upgrade several versions at once: four versions the first time, then one per cycle. The products docomo uses have a support lifecycle of more than two years, which leaves roughly one year each for development and operation.
• Trim the intermediate versions. They only run in production briefly, so features are scoped down and test cases trimmed (about 50% fewer). Fewer platform release points cut application integration testing to twice a year.
• The production constraint: 300+ clusters and 10,000+ servers, add-ons included, had to be upgraded in a short window, with only two to three months of support left at the start. Staffing operators per prefecture would have been too expensive.
• ZeTA and CCDs. Kubernetes and add-on versions are defined in CIS Cluster Descriptors (CCDs). ZeTA holds the server and cluster inventory and drives zero-touch provisioning and lifecycle operations, so clusters can be upgraded in parallel. Operators pick the target CCD version and set maxUnavailable and maxSurge.

The result: 3 cluster types × 4 Kubernetes versions = 12 upgrade steps, each run through ZeTA, completed within 9 days per prefecture.

Challenge 2: zero downtime during the upgrade

The platform has to be upgraded without interrupting call processing, across the full gNB: vCU C-plane, vCU U-plane and vDU. Those are three application types with three different service-continuity designs.

• vCU, “the Kubernetes way”: a PodDisruptionBudget with minAvailable set to the number of pods needed to keep service up, plus node labels and node-affinity constraints so vCU U-plane units sit in different node groups and can’t all go down at once.
• vDU, “the Telco Legacy Way”: each vDU runs on a single dedicated node, so the platform can’t provide continuity by itself. docomo uses an “Overlay Method”: neighbouring physical cells on different radio spectrum cover the vDU’s area during the upgrade.
• Toward a Kubernetes-native vDU upgrade: the overlay isn’t a permanent answer as vRAN density grows. The next milestone is automating service recovery after a graceful reboot of the underlying node: first backward compatibility across multiple Kubernetes and kernel versions, then a Kubernetes operator that manages the order of multi-layer initialisation.

The hidden risk: Cluster API forced rollouts

The slide I photographed more than once. Once the MachineTemplate schema changes, a later modification of the cluster manifest triggers a reconciliation that rolls out every managed node, rebooting them in sequence. For vDU, which has no Kubernetes-native redundancy, that means a major service disruption.

“Hidden Risk: Forced-rollout by Cluster API”: a schema change in the MachineTemplate turns the next manifest edit into a rolling reboot of every node.

The mitigation was to shrink the risk window: bundle the Cluster API component upgrade into the first management-cluster step, then upgrade the vCU and vDU clusters right after it, with all vDU clusters in parallel. The slide’s honest footnote: “Luckily, we ultimately did not experience any unexpected forced rollout in commercial.” Their requests to the Cluster API community were to allow selective rollout exclusion for chosen nodes, and to stop manual operations such as node scale-out/scale-in from triggering a full template re-evaluation.

The key takeaway slide summed it up: nationwide vRAN can run efficiently on multi-cluster Kubernetes, but simultaneous multi-version upgrades, operability and reliability need deliberate design, and “Cluster API is powerful, but forced rollout needs guardrails.” Preventing vDU-cluster-level impact from forced rollouts remains future work.

My take: this is the most useful Cluster API field report I’ve seen this year. Anyone running CAPI against non-redundant edge nodes should check exactly which template changes their provider treats as “replace every machine” before the upgrade window, not during it.

KDDI: secondary networks and Kubernetes on OpenStack

The lightning-talk block opened with Yusho Yamaguchi of KDDI, who works on KDDI’s private cloud MShip3 and is a developer of Cilium and of the reference CNI plugins maintained by the CNI community. According to his introduction slide, MShip3 is an OpenStack-based private cloud for NFV that hosts many Kubernetes (OpenShift) clusters for CNF workloads, plus VM-based network functions: 6 regions, 4,000+ hypervisors and 20,000+ VMs.

His argument in three steps:

• Standard Kubernetes networking falls short for CNFs. Only one interface per Pod, poor fit with static Pod IPs, and incoming traffic has to go through a Service. CNFs often want multiple interfaces, separate planes per traffic purpose (with overlapping IPs), direct communication outside the cluster with the Pod’s own static IP, or direct access to the worker NIC for performance. One cause, per the slide: NF vendors carrying bare-metal-era NF configuration straight into CNF Pods.
• Secondary networks work around that, at a cost. Multus calls CNI plugins multiple times to attach extra interfaces (mainly ipvlan/macvlan, with the Pod sharing the worker’s L2 domain). But “K8s is not involved” in the secondary network: you manage IP addresses yourself, and Services and NetworkPolicy don’t apply. On bare metal, every plane needs a VLAN on both the data-centre network side and the worker side, which doesn’t scale operationally.
• Kubernetes on OpenStack fills the gap. The Pods’ secondary interfaces connect to OpenStack virtual L2 networks between worker VMs, created on demand by OpenStack. The missing Kubernetes features come from the OpenStack layer: NetworkPolicy from Security Groups, and Service load balancing from LBaaS.

“Advantages of K8s on OpenStack for secondary network”: Security Groups and LBaaS stand in for NetworkPolicy and Service load balancers.

KDDI: “Building the Bridge”

The second KDDI talk, “Building the Bridge: Connecting Cloud-Native Agility with Telecom Reliability” by Akihiro Kagimoto (Mobile Core Platform, KDDI Corporation), was about people and process rather than packets. His profile slide listed the mission of promoting virtualization of mobile core networks.

“IT, designed for change” vs “Telecom, demanding unwavering stability”.

The slides walked through the gaps:

• IT vs telecom. “Move fast and break things” against “Must Never, Ever Be Broken”. Even with Kubernetes abstraction, telco CNFs still carry telecom-specific performance and reliability requirements tightly coupled to hardware (the takeaways slide cited CPU pinning).
• “Legacy in a Container’s Clothing.” CNFs are global, general-purpose products, and “We Are Just ‘One User’”: vendors won’t change their architecture for one operator’s platform. “We can’t just wait for vendors to ‘become perfectly cloud-native someday.’”
• The responsibility gap. Moving from vertically integrated development to horizontally specialised layers (app, container, virtualization, hardware, each with its own vendor or in-house team) creates “an area that is everyone’s job, yet no one’s job.” That leads to a serious bottleneck: dependence on a handful of “super engineers”.
• Four practical approaches: establish a grand design (system-wide architectural rules and standardisation), implement canary deployments of platform updates on small environments first, form a cross-functional issue-resolution team for the responsibility gap, and run workshops so application teams understand the platform’s mechanisms and constraints.
• Future outlook: AI-assisted end-to-end decision-making that consolidates siloed data and knowledge across layers, with the takeaways slide pointing to “a new operational model with automated execution powered by AI-GitOps.”

My take: the “super engineers” bottleneck is the same thing I see in enterprise platform teams. Canary platform rollouts and shared architectural rules are cheap compared with the cost of that dependency.

Kubernetes DRA and DRANET for networking

Yohei Motomura (Senior Consultant, Red Hat K.K.) presented “Exploring Kubernetes DRA from Core Concepts to Networking Use Cases with the DRANET Implementation”, structured as past, present and future.

Yohei Motomura of Red Hat opening the DRA and DRANET talk.

• Past: device plugins. The scheduler only considers CPU and memory from Node.status. Device plugins expose GPUs and other hardware as extended resources (for example nvidia.com/gpu), but they can’t express requirements: no “GPU with at least 40 GB of memory”, no NUMA locality, no NIC affinity, no advance reservation, no flexible slicing such as MIG.
• Dynamic Resource Allocation (DRA) “manages resources, not devices”. Drivers publish what’s available in ResourceSlices, Pods state what they need in ResourceClaims, DeviceClasses carry the selection rules, and the scheduler matches them. The history slide ran from the 2020 “classic DRA” design and KEP-3063 through structured parameters (KEP-4381, v1.30) and the new API (v1.31) to GA in v1.34. That matches the Kubernetes project: the v1.34 release blog announced core DRA as GA with the resource.k8s.io/v1 API, and the DRA documentation now lists it as stable.
• Present: DRANET. The slides described DRANET as a reference implementation of a DRA driver for network resources. It has two halves: a DRA driver that talks to the kubelet (publish ResourceSlices, select resources for ResourceClaims) and an NRI plugin that talks to the container runtime (add or remove NICs in the Pod’s network namespace, clean up after the Pod ends). The use-case table mapped requirements to benefits: RDMA-capable NICs for low-latency fronthaul/backhaul, SmartNICs/DPUs to offload packet processing, guaranteed bandwidth and queues, NUMA-aware placement for CPU–NIC communication in vRAN/CNFs, PCIe topology awareness for NICs close to GPUs, and advance reservation for maintenance.
• Future: the Pod Networking API. According to the slides, the Kubernetes multi-network work is standardising a Pod Networking API (multiple networks, network resource management, network-aware Services and NetworkPolicies), with DRA considered as its resource-management foundation. “DRANET is not the end goal – it is a first step.” The conceptual API example moved from a Multus-style k8s.v1.cni.cncf.io/networks annotation, to resourceClaims today, to per-interface resourceClaim and network fields.

The talk closed by pointing to a KubeCon Japan panel on 30 July, “Breaking the Single-Network Barrier: A Cross-Domain Look at Kubernetes Multi-Networking”.

My take: this is the cleanest link I saw all day between the vRAN and AI-infrastructure worlds. The same requirement, “give this Pod the NIC that sits next to its accelerator”, shows up in both.

LF Networking: from consumption to global leadership

Next came Arpit Joshipura (GM/SVP, Networking, Edge/IOT, The Linux Foundation), who appeared on screen by video with “From Consumption to Global Leadership – Open Source Networking”. His slides covered:

• The market. “AI, 5G and Cloud-Native Networks Are Driving the Next Decade of Growth”, with a $153.8B mobile infrastructure market by 2033 (the slide credited Market Research and News) and ~70% of the top mobile infrastructure companies participating in the Linux Foundation and open source networking. Japan’s line on the global-momentum list was “Open RAN and 5G Advanced”.
• AI agents in telecom. Citing a TeckNexus leaderboard: 0% of operators have fully removed humans from the loop, 54% require humans to execute every AI-recommended action, and 42% allow autonomous routine tasks with human oversight.
• LFN as a collaboration hub for open source networking, edge and access, with a map of projects such as ONAP, Nephio, Anuket, OpenDaylight, L3AF, Essedum and the Cloud Native Telecom Initiative, alongside a “2026: Evolving AI Framework” slide that maps Linux Foundation communities (the Agentic AI Foundation, PyTorch, LF AI & Data, the CNCF and LF Networking) onto layers from hardware and software infrastructure up to intelligence, agentic AI and end-user applications.
• OCUDU, an open source CU and DU, with an ecosystem foundation launched at MWC 2026. The slide claimed 2× growth in Q2 and listed SoftBank Corp. among the founding members shaping it.
• Project Akrites: “coordinated, confidential vulnerability remediation for the open source software critical infrastructure depends on”, at the pace AI-assisted attackers now operate.

OCUDU: oversight, requirements and contributors around the open source CU/DU project.

I checked the claims against the official sources. LF Networking was founded in January 2018, and its projects page lists ONAP, Nephio, Anuket, OpenDaylight, L3AF, Essedum and CNTI, among others. The Linux Foundation announced the OCUDU Ecosystem Foundation on 1 March 2026 at MWC Barcelona, with AMD, AT&T, DeepSig, Ericsson, Nokia, NVIDIA, SoftBank Corp., SRS and Verizon as premier founding members. It also launched Akrites as a shared security incident response team for critical open source software.

Yoshiya ETO then took the lectern for “Introducing LF networking events & Recent spotlight projects”. OCUDU was described as US-government funded, with two requests for prototype proposals from the NSC and FutureG. Akrites is forming an open source software security incident response team, where project maintainers see only the Akrites team in vulnerability reports. NeoNephos’s slogan was “We make cloud native sovereign”. The CFP for ONE Summit Japan (10–11 December 2026, Tokyo; theme “A New Global Era: Agentic AI, Edge AI & Open Networking”) was open until 24 August.

Metering AI inference, from PDU to pod

The last talk was “Metering AI Inference – From PDU to Pod: Per-workload energy accounting on Kubernetes” by Steven Tan (President R&D, XFusion Singapore Open Lab), presented as AITRA, a SODA Foundation project.

Steven Tan opening the AITRA talk on per-workload energy accounting.

The problem statement was sharp: AI is now production infrastructure across telecom operators (enterprise AI services, MEC, network operations copilots, OSS/BSS automation, RAN intelligence), and operators are asking infrastructure questions such as “another tenant?” or “more GPUs?” that “need measurements to answer”. The power side (PDU/BMS per rack, Redfish/IPMI per node, NVML/DCGM per GPU, RAPL per CPU) and the Kubernetes side (Pods by namespace and workload, GPU utilisation, latency per request, tokens per model) have no link between them.

Aitra Meter is the first step, and the slides said it started from an AI energy benchmarking study with Tsinghua University:

• It joins GPU energy with inference workload metrics to get per-workload energy, and the first metric is J/token. Other workloads would count images, frames or seconds: “same join, different denominator”.
• One Helm install, no application changes. A per-node measurement agent reads energy from NVML and DCGM and tokens from vLLM (or any server with a Prometheus endpoint), and attributes them by model, workload, namespace and tenant. Idle windows are excluded, and every record carries the attribution method.
• Output goes to Prometheus, Grafana, OpenTelemetry and OpenCost. The ecosystem slide also listed AMD SMI and SGLang as inputs.
• From the lab, eight models measured in the same cluster, in the same window, under load: “The same 27B model at fp8 measured 14% cheaper per token than at bf16. Efficiency has to be measured, not assumed.”

“Aitra Meter is a starting point, not a finished product”: the call to define the methodology, build the software and validate it in production.

The longer-term vision is “AI Infrastructure Intelligence” (measure, understand, compare, optimise), built on an open methodology and community, with energy as the first dimension and GPU, memory, network and storage to follow. The code is in the aitra-ai GitHub organisation, and the closing slide promised a demo on 8× H100 at KubeCon Japan.

My take: J/token per namespace and tenant is the number FinOps teams keep asking me for on shared GPU clusters. Measuring fp8 against bf16 on the same model is precisely the kind of evidence that settles arguments.

What this means for my OpenShift AI work with Dell

Walking out of Odaiba, four things are going straight into how I think about our common OpenShift AI project:

1. Treat runbooks as the deliverable, not the agent. Vendor- and ISV-specific knowledge should live in version-controlled markdown SOPs; the agent stays generic. That’s what makes it auditable and portable across clusters.
2. Let Kubernetes be the coordination layer. If your agents coordinate over minutes, CRDs + etcd + RBAC already give you persistence, audit, and access control for free. Don’t stand up a broker you have to operate.
3. Earn autonomy with evals, not promises. Graduated, eval-gated autonomy (L3→L4) is how you get a regulated environment to trust an agent near live traffic.
4. Plan upgrades as a product. docomo’s multi-version upgrades, CAPI guardrails and per-workload energy metering all point the same way: lifecycle and cost have to be designed in from day one, not bolted on.

Sessions to watch when recordings drop

The meetup was a co-located event ahead of KubeCon + CloudNativeCon Japan 2026 (Yokohama, July 28–30). The main conference recordings will land on the CNCF YouTube channel; if the ANO and Strands-based AIOps material from the Cloud Native Telco Day appears there, along with the multi-networking panel, they’re worth your time.

If you were at Odaiba today, or you’re working on agentic AIOps for telco or any regulated workload, reach out. I’d especially like to compare notes with anyone running SOP-grounded agents on OpenShift or EKS Hybrid Nodes.

Luca Berton is The Production AI Expert, a Docker Captain, and a CNCF/KubeCon media partner. He is collaborating with Dell Technologies on a common OpenShift AI project spanning Europe.

Related Articles

• KubeCon + CloudNativeCon Japan 2026: Media-Partner Preview
• Tuning Kubernetes for AI: the Real Trade-offs from KubeCon Japan 2026
• Cilium & eBPF: Next-Gen Kubernetes Networking
• Infrastructure as Code & GitOps for Network Automation 2026
• Zero Trust for Kubernetes Workloads