Posted inDevOps

Xây dựng ChatOps với Slack và Kubernetes: Ngừng chuyển đổi ngữ cảnh và bắt đầu tự động hóa

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Cái giá đắt của việc chuyển đổi ngữ cảnh

Buổi sáng của tôi thường bắt đầu bằng một kịch bản gây ức chế. Một thông báo từ Slack báo hiệu dịch vụ production đang bị chậm. Tôi phải bỏ dở mọi việc, bật VPN, xác thực với nhà cung cấp đám mây và bắt đầu gõ kubectl get pods. Đến khi tôi thực sự xem được log thì 5 phút đã trôi qua. Trong khi đó, luồng thảo luận sự cố trên Slack đã tăng thêm 30 tin nhắn với các bên liên quan yêu cầu cập nhật thông tin mà tôi vẫn chưa có.

Chuyển đổi ngữ cảnh (context switching) là một “kẻ sát nhân” thầm lặng đối với năng suất. Nghiên cứu cho thấy có thể mất tới 20 phút để lấy lại sự tập trung sâu sau khi bị xao nhãng. ChatOps giải quyết vấn đề này bằng cách đưa việc quản lý hạ tầng vào ngay trong cuộc hội thoại của nhóm. Thay vì rời khỏi Slack để chạy lệnh, bạn mang câu lệnh đó vào Slack.

Tôi đã triển khai quy trình này trong các môi trường production quản lý hơn 50 microservices. Kết quả luôn nhất quán: thời gian xử lý sự cố nhanh hơn và nhật ký kiểm tra (audit trail) minh bạch. Mọi người trong kênh đều thấy chính xác những gì đã được thực hiện để khắc phục sự cố, loại bỏ nhu cầu báo cáo trạng thái thủ công.

Cách ChatOps thu hẹp khoảng cách

ChatOps hoạt động bằng cách kết nối một ứng dụng chat như Slack hoặc Teams với cụm cluster của bạn thông qua một bot chuyên dụng. Đối với Kubernetes, bot này thường nằm bên trong cụm dưới dạng một deployment, đóng vai trò trung gian giữa các tin nhắn của bạn và K8s API.

Mô hình này dựa trên ba thành phần cụ thể:

  • Giao diện (Slack): Nơi bạn kích hoạt các hành động và nhận các thông báo được định dạng đẹp mắt.
  • Cầu nối (Botkube): Mặc dù bạn có thể tự xây dựng một bot tùy chỉnh, Botkube là tiêu chuẩn trong ngành. Đây là một công cụ mã nguồn mở được xây dựng riêng để chuyển đổi các tin nhắn Slack thành các hành động trên Kubernetes.
  • Công cụ thực thi (Kubernetes API): Đây là đích đến. Bot sẽ truy vấn API server để lấy dữ liệu hoặc sửa đổi tài nguyên dựa trên quyền hạn của bạn.

Quy trình làm việc rất đơn giản. Bạn gõ @Botkube get pods trong một kênh. Slack API sẽ chuyển tiếp yêu cầu này đến controller của Botkube trong cụm của bạn. Sau đó, Botkube truy vấn K8s API, định dạng kết quả thành một khối (block) Slack gọn gàng và gửi ngược lại. Nó biến một phiên terminal cá nhân thành một trải nghiệm chia sẻ cho cả nhóm.

Chuẩn bị không gian làm việc Slack

Bạn cần thiết lập phía Slack trước khi chạm vào cụm cluster. Việc này bao gồm tạo một Slack App để tạo các token xác thực cần thiết.

  1. Truy cập Slack API console và tạo một ứng dụng mới “From scratch”.
  2. Đặt tên ứng dụng là K8s-Bot và liên kết nó với không gian làm việc chính của bạn.
  3. Trong phần OAuth & Permissions, gán các Bot Token Scopes cụ thể sau:
    • app_mentions:read: Cho phép bot nghe các lệnh của bạn.
    • chat:write: Cho phép bot gửi phản hồi.
    • files:write: Cần thiết để gửi các tệp log dài dưới dạng snippet.
  4. Cài đặt ứng dụng vào không gian làm việc. Lưu lại Bot User OAuth Token (bắt đầu bằng xoxb-) để cấu hình Helm.

Triển khai Botkube qua Helm

Sử dụng Helm là cách nhanh nhất để chạy Botkube, thường mất chưa đầy hai phút. Chúng ta sẽ bắt đầu với cấu hình chỉ đọc (read-only). Việc kiểm tra đầu ra của bot trước khi cấp quyền sửa đổi hoặc xóa tài nguyên là một thực hành tốt (best practice).

Bắt đầu bằng cách thêm kho lưu trữ chính thức:

helm repo add botkube https://charts.botkube.io
helm repo update

Tiếp theo, tạo tệp values.yaml. Tệp này xác định bot sẽ lắng nghe kênh nào và những sự kiện Kubernetes nào nó nên giám sát.

# values.yaml
communications:
  'default-group':
    slack:
      enabled: true
      channel: 'devops-alerts'
      token: 'xoxb-token-cua-ban-tai-day'

settings:
  clusterName: 'prod-cluster-01'
  allowInsecureStateless: true

executors:
  'k8s-read-only':
    botkube/kubectl:
      enabled: true
      config:
        rbac:
          group: system:read-only
      namespaces:
        include: ["default", "production"]

sources:
  'k8s-events':
    botkube/kubernetes:
      enabled: true
      config:
        resources:
          - name: v1/pods
            events: [create, delete, error]
          - name: apps/v1/deployments
            events: [update, error]

Cài đặt chart vào namespace riêng của nó:

helm install botkube botkube/botkube \
  --namespace botkube \
  --create-namespace \
  -f values.yaml

Các tình huống thực tế: Debug từ Chat

Sau khi mời bot vào kênh bằng lệnh /invite @K8s-Bot, bạn có thể ngừng sử dụng terminal cho các bước kiểm tra cơ bản. Dưới đây là ba cách điều này thay đổi quy trình làm việc hàng ngày của bạn.

1. Kiểm tra sức khỏe tức thì

Nếu một lập trình viên báo cáo rằng môi trường staging có vẻ chậm, bạn không cần phải đoán già đoán non. Chỉ cần hỏi bot.

@Botkube kubectl get pods -n production

Bot sẽ trả về một bảng trạng thái ngay lập tức. Nếu một pod hiển thị OOMKilled hoặc CrashLoopBackOff, bạn đã xác định được điểm nghẽn chỉ trong vài giây thay vì vài phút.

2. Phân tích log cộng tác

Thông thường, log bị “kẹt” trong terminal của một người. Với ChatOps, bạn có thể kéo 100 dòng cuối cùng của một dịch vụ đang lỗi trực tiếp vào luồng thảo luận:

@Botkube kubectl logs deployment/api-gateway --tail=100

Botkube tải các log này lên dưới dạng một đoạn văn bản (text snippet). Giờ đây, toàn bộ đội ngũ backend của bạn có thể xem stack trace cùng một lúc, giúp đưa ra chẩn đoán tập thể nhanh hơn nhiều.

3. Thông báo sự kiện chủ động

Vì chúng ta đã cấu hình sources trong tệp YAML, bot đóng vai trò như một hệ thống cảnh báo sớm. Nó sẽ đẩy thông báo ngay khi một Deployment thất bại trong việc kiểm tra sức khỏe. Thông thường, tôi thấy các cảnh báo Slack này và bắt đầu điều tra trước khi hệ thống giám sát chính thức kích hoạt cảnh báo mức độ nghiêm trọng cao.

Bảo mật cụm của bạn với RBAC

Bảo mật là trở ngại phổ biến nhất đối với ChatOps. Bạn không muốn một tài khoản Slack bị xâm nhập hoặc một câu lệnh vô tình xóa sạch một namespace production. Đây là lúc Kubernetes Role-Based Access Control (RBAC) trở nên quan trọng.

Trong thiết lập ban đầu, chúng ta đã gán bot vào nhóm system:read-only. Nếu sau này bạn muốn cho phép bot khởi động lại các pod, hãy tạo một ClusterRole riêng biệt với các quyền hạn (verbs) hạn chế:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: botkube-restarter
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: botkube-restarter-binding
subjects:
- kind: ServiceAccount
  name: botkube
  namespace: botkube
roleRef:
  kind: ClusterRole
  name: botkube-restarter
  apiGroup: rbac.authorization.k8s.io

Bằng cách xác định các ranh giới nghiêm ngặt, bạn có được tốc độ của tự động hóa mà không lo rủi ro do sai sót của con người.

Lời kết

Đưa các hoạt động vận hành Kubernetes vào Slack không chỉ đơn thuần là sự tiện lợi. Đó là về việc giảm tải nhận thức cho toàn bộ đội ngũ của bạn. Khi các bản log và kiểm tra trạng thái nằm cùng một nơi với nơi bạn thảo luận về sự cố, bức tường giữa Dev và Ops cuối cùng sẽ bắt đầu sụp đổ.

Hãy bắt đầu với quyền chỉ đọc để xây dựng niềm tin. Khi nhóm của bạn đã quen thuộc, bạn có thể khám phá các tính năng nâng cao như kích hoạt rollback CI/CD hoặc tự động mở rộng quy mô trực tiếp từ cửa sổ chat. Terminal nên dành cho những công việc chuyên sâu, không phải cho những lần kiểm tra trạng thái định kỳ.

Share:
Tags: