Funktioniert Kubernetes in China? Data Residency, ICP & Grenztransfer-Regeln
Kubernetes ist Open Source und selbst gehostet, Residency ist also eine Wahl: der Cluster hält Ihre Workloads, seine Secrets (Passwörter, Tokens, Keys) und die privaten Images, die er zieht. Eine managed Control Plane und eine Offshore-Registry stellen diese Daten und Lieferkette ins Ausland — eine Data-Residency- und PIPL-Frage, keine Erreichbarkeitsfrage.
Funktioniert Kubernetes in China?
Kubernetes ist Open Source und Sie hosten den Cluster selbst, Residency ist also eine Wahl, die Sie treffen — und was über Compliance entscheidet, ist, wo der Cluster, seine Secrets und die privaten Images, die er zieht, tatsächlich leben, nicht, ob ein Knoten in Shanghai eine Registry erreichen kann. Ein laufender Cluster hält Ihre Workloads, die privaten Images, in die Ihr proprietärer Code eingebacken ist, und seine Secrets — in Kubernetes’ eigenen Worten „an object that contains a small amount of sensitive data such as a password, a token, or a key“, standardmäßig im etcd-Datenspeicher des Clusters abgelegt. Betreiben Sie das auf einer managed Control Plane (EKS, AKS oder GKE) oder ziehen Sie aus einer Offshore-Private-Registry, sitzt dieses konzentrierte Code- und Secret-Material im Ausland.
Weil diese Daten offshore sitzen, wird personenbezogene Information in Ihren Workloads, Secrets oder Build-Metadaten zu einem grenzüberschreitenden Transfer nach PIPL (Artikel 38–40) — Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus — und für einen Betreiber kritischer Informationsinfrastruktur fügt das Cybersicherheitsgesetz mit Artikel 39 (vormals Artikel 37) eine inländische Speicherpflicht hinzu, die eine Offshore-Control-Plane nicht erfüllen kann. Die Image-Lieferkette Ihres China-Deployments — was im Festland läuft, mit welcher Herkunft — überschreitet ebenfalls die Grenze. Ein Registry-Mirror oder -Cache beschleunigt einen Pull; er bewegt Ihre privaten Images oder Secrets nicht ins Inland.
Weil Kubernetes selbst hostbar ist, gibt es einen echten inländischen Pfad: 21YunBox kartiert, wo Ihr Cluster, Ihre Secrets und Ihre privaten Images leben, und betreibt dann den Open-Source-Cluster und eine inländische private Registry mit ICP-eingereichter Auslieferung davor — damit Ihre Workloads, Secrets und Image-Lieferkette resident bleiben, ohne Neuaufbau und ohne Umgehung jeglicher Art. Behandeln Sie die Besonderheiten als ein mit Rechtsbeistand zu bestätigendes Risiko.
Compliance-Momentaufnahme
- ! Kubernetes ist Open Source und selbst gehostet, wo der Cluster läuft entscheidet also Residency.
- ! Der Cluster hält Ihre Workloads, seine Secrets und die privaten Images, die er zieht.
- ! Secrets halten Passwörter, Tokens und Keys, gespeichert im etcd-Datenspeicher des Clusters.
- ! Managed K8s (EKS/AKS/GKE) stellt die Control Plane und diese Daten offshore.
- ! China-Daten offshore lösen CSL Art 39 (vormals Art 37) und PIPL Art 38–40 aus.
- ✓ Betreiben Sie den OSS-Cluster plus eine inländische private Registry, um alles resident zu halten.
Was die offizielle Kubernetes-Dokumentation über China sagt
| Fakt | Primärquelle |
|---|---|
| Ein Kubernetes-Cluster speichert Ihre Secrets — Credentials, Tokens und Keys. Kubernetes’ eigene Docs definieren es schlicht: „A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key“. Standardmäßig sind diese Secrets „stored unencrypted in the API server’s underlying data store (etcd)“, sie leben also, wo immer der Cluster läuft. | Kubernetes Documentation, „Secrets“ (kubernetes.io), abgerufen 2026-10-13 |
| Kubernetes ist Open Source, Sie wählen also, wo der Cluster läuft. Kubernetes’ Docs beschreiben es als „a portable, extensible, open source platform for managing containerized workloads and services“ und merken an, dass „Google open sourced the Kubernetes project in 2014“. Open Source und selbst hostbar zu sein bedeutet, dass ein inländischer Cluster eine echte, rechtmäßige Option ist — eine managed Control Plane (EKS/AKS/GKE) ist die Offshore-Variante. | Kubernetes Documentation, „Overview“ (kubernetes.io), abgerufen 2026-10-13 |
| In China erhobene Daten müssen möglicherweise im Festland bleiben. Für einen Betreiber kritischer Informationsinfrastruktur verlangt das Cybersicherheitsgesetz mit Artikel 39 (vormals Artikel 37, umnummeriert durch die Novelle, in Kraft seit 2026-01-01), dass in China erhobene und erzeugte personenbezogene Information und important data im Festland gespeichert werden — eine Pflicht, die eine Offshore-managed-Control-Plane oder -Registry nicht erfüllen kann. | Cybersecurity Law of the PRC, Article 39 (formerly Article 37), amended 2025, in force 2026-01-01 — siehe 21YunBox gov-doc summary, abgerufen 2026-10-13 |
| Offshore gehaltene Cluster-Daten und -Identitäten sind ein PIPL-Grenztransfer. Personenbezogene Daten in Ihren Workloads, Secrets oder Build- und Zugriffs-Metadaten — auf einer managed Control Plane oder Registry außerhalb des Festlands gehalten — sind ein grenzüberschreitender Transfer nach PIPL Artikel 38–40: Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus (eine CAC-Sicherheitsbewertung, der CAC-Standardvertrag oder eine Zertifizierung). | Personal Information Protection Law of the PRC, Articles 38–40 — siehe 21YunBox cross-border data transfers summary, abgerufen 2026-10-13 |
Quellen vom 21YunBox Compliance-Team am 13. Oktober 2026 geprüft.
Für einen Festlandchina-Betrieb ist die entscheidende Frage zu Kubernetes nicht, ob ein Knoten in Shanghai ein öffentliches Base-Image ziehen kann — es ist, wo Ihr Cluster läuft, was er hält und auf welcher Rechtsgrundlage dort in ihm enthaltene, in China erhobene Daten sitzen. Community-Images zu ziehen ist ein Erreichbarkeitsthema und nicht das, was entscheidet, ob Ihr Setup verteidigbar ist. Kubernetes ist Open Source und Sie hosten es selbst, Residency ist also eine Wahl, die Sie treffen, statt einer festen Eigenschaft des Dienstes eines anderen. Ein laufender Cluster ist das maßgebliche Zuhause Ihrer Workloads, der privaten Images, in die Ihr proprietärer Code eingebacken ist, und seiner Secrets — und in Kubernetes’ eigenen Worten ist ein Secret „an object that contains a small amount of sensitive data such as a password, a token, or a key“, standardmäßig im etcd-Datenspeicher des Clusters abgelegt. Stellen Sie diesen Cluster auf eine managed Control Plane (EKS, AKS oder GKE) oder lassen ihn private Images aus einer Offshore-Registry ziehen, dann lebt dieses konzentrierte Code- und Secret-Material im Ausland, während die Image-Lieferkette Ihres China-Deployments — was im Festland läuft, mit welcher Herkunft und Integrität — die Grenze überschreitet. Residency und Grenztransfer, nicht Ladezeit, sind es, was hier entscheidet.
Funktioniert Kubernetes in China? Auf einen Blick
| Was darüber entscheidet | Was es für Festlandchina bedeutet |
|---|---|
| Was Ihr Cluster hält | Ihre Workloads, die privaten Images, in die Ihr proprietärer Code eingebacken ist, und Secrets — Passwörter, Tokens und Keys — standardmäßig im etcd-Datenspeicher des Clusters abgelegt. |
| Wo die Control Plane läuft | Selbst gehostet läuft der Cluster, wo immer Sie ihn hinstellen. Auf einem managed Service (EKS, AKS, GKE) laufen die Control Plane und diese Daten auf der Offshore-Infrastruktur des Anbieters; bestätigen Sie jede Festland-Region mit dem Anbieter. |
| Woher Ihre privaten Images kommen | Ein China-Cluster, der private Images aus einer Offshore-Registry zieht, betreibt seine Image-Lieferkette über die Grenze hinweg — Herkunft und Integrität offshore geregelt. Ein Registry-Mirror oder -Cache beschleunigt den Pull; er bewegt die privaten Images nicht ins Inland. |
| Data Residency | Für einen CIIO oder Handler mit hohem Volumen müssen in China erhobene personenbezogene Information und important data im Festland gespeichert werden (Cybersicherheitsgesetz Artikel 39 (vormals Artikel 37)) — eine Pflicht, die eine Offshore-Control-Plane nicht erfüllen kann. |
| Grenzüberschreitender Transfer | Personenbezogene Daten in Workloads, Secrets oder Build- und Zugriffs-Metadaten, offshore gehalten, sind ein PIPL-Grenztransfer (Artikel 38–40): Mitteilung, eine gesonderte Einwilligung und ein Transfermechanismus. |
| Der Residency-Hebel | Betreiben Sie den Open-Source-Cluster im Inland und ziehen Sie aus einer inländischen privaten Registry, die Sie selbst hosten (Harbor, Nexus oder Artifactory in Ihrer eigenen Infrastruktur), um Workloads, Images und Secrets resident zu halten. |
Tür eins — Ihr Cluster hält proprietären Code und Secrets, und Residency folgt dem, wo Sie ihn betreiben
Beginnen Sie bei dem, was der Cluster hält, denn das ist es, worauf Chinas Recht antwortet. Öffentliche Base-Images zu ziehen ist ein Erreichbarkeitsthema und nicht der Teil, der hier entscheidet. Ihre privaten Images sind anders: ein Container-Image ist ein Artefakt, das Ihren proprietären Code in seine Schichten einbäckt und routinemäßig Build-Konfiguration, API-Tokens und Credentials einbettet. Der Cluster, der sie ausführt, ist der maßgebliche Speicher Ihrer Workloads und — in Kubernetes’ eigenen Worten — Secrets, „an object that contains a small amount of sensitive data such as a password, a token, or a key“. Diese Secrets schweben nicht im Abstrakten: standardmäßig sind sie „stored unencrypted in the API server’s underlying data store (etcd)“, was bedeutet, dass sie physisch leben, wo immer der Cluster läuft.
Das ist der Punkt. Weil Kubernetes Open Source und selbst gehostet ist, ist es eine Entscheidung und keine Gegebenheit, wo Sie den Cluster betreiben — und eine managed Control Plane (EKS, AKS oder GKE) ist die Variante, die ihn, und diesen Secret-Speicher, auf der Offshore-Infrastruktur des Anbieters betreibt (bestätigen Sie jede Festland-Region mit dem Anbieter, statt sie anzunehmen). Sind Sie ein Betreiber kritischer Informationsinfrastruktur oder handhaben personenbezogene Information in Mengen, müssen in China erhobene und erzeugte personenbezogene Information und important data im Festland gespeichert werden, mit einer Sicherheitsbewertung vor jedem Export — die Datenlokalisierungsregel des Cybersicherheitsgesetzes, Artikel 39 (vormals Artikel 37), wie durch die Novelle von 2025 umnummeriert, in Kraft seit 2026-01-01. Eine Offshore-Control-Plane, die Ihre Workloads und Secrets hält, hat kein Festland-Fundament, um das zu erfüllen.
Tür zwei — personenbezogene Daten, Lieferketten-Herkunft und PIPL
Die zweite Tür ist PIPL und die Integrität dessen, was in Ihrem China-Cluster läuft. Ein Cluster und die Pipeline um ihn tragen mehr als Code: personenbezogene Daten können in Workloads und Persistent Volumes leben, in Secrets und in Build- und Zugriffs-Metadaten — wer ein Image gepusht hat, wer ein Release deployt hat und die Logs, die es aufzeichnen. Nach dem Gesetz zum Schutz personenbezogener Daten ist das Halten dieser Daten auf Infrastruktur außerhalb des Festlands ein grenzüberschreitender Transfer (Artikel 38–40): der Handler muss Mitteilung geben, eine gesonderte Einwilligung für den Transfer einholen und einen Mechanismus freigeben — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Die Secrets und personenbezogenen Daten, die überhaupt erst in Images und Workloads gelangen, zu minimieren, ist Teil der Lösung, bewegt den Speicher aber nicht für sich allein. Und weil ein China-Cluster seine privaten Images von dort zieht, wo die Registry läuft, werden auch Herkunft und Integrität des in Ihr China-Deployment eintretenden Codes über die Grenze hinweg geregelt — eine Software-Lieferketten-Exponierung, die eine Konnektivitätsprüfung nie aufdeckt.
Warum eine Erreichbarkeitsprüfung das verfehlt
Ein Test „kann mein Knoten ein Image aus Shanghai ziehen“ beantwortet die falsche Frage. Ein Registry-Mirror oder -Cache oder Konnektivitäts-Tuning ändert, wie schnell und wie zuverlässig ein Image gezogen wird — es ändert nicht, wo Ihr Cluster, seine Secrets und Ihre privaten Images tatsächlich leben. Ein Setup kann also aus China heraus vollkommen gesund aussehen, während die Control Plane, jedes Secret in etcd und jedes private Image weiterhin offshore sitzen. Die Residency- und Grenztransfer-Fragen oben sind für eine Erreichbarkeitssonde unsichtbar, gerade weil die Pulls weiter gelingen — weshalb der Zug, der zählt, darin besteht, den Cluster und seine Registry im Inland zu betreiben, nicht eine Offshore-Control-Plane oder -Registry bloß erreichbar oder gespiegelt zu machen. Wir publizieren keine eigene Messung der Kubernetes-Registry-Konnektivität aus China, wir setzen hier also keine Zahlen; es wäre etwas, das wir gegen Ihr tatsächliches Setup messen würden, statt es zu behaupten.
Dies ist eine Risikokarte, kein Urteil: ob Sie inländische Speicherung, einen Transfermechanismus, einen überarbeiteten Einwilligungs-Flow, eine ICP-Beian für einen öffentlich zugewandten Entwickler- oder App-Endpunkt oder eine Kombination brauchen, hängt davon ab, was Ihre Workloads, Secrets und Images tragen, wie viel und wer Ihre Nutzer und Mitwirkenden sind — wert, mit Rechtsbeistand zu klären, bevor Sie bauen.
Der Hebel — kartieren, lokalisieren, ausliefern
Weil Kubernetes Open Source und selbst hostbar ist, gibt es einen echten inländischen Pfad, und 21YunBox nutzt oder empfiehlt niemals Umgehung jeglicher Art.
- Kartieren — inventarisieren, welche Images privat sind (Ihr proprietärer Code), ob Images und Secrets Credentials, Tokens oder Konfiguration einbetten, wo die Cluster-Control-Plane und ihr etcd-Secret-Speicher heute laufen, die Residency-Grundlage und wie die Image-Lieferkette Ihres China-Deployments die Grenze überschreitet.
- Lokalisieren / governen — betreiben Sie den Open-Source-Cluster und seinen Secret-Speicher im Inland (selbst gehostet) und ziehen Sie private Images aus einer inländischen privaten Registry, die Sie selbst hosten (Harbor, Nexus oder Artifactory in Ihrer eigenen Infrastruktur), damit der proprietäre Code und die Secrets resident bleiben; halten Sie die Lieferkette des China-Deployments im Inland; und minimieren Sie, was die Grenze überschreitet.
- Ausliefern — setzen Sie einen rechtskonformen, inländischen Cluster, eine private Registry und Image-Auslieferung vor (oder an die Stelle) der Offshore-Control-Plane; 21YunBox stellt die inländische Schicht ohne Neuaufbau auf.
Eine Offshore-Registry bloß erreichbar oder gespiegelt zu machen, ist nicht die Antwort — Ihr Cluster, seine Secrets und Ihre privaten Images sind weiterhin offshore, und sie schneller zu ziehen ändert das nicht. Den Cluster, die Registry und die Secrets im Inland zu halten, ist es.
Wo 21YunBox passt — eine rechtskonforme Overlay, keine Migration
Sie betreiben Kubernetes weiter. Wir fügen das Stück hinzu, das eine Offshore-Control-Plane nicht aus sich heraus bieten kann: ein rechtmäßiges, inländisches Zuhause für einen selbst gehosteten Cluster, seinen etcd-Secret-Speicher und eine selbst gehostete private Registry, damit Ihre Workloads, proprietären Images und Secrets dort resident bleiben, wo das Recht es verlangt, mit rechtskonformer ICP-eingereichter Auslieferung für den Entwickler-Zugang und jeden öffentlich zugewandten Endpunkt davor — um Ihr bestehendes Setup herum platziert, ohne Neuaufbau, ohne zweite Codebasis und ohne Migration weg von Kubernetes. Als Partner zu der Toolchain, die Sie bereits betreiben, kartiert unser China-Team Ihre PIPL-Grenztransfer-, Einwilligungs- und Data-Residency-Pflichten gegen Ihre Rechtsperson und Ihre Pipeline und stellt dann den inländischen Cluster, die Registry und die Auslieferung auf, die eine verteidigbare China-Präsenz braucht. Wir nutzen oder empfehlen niemals Umgehung jeglicher Art.
Compliance-Einschätzung anfordern →
Weiterführend:
- Grenzüberschreitende Datentransfers nach PIPL
- Chinas Cybersicherheitsgesetz und Datenlokalisierung
- So erhalten Sie eine ICP-Beian für China
Häufige Fragen
Ist Kubernetes in China gesperrt?
Nein — Kubernetes ist Open-Source-Software, die Sie selbst betreiben, kein gehosteter Dienst, den Chinas Netzwerkfilterung sperrt, Sie können also einen Cluster im Festland betreiben. Aber Erreichbarkeit ist nicht die Frage, die Compliance für ein China-gerichtetes Deployment entscheidet. Was entscheidet, ist, wo der Cluster, seine Secrets (Passwörter, Tokens und Keys) und die privaten Images, die er zieht, tatsächlich leben und ob darin enthaltene, in China erhobene personenbezogene Daten die Grenze überschreiten. Behandeln Sie die Besonderheiten als ein mit Rechtsbeistand zu bestätigendes Risiko.
Kann ich managed Kubernetes (EKS, AKS, GKE) für mein China-Deployment nutzen?
Sie können, aber ein managed Kubernetes-Dienst betreibt die Control Plane auf der Offshore-Infrastruktur des Anbieters, und Ihre privaten Images kommen typischerweise aus einer Offshore-Registry — die Secrets, Workload-Daten und Image-Lieferkette Ihres Clusters sitzen also im Ausland. Für in China erhobene personenbezogene Daten ist das ein PIPL-Grenztransfer (Artikel 38–40), und für einen Betreiber kritischer Informationsinfrastruktur fügt das Cybersicherheitsgesetz mit Artikel 39 (vormals Artikel 37) eine inländische Speicherpflicht hinzu. Der inländische Pfad ist, den Open-Source-Cluster und eine private Registry innerhalb des Festlands zu betreiben. Ob jede Regel auf Ihre Daten zutrifft, ist eine Frage für Rechtsbeistand.
Was ist der rechtskonforme Weg, Kubernetes in China zu betreiben?
Betreiben Sie den Open-Source-Cluster innerhalb des Festlands und ziehen Sie aus einer inländischen privaten Registry, die Sie selbst hosten (zum Beispiel Harbor, Nexus oder Artifactory in Ihrer eigenen Infrastruktur), damit Ihre Workloads, Secrets und privaten Images resident bleiben, und bedienen Sie jeden öffentlich zugewandten Entwickler- oder App-Endpunkt auf ICP-eingereichter, inländischer Infrastruktur. Halten Sie die Image-Lieferkette des China-Deployments im Inland und minimieren Sie, was die Grenze überschreitet. 21YunBox kartiert diesen Pfad und stellt den inländischen Cluster, die Registry und die Auslieferung ohne Neuaufbau auf — niemals eine Route um eine Sperre herum.
