Does Kubernetes Work in China? Data Residency, ICP & Cross-Border Rules
Kubernetes is open-source and self-hosted, so residency is a choice: the cluster holds your workloads, its Secrets (passwords, tokens, keys) and the private images it pulls. A managed control plane and an offshore registry put that data and supply chain abroad — a data-residency and PIPL question, not a reachability one.
Does Kubernetes work in China?
Kubernetes is open-source and you self-host the cluster, so residency is a choice you make — and the thing that decides compliance is where the cluster, its Secrets and the private images it pulls actually live, not whether a node in Shanghai can reach a registry. A running cluster holds your workloads, the private images baked with your proprietary code, and its Secrets — in Kubernetes’ own words “an object that contains a small amount of sensitive data such as a password, a token, or a key,” stored by default in the cluster’s etcd data store. Run that on a managed control plane (EKS, AKS or GKE) or pull from an offshore private registry, and that concentrated code and secret material sits abroad.
Because that data sits offshore, personal information in your workloads, Secrets or build metadata becomes a cross-border transfer under PIPL (Articles 38–40) — notice, a separate consent, and a transfer mechanism — and for a critical information infrastructure operator the Cybersecurity Law’s Article 39 (formerly Article 37) adds an in-country storage duty an offshore control plane cannot meet. Your China deployment’s image supply chain — what runs in the mainland, with what provenance — crosses the border too. A registry mirror or cache speeds a pull; it does not move your private images or Secrets in-country.
Because Kubernetes is self-hostable, there is a genuine in-country path: 21YunBox maps where your cluster, Secrets and private images live, then runs the open-source cluster and an in-country private registry with ICP-filed delivery in front of it — so your workloads, Secrets and image supply chain stay resident, with no rebuild and no circumvention of any kind. Treat the specifics as a risk to confirm with counsel.
What Kubernetes's own documentation says about China
| Fact | Primary source |
|---|---|
| A Kubernetes cluster stores your Secrets — credentials, tokens and keys. Kubernetes’ own docs define it plainly: “A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key.” By default those Secrets are “stored unencrypted in the API server’s underlying data store (etcd),” so they live wherever the cluster runs. | Kubernetes Documentation, “Secrets” (kubernetes.io), retrieved 2026-10-13 |
| Kubernetes is open-source, so you choose where the cluster runs. Kubernetes’ docs describe it as “a portable, extensible, open source platform for managing containerized workloads and services,” and note that “Google open sourced the Kubernetes project in 2014.” Being open-source and self-hostable means an in-country cluster is a genuine, lawful option — a managed control plane (EKS/AKS/GKE) is the offshore variant. | Kubernetes Documentation, “Overview” (kubernetes.io), retrieved 2026-10-13 |
| China-collected data may have to stay in the mainland. For a critical information infrastructure operator, the Cybersecurity Law’s Article 39 (formerly Article 37, renumbered by the amendment in force 2026-01-01) requires personal information and important data collected and generated in China to be stored in the mainland — a duty an offshore managed control plane or registry cannot meet. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37), amended 2025, in force 2026-01-01 — see 21YunBox gov-doc summary, retrieved 2026-10-13 |
| Cluster data and identities held offshore are a PIPL cross-border transfer. Personal data inside your workloads, Secrets or build and access metadata — held on a managed control plane or registry outside the mainland — is a cross-border transfer under PIPL Articles 38–40: notice, a separate consent, and one transfer mechanism (a CAC security assessment, the CAC standard contract, or certification). | Personal Information Protection Law of the PRC, Articles 38–40 — see 21YunBox cross-border data transfers summary, retrieved 2026-10-13 |
Sources verified by the 21YunBox compliance team on 2026-10-13.
For a mainland-China operation, the deciding question about Kubernetes is not whether a node in Shanghai can pull a public base image — it is where your cluster runs, what it holds, and on what legal basis any China-collected data in it sits there. Pulling community images is a reachability topic, and not the one that decides whether your setup is defensible. Kubernetes is open-source and you self-host it, so residency is a choice you make rather than a fixed property of someone else’s service. A running cluster is the authoritative home of your workloads, the private images baked with your proprietary code, and its Secrets — and in Kubernetes’ own words a Secret is “an object that contains a small amount of sensitive data such as a password, a token, or a key,” stored by default in the cluster’s etcd data store. Put that cluster on a managed control plane (EKS, AKS or GKE) or let it pull private images from an offshore registry, and that concentrated code and secret material lives abroad, while your China deployment’s image supply chain — what runs in the mainland, with what provenance and integrity — crosses the border. Residency and cross-border transfer, not load time, are what decide this.
Does Kubernetes work in China? At a glance
| What decides it | What it means for mainland China |
|---|---|
| What your cluster holds | Your workloads, the private images baked with your proprietary code, and Secrets — passwords, tokens and keys — stored by default in the cluster's etcd data store. |
| Where the control plane runs | Self-hosted, the cluster runs wherever you put it. On a managed service (EKS, AKS, GKE) the control plane and that data run on the vendor's offshore infrastructure; confirm any mainland region with the vendor. |
| Where your private images come from | A China cluster pulling private images from an offshore registry runs its image supply chain across the border — provenance and integrity governed offshore. A registry mirror or cache speeds the pull; it does not move the private images in-country. |
| Data residency | For a CIIO or large-volume handler, personal information and important data collected in China must be stored in the mainland (Cybersecurity Law Article 39 (formerly Article 37)) — a duty an offshore control plane cannot meet. |
| Cross-border transfer | Personal data inside workloads, Secrets or build and access metadata, held offshore, is a PIPL cross-border transfer (Articles 38–40): notice, a separate consent, and one transfer mechanism. |
| The residency lever | Run the open-source cluster in-country and pull from an in-country private registry you host (Harbor, Nexus or Artifactory in your own infrastructure) to keep the workloads, images and Secrets resident. |
Door one — your cluster holds proprietary code and Secrets, and residency follows where you run it
Start with what the cluster holds, because that is what China’s law answers to. Pulling public base images is a reachability topic, and not the part that decides this. Your private images are different: a container image is an artifact that bakes your proprietary code into its layers, and routinely embeds build configuration, API tokens and credentials. The cluster that runs them is the authoritative store of your workloads and — in Kubernetes’ own words — Secrets, “an object that contains a small amount of sensitive data such as a password, a token, or a key.” Those Secrets do not float in the abstract: by default they are “stored unencrypted in the API server’s underlying data store (etcd),” which means they physically live wherever the cluster runs.
That is the point. Because Kubernetes is open-source and self-hosted, where you run the cluster is a decision, not a given — and a managed control plane (EKS, AKS or GKE) is the variant that runs it, and that Secret store, on the vendor’s offshore infrastructure (confirm any mainland region with the vendor rather than assume). If you are a critical information infrastructure operator, or you handle personal information at volume, personal information and important data collected and generated in China must be stored in the mainland, with a security assessment before any export — the Cybersecurity Law data-localization rule, Article 39 (formerly Article 37) as renumbered by the 2025 amendment in force 2026-01-01. An offshore control plane holding your workloads and Secrets has no mainland footing to satisfy that.
Door two — personal data, supply-chain provenance and PIPL
The second door is PIPL and the integrity of what runs in your China cluster. A cluster and the pipeline around it carry more than code: personal data can live inside workloads and persistent volumes, inside Secrets, and inside build and access metadata — who pushed an image, who deployed a release, and the logs that record it. Under the Personal Information Protection Law, holding that data on infrastructure outside the mainland is a cross-border transfer (Articles 38–40): the handler must give notice, obtain a separate consent for the transfer, and clear one mechanism — a CAC security assessment, the CAC standard contract, or certification. Minimizing the secrets and personal data that enter images and workloads in the first place is part of the fix, but it does not move the store on its own. And because a China cluster pulls its private images from wherever the registry runs, the provenance and integrity of the code entering your China deployment are governed across the border too — a software-supply-chain exposure a connectivity check never surfaces.
Why a reachability check misses this
A “can my node pull an image from Shanghai” test answers the wrong question. A registry mirror or cache, or connectivity tuning, changes how fast and how reliably an image pulls — it does not change where your cluster, its Secrets and your private images actually live. So a setup can look perfectly healthy from inside China while the control plane, every Secret in etcd, and every private image still sit offshore. The residency and cross-border questions above are invisible to a reachability probe precisely because the pulls keep succeeding — which is why the move that matters is running the cluster and its registry in-country, not making an offshore control plane or registry merely reachable or mirrored. We publish no first-party measurement of Kubernetes registry connectivity from inside China, so we put no figures here; it is something we would measure against your actual setup rather than assert.
This is a risk map, not a verdict: whether you need in-country storage, a transfer mechanism, a reworked consent flow, an ICP filing for any public-facing developer or app endpoint, or some combination depends on what your workloads, Secrets and images carry, how much, and who your users and contributors are — worth settling with counsel before you build.
The lever — map, localize, deliver
Because Kubernetes is open-source and self-hostable, there is a genuine in-country path, and 21YunBox never uses or suggests circumvention of any kind.
- Map — inventory which images are private (your proprietary code), whether images and Secrets embed credentials, tokens or configuration, where the cluster control plane and its etcd Secret store run today, the residency basis, and how your China deployment’s image supply chain crosses the border.
- Localize / govern — run the open-source cluster and its Secret store in-country (self-hosted), and pull private images from an in-country private registry you host (Harbor, Nexus or Artifactory in your own infrastructure), so the proprietary code and Secrets stay resident; keep the China deployment’s supply chain in-country; and minimize what crosses the border.
- Deliver — put a compliant, in-country cluster, private registry and image delivery in front of (or in place of) the offshore control plane; 21YunBox stands up the in-country layer without a rebuild.
Making an offshore registry merely reachable or mirrored is not the answer — your cluster, its Secrets and your private images are still offshore, and pulling them faster does not change that. Keeping the cluster, registry and Secrets in-country is.
Where 21YunBox fits — a compliant overlay, not a migration
You keep running Kubernetes. We add the piece an offshore control plane cannot provide on its own: a lawful, in-country home for a self-hosted cluster, its etcd Secret store and a self-hosted private registry, so your workloads, proprietary images and Secrets stay resident where the law requires, with compliant ICP-filed delivery for the developer access and any public-facing endpoint in front of it — placed around your existing setup, with no rebuild, no second codebase, and no migration off Kubernetes. As a partner to the toolchain you already run, our China team maps your PIPL cross-border, consent and data-residency obligations against your entity and your pipeline, then stands up the in-country cluster, registry and delivery a defensible China presence needs. We never use or suggest circumvention of any kind.
Related reading:
- Cross-border data transfers under PIPL
- China’s Cybersecurity Law and data localization
- How to get an ICP filing for China
