Skip to main content

2.2. Core Concepts - Pods

Mục lục​

1. Pod là gì?​

Trước khi tìm hiểu về Pod, giả định rằng những điều sau đã được thiết lập sẵn: ứng dụng đã được phát triển và build thành Docker image, và có sẵn trên một Docker repository như Docker Hub, để Kubernetes có thể pull về. Cũng giả định Kubernetes cluster đã được setup sẵn và đang hoạt động — có thể là single-node hoặc multi-node, không quan trọng. Mọi service cần ở trạng thái running.

Mục tiêu cuối cùng khi dùng Kubernetes là deploy ứng dụng dưới dạng container trên một tập máy được cấu hình làm worker node trong cluster. Tuy nhiên, Kubernetes không deploy container trực tiếp lên worker node. Container được đóng gói vào một Kubernetes object gọi là Pod. Pod là một instance đơn lẻ của một ứng dụng. Pod là object nhỏ nhất có thể tạo trong Kubernetes.

Trường hợp đơn giản nhất: một single-node Kubernetes cluster với một instance duy nhất của ứng dụng, chạy trong một Docker container duy nhất, được đóng gói trong một Pod.

Nếu số lượng người dùng truy cập ứng dụng tăng lên và cần scale ứng dụng, cần thêm instance mới của web application để chia tải. Vậy các instance mới này được đưa lên đâu? Có phải bằng cách thêm một container instance mới bên trong cùng Pod không? Không — thay vào đó tạo một Pod hoàn toàn mới với một instance mới của cùng ứng dụng. Kết quả là có 2 instance của web application chạy trên 2 Pod riêng biệt, trên cùng một Kubernetes cluster hoặc node.

Nếu lượng người dùng tiếp tục tăng và node hiện tại không còn đủ khả năng, có thể deploy thêm Pod trên một node mới trong cluster — một node mới được thêm vào để mở rộng physical capacity của cluster.

Điều đang minh họa ở đây là Pod thường có quan hệ một-một với container chạy ứng dụng. Để scale up, tạo Pod mới. Để scale down, xóa Pod hiện có — không thêm container vào một Pod đã tồn tại để scale ứng dụng. (Cách triển khai chi tiết việc load balancing giữa các Pod sẽ được bàn ở phần sau — hiện tại chỉ tập trung hiểu khái niệm cơ bản.)

2. Multi-container Pod​

Vừa nói rằng Pod thường có quan hệ một-một với container. Nhưng có bị giới hạn chỉ 1 container trong 1 Pod không? Không — một Pod đơn lẻ có thể có nhiều container, ngoại trừ việc chúng thường không phải nhiều container cùng loại.

Như đã bàn ở phần trước, nếu mục đích là scale ứng dụng, thì cần tạo thêm Pod. Nhưng đôi khi có tình huống có một helper container thực hiện một số tác vụ hỗ trợ cho web application, như xử lý dữ liệu người dùng nhập, xử lý file người dùng upload, v.v. Muốn các helper container này sống cùng container ứng dụng. Trong trường hợp đó, có thể đặt cả 2 container vào cùng một Pod, để khi một application container mới được tạo, helper cũng được tạo theo. Và khi nó chết, helper cũng chết theo, vì chúng thuộc cùng một Pod.

Hai container có thể giao tiếp trực tiếp với nhau bằng cách gọi nhau qua localhost, vì chúng chia sẻ cùng network space. Ngoài ra, chúng cũng dễ dàng chia sẻ cùng storage space.

Nhìn lại từ góc độ thuần Docker​

Tạm gác Kubernetes sang một bên, bàn về Docker container đơn thuần. Giả sử đang phát triển một process hay script để deploy ứng dụng trên một Docker host. Đầu tiên chỉ đơn giản deploy ứng dụng bằng lệnh docker run python-app, và ứng dụng chạy ổn, người dùng truy cập được. Khi tải tăng, deploy thêm instance bằng cách chạy lệnh docker run nhiều lần nữa — vẫn ổn.

Sau đó, ứng dụng phát triển thêm, trải qua thay đổi kiến trúc, và trở nên phức tạp hơn. Giờ có một helper container mới hỗ trợ web application bằng cách xử lý hoặc fetch dữ liệu từ nơi khác. Các helper container này duy trì quan hệ một-một với application container, và cần giao tiếp trực tiếp, truy cập dữ liệu từ các container đó. Để làm được, cần duy trì một bản đồ (map) về app và helper container nào kết nối với nhau. Cần tự thiết lập network connectivity giữa các container này bằng link và custom network. Cần tạo shareable volume và chia sẻ chúng giữa các container — và cũng cần duy trì bản đồ cho việc đó. Quan trọng hơn, cần giám sát trạng thái của application container, và khi nó chết, phải tự tay kill helper container vì nó không còn cần thiết nữa. Khi một container mới được deploy, cũng phải tự deploy helper container mới.

Với Pod, Kubernetes tự động làm hết mọi việc đó. Chỉ cần định nghĩa Pod gồm những container nào, và các container trong Pod, theo mặc định, sẽ có quyền truy cập vào cùng storage, cùng network namespace, và cùng số phận — nghĩa là chúng được tạo cùng nhau và bị hủy cùng nhau.

Ngay cả khi ứng dụng không phức tạp đến vậy và có thể sống ổn với một container duy nhất, Kubernetes vẫn yêu cầu tạo Pod. Nhưng điều này lại tốt về lâu dài, vì ứng dụng đã sẵn sàng cho các thay đổi kiến trúc và scale trong tương lai.

Tuy nhiên, cũng cần lưu ý rằng multi-container Pod là một use case khá hiếm gặp. Trong khóa học này, sẽ chủ yếu dùng single container mỗi Pod.

3. Deploy Pod bằng lệnh kubectl run​

Trước đó đã học về lệnh kubectl run. Lệnh này thực chất làm gì? Nó deploy một Docker container bằng cách tạo một Pod. Nó trước tiên tự động tạo một Pod và deploy một instance của Docker image NGINX.

Nhưng nó lấy application image ở đâu? Cần chỉ định tên image bằng tham số --image. Application image, trong trường hợp này là image Nginx, được tải về từ Docker Hub repository. Docker Hub là một public repository nơi lưu các Docker image mới nhất của nhiều ứng dụng khác nhau. Có thể cấu hình Kubernetes pull image từ Docker Hub công khai hoặc từ một private repository nội bộ trong tổ chức.

Có Pod được tạo rồi, làm sao xem danh sách Pod hiện có?

kubectl get pods

Lệnh này giúp thấy danh sách Pod trong cluster. Ở đây, thấy Pod đang ở trạng thái ContainerCreating, và sớm chuyển sang trạng thái Running khi nó thực sự đang chạy.

Cũng cần lưu ý, phần này chưa bàn tới khái niệm cách người dùng truy cập được NGINX web server — vì vậy ở trạng thái hiện tại, web server chưa được expose ra ngoài cho người dùng bên ngoài. Có thể truy cập nó nội bộ từ node. Nhưng hiện tại, chỉ dừng ở việc xem cách deploy một Pod — sau này, khi học về networking và services, sẽ biết cách làm cho service này truy cập được từ end user.

4. File định nghĩa Pod bằng YAML​

Phần này bàn về cách tạo một Pod bằng file cấu hình dạng YAML. Kubernetes dùng file YAML làm input để tạo object như Pods, replicas, deployments, services, v.v. Tất cả đều theo một cấu trúc tương tự nhau.

Một Kubernetes definition file luôn chứa 4 field cấp cao nhất (top-level field): apiVersion, kind, metadata, và spec. Đây là các property cấp gốc (root-level), và cũng là các field bắt buộc — phải có chúng trong file cấu hình.

apiVersion​

Đây là phiên bản của Kubernetes API đang dùng để tạo object. Tùy vào thứ đang tạo, phải dùng đúng API version. Với Pod, sẽ set apiVersion là v1. Một vài giá trị khác có thể gặp cho field này là apps/v1 (dùng cho Deployment, ReplicaSet, DaemonSet, StatefulSet), batch/v1 (dùng cho Job, CronJob), v.v. — phần sau của tài liệu sẽ bàn các giá trị này dùng cho việc gì.

kind​

kind là loại object đang tạo — trong trường hợp này là Pod, nên set là Pod. Một số giá trị khác có thể gặp ở field này là ReplicaSet, Deployment, hoặc Service.

metadata​

metadata là dữ liệu về object, như tên (name), nhãn (labels), v.v. Khác với 2 field đầu là string value, metadata ở dạng dictionary. Mọi thứ dưới metadata đều được thụt vào bên phải một chút, nên name và labels là con (children) của metadata. Số khoảng trắng trước 2 property đó không quan trọng, nhưng chúng phải bằng nhau, vì chúng là anh em (siblings). Nếu labels có nhiều khoảng trắng hơn name, nó trở thành con của name thay vì là anh em — điều này sai. Cả 2 property cũng phải có nhiều khoảng trắng hơn parent của nó là metadata, để được thụt vào bên phải đúng cách.

Dưới metadata, name là một string value — có thể đặt tên Pod là my-app-pod. Còn labels là một dictionary, nên labels là một dictionary nằm bên trong dictionary metadata, và có thể chứa bất kỳ cặp key-value nào tùy ý. Ví dụ, thêm một label app với giá trị myapp. Có thể thêm các label khác tùy ý, giúp nhận diện các object này về sau. Ví dụ, nếu có hàng trăm Pod chạy ứng dụng frontend và hàng trăm Pod chạy ứng dụng backend hoặc database, sẽ khó group các Pod này lại sau khi deploy — nếu gán nhãn chúng là frontend, backend, hoặc database ngay từ đầu, có thể filter Pod dựa trên nhãn này về sau.

Điểm quan trọng cần lưu ý: dưới metadata, chỉ có thể chỉ định name, labels, hoặc bất kỳ thứ gì Kubernetes mong đợi nằm dưới metadata — không thể thêm property tùy ý khác dưới metadata. Tuy nhiên, dưới labels, có thể có bất kỳ loại cặp key-value nào tùy ý.

spec​

Cho tới lúc này chỉ mới chỉ định type và name của object cần tạo, là một Pod tên myAppPod. Nhưng chưa thực sự chỉ định container hay image cần trong Pod. Phần cuối trong file cấu hình là phần đặc tả (specification section), viết là spec.

Tùy vào object định tạo, đây là nơi cung cấp thêm thông tin cho Kubernetes liên quan tới object đó. Phần này sẽ khác nhau giữa các object khác nhau — nên quan trọng là hiểu hoặc tra tài liệu để lấy đúng format cho từng loại.

Vì chỉ tạo một Pod với 1 container, việc này khá đơn giản: spec là một dictionary, nên thêm một property dưới nó tên containers. containers là một list hoặc array — vì Pod có thể chứa nhiều container bên trong, như đã học ở phần trước. Trong trường hợp này, chỉ thêm một item duy nhất trong list, vì chỉ có một container trong Pod. Dấu gạch ngang (-) ngay trước tên chỉ ra đây là item đầu tiên trong list. Item trong list là một dictionary — thêm property name và image, giá trị của image là nginx, tên của Docker image trong Docker repository.

Cấu trúc pod-definition.yamlapiVersion: v1kind: Podmetadata:name: myapp-podlabels:app: myappspec:containers:- name: nginx, image: nginxThụt vào bên phải = con của property phía trênname/labels là con của metadata, containers là con của spec

Sau khi file được tạo, chạy:

kubectl create -f pod-definition.yaml

Và Kubernetes tạo Pod.

Tóm lại, hãy nhớ 4 top-level property: apiVersion, kind, metadata, và spec — rồi bắt đầu thêm giá trị vào đó tùy vào object định tạo.

Sau khi tạo Pod, làm sao xem nó?

kubectl get pods

Dùng lệnh này để xem danh sách Pod hiện có — trong trường hợp này chỉ có một. Để xem thông tin chi tiết về Pod:

kubectl describe pod

Lệnh này cho biết thông tin về Pod — khi nào nó được tạo, những nhãn nào được gán, những Docker container nào là một phần của nó, và các event liên quan tới Pod đó.

5. Demo: tạo Pod bằng file YAML​

Trong demo này, tạo lại một Pod, nhưng lần này thay vì dùng lệnh kubectl run, tạo nó bằng một file định nghĩa YAML. Mục tiêu là tạo một file YAML với các thông số kỹ thuật (specification) của Pod bên trong.

Có nhiều cách để làm việc này — có thể tạo file bằng bất kỳ text editor nào. Trên Windows, có thể dùng Notepad. Trên Linux, dùng một editor gốc như VI hay Vim. Một editor có hỗ trợ cú pháp YAML sẽ rất hữu ích để đảm bảo cú pháp đúng — thay vì Notepad, một tool như Notepad++ trên Windows hoặc Vim trên Linux sẽ tốt hơn.

Trong demo này, dùng Vim text editor trên hệ thống Linux. Tên file được đặt là pod.yaml. Bắt đầu với 4 root-level element hay root-level property đã học: apiVersion, kind, metadata, và spec.

  • Giá trị apiVersion cho một Pod là v1.
  • kind là Pod với chữ P viết hoa — có phân biệt hoa thường (case sensitive), nên đây là điểm quan trọng.
  • metadata là một dictionary, có thể chứa giá trị định nghĩa tên của Pod — dùng name: nginx, và có thể thêm nhãn (labels) khác dưới nó. labels cũng là một dictionary, có thể có bao nhiêu label tùy ý bên dưới. Ví dụ chỉ định một label dạng key-value như app: nginx. Có thể thêm label khác như tier: frontend, hay bất kỳ label nào giúp group Pod này.

Tiếp theo, định nghĩa spec — cũng là một dictionary, có một object tên containers. Trước khi qua phần đó, phải đảm bảo đúng indentation. Ví dụ, app và tier là con của property labels, nên phải cùng một đường thẳng đứng (vertical line). Tương tự, dưới metadata, có name và labels — là con của metadata, cả hai cũng phải nằm cùng đường thẳng đứng. Vậy phải đảm bảo spacing đúng — thường là 2 khoảng trắng hoặc 1 tab, nhưng khuyến nghị không dùng tab, luôn dùng 2 khoảng trắng và giữ nhất quán xuyên suốt.

Kế tiếp là containers — một list các object. Đầu tiên đặt tên (đây là tên của container bên trong Pod, có thể có nhiều container, mỗi cái có tên khác nhau — một container có thể tên app, container khác tên helper, tùy chọn tên nào hợp lý). Trong demo, đặt tên cùng với tên image container — nginx. Object thứ hai cần thêm là tên image — tên Docker Hub image của container cần tạo, trong trường hợp này cũng là nginx. Nếu dùng registry khác ngoài Docker Hub, phải chỉ định full path tới image repository đó.

Có thể thêm container phụ vào Pod — nếu cần, khai báo phần tử thứ hai vào list, là object thứ hai trong list. Ví dụ có thể thêm một container busybox dùng image busybox, đó sẽ là phần tử thứ hai của array. Trong demo này, chỉ giữ lại một container duy nhất, nên phần tử busybox được xóa đi.

Sau khi soạn xong, nhấn Escape rồi :wq để lưu file, và dùng lệnh cat để đảm bảo file được tạo đúng nội dung. Đảm bảo format đúng — name và labels là con của metadata và nằm cùng đường thẳng đứng; labels có 2 con là 2 label app và tier; spec có một list, được định nghĩa dưới dạng list với dấu gạch ngang theo sau là các object.

Có thể dùng lệnh kubectl create hoặc lệnh kubectl apply — 2 lệnh này hoạt động như nhau nếu đang tạo object mới. Dùng option -f để truyền tên file:

kubectl create -f pod.yaml

hoặc

kubectl apply -f pod.yaml

Và Pod đã được tạo. Kiểm tra trạng thái nhanh:

kubectl get pods

Thấy Pod đang ở trạng thái ContainerCreating, và khi kiểm tra lại, thấy nó chuyển sang trạng thái Running. Như trước, nếu muốn xem thêm chi tiết về Pod, luôn có thể chạy lệnh kubectl describe kèm tên Pod:

kubectl describe pod nginx

Sẽ nhận được thông tin sâu hơn nhiều về Pod.

6. Hướng dẫn dùng practice test portal​

Trước khi bước vào practice test, đây là vài phút hướng dẫn về practice test portal. Sau phần này, sẽ được đưa tới lab. Bấm nút Start để load lab. Cần truy cập practice test trên laptop hoặc desktop, vì cần bàn phím để thao tác hands-on. Cho lab một chút thời gian để load — thường mất dưới 30 giây, và trong một số trường hợp hiếm, có thể mất vài phút. Hãy kiên nhẫn nếu quá trình load lâu hơn bình thường.

Khi lab đã load xong, sẽ thấy quiz portal ở bên trái và một terminal ở bên phải. Terminal bên phải là một terminal sống để thao tác. Đây có thể là Linux terminal nếu đang học Linux, shell scripting, hoặc Git; hoặc là một Docker host nếu đang học Docker; hoặc control plane của Kubernetes nếu đang học Kubernetes. Có thể chạy lệnh ở đây và tương tác với hệ thống để thực hiện task.

Có 2 phần trong lab: terminal bên phải nơi thao tác, chạy lệnh để xem và cấu hình Kubernetes cluster; và quiz portal bên trái. Mỗi topic được dạy trong tài liệu có một practice test tương ứng, gồm từ 5 đến 15 câu hỏi. Có thể thấy tổng số câu hỏi ở trên cùng, và khi tiến triển qua từng câu, tiến độ sẽ được đánh dấu tương ứng.

Các câu hỏi thuộc nhiều dạng khác nhau. Đôi khi được yêu cầu tìm thông tin trong môi trường và chọn đáp án đúng. Đôi khi cần thực hiện thay đổi lên môi trường, như deploy một tập Pods hay Services, và được yêu cầu tìm thông tin bên trong chúng. Hoặc có thể được yêu cầu thực hiện một task cấu hình theo một spec cho sẵn. Hệ thống sau đó sẽ test công việc để đảm bảo đã hoàn thành thành công. Đôi khi được cho một tập Kubernetes definition file và được yêu cầu dùng chúng để tạo cấu hình — dùng vi editor để chỉnh sửa các file này.

⚠️ Lưu ý: trong bài thi chứng chỉ thật, phải dùng một trong các editor có sẵn trong môi trường thi được cung cấp. Vì vậy phải luyện tập làm việc với vi editor.

Cũng có một số câu hỏi trắc nghiệm (multiple-choice) theo tình huống, nhưng sẽ không có dạng này trong bài thi chứng chỉ thật — chúng được thêm vào để kiểm tra kiến thức và đảm bảo đang thực sự học. Khi được cho một spec, hãy nhớ tạo đúng cấu hình khớp chính xác với spec đó. Có thể skip một câu bất kỳ bằng cách bấm nút ở trên cùng, nhưng lưu ý không thể quay lại, vì các câu hỏi đi theo một luồng nhất định. Đôi khi có thể truy cập ứng dụng vừa deploy bằng cách bấm vào link web portal phía trên terminal — nhưng điều này tùy thuộc vào việc ứng dụng có web portal hay không. Nếu vì lý do nào đó cần mở terminal mới, bấm vào nút tương ứng ở trên cùng.

Lưu ý rằng đây không phải bản sao chính xác của kỳ thi chứng chỉ Kubernetes thật — nên interface và trải nghiệm trong kỳ thi thật sẽ hơi khác so với ở đây. Đây là một giải pháp tùy chỉnh được xây dựng để giúp luyện tập, kiểm tra kỹ năng, hướng dẫn, và chuẩn bị cho kỳ thi thật. Đừng quá lo lắng về interface của kỳ thi — dù sao thì đó cũng sẽ là các task cần thực hiện cùng terminal cạnh bên, gần như môi trường lab này, nên sẽ dễ làm quen, không cần quá căng thẳng.

Có thể làm lại các bài test này nhiều lần tùy thích cho tới khi cảm thấy tự tin. Lưu ý, đây là môi trường tạm thời và chỉ khả dụng trong một giờ, tùy vào mock exam hoặc môi trường lab cụ thể — sau đó nó sẽ bị xóa, nên công việc sẽ không được lưu lại. Có thể refresh cửa sổ lab bất cứ lúc nào, và nó sẽ đưa trở lại đúng môi trường lab đó — ví dụ nếu tạm thời mất kết nối internet, hoặc restart môi trường lab, hoặc refresh trang web, nó sẽ đưa trở lại đúng môi trường lab đó. Tuy nhiên, nếu đóng trình duyệt trong thời gian dài hoặc session lab bị idle quá lâu, nó sẽ tự động bị chấm dứt — nhưng luôn có thể refresh trang và load một môi trường lab mới, bắt đầu lại từ câu hỏi đầu tiên.

Cũng lưu ý không được dùng hoặc lưu bất kỳ personal credential hay công việc mang tính lâu dài (persistent) nào trong môi trường này. Cuối cùng, hãy nhớ rằng practice test không chỉ để kiểm tra kỹ năng và các khái niệm đã học trong tài liệu — chúng được thiết kế để học các khái niệm và có được kinh nghiệm hands-on. Vì vậy có thể có những chủ đề không được bàn trong tài liệu. Có thể sẽ có lúc bị mắc kẹt — nếu vậy, tất nhiên có thể liên hệ, và cũng có thể thử lại. Nếu không biết gì, phải tự đi qua trang tài liệu và cố gắng tìm câu trả lời. Việc thúc đẩy đọc trang tài liệu, tìm thông tin, và tự triển khai chính là ý tưởng đứng sau các practice test này.

Vậy nên nếu cần thêm giải thích về bất kỳ chủ đề nào, hãy liên hệ và cho biết. Nhưng mọi câu hỏi hay task được giao trong lab đều có tab Hints and Solutions hiển thị cạnh câu hỏi.

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

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

Dùng lệnh:

kubectl get pods

Kết quả trả về 0 — no resources found, nên đáp án là 0.

Câu hỏi 2 — Tạo một Pod mới với image nginx​

Cách dễ nhất là chạy lệnh kubectl run, chỉ định tên và image. Nếu không chắc cú pháp, chạy lệnh help. Cú pháp là tên Pod theo sau bởi image theo định dạng:

kubectl run <tên> --image=<image>

Không có yêu cầu cụ thể về tên Pod, nên có thể đặt tên bất kỳ, nhưng image phải là nginx. Chạy lệnh, Pod được tạo.

Câu hỏi 3 — Có bao nhiêu Pod được tạo hiện tại?​

Đã có thêm vài Pod khác được tạo. Chạy lại:

kubectl get pods

Ngoài Pod nginx vừa tạo, có thêm vài Pod khác đã được tạo sẵn (bởi hệ thống lab). Tổng cộng có 4 Pod tại thời điểm này.

Xóa Pod thứ 4​

Xác định image dùng để tạo các Pod mới: phải xem chi tiết một trong các Pod mới. Chạy lệnh:

kubectl describe pod <tên-pod>

Xem phần containers trong output, thấy image là busybox.

Câu hỏi — Pod này được đặt (schedule) trên node nào?​

Phải xem chi tiết toàn bộ Pod để xác định. Một cách là chạy kubectl describe pod cho từng Pod — thấy Pod này nằm trên control plane. Cách khác dễ hơn: chạy lệnh với option wide:

kubectl get pods -o wide

Thấy cột node, ghi control plane. Vậy tất cả Pod mới đều được tạo trên node control plane.

Câu hỏi — Có bao nhiêu container là một phần của Pod webapp?​

Chạy kubectl get pods để xem — cột số container thể hiện tổng số container thuộc Pod đó. Hoặc luôn có thể chạy lệnh describe để xem chi tiết — thấy phần Containers, có 2 container: một là nginx, một là agentx.

Câu hỏi — Image nào được dùng cho các container trong Pod webapp?​

Xem chi tiết Pod: image cho container nginx là nginx, image cho container còn lại (tên agentx) là agentx.

Câu hỏi — Trạng thái của container agentx trong Pod webapp là gì?​

Xem trong phần state của container, thấy trạng thái là Waiting. Trong các trạng thái Running, Ready, Success, Error, hay Waiting — đây là trạng thái Waiting.

Câu hỏi — Vì sao container agentx trong Pod webapp ở trạng thái Error/Waiting?​

Xem phần section của Pod dưới state, có reason là Error: ImagePull. Hoặc xem trong phần events, thấy lỗi cụ thể: Failed to pull image "agentx" tại docker.io/library/agentx. Image tên agentx không tồn tại. Đáp án đúng: image Docker với tên này không tồn tại trên Docker Hub.

Câu hỏi — Cột READY trong output của lệnh kubectl get pods thể hiện gì?​

Trong output có giá trị dạng 1/1 và 1/2. Đây là tổng số container trong Pod, và số container đang ready. Ở đây chỉ có 1 container ready trong tổng 2, vì image agentx không tồn tại nên container đó chưa ready. Đáp án đúng: tổng số container ready trên tổng số container trong Pod.

Xóa Pod webapp​

kubectl delete pod webapp

Câu hỏi — Tạo Pod mới tên redis với image redis123 (tên image sai)​

Khuyến nghị dùng file định nghĩa Pod dạng YAML. Có 2 cách: chạy kubectl run trực tiếp, hoặc tạo YAML để làm quen với việc generate file YAML. Dùng option dry-run để output ra định dạng YAML mà không thực sự tạo object:

kubectl run redis --image=redis123 --dry-run=client -o yaml

⚠️ Lưu ý: option --dry-run (không kèm giá trị) đã bị deprecated, và được thay bằng --dry-run=client.

Redirect output ra file:

kubectl run redis --image=redis123 --dry-run=client -o yaml > redis.yaml

Tạo Pod bằng file YAML vừa tạo:

kubectl create -f redis.yaml

Kiểm tra, thấy Pod ở trạng thái lỗi ImagePull, vì dùng sai tên image — đúng như mong đợi.

Câu hỏi cuối — Sửa image trên Pod này thành redis để Pod chạy được​

Có 2 cách: dùng lệnh kubectl edit để sửa Pod, hoặc vì đã có sẵn file redis.yaml, chỉnh sửa trực tiếp file rồi apply lại. Sửa tên image trong file, rồi apply lại thay đổi. Kiểm tra lại bằng kubectl get pods, thấy Pod ở trạng thái Running.

(Ghi chú: có một warning liên quan tới việc kết hợp lệnh imperative và cách apply declarative xuất hiện ở bước này trong nguồn gốc — nội dung này được giải thích chi tiết hơn ở Part 2.5 — Imperative vs Declarative của tài liệu.)

Nguồn tham khảo​

Nguồn gốc: Khóa "Certified Kubernetes Administrator (CKA)" — phần "Core Concepts" (Pods: khái niệm Pod, multi-container Pod, file định nghĩa YAML, demo tạo Pod, hướng dẫn practice test portal, lab giải bài Pods), 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.

Fact-check: