2.3. Core Concepts: ReplicaSets and Deployments

Mục lục

• 1. Vì sao cần Replication Controller / ReplicaSet
• 2. Tạo Replication Controller bằng file YAML
• 3. ReplicaSet
• 4. Labels và Selectors
• 5. Scale ReplicaSet
• 6. Các lệnh kubectl thường dùng với ReplicaSet
• 7. Deployments
• 8. Tip: dùng kubectl run/create để generate YAML nhanh trong kỳ thi
• 9. Các lệnh kubectl thường dùng với Deployment

---

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

Controller là lớp process chạy nền của Kubernetes: chúng giám sát các Kubernetes object và phản ứng tương ứng. Một trong các controller đó 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: chỉ có một Pod duy nhất chạy ứng dụng. Nếu ứng dụng crash và Pod fail, người dùng mất luôn đường vào ứng dụng. Để tránh chuyện đó, cần nhiều hơn một instance hay Pod chạy cùng lúc, để khi một cái fail thì ứng dụng trên cái còn lại vẫn phục vụ được.

💡 Hình dung: giữ đúng 1 Pod giống chỉ có 1 nhân viên trực tổng đài, người đó nghỉ ốm là cả công ty ngừng nhận cuộc gọi. Giữ nhiều Pod dự phòng giống có sẵn ca trực dự bị: 1 người vắng mặt, người khác vào thay ngay lập tức, khách gọi tới không hề hay biết có sự cố xảy ra.

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). Điều đó không có nghĩa là replication controller trở nên vô dụng khi chỉ định chạy một Pod duy nhất: ngay cả với một Pod, nó vẫn 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ụ, ban đầu chỉ 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à node đầu tiên đã hết tài nguyê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, vừa cân bằng tải giữa nhiều Pod trên các node khác nhau, vừa scale được ứng dụng khi nhu cầu tăng lên.

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

Có 2 thuật ngữ rất dễ lẫn vào nhau: ReplicationController và ReplicaSet. Cả 2 cùng một 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, công nghệ được khuyến nghị dùng hiện nay. Mọi điều đã bàn ở trên vẫn áp dụng cho cả 2, chỉ khác nhau vài chi tiết nhỏ trong cách hoạt động. Tài liệu này sẽ bám theo ReplicaSet cho mọi demo và triển khai về sau, nhưng trước khi tới đó, cần xem ReplicationController được khai báo bằng YAML ra sao, vì ReplicaSet gần như thừa hưởng nguyên cấu trúc này.

---

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. ReplicationController được hỗ trợ ở Kubernetes API version v1, nên set là v1. kind là ReplicationController. Dưới metadata, thêm một name, đặt là myapp-rc, kèm vài label như app và type với giá trị tương ứng. Tới đây, mọi thứ khá giống với cách đã tạo một Pod ở Part 2.2.

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. Ở đây replication controller tạo nhiều instance của một Pod, nên bên trong spec cần một phần template 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ó: tái sử dụng đúng nội dung pod definition file đã tạo ở Part 2.2, di chuyển toàn bộ vào phần template, ngoại trừ 2 dòng apiVersion và kind (RC đã có apiVersion/kind riêng ở cấp ngoài cùng rồi). Mọi thứ được di chuyển phải nằm dưới template, nghĩa là thụt vào bên phải và có nhiều khoảng trắng hơn dòng template, vì chúng là con của template.

Còn thiếu một thứ: chưa nói bao nhiêu replica cần trong ReplicationController. Thêm một property nữa vào spec tên replicas, rồi 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, tức là có số khoảng trắng bằng nhau trước chúng.

Gộp lại đúng những gì vừa nói, file rc-definition.yaml hoàn chỉnh trông như sau:

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx
  replicas: 3

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

kubectl create -f rc-definition.yaml

# Output:
replicationcontroller/myapp-rc created

Khi replication controller được tạo, việc đầu tiên nó làm là dựng các Pod từ pod definition template, đúng 3 Pod như đã khai báo. Xem danh sách replication controller đã tạo:

kubectl get replicationcontroller

# Output:
NAME       DESIRED   CURRENT   READY   AGE
myapp-rc   3         3         3       12s

Cột DESIRED/CURRENT/READY chính là bằng chứng trực tiếp cho khái niệm "duy trì đúng số lượng" vừa minh họa ở diagram trên. Xem các Pod do nó tạo ra:

kubectl get pods

# Output:
NAME             READY   STATUS    RESTARTS   AGE
myapp-rc-4kx8z   1/1     Running   0          12s
myapp-rc-9jf2m   1/1     Running   0          12s
myapp-rc-w7bqp   1/1     Running   0          12s

Cả 3 Pod đều bắt đầu bằng tên của replication controller, myapp-rc, cho thấy chúng đều do nó tạo tự động, không phải do ai đó kubectl run từng cái thủ công.

ReplicationController vẫn hoạt động tốt, nhưng đây là công nghệ cũ hơn. Phiên bản hiện đại và được khuyến nghị dùng thay thế là ReplicaSet, với ý tưởng gần như giống hệt và chỉ khác vài chi tiết quan trọng.

---

3. ReplicaSet

Phần ReplicationController đã xong, giờ tới ReplicaSet. Cấu trúc file của nó khá giống ReplicationController, cũng gồm apiVersion, kind, metadata, và spec.

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

Phần đặc tả (specification section) cũng gần như ReplicationController: vẫn có template cung cấp pod definition như trước, sao chép nội dung từ pod definition file, và replicas được set là 3. Nhưng giữa ReplicationController và ReplicaSet có một khác biệt lớn: 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.

💡 Hình dung: selector giống danh sách điểm danh của giáo viên chủ nhiệm: không quan trọng học sinh nào có mặt từ trước, học sinh nào vừa vào lớp; miễn tên có trong danh sách (khớp label) là được tính vào sĩ số. Thiếu bao nhiêu bạn so với sĩ số chuẩn (replicas), giáo viên (ReplicaSet) sẽ "gọi" thêm bấy nhiêu bạn mới.

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: field này 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, 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ó.

File replicaset-definition.yaml hoàn chỉnh:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx
  replicas: 3
  selector:
    matchLabels:
      app: myapp

Tạo và kiểm tra ReplicaSet:

kubectl create -f replicaset-definition.yaml

# Output:
replicaset.apps/myapp-replicaset created

kubectl get replicaset

# Output:
NAME               DESIRED   CURRENT   READY   AGE
myapp-replicaset   3         3         3       8s

kubectl get pods

# Output:
NAME                     READY   STATUS    RESTARTS   AGE
myapp-replicaset-2f8lk   1/1     Running   0          8s
myapp-replicaset-6vqzr   1/1     Running   0          8s
myapp-replicaset-tgm9x   1/1     Running   0          8s

Cách label và selector phối hợp với nhau, kể cả khi ReplicaSet gặp những Pod đã tồn tại sẵn từ trước, là nội dung của mục ngay sau đây.

---

4. Labels và Selectors

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

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

Còn lại một chuyện: ReplicaSet phải biết Pod nào cần giám sát, giữa hàng trăm Pod khác trong cluster đang chạy các ứng dụng khác nhau. Việc gán nhãn cho Pod ngay từ lúc tạo phát huy tác dụng ở chỗ này, vì các label đó trở thành 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 ReplicaSet đượ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? Vẫn cần, vì trong tương lai, nếu một trong các Pod fail, ReplicaSet phải tạo một Pod mới để duy trì đúng số lượng mong muốn. Muốn tạo được Pod mới thì phần định nghĩa template là bắt buộc: biết giám sát bao nhiêu Pod là chưa đủ, còn phải biết tạo lại Pod đó như thế nào.

---

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

# Output:
replicaset.apps/myapp-replicaset replaced

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

# Output:
replicaset.apps/myapp-replicaset scaled

Có thể input file định nghĩa, hoặc cung cấp tên ReplicaSet theo định dạng type/name (ví dụ kubectl scale --replicas=6 replicaset/myapp-replicaset). Nhưng cần nhớ: dùng tên file làm input sẽ không tự động cập nhật số replica trong file. Số replica trong file định nghĩa ReplicaSet vẫn 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 (Horizontal Pod Autoscaler), nhưng đó là một chủ đề nâng cao, sẽ bàn ở thời điểm sau. Nắm vững cách tạo, xem, và scale rồi, phần tiếp theo tổng hợp lại toàn bộ lệnh hay dùng với ReplicaSet, kể cả cách xử lý những lỗi hay gặp nhất khi tự lab.

---

6. Các lệnh kubectl thường dùng với ReplicaSet

Tự lab trên cluster local nào cũng được (Minikube, Kind, Docker Desktop Kubernetes). Output thực tế sẽ khác đôi chút (AGE, tên Pod...), nhưng cấu trúc và ý nghĩa các field là như nhau.

Tạo và xem ReplicaSet

kubectl create -f replicaset-definition.yaml
kubectl get replicaset

# Output:
NAME               DESIRED   CURRENT   READY   AGE
myapp-replicaset   3         3         3       8s

Xem chi tiết một ReplicaSet, hữu ích nhất khi debug, vì mục Events cho biết chính xác nó đang làm gì:

kubectl describe replicaset myapp-replicaset

# Output (rút gọn):
Name:         myapp-replicaset
Namespace:    default
Selector:     app=myapp
Replicas:     3 current / 3 desired
Pod Template:
  Containers:
   nginx:
    Image:      nginx
Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  8s    replicaset-controller  Created pod: myapp-replicaset-2f8lk

Scale ReplicaSet

kubectl scale --replicas=6 rs myapp-replicaset

# Output:
replicaset.apps/myapp-replicaset scaled

Hoặc sửa trực tiếp số replicas bằng kubectl edit rs myapp-replicaset, hay bằng kubectl replace -f replicaset-definition.yaml sau khi đã sửa file.

Sửa và xóa ReplicaSet

kubectl edit replicaset myapp-replicaset

⚠️ Lưu ý: sửa image trong ReplicaSet (qua kubectl edit) không tự động tạo lại các Pod đang chạy: ReplicaSet chỉ dùng template mới cho Pod được tạo sau này. Muốn áp dụng image mới ngay, phải chủ động xóa Pod cũ để ReplicaSet tạo Pod thay thế bằng template đã cập nhật.

kubectl delete rs replicaset-1 replicaset-2

# Output:
replicaset.apps "replicaset-1" deleted
replicaset.apps "replicaset-2" deleted

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

Debug lỗi ReplicaSet thường gặp

Lỗi	Nguyên nhân	Cách xử lý
no matches for kind "ReplicaSet" in version "v1"	Sai apiVersion — ReplicaSet cần apps/v1, không phải v1	Sửa apiVersion thành apps/v1; dùng kubectl explain replicaset để tra đúng version
selector does not match template labels	Label trong selector.matchLabels không khớp label của Pod trong template.metadata.labels	Sửa 1 trong 2 cho khớp nhau — 2 chỗ này luôn phải trùng
Pod ở ErrImagePull/ImagePullBackOff dù ReplicaSet đã đủ số lượng	Sai tên image trong template	kubectl edit rs <name> sửa image, rồi xóa Pod cũ để ReplicaSet tạo Pod mới với image đúng (xem lưu ý ở trên)

kubectl explain <resource> luôn là cách nhanh nhất để tra đúng apiVersion/field hợp lệ ngay trên terminal, không cần rời sang trình duyệt:

kubectl explain replicaset

# Output (rút gọn):
KIND:     ReplicaSet
VERSION:  apps/v1
DESCRIPTION:
     ReplicaSet ensures that a specified number of pod replicas are running...

Danh sách lệnh chính

Lệnh	Công dụng
kubectl create -f <file>.yaml	Tạo ReplicaSet (hay bất kỳ object nào) từ file YAML
kubectl get rs / get replicaset	Xem danh sách ReplicaSet, kèm DESIRED/CURRENT/READY
kubectl describe rs <name>	Xem chi tiết + Events — chỗ đầu tiên cần xem khi debug
kubectl scale --replicas=<n> rs <name>	Scale trực tiếp từ command line, không cần sửa file
kubectl replace -f <file>.yaml	Thay thế ReplicaSet bằng nội dung file đã sửa
kubectl edit rs <name>	Sửa trực tiếp ReplicaSet đang chạy (nhớ: không tự tạo lại Pod cũ)
kubectl delete rs <name> [<name2>...]	Xóa 1 hoặc nhiều ReplicaSet
kubectl explain <resource>	Tra nhanh đúng apiVersion/field hợp lệ của 1 loại object

Nắm được ReplicaSet rồi, còn một câu hỏi nữa cho môi trường production: ai đứng trên ReplicaSet để lo luôn cả việc rolling update, rollback, và pause/resume thay đổi. Lớp đứng trên đó là Deployment.

---

7. 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 lên production. Cần nhiều instance của web server cùng chạy chứ không phải chỉ một, 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à. Nhưng khi nâng cấp, không muốn đụng vào tất cả instance cùng lúc, vì việc đó có thể ảnh hưởng người dùng đang truy cập ứng dụng, nên muốn nâng cấp lần lượt từng cái một. 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: lúc đó cần khả năng rollback, undo lại đúng 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, mà 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.

💡 Hình dung: Deployment giống người quản lý dây chuyền sản xuất, ReplicaSet là một ca làm việc cụ thể, Pod là công nhân đứng máy trong ca đó. Khi đổi quy trình sản xuất (rolling update sang image mới), quản lý không đuổi hết công nhân cùng lúc mà thay từng người một bằng ca mới, nên dây chuyền không bao giờ ngừng hẳn. Đổi ý giữa chừng thì gọi lại đúng ca cũ (rollback).

Đến lúc này, tài liệu đã bàn về Pod, dùng để deploy một instance đơn lẻ của ứng dụng, với mỗi container được đóng gói trong Pod. Nhiều Pod như vậy được deploy bằng ReplicationController hoặc ReplicaSet. 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 cũng giống các component đã làm: bắt đầu bằng một deployment definition file. Nội dung của nó gần giống hệt replicaset definition file, ngoại trừ phần kind giờ là Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx
  replicas: 3
  selector:
    matchLabels:
      app: myapp

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

kubectl create -f deployment-definition.yaml

# Output:
deployment.apps/myapp-deployment created

kubectl get deployments

# Output:
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
myapp-deployment   3/3     3            3           10s

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

kubectl get replicaset

# Output:
NAME                          DESIRED   CURRENT   READY   AGE
myapp-deployment-7d8f9c6b5d   3         3         3       10s

Tới lượt ReplicaSet tạo ra Pod ở tầng cuối, và kubectl get pods cho thấy các Pod mang tên của cả Deployment và ReplicaSet:

kubectl get pods

# Output:
NAME                                READY   STATUS    RESTARTS   AGE
myapp-deployment-7d8f9c6b5d-2n5kp   1/1     Running   0          10s
myapp-deployment-7d8f9c6b5d-8qz4t   1/1     Running   0          10s
myapp-deployment-7d8f9c6b5d-x6vwr   1/1     Running   0          10s

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 ở trên (rolling update, undo, pause/resume) sẽ được xem xét ở các phần sau.

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

kubectl get all

# Output (rút gọn):
NAME                                    READY   STATUS    RESTARTS   AGE
pod/myapp-deployment-7d8f9c6b5d-2n5kp   1/1     Running   0          10s
pod/myapp-deployment-7d8f9c6b5d-8qz4t   1/1     Running   0          10s
pod/myapp-deployment-7d8f9c6b5d-x6vwr   1/1     Running   0          10s

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/myapp-deployment   3/3     3            3           10s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/myapp-deployment-7d8f9c6b5d   3         3         3       10s

Đúng như diagram ở trên: Deployment vừa được tạo, theo sau là ReplicaSet, rồi tới 3 Pod, cả 3 tầng hiện ra cùng lúc trong đúng 1 lệnh.

---

8. 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. Dùng kubectl run/kubectl create kèm --dry-run=client -o yaml để generate nhanh khung file thay vì viết tay từ đầu:

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 bằng kubectl create -f nginx-deployment.yaml. Đây là kỹ thuật dùng chung cho mọi loại object (Pod, Deployment, Service,...), không riêng gì ReplicaSet/Deployment, nên cheatsheet đầy đủ (kèm cả Service, option --replicas, và link tài liệu tham khảo) được gom về một chỗ duy nhất ở Part 2.5, mục Cheatsheet: Imperative Commands với kubectl, tránh lặp lại và dễ bảo trì hơn khi cần cập nhật.

Nắm được mẹo generate YAML nhanh này, phần cuối tổng hợp lại toàn bộ lệnh kubectl hay dùng nhất với Deployment, kèm cả những lỗi hay gặp khi tự lab.

---

9. Các lệnh kubectl thường dùng với Deployment

Tạo và xem Deployment

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

# Output:
deployment.apps/httpd-frontend created

kubectl get deploy

# Output:
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
httpd-frontend    3/3     3            3           14s

Xem chi tiết, cũng dựa vào mục Events để biết Deployment đang ready hay đang kẹt ở bước nào:

kubectl describe deployment httpd-frontend

# Output (rút gọn):
Name:                   httpd-frontend
Replicas:               3 desired | 3 updated | 3 total | 3 available
StrategyType:           RollingUpdate
Pod Template:
  Containers:
   httpd:
    Image:        httpd

Scale Deployment

kubectl scale deployment httpd-frontend --replicas=5

# Output:
deployment.apps/httpd-frontend scaled

Debug lỗi Deployment thường gặp

Lỗi	Nguyên nhân	Cách xử lý
no kind "Deployment" is registered for version "apps/v1"	kind viết sai case — YAML/Kubernetes phân biệt hoa thường, phải đúng Deployment (chữ D hoa), không phải deployment	Sửa lại đúng chữ hoa Deployment
Pod ở ErrImagePull/ImagePullBackOff, Deployment mãi không READY	Sai tên image trong template	kubectl describe pod <tên-pod> xem field Image để xác nhận, sửa lại đúng tên image rồi apply lại

Danh sách lệnh chính

Lệnh	Công dụng
kubectl create -f <file>.yaml	Tạo Deployment từ file YAML
kubectl create deployment <name> --image=<image> [--replicas=<n>]	Tạo nhanh Deployment bằng lệnh imperative
kubectl get deploy / get deployments	Xem danh sách Deployment, kèm READY/UP-TO-DATE/AVAILABLE
kubectl describe deployment <name>	Xem chi tiết + Events
kubectl scale deployment <name> --replicas=<n>	Scale Deployment
kubectl get all	Xem cả Deployment, ReplicaSet, Pod cùng lúc

Nắm vững Pod, ReplicaSet, và Deployment rồi, vẫn còn hai chỗ trống: làm sao expose các Pod này ra ngoài để người dùng truy cập được, và làm sao các Pod bên trong cluster tìm thấy nhau. Cả hai là chủ đề của Part 2.4: Services và Namespaces.

---

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, Deployments, tip generate YAML nhanh), 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.