# How Subaru Accelerated AI Model Development for EyeSight > [!question] Lingering Questions > - Four changes are bundled into one 60× number (in-cluster Harbor, host-network Envoy, node co-location, MetalLB) — which one actually did the work? As reported, nobody can act on this precisely. > - Harbor and Envoy co-located on one node is a single point of failure for the cluster's whole image supply, and it's unmentioned in the talk. > - Why are the ML images 30GB in the first place? Layer optimization as a cheaper first attempt is never discussed. > [!tip] Article Ideas > - Registry placement relative to workloads is a five-second diagnostic worth running on any cluster before optimizing anything else — worth a short practical checklist piece. > [!link] Cross Reference > - [[3. Resources/Literature Notes/Out of the Box, at Multi-Region Scale — How Hyundai Scales Its Platform]] — the same "remove the slow path rather than optimize it" principle at a different scale (single-cluster in-cluster registry here vs. Hyundai's cross-region replication) — two independent KubeCon Japan data points. > [!quote] Vocabulary > - **Host-network Envoy** — running the Envoy proxy in the host's network namespace rather than a pod-isolated one, used here to speed traffic to the co-located in-cluster registry. ## Bibliographic capsule A KubeCon Japan 2026 case study on how Subaru removed three bottlenecks from in-house AI model development for the next-generation EyeSight driver-assistance system: 30GB container images taking three hours to pull, hand-executed deployments, and unmanaged ML workflow dependencies. This supports a stated goal of zero fatal traffic accidents by 2030. ## Author's thesis Moving the container registry in-cluster (rather than optimizing the network path to an external one) cut image pull time from about three hours to about three minutes — a reported 60× reduction — alongside replacing manual Helm deployments with GitOps (Helmfile plus Argo CD, 25 application definitions) and making ML pipeline dependencies explicit via Argo Workflows. ## Key arguments (≤3) 1. **In-cluster registry cut image pull from hours to minutes** — the one hard, measured number in the talk, but four changes (in-cluster Harbor, host-network Envoy, node co-location, MetalLB) were made together, so the attribution is bundled rather than isolated. 2. **No costs are discussed anywhere** — in-cluster Harbor moves storage, availability, and backup responsibility onto the platform team, and single-node co-location is a stated-but-unnamed dependency. 3. **The safety-critical framing (zero fatal accidents by 2030) raises the stakes of the unstated single point of failure** without the talk connecting the two. ## Claim atoms ### In-cluster registry cut image pull from hours to minutes > [!quote] ID:rw_01kysr5a4qkw28qs6c6nghn178 > image pull time was reduced to about 3 minutes. Following the description of moving Harbor in-cluster with host-network Envoy, node co-location, and MetalLB. The one hard number in the talk, from roughly three hours on 30GB+ ML images — note four changes were made together, so attribution is bundled. ## Permanent candidates - **Artifact distance dominates transfer time at large sizes** — once an artifact is large enough, where it's stored relative to where it's consumed matters more than any transfer optimization. → promoted. ## Processing checklist - [ ] Check registry placement relative to workloads on any cluster reviewed going forward — the diagnostic is five seconds - [x] Connect into the relevant MOC ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — a GitOps/Kubernetes platform-engineering case study using CNCF-ecosystem tooling (Harbor, Argo CD, Argo Workflows) - [[3. Resources/Readwise/Full Document Contents/Articles/How Subaru Accelerated AI Model Development for Next-Generation EyeSight...- Ryoji Kobayashi, Subaru]]