Tên tôi là Viktor Yagofarov và tôi đang phát triển nền tảng Kubernetes tại DomClick với tư cách là giám đốc phát triển kỹ thuật trong nhóm Ops (vận hành). Tôi muốn nói về cấu trúc của các quy trình Dev <-> Ops của chúng tôi, các tính năng vận hành một trong những cụm k8s lớn nhất ở Nga, cũng như các phương pháp thực hành DevOps/SRE mà nhóm của chúng tôi áp dụng.
Nhóm điều hành
Nhóm Ops hiện có 15 người. Ba người trong số họ chịu trách nhiệm văn phòng, hai người làm việc ở múi giờ khác và có mặt, kể cả vào ban đêm. Do đó, ai đó từ Ops luôn theo dõi và sẵn sàng ứng phó với mọi sự cố phức tạp. Chúng tôi không có ca đêm, điều này giúp giữ gìn tâm lý và giúp mọi người có cơ hội ngủ đủ giấc và dành thời gian giải trí không chỉ bên máy tính.
Mọi người đều có những năng lực khác nhau: nhà mạng, DBA, chuyên gia ngăn xếp ELK, quản trị viên/nhà phát triển Kubernetes, giám sát, ảo hóa, chuyên gia phần cứng, v.v. Một điều gắn kết tất cả mọi người - mọi người đều có thể thay thế bất kỳ ai trong chúng ta ở một mức độ nào đó: ví dụ: giới thiệu các nút mới vào cụm k8s, cập nhật PostgreSQL, viết đường dẫn CI/CD + Ansible, tự động hóa thứ gì đó trong Python/Bash/Go, kết nối phần cứng với Trung tâm dữ liệu. Năng lực mạnh mẽ trong bất kỳ lĩnh vực nào không ngăn cản bạn thay đổi hướng hoạt động và bắt đầu cải thiện ở một số lĩnh vực khác. Ví dụ: tôi đã gia nhập một công ty với tư cách là chuyên gia PostgreSQL và hiện tại lĩnh vực trách nhiệm chính của tôi là cụm Kubernetes. Trong đội, mọi chiều cao đều được chào đón và ý thức về đòn bẩy rất phát triển.
Nhân tiện, chúng tôi đang đi săn. Yêu cầu đối với ứng viên khá chuẩn. Đối với cá nhân tôi, điều quan trọng là một người phải hòa nhập với nhóm, không xung đột nhưng cũng biết bảo vệ quan điểm của mình, muốn phát triển và không ngại làm điều gì đó mới, đưa ra ý tưởng của mình. Ngoài ra, cần có kỹ năng lập trình bằng ngôn ngữ kịch bản, kiến thức cơ bản về Linux và tiếng Anh. Tiếng Anh là cần thiết đơn giản để một người trong trường hợp fakap có thể google giải pháp cho vấn đề trong 10 giây chứ không phải trong 10 phút. Hiện nay rất khó tìm được các chuyên gia có kiến thức sâu về Linux: thật buồn cười, nhưng cứ ba ứng viên thì có hai người không thể trả lời được câu hỏi “Load Average là gì? Nó được làm từ gì?”, và câu hỏi “Làm thế nào để lắp ráp một bãi chứa lõi từ chương trình C” được coi là một thứ gì đó đến từ thế giới của siêu nhân… hay khủng long. Chúng tôi phải chấp nhận điều này, vì thông thường mọi người đã phát triển cao các năng lực khác, nhưng chúng tôi sẽ dạy Linux. Câu trả lời cho câu hỏi “tại sao một kỹ sư DevOps cần phải biết tất cả những điều này trong thế giới đám mây hiện đại” sẽ phải nằm ngoài phạm vi của bài viết, nhưng chỉ gói gọn trong ba từ: tất cả những điều này là cần thiết.
Công cụ nhóm
Nhóm Công cụ đóng một vai trò quan trọng trong việc tự động hóa. Nhiệm vụ chính của họ là tạo ra các công cụ đồ họa và CLI thuận tiện cho các nhà phát triển. Ví dụ: Confer phát triển nội bộ của chúng tôi cho phép bạn triển khai một ứng dụng cho Kubernetes theo đúng nghĩa đen chỉ bằng vài cú click chuột, định cấu hình tài nguyên, khóa từ vault, v.v. Trước đây đã có Jenkins + Helm 2 nhưng tôi phải phát triển công cụ của riêng mình để loại bỏ việc sao chép-dán và mang lại sự đồng nhất cho vòng đời phần mềm.
Nhóm Ops không viết quy trình cho các nhà phát triển nhưng có thể tư vấn về bất kỳ vấn đề nào bằng văn bản của họ (một số người vẫn có Helm 3).
DevOps
Đối với DevOps, chúng tôi thấy như thế này:
Nhóm phát triển viết mã, triển khai mã thông qua Confer to dev -> qa/stage -> prod. Trách nhiệm đảm bảo mã không bị chậm và không có lỗi thuộc về nhóm Dev và Ops. Vào ban ngày, người trực của nhóm Ops trước hết phải ứng phó với sự cố xảy ra với ứng dụng của mình, còn vào buổi tối và ban đêm, quản trị viên trực (Ops) phải đánh thức nhà phát triển đang trực nếu anh ta biết. chắc chắn rằng vấn đề không nằm ở cơ sở hạ tầng. Tất cả các số liệu và cảnh báo trong quá trình giám sát đều xuất hiện tự động hoặc bán tự động.
Phạm vi trách nhiệm của Ops bắt đầu từ thời điểm ứng dụng được đưa vào sản xuất, nhưng trách nhiệm của Dev không chỉ dừng lại ở đó - chúng tôi làm điều tương tự và ở trên cùng một con thuyền.
Nhà phát triển tư vấn cho quản trị viên nếu họ cần trợ giúp viết vi dịch vụ quản trị viên (ví dụ: Go backend + HTML5) và quản trị viên tư vấn cho nhà phát triển về mọi vấn đề cơ sở hạ tầng hoặc vấn đề liên quan đến k8.
Nhân tiện, chúng tôi không có một khối nguyên khối nào cả, chỉ có các dịch vụ vi mô. Số lượng của chúng cho đến nay dao động trong khoảng từ 900 đến 1000 trong cụm prod k8s, nếu đo bằng số triển khai. Số lượng nhóm dao động trong khoảng từ 1700 đến 2000. Hiện tại có khoảng 2000 nhóm trong cụm sản phẩm.
Tôi không thể đưa ra con số chính xác vì chúng tôi giám sát các vi dịch vụ không cần thiết và loại bỏ chúng một cách bán tự động. K8s giúp chúng ta theo dõi những thực thể không cần thiết , giúp tiết kiệm rất nhiều nguồn lực và tiền bạc.
Quản lý nguồn tài nguyên
Giám sát
Việc giám sát có cấu trúc tốt và mang tính thông tin sẽ trở thành nền tảng trong hoạt động của một cụm lớn. Chúng tôi vẫn chưa tìm thấy giải pháp phổ quát nào có thể đáp ứng 100% tất cả các nhu cầu giám sát, vì vậy, chúng tôi định kỳ tạo các giải pháp tùy chỉnh khác nhau trong môi trường này.
- Zabbix. Giám sát cũ tốt, chủ yếu nhằm mục đích theo dõi tình trạng chung của cơ sở hạ tầng. Nó cho chúng ta biết khi nào một nút chết về mặt xử lý, bộ nhớ, đĩa, mạng, v.v. Không có gì siêu nhiên, nhưng chúng tôi cũng có một DaemonSet tác nhân riêng biệt, chẳng hạn như với sự trợ giúp của nó, chúng tôi theo dõi trạng thái DNS trong cụm: chúng tôi tìm kiếm các nhóm coredns ngu ngốc, chúng tôi kiểm tra tính khả dụng của các máy chủ bên ngoài. Có vẻ như tại sao phải bận tâm đến điều này, nhưng với lưu lượng truy cập lớn thì thành phần này là một điểm hỏng hóc nghiêm trọng. Tôi sẵn sàng , cách tôi gặp khó khăn với hiệu suất DNS trong một cụm.
- Nhà điều hành Prometheus. Một tập hợp các nhà xuất khẩu khác nhau sẽ cung cấp một cái nhìn tổng quan về tất cả các thành phần của cụm. Tiếp theo, chúng tôi trực quan hóa tất cả những điều này trên các trang tổng quan lớn trong Grafana và sử dụng trình quản lý cảnh báo để cảnh báo.
Một công cụ hữu ích khác cho chúng tôi là . Chúng tôi đã viết nó sau nhiều lần gặp phải tình huống một nhóm chồng lên đường dẫn Ingress của một nhóm khác, dẫn đến lỗi gấp 50 lần. Bây giờ trước khi triển khai vào sản xuất, các nhà phát triển sẽ kiểm tra để đảm bảo không ai bị ảnh hưởng và đối với nhóm của tôi, đây là một công cụ tốt để chẩn đoán ban đầu các vấn đề với Ingresses. Thật buồn cười là lúc đầu nó được viết cho quản trị viên và trông khá “vụng về”, nhưng sau khi nhóm phát triển yêu thích công cụ này, nó đã thay đổi rất nhiều và bắt đầu trông không giống “quản trị viên làm mặt web cho quản trị viên”. ” Chúng tôi sẽ sớm từ bỏ công cụ này và những tình huống như vậy sẽ được xác thực ngay cả trước khi hệ thống được triển khai.
Tài nguyên nhóm trong Cube
Trước khi đi vào các ví dụ, cần giải thích cách chúng ta phân bổ nguồn lực cho vi dịch vụ.
Để hiểu đội nào và với số lượng bao nhiêu sử dụng ресурсы (bộ xử lý, bộ nhớ, SSD cục bộ), chúng tôi phân bổ từng lệnh riêng không gian tên trong “Cube” và giới hạn khả năng tối đa của nó về bộ xử lý, bộ nhớ và ổ đĩa, trước đó đã thảo luận về nhu cầu của các nhóm. Theo đó, một lệnh nói chung sẽ không chặn toàn bộ cụm để triển khai, phân bổ hàng nghìn lõi và terabyte bộ nhớ. Quyền truy cập vào không gian tên được cấp thông qua AD (chúng tôi sử dụng RBAC). Các không gian tên và giới hạn của chúng được thêm vào thông qua yêu cầu kéo tới kho lưu trữ GIT, sau đó mọi thứ sẽ tự động được triển khai thông qua đường dẫn Ansible.
Ví dụ về phân bổ nguồn lực cho một nhóm:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Yêu cầu và giới hạn
hình khối" Yêu cầu là số lượng tài nguyên dành riêng được đảm bảo cho pod (một hoặc nhiều container docker) trong một cụm. Giới hạn là mức tối đa không được đảm bảo. Bạn thường có thể thấy trên biểu đồ cách một số nhóm đã tự đặt ra quá nhiều yêu cầu cho tất cả các ứng dụng của mình và không thể triển khai ứng dụng lên “Cube”, vì tất cả các yêu cầu trong không gian tên của họ đã được “chi tiêu”.
Cách chính xác để thoát khỏi tình huống này là xem xét mức tiêu thụ tài nguyên thực tế và so sánh nó với lượng được yêu cầu (Yêu cầu).
Trong ảnh chụp màn hình ở trên, bạn có thể thấy rằng CPU “Được yêu cầu” được khớp với số luồng thực và Giới hạn có thể vượt quá số luồng CPU thực =)
Bây giờ chúng ta hãy xem xét chi tiết một số không gian tên (tôi đã chọn không gian tên kube-system - không gian tên hệ thống cho các thành phần của chính “Cube”) và xem tỷ lệ giữa thời gian và bộ nhớ của bộ xử lý được sử dụng thực tế so với yêu cầu:
Rõ ràng là nhiều bộ nhớ và CPU được dành cho các dịch vụ hệ thống hơn mức sử dụng thực tế. Trong trường hợp của hệ thống kube, điều này là hợp lý: đã xảy ra trường hợp bộ điều khiển xâm nhập nginx hoặc nodelocaldns ở mức cao nhất của chúng chạm vào CPU và tiêu tốn rất nhiều RAM, vì vậy việc dự trữ như vậy ở đây là hợp lý. Ngoài ra, chúng ta không thể dựa vào biểu đồ trong 3 giờ qua: nên xem các số liệu lịch sử trong một khoảng thời gian dài.
Một hệ thống “khuyến nghị” đã được phát triển. Ví dụ: tại đây, bạn có thể xem tài nguyên nào sẽ tốt hơn khi tăng “giới hạn” (thanh trên cho phép) để không xảy ra hiện tượng “điều tiết”: thời điểm tài nguyên đã sử dụng hết CPU hoặc bộ nhớ trong lát thời gian được phân bổ và đang đợi cho đến khi nó được "mở băng":
Và đây là những loại quả có thể hạn chế sự thèm ăn của chúng:
trên điều tiết + giám sát tài nguyên, bạn có thể viết nhiều bài, vì vậy hãy đặt câu hỏi trong phần bình luận. Nói một cách ngắn gọn, tôi có thể nói rằng nhiệm vụ tự động hóa các số liệu như vậy là rất khó khăn và đòi hỏi nhiều thời gian cũng như hành động cân bằng giữa các chức năng “cửa sổ” và “CTE” Prometheus / VictoriaMetrics (các thuật ngữ này được đặt trong dấu ngoặc kép, vì gần như không có gì giống như thế này trong PromQL và bạn phải chia các truy vấn đáng sợ thành nhiều màn hình văn bản và tối ưu hóa chúng).
Do đó, các nhà phát triển có các công cụ để giám sát không gian tên của họ trong Cube và họ có thể tự chọn địa điểm và thời điểm ứng dụng nào có thể bị “cắt” tài nguyên và máy chủ nào có thể được cấp toàn bộ CPU suốt đêm.
Phương pháp luận
Ở công ty như bây giờ hợp thời trang, chúng tôi tuân thủ DevOps- và SRE-người hành nghề Khi một công ty có 1000 microservice, khoảng 350 nhà phát triển và 15 quản trị viên cho toàn bộ cơ sở hạ tầng, bạn phải “thời thượng”: đằng sau tất cả những “khẩu phần” này có nhu cầu cấp thiết là tự động hóa mọi thứ và mọi người, và quản trị viên không nên trở thành nút thắt cổ chai trong các quá trình.
Với tư cách là Vận hành, chúng tôi cung cấp nhiều số liệu và bảng thông tin khác nhau cho nhà phát triển liên quan đến tỷ lệ phản hồi và lỗi dịch vụ.
Chúng tôi sử dụng các phương pháp như: , и bằng cách kết hợp chúng lại với nhau. Chúng tôi cố gắng giảm thiểu số lượng trang tổng quan để có thể nhanh chóng biết được dịch vụ nào hiện đang xuống cấp (ví dụ: mã phản hồi mỗi giây, thời gian phản hồi theo phân vị thứ 99), v.v. Ngay khi một số số liệu mới trở nên cần thiết cho trang tổng quan chung, chúng tôi sẽ ngay lập tức vẽ và thêm chúng.
Tôi đã không vẽ đồ thị trong một tháng. Đây có lẽ là một dấu hiệu tốt: nó có nghĩa là hầu hết những “mong muốn” đã được thực hiện. Tình cờ là trong tuần tôi sẽ vẽ một số biểu đồ mới ít nhất một lần một ngày.
Kết quả thu được rất có giá trị vì hiện nay các nhà phát triển hiếm khi tìm đến quản trị viên để đặt câu hỏi “xem một số loại số liệu ở đâu”.
Thực hiện Lưới dịch vụ sắp đến gần và sẽ giúp cuộc sống của mọi người dễ dàng hơn nhiều, các đồng nghiệp từ Công cụ đã gần triển khai tóm tắt “Istio của một người khỏe mạnh”: vòng đời của mỗi yêu cầu HTTP sẽ hiển thị trong quá trình giám sát và nó sẽ luôn có thể hiểu được “mọi thứ đã hỏng ở giai đoạn nào” trong quá trình tương tác giữa các dịch vụ (và không chỉ). Đăng ký nhận tin tức từ trung tâm DomClick. =)
Hỗ trợ cơ sở hạ tầng Kubernetes
Trong lịch sử, chúng tôi sử dụng phiên bản vá Kubespray — Vai trò có thể thực hiện được trong việc triển khai, mở rộng và cập nhật Kubernetes. Tại một số thời điểm, nhánh chính đã cắt hỗ trợ cài đặt không phải kubeadm và quá trình chuyển sang kubeadm không được đề xuất. Kết quả là công ty Southbridge đã tạo ra fork của riêng mình (với sự hỗ trợ của kubeadm và cách khắc phục nhanh chóng các vấn đề nghiêm trọng).
Quá trình cập nhật tất cả các cụm k8s trông như thế này:
- Chúng tôi lấy Kubespray từ Southbridge, hãy kiểm tra chủ đề của chúng tôi, Merjim.
- Chúng tôi đang triển khai bản cập nhật cho Căng thẳng- “Khối lập phương”.
- Chúng tôi triển khai bản cập nhật từng nút một (trong Ansible đây là “serial: 1”) trong Dev- “Khối lập phương”.
- Chúng tôi cập nhật Sản vào tối thứ bảy, mỗi lần một nút.
Có kế hoạch thay thế nó trong tương lai Kubespray để tìm thứ gì đó nhanh hơn và đi đến kubeadm.
Tổng cộng chúng tôi có ba “Khối”: Stress, Dev và Prod. Chúng tôi đang có kế hoạch ra mắt một cái khác (chế độ chờ nóng) Prod-“Cube” trong trung tâm dữ liệu thứ hai. Căng thẳng и Dev sống trong “máy ảo” (oVirt dành cho Stress và đám mây VMWare dành cho Dev). Sản- “Cube” tồn tại trên “kim loại trần”: đây là các nút giống hệt nhau với 32 luồng CPU, bộ nhớ 64-128 GB và SSD 300 GB RAID 10 - tổng cộng có 50 nút trong số đó. Ba nút “mỏng” được dành riêng cho “bậc thầy” Sản- “Cuba”: Bộ nhớ 16 GB, CPU 12 luồng.
Để bán hàng, chúng tôi ưu tiên sử dụng “kim loại trần” và tránh các lớp không cần thiết như OpenStack: chúng tôi không cần “hàng xóm ồn ào” và CPU ăn trộm thời gian. Và sự phức tạp của việc quản trị gần như tăng gấp đôi trong trường hợp OpenStack nội bộ.
Đối với CI/CD “Cubic” và các thành phần cơ sở hạ tầng khác, chúng tôi sử dụng máy chủ GIT riêng, Helm 3 (đó là một quá trình chuyển đổi khá khó khăn từ Helm 2, nhưng chúng tôi rất hài lòng với các tùy chọn nguyên tử), Jenkins, Ansible và Docker. Chúng tôi yêu thích các nhánh tính năng và triển khai đến các môi trường khác nhau từ một kho lưu trữ.
Kết luận
Nói chung, đây là quy trình DevOps trông như thế nào tại DomClick từ góc nhìn của một kỹ sư vận hành. Bài viết hóa ra ít mang tính kỹ thuật hơn tôi mong đợi: do đó, hãy theo dõi tin tức DomClick trên Habré: sẽ có nhiều bài viết “khó tính” hơn về Kubernetes và hơn thế nữa.
Nguồn: www.habr.com