Những suy nghĩ và kinh nghiệm trong quá trình chuẩn bị CKA, CKAD: xây nền Kubernetes, luyện tập có chủ đích, quản lý áp lực thời gian và tránh biến chứng chỉ thành mục tiêu duy nhất
Có một giai đoạn tôi nhìn CKA và CKAD như hai cột mốc khá rõ ràng: học đủ kiến thức, luyện đủ bài, đăng ký kỳ thi rồi chờ một kết quả xác nhận rằng mình đã hiểu Kubernetes.
Cách nghĩ ấy rất hấp dẫn vì nó biến một hệ thống rộng lớn thành một con đường có điểm kết thúc. Tôi chỉ cần đi đúng lộ trình, đánh dấu từng mục và cố gắng không lạc sang những chủ đề chưa cần thiết.
Nhưng càng chuẩn bị, tôi càng thấy Kubernetes không vận hành theo cách gọn gàng như một checklist. Mỗi khái niệm đều nối sang một khái niệm khác. Deployment dẫn tới ReplicaSet, Pod dẫn tới scheduling, Service dẫn tới networking, còn một lỗi tưởng như nằm trong YAML đôi khi lại bắt đầu từ DNS hoặc quyền truy cập.
Tôi vẫn muốn chuẩn bị cho CKA và CKAD. Chỉ là mục tiêu đã thay đổi đôi chút: chứng chỉ không còn là bằng chứng duy nhất rằng tôi biết Kubernetes. Nó trở thành một lý do đủ mạnh để tôi học nghiêm túc hơn, đều đặn hơn và trung thực hơn với những phần mình chưa hiểu.
“Chứng chỉ cho tôi một deadline. Việc học cho tôi một cách nhìn mới về hệ thống.”
CKA và CKAD cùng nói ngôn ngữ Kubernetes, nhưng chúng khiến tôi nhìn cluster từ hai vị trí khác nhau.
Khi nghĩ theo hướng CKA, tôi thường đặt câu hỏi từ phía hệ thống: node có khoẻ không, workload được schedule thế nào, network và storage đang hoạt động ra sao, mình sẽ tìm lỗi ở đâu nếu một phần của cluster ngừng đáp ứng.
Khi nghĩ theo hướng CKAD, câu hỏi dịch chuyển về phía ứng dụng: container cần cấu hình gì, khi nào Pod sẵn sàng nhận traffic, rollout có an toàn không, dữ liệu nào cần được giữ lại và manifest nên biểu đạt ý định của ứng dụng như thế nào.
| Góc nhìn | Câu hỏi tôi thường đặt ra | Điều dễ bỏ quên |
|---|---|---|
| CKA | Cluster đang vận hành ra sao? | Ứng dụng có thực sự phục vụ tốt không? |
| CKAD | Ứng dụng nên chạy thế nào? | Hạ tầng phía dưới đang giới hạn điều gì? |
| Cả hai | Trạng thái mong muốn có đạt được không? | Ai sẽ quan sát và phản ứng khi nó không đạt? |
Tôi không xem đây là hai thế giới tách biệt. Một người phát triển ứng dụng hiểu cluster sẽ viết workload dễ vận hành hơn. Một người vận hành hiểu vòng đời ứng dụng sẽ tránh biến mọi sự cố thành câu chuyện “restart Pod là được”.
Điều này cũng ảnh hưởng tới thứ tự học của tôi. Thay vì hỏi “nên thi chứng chỉ nào trước?”, tôi bắt đầu hỏi “lỗ hổng kiến thức hiện tại của mình nằm ở phía cluster hay phía workload?”. Câu trả lời ấy hữu ích hơn một lộ trình chung dành cho tất cả mọi người.
Khi bắt đầu, tôi có quá nhiều tài liệu và quá ít thời gian thật sự ngồi với cluster.
Một khoá học đang xem dở. Một playlist được đánh dấu “rất quan trọng”. Vài repository chứa bài lab. Nhiều tab tài liệu chính thức. Thêm một bảng theo dõi tiến độ đủ đẹp để khiến tôi cảm thấy mình đang học, dù phần lớn thời gian chỉ dành cho việc tổ chức thứ sẽ học sau này.
Tài liệu không thiếu. Sự tập trung mới thiếu.
Tôi từng chuyển sang một video khác mỗi khi gặp đoạn khó hiểu. Cách đó tạo cảm giác tiến bộ vì nội dung luôn mới, nhưng kiến thức không có thời gian lắng xuống. Sau vài tuần, tôi nhận ra mình có thể nhận diện nhiều thuật ngữ mà không thể tự giải thích chúng.
Sau đó tôi thu hẹp lại:
Việc bỏ bớt tài liệu khiến tôi hơi bất an. Tôi luôn có cảm giác một khoá học khác có thể giải thích tốt hơn. Nhưng chính giới hạn đó buộc tôi ngừng tìm lời giải thích hoàn hảo và bắt đầu làm việc với điều mình đang có.
CKA và CKAD đều khiến terminal trở thành một phần quan trọng của quá trình chuẩn bị. Tôi muốn thao tác nhanh hơn, nhưng cũng sớm nhận ra tốc độ có hai loại.
Loại thứ nhất đến từ việc hiểu mình cần tạo resource nào, kiểm tra trạng thái gì và đọc thông tin ở đâu. Loại thứ hai đến từ việc ghi nhớ một chuỗi ký tự rồi gõ lại thật nhanh.
Loại thứ hai dễ đo hơn. Loại thứ nhất hữu ích hơn.
kubectl get pods -A -o wide
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --tail=100
kubectl get events -n <namespace> --sort-by=.metadata.creationTimestampBốn lệnh này không đặc biệt. Điều quan trọng là tôi có biết khi nào dùng chúng và đang tìm dấu hiệu gì trong kết quả hay không.
Tôi từng cố nhớ thật nhiều alias. Một số alias giúp giảm thao tác lặp lại, nhưng chúng cũng có thể che đi cấu trúc của lệnh khi nền tảng chưa vững. Bây giờ tôi chỉ giữ những thứ dùng đủ thường xuyên để không phải suy nghĩ:
alias k=kubectl
export do='--dry-run=client -o yaml'Một manifest đơn giản vẫn chứa nhiều quyết định vận hành:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 2
template:
spec:
containers:
- name: api
image: ghcr.io/helios/api:1.0.0
readinessProbe:
httpGet:
path: /health/ready
port: 8080Tại sao là hai replica? Endpoint readiness có phản ánh khả năng phục vụ thật không? Nếu image khởi động chậm thì chuyện gì xảy ra? Khi phiên bản mới lỗi, rollout sẽ dừng ở đâu?
Tôi cố tập thói quen đọc YAML như đọc một tập hợp giả định, không chỉ như cú pháp cần đúng indentation.
Khi lab chạy đúng, tôi thường học được ít hơn mình tưởng. Tôi áp dụng manifest, nhìn trạng thái Running, rồi nhanh chóng chuyển sang chủ đề tiếp theo.
Khi lab lỗi, phản xạ đầu tiên của tôi từng là xoá resource và tạo lại. Đôi lúc cách đó làm mọi thứ chạy, nhưng nó cũng xoá mất cơ hội hiểu nguyên nhân.
Sau này, tôi ép bản thân dừng lại lâu hơn:
Những ghi chú như vậy không đẹp bằng một sơ đồ kiến thức hoàn chỉnh. Nhưng chúng gắn khái niệm với một trải nghiệm cụ thể, nên tôi nhớ lâu hơn và ít hoảng hơn khi gặp lại trạng thái tương tự.
Khi nghĩ tới kỳ thi thực hành, tôi khó tránh khỏi việc quan tâm đến tốc độ. Tôi bắt đầu bấm giờ, dùng phím tắt, mở tài liệu bằng Ctrl + K và cố giảm mọi thao tác thừa.
Việc luyện với thời gian là cần thiết, nhưng làm quá sớm khiến tôi hình thành thói quen xấu: đọc đề vội, sửa nhiều thứ cùng lúc và bỏ qua bước kiểm tra cuối.
Tôi phải học cách phân biệt ba giai đoạn:
| Giai đoạn | Điều tôi ưu tiên | Điều chưa cần tối ưu |
|---|---|---|
| Học khái niệm | Hiểu resource và mối quan hệ | Tốc độ gõ lệnh |
| Luyện có chủ đích | Tự làm, đọc lỗi, kiểm chứng | Điểm số giả lập |
| Luyện thời gian | Chọn chiến lược và thao tác gọn | Học thêm quá nhiều chủ đề mới |
Nếu chưa hiểu vì sao Service không có endpoint, việc gõ kubectl get endpoints nhanh hơn nửa giây không giúp được nhiều. Tốc độ nên là kết quả của sự rõ ràng, không phải cách thay thế sự rõ ràng.
Tôi cũng cố chấp nhận rằng có những ngày mình học chậm. Một buổi chỉ hiểu rõ label và selector vẫn có giá trị hơn việc lướt qua năm chủ đề rồi không thể tự dựng lại chúng vào hôm sau.
Tôi không cho rằng chứng chỉ vô nghĩa. Một mục tiêu có cấu trúc giúp tôi lấp những khoảng trống mà công việc hằng ngày chưa chắc chạm tới. Nó cũng buộc tôi thực hành thay vì chỉ đọc.
Nhưng chứng chỉ không thể thay thế kinh nghiệm vận hành một hệ thống có người dùng, dữ liệu và hậu quả thật.
Nó có thể thúc đẩy tôi:
Nó không tự động chứng minh rằng tôi:
Tôi muốn giữ cả hai mặt đó trong đầu. Nếu thần thánh hoá chứng chỉ, tôi dễ học để vượt qua một bài đánh giá. Nếu phủ nhận hoàn toàn, tôi bỏ qua một khuôn khổ khá tốt để rèn tính kỷ luật.
Tôi không dùng một lịch học quá chi tiết vì lịch càng phức tạp càng dễ trở thành công việc quản lý lịch. Tôi chỉ giữ một nhịp đơn giản:
Checklist hiện tại của tôi:
Tôi tham khảo Kubernetes Documentation để kiểm tra khái niệm và kubectl quick reference khi cần nhớ cú pháp. Với thông tin về chứng chỉ, tôi chỉ dựa vào trang chính thức của Linux Foundation Training.
Tôi tránh xây lộ trình dựa trên các con số dễ thay đổi như giá, thời lượng hoặc chính sách kỳ thi. Những thông tin ấy nên được kiểm tra lại ở nguồn chính thức vào thời điểm đăng ký.
Tôi chưa biết kết quả cuối cùng của hành trình này sẽ như thế nào. Có thể tôi sẽ chọn CKA trước, cũng có thể CKAD phù hợp hơn với công việc đang làm khi thời điểm đăng ký đến.
Nhưng tôi biết mình không muốn kết thúc với một bộ lệnh được ghi nhớ vừa đủ để vượt qua kỳ thi rồi nhanh chóng biến mất.
Tôi muốn giữ lại khả năng nhìn một trạng thái lạ mà không hoảng, biết bắt đầu từ đâu khi workload không hoạt động và hiểu rằng mỗi manifest đều đang mô tả một cam kết vận hành.
CKA và CKAD cho tôi hai hướng nhìn. Một hướng đi từ cluster tới ứng dụng. Hướng còn lại đi từ ứng dụng xuống cluster. Ở giữa hai hướng ấy là phần tôi thấy đáng học nhất: cách một ý định trở thành trạng thái đang chạy, và cách mình phản ứng khi trạng thái đó không còn đúng.
Chứng chỉ có thể là điểm đánh dấu tốt.
Nhưng tôi hy vọng điều ở lại lâu hơn sẽ là thói quen quan sát, đặt câu hỏi và kiểm chứng.
Tôi đang chuẩn bị cho một kỳ thi, nhưng thứ tôi thật sự muốn xây dựng là năng lực có thể dùng sau khi kỳ thi kết thúc.