Phần 1 - Cách etcd hoạt động khi có và không có Kubernetes
Bạn đã biết tại sao Kubernetes sử dụng etcd làm cơ sở dữ liệu bằng cách xây dựng một cụm etcd 3 nút chưa? Bài viết này sẽ giới thiệu cách hoạt động của etcd để bạn có thể hiểu sâu hơn về hoạt động bên trong của Kubernetes, cũng như cung cấp cho bạn một số công cụ bổ sung trong hộp công cụ khắc phục sự cố cụm. Hãy cùng theo dõi với Bizfly Cloud nhé.
Tại sao etcd phù hợp với Kubernetes?
Ở một cấp độ cao hơn, một cụm Kubernetes (K8s) sẽ có ba loại quy trình mặt phẳng điều khiển:
- Bộ điều khiển tập trung: có thể coi như bộ lập lịch, bộ điều khiển - người quản lý và bộ điều khiển bên thứ ba.
- Quy trình dành riêng cho nút: quan trọng nhất trong đó chính là Kubelet sẽ xử lý việc thiết lập nhóm và kết nối mạng dựa trên cấu hình bạn mong muốn.
- Máy chủ API: điều phối giữa tất cả các quy trình mặt phẳng điều khiển và các nút.
Khi người dùng hoặc quy trình thực hiện lệnh gọi API, máy chủ API sẽ:
- Xác định xem lệnh gọi API có được ủy quyền hay không (sử dụng RBAC).
- Có thể thay đổi trọng tải của lệnh gọi API thông qua các webhook thay đổi.
- Xác định xem tải trọng có hợp lệ hay không (sử dụng xác thực nội bộ và xác thực webhook).
- Duy trì tải trọng API và trả về thông tin được yêu cầu.
- Có khả năng thông báo cho người đăng ký của điểm cuối API rằng đối tượng đã thay đổi.
Ngay sau khi một Deployment được tạo trong etcd, trình quản lý bộ điều khiển sẽ được thông báo về tài nguyên mới.
Về mặt kiến trúc, máy chủ API là một ứng dụng CRUD không khác với WordPress - hầu hết những gì nó làm là lưu trữ và cung cấp dữ liệu. Cũng giống như WordPress, nó cần một cơ sở dữ liệu để lưu trữ dữ liệu lâu dài và đó là nơi mà etcd hoạt động.
Đặc điểm hỗ trợ của máy chủ API là gì?
1. Tính nhất quán
Vì máy chủ API là điểm điều phối trung tâm của toàn bộ cụm, nên tính nhất quán là điều vô cùng cần thiết.
Sẽ là một thảm họa nếu, giả sử, hai nút cố gắng đính kèm cùng một khối lượng liên tục qua iSCSI vì máy chủ API nói với cả hai rằng nó đều khả dụng. Yêu cầu này quy định cơ sở dữ liệu NoSQL nhất quán cuối cùng và một số cấu hình SQL đa chủ phân tán.
2. Tính khả dụng
API ngừng hoạt động có nghĩa là toàn bộ mặt phẳng điều khiển Kubernetes ngừng hoạt động. Mặc dù theo các định lý CAP thì việc khả dụng 100% là không thể nhưng giảm thiểu được thời gian chết vẫn là một mục tiêu quan trọng.
3. Hiệu suất nhất quán
Máy chủ API cho một cụm Kubernetes nhận được một lượng lưu lượng đọc và ghi hợp lý. Nếu đột nhiên hiệu suất chậm lại do sử dụng API đồng thời sẽ là một vấn đề rất lớn.
4. Thay đổi thông báo
Vì máy chủ API hoạt động như một bộ điều phối tập trung giữa nhiều loại máy khách khác nhau, nên việc phát trực tuyến các thay đổi trong thời gian thực sẽ là một tính năng tuyệt vời.
5. Những cân nhắc khác
Tập dữ liệu lớn: Vì máy chủ API chỉ giữ siêu dữ liệu về nhóm và các đối tượng khác, nên có giới hạn tự nhiên về lượng dữ liệu sẽ được lưu trữ. Một cụm lớn sẽ có hàng trăm megabyte hoặc có thể là vài gigabyte dữ liệu, nhưng chắc chắn không bao giờ là terabyte.
Truy vấn phức tạp: API Kubernetes khá dễ đoán trong các mẫu truy cập của nó: hầu hết các đối tượng được truy cập theo loại, không gian tên và đôi khi là tên. Nếu có thêm bộ lọc, nó thường sẽ theo nhãn hoặc chú thích. Các khả năng giống SQL với các phép nối và các truy vấn phân tích phức tạp là quá mức cần thiết đối với cách hoạt động của API.
Cơ sở dữ liệu SQL truyền thống có xu hướng tối ưu hóa để có tính nhất quán cao với các bộ dữ liệu lớn và phức tạp, nhưng thường khó đạt được tính khả dụng cao và hiệu suất nhất quán.
Cách hoạt động của etcd
Đằng sau sự cân bằng giữa tính nhất quán và tính khả dụng của etcd là thuật toán Raft.
Raft hoạt động bằng cách chọn một người lãnh đạo trong số một tập hợp các nút và buộc tất cả các yêu cầu viết thư phải gửi đến người lãnh đạo.
Khi một cụm được hình thành, tất cả các nút bắt đầu ở trạng thái theo dõi.
Nếu những người theo dõi không nghe thấy từ một nhà lãnh đạo, thì họ có thể trở thành một ứng cử viên và yêu cầu phiếu bầu từ các nút khác.
Các nút trả lời bằng phiếu bầu của họ
Ứng cử viên trở thành người dẫn đầu nếu nhận được phiếu bầu từ đa số các nút.
Các thay đổi sau đó được nhân rộng từ người dẫn đầu đến tất cả các nút khác; nếu nhà lãnh đạo offline, một cuộc bầu cử mới được tổ chức và một nhà lãnh đạo mới được chọn.
Một cụm etcd luôn có một nút lãnh đạo duy nhất tại bất kỳ thời điểm nào (được bầu bằng cách sử dụng giao thức Raft).
Việc ghi dữ liệu theo một đường dẫn nhất quán:
- Máy khách có thể gửi yêu cầu ghi tới bất kỳ một trong các nút etcd trong cụm.
- Nếu máy khách tình cờ giao tiếp với nút lãnh đạo, việc ghi sẽ được thực hiện và sao chép sang các nút khác.
- Nếu khách hàng đã chọn một nút khác với nút lãnh đạo, yêu cầu ghi sẽ được chuyển tiếp đến nút lãnh đạo và quá trình này sẽ giống như vậy kể từ đó trở đi.
- Sau khi ghi thành công, một xác nhận sẽ được gửi lại cho khách hàng.
Một cụm etcd nên có bao nhiêu nút để đạt được tính khả dụng tốt nhất?
Như với hầu hết các câu hỏi về thiết kế, câu trả lời là "nó phụ thuộc", nhưng từ việc nhìn vào bảng nhanh, có thể thấy một quy tắc chung:
Một điều nổi bật từ bảng này là việc thêm một nút vào một số nút lẻ không làm tăng tính khả dụng.
>> Có thể bạn quan tâm: Phần 2 - Cách etcd hoạt động khi có và không có Kubernetes
