Sự cố với các ứng dụng có trạng thái trong Kubernetes
Việc cấu hình, khởi chạy và mở rộng quy mô hơn nữa của các ứng dụng và dịch vụ thật dễ dàng khi gặp các trường hợp được phân loại là không trạng thái, tức là. mà không lưu dữ liệu. Thật thuận tiện khi chạy các dịch vụ như vậy trong Kubernetes bằng cách sử dụng các API tiêu chuẩn của nó, bởi vì mọi thứ đều diễn ra “ngay lập tức”: theo cấu hình tiêu chuẩn, không liên quan đến bất kỳ chi tiết cụ thể hoặc phép thuật nào.
Nói một cách đơn giản, để khởi chạy thêm năm bản sao phụ trợ trong PHP/Ruby/Python trong một cụm vùng chứa, bạn chỉ cần thiết lập một máy chủ mới 5 lần và sao chép các nguồn. Vì cả mã nguồn và tập lệnh init đều có trong hình ảnh nên việc mở rộng ứng dụng không trạng thái trở nên hoàn toàn cơ bản. Như những người hâm mộ kiến trúc container và microservice đều biết rõ, khó khăn bắt đầu với ứng dụng có trạng thái, I E. với tính bền vững của dữ liệu như cơ sở dữ liệu và bộ nhớ đệm (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Điều này áp dụng cho cả phần mềm triển khai độc lập cụm đại biểu (ví dụ: Percona XtraDB và Cassandra) và phần mềm yêu cầu các tiện ích quản lý riêng biệt (chẳng hạn như Redis, MySQL, PostgreSQL...).
Khó khăn nảy sinh do mã nguồn và khởi chạy dịch vụ không còn đủ nữa - bạn cần thực hiện thêm một số bước nữa. Ở mức tối thiểu, hãy sao chép dữ liệu và/hoặc tham gia cụm. Chính xác hơn, các dịch vụ này đòi hỏi sự hiểu biết về cách mở rộng quy mô, cập nhật và cấu hình lại chúng một cách hợp lý mà không làm mất dữ liệu hoặc không có sẵn tạm thời. Việc tính đến những nhu cầu này được gọi là “kiến thức vận hành”.
Nhà khai thác CoreOS
Để “lập trình” kiến thức vận hành, cuối năm ngoái dự án CoreOS “một loại phần mềm mới” dành cho nền tảng Kubernetes - Người vận hành (từ “hoạt động” trong tiếng Anh, tức là “hoạt động”).
Người vận hành sử dụng và mở rộng các khả năng cốt lõi của Kubernetes (bao gồm. Bộ trạng thái, hãy xem sự khác biệt bên dưới) cho phép các chuyên gia DevOps bổ sung kiến thức vận hành vào mã ứng dụng.
Mục đích của người vận hành — cung cấp cho người dùng một API cho phép bạn quản lý nhiều thực thể ứng dụng có trạng thái trong cụm Kubernetes mà không cần suy nghĩ về những gì ẩn sâu (dữ liệu nào và phải làm gì với dữ liệu đó, những lệnh nào vẫn cần được thực thi để duy trì cụm ). Trên thực tế, Toán tử được thiết kế để đơn giản hóa công việc với ứng dụng trong cụm càng nhiều càng tốt, tự động hóa việc thực thi các tác vụ vận hành mà trước đây phải giải quyết thủ công.
Cách thức hoạt động của người vận hành
Bản sao Kubernetes cho phép bạn chỉ định số lượng nhóm đang chạy mong muốn và bộ điều khiển đảm bảo rằng số lượng của chúng được duy trì (bằng cách tạo và xóa các nhóm). Toán tử hoạt động theo cách tương tự, thêm một bộ kiến thức vận hành vào tài nguyên và bộ điều khiển Kubernetes tiêu chuẩn cho phép bạn thực hiện các hành động bổ sung để hỗ trợ số lượng thực thể ứng dụng cần thiết.
Điều này khác với thế nào Bộ trạng thái, được thiết kế cho các ứng dụng yêu cầu cụm cung cấp cho chúng các tài nguyên có trạng thái như bộ lưu trữ dữ liệu hoặc IP tĩnh? Đối với các ứng dụng như vậy, Người vận hành có thể sử dụng Bộ trạng thái (thay vì Bản sao) làm cơ sở, cung cấp tự động hóa bổ sung: thực hiện các hành động cần thiết trong trường hợp gặp sự cố, tạo bản sao lưu, cập nhật cấu hình, v.v.
Vì vậy, tất cả những thứ này hoạt động như thế nào? Toán tử là một daemon quản lý:
- đăng ký API sự kiện trong Kubernetes;
- nhận được từ nó dữ liệu về hệ thống (về Bản sao, pods, DỊCH VỤ và như thế.);
- nhận dữ liệu về Tài nguyên của bên thứ ba (xem ví dụ bên dưới);
- phản ứng với sự xuất hiện/thay đổi Tài nguyên của bên thứ ba (ví dụ: để thay đổi kích thước, thay đổi phiên bản, v.v.);
- phản ứng với những thay đổi về trạng thái của hệ thống (về Bản sao, pods, DỊCH VỤ và như thế.);
- điều quan trọng nhất:
- gọi API Kubernetes để tạo mọi thứ nó cần (một lần nữa, API của chính nó Bản sao, pods, DỊCH VỤ...),
- thực hiện một số phép thuật (để đơn giản hóa, bạn có thể nghĩ rằng Người vận hành tự đi vào nhóm và gọi các lệnh, chẳng hạn như tham gia một cụm hoặc nâng cấp định dạng dữ liệu khi cập nhật phiên bản).
Trên thực tế, như có thể thấy từ hình ảnh, một ứng dụng riêng biệt chỉ được thêm vào Kubernetes (một ứng dụng thông thường Triển khai с Bộ bản sao), được gọi là Toán tử. Nó sống trong một cái kén bình thường (thường chỉ một cái) và theo quy luật, nó chỉ chịu trách nhiệm về Không gian tên. Ứng dụng toán tử này triển khai API của nó - mặc dù không trực tiếp nhưng thông qua Tài nguyên của bên thứ ba trong Kubernetes.
Vì vậy, sau khi chúng ta đã tạo trong Không gian tên Toán tử, chúng ta có thể thêm vào nó Tài nguyên của bên thứ ba.
Ví dụ cho vvd (xem bên dưới để biết chi tiết):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Ví dụ cho Elaticsearch:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Yêu cầu đối với người vận hành
CoreOS đã xây dựng các mẫu chính mà các kỹ sư thu được khi làm việc với Toán tử. Mặc dù thực tế là tất cả các Toán tử đều là cá nhân (được tạo cho một ứng dụng cụ thể với các đặc điểm và nhu cầu riêng), việc tạo ra chúng phải dựa trên một loại khuôn khổ áp đặt các yêu cầu sau:
- Việc cài đặt phải được thực hiện thông qua một Triển khai: kubectl tạo -f SOME_OPERATOR_URL/deployment.yaml - và không yêu cầu hành động bổ sung.
- Khi cài đặt Toán tử trong Kubernetes, phải tạo loại bên thứ ba mới (Tài nguyên của bên thứ ba). Để khởi chạy các phiên bản ứng dụng (phiên bản cụm) và quản lý thêm chúng (cập nhật phiên bản, thay đổi kích thước, v.v.), người dùng sẽ sử dụng loại này.
- Bất cứ khi nào có thể, bạn nên sử dụng các nguyên hàm được tích hợp trong Kubernetes, chẳng hạn như DỊCH VỤ и Bản saođể sử dụng mã đã được kiểm tra tốt và dễ hiểu.
- Yêu cầu khả năng tương thích ngược của Toán tử và hỗ trợ các phiên bản cũ hơn của tài nguyên do người dùng tạo.
- Nếu Toán tử bị xóa, ứng dụng sẽ tiếp tục hoạt động mà không có thay đổi.
- Người dùng có thể xác định phiên bản ứng dụng mong muốn và sắp xếp các bản cập nhật phiên bản ứng dụng. Thiếu cập nhật phần mềm là nguyên nhân phổ biến gây ra các vấn đề về vận hành và bảo mật, vì vậy Nhà điều hành phải hỗ trợ người dùng trong vấn đề này.
- Người vận hành nên được kiểm tra bằng một công cụ như Chaos Monkey, công cụ này xác định các lỗi tiềm ẩn trong nhóm, cấu hình và mạng.
toán tử vvd
Ví dụ triển khai toán tử - Toán tử etcd, vào ngày công bố khái niệm này. Cấu hình cụm etcd có thể phức tạp do nhu cầu duy trì số đại biểu, nhu cầu cấu hình lại tư cách thành viên cụm, tạo bản sao lưu, v.v. Ví dụ: chia tỷ lệ cụm etcd theo cách thủ công có nghĩa là bạn cần tạo tên DNS cho thành viên cụm mới, bắt đầu thực thể etcd mới và thông báo cho cụm về thành viên mới (thêm thành viên etcdctl). Trong trường hợp Người vận hành, người dùng sẽ chỉ cần thay đổi kích thước cụm - mọi thứ khác sẽ tự động diễn ra.
Và vì etcd cũng được tạo trong CoreOS nên khá hợp lý khi thấy Toán tử của nó xuất hiện đầu tiên. Anh ấy làm việc như thế nào? Logic toán tử, v.v. được xác định bởi ba thành phần:
- Quan sát. Người vận hành giám sát trạng thái của cụm bằng API Kubernetes.
- Phân tích. Tìm sự khác biệt giữa trạng thái hiện tại và trạng thái mong muốn (được xác định bởi cấu hình người dùng).
- Hoạt động. Giải quyết những khác biệt được phát hiện bằng cách sử dụng API dịch vụ etcd và/hoặc Kubernetes.
Để thực hiện logic này, các hàm đã được chuẩn bị trong Toán tử Tạo/Hủy (tạo và xóa các thành viên cụm etcd) và Thay đổi kích thước (thay đổi số lượng thành viên cụm). Tính chính xác của hoạt động của nó đã được xác minh bằng cách sử dụng một tiện ích được tạo giống như Chaos Monkey từ Netflix, tức là. giết chết các nhóm etcd một cách ngẫu nhiên.
Để vận hành đầy đủ etcd, Người vận hành cung cấp các tính năng bổ sung: sao lưu (tự động và vô hình đối với người dùng khi tạo các bản sao lưu - trong cấu hình, nó đủ để xác định tần suất tạo chúng và số lượng cần lưu trữ - cũng như việc khôi phục dữ liệu từ chúng sau đó) và Upgrade (cập nhật cài đặt etcd mà không có thời gian chết).
Làm việc với Người vận hành trông như thế nào?
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
Trạng thái hiện tại của etcd Operator là phiên bản beta, yêu cầu Kubernetes 1.5.3+ và etcd 3.0+ để chạy. Mã nguồn và tài liệu (bao gồm cả hướng dẫn sử dụng) có sẵn tại .
Một ví dụ triển khai khác từ CoreOS đã được tạo - , nhưng nó vẫn ở phiên bản alpha (không phải tất cả các tính năng theo kế hoạch đều đã được triển khai).
Tình trạng và triển vọng
Đã 5 tháng trôi qua kể từ khi công bố Kubernetes Operators. Vẫn chỉ có hai triển khai có sẵn trong kho CoreOS chính thức (dành cho etcd và Prometheus). Cả hai đều chưa đạt đến phiên bản ổn định, nhưng các cam kết được thực hiện hàng ngày.
Các nhà phát triển hình dung “một tương lai trong đó người dùng cài đặt Toán tử Postgres, Toán tử Cassandra hoặc Toán tử Redis trên cụm Kubernetes của họ và làm việc với các thực thể có thể mở rộng của các ứng dụng này dễ dàng như việc triển khai các bản sao của ứng dụng web không trạng thái ngày nay”. Đầu tiên Nhà điều hành từ nhà phát triển bên thứ ba thực sự bắt đầu xuất hiện:
- từ Doanh nghiệp UPMC;
- từ Crunchy Data (được công bố vào cuối tháng 2017 năm XNUMX);
- từ các tác giả của hệ thống lưu trữ dữ liệu phân tán dựa trên Ceph (Rook ở trạng thái alpha);
- từ SAP CCloud.
Tại hội nghị phần mềm miễn phí lớn nhất châu Âu FOSDEM, diễn ra vào tháng 2017 năm XNUMX tại Brussels, Josh Wood từ CoreOS đã công bố Nhà điều hành trong (có sẵn video tại liên kết!), Điều này sẽ góp phần vào sự phát triển phổ biến của khái niệm này trong cộng đồng Nguồn mở rộng lớn hơn.
PS Cảm ơn bạn đã quan tâm đến bài viết! Đăng ký vào trung tâm của chúng tôi, để không bỏ lỡ các tài liệu và công thức mới về quản trị hệ thống DevOps và GNU/Linux - chúng tôi sẽ xuất bản chúng thường xuyên!
Nguồn: www.habr.com