Kubernetes는 중국에서 작동하나요? 데이터 레지던시, ICP & 국경 간 규칙
Kubernetes는 오픈소스이고 셀프호스팅이므로, 레지던시는 선택입니다: 클러스터는 귀사 워크로드, 그 Secret(패스워드, 토큰, 키), 그리고 그것이 당겨오는 사설 이미지를 쥡니다. 관리형 컨트롤 플레인과 해외 레지스트리는 그 데이터와 공급망을 해외에 둡니다 — 도달성이 아니라 데이터 레지던시와 PIPL 질문.
Kubernetes는 중국에서 작동하나요?
Kubernetes는 오픈소스이고 귀사가 클러스터를 셀프호스팅하므로, 레지던시는 귀사가 하는 선택입니다 — 그리고 컴플라이언스를 결정하는 것은 상하이의 노드가 레지스트리에 닿을 수 있는지가 아니라, 클러스터, 그 Secret, 그것이 당겨오는 사설 이미지가 실제로 어디에 사는지입니다. 도는 클러스터는 귀사 워크로드, 귀사 독점 코드로 구운 사설 이미지, 그리고 그 Secret — Kubernetes 자신의 표현으로 “an object that contains a small amount of sensitive data such as a password, a token, or a key,” 기본적으로 클러스터의 etcd 데이터 저장소에 저장된 — 을 쥡니다. 그것을 관리형 컨트롤 플레인(EKS, AKS, 또는 GKE)에서 돌리거나 해외 사설 레지스트리에서 당기면, 그 집중된 코드와 비밀 재료가 해외에 앉습니다.
그 데이터가 해외에 앉으므로, 귀사 워크로드, Secret, 또는 빌드 메타데이터 안의 개인정보가 PIPL상 국경 간 이전(제38~40조)이 됩니다 — 고지, 별도 동의, 이전 메커니즘 — 그리고 핵심정보인프라 운영자에는 사이버보안법의 제39조(구 제37조)가 해외 컨트롤 플레인이 충족할 수 없는 국내 저장 의무를 더합니다. 귀사 중국 배포의 이미지 공급망 — 무엇이 본토에서 돌고, 어떤 출처로 — 도 국경을 넘습니다. 레지스트리 미러나 캐시는 당김을 빠르게 하지; 귀사 사설 이미지나 Secret을 국내로 옮기지 않습니다.
Kubernetes가 셀프호스팅 가능하므로, 진정한 국내 경로가 있습니다: 21YunBox는 귀사 클러스터, Secret, 사설 이미지가 어디에 사는지 매핑하고, 그런 다음 오픈소스 클러스터와 국내 사설 레지스트리를 그 앞단의 ICP 비안 전송과 함께 돌립니다 — 그래서 귀사 워크로드, Secret, 이미지 공급망이 거주하고, 재구축도 어떤 종류의 우회도 없이. 구체적인 것은 자문과 확인할 리스크로 다루십시오.
컴플라이언스 스냅샷
- ! Kubernetes는 오픈소스이고 셀프호스팅이므로, 클러스터가 어디서 도는지가 레지던시를 결정합니다.
- ! 클러스터는 귀사 워크로드, 그 Secret, 그리고 그것이 당겨오는 사설 이미지를 쥡니다.
- ! Secret은 패스워드, 토큰, 키를 쥐고, 클러스터의 etcd 데이터 저장소에 저장됩니다.
- ! 관리형 K8s(EKS/AKS/GKE)는 컨트롤 플레인과 그 데이터를 해외에 둡니다.
- ! 중국 데이터가 해외에 있으면 CSL 제39조(구 제37조)와 PIPL 제38~40조가 걸립니다.
- ✓ OSS 클러스터에 국내 사설 레지스트리를 더해 돌려 그 모두를 거주시키십시오.
Kubernetes 공식 문서가 중국에 대해 말하는 것
| 사실 | 1차 출처 |
|---|---|
| Kubernetes 클러스터는 귀사 Secret — 자격증명, 토큰, 키 — 을 저장합니다. Kubernetes 자신의 문서가 그것을 분명히 정의합니다: “A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key.” 기본적으로 그 Secret은 “stored unencrypted in the API server’s underlying data store (etcd),” 이므로, 클러스터가 도는 어디든 삽니다. | Kubernetes Documentation, “Secrets” (kubernetes.io), 2026-10-13 열람 |
| Kubernetes는 오픈소스이므로, 귀사가 클러스터가 어디서 도는지 고릅니다. Kubernetes 문서는 그것을 “a portable, extensible, open source platform for managing containerized workloads and services,” 로 기술하고, “Google open sourced the Kubernetes project in 2014.” 라 언급합니다. 오픈소스이고 셀프호스팅 가능하다는 것은 국내 클러스터가 진정한, 합법적 옵션임을 뜻합니다 — 관리형 컨트롤 플레인(EKS/AKS/GKE)은 해외 변종입니다. | Kubernetes Documentation, “Overview” (kubernetes.io), 2026-10-13 열람 |
| 중국에서 수집된 데이터는 본토에 머물러야 할 수 있습니다. 핵심정보인프라 운영자에게, 사이버보안법의 제39조(구 제37조, 2026-01-01 발효된 개정으로 재번호)는 중국에서 수집되고 생성된 개인정보와 중요 데이터가 본토에 저장될 것을 요구합니다 — 해외 관리형 컨트롤 플레인이나 레지스트리가 충족할 수 없는 의무. | 중화인민공화국 사이버보안법, 제39조(구 제37조), 2025년 개정, 2026-01-01 발효 — 21YunBox gov-doc 요약 참고, 2026-10-13 열람 |
| 해외에 쥐어진 클러스터 데이터와 신원은 PIPL 국경 간 이전입니다. 귀사 워크로드, Secret, 또는 빌드·접근 메타데이터 안의 개인 데이터 — 본토 밖 관리형 컨트롤 플레인이나 레지스트리에 쥐어진 — 는 PIPL 제38~40조상 국경 간 이전입니다: 고지, 별도 동의, 그리고 이전 메커니즘 하나(CAC 안전성 평가, CAC 표준계약, 또는 인증). | 중화인민공화국 개인정보 보호법, 제38~40조 — 21YunBox 국경 간 데이터 이전 요약 참고, 2026-10-13 열람 |
21YunBox 컴플라이언스 팀이(가) 2026년 10월 13일에 출처를 확인했습니다.
중국 본토 운영에, Kubernetes에 대한 결정적 질문은 상하이의 노드가 공개 베이스 이미지를 당겨올 수 있는지가 아니라 — 귀사 클러스터가 어디서 도는지, 그것이 무엇을 쥐는지, 그리고 그 안의 어떤 중국 수집 데이터든 무슨 법적 근거로 거기 앉는지입니다. 커뮤니티 이미지를 당기는 것은 도달성 주제이고, 귀사 설정이 방어 가능한지를 결정하는 것이 아닙니다. Kubernetes는 오픈소스이고 귀사가 그것을 셀프호스팅하므로, 레지던시는 남의 서비스의 고정된 속성이 아니라 귀사가 하는 선택입니다. 도는 클러스터는 귀사 워크로드, 귀사 독점 코드로 구운 사설 이미지, 그리고 그 Secret의 권위 있는 집입니다 — 그리고 Kubernetes 자신의 표현으로 Secret은 “an object that contains a small amount of sensitive data such as a password, a token, or a key,” 로, 기본적으로 클러스터의 etcd 데이터 저장소에 저장됩니다. 그 클러스터를 관리형 컨트롤 플레인(EKS, AKS, 또는 GKE)에 두거나 해외 레지스트리에서 사설 이미지를 당기게 하면, 그 집중된 코드와 비밀 재료가 해외에 살고, 귀사 중국 배포의 이미지 공급망 — 무엇이 본토에서 돌고, 어떤 출처와 무결성으로 — 이 국경을 넘습니다. 로드 타임이 아니라 레지던시와 국경 간 이전이 이것을 결정합니다.
Kubernetes는 중국에서 작동하나요? 한눈에
| 무엇이 결정하는가 | 중국 본토에 무엇을 뜻하는가 |
|---|---|
| 귀사 클러스터가 무엇을 쥐는가 | 귀사 워크로드, 귀사 독점 코드로 구운 사설 이미지, 그리고 Secret — 패스워드, 토큰, 키 — 기본적으로 클러스터의 etcd 데이터 저장소에 저장된. |
| 컨트롤 플레인이 어디서 도는가 | 셀프호스팅이면, 클러스터는 귀사가 두는 어디서든 돕니다. 관리형 서비스(EKS, AKS, GKE)에서는 컨트롤 플레인과 그 데이터가 벤더의 해외 인프라에서 돕니다; 어떤 본토 리전이든 벤더와 확인하십시오. |
| 귀사 사설 이미지가 어디서 오는가 | 해외 레지스트리에서 사설 이미지를 당기는 중국 클러스터는 그 이미지 공급망을 국경 너머로 돌립니다 — 출처와 무결성이 해외에서 다스려지며. 레지스트리 미러나 캐시는 당김을 빠르게 하지; 사설 이미지를 국내로 옮기지 않습니다. |
| 데이터 레지던시 | 핵심정보인프라 운영자나 대량 취급자에는, 중국에서 수집된 개인정보와 중요 데이터가 본토에 저장되어야 합니다(사이버보안법 제39조(구 제37조)) — 해외 컨트롤 플레인이 충족할 수 없는 의무. |
| 국경 간 이전 | 워크로드, Secret, 또는 빌드·접근 메타데이터 안의 개인 데이터를 해외에 쥐는 것은 PIPL 국경 간 이전입니다(제38~40조): 고지, 별도 동의, 이전 메커니즘 하나. |
| 레지던시 레버 | 오픈소스 클러스터를 국내에서 돌리고 귀사가 호스팅하는 국내 사설 레지스트리(귀사 자신의 인프라 안 Harbor, Nexus, 또는 Artifactory)에서 당겨, 워크로드, 이미지, Secret을 거주시키십시오. |
문 하나 — 귀사 클러스터는 독점 코드와 Secret을 쥐고, 레지던시는 귀사가 그것을 어디서 돌리는지를 따른다
클러스터가 무엇을 쥐는지로 시작하십시오, 그것이 중국 법이 답하는 것이기 때문입니다. 공개 베이스 이미지를 당기는 것은 도달성 주제이고, 이것을 결정하는 부분이 아닙니다. 귀사 사설 이미지는 다릅니다: 컨테이너 이미지는 귀사 독점 코드를 그 레이어에 굽는 아티팩트이고, 일상적으로 빌드 구성, API 토큰, 자격증명을 끼워 넣습니다. 그것을 돌리는 클러스터는 귀사 워크로드와 — Kubernetes 자신의 표현으로 — Secret, “an object that contains a small amount of sensitive data such as a password, a token, or a key,” 의 권위 있는 저장소입니다. 그 Secret은 추상 속에 떠 있지 않습니다: 기본적으로 그것은 “stored unencrypted in the API server’s underlying data store (etcd),” 로, 클러스터가 도는 어디든 물리적으로 산다는 뜻입니다.
그것이 요점입니다. Kubernetes가 오픈소스이고 셀프호스팅이므로, 귀사가 클러스터를 어디서 돌리는지는 주어진 것이 아니라 결정입니다 — 그리고 관리형 컨트롤 플레인(EKS, AKS, 또는 GKE)은 그것을, 그리고 그 Secret 저장소를, 벤더의 해외 인프라에서 돌리는 변종입니다(어떤 본토 리전이든 가정하지 말고 벤더와 확인하십시오). 귀사가 핵심정보인프라 운영자이거나, 개인정보를 물량으로 다루면, 중국에서 수집되고 생성된 개인정보와 중요 데이터가 본토에 저장되어야 하고, 어떤 수출이든 전에 안전성 평가가 있어야 합니다 — 사이버보안법 데이터 현지화 규칙, 2026-01-01 발효된 2025년 개정으로 재번호된 제39조(구 제37조). 귀사 워크로드와 Secret을 쥐는 해외 컨트롤 플레인은 그것을 충족할 본토 발판이 없습니다.
문 둘 — 개인 데이터, 공급망 출처, 그리고 PIPL
둘째 문은 PIPL과 귀사 중국 클러스터에서 도는 것의 무결성입니다. 클러스터와 그 주변 파이프라인은 코드보다 더 실어 나릅니다: 개인 데이터가 워크로드와 퍼시스턴트 볼륨 안에, Secret 안에, 빌드·접근 메타데이터 — 누가 이미지를 푸시했고, 누가 릴리스를 배포했고, 그것을 기록하는 로그 — 안에 살 수 있습니다. 개인정보 보호법상, 그 데이터를 본토 밖 인프라에 쥐는 것은 국경 간 이전입니다(제38~40조): 처리자는 고지하고, 이전에 별도 동의를 받고, 메커니즘 하나 — CAC 안전성 평가, CAC 표준계약, 또는 인증 — 를 통과해야 합니다. 애초에 이미지와 워크로드에 들어가는 비밀과 개인 데이터를 최소화하는 것이 해결의 일부이나, 그것만으로 저장소를 옮기지 않습니다. 그리고 중국 클러스터가 레지스트리가 도는 어디서든 사설 이미지를 당기므로, 귀사 중국 배포에 들어가는 코드의 출처와 무결성도 국경 너머에서 다스려집니다 — 연결성 검사가 결코 드러내지 않는 소프트웨어 공급망 노출.
왜 도달성 검사가 이것을 놓치는가
“내 노드가 상하이에서 이미지를 당길 수 있나” 테스트는 틀린 질문에 답합니다. 레지스트리 미러나 캐시, 또는 연결성 튜닝은 이미지가 얼마나 빨리 그리고 얼마나 신뢰성 있게 당겨지는지를 바꿉니다 — 그것은 귀사 클러스터, 그 Secret, 귀사 사설 이미지가 실제로 어디에 사는지를 바꾸지 않습니다. 그래서 설정이 중국 안에서 완벽히 건강해 보이면서도 컨트롤 플레인, etcd의 모든 Secret, 모든 사설 이미지가 여전히 해외에 앉을 수 있습니다. 위의 레지던시와 국경 간 질문은 도달성 프로브에 보이지 않는데, 바로 당김이 계속 성공하기 때문입니다 — 그것이 중요한 동작이 해외 컨트롤 플레인이나 레지스트리를 그저 도달 가능하거나 미러링되게 만드는 것이 아니라 클러스터와 그 레지스트리를 국내에서 돌리는 것인 이유입니다. 저희는 중국 안에서 Kubernetes 레지스트리 연결성의 어떤 일차 측정도 공표하지 않으므로, 여기 수치를 두지 않습니다; 그것은 저희가 주장하기보다 귀사 실제 설정에 대해 측정할 것입니다.
이는 리스크 지도이지 판정이 아닙니다: 귀사가 국내 저장, 이전 메커니즘, 재작업된 동의 흐름, 어떤 공개 대상 개발자나 앱 엔드포인트를 위한 ICP 비안, 또는 그 어떤 조합이 필요한지는 귀사 워크로드, Secret, 이미지가 무엇을 싣는지, 얼마나, 누가 귀사 이용자와 기여자인지로 돕니다 — 귀사가 짓기 전에 자문과 매듭지을 가치가 있습니다.
레버 — 매핑, 현지화, 전송
Kubernetes가 오픈소스이고 셀프호스팅 가능하므로, 진정한 국내 경로가 있고, 21YunBox는 어떤 종류의 우회도 쓰거나 제안하지 않습니다.
- 매핑 — 어느 이미지가 사설인지(귀사 독점 코드), 이미지와 Secret이 자격증명, 토큰, 또는 구성을 끼워 넣는지, 클러스터 컨트롤 플레인과 그 etcd Secret 저장소가 오늘 어디서 도는지, 레지던시 근거, 그리고 귀사 중국 배포의 이미지 공급망이 어떻게 국경을 넘는지 목록화.
- 현지화 / 거버넌스 — 오픈소스 클러스터와 그 Secret 저장소를 국내에서(셀프호스팅) 돌리고, 귀사가 호스팅하는 국내 사설 레지스트리(귀사 자신의 인프라 안 Harbor, Nexus, 또는 Artifactory)에서 사설 이미지를 당겨, 독점 코드와 Secret이 거주하도록; 중국 배포의 공급망을 국내에 두고; 국경을 넘는 것을 최소화.
- 전송 — 규정에 맞는, 국내 클러스터, 사설 레지스트리, 이미지 전송을 해외 컨트롤 플레인 앞단에(또는 대신에) 두십시오; 21YunBox는 재구축 없이 국내 레이어를 세웁니다.
해외 레지스트리를 그저 도달 가능하거나 미러링되게 만드는 것은 답이 아닙니다 — 귀사 클러스터, 그 Secret, 귀사 사설 이미지가 여전히 해외이고, 그것들을 더 빨리 당긴다고 그것이 바뀌지 않습니다. 클러스터, 레지스트리, Secret을 국내에 두는 것이 답입니다.
21YunBox가 맞는 자리 — 마이그레이션이 아니라 규정에 맞는 overlay
귀사는 Kubernetes를 계속 돌립니다. 저희는 해외 컨트롤 플레인이 스스로 제공할 수 없는 조각을 더합니다: 셀프호스팅 클러스터, 그 etcd Secret 저장소, 셀프호스팅 사설 레지스트리를 위한 합법적, 국내 집, 그래서 귀사 워크로드, 독점 이미지, Secret이 법이 요구하는 곳에 거주하고, 그 앞단의 개발자 접근과 어떤 공개 대상 엔드포인트를 위한 규정에 맞는 ICP 비안 전송과 함께 — 귀사 기존 설정 둘레에 놓이고, 재구축도, 두 번째 코드베이스도, Kubernetes를 벗어나는 마이그레이션도 없이. 귀사가 이미 돌리는 툴체인에 대한 파트너로서, 저희 중국 팀이 귀사 법인과 귀사 파이프라인에 대한 귀사 PIPL 국경 간, 동의, 데이터 레지던시 의무를 매핑하고, 그런 다음 방어 가능한 중국 존재가 필요로 하는 국내 클러스터, 레지스트리, 전송을 세웁니다. 저희는 어떤 종류의 우회도 쓰거나 제안하지 않습니다.
관련 읽을거리:
자주 묻는 질문
Kubernetes는 중국에서 차단되나요?
아니요 — Kubernetes는 중국의 네트워크 필터링이 차단하는 호스팅 서비스가 아니라 귀사가 직접 돌리는 오픈소스 소프트웨어이므로, 귀사는 본토 안에 클러스터를 돌릴 수 있습니다. 하지만 도달성은 중국 대상 배포에 컴플라이언스를 결정하는 질문이 아닙니다. 그것을 결정하는 것은 클러스터, 그 Secret(패스워드, 토큰, 키), 그것이 당겨오는 사설 이미지가 실제로 어디에 사는지, 그리고 그 안의 어떤 중국 수집 개인 데이터든 국경을 넘는지입니다. 구체적인 것은 자문과 확인할 리스크로 다루십시오.
내 중국 배포에 관리형 Kubernetes(EKS, AKS, GKE)를 쓸 수 있나요?
쓸 수 있지만, 관리형 Kubernetes 서비스는 컨트롤 플레인을 벤더의 해외 인프라에서 돌리고, 귀사 사설 이미지는 보통 해외 레지스트리에서 옵니다 — 그래서 귀사 클러스터의 Secret, 워크로드 데이터, 이미지 공급망이 해외에 앉습니다. 중국 수집 개인 데이터에 그것은 PIPL 국경 간 이전이고(제38~40조), 핵심정보인프라 운영자에는 사이버보안법의 제39조(구 제37조)가 국내 저장 의무를 더합니다. 국내 경로는 오픈소스 클러스터와 사설 레지스트리를 본토 안에서 돌리는 것입니다. 각 규칙이 귀사 데이터에 적용되는지는 자문에 던질 질문입니다.
중국에서 Kubernetes를 돌리는 규정에 맞는 방법은 무엇인가요?
오픈소스 클러스터를 본토 안에서 돌리고 귀사가 호스팅하는 국내 사설 레지스트리(예를 들어 귀사 자신의 인프라 안 Harbor, Nexus, 또는 Artifactory)에서 당겨, 귀사 워크로드, Secret, 사설 이미지가 거주하도록 하고, 어떤 공개 대상 개발자나 앱 엔드포인트든 ICP 비안 국내 인프라에서 제공하십시오. 중국 배포의 이미지 공급망을 국내에 두고 국경을 넘는 것을 최소화하십시오. 21YunBox는 그 경로를 매핑하고 재구축 없이 국내 클러스터, 레지스트리, 전송을 세웁니다 — 결코 어떤 차단을 도는 경로가 아니라.
