inflearn logo

Khởi động lại, chậm đi 4 lần, lỗi 502 khi triển khai — khi chỉ dịch vụ của bạn gặp sự cố trên Kubernetes, hãy tự tái hiện và khắc phục 8 sự cố thường gặp.

Sau phần nhập môn Kubernetes, khi dịch vụ của tôi gặp sự cố. Chỉ dựa vào các triệu chứng như khởi động lại, chạy chậm, lỗi 502 hay triển khai bị treo, dùng kubectl và các chỉ số để xác định nguyên nhân rồi khắc phục. Trên Kubernetes cục bộ ở máy tính xách tay, tự tạo ra 8 sự cố, sau đó đo và so sánh các chỉ số trước và sau khi sửa với cùng một mức tải.

1 học viên đang tham gia khóa học này

Độ khó Trung cấp trở lên

Thời gian Không giới hạn

Kubernetes
Kubernetes
Docker
Docker
devops
devops
container
container
Kubernetes
Kubernetes
Docker
Docker
devops
devops
container
container

Bạn sẽ nhận được điều này sau khi học.

  • Tìm OOMKilled và mã thoát 137 trong lastState của Pod đang khởi động lại, đồng thời giải thích vì sao chúng không xuất hiện trong nhật ký ứng dụng.

  • Điều chỉnh giới hạn heap của JVM khớp với giới hạn bộ nhớ của container để ứng dụng tự thông báo thay vì bị buộc tắt mà không có cảnh báo.

  • Trong một dịch vụ chưa chết nhưng đang chậm lại, hãy đếm trực tiếp tình trạng throttling CPU bằng cpu.stat và đừng để số liệu trung bình của kubectl top đánh lừa.

  • Phân biệt các phép kiểm tra liveness, readiness và startup để ngăn ứng dụng khởi động chậm bị khởi động lại liên tục.

  • Phân biệt chủ thể phản hồi (Ingress hay ứng dụng) dựa trên mã 404·502·503·504, đồng thời xác định các vấn đề về viết lại đường dẫn, bộ chọn Service, cổng và tên DNS.

  • Đo khoảng thời gian HPA tự động mở rộng bị trễ và ứng phó bằng số lượng replica tối thiểu, đồng thời giảm số lần gián đoạn trong quá trình triển khai xuống 0 nhờ thời gian chờ kết thúc và xả tải.

  • Phát hiện đợt triển khai bị đình trệ do nhập sai secret key thông qua rollout status và progress deadline.

Sau khi làm quen với Kubernetes, khi dịch vụ của tôi gặp trục trặc.

Chỉ dựa vào các triệu chứng như khởi động lại, chậm, lỗi 502 hay triển khai bị treo, dùng kubectl và các chỉ số để xác định nguyên nhân rồi khắc phục. Trên Kubernetes cục bộ của máy tính, tự tạo ra 8 sự cố, khắc phục xong rồi đo các con số trước và sau với cùng một mức tải.

Phần lớn các khóa học Kubernetes đều dựng một cụm rồi lần lượt tìm hiểu từng tính năng. Khóa học này tập trung vào những lúc dịch vụ của bạn gặp sự cố trên Kubernetes đã được người khác dựng sẵn. Bắt đầu từ một triệu chứng (khởi động lại, độ trễ, 5xx, phản hồi trống, bản triển khai bị treo), bạn sẽ dùng kubectl và các chỉ số kernel để xác định vấn đề nằm ở tầng nào, rồi đo đạc trước và sau khi khắc phục với cùng một tải. Tất cả con số và thông báo trên màn hình đều là kết quả thực tế được chạy trong môi trường thực hành.

Sau khi hoàn thành khóa học này, bạn sẽ có thể...

  • Tìm OOMKilled và mã thoát 137 bằng lastState trong Pod khởi động lại, đồng thời giải thích vì sao chúng không được ghi lại trong nhật ký ứng dụng.

  • Điều chỉnh giới hạn heap của JVM cho khớp với giới hạn bộ nhớ của container, để ứng dụng tự thông báo thay vì bị buộc dừng trong im lặng.

  • Với dịch vụ chậm nhưng chưa chết, hãy trực tiếp đếm mức throttling CPU bằng cpu.stat, đừng để số liệu trung bình của kubectl top đánh lừa.

  • Phân biệt các probe liveness, readiness và startup để ngăn tình trạng khởi động lại liên tục ở những ứng dụng khởi động chậm.

  • Dựa vào các mã 404·502·503·504, xác định bên trả lời là Ingress hay ứng dụng, đồng thời tìm ra vấn đề về viết lại đường dẫn, selector của Service, cổng hoặc tên DNS.

  • Đo lường những khoảng thời gian HPA phản ứng chậm, chuẩn bị trước với số lượng bản sao tối thiểu, và đưa số lần gián đoạn trong quá trình triển khai về 0 nhờ thời gian chờ kết thúc và drain.

  • Phát hiện đợt triển khai bị dừng do gõ sai khóa bí mật bằng rollout status và thời hạn tiến độ.

Những người phù hợp với khóa học này

  • Lập trình viên backend đã học khóa nhập môn Kubernetes và giờ muốn tìm nguyên nhân khi dịch vụ của mình gặp sự cố bất thường trên Kubernetes.

  • Tôi là nhà phát triển, trong đó nhóm khác vận hành cụm, còn tôi chỉ chịu trách nhiệm về các tệp manifest và ứng dụng.

  • Người cứ mỗi lần xảy ra sự cố lại chỉ hỏi "Có phải vấn đề hạ tầng không?" rồi chờ đợi.

Chương trình học (7 phần · 40 bài · khoảng 300 phút)

  • Phần 0. Thành công đầu tiên: xử lý sự cố đầu tiên chỉ trong 5 phút — Demo hoàn chỉnh: khắc phục 8 sự cố của Loop Market chỉ dựa trên triệu chứng, tìm ra nguyên nhân đầu tiên trong 5 phút: catalog khởi động lại do OOMKilled, môi trường thực hành và các điểm kiểm tra: up.sh và checkpoint.sh, bộ công cụ kubectl tối thiểu: get·describe·events·logs --previous, trình tự chẩn đoán và bảng theo dõi trên một trang: triệu chứng → tầng → lệnh.

  • Phần 1. Bộ nhớ · JVM — OOMKilled xảy ra như thế nào: giới hạn bộ nhớ của container, vì sao không được ghi vào nhật ký ứng dụng: exit 137 và lastState, bộ nhớ JVM = heap + phần còn lại: MaxRAMPercentage, khắc phục và xác nhận: thiết lập heap trong giới hạn, trước → sau khi khởi động lại, yêu cầu và giới hạn bộ nhớ: dành chỗ và ngắt, kiểm tra phần: đã khắc phục sự cố 1/8, số lần khởi động lại trước → sau.

  • Mục 2. CPU throttling — Tái hiện sự cố 2: không có tiến trình nào bị dừng nhưng độ trễ tăng gấp bốn, yêu cầu và giới hạn CPU: chu kỳ 100ms và quota, đếm trực tiếp số lần throttling bằng cpu.stat, top chỉ báo 38m mà sao vẫn chậm: cái bẫy của giá trị trung bình, khắc phục và đo trước→sau: độ trễ·throttling trước→sau, nên bỏ hay tăng giới hạn: tiêu chí quyết định và kiểm tra mục (2/8)

  • Phần 3. Probe và khởi động lại — Tái hiện sự cố 4: chỉ phiên bản mới khởi động lại 4 lần sau 75 giây, sự khác nhau giữa readiness, liveness và startup, đọc nguyên nhân qua các sự kiện và lý do phiên bản cũ vẫn trụ được, khắc phục bằng startupProbe và so sánh trước→sau khi khởi động lại (3/8), cấu hình còn sót lại dù đã dùng apply để khôi phục: cái bẫy của replace và khôi phục

  • Mục 4. Đường dẫn yêu cầu và tên gọi — tái hiện sự cố 1: /catalog vẫn hoạt động cho đến hôm qua nhưng nay trả về 404, lần theo Ingress → Service → Pod, chẩn đoán và khắc phục: viết lại đường dẫn (4/8), khi selector của Service không khớp khiến danh sách endpoint trống, 502·503·504 — ai đã phản hồi, tái hiện sự cố 7: địa chỉ bị gõ sai catalog-api và quy tắc đặt tên DNS (5/8)

  • Mục 5. Tự động mở rộng và triển khai — Tái hiện sự cố 5: tải tăng đột biến nhưng trong 30 giây đầu chỉ có 1 máy chủ, công thức HPA: tỷ lệ phần trăm so với lượng yêu cầu, vì sao bị trễ: chu kỳ thu thập chỉ số và quyết định mở rộng, Pod khởi động mất 2 giây, biện pháp: bắt đầu với tối thiểu 3 máy chủ, p95 885ms → 457ms(6/8), tái hiện sự cố 6: 12 lỗi trong khi triển khai, drain và thời gian chờ kết thúc giúp giảm từ 12 lỗi → 0 lỗi(7/8)

  • Phần 6. Cấu hình · Capstone — Tái hiện sự cố 8: Gõ sai khóa bí mật và triển khai bị treo, tìm nguyên nhân triển khai bị treo: rollout status và maxSurge (8/8), Hướng dẫn capstone: một tờ danh sách kiểm tra chẩn đoán, Capstone A: Tự chẩn đoán một bộ sự cố chưa từng gặp, Capstone B: Tự chẩn đoán các triệu chứng đan xen, Lời giải capstone và toàn bộ trước → sau, Bước tiếp theo

Môi trường thực hành

Thực hành được tiến hành trên Kubernetes cục bộ (kind) của máy tính, với hai dịch vụ (catalog·order) của trung tâm thương mại ảo “Loop Market”. Chỉ cần chạy up.sh một lần là cụm, ingress, hệ thống thu thập chỉ số và các dịch vụ sẽ khởi chạy; checkpoint.sh giúp nhanh chóng tạo trạng thái bắt đầu của từng bài học. Tài liệu thực hành bao gồm 8 tập lệnh chèn lỗi, 2 bộ lỗi capstone, công cụ tạo tải và bảng kiểm chẩn đoán.

Kiến thức tiên quyết

  • Đã từng nghe đến Pod, Deployment, Service (ở mức độ khóa học nhập môn)

  • Đã từng chạy lệnh trong terminal.

  • Mac hoặc Linux có Docker đang chạy (khuyến nghị Docker có ít nhất 4 CPU và 6GB bộ nhớ)

Những nội dung không được đề cập trong khóa học này

  • Cài đặt và vận hành cụm (kubeadm, quản lý node)

  • Helm, công cụ triển khai và lưới dịch vụ

  • Triển khai công cụ truy vết phân tán và khả năng quan sát

  • Cấu hình Kubernetes được quản lý trên đám mây

Thông tin hướng dẫn

Lời thuyết minh trong video là giọng nói tổng hợp bằng AI. Các lệnh, chỉ số và kết quả trên màn hình là đầu ra thực tế được tạo khi chạy trong môi trường thực hành. Tất cả dữ liệu đều là dữ liệu giả lập phục vụ đào tạo; các con số có thể thay đổi tùy theo môi trường thực thi.

Khuyến nghị cho
những người này

Khóa học này dành cho ai?

  • Lập trình viên backend đã học khóa nhập môn Kubernetes và giờ muốn tìm nguyên nhân khi dịch vụ của mình hoạt động bất thường trên Kubernetes.

  • Cluster do nhóm khác vận hành, còn tôi là lập trình viên chỉ phụ trách manifest và ứng dụng.

  • Người mỗi lần xảy ra sự cố đều chỉ hỏi "Có phải vấn đề về hạ tầng không?" rồi chờ đợi

Cần biết trước khi bắt đầu?

  • Đã từng nghe nói đến Pod, Deployment, Service (ở mức độ khóa học nhập môn)

  • Kinh nghiệm thử chạy lệnh trong terminal

  • Máy Mac hoặc Linux chạy Docker (khuyến nghị Docker có ít nhất 4 CPU và 6 GB bộ nhớ)

Xin chào
Đây là dorian05202988

Xác minh sự nghiệp

Tôi là một chuyên gia dữ liệu với hơn 20 năm kinh nghiệm trong lĩnh vực cơ sở dữ liệu và CNTT. Trong vai trò DBA và quản lý nhóm Nền tảng Cơ sở dữ liệu, tôi phụ trách các nền tảng cơ sở dữ liệu, với chuyên môn về MySQL, PostgreSQL, Oracle, MongoDB, tinh chỉnh SQL, AWS, Terraform và Python. Dựa trên kinh nghiệm trong các lĩnh vực trò chơi, tài chính và dịch vụ CNTT, tôi trình bày về cơ sở dữ liệu và kiến trúc đám mây. Tôi đã xuất bản 『Học các mẫu SQL tinh chỉnh thực tế Oracle』 và 『Sổ tay ứng dụng dự án thực tế Oracle Pro*C』, đồng thời thuyết trình về serverless, lựa chọn cơ sở dữ liệu và chiến lược đa cơ sở dữ liệu tại AWS Summit 2018·2019 và sự kiện 데이터야 놀자 2020. Gần đây, tôi tập trung vào phân tích và khuyến nghị tinh chỉnh truy vấn chậm bằng Bedrock LLM, tự động hóa việc tính toán thông số DB, cũng như quy trình tra cứu thông qua máy chủ DB Meta MCP và bot Slack. Tôi giải thích về tự động hóa cơ sở dữ liệu dành cho nhà phát triển và việc ứng dụng AI vào công việc dành cho người không chuyên về phát triển thông qua các bài thực hành phù hợp với đối tượng và mục tiêu của từng khóa học. Thay vì áp dụng nguyên xi các đề xuất của AI, tôi truyền đạt các tiêu chí đánh giá như kiểm tra tính tương đương của kết quả, kế hoạch thực thi và điều kiện quan sát; nếu thiếu căn cứ thì tạm thời chưa áp dụng. Dữ liệu vận hành của công ty và thông tin xác thực không được đưa vào tài liệu giảng dạy.

Thêm

Chương trình giảng dạy

Tất cả

40 bài giảng ∙ (4giờ 59phút)

Tài liệu khóa học:

Tài liệu bài giảng
Ngày đăng: 
Cập nhật lần cuối: 

Đánh giá

Chưa có đủ đánh giá.
Hãy trở thành tác giả của một đánh giá giúp mọi người!

Khóa học khác của dorian05202988

Hãy khám phá các khóa học khác của giảng viên!

Khóa học tương tự

Khám phá các khóa học khác trong cùng lĩnh vực!

Ưu đãi có thời hạn

56.320 ₫

20%

1.449.050 ₫