Ghi chú dịch: Đây là bản dịch của khám nghiệm tử thi công khai từ blog kỹ thuật của công ty . Nó mô tả sự cố với conntrack trong cụm Kubernetes, dẫn đến thời gian ngừng hoạt động một phần của một số dịch vụ sản xuất.
Bài viết này có thể hữu ích cho những ai muốn tìm hiểu thêm một chút về postmortems hoặc ngăn ngừa một số vấn đề DNS tiềm ẩn trong tương lai.
Đây không phải là DNS
Nó không thể là DNS
Đó là DNS
Một chút về khám nghiệm tử thi và quy trình trong Preply
Khám nghiệm tử thi mô tả một trục trặc hoặc một sự kiện nào đó trong quá trình sản xuất. Quá trình khám nghiệm tử thi bao gồm dòng thời gian của các sự kiện, tác động của người dùng, nguyên nhân gốc rễ, các hành động đã thực hiện và bài học kinh nghiệm.
Tại các cuộc họp hàng tuần với pizza, giữa nhóm kỹ thuật, chúng tôi chia sẻ nhiều thông tin khác nhau. Một trong những phần quan trọng nhất của những cuộc họp như vậy là khám nghiệm tử thi, thường đi kèm với phần trình bày bằng slide và phân tích sâu hơn về vụ việc. Mặc dù chúng tôi không vỗ tay sau khi khám nghiệm tử thi, nhưng chúng tôi cố gắng phát triển văn hóa "không đổ lỗi" (). Chúng tôi tin rằng việc viết và trình bày kết quả khám nghiệm tử thi có thể giúp chúng tôi (và những người khác) ngăn ngừa những sự cố tương tự trong tương lai, đó là lý do tại sao chúng tôi chia sẻ chúng.
Các cá nhân liên quan đến một vụ việc nên cảm thấy rằng họ có thể nói ra chi tiết mà không sợ bị trừng phạt hoặc bị trả thù. Không đổ lôi! Viết bản khám nghiệm tử thi không phải là một hình phạt mà là cơ hội học hỏi cho toàn thể công ty.
Sự cố với DNS trong Kubernetes. khám nghiệm tử thi
Дата: 28.02.2020
Các tác giả: Amet U., Andrey S., Igor K., Alexey P.
Tiêu đề: Đã kết thúc
Tóm lại: Không có DNS một phần (26 phút) đối với một số dịch vụ trong cụm Kubernetes
Va chạm: 15000 sự kiện bị mất đối với các dịch vụ A, B và C
Nguyên nhân sâu xa: Kube-proxy không thể xóa chính xác mục nhập cũ khỏi bảng conntrack, vì vậy một số dịch vụ vẫn đang cố gắng kết nối với các nhóm không tồn tại
E0228 20:13:53.795782 1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...Cò súng: Do tải bên trong cụm Kubernetes thấp, CoreDNS-autoscaler đã giảm số lượng nhóm trong quá trình triển khai từ ba xuống còn hai
giải pháp: Lần triển khai ứng dụng tiếp theo đã bắt đầu việc tạo các nút mới, CoreDNS-autoscaler đã thêm nhiều nhóm hơn để phục vụ cụm, điều này dẫn đến việc viết lại bảng conntrack
phát hiện: Giám sát của Prometheus đã phát hiện một số lượng lớn lỗi 5xx đối với các dịch vụ A, B và C và bắt đầu cuộc gọi tới các kỹ sư đang làm nhiệm vụ
Lỗi 5xx ở Kibana
Hoạt động
ảnh hưởng
Loại
Chịu trách nhiệm
Nhiệm vụ
Tắt tính năng tự động chia tỷ lệ cho CoreDNS
ngăn chặn
Amet U.
DEVOPS-695
Thiết lập máy chủ DNS lưu vào bộ nhớ đệm
giảm bớt
Max V.
DEVOPS-665
Thiết lập giám sát conntrack
ngăn chặn
Amet U.
DEVOPS-674
Bài học kinh nghiệm
Điều gì đã diễn ra tốt đẹp:
- Việc giám sát đã hoạt động tốt. Phản hồi nhanh chóng và có tổ chức
- Chúng tôi không đạt bất kỳ giới hạn nào đối với các nút
Có gì sai:
- Vẫn chưa rõ nguyên nhân thực sự, tương tự như ngược lại
- Mọi hành động chỉ sửa được hậu quả chứ không sửa được nguyên nhân gốc rễ (lỗi)
- Chúng tôi biết rằng sớm hay muộn chúng tôi cũng có thể gặp sự cố với DNS, nhưng chúng tôi đã không ưu tiên các nhiệm vụ
Nơi chúng tôi gặp may mắn:
- Lần triển khai tiếp theo được kích hoạt bởi CoreDNS-autoscaler, nó ghi đè lên bảng conntrack
- Lỗi này chỉ ảnh hưởng đến một số dịch vụ
Dòng thời gian (EET)
thời gian
ảnh hưởng
22:13
CoreDNS-autoscaler đã giảm số lượng nhóm từ ba xuống còn hai
22:18
Các kỹ sư đang làm nhiệm vụ bắt đầu nhận được cuộc gọi từ hệ thống giám sát
22:21
Các kỹ sư trực ban bắt đầu tìm ra nguyên nhân gây ra lỗi.
22:39
Các kỹ sư đang làm nhiệm vụ bắt đầu đưa một trong những dịch vụ mới nhất về phiên bản trước
22:40
Lỗi 5xx đã ngừng xuất hiện, tình hình đã ổn định
- Thời gian phát hiện: 4 phút
- Thời gian trước khi hành động: 21 phút
- Thời gian khắc phục: 1 phút
thêm thông tin
- Nhật ký CoreDNS:
I0228 20:13:53.507780 1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2 - Liên kết tới Kibana (cắt), Grafana (cắt)
Để giảm thiểu việc sử dụng CPU, nhân Linux sử dụng một thứ gọi là conntrack. Nói tóm lại, đây là một tiện ích chứa danh sách các bản ghi NAT được lưu trữ trong một bảng đặc biệt. Khi gói tiếp theo đến từ cùng một nhóm đến cùng một nhóm như trước, địa chỉ IP cuối cùng sẽ không được tính toán lại mà sẽ được lấy từ bảng conntrack.
Conntrack hoạt động như thế nào
Kết quả
Đây là một ví dụ về một trong những cuộc khám nghiệm tử thi của chúng tôi với một số liên kết hữu ích. Cụ thể trong bài viết này, chúng tôi chia sẻ thông tin có thể hữu ích cho các công ty khác. Đó là lý do tại sao chúng tôi không sợ mắc sai lầm và đó là lý do tại sao chúng tôi công khai một trong những khám nghiệm tử thi của mình. Dưới đây là một số khám nghiệm tử thi công khai thú vị hơn:
- GitLab:
- Dropbox:
- Spotify:
- Nhiều người khác từ và kho lưu trữ
- Ngoài ra khám nghiệm tử thi công khai với SRE Book
Nguồn: www.habr.com