Node-Level Isolation

Tại sao cần cách ly ở lớp node

Các file trước cô lập ở lớp logic (namespace, RBAC, mạng) và lớp kernel (gVisor). Nhưng có những yêu cầu mà chỉ cách ly ở lớp node mới đáp ứng được:

1. Compliance bắt buộc hardware isolation. PCI-DSS, HIPAA, một số quy định chính phủ yêu cầu workload xử lý dữ liệu nhạy cảm chạy trên phần cứng không chia sẻ với workload khác — không đủ nếu chỉ chia sẻ node với container isolation.

2. License ràng buộc theo phần cứng. Một số phần mềm thương mại (Oracle, SQL Server, một số BYOL) tính phí theo physical core/socket. Chạy trên node chia sẻ vi phạm license hoặc khiến chi phí license không kiểm soát được.

3. Workload đặc thù hardware. GPU/TPU, local SSD, machine type đặc biệt cần node pool riêng vì không phải mọi node đều có.

4. Tách biệt hiệu năng/blast radius giữa team. Đảm bảo workload của team A không bao giờ chia sẻ node với team B — để noisy neighbor ở mức kernel/hardware không xảy ra, hoặc để một node bị xâm phạm không phơi bày nhiều tenant.

GKE cung cấp hai cấp độ: dedicated node pools (taint/toleration — cách ly logic ở mức node, dùng cho team tin cậy) và sole-tenant nodes (cách ly vật lý — server riêng, dùng cho compliance).

Dedicated node pools với taint/toleration

Internal model

Node pool là một nhóm node cùng cấu hình trong cluster. Bạn có thể tạo node pool riêng cho từng team/workload và dùng taint để "đẩy lùi" Pod không thuộc về, toleration để cho phép Pod đúng vào, và nodeSelector/nodeAffinity để "kéo" Pod vào đúng pool.

gcloud container node-pools create team-payments-pool \
  --cluster=my-cluster \
  --region=us-central1 \
  --node-taints=team=payments:NoSchedule \
  --node-labels=team=payments \
  --machine-type=n2-standard-8 \
  --num-nodes=3

Pod của team payments khai báo toleration + nodeSelector để chạy đúng pool:

spec:
  nodeSelector:
    team: payments
  tolerations:
  - key: team
    operator: Equal
    value: payments
    effect: NoSchedule

Cơ chế ba phần:

• Taint trên node: đẩy lùi mọi Pod không có toleration tương ứng → Pod team khác không vào.
• Toleration trên Pod: cho phép Pod payments được schedule lên node taint đó.
• nodeSelector: buộc Pod payments chỉ chạy trên node có label team=payments → không "lạc" sang pool khác.

⚠️ Cảnh báo bảo mật quan trọng

Đây là điểm sống còn, lặp lại từ file 01: theo tài liệu GKE, taint và anti-affinity có thể bị bỏ qua bởi tenant độc hại. Một tenant có quyền tạo Pod chỉ cần thêm toleration tương ứng vào Pod của họ để "lẻn" vào node pool của team khác.

→ Dedicated node pool qua taint/toleration là cơ chế cho team TIN CẬY, để tổ chức và tránh noisy neighbor vô tình — KHÔNG phải security boundary chống tenant độc hại. Để biến nó thành ràng buộc bảo mật, cần thêm admission policy (Policy Controller/Kyverno) chặn tenant khác đặt toleration đó. Với untrusted thực sự, dùng cluster riêng hoặc sole-tenant.

Sole-tenant nodes: hardware isolation

Internal model

Theo tài liệu sole-tenancy, sole-tenant nodes là "các server vật lý chuyên dụng chỉ chạy VM của một project cụ thể". Khác biệt cốt lõi với node thường: node thường (GCE VM) có thể chia sẻ host vật lý với VM của project/khách hàng khác của Google; sole-tenant node độc chiếm toàn bộ server vật lý — không có VM nào khác (kể cả của tổ chức khác) chạy trên phần cứng đó.

Đây là khác biệt quyết định cho compliance: dữ liệu của bạn chạy trên silicon không chia sẻ với bất kỳ ai ngoài tổ chức bạn.

Cấu hình trên GKE

Sole-tenancy được cấu hình qua node template và node group ở cấp Compute Engine, rồi node pool GKE tham chiếu qua node affinity:

# 1. Tạo node template (Compute Engine)
gcloud compute sole-tenancy node-templates create my-node-template \
  --node-type=n2-node-80-640 \
  --node-affinity-labels=workload=pci \
  --region=us-central1

# 2. Tạo node group từ template (trong từng zone)
gcloud compute sole-tenancy node-groups create my-node-group \
  --node-template=my-node-template \
  --target-size=3 \
  --zone=us-central1-a

Node pool GKE dùng affinity file để ghim lên sole-tenant node group:

[
  {
    "key": "compute.googleapis.com/node-group-name",
    "operator": "IN",
    "values": ["my-node-group"]
  }
]

gcloud container node-pools create pci-pool \
  --cluster=my-cluster \
  --node-group=my-node-group \
  --sole-tenant-node-affinity-file=/path/to/affinity.json \
  ...

Shared sole-tenant nodes (cross-project)

Tổ chức có thể chỉ định một "owner project" tạo node group, các "consumer project" khác trong tổ chức truy cập chúng — chia sẻ phần cứng dành riêng trong nội bộ tổ chức (vẫn không chia sẻ với tổ chức khác).

CPU overcommit

Tùy chọn cho phép oversubscribe CPU trên sole-tenant node (vì bạn sở hữu toàn bộ server). Bật --cpu-overcommit-type=enabled khi tạo template, đặt min vCPU qua --sole-tenant-min-node-cpus. Yêu cầu GKE 1.33.1-gke.1545000+. Hữu ích để tận dụng phần cứng đắt tiền hơn.

Giới hạn quan trọng

Theo tài liệu:

• Cluster autoscaling bị giới hạn bởi capacity của node group — không tự mở rộng vượt server đã provision.
• Không dùng được node auto-provisioning (NAP) khi dùng sole-tenant nodes.
• Node upgrade cần đủ capacity dự phòng trong node group (surge upgrade cần slot trống).
• Cần xin tăng quota Compute Engine CPU trước — sole-tenant tốn nhiều tài nguyên, "yêu cầu có thể mất tới 48 giờ".

Các giới hạn này nghĩa là sole-tenant đánh đổi tính đàn hồi (elasticity) lấy isolation. Bạn quay lại mô hình capacity planning thủ công gần giống on-prem.

Use cases: HIPAA / PCI / license

HIPAA / PCI compliance

Quy định yêu cầu cách ly workload xử lý PHI (HIPAA) hoặc cardholder data (PCI-DSS) khỏi workload khác ở mức phần cứng. Sole-tenant đáp ứng yêu cầu "dedicated physical infrastructure". Kết hợp: namespace PCI riêng + restricted PSA + default-deny NetworkPolicy + sole-tenant node pool + audit logging riêng = một enclave compliance trong cluster lớn hơn.

License-bound (BYOL)

Phần mềm tính phí theo physical core. Sole-tenant cho bạn --node-type cố định với số core biết trước, đảm bảo workload chỉ chạy trên phần cứng đó — đáp ứng license và kiểm soát chi phí license. Node affinity buộc binding ổn định giữa workload và phần cứng cụ thể.

Production architecture patterns

Pattern 1: Compliance enclave trong cluster chung

Phần lớn workload chạy trên node pool thường (cost-efficient). Workload in-scope compliance chạy trên sole-tenant node pool với taint compliance=pci:NoSchedule + nodeSelector + admission policy chặn Pod ngoài namespace PCI đặt toleration đó. Cách ly vật lý cho phần cần, chia sẻ cho phần còn lại.

Pattern 2: Team separation cho trusted internal (chỉ taint)

Mỗi team lớn có node pool riêng qua taint/toleration để tránh noisy neighbor ở mức node và đơn giản hóa cost attribution (file 09). Vì team tin cậy, không cần sole-tenant — taint đủ cho mục đích tổ chức.

Real-world scenario

Bệnh viện chạy GKE với workload HIPAA: Cluster phục vụ cả workload nội bộ thường (lịch hẹn, billing) và workload xử lý hồ sơ bệnh án điện tử (PHI — thuộc HIPAA). Workload PHI chạy trong namespace phi-workloads trên một sole-tenant node pool (server vật lý riêng, không chia sẻ với bất kỳ tổ chức nào khác của Google), với restricted PSA, default-deny NetworkPolicy chỉ cho phép gọi database PHI qua Private Service Connect, và Cloud Audit Logs ghi mọi truy cập. Admission policy chặn Pod ngoài namespace phi-workloads đặt toleration của node pool đó. Sole-tenant đáp ứng yêu cầu cách ly vật lý của HIPAA; các lớp khác cung cấp defense-in-depth.

Common mistakes / anti-patterns

Anti-pattern 1: Taint như security boundary cho untrusted

Vì sao xảy ra: Nhầm taint (scheduling) với access control (đã giải thích ở file 01).

Hệ quả ở scale: Tenant độc hại thêm toleration và lẻn vào node "riêng", phá vỡ cách ly tưởng có. Trong compliance scope, điều này có thể là vi phạm nghiêm trọng.

Cách phòng tránh: Với untrusted/compliance, dùng sole-tenant (hardware) + admission policy chặn toleration trái phép, hoặc cluster riêng. Taint một mình chỉ cho trusted.

Anti-pattern 2: Sole-tenant cho mọi thứ (lãng phí)

Vì sao xảy ra: Áp sole-tenant rộng rãi "cho an toàn".

Hệ quả ở scale: Mất tính đàn hồi (không autoscale/NAP), capacity planning thủ công, chi phí cao (trả cho cả server dù dùng một phần), upgrade phức tạp. Lãng phí lớn nếu workload không thực sự cần hardware isolation.

Cách phòng tránh: Dùng sole-tenant chỉ cho workload có yêu cầu compliance/license cụ thể. Phần còn lại dùng node pool thường.

Anti-pattern 3: Quên capacity dự phòng cho upgrade trên sole-tenant

Vì sao xảy ra: Provision sole-tenant node group vừa khít với nhu cầu.

Hệ quả ở scale: Surge upgrade cần slot trống để tạo node mới trước khi drain node cũ; không đủ capacity → upgrade kẹt hoặc gây downtime. Khác với node pool thường tự mở rộng.

Cách phòng tránh: Provision node group với buffer cho surge upgrade. Lên kế hoạch capacity như on-prem.

Anti-pattern 4: Quên rằng NAP không hoạt động với sole-tenant

Vì sao xảy ra: Kỳ vọng node auto-provisioning tự tạo capacity.

Hệ quả ở scale: Pod pending vì không có NAP và node group đã đầy; không có cơ chế tự mở rộng. Bất ngờ trong sự cố tải cao.

Cách phòng tránh: Hiểu rằng sole-tenant tắt NAP. Giám sát capacity node group chủ động, mở rộng thủ công hoặc qua tự động hóa riêng.

References

• Sole-tenant nodes on GKE
• Sole-tenant nodes (Compute Engine)
• Isolate workloads in dedicated node pools
• Taints and Tolerations (Kubernetes)
• GKE Multi-Tenancy Overview