Chủ Nhật, 04/10/2026, 17:00 (GMT+0)

[Part 3] Headlamp trong thực tế: Quan sát và quản trị Kubernetes ngay trên laptop

Quay lại Trang chủ Blog
Trên trang này

Mở Headlamp lên rồi làm gì tiếp? Bài viết đi qua các thao tác thực tế: quan sát cluster, kiểm tra Deployment và Pod, đọc Logs, Events, kiểm tra Service và thực hiện các thao tác quản trị cơ bản.

Headlamp đã được cài đặt và kết nối tới cluster ở Part 2. Bây giờ là câu hỏi thực tế nhất: “Tôi mở Headlamp lên. Bây giờ tôi dùng nó như thế nào?”

Làm quen với giao diện Headlamp

Giao diện Headlamp gồm vài khu vực chính, đủ để tìm đến bất kỳ tài nguyên nào cần kiểm tra:

  • Cluster: chọn cluster đang làm việc ở trang Home hoặc trên sidebar.
  • Namespace: bộ lọc namespace ở góc trên danh sách tài nguyên.
  • Navigation: sidebar nhóm tài nguyên theo Workloads, Network, Storage, Configuration, Cluster.
  • Resource view: danh sách tài nguyên, click vào tên để mở trang chi tiết.
  • Search: ô tìm kiếm trên thanh công cụ (phím tắt /) để tìm nhanh tài nguyên.
Giao diện Headlamp với sidebar, ô tìm kiếm và bộ lọc namespace

Sidebar điều hướng, ô tìm kiếm và bộ lọc Namespaces. Nguồn: Alok Shankar, dev.to (đã chỉnh sửa)

Quan sát tổng quan Kubernetes Cluster

Cluster  →  Nodes  →  Namespaces  →  Workloads

Đi theo thứ tự này, người vận hành trả lời được các câu hỏi cơ bản:

  • Cluster có những Node nào? Node đang ở trạng thái gì (Ready / NotReady)?
  • Có những Namespace nào?
  • Workload đang được triển khai ra sao? Trang Workloads hiển thị tổng số Pod, Deployment, StatefulSet, DaemonSet đang Running theo dạng biểu đồ, như ảnh ở trên.

Ảnh minh hoạ cần bổ sung: trang Cluster → Nodes trên cluster demo, thể hiện danh sách Node, trạng thái Ready, CPU/Memory.

Kiểm tra Workload và Deployment

Tình huống: ứng dụng vẫn đang chạy nhưng người dùng phản ánh dịch vụ có vấn đề. Người vận hành cần kiểm tra lần lượt từ Deployment xuống tới container:

Deployment  →  ReplicaSet  →  Pod  →  Container

Mở Workloads → Deployments, chọn Deployment của ứng dụng và kiểm tra:

  • Desired / Available replicas: số Pod mong muốn so với số Pod thực sự sẵn sàng.
  • Pod status và số lần Restart.
  • Resource: requests/limits, mức sử dụng CPU/memory (nếu cluster có metrics-server).
  • Configuration: image, biến môi trường, ConfigMap/Secret được mount, xem trong YAML.

Để thấy toàn bộ chuỗi Deployment → ReplicaSet → Pod → Service trên một màn hình, dùng Map View:

Map View của Headlamp

Map View hiển thị quan hệ giữa các tài nguyên. Nguồn: headlamp.dev

Kiểm tra Pod và Logs

Tình huống: một Pod có trạng thái bất thường. Không cần chuyển ngay sang terminal, có thể mở trực tiếp Pod để xem thông tin và Logs.

Bước 1: Mở Workloads → Pods, click vào Pod cần kiểm tra. Trang chi tiết hiển thị Pod status, container, số lần restart, label, node đang chạy và Events.

Trang chi tiết Pod trong Headlamp

Trang chi tiết Pod và thanh công cụ thao tác. Nguồn: Alok Shankar, dev.to (đã chỉnh sửa)

Bước 2: Chọn biểu tượng Show Logs trên thanh công cụ của Pod.

Biểu tượng Show Logs trên trang chi tiết Pod

Biểu tượng Show Logs. Nguồn: Alok Shankar, dev.to (đã chỉnh sửa)

Bước 3: Chọn container, số dòng hiển thị; bật Follow để xem log theo thời gian thực, bật Previous để xem log của lần chạy trước khi container bị restart.

Log viewer của Headlamp

Log viewer: Container, Lines, Previous, Timestamps, Follow. Nguồn: Alok Shankar, dev.to (đã chỉnh sửa)

Bước 4: Tải log xuống bằng nút Download để đính kèm vào ticket hoặc gửi cho developer.

Nút tải log xuống trong Headlamp

Nút tải log xuống. Nguồn: Alok Shankar, dev.to (đã chỉnh sửa)

Khi cần kiểm tra sâu hơn bên trong container, chọn biểu tượng Terminal / Exec để mở terminal ngay trên giao diện (yêu cầu quyền pods/exec):

Nút Terminal/Exec trên trang chi tiết Pod

Biểu tượng Terminal / Exec. Nguồn: Alok Shankar, dev.to (đã chỉnh sửa)

Phiên terminal trong Headlamp

Thực thi lệnh bên trong container. Nguồn: Alok Shankar, dev.to (đã chỉnh sửa)

Kiểm tra Events để tìm nguyên nhân

Khi Pod không ở trạng thái Running, Events thường là nơi cho biết nguyên nhân nhanh nhất:

Pod không Running  →  Xem Events  →  Phát hiện lỗi  →  Xác định hướng xử lý
Dấu hiệu trong EventsNguyên nhân thường gặpHướng xử lý
FailedSchedulingKhông đủ CPU/memory, taint/affinity không khớpKiểm tra requests, Node, taint/toleration
ErrImagePull / ImagePullBackOffSai tên/tag image, thiếu quyền pull registryKiểm tra image, imagePullSecrets
FailedMountPVC chưa bound, ConfigMap/Secret không tồn tạiKiểm tra PVC, ConfigMap, Secret
Unhealthy (Liveness/Readiness)Probe cấu hình sai hoặc ứng dụng chưa sẵn sàngKiểm tra probe, xem Logs
BackOff (CrashLoopBackOff)Ứng dụng lỗi khi khởi độngXem Logs của lần chạy trước (Previous)

Events hiển thị ở cuối trang chi tiết của từng tài nguyên, và có thể xem toàn cluster tại Cluster → Events.

Kiểm tra Service và kết nối ứng dụng

Deployment  →  Pod  →  Service

Pod chạy bình thường nhưng ứng dụng vẫn không truy cập được? Mở Network → Services, chọn Service của ứng dụng và kiểm tra:

  • Port / Target port: khớp với port container đang lắng nghe.
  • Selector: khớp với label của Pod.
  • Endpoints: có địa chỉ Pod; nếu trống, thường do selector không khớp hoặc Pod chưa Ready.
  • Network configuration: Ingress trỏ đúng Service, NetworkPolicy không chặn traffic.

Ảnh minh hoạ cần bổ sung: trang chi tiết Service trên cluster demo, thể hiện Ports, Selector và Endpoints.

Thực hiện các thao tác quản trị cơ bản

Trên trang chi tiết tài nguyên, thanh công cụ cung cấp các thao tác thường dùng:

  • Edit: chỉnh sửa tài nguyên bằng YAML editor rồi Apply.
  • Scale: thay đổi số replica của Deployment/StatefulSet.
  • Restart: khởi động lại workload (rollout restart).
  • Delete: xoá tài nguyên.
  • Create / Apply manifest: nút dấu cộng cho phép dán hoặc tải lên YAML để tạo tài nguyên mới.

Ảnh minh hoạ cần bổ sung: hộp thoại Scale của một Deployment và YAML editor, chụp trên phiên bản Headlamp đang sử dụng để xác nhận các thao tác có sẵn.

Lưu ý: các thao tác thay đổi tài nguyên cần được thực hiện theo quyền RBAC và quy trình vận hành của cluster. Với cluster được quản lý bằng GitOps (Argo CD, Flux), thay đổi trực tiếp trên giao diện có thể bị ghi đè; nên cập nhật manifest trong Git.

Khi nào vẫn nên dùng kubectl?

Headlampkubectl
Quan sát trực quanCLI
Dễ xem resourceLinh hoạt với command
Dễ kiểm tra Logs/EventsScript/automation
Phù hợp thao tác hằng ngàyPhù hợp troubleshooting/automation nâng cao

Headlamp và kubectl có thể sử dụng song song. Headlamp giúp quan sát và thao tác trực quan; kubectl vẫn phù hợp cho các tình huống cần command line, scripting hoặc automation.

Kết luận series

  • Nhẹ: Cài ngay trên laptop.
  • Đơn giản: Kết nối Kubernetes Cluster nhanh.
  • Trực quan: Quan sát và thực hiện các tác vụ quản trị phổ biến.

Với những nhu cầu quản trị Kubernetes thường ngày, đôi khi bạn không cần một nền tảng quản trị lớn. Một công cụ gọn nhẹ như Headlamp có thể là một lựa chọn đơn giản để bắt đầu.

#Kubernetes
#CloudWave Radar
#Kubernetes
#CloudWave Radar
Sovereign Cloud không chỉ là đặt máy chủ trong nước. Với bối cảnh pháp lý dữ liệu mới tại Việt Nam, đây đang trở thành bài toán hạ tầng quan trọng cho doanh nghiệp Việt và doanh nghiệp nước ngoài hoạt động tại Việt Nam
Sovereign Cloud - Đám mây chủ quyền là gì? Và vì sao doanh nghiệp hoạt động tại Việt Nam nên quan tâm từ bây giờ?
Tiếp tục đọc