Container & OrchestrationContainers & Orchestration

Thuộc bộ kiến thức Data Engineer Roadmap.

Tổng quan

Một data pipeline chạy hoàn hảo trên laptop rồi âm thầm fail khi lên production là một trong những sự cố phổ biến — và cũng dễ tránh nhất — trong nghề này. Thủ phạm gần như luôn là environment drift: một phiên bản Python khác, thiếu một system library mà pandas hay JDBC driver cần, một locale khiến việc parse ngày tháng ra kết quả khác, một version Spark không khớp hoàn toàn với version trên cluster. Container ra đời để loại bỏ hẳn nhóm lỗi này bằng cách đóng gói code cùng với đúng runtime nó cần, để cùng một artifact chạy không đổi từ máy developer, qua CI, đến production. Ghi chú này giả định bạn đã hiểu container là gì — namespace, cgroup, image, layer, cú pháp Dockerfile — những nội dung đó được trình bày đầy đủ trong DevOps — Containers. Nội dung ở đây bổ sung góc nhìn của data engineer về cùng công nghệ đó: phần nào trong công việc của bạn thực sự cần containerize, vì sao Kubernetes nói riêng trở thành nơi mặc định để chạy các data workload (chứ không chỉ để đóng gói chúng), và một số cách mà data workload gây áp lực lên nền tảng container khác hẳn so với một web service stateless thông thường.

Kubernetes xuất hiện trong thế giới của data engineer ở ba vai trò khác nhau, và nên tách bạch chúng ngay từ đầu. Thứ nhất, đó là nơi để chạy chính code pipeline của bạn — một script Python được containerize, một dbt project, một custom transformation job — dưới dạng một Job theo lịch hoặc một task bên trong orchestrator. Thứ hai, nó ngày càng trở thành execution engine cho chính các framework tính toán phân tán: Spark, Flink, Ray giờ đều chạy native dưới dạng Pod do Kubernetes scheduler quản lý, thay vì trên cluster manager riêng của chúng. Thứ ba, nó là nền tảng mà chính orchestrator chạy trên đó — Airflow, Dagster và các công cụ tương tự thường được deploy bên trong Kubernetes, và thậm chí có thể dùng Kubernetes làm backend thực thi task. Hiểu vai trò nào áp dụng cho vấn đề cụ thể nào là phần lớn những gì bạn cần để suy luận tốt về chủ đề này; cơ chế của bản thân Kubernetes được trình bày đầy đủ trong bộ kiến thức Kubernetes và sẽ không lặp lại ở đây.

Kiến thức nền tảng

Containerize code pipeline

Kỹ năng nền tảng khá đơn giản: lấy một transformation script, một dbt project, hoặc một ETL job nhỏ, và đóng gói nó vào một Docker image để nó mang theo đúng phiên bản interpreter, các system library (libpq, ODBC driver, libgomp cho các thư viện tính toán số), và các phiên bản package Python/R đã được pin. Ví dụ tối giản cho một Python transformation job:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
ENTRYPOINT ["python", "run_pipeline.py"]

Toàn bộ kỹ thuật viết Dockerfile tốt — multi-stage build, layer caching, non-root user, image scanning — không đặc thù cho data engineering và đã được trình bày chi tiết trong DevOps — Containers; áp dụng ở đây y hệt như với bất kỳ service nào khác. Điều đặc thù cho data pipeline là:

• Pin phiên bản data library một cách có chủ đích. Một bản nâng cấp minor version âm thầm của pandas, pyarrow, hay JDBC driver có thể thay đổi cách xử lý null, cách parse ngày tháng, hoặc độ chính xác số thực đủ để làm hỏng một aggregate ở downstream mà không hề báo lỗi. Lockfile (requirements.txt kèm hash, poetry.lock, uv.lock) phải nằm trong quá trình build image, không được resolve lúc runtime.
• Bake các native dependency nặng một lần, tái sử dụng khắp nơi. Các native stack nặng (JVM của Spark, libgdal cho geospatial, CUDA cho các ML feature pipeline) tốn kém để cài đặt; một base image dùng chung cho các job của team trả chi phí đó một lần thay vì mỗi lần cold start của từng job.
• Image là đơn vị promote, không phải code. Cùng một image đã pass test ở CI là image chạy ở staging và production — một artifact bất biến, được gắn tag, không bao giờ build lại theo từng môi trường. Đây chính là thứ thực sự loại bỏ kiểu lỗi “chạy được trên máy tôi”: một khi image đã tồn tại thì không còn “máy tôi” nào trong vòng lặp nữa.

Spark trên Kubernetes so với standalone và YARN

Trong nhiều năm, đích deploy mặc định của Apache Spark là một cluster YARN riêng (kế thừa từ hệ sinh thái Hadoop) hoặc cluster manager standalone nhẹ của chính Spark. Cả hai đều hoạt động tốt, nhưng cả hai đều nghĩa là data engineering phải sở hữu và capacity-plan một fleet máy riêng, tĩnh, chỉ để chạy Spark — được size theo tải đỉnh, phần lớn thời gian idle, và tách biệt về mặt vận hành với bất kỳ nền tảng nào đang chạy phần còn lại của các service trong tổ chức.

Chạy Spark trên Kubernetes (qua hỗ trợ có sẵn spark-submit --master k8s://..., hoặc Spark Operator nhiều tính năng hơn) thay đổi điều này theo vài cách cụ thể:

• Executor trở thành Pod. Driver xin Kubernetes scheduler cấp các executor Pod khi job cần, và giải phóng chúng khi không cần nữa — scaling co giãn được điều khiển bởi chính các primitive (requests/limits, scheduler, cluster autoscaler) vận hành mọi thứ khác trong cluster, thay vì một phân bổ tĩnh, kích thước cố định.
• Một hạ tầng cho tất cả. Nếu phần còn lại của nền tảng — service, orchestrator, ML training job — đã chạy trên Kubernetes, thì Spark-on-K8s nghĩa là một scheduler, một bộ node pool, một stack monitoring, một mô hình RBAC, và chỉ cần một team có chuyên môn vận hành Kubernetes, thay vì phải duy trì song song cả YARN lẫn Kubernetes.
• Bin-packing và chi phí. Các Spark executor Pod có thể chia sẻ node với các workload khác không liên quan (tùy vào resource requests và taint), điều mà một cluster YARN chuyên dụng không thể làm được — capacity nhàn rỗi trở thành capacity cả tổ chức có thể dùng, thay vì bị mắc kẹt trong một fleet chỉ dành riêng cho Spark.
• Đánh đổi cần biết trước. Spark chạy native trên Kubernetes vẫn còn non hơn và chưa hoàn thiện bằng YARN ở vài điểm cụ thể: dynamic allocation với true shuffle-service-backed scale-down chưa trưởng thành bằng, và chẩn đoán một job chạy chậm nghĩa là phải đối chiếu metric từ Spark UI với sự kiện Pod của Kubernetes cùng áp lực tài nguyên ở mức node — một tập hệ thống rộng hơn để suy luận so với chỉ một Resource Manager UI của YARN. Với hầu hết team đã chuẩn hóa Kubernetes cho mọi thứ khác, đây vẫn là một đánh đổi đáng giá.

Đây là một trường hợp cụ thể của một mẫu hình rộng hơn nhiều được trình bày trong Big Data & Distributed Computing: các engine tính toán phân tán ngày càng ủy quyền việc lập lịch và quản lý tài nguyên cho Kubernetes thay vì tự tái triển khai nó, giống như trước đây chúng từng ủy quyền cho YARN.

Managed Kubernetes cho nền tảng dữ liệu

Vận hành Kubernetes tốt — vá control plane, quản lý etcd, xử lý nâng cấp version — là một gánh nặng vận hành chuyên biệt, liên tục, và không liên quan gì đến bản thân data engineering. Với một team nền tảng dữ liệu, lựa chọn thực dụng mặc định là một control plane managed: Amazon EKS hoặc Google Cloud GKE (Azure AKS là tương đương trên cloud đó). Nhà cung cấp vận hành và vá control plane cùng etcd; team của bạn sở hữu node pool, workload, và các data service bạn deploy lên trên. Chế độ Autopilot của GKE đi xa hơn một bước và quản lý cả việc cấp phát node, tính phí theo Pod thay vì theo node — hấp dẫn với các team muốn có API và mô hình lập lịch của Kubernetes mà không phải sở hữu vòng đời node chút nào.

Với một team dữ liệu cụ thể, điều này quan trọng hơn so với một team backend thông thường, bởi vì mục đích của việc áp dụng Kubernetes cho data workload thường là để đưa Spark, Airflow, và các custom service lên một hạ tầng dùng chung, co giãn được — chứ không phải để trở thành một platform team Kubernetes tay ngang. Tự host Kubernetes chỉ để chạy data job nghĩa là gánh thêm cả một chuyên môn thứ hai (vận hành cluster) chồng lên chuyên môn bạn đã phải chịu trách nhiệm (dữ liệu). Cơ chế chi tiết của các dịch vụ managed, node pool, tích hợp IAM, và kiến trúc cluster nằm trong bộ kiến thức Kubernetes và Cloud Data Platform; bài học cho data engineering đơn giản là: ưu tiên control plane managed trừ khi có lý do cụ thể, được hiểu rõ để không làm vậy.

GitOps cho hạ tầng dữ liệu

Khi footprint Kubernetes của một nền tảng dữ liệu lớn lên vượt quá vài lệnh kubectl apply thủ công — bản deploy của chính Airflow, một loạt template job Spark, các custom microservice nuôi pipeline — nó cần cùng kỷ luật mà bất kỳ hạ tầng production nào khác cần: một nguồn chân lý duy nhất cho những gì nên đang chạy, và một cách tự động để đưa cluster hội tụ về đúng như vậy. Đây chính xác là những gì GitOps (Argo CD, Flux) cung cấp, và nó áp dụng cho hạ tầng dữ liệu không có ngoại lệ đặc biệt nào: Helm values của Airflow, manifest job Spark, và Deployment của các custom service đều nằm trong Git, và một agent trong cluster reconcile cluster đang chạy để khớp với đó. Cơ chế đầy đủ — Argo CD so với Flux, app-of-apps, xử lý secret, promote giữa các môi trường — được trình bày trong DevOps — GitOps và áp dụng ở đây không đổi. Điểm đặc thù cho dữ liệu đáng lưu ý: các job chạy một lần và migration (một lượt Spark backfill, một schema migration, một lượt reprocessing một lần) không khớp gọn với mô hình “reconcile mãi mãi” thuần túy, vì chúng nên chạy một lần rồi ngừng là trạng thái mong muốn — các công cụ GitOps xử lý việc này bằng sync hook hoặc bằng cách coi chúng là tài nguyên Job với điều kiện hoàn thành rõ ràng, chứ không phải như các Deployment chạy dài hạn.

Khái niệm chính

Containerize chính orchestrator: KubernetesExecutor của Airflow

Rất dễ nhầm lẫn giữa “Airflow chạy pipeline” với “Airflow chạy trên Kubernetes” — hai quyết định liên quan nhưng khác nhau, và quyết định thứ hai có những đánh đổi riêng đáng hiểu rõ (nội dung orchestrator đầy đủ nằm trong Workflow Orchestration). Bản thân Airflow có thể được deploy trên Kubernetes (qua Helm chart chính thức của cộng đồng), và độc lập với đó, nó có thể được cấu hình để thực thi task bằng một trong nhiều executor:

Executor	Task chạy như thế nào	Cách ly
SequentialExecutor	Từng task một, trong cùng process	Không có — chỉ dùng cho dev/test
LocalExecutor	Các subprocess song song trên chính máy scheduler	Tài nguyên máy dùng chung; không có giới hạn theo từng task
CeleryExecutor	Task được phân phối tới một pool cố định các Celery worker process chạy dài hạn	Worker dùng chung giữa các task; được size theo trường hợp xấu nhất
KubernetesExecutor	Mỗi task instance khởi chạy thành một Pod Kubernetes riêng, rồi Pod đó kết thúc	Cách ly hoàn toàn theo từng task: image riêng, resource requests/limits CPU/memory riêng

KubernetesExecutor phổ biến trong các nền tảng dữ liệu chính bởi vì pipeline workload không đồng nhất theo cách mà hầu hết web service không gặp phải: một task trong DAG có thể là một cuộc gọi poll API nhẹ chỉ cần 100Mi bộ nhớ, và task tiếp theo trong cùng DAG đó có thể là một job pandas load một dataframe nhiều gigabyte cần đến 16Gi. Pool worker cố định của CeleryExecutor phải được size theo task lớn nhất mà bất kỳ DAG nào có thể từng chạy, lãng phí capacity ở mọi task nhỏ hơn; KubernetesExecutor thay vào đó yêu cầu đúng lượng tài nguyên mỗi task khai báo, được lập lịch độc lập, và scale node pool bên dưới (qua cluster autoscaler hoặc Karpenter) theo đúng nhu cầu thực tế của từng task thay vì một pool cố định theo trường hợp xấu nhất. Cái giá phải trả là độ trễ khởi động Pod cho từng task (thường vài giây) và việc pull image cho mỗi task trừ khi node đã được làm ấm sẵn — một đánh đổi thực sự so với việc Celery nhận task gần như tức thì trên một worker đã chạy sẵn, đó là lý do một số team chạy hybrid: KubernetesExecutor cho các job nặng, bất thường và một pool Celery nhỏ cho các task nhẹ, tần suất cao.

Resource requests và limits cho data workload

Việc tinh chỉnh resource Kubernetes cho một web API stateless và cho một job Spark hay một tác vụ batch dựa trên pandas trông chẳng giống nhau chút nào, và đối xử với chúng như nhau là một nguồn sự cố production phổ biến:

Khía cạnh	Web service điển hình	Data workload (Spark executor / job pandas)
Hồ sơ bộ nhớ	Bằng phẳng, dễ đoán, nhỏ (vài trăm MB)	Nhảy vọt, lớn, khó đoán — có thể tăng vài GB giữa chừng khi một shuffle hoặc một groupby materialize
Hồ sơ CPU	Ổn định, theo request	Bùng nổ từng đợt — gần như bằng 0 khi chờ I/O, rồi kịch trần khi shuffle hoặc ở giai đoạn tính toán nặng
Hệ quả khi cấp thiếu	Phản hồi chậm, có thể bị throttle	OOMKilled — container bị kill thẳng, không phải throttle, và cả task (có thể hàng giờ công việc) bị mất
Cách right-size	Metric ở trạng thái ổn định qua nhiều ngày/tuần	Profile chính job cụ thể (metric executor từ Spark UI, memory profiling của pandas) — nhu cầu bộ nhớ của job này hiếm khi áp dụng chung cho job khác
Chi phí restart	Rẻ — vài giây, không mất state	Đắt — một Spark executor bị kill kích hoạt tính toán lại task; một batch job bị kill có thể phải chạy lại từ checkpoint gần nhất hoặc từ đầu

Hệ quả thực tế: đặt memory limit hào phóng và dựa trên profiling thực tế, không phải đoán mò, bởi vì một data workload chạm memory limit không suy giảm nhẹ nhàng — OOM killer của kernel kill thẳng container (hiển thị dưới dạng OOMKilled trong kubectl describe pod), và tùy framework, điều đó có thể âm thầm retry, âm thầm drop kết quả một phần, hoặc fail cả job. Riêng với Spark, nhớ rằng memory limit của một Pod phải tính đến nhiều hơn heap của JVM: bộ nhớ off-heap, overhead của chính JVM, và (quan trọng) bất kỳ UDF Python hay workload pandas-on-Spark nào chạy trong một process Python riêng biệt song song với JVM đều tính vào tổng memory limit của container — size container chỉ theo spark.executor.memory và quên mất spark.executor.memoryOverhead là một trong những nguyên nhân phổ biến nhất khiến Spark executor bị OOMKilled trên Kubernetes.

Ephemeral storage cho các tập dữ liệu trung gian lớn

Web service hiếm khi ghi một lượng dữ liệu đáng kể xuống đĩa cục bộ; data workload thì làm việc đó liên tục. Một shuffle của Spark spill dữ liệu trung gian xuống đĩa cục bộ khi không vừa bộ nhớ; một job pandas hay Polars đọc một file lớn có thể materialize các file Parquet hoặc CSV tạm thời; một lượt chạy dbt có thể stage các bảng trung gian. Trên Kubernetes, không gian scratch cục bộ này là ephemeral storage — hệ thống file ghi được của container cộng với bất kỳ volume emptyDir nào — và đó là một tài nguyên phải được request và limit y hệt như CPU và memory:

resources:
  requests:
    memory: "8Gi"
    cpu: "2"
    ephemeral-storage: "20Gi"
  limits:
    memory: "10Gi"
    cpu: "4"
    ephemeral-storage: "40Gi"
volumes:
  - name: scratch
    emptyDir:
      sizeLimit: 40Gi

Nếu không có request và limit tường minh, một Spark job nặng shuffle hoặc một lượt ghi trung gian lớn có thể âm thầm lấp đầy đĩa của một node, lúc đó kubelet bắt đầu evict Pod — kể cả các Pod không liên quan gì đến Pod gây ra vấn đề — để giải phóng không gian, đây là một kiểu lỗi ồn ào và khó chẩn đoán hơn nhiều so với một OOMKill thông thường. Hãy mount volume scratch emptyDir với sizeLimit tường minh, ưu tiên các node có NVMe cục bộ nhanh cho các job Spark nặng shuffle khi nhà cung cấp cloud có hỗ trợ, và giám sát mức dùng ephemeral storage nghiêm túc như với memory — đây là chiều tài nguyên mà data workload dễ dùng cạn nhất trong khi web service hầu như không bao giờ nghĩ tới.

Tóm tắt: điều gì khác biệt khi data workload chạy trên container/Kubernetes

Mối quan tâm	Cân nhắc đặc thù cho data engineering	Đi sâu hơn
Đóng gói code pipeline	Pin phiên bản data library chính xác; bake các native dependency nặng (JVM Spark, GDAL, CUDA) vào base image dùng chung	DevOps — Containers
Lập lịch tính toán	Spark/Flink/Ray chạy như Pod native của Kubernetes thay vì trên YARN/standalone — executor co giãn, một hạ tầng dùng chung	Big Data & Distributed Computing
Vận hành control plane	Ưu tiên EKS/GKE managed thay vì tự host Kubernetes — đừng gánh vận hành cluster chỉ để chạy data job	Bộ kiến thức Kubernetes, Cloud Data Platform
Deploy khai báo	Airflow, template job Spark, và custom service được quản lý qua Git + Argo CD/Flux, với sync hook cho job chạy một lần	DevOps — GitOps
Cách ly thực thi task	KubernetesExecutor của Airflow: một Pod cho mỗi task để đáp ứng nhu cầu memory/CPU không đồng nhất, so với pool worker Celery cố định	Workflow Orchestration
Size bộ nhớ	Requests/limits dựa trên profiling thực tế, không phải mặc định kiểu web service; tính cả overhead memory của Spark, không chỉ heap	DevOps — Container Orchestration
Dùng đĩa cục bộ	Request/limit ephemeral-storage; giới hạn emptyDir bằng sizeLimit để tránh eviction Pod toàn node do shuffle spill	DevOps — Container Orchestration

Best Practices

1. Coi image container là đơn vị promote. Build một lần ở CI, gắn tag bất biến, và chạy đúng image đó ở staging lẫn production — không bao giờ build lại theo từng môi trường, và không bao giờ vá tay một container đang chạy.
2. Pin phiên bản data library và native dependency trong image, không phải lúc runtime. Một sự trôi phiên bản âm thầm của pandas/pyarrow/JDBC driver là một kiểu lỗi tinh vi và nguy hiểm hơn việc thiếu hẳn một package.
3. Chọn Spark-on-Kubernetes khi bạn đã native Kubernetes ở những nơi khác, và giữ đánh đổi trung thực: nó mang lại scaling co giãn và một nền tảng dùng chung, đổi lại một câu chuyện dynamic allocation kém trưởng thành hơn YARN đôi chút.
4. Mặc định dùng control plane managed (EKS/GKE) cho hạ tầng dữ liệu — lợi ích vận hành của việc tự host Kubernetes gần như không bao giờ xứng đáng với chuyên môn nó đòi hỏi từ một team dữ liệu.
5. Đặt bản deploy của chính Airflow, manifest job Spark, và custom service dưới GitOps — một nguồn chân lý duy nhất được reconcile trong Git có giá trị với hạ tầng dữ liệu không kém gì với bất kỳ hệ thống production nào khác.
6. Chọn KubernetesExecutor của Airflow khi nhu cầu tài nguyên của các task không đồng nhất — task Spark/pandas nặng nằm cạnh các task nhẹ — và chấp nhận chi phí khởi động Pod theo từng task như cái giá của sự cách ly thật sự.
7. Size memory limit dựa trên profiling thực tế, không phải mặc định copy từ web service — workload Spark và pandas nhảy vọt khó đoán, và chạm memory limit nghĩa là OOMKill thẳng, không phải throttle nhẹ nhàng.
8. Luôn tính đến bộ nhớ off-heap và process Python của Spark, không chỉ executor.memory, khi đặt memory limit của Pod — sơ suất duy nhất này là nguyên nhân phổ biến nhất khiến Spark executor bị OOMKilled trên Kubernetes.
9. Request và limit ephemeral-storage tường minh, và giới hạn volume scratch emptyDir bằng sizeLimit — dùng đĩa cục bộ không giới hạn từ shuffle hoặc file trung gian dẫn đến eviction Pod toàn node, chứ không chỉ làm fail một job gây ra nó.
10. Tách các job chạy một lần (backfill, migration) khỏi các Deployment ổn định trong mô hình GitOps của bạn — dùng tài nguyên Job với sync hook thay vì ép chúng vào tư duy “luôn luôn reconcile” vốn chỉ phù hợp với các service chạy dài hạn.

Tài liệu tham khảo

• DevOps — Containers
• DevOps — Container Orchestration (Kubernetes)
• Bộ kiến thức Kubernetes
• DevOps — GitOps
• Big Data & Distributed Computing
• Cloud Data Platform
• Apache Spark — Running on Kubernetes
• Kubeflow Spark Operator
• Apache Airflow — Kubernetes Executor
• Apache Airflow Helm Chart
• Kubernetes — Managing Resources for Containers
• roadmap.sh — Data Engineer

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
ENTRYPOINT ["python", "run_pipeline.py"]

resources:
  requests:
    memory: "8Gi"
    cpu: "2"
    ephemeral-storage: "20Gi"
  limits:
    memory: "10Gi"
    cpu: "4"
    ephemeral-storage: "40Gi"
volumes:
  - name: scratch
    emptyDir:
      sizeLimit: 40Gi