Skip to main content

2.3. Core Concepts - ReplicaSets and Deployments

Mục lục​

1. Vì sao cần Replication Controller / ReplicaSet​

Controller là "bộ não" đứng sau Kubernetes — chúng là các process giám sát Kubernetes object và phản ứng tương ứng. Trong đó, một controller đáng chú ý là Replication Controller.

Vậy replica là gì, và vì sao cần một Replication Controller? Quay lại tình huống ban đầu: có một Pod duy nhất chạy ứng dụng. Nếu vì lý do nào đó ứng dụng crash và Pod fail, người dùng sẽ không còn truy cập được ứng dụng nữa. Để tránh mất quyền truy cập ứng dụng, cần có nhiều hơn một instance hay Pod chạy cùng lúc — nhờ đó, nếu một cái fail, vẫn còn ứng dụng chạy trên cái còn lại.

Replication controller giúp chạy nhiều instance của một Pod duy nhất trong Kubernetes cluster, nhờ đó cung cấp tính sẵn sàng cao (high availability). Vậy có nghĩa là không thể dùng replication controller nếu chỉ định chạy một Pod duy nhất? Không — ngay cả khi chỉ có một Pod, replication controller vẫn giúp bằng cách tự động tạo Pod mới khi Pod hiện tại fail. Vì vậy, replication controller đảm bảo số lượng Pod chỉ định luôn đang chạy tại mọi thời điểm, dù đó là 1 hay 100.

Một lý do khác cần replication controller là để tạo nhiều Pod chia tải giữa chúng. Ví dụ, trong tình huống đơn giản, có một Pod duy nhất phục vụ một tập người dùng. Khi số lượng người dùng tăng, deploy thêm một Pod để cân bằng tải giữa 2 Pod. Nếu nhu cầu tiếp tục tăng, và nếu hết tài nguyên trên node đầu tiên, có thể deploy thêm Pod trên các node khác trong cluster. Replication controller trải rộng trên nhiều node trong cluster — nó giúp cân bằng tải giữa nhiều Pod trên các node khác nhau, cũng như scale ứng dụng khi nhu cầu tăng lên.

ReplicationController và ReplicaSet là 2 thứ khác nhau​

Quan trọng cần lưu ý: có 2 thuật ngữ tương tự nhau — ReplicationController và ReplicaSet. Cả 2 có cùng mục đích, nhưng không phải cùng một thứ. ReplicationController là công nghệ cũ hơn, đang dần được thay thế bởi ReplicaSet. ReplicaSet là cách được khuyến nghị hiện nay để thiết lập replication. Tuy nhiên, mọi điều đã bàn ở trên vẫn áp dụng cho cả 2 công nghệ này — có một số khác biệt nhỏ trong cách mỗi cái hoạt động. Trong khóa học, sẽ cố gắng bám theo ReplicaSet cho mọi demo và triển khai về sau.

2. Tạo Replication Controller bằng file YAML​

Cách tạo một replication controller: bắt đầu bằng cách tạo một replication controller definition file, đặt tên rc-definition.yaml. Như mọi Kubernetes definition file, có 4 phần: apiVersion, kind, metadata, và spec.

apiVersion phụ thuộc vào thứ đang tạo — trong trường hợp này, ReplicationController được hỗ trợ ở Kubernetes API version v1, nên set là v1. kind, như đã biết, là ReplicationController. Dưới metadata, thêm một name, đặt là myapp-RC, và thêm vài label như app và type, gán giá trị tương ứng. Tới đây, mọi thứ khá giống với cách đã tạo một Pod ở phần trước.

Phần tiếp theo, quan trọng nhất trong definition file, là phần đặc tả (specification), viết là spec. Với bất kỳ Kubernetes definition file nào, phần spec định nghĩa những gì nằm bên trong object đang tạo. Trong trường hợp này, biết rằng replication controller tạo nhiều instance của một Pod. Nhưng với Pod, tạo một phần template dưới spec để cung cấp pod template mà replication controller sẽ dùng để tạo các bản replica.

Định nghĩa pod template thế nào? Không khó, vì đã làm điều này ở phần trước — đã tạo một pod definition file trước đó, và có thể tái sử dụng nội dung của file đó để điền vào phần template. Di chuyển toàn bộ nội dung của pod definition file vào phần template của replication controller, ngoại trừ vài dòng đầu là apiVersion và kind. Ghi nhớ: mọi thứ được di chuyển phải nằm dưới template, nghĩa là phải được thụt vào bên phải và có nhiều khoảng trắng hơn dòng template — chúng phải là con của phần template.

Nhìn lại file lúc này, giờ có 2 phần metadata — một cho ReplicationController, một cho Pod. Và có 2 phần apiVersion — một cho mỗi cái. Đã lồng 2 definition file lại với nhau: ReplicaSet là parent, Pod definition là child.

Còn thiếu một thứ: chưa nói bao nhiêu replica cần trong ReplicaSet. Để làm việc đó, thêm một property khác vào spec tên replicas, và nhập số lượng replica cần dưới nó. Ghi nhớ template và replicas là con trực tiếp của phần spec, nên chúng là anh em (siblings), phải nằm trên cùng một đường thẳng đứng — nghĩa là có số khoảng trắng bằng nhau trước chúng.

Sau khi file đã sẵn sàng, chạy:

kubectl create -f rc-definition.yaml

Replication controller được tạo. Khi replication controller được tạo, nó trước tiên tạo các Pod bằng pod definition template, tạo đúng số lượng cần — trong trường hợp này là 3.

Để xem danh sách replication controller đã tạo:

kubectl get replicationcontroller

Sẽ thấy replication controller được liệt kê. Cũng có thể thấy số replica/Pod mong muốn, số hiện tại, và bao nhiêu trong số đó đã ready trong output. Nếu muốn xem các Pod được tạo bởi replication controller:

kubectl get pods

Sẽ thấy 3 Pod đang chạy. Lưu ý tất cả chúng đều bắt đầu bằng tên của replication controller, myapp-RC, cho thấy chúng đều được tạo tự động bởi replication controller.

3. ReplicaSet​

Đó là những gì vừa thấy về replication controller. Giờ nhìn tới ReplicaSet. Nó khá giống Replication Controller. Như thường lệ, trước tiên có apiVersion, kind, metadata, và spec.

apiVersion lại hơi khác — là apps/v1, khác với ReplicationController vốn chỉ là v1. Nếu chọn sai, khả năng cao sẽ gặp lỗi trông giống thế này: no match for kind ReplicaSet, vì API version chỉ định không hỗ trợ ReplicaSet. kind sẽ là ReplicaSet. Và thêm name cùng labels dưới metadata.

Phần đặc tả (specification section) trông khá giống Replication Controller — cũng có phần template cung cấp pod definition như trước, sao chép nội dung từ pod definition file, và có replicas được set là 3. Tuy nhiên, có một khác biệt lớn giữa ReplicationController và ReplicaSet: ReplicaSet yêu cầu định nghĩa selector.

Vì sao ReplicaSet cần selector​

Phần selector giúp ReplicaSet xác định Pod nào thuộc về nó. Nhưng vì sao cần chỉ định Pod nào thuộc về nó nếu đã cung cấp nội dung của pod definition file ngay trong template? Vì ReplicaSet cũng có thể quản lý các Pod không được tạo như một phần của việc tạo ReplicaSet. Ví dụ, nếu có Pod được tạo từ trước, khớp với label chỉ định trong selector, ReplicaSet cũng sẽ tính các Pod đó khi tạo replica.

Selector là một trong những khác biệt chính giữa ReplicationController và ReplicaSet. Với replication controller, selector không phải field bắt buộc — nó vẫn khả dụng, nhưng khi bỏ qua, nó được giả định giống với label cung cấp trong pod definition file. Với ReplicaSet, selector là field bắt buộc, và phải viết dưới dạng matchLabels. Selector matchLabels đơn giản khớp các label chỉ định dưới nó với label trên Pod. Selector của ReplicaSet còn cung cấp nhiều option khác để match label mà ReplicationController không có.

Để tạo ReplicaSet:

kubectl create -f replicaset-definition.yaml

Để xem ReplicaSet đã tạo:

kubectl get replicaset

Để lấy danh sách Pod:

kubectl get pods

4. Labels và Selectors​

Vậy chuyện gì với label và selector? Vì sao gán nhãn (label) cho Pod và object trong Kubernetes? Xét một tình huống đơn giản: giả sử đã deploy 3 instance của ứng dụng front-end web dưới dạng 3 Pod. Muốn tạo một replication controller hoặc ReplicaSet để đảm bảo luôn có 3 Pod hoạt động tại mọi thời điểm.

Đây chính là một trong các use case của ReplicaSet: có thể dùng nó để giám sát các Pod đã tồn tại sẵn, như trong ví dụ này. Nếu chúng chưa được tạo, ReplicaSet sẽ tạo chúng thay. Vai trò của ReplicaSet là giám sát các Pod, và nếu bất kỳ cái nào fail, deploy cái mới. ReplicaSet thực chất là một process giám sát các Pod.

Giờ ReplicaSet biết Pod nào cần giám sát bằng cách nào? Có thể có hàng trăm Pod khác trong cluster chạy các ứng dụng khác nhau. Đây là lúc việc gán nhãn cho Pod ngay từ lúc tạo phát huy tác dụng. Có thể dùng các label đó làm bộ lọc (filter) cho ReplicaSet. Dưới phần selector, dùng filter matchLabels và cung cấp cùng label đã dùng khi tạo Pod. Nhờ vậy, ReplicaSet biết Pod nào cần giám sát.

Cùng khái niệm về label và selector này được dùng ở nhiều nơi khác xuyên suốt Kubernetes.

Vẫn cần phần template ngay cả khi ReplicaSet không tạo Pod mới nào​

Trong phần đặc tả của ReplicaSet, có 3 phần: template, replicas, và selector. Xét lại tình huống trên: có sẵn 3 Pod đã tồn tại từ trước, cần tạo ReplicaSet để giám sát các Pod đó, đảm bảo luôn có tối thiểu 3 Pod chạy tại mọi thời điểm. Khi replication controller được tạo, nó sẽ không deploy một instance Pod mới nào, vì đã có 3 Pod khớp label được tạo sẵn.

Trong trường hợp đó, có thực sự cần cung cấp phần template trong đặc tả của ReplicaSet không, vì không kỳ vọng ReplicaSet tạo Pod mới khi deploy? Có, vẫn cần — vì trong tương lai, nếu một trong các Pod fail, ReplicaSet cần tạo một Pod mới để duy trì đúng số lượng mong muốn. Và để ReplicaSet tạo Pod mới, phần định nghĩa template là bắt buộc.

5. Scale ReplicaSet​

Giờ xem cách scale ReplicaSet. Giả sử bắt đầu với 3 replica, và trong tương lai quyết định scale lên 6. Làm sao cập nhật ReplicaSet để scale lên 6 replica? Có nhiều cách để làm việc này.

Cách 1: cập nhật số replicas trong definition file thành 6, sau đó chạy lệnh kubectl replace, chỉ định cùng file bằng option -f:

kubectl replace -f replicaset-definition.yaml

Việc này sẽ cập nhật ReplicaSet để có 6 replica.

Cách 2: chạy lệnh kubectl scale, dùng tham số --replicas để cung cấp số replica mới, và chỉ định cùng file làm input:

kubectl scale --replicas=6 -f replicaset-definition.yaml

Có thể input file định nghĩa, hoặc cung cấp tên ReplicaSet theo định dạng type/name. Tuy nhiên, cần nhớ rằng dùng tên file làm input sẽ không tự động cập nhật số replica trong file. Nói cách khác, số replica trong file định nghĩa ReplicaSet vẫn sẽ là 3, dù đã scale ReplicaSet lên 6 replica bằng lệnh kubectl scale với file làm input.

Cũng có các tùy chọn để tự động scale ReplicaSet dựa trên tải, nhưng đó là một chủ đề nâng cao, sẽ bàn ở thời điểm sau.

6. Tóm tắt các lệnh ReplicaSet​

  • kubectl create — dùng để tạo ReplicaSet, hay về cơ bản bất kỳ object nào trong Kubernetes, tùy vào file được cung cấp làm input. Phải cung cấp file input bằng tham số -f.
  • kubectl get replicaset — dùng để xem danh sách ReplicaSet đã tạo.
  • kubectl delete replicaset <tên> — dùng để xóa ReplicaSet.
  • kubectl replace — dùng để thay thế hoặc cập nhật ReplicaSet.
  • kubectl scale — dùng để scale ReplicaSet trực tiếp từ command line, mà không cần chỉnh sửa file.

7. Lab: giải bài thực hành về ReplicaSets​

Câu hỏi 1 — Có bao nhiêu Pod tồn tại trên hệ thống?​

kubectl get pods

Không có Pod nào — đáp án 0.

Câu hỏi 2 — Có bao nhiêu ReplicaSet tồn tại trên hệ thống?​

kubectl get replicaset

Đáp án 0. Sau khi một số thay đổi được thực hiện, kiểm tra lại — thấy có một ReplicaSet được tạo.

Câu hỏi — Có bao nhiêu Pod được mong muốn (desired) trong ReplicaSet mới?​

Từ output, số Pod mong muốn (desired) trong ReplicaSet là 4.

Câu hỏi — Image nào được dùng để tạo Pod trong ReplicaSet mới?​

Xem ReplicaSet chi tiết hơn:

kubectl describe replicaset new-replica-set

(Có thể dùng phím Tab để auto-complete tên.) Trong output, thấy pod template và image dùng là busybox777.

Câu hỏi — Có bao nhiêu Pod ready trong ReplicaSet mới?​

Từ output, số Pod ready là 0. Cũng thấy thông tin tương tự ở phần pod status: 0 Running.

Câu hỏi — Vì sao các Pod không Ready?​

Xem chi tiết một trong các Pod:

kubectl describe pod <tên-pod>

Thấy nguyên nhân là do không pull được image busybox777 — repository này không tồn tại, không có image nào tên busybox777.

Xóa một trong các Pod​

Xóa xong, kiểm tra lại số Pod:

kubectl get pods

Vẫn còn 4 Pod đang chạy — dù vừa xóa một cái, Pod bị xóa (bắt đầu bằng wk) không còn ở đó, nhưng vẫn có 4 Pod. Pod mới được tạo chỉ 17 giây trước, so với các Pod khác đã chạy 3 phút hoặc hơn. Điều này minh họa: dù xóa một Pod thuộc ReplicaSet, nó sẽ tự động tạo lại một Pod mới, vì ReplicaSet đảm bảo số lượng Pod mong muốn luôn chạy — không phải vì không thể xóa Pod của một ReplicaSet.

Tạo ReplicaSet dùng file định nghĩa tại root, sửa lỗi trong file​

kubectl create -f /root/replicaset-definition.yaml

Lỗi trả về: unable to recognize... no matches for kind "ReplicaSet" in version "v1". Xem file, thấy apiVersion là v1 và kind là ReplicaSet. Đúng như đã học, API version bị sai. Để xác định đúng giá trị, dùng lệnh:

kubectl explain replicaset

Từ output, thấy version đúng phải là apps/v1. Sửa lại apiVersion thành apps/v1 và tạo lại — lần này thành công.

Sửa lỗi trong file thứ hai, tạo ReplicaSet​

Chạy thử tạo, gặp lỗi: Invalid value: ... selector does not match template labels. Xem file: apiVersion là apps/v1 (đúng), kind là ReplicaSet (đúng), phần spec có replicas và selector. Vấn đề: label chỉ định trong selector là tier: frontend, trong khi label của Pod mà ReplicaSet sẽ tạo lại là nginx. Hai giá trị này phải khớp nhau, nếu không ReplicaSet không thể quản lý các Pod nó tạo ra. Sửa lại để khớp — trong trường hợp này đổi thành nginx. Lưu file và chạy lại — lần này được tạo thành công.

Xóa 2 ReplicaSet vừa tạo​

kubectl get rs

(rs là dạng viết tắt của replicaset.)

kubectl delete rs replicaset-1 replicaset-2

(Có thể chỉ định nhiều ReplicaSet trong cùng một lệnh.)

Sửa ReplicaSet ban đầu để dùng đúng image busybox​

Đã biết pod trong ReplicaSet đầu tiên chưa Ready vì tên image sai. Sửa bằng lệnh:

kubectl edit replicaset new-replica-set

Vào phần container, sửa tên image thành busybox, lưu file. Kiểm tra trạng thái Pod trên ReplicaSet — dù đã sửa tên image, các Pod hiện có không tự động được tạo lại. Phải xóa toàn bộ ReplicaSet và tạo lại, hoặc xóa toàn bộ Pod để ReplicaSet tạo Pod mới với image mới. Trong lab, xóa từng Pod đang lỗi và chờ ReplicaSet tạo lại Pod mới với image đúng. Sau khi các Pod mới chuyển sang trạng thái Running, kiểm tra ReplicaSet — tất cả đều ở trạng thái Ready.

Scale ReplicaSet lên 5 Pod​

kubectl scale --replicas=5 rs new-replica-set

Kiểm tra trạng thái, thấy một Pod mới đã được thêm. Cũng có thể làm điều này bằng lệnh kubectl edit, đổi số replica trong file rồi lưu.

Scale ReplicaSet xuống 2 Pod​

Lần này dùng cách khác — kubectl edit rs, chỉ định tên ReplicaSet, sửa số replica thành 2, và lưu file.

8. Deployments​

Tạm quên Pod, ReplicaSet, và các khái niệm khác của Kubernetes trong một phút — bàn về cách deploy ứng dụng trong môi trường production. Ví dụ, có một web server cần deploy trong môi trường production. Cần không chỉ một, mà nhiều instance của web server đang chạy — vì những lý do hiển nhiên.

Thứ hai, mỗi khi có bản build ứng dụng mới trên Docker registry, muốn nâng cấp Docker instance một cách mượt mà. Tuy nhiên, khi nâng cấp instance, không muốn nâng cấp tất cả cùng lúc — việc này có thể ảnh hưởng người dùng đang truy cập ứng dụng, nên muốn nâng cấp từng cái một, và kiểu nâng cấp đó gọi là rolling update.

Giả sử một trong các lần nâng cấp gây ra lỗi ngoài dự kiến, và cần undo thay đổi vừa thực hiện. Muốn có khả năng rollback lại các thay đổi vừa thực hiện. Cuối cùng, giả sử muốn thực hiện nhiều thay đổi lên môi trường cùng lúc, như nâng cấp phiên bản web server bên dưới, đồng thời scale môi trường, và sửa resource allocation, v.v. Không muốn áp dụng từng thay đổi ngay sau khi lệnh chạy — thay vào đó, muốn tạm dừng (pause) môi trường, thực hiện các thay đổi, rồi tiếp tục (resume) để mọi thay đổi được rollout cùng lúc.

Tất cả các khả năng này đều có sẵn với Kubernetes Deployment.

Đến lúc này trong khóa học, đã bàn về Pod, dùng để deploy một instance đơn lẻ của ứng dụng — mỗi container được đóng gói trong Pod. Nhiều Pod như vậy được deploy bằng replication controller hoặc ReplicaSet. Và tiếp theo là Deployment — một Kubernetes object nằm cao hơn trong hệ thống phân cấp (hierarchy). Deployment cung cấp khả năng nâng cấp các instance bên dưới một cách mượt mà thông qua rolling update, undo thay đổi, và pause, resume thay đổi khi cần.

Tạo Deployment​

Cách tạo Deployment: như các component trước, trước tiên tạo một deployment definition file. Nội dung của deployment definition file gần giống hệt replica set definition file, ngoại trừ phần kind giờ sẽ là Deployment. Xem qua nội dung file: có apiVersion là apps/v1, metadata có name và labels, và spec có template, replicas, và selector. Phần template có pod definition bên trong nó.

Khi file đã sẵn sàng, chạy lệnh kubectl create, chỉ định deployment definition file:

kubectl create -f deployment-definition.yaml

Sau đó chạy lệnh kubectl get deployments để xem Deployment vừa tạo:

kubectl get deployments

Deployment tự động tạo một ReplicaSet — nếu chạy lệnh kubectl get replicaset, sẽ thấy một ReplicaSet mới mang tên của Deployment:

kubectl get replicaset

ReplicaSet cuối cùng tạo ra Pod — nếu chạy lệnh kubectl get pods, sẽ thấy các Pod mang tên của Deployment và ReplicaSet:

kubectl get pods

Tới đây, chưa có nhiều khác biệt giữa ReplicaSet và Deployment, ngoại trừ việc Deployment tạo ra một Kubernetes object mới gọi là deployments. Việc tận dụng Deployment cho các use case đã bàn ở phần trước (rolling update, undo, pause/resume) sẽ được xem xét ở các lecture sau.

Trước khi kết thúc lecture này, một ghi chú cuối: để xem tất cả object đã tạo cùng lúc, chạy:

kubectl get all

Trong trường hợp này, sẽ thấy Deployment vừa được tạo, theo sau là ReplicaSet, rồi tới 3 Pod được tạo như một phần của Deployment.

9. Tip: dùng kubectl run/create để generate YAML nhanh trong kỳ thi​

Việc tạo và chỉnh sửa file YAML khá khó, đặc biệt trên CLI. Trong kỳ thi, có thể sẽ gặp khó khăn khi copy-paste file YAML từ trình duyệt sang terminal. Dùng đúng lệnh có thể giúp generate một YAML template. Và đôi khi, có thể chỉ cần lệnh mà không cần tạo file YAML nào cả. Ví dụ, nếu được yêu cầu tạo một Pod hay Deployment với tên và image cụ thể, có thể đơn giản chạy lệnh.

Tham khảo (nên bookmark trang này cho kỳ thi, sẽ rất hữu ích): kubernetes.io/docs/reference/kubectl/conventions

Tạo Pod NGINX:

kubectl run nginx --image=nginx

Generate Pod manifest YAML (-o yaml), không tạo (--dry-run):

kubectl run nginx --image=nginx --dry-run=client -o yaml

Tạo Deployment:

kubectl create deployment --image=nginx nginx

Generate Deployment YAML (-o yaml), không tạo (--dry-run):

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Generate Deployment YAML và lưu ra file:

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

Chỉnh sửa file khi cần (ví dụ thêm replica), rồi tạo Deployment:

kubectl create -f nginx-deployment.yaml

Hoặc, từ Kubernetes version 1.19+, có thể chỉ định option --replicas để tạo Deployment với 4 replica ngay từ lệnh:

kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml

10. Lab: giải bài thực hành về Deployments​

Câu hỏi 1 — Có bao nhiêu Pod tồn tại trên hệ thống?​

kubectl get pods

Không có Pod nào.

Câu hỏi 2 — Có bao nhiêu ReplicaSet?​

kubectl get rs

Đáp án 0.

Câu hỏi 3 — Có bao nhiêu Deployment?​

kubectl get deployments

Đáp án 0. Môi trường đang sạch — không có Pod, ReplicaSet, hay Deployment nào. Sau khi một số thay đổi được thực hiện, kiểm tra lại Deployment — có một Deployment. Đáp án là 1.

Câu hỏi — Có bao nhiêu ReplicaSet tồn tại?​

kubectl get rs

Có một ReplicaSet — Deployment tên frontend-deployment đã tạo một ReplicaSet tên frontend-deployment-<số>. Kiểm tra số Pod:

kubectl get pods

Có 4 Pod — trước đó chưa có gì, khi Deployment được tạo, nó tạo một ReplicaSet, và ReplicaSet đó tạo 4 Pod.

Câu hỏi — Trong số các Pod hiện có, bao nhiêu Pod ready?​

Từ trạng thái, trong 4 Pod, số Pod ready là 0.

Câu hỏi — Image nào được dùng để tạo Pod trong Deployment mới?​

kubectl describe pod <tên-pod-frontend-deployment>

Image dùng là busybox888.

Câu hỏi — Vì sao Deployment chưa ready?​

Vì image busybox888 không tồn tại.

Tạo Deployment mới bằng file deployment-definition-1.yaml tại root​

kubectl create -f deployment-definition-1.yaml

Lỗi trả về: no kind "Deployment" is registered for version "apps/v1". Xem file: apiVersion là apps/v1 (đúng), kind là Deployment (cũng đúng về mặt chữ), nhưng vấn đề là nó phân biệt hoa thường (case-sensitive) — ký tự đầu của Kind phải viết hoa. Sửa lại và tạo lại thành công.

Tạo Deployment mới với các thuộc tính cho trước (tên, replicas, image)​

Dùng lệnh kubectl create deployment, xem help để biết các option — có thể chỉ định tên, image, và số replica ngay trong lệnh:

kubectl create deployment httpd-frontend --image=httpd --replicas=3

Kiểm tra:

kubectl get deploy

Thấy Deployment httpd-frontend, và đảm bảo nó đạt trạng thái Ready — 3/3 Ready.

Nguồn tham khảo​

Nguồn gốc: Khóa "Certified Kubernetes Administrator (CKA)" — phần "Core Concepts" (Replication Controller, ReplicaSet, labels/selectors, scale ReplicaSet, lab ReplicaSets, Deployments, tip generate YAML nhanh, lab Deployments), nền tảng KodeKloud. Giảng viên: Mumshad Mannambeth.

Repo ghi chú, link tài liệu, và đáp án các practice question của toàn bộ khóa học: kodekloudhub/certified-kubernetes-administrator-course.