Hành trình trở thành Kubestronaut qua góc nhìn của một SRE

Chào mọi người, mình là Nguyễn Ngọc Phú, hiện đang là Site Reliability Engineer tại Zalopay.

Gần đây mình vừa pass cả 5 chứng chỉ K8S của CNCF và trở thành Kubestronaut. Trong quá trình làm việc với kubernetes, mình nhận ra kiến thức của mình phần lớn đến từ việc gặp đâu học đó, nên có nhiều chỗ còn rời rạc và chưa thật sự hiểu rõ bản chất. Nên mình xem việc thi chứng chỉ như một cơ hội để học lại K8S một cách bài bản hơn.

Mình thi CKA từ vài tháng trước, sau đó tranh thủ thời gian nghỉ lễ 2/9 ôn thi tiếp 4 chứng chỉ còn lại là CKS, CKAD, KCNA và KCSA và may mắn là mình đã pass hết.

Trong bài viết này, mình muốn chia sẻ lại hành trình của mình, review từng chứng chỉ, những phần mình thấy khó, cũng như một vài kinh nghiệm nhỏ. Hy vọng bài viết sẽ có ích cho những bạn đang có ý định thi chứng chỉ K8S hoặc muốn trở thành Kubestronaut.

Từng link nguồn học mình đã để chi tiết trong bài viết mọi người có thể tham khảo nhé.

Động lực

Mình khá may mắn khi được làm việc tại Zalopay (thuộc VNG), nơi hệ thống chạy hoàn toàn trên K8S on-premise.

Khác với việc dùng các dịch vụ managed như EKS (AWS) hay GKE (Google Cloud), khi chạy on-premise thì mọi thứ từ control plane, etcd, network cho đến storage đều do team tự vận hành.

Thêm nữa, vì là sản phẩm thanh toán nên hệ thống luôn đòi hỏi tính High Availability (HA), uptime gần như tuyệt đối (99,999%) và bảo mật chặt chẽ, chỉ một sự cố nhỏ cũng có thể ảnh hưởng trực tiếp đến giao dịch của người dùng.

Nhờ vậy mà mình được tiếp xúc với K8S ở mức khá sâu, và khi tìm hiểu các chứng chỉ của CNCF, mình thấy nội dung thi bám sát với công việc hằng ngày: từ troubleshoot cluster, quản lý workload cho đến bảo mật hệ thống.

Lộ trình tổng quan

Thứ tự thi của mình là CKA > CKS > CKAD > KCNA > KCSA. Dưới đây là tóm tắt thời gian ôn và tài liệu cho từng chứng chỉ:

Nhìn chung, tài liệu chính của mình chỉ gói gọn trong 2 platform là KodeKloud và killer.sh. Không cần ôm quá nhiều nguồn, quan trọng là làm lab và mock exam cho thật quen tay.

Review 5 chứng chỉ qua góc nhìn của một SRE

1. CKA (Certified Kubernetes Administrator)

Lúc đầu, mình tự mua một con VPS, chia thành 3 VM bằng LXC rồi tự dựng một cụm K8S gồm 1 master và 2 worker để nghịch thử. Song song đó, mình học theo playlist trên YouTube của bác Piyush.

Sau khoảng hơn 1 tháng, mình đã nắm được hầu hết các concept cơ bản của K8S, nhưng phần troubleshoot thì vẫn khá đuối. Lý do là muốn luyện troubleshoot thì phải tự tạo kịch bản làm cluster bị broken rồi tự fix, việc này tốn công và khá mệt.

Đó là lúc mình tìm đến KodeKloud. Điểm mình thích nhất ở platform này là playground rất xịn, cùng rất nhiều bài lab và kịch bản troubleshoot có sẵn. Mình chỉ việc tập trung vào giải quyết vấn đề mà không cần mất thời gian setup môi trường.

Ngoài ra KodeKloud còn có cả series Ultimate Mock Exam để luyện thoải mái. Sau khoảng 2 tuần luyện trên KodeKloud, mình làm thêm 2 sessions thi thử trên killer.sh, 2 sessions này hoàn toàn miễn phí khi bạn đăng ký thi chứng chỉ nhé.

Nhận xét về độ khó của mock exam

• killer.sh: rất khó, mình đánh giá độ khó ngang với thi thật.
• KodeKloud: mình nghĩ chỉ khoảng 50% so với thi thật, phù hợp để luyện tay và làm quen dạng bài.

Trải nghiệm các câu hỏi trong phòng thi

• Network Policy: phần này ở CKA không khó. Dạng bài mình gặp là chọn ra cấu hình network policy phù hợp với yêu cầu đề bài rồi apply, chủ yếu cần đọc kỹ yêu cầu và hiểu đúng các rule.
• Migrate từ Ingress sang Gateway API: câu này không khó nhưng làm khá dài và lâu, từ việc tạo GatewayClass, Gateway, HTTPRoute, TCPRoute, đến setup TLS và route đúng service theo path. Nếu chưa quen tay thì rất dễ bị ngốn thời gian.
• Output theo custom-columns hoặc JSONPath: có vài câu yêu cầu dùng -o custom-columns hoặc -o jsonpath để ghi kết quả ra file. Mình nghĩ mình mất điểm ở những câu này vì kết quả không đúng format mà đề mong đợi. Lời khuyên là đọc thật kỹ yêu cầu về format và kiểm tra lại nội dung file trước khi chuyển câu.
• Helm: đây là câu mình thấy mất thời gian nhất vì chưa quen tay và không nhớ hết các thao tác như search repo, overwrite value khi install/upgrade, hay tìm xem trong tất cả các release được cài bằng Helm, deployment nào đang dùng một image cụ thể. Helm nghe thì đơn giản nhưng nếu không luyện trước thì vào phòng thi sẽ khá lúng túng.
• Troubleshoot: khó nhất vẫn là troubleshoot. Mình gặp một câu troubleshoot kubelet đang bị broken, nguyên nhân là đường dẫn tới file binary của kubelet bị sai, chỉ cần sửa lại cho đúng rồi restart kubelet là xong. Nhưng có một câu khác liên quan đến certificate của etcd thì mình không làm được, khá tiếc.

Góc nhìn SRE

Đây là chứng chỉ gần với công việc của SRE nhất, nhưng cũng có những điểm khác biệt giữa môi trường thi và thực tế mà mình nghĩ đáng chia sẻ:

• Môi trường thi khác với thực tế: các cluster trong đề thi hầu hết được dựng bằng kubeadm, các component trong control plane đều chạy dưới dạng static pod. Trong khi đó, các cụm K8S mình vận hành thực tế lại chạy các component này dưới dạng systemd service trên máy vật lý. Vì vậy việc debug hay nâng cấp cluster ngoài thực tế không đơn giản chỉ là chạy kubectl logs hay crictl logs là ra, mà phải hiểu rõ từng component được triển khai thế nào, log nằm ở đâu, cấu hình ra sao.
• Helm phổ biến hơn Kustomize: trong chương trình học có cả Kustomize, nhưng thực tế mình thấy Helm chart vẫn được dùng là chủ yếu.
• Scheduling là kiến thức dùng hằng ngày: taint, toleration, node label, node selector rất quan trọng và được dùng rất nhiều trên môi trường production, ví dụ để phân bổ workload lên đúng nhóm node phù hợp.
• Tư duy troubleshoot có hệ thống: những tình huống như node bị NotReady, kubelet không start được, certificate hết hạn hay pod bị Pending đều có thể xảy ra bất cứ lúc nào. Sau khi ôn CKA, mình biết bắt đầu từ đâu, kiểm tra component nào trước, thay vì mò từng chỗ như trước.

Nhưng phần mình thấy hay nhất ở CKA là được học lại toàn bộ các concept nền tảng về security và networking. Mình hiểu được vì sao security lại đi lên từ symmetric key, đến asymmetric key rồi đến certificate, vì sao K8S lại dùng overlay network.

Hay quá trình phát triển của K8S: từ việc dùng Docker, rồi bỏ Docker để chuyển sang chuẩn chung CRI, hay việc K8S không tích hợp sẵn giải pháp networking nào mà phải tích hợp riêng thông qua CNI như Calico, Cilium. Những thứ này nếu chỉ làm công việc vận hành hằng ngày thì có thể mình sẽ không để ý tới.

2. CKS (Certified Kubernetes Security Specialist)

Mình ôn khoảng 2 tuần, vẫn là combo KodeKloud và killer.sh. Vì ôn vào dịp lễ nên mình dành được toàn thời gian cho việc học, nhờ vậy mà hoàn thành khá nhanh.

Nhưng phải thừa nhận là lúc bắt đầu học CKS, mình khá ngợp vì lượng kiến thức rất nhiều và trải rộng: từ AppArmor, seccomp ở tầng hệ điều hành, audit policy, admission controller, OPA Gatekeeper, đến scan image, tạo SBOM, sandbox runtime như gVisor, và đặc biệt là Falco. Nhiều thứ trong số này mình gần như chưa đụng tới trong công việc hằng ngày.

Cách mình ôn khá cày: xem lần lượt hết khoảng 200 video của KodeKloud, làm hết tất cả các bài lab cho đến khi đạt điểm tuyệt đối mới thôi. Riêng với CKS, KodeKloud còn có series CKS Challenges mà mình thấy rất hay, vì các challenge mô tả những tình huống sát với thực tế nhất.

Những lần làm đầu tiên mình chỉ đạt khoảng 50~70%, nhưng mình luôn đặt mục tiêu làm đến khi đạt 100% mới được qua bài mới. Mình áp dụng y hệt với series Ultimate Mock Exam, mỗi bài làm đến 100% mới next. Đến killer.sh cũng vậy, làm đến khi đạt 100% cho session đó mới nghỉ.

Cách học này tốn sức nhưng giúp mình hiểu sâu từng dạng bài, vì muốn đạt 100% thì không thể chỉ làm đúng “na ná”, mà phải hiểu rõ vì sao mình sai.

Nhận xét về độ khó của mock exam

• KodeKloud: Với CKS, mình nghĩ độ khó tầm 70% so với thi thật.
• killer.sh: Độ khó nhỉnh hơn KodeKloud một xíu, tầm 80% so với thi thật.

Trải nghiệm các câu hỏi trong phòng thi

• SBOM và supply chain: phần này mình thấy khá dễ, chỉ cần chạy bom generate từ image để tạo SBOM, hoặc dùng kubesec scan để kiểm tra file manifest. Lưu ý sau khi fix xong thì chạy lại để chắc chắn kết quả đã PASS.
• Hardening các component trong control plane: chủ yếu là set permission cho các file config bằng chmod, chown (có thể phải tạo thêm user Linux nếu đề yêu cầu), tắt profiling, tắt anonymous access, chuyển authorization mode của kubelet sang Webhook,… Những phần này không khó nhưng có nhiều yêu cầu nhỏ trong một câu, phải đọc kỹ đề vì rất dễ bị sót.
• Audit policy: cũng không khó nhưng đề khá dài, cần đọc kỹ để viết policy đúng level cho từng loại resource. Lưu ý phải mount volume cho file policy và thư mục log trong manifest của kube-apiserver, sau đó cat file log để kiểm tra audit log đã được ghi đúng chưa.
• Network Policy: ngoài NetworkPolicy mặc định của K8S, đề còn yêu cầu viết CiliumNetworkPolicy. Cilium có một vài điểm khác như dùng endpointSelector thay cho podSelector, cách viết default deny egress, hay chặn/cho phép theo dải IP bằng toCIDR. Ngoài ra còn có phần bảo mật kết nối pod-to-pod bằng Istio, áp dụng PeerAuthentication với mTLS cho cả namespace.
• Docker: CKS không chỉ test K8S mà còn test cả kiến thức về Docker, như hardening cấu hình Docker daemon (ví dụ tắt TCP socket), review Dockerfile để tìm lỗi bảo mật (chạy bằng user root, hard-code secret, copy cả file .env hay file secret vào image), build và push image lên internal registry, hoặc docker save image ra file .tar.
• Admission Controller và webhook: dạng bài mình gặp là cấu hình ImagePolicyWebhook để kube-apiserver gửi image tới một webhook bên ngoài cluster để xác thực trước khi cho phép tạo pod. Câu này phải setup khá nhiều thứ: bật admission plugin, viết file AdmissionConfiguration, file kubeconfig trỏ tới webhook, cấu hình để kube-apiserver kết nối được tới webhook (ví dụ qua service ExternalName), rồi mount volume cho các file cấu hình vào kube-apiserver. Chỉ cần sai một bước là kube-apiserver không lên, nên nhớ backup manifest trước khi sửa.
• Upgrade cluster: phần này mình nghĩ sẽ không ra nhưng lại ra. Đề yêu cầu upgrade worker node lên cùng version với control plane. Nên luyện tập nhiều để nhớ các lệnh upgrade, vì nếu vừa tra docs vừa làm thì sẽ mất khá nhiều thời gian.
• Falco: đây là phần khó nhất với mình. Đề yêu cầu viết Falco rule để phát hiện container có hành vi bất thường và ghi kết quả ra file. Lúc thi mình có tra docs của Falco và viết theo, nhưng không hiểu sao rule vẫn không hoạt động. Muốn viết được Falco rule thì phải vững Linux, hiểu các system call và field mà Falco hỗ trợ, nên phần này cần luyện tập thật nhiều trước khi thi.

Góc nhìn SRE

Thực tế, khi apply security cho K8S trên production, phần lớn những gì mình làm xoay quanh namespace isolation, NetworkPolicy, RBAC và giới hạn quyền của container/pod như disable privileged, set read-only root filesystem, không chạy bằng user root hay drop all capabilities.

Những thứ này y hệt kiến thức trong CKS. Còn các phần sâu hơn như seccomp profile, AppArmor, hay viết Falco rule để phát hiện container bị mở shell hoặc đọc các file nhạy cảm như /etc/passwd, thì mình thấy ít khi được để ý và áp dụng. Sau khi thi cert, mình hiểu rõ hơn những lớp bảo mật này giải quyết vấn đề gì, và từ đó có thể propose thêm các cải tiến bảo mật cho những cụm K8S production mà mình đang quản lý.

3. CKAD (Certified Kubernetes Application Developer)

Khi đã có CKA và CKS thì CKAD trở nên nhẹ nhàng hơn khá nhiều. Kiến thức của CKAD overlap hơn 70% với CKA, phần còn lại chủ yếu là StatefulSet, Job/CronJob, multi-container pod, probe và deployment strategies (rolling update, blue green, canary).

Vì vậy mình chỉ dành khoảng 1 tuần để ôn những phần còn thiếu và làm mock exam vẫn trên KodeKloud và killer.sh (có tới 8 bài mock exam trên KodeKloud nên tha hồ luyện). Kết quả là mình đạt 100/100, điểm tối đa của bài thi này.

Nhận xét về độ khó của mock exam: Mình nghĩ KodeKloud và killer.sh độ khá ngang nhau và gần như bằng 90% so với thi thật.

Trải nghiệm các câu hỏi trong phòng thi

• Canary deployment: phần này chỉ cần để ý label selector của Service phải match được pod của cả 2 deployment, rồi scale số replica của mỗi deployment cho đúng tỷ lệ traffic mà đề yêu cầu là được.
• Job và CronJob: cần nhớ đúng format của schedule, gồm 5 thành phần tương ứng với 5 dấu *: phút, giờ, ngày trong tháng, tháng, ngày trong tuần. Để kiểm tra CronJob vừa tạo có đúng không, mình tạo một Job test từ CronJob đó rồi check log của pod, pod Completed là coi như xong. Ngoài ra CronJob còn có các field cần để ý như successfulJobsHistoryLimit và failedJobsHistoryLimit, còn Job thì có completions, parallelism, backoffLimit.
• Multi-container pod: với các container dùng image busybox, nhớ set command chạy lâu dài như sleep 3600. Nếu không, container sẽ start rồi exit ngay vì không có process nào chạy, pod sẽ bị restart liên tục và rơi vào trạng thái CrashLoopBackOff. Đọc kỹ đề để viết command cho đúng, hầu hết đều đơn giản như echo, tail -f, hay vòng lặp kiểu sh -c 'while true; do ...; sleep 10; done'.
• Troubleshoot Ingress: dạng bài mình gặp là đã setup Ingress nhưng curl vào không hoạt động. Lúc này nên kiểm tra pod của ingress controller có đang chạy không, nếu không thì đọc log để tìm nguyên nhân. Trường hợp của mình là do cấu hình default backend trỏ tới một Service không tồn tại, chỉ cần tạo Service đó hoặc bỏ cấu hình default backend là xong.
• Custom Resource: phần này cũng không khó. Chỉ cần đọc hiểu CRD đã được tạo sẵn, bao gồm các field, kiểu dữ liệu của từng field, giá trị min/max với các field integer (nếu có), sau đó tạo Custom Resource theo đúng định nghĩa đó là được.

Góc nhìn SRE

Mình nghĩ CKAD không chỉ dành cho SRE mà phù hợp với mọi developer.

Ví dụ trên production, sau khi deploy ứng dụng qua CI/CD, nếu dev muốn tinh chỉnh workload như scale up/down, tăng giảm resource request/limit hay tạo Ingress hostname cho service của mình, dev hoàn toàn có thể tự chỉnh Helm chart rồi tạo PR để SRE review và merge. Để làm được vậy, dev cần hiểu K8S và các resource object ở mức nhất định, và CKAD là lộ trình rất phù hợp cho việc đó.

Ngoài ra, mình muốn chia sẻ thêm về Operator, một phần khá hay được học trong CKAD (và cả CKA) nhưng lại không có trong đề thi. Trên thực tế, Operator được dùng rất nhiều trên K8S production để tự động vận hành các hệ thống như Redis, Kafka, MySQL hay Ceph.

Lấy MySQL làm ví dụ. Vì là stateful workload, chạy database trên K8S không chỉ là container hoá rồi tạo Deployment, mà còn phải lo replication, failover khi master chết, backup, rolling update đúng thứ tự,… Trước đây, những việc này thường được xử lý bằng script bên ngoài cluster, và K8S hoàn toàn không biết gì về chúng, nó chỉ biết pod có running hay không, chứ không biết replication có healthy hay master vừa nhảy role. Operator ra đời để giải quyết vấn đề này.

Về bản chất, Operator = CRD + custom controller, liên tục theo dõi các custom resource và đưa trạng thái thực tế về trạng thái mong muốn. Nói đơn giản, Operator giống như một SRE được viết bằng code, chạy 24/7 trong cluster và hiểu rõ cách vận hành ứng dụng đó.

4. KCNA (Kubernetes and Cloud Native Associate) và KCSA (Kubernetes and Cloud Native Security Associate)

Đây là hai chứng chỉ trắc nghiệm, thiên về lý thuyết nên nhẹ nhàng hơn nhiều so với ba chứng chỉ thực hành ở trên.

Với KCNA, thành thật là mình không ôn mà cứ thế đi thi, vì sau CKA, CKS và CKAD thì phần lớn kiến thức đã được bao phủ. Ngoài K8S, đề còn hỏi thêm về hệ sinh thái cloud native như observability với Prometheus và Grafana, các khái niệm SLA, SLO, SLI, hay GitOps với Argo CD, nhưng với mình thì đây đều là những thứ khá quen thuộc trong công việc hằng ngày.

Mình làm bài khoảng 20 phút là xong.

Với KCSA thì mình vẫn phải ôn thêm một chút dù đã có CKS. Đề thiên về lý thuyết với phạm vi khá rộng, từ mô hình 4C (Cloud, Cluster, Container, Code), bảo mật các component trong cluster, threat model, đến các công cụ bảo mật như Trivy, Falco, Istio và các framework compliance (PCI DSS, ISO,…).

Mình ôn trên KodeKloud khoảng 3 ngày rồi đi thi và làm bài trong khoảng 30 phút là xong.

Góc nhìn SRE

Tuy chỉ là hai chứng chỉ trắc nghiệm, nhưng nhờ ôn KCNA và KCSA mà mình biết thêm khá nhiều thứ trong hệ sinh thái K8S.

Ví dụ như cách một tính năng mới ra đời qua KEP (Kubernetes Enhancement Proposal), được phát triển bởi các SIG (Special Interest Group) phụ trách từng mảng như Network, Storage, Security, hay các open standard như OCI, CRI, CNI, CSI giúp K8S thay runtime, network, storage một cách linh hoạt.

Rồi các chuẩn compliance và vì sao mỗi chuẩn hợp với từng lĩnh vực: GDPR cho dữ liệu cá nhân, HIPAA cho y tế, PCI DSS cho thanh toán, NIST và CIS Benchmark cho hardening hệ thống. Mình cũng thấy khá hay khi tìm hiểu MITRE ATT&CK, bộ tổng hợp các chiến thuật và kỹ thuật tấn công trong thực tế, cùng bức tranh các công cụ bảo mật theo từng giai đoạn từ Develop, Distribute, Deploy đến Runtime.

Đôi khi học lý thuyết rồi chiêm nghiệm lại, mình mới thấy nhiều thứ đang dùng hằng ngày đều có lý do và bối cảnh phía sau cả.

5. Lời cảm ơn

Tổng kết lại, sau khi áp dụng voucher và hoàn tiền từ chương trình DevOps VietNam x Linux Foundation Education: đặc quyền kép, mình chi khoảng 26 triệu cho 5 chứng chỉ, cộng thêm khoảng 2 triệu tiền học trên KodeKloud.

Tính ra cả hành trình trở thành Kubestronaut của mình tốn khoảng 28 triệu. Nếu không có voucher và hoàn tiền thì con số này chắc chắn sẽ cao hơn nhiều (có thể lên đến hơn 5x), nên thật sự rất cảm ơn team DevOps VietNam đã tạo điều kiện cho anh em engineer Việt Nam như mình.

Hy vọng bài viết giúp ích được cho các bạn đang có ý định thi. Có gì thắc mắc cứ comment bên dưới, mình sẽ trả lời trong khả năng nhé!