DevOps 31/08/2026 8 phút

Dựng namespace riêng rồi tưởng đã có tường lửa — nhưng pod ở 'dev' vẫn gọi thẳng được cơ sở dữ liệu ở 'prod', chỉ cần đoán đúng tên

Namespace chia không gian TÊN, không chia không gian MẠNG — mặc định mọi pod gọi được mọi pod xuyên namespace. Đo cách dựng ranh giới thật bằng NetworkPolicy: chặn hết rồi mở dần theo nhãn, và cái bẫy VÀ-so-với-HOẶC chỉ khác một dấu gạch đầu dòng nhưng nới rộng quyền một cách im lặng. NetworkPolicy thực thi ở tầng CNI nên chặn cả khi gọi thẳng podIP, nhưng chính CNI phải hỗ trợ — plugin không hỗ trợ thì chính sách của bạn chỉ là văn bản, không lỗi, không cảnh báo.

DevOps 31/08/2026 7 phút

Tôi cấp một ServiceAccount đúng quyền 'chỉ đọc' Secret — rồi đọc ra ngay SieuBiMat123, và ba quyền nghe vô hại khác hoá ra tương đương quyền quản trị

Cấp quyền từng lớp cho một ServiceAccount rồi đo chính xác nó mở ra được gì. Role bó rất chặt (đúng động từ, đúng tài nguyên, đúng namespace), nhưng 'chỉ đọc' Secret là đọc được mọi mật khẩu vì base64 không phải mã hoá. Ba quyền nghe vô hại trong một bản YAML — create pods, get secrets, create rolebindings — đều là đường leo thang lên quyền toàn cụm. Và kubectl auth can-i là cách duy nhất kiểm quyền thực tế thay vì đọc YAML rồi đoán.

DevOps 31/08/2026 8 phút

Pod in ra 400.000 dòng nhật ký, nằm sờ sờ 53 MB trên đĩa — kubectl logs trả về đúng 0 dòng, không một lời cảnh báo

kubectl logs là lệnh ai cũng gõ đầu tiên khi có sự cố — bài này đo nó thực sự đọc gì và không đọc gì. Log là tệp văn bản trên đĩa node, không qua control plane; kubectl logs chỉ đọc tệp HIỆN TẠI, nên 400.000 dòng đã xoay vòng ra file khác trả về 0 dòng không lỗi. Hệ quả đáng sợ: pod ồn ào tự xoá log của chính mình, và đúng lúc sự cố thì nó in nhiều nhất nên chính phần đầu sự cố bị đẩy ra khỏi tầm với. Thêm: containerLogMaxSize 10Mi không phải trần cứng — đo được 55 MB vì kubelet chỉ kiểm định kỳ.

DevOps 31/08/2026 8 phút

Ba lỗi mạng hoàn toàn khác nhau trong Kubernetes cho ra đúng một thông báo và đúng một thời gian — và một lệnh duy nhất phân biệt được cả ba

Nhãn sai, cổng sai, pod chưa sẵn sàng — ba nguyên nhân khác hẳn nhau nhưng đều ra ConnectionRefused ~0 ms, và DNS thì phân giải tốt ở cả ba nên nslookup chẳng chứng minh gì. Đo cách một bảng endpointslices tách được ba bệnh cùng triệu chứng, và vì sao khác biệt Refused-ngay-lập-tức so với Timeout-đúng-hạn-chờ (3004 ms khi bật NetworkPolicy) là phép chia đôi tốt nhất khi lần lỗi mạng.

DevOps 31/08/2026 8 phút

Cùng một container, kubectl top báo 12 Mi bộ nhớ còn Grafana vẽ 413 Mi — cả hai đều đúng, và biết vì sao thì bảng cảnh báo của bạn hết kêu oan

Bốn con số bộ nhớ cho một container, chênh nhau 34 lần, tất cả đều đúng vì chúng trả lời những câu hỏi khác nhau. memory.current 413 Mi gồm 400 Mi bộ đệm tệp mà kernel vứt trong tích tắc; working_set chỉ 13 Mi mới là phần OOM killer nhìn vào. Đây là nguồn của phần lớn báo động giả 'rò bộ nhớ'. Thêm: kubectl top chậm hơn thực tế 30 giây và lặp lại y hệt mẫu cũ — nó không đo, chỉ đọc lại mẫu gần nhất, nên một đợt tải ngắn hơn 15 giây có thể không lọt vào mẫu nào.

DevOps 31/08/2026 8 phút

Pod distroless không có cả sh lẫn ls, kubectl exec bó tay hoàn toàn — nhưng vẫn đọc được cấu hình và biến môi trường thật của nó qua /proc/1/root

Image càng gọn thì kẻ tấn công càng ít thứ để dùng — và bạn cũng vậy lúc gỡ rối. Khi exec vô dụng với distroless, kubectl debug luồn một ephemeral container vào ĐÚNG pod đang hỏng mà không khởi động lại gì. Đo cái bẫy lớn nhất: thiếu --target thì container gỡ rối nằm không gian PID riêng, không thấy tiến trình nào của ứng dụng (PID 1 là sh của chính nó, không phải /pause của mục tiêu). Có --target rồi thì đọc cả hệ tệp lẫn /proc/1/environ thật của container mục tiêu — thứ exec không bao giờ với tới.