CKA, CKAD và hành trình học Kubernetes nghiêm túc hơn

Tôi bắt đầu từ chứng chỉ, nhưng ở lại vì Kubernetes

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.”

Hai góc nhìn trên cùng một cluster

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.

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.

Sai lầm đầu tiên là sưu tầm tài liệu

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:

• Một nguồn chính để giữ cấu trúc học.
• Tài liệu Kubernetes để kiểm tra khái niệm và cú pháp.
• Một cluster dùng cho thực hành.
• Một file ghi lại lỗi, giả thuyết và cách tôi đã kiểm chứng.

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ó.

Học bằng tay khác với học thuộc lệnh

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.creationTimestamp

Bố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'

YAML ngắn không có nghĩa là quyết định ít

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: 8080

Tạ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.

Phần khó nhất là đọc trạng thái khi mọi thứ sai

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:

1. Ghi lại trạng thái đang thấy.
2. Đưa ra một giả thuyết duy nhất.
3. Chọn một lệnh có thể xác nhận hoặc bác bỏ giả thuyết.
4. Chỉ thay đổi một thứ mỗi lần.
5. Ghi lại điều đã học được trước khi dọn lab.

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ự.

Áp lực thời gian và cái bẫy của sự vội vàng

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:

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.

Chứng chỉ có thể đo điều gì, và không thể đo điều gì

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:

• Hiểu các resource cốt lõi.
• Làm việc với terminal và tài liệu hiệu quả hơn.
• Luyện cách quan sát trạng thái dưới áp lực.
• Nhận ra phần kiến thức mình còn né tránh.

Nó không tự động chứng minh rằng tôi:

• Thiết kế được một platform phù hợp cho mọi tổ chức.
• Hiểu toàn bộ failure mode trong production.
• Có chiến lược backup và restore đáng tin cậy.
• Biết lúc nào Kubernetes là lựa chọn sai.

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.

Cách tôi đang tổ chức hành trình này

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:

• Học một nhóm khái niệm nhỏ.
• Tự giải thích lại bằng lời của mình.
• Làm lab mà không nhìn lời giải.
• Cố tình tạo một lỗi liên quan.
• Dọn resource và làm lại sau vài ngày.

Checklist hiện tại của tôi:

• Củng cố Pod, Deployment, Service và namespace.
• Tập đọc event, log và trạng thái rollout.
• Dùng ConfigMap, Secret và probe trong workload nhỏ.
• Hiểu sâu hơn về scheduling, taint và affinity.
• Luyện networking và storage bằng tình huống lỗi.
• Làm lại các lab cũ mà không dựa vào trí nhớ ngắn hạn.
• Chỉ đặt lịch thi khi kết quả luyện tập đủ ổn định.

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 muốn mang gì ra khỏi kỳ thi

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.