Pod Disruption Budget là gì? Cách xác định Pod Disruption Budget cho ứng dụng

Pod Disruption Budget là một cơ chế trong Kubernetes, được sử dụng để giới hạn số lượng Pod của một ứng dụng có thể bị gián đoạn cùng một thời điểm trong các hoạt động tự nguyện như drain node, nâng cấp cluster, hoặc bảo trì hạ tầng. Trong bài viết này, mình sẽ giúp bạn hiểu rõ hơn về cách thức hoạt động của Pod Disruption Budget cũng như hướng dẫn quy trình tạo và quản lý PDB hiệu quả.

Những điểm chính

• Khái niệm: Hiểu rõ Pod Disruption Budget (PDB) là một đối tượng API Kubernetes, giúp bạn nhận biết vai trò của nó trong việc duy trì tính sẵn sàng của ứng dụng trong các đợt gián đoạn có kế hoạch.
• Cơ chế hoạt động: Nắm được cách PDB kiểm soát API Eviction, hệ thống sẽ từ chối việc tắt Pod nếu hành động đó làm số lượng Pod đang chạy vi phạm ngưỡng an toàn đã thiết lập.
• Tham số cấu hình cốt lõi: Biết rõ vai trò của Label Selector, minAvailable và maxUnavailable, cùng lưu ý chỉ được dùng một trong hai tham số này.
• Lợi ích chính: Hiểu được lợi ích của PDB trong việc đảm bảo tính sẵn sàng cao, giảm thiểu downtime, hỗ trợ bảo trì an toàn và phân tách rõ ràng trách nhiệm giữa team Dev và Ops.
• Quy trình triển khai: Nắm vững 4 bước thực hiện từ việc xác định nhu cầu, viết file YAML, khởi tạo bằng lệnh kubectl apply đến việc kiểm tra trạng thái bằng kubectl get pdb.
• Trường hợp sử dụng: Nhận biết các kịch bản cần dùng PDB như ứng dụng yêu cầu HA, hệ thống Microservices nhiều Replica, các ứng dụng Stateful hoặc trước khi thực hiện gián đoạn tự nguyện trên cluster.
• Nguyên tắc tối ưu: Bỏ túi các kinh nghiệm thực tế như luôn dùng PDB cho workload quan trọng Production, đồng bộ với mục tiêu SLOs và phải kiểm thử kỹ lưỡng trước khi triển khai chính thức.
• Giới thiệu Vietnix: Biết đến Vietnix là nhà cung cấp Cloud Server mạnh mẽ, giúp bạn có một nền tảng hạ tầng đáng tin cậy để triển khai các giải pháp Kubernetes.
• Câu hỏi thường gặp: Giải đáp các thắc mắc liên quan đến Pod Disruption Budget.

Pod Disruption Budget là gì?

Pod Disruption Budget (PDB) là một cơ chế bảo vệ ứng dụng của Kubernetes cho phép quản trị viên định nghĩa số lượng hoặc tỷ lệ phần trăm Pod tối thiểu phải luôn ở trạng thái hoạt động trong một thời điểm nhất định. Khi khai báo PDB, người vận hành xác định số Pod tối thiểu phải luôn sẵn sàng (minAvailable) hoặc số Pod tối đa được phép ngừng hoạt động (maxUnavailable), dựa trên nhu cầu khả dụng của ứng dụng.

Cơ chế này giúp cluster vẫn thực hiện được các thao tác tự nguyện như drain node, nâng cấp, bảo trì hay thay đổi cấu hình mà không làm giảm số Pod đang chạy xuống dưới ngưỡng cho phép, từ đó hạn chế downtime và duy trì tính liên tục của dịch vụ trong các kịch bản gián đoạn có kiểm soát.

Cơ chế hoạt động của Pod Disruption Budget

Cơ chế hoạt động của PDB xoay quanh việc kiểm soát API Eviction (API trục xuất Pod) của Kubernetes thông qua hai tham số chính: minAvailable (số lượng tối thiểu sẵn sàng) và maxUnavailable (số lượng tối đa không sẵn sàng).

• Khi có yêu cầu bảo trì: Khi quản trị viên hoặc một tiến trình tự động muốn gỡ bỏ một Node, Kubernetes sẽ gọi API Eviction để tắt các Pod đang chạy trên Node đó.
• Kiểm tra điều kiện: Trước khi tắt Pod, API Eviction sẽ đối chiếu với cấu hình PDB đã được gắn cho ứng dụng.
• Ra quyết định: Nếu việc tắt Pod khiến số lượng Pod đang chạy rơi xuống dưới mức minAvailable (hoặc vượt mức maxUnavailable), Kubernetes sẽ từ chối yêu cầu trục xuất đó. Quá trình bảo trì sẽ phải chờ đợi cho đến khi có các Pod mới được tạo ra ở các Node khác để bù đắp, đảm bảo PDB luôn được thỏa mãn.
• Chỉ bảo vệ trước các gián đoạn có chủ đích: PDB giúp kiểm soát các tác vụ như nâng cấp Node, di dời Pod. Tuy nhiên, cơ chế này không thể bảo vệ ứng dụng khỏi các sự cố ngoài ý muốn như lỗi phần cứng, sự cố hệ điều hành hoặc ứng dụng bị crash.

Label Selector (.spec.selector)

Label Selector là thuộc tính dùng để xác định chính xác nhóm Pod nào trong hệ thống sẽ được bảo vệ bởi cấu hình PDB này. Bạn phải sử dụng các nhãn khớp với nhãn đang được định nghĩa trong Deployment hoặc StatefulSet. Một lưu ý nâng cao cực kỳ quan trọng là sự khác biệt khi sử dụng Empty Selector (selector rỗng). Trong phiên bản API cũ policy/v1beta1, selector rỗng sẽ không khớp với bất kỳ Pod nào. Tuy nhiên, ở phiên bản API mới policy/v1, một selector rỗng sẽ tự động khớp với toàn bộ các Pod đang tồn tại trong namespace đó.

minAvailable

Thuộc tính minAvailable cho phép bạn chỉ định số lượng Pod tối thiểu bắt buộc phải duy trì trạng thái hoạt động và khỏe mạnh trong suốt quá trình xảy ra gián đoạn. Bạn có thể định nghĩa giá trị này bằng một số nguyên hoặc một tỷ lệ phần trăm (%). Ví dụ thực tế: Nếu ứng dụng của bạn có tổng cộng 5 Pod và bạn cấu hình minAvailable: 3, Kubernetes sẽ chỉ cho phép trục xuất tối đa 2 Pod tại cùng một thời điểm để luôn đảm bảo có 3 Pod đang phục vụ người dùng.

maxUnavailable

Thuộc tính maxUnavailable quy định số lượng Pod tối đa được phép ngừng hoạt động hoặc bị trục xuất cùng lúc. Tương tự như thuộc tính trên, bạn có thể thiết lập bằng số nguyên hoặc tỷ lệ phần trăm. Các chuyên gia Kubernetes khuyến nghị sử dụng maxUnavailable thay vì minAvailable vì tính linh hoạt tuyệt vời của nó khi kết hợp với hệ thống tự động mở rộng. Khi ứng dụng tự động tăng số lượng Pod lên, việc dùng phần trăm cho maxUnavailable sẽ giúp hệ thống tự động điều chỉnh số lượng Pod được phép gián đoạn mà không cần bạn phải sửa lại file cấu hình.

Logic làm tròn của Kubernetes

Khi bạn cấu hình PDB bằng tỷ lệ phần trăm, hệ thống Kubernetes sẽ tự động tính toán và áp dụng logic làm tròn để đảm bảo an toàn tối đa cho ứng dụng. Ví dụ: Nếu bạn có 7 Pod và cấu hình minAvailable là 50%, 50% của 7 là 3.5; lúc này Kubernetes sẽ làm tròn lên thành 4 Pod để đảm bảo tính sẵn sàng.

Một lưu ý là bạn chỉ được phép sử dụng một trong hai thuộc tính (minAvailable HOẶC maxUnavailable) trong cùng một file cấu hình PDB. Ngoài ra, bạn tuyệt đối không nên thiết lập chặn hoàn toàn mọi gián đoạn (ví dụ cấu hình maxUnavailable: 0 hoặc minAvailable: 100%) nếu bạn không có kế hoạch can thiệp thủ công, vì điều này sẽ khiến hệ thống không thể thực hiện lệnh drain node.

Lợi ích của việc sử dụng Pod Disruption Budget

Pod Disruption Budget không chỉ là một cấu hình kỹ thuật mà còn là công cụ quan trọng trong chiến lược đảm bảo tính sẵn sàng và ổn định cho các ứng dụng chạy trên Kubernetes.

• Đảm bảo tính sẵn sàng cao: PDB đảm bảo một số lượng Pod tối thiểu vẫn hoạt động trong các hoạt động như drain node, nâng cấp cluster, cập nhật Deployment hoặc scale hạ tầng. Nhờ đó, dịch vụ vẫn phục vụ được lưu lượng trong khi cluster được bảo trì, tránh tình trạng toàn bộ replicas của ứng dụng dừng cùng lúc.
• Giảm nguy cơ outage và suy giảm chất lượng dịch vụ: Bằng cách giới hạn số Pod được phép bị gián đoạn đồng thời, PDB giúp ngăn chặn tình huống gián đoạn vượt quá ngưỡng chịu đựng của ứng dụng dẫn đến downtime.
• Hỗ trợ quá trình bảo trì an toàn: Quản trị viên hệ thống có thể tự tin nâng cấp phiên bản Kubernetes, bảo trì máy chủ vật lý hoặc thay đổi cấu hình Node mà không sợ làm gián đoạn dịch vụ của khách hàng.
• Phân tách trách nhiệm hiệu quả: Đội ngũ phát triển (Dev) có thể tự định nghĩa khả năng chịu đựng gián đoạn của ứng dụng, trong khi đó đội ngũ vận hành (Ops) vẫn chủ động tự động hóa các tác vụ bảo trì mà không cần giao tiếp thủ công.

Bước 1: Xác định nhu cầu và phạm vi áp dụng PDB

Trước tiên, bạn cần đánh giá mức độ sẵn sàng mà ứng dụng phải duy trì trong các đợt gián đoạn, từ đó xác định số Pod tối thiểu cần hoạt động hoặc số Pod tối đa có thể tạm thời ngừng. Đồng thời, phải xác định rõ workload mục tiêu (Deployment, StatefulSet, ReplicaSet…) và bộ label dùng để chọn đúng tập Pod sẽ được PDB bảo vệ. Việc xác định đúng nhu cầu và selector là cơ sở để PDB phản ánh chính xác đặc thù hoạt động của ứng dụng.

Bước 2: Viết file YAML cấu hình

Sau khi xác định nhu cầu, bạn cần tạo manifest PDB dưới dạng YAML với các trường chính .spec.selector, .spec.minAvailable hoặc .spec.maxUnavailable (chỉ sử dụng một trong hai). Selector trong PDB phải trùng với label của workload để PDB áp dụng đúng nhóm Pod cần bảo vệ, còn giá trị minAvailable hoặc maxUnavailable có thể khai báo dạng số tuyệt đối hoặc phần trăm. Manifest này là định nghĩa chuẩn được dùng để tạo mới, cập nhật và quản lý PDB xuyên suốt vòng đời ứng dụng.

Mẫu YAML sử dụng minAvailable:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: default
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

Mẫu YAML sử dụng maxUnavailable:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: default
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: my-app

Bước 3: Khởi tạo PDB

Sau khi đã lưu file YAML, bạn áp dụng cấu hình này vào Kubernetes cluster bằng cách chạy lệnh sau trong terminal:

kubectl apply -f mypdb.yaml

Bước 4: Kiểm tra và giám sát trạng thái

Để xem số Pod mong đợi, số Pod hiện có và mức độ sẵn sàng thực tế, bạn chạy các lệnh:

kubectl get pdb
kubectl describe pdb <tên-pdb>

Hệ thống sẽ trả về một bảng với các thông số quan trọng. Ý nghĩa của chúng như sau:

• MIN AVAILABLE / MAX UNAVAILABLE: Cho biết quy tắc giới hạn mà bạn đã cấu hình trong file YAML.
• ALLOWED DISRUPTIONS: Đây là thông số quan trọng nhất. Nếu giá trị này > 0, điều đó có nghĩa là hệ thống hiện đang an toàn và cho phép trục xuất thêm Pod. Nếu giá trị bằng 0, hệ thống sẽ từ chối mọi lệnh trục xuất Pod.

Để xem chi tiết hơn về các sự kiện và trạng thái của một PDB cụ thể, bạn có thể chạy lệnh:

kubectl get poddisruptionbudgets my-app-pdb -o yaml

Khi nhu cầu khả dụng thay đổi (scale replicas, đổi kiến trúc, chuyển traffic,…), cần điều chỉnh PDB bằng cách cập nhật YAML và apply lại hoặc xoá PDB nếu không còn phù hợp, nhằm đảm bảo PDB luôn phản ánh đúng trạng thái vận hành của ứng dụng.

Khi nào nên sử dụng Pod Disruption Budget?

Pod Disruption Budget phù hợp cho các ứng dụng cần duy trì mức độ sẵn sàng tối thiểu trong khi cluster vẫn phải thực hiện các hoạt động bảo trì, nâng cấp hoặc thay đổi cấu hình định kỳ.

• Ứng dụng yêu cầu tính sẵn sàng cao (HA): Sử dụng PDB cho các dịch vụ backend, API, hệ thống xử lý giao dịch hoặc bất kỳ workload nào cần luôn duy trì một số lượng Pod tối thiểu để đáp ứng SLO về uptime. Trong các kịch bản này, PDB giúp giới hạn số Pod được phép gián đoạn cùng lúc, giảm nguy cơ downtime trong quá trình bảo trì cluster.
• Khi thực hiện các gián đoạn tự nguyện trên cluster: Nên cấu hình PDB trước khi thực hiện các thao tác như drain node, nâng cấp node, nâng cấp control plane, cập nhật Deployment hoặc autoscaling hạ tầng. PDB đảm bảo các hoạt động tự nguyện này không làm số Pod đang chạy giảm xuống dưới ngưỡng chịu đựng mà ứng dụng đã được thiết kế.
• Hệ thống Microservices/Ứng dụng nhiều Replica: PDB giới hạn số Pod bị dừng cùng lúc, đảm bảo các service luôn có đủ năng lực xử lý lượng truy cập từ người dùng, tránh tình trạng quá tải cục bộ.
• Các ứng dụng Stateful: Đối với các hệ thống phân tán như ZooKeeper, Consul hoặc Database Cluster, PDB giữ cho số lượng node không bao giờ giảm xuống dưới mức “quorum” (số lượng tối thiểu để duy trì đồng thuận), giúp ngăn chặn lỗi ghi dữ liệu hoặc lỗi đồng bộ.

Các thực hành tốt nhất khi dùng PDB

Dưới đây là các nguyên tắc cốt lõi bạn cần tuân thủ để tối ưu hóa PDB:

• Sử dụng cho tất cả các Workload quan trọng: PDB là yếu tố thiết yếu để duy trì tính sẵn sàng cao. Bạn hãy đảm bảo mọi ứng dụng cốt lõi trong môi trường Production đều được gắn cấu hình PDB.
• Đồng bộ với các mục tiêu dịch vụ: Bạn nên thiết lập giá trị minAvailable hoặc maxUnavailable dựa trên các yêu cầu cụ thể về tính sẵn sàng và Mục tiêu cấp độ dịch vụ (SLOs) mà doanh nghiệp đã cam kết với khách hàng.
• Kết hợp với các công cụ khác: PDB hoạt động hiệu quả nhất khi được triển khai cùng với các bộ điều khiển cấp cao như Deployments, StatefulSets và hệ thống tự động mở rộng Pod.
• Kiểm thử kỹ lưỡng: Quản trị viên luôn luôn phải kiểm tra cấu hình PDB trong môi trường thử nghiệm trước. Việc này giúp đội ngũ đảm bảo rằng PDB hoạt động đúng như mong đợi và không gây hiện tượng bị nghẽn khi nâng cấp môi trường Production.

Vietnix – Nền tảng Enterprise Server cho mọi giải pháp Kubernetes

Để triển khai hiệu quả các cơ chế đảm bảo tính sẵn sàng cao như Pod Disruption Budget trong Kubernetes, đòi hỏi một hạ tầng đám mây mạnh mẽ, ổn định và có khả năng chịu lỗi. Vietnix cung cấp dịch vụ Enterprise Cloud Server hiệu suất vượt trội, lý tưởng để bạn xây dựng và vận hành các cluster Kubernetes. Với các tùy chọn cấu hình mạnh mẽ, bộ vi xử lý hiệu suất cao, ổ cứng NVMe siêu tốc và kết nối mạng ổn định, Vietnix đảm bảo nền tảng vững chắc để bạn triển khai PDB, thực hiện các hoạt động bảo trì, nâng cấp mà không lo gián đoạn dịch vụ. Liên hệ ngay!

Thông tin liên hệ:

• Website: https://vietnix.vn/
• Hotline: 1800 1093
• Email: sales@vietnix.com.vn
• Địa chỉ: 265 Hồng Lạc, Phường Bảy Hiền, Thành Phố Hồ Chí Minh

Pod Disruption Budget là một công cụ mạnh mẽ và không thể thiếu trong Kubernetes để đảm bảo tính sẵn sàng và ổn định của các ứng dụng trong quá trình bảo trì và nâng cấp. Bằng cách đặt ra các giới hạn rõ ràng về số lượng Pod có thể bị gián đoạn, PDB tạo ra một cơ chế phối hợp an toàn giữa đội ngũ vận hành hạ tầng và đội ngũ phát triển ứng dụng. Việc hiểu rõ cách thức hoạt động, các trường hợp sử dụng và quy trình quản lý PDB là chìa khóa để xây dựng các hệ thống có khả năng phục hồi cao, giảm thiểu downtime và duy trì chất lượng dịch vụ trong môi trường Cloud Native.