Prohoster > Blog > quản lý > Tra cứu DNS trong Kubernetes

Tra cứu DNS trong Kubernetes

Ghi chú. bản dịch.: Sự cố DNS trong Kubernetes, hay chính xác hơn là cài đặt tham số ndots, phổ biến một cách đáng ngạc nhiên, và đã không phải là người đầu tiên năm. Trong một ghi chú khác về chủ đề này, tác giả của nó, một kỹ sư DevOps từ một công ty môi giới lớn ở Ấn Độ, nói một cách rất đơn giản và ngắn gọn về những điều hữu ích mà các đồng nghiệp vận hành Kubernetes cần biết.

Tra cứu DNS trong Kubernetes

Một trong những lợi ích chính của việc triển khai ứng dụng trên Kubernetes là khám phá ứng dụng liền mạch. Tương tác nội bộ cụm được đơn giản hóa rất nhiều nhờ khái niệm dịch vụ (Dịch vụ), là một IP ảo hỗ trợ một tập hợp các địa chỉ IP nhóm. Ví dụ, nếu dịch vụ vanilla mong muốn liên hệ với dịch vụ chocolate, nó có thể truy cập trực tiếp vào IP ảo để chocolate. Câu hỏi đặt ra: trong trường hợp này ai sẽ giải quyết yêu cầu DNS tới chocolate Và làm thế nào?

Độ phân giải tên DNS được định cấu hình trên cụm Kubernetes bằng cách sử dụng lõiDNS. Kubelet đăng ký một nhóm có CoreDNS làm máy chủ tên trong các tệp /etc/resolv.conf tất cả các quả. Nếu bạn nhìn vào nội dung /etc/resolv.conf bất kỳ nhóm nào, nó sẽ trông giống như thế này:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

Cấu hình này được máy khách DNS sử dụng để chuyển tiếp yêu cầu đến máy chủ DNS. Trong tập tin resolv.conf chứa các thông tin sau:

  • tên máy chủ: máy chủ mà các yêu cầu DNS sẽ được gửi tới. Trong trường hợp của chúng tôi, đây là địa chỉ của dịch vụ CoreDNS;
  • Tìm kiếm: Xác định đường dẫn tìm kiếm cho một tên miền cụ thể. Thật thú vị google.com hoặc mrkaran.dev không phải là FQDN (tên miền đủ điều kiện). Theo quy ước tiêu chuẩn mà hầu hết các trình phân giải DNS tuân theo, chỉ những miền kết thúc bằng dấu chấm ".", đại diện cho vùng gốc, mới được coi là các miền đủ điều kiện (FDQN). Một số người giải quyết có thể tự thêm một điểm. Như vậy, mrkaran.dev. là tên miền đủ điều kiện (FQDN) và mrkaran.dev - KHÔNG;
  • dấu chấm: Thông số thú vị nhất (bài viết này nói về nó). ndots chỉ định số lượng ngưỡng dấu chấm trong tên yêu cầu trước khi nó được coi là tên miền "đủ điều kiện". Chúng ta sẽ nói nhiều hơn về điều này sau khi phân tích trình tự tra cứu DNS.

Tra cứu DNS trong Kubernetes

Hãy xem điều gì xảy ra khi chúng ta hỏi mrkaran.dev trong nhóm:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

Đối với thử nghiệm này, tôi đặt mức ghi nhật ký CoreDNS thành all (điều này làm cho nó khá dài dòng). Hãy nhìn vào nhật ký của nhóm coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

Phù. Hai điều thu hút sự chú ý của bạn ở đây:

  • Yêu cầu trải qua tất cả các giai đoạn tìm kiếm cho đến khi phản hồi chứa mã NOERROR (Kết quả là máy khách DNS hiểu nó và lưu trữ nó). NXDOMAIN có nghĩa là không tìm thấy bản ghi nào cho tên miền đã cho. Bởi vì mrkaran.dev không phải là tên FQDN (theo ndots=5), trình phân giải sẽ xem xét đường dẫn tìm kiếm và xác định thứ tự các yêu cầu;
  • Entries А и АААА đến song song. Thực tế là các yêu cầu một lần trong /etc/resolv.conf Theo mặc định, chúng được cấu hình theo cách thực hiện tìm kiếm song song bằng giao thức IPv4 và IPv6. Bạn có thể hủy hành vi này bằng cách thêm tùy chọn single-request в resolv.conf.

Lưu ý: glibc có thể được cấu hình để gửi các yêu cầu này một cách tuần tự và musl - không, vì vậy người dùng Alpine cần lưu ý.

Thử nghiệm với ndots

Hãy thử nghiệm thêm một chút với ndots và hãy xem tham số này hoạt động như thế nào. Ý tưởng rất đơn giản: ndots xác định xem máy khách DNS sẽ coi tên miền là tuyệt đối hay tương đối. Ví dụ: trong trường hợp máy khách DNS đơn giản của Google, làm thế nào để biết tên miền này có tuyệt đối hay không? Nếu bạn đặt ndots bằng 1, khách hàng sẽ nói: "Ồ, trong google không có một điểm nào; Tôi đoán tôi sẽ xem qua toàn bộ danh sách tìm kiếm.” Tuy nhiên, nếu bạn hỏi google.com, danh sách hậu tố sẽ bị bỏ qua hoàn toàn vì tên được yêu cầu đạt ngưỡng ndots (có ít nhất một điểm).

Hãy chắc chắn về điều này:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

Nhật ký CoreDNS:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

Kể từ trong mrkaran không có một điểm nào, việc tìm kiếm được thực hiện trên toàn bộ danh sách các hậu tố.

Lưu ý: trong thực tế giá trị tối đa ndots giới hạn ở 15; theo mặc định trong Kubernetes là 5.

Ứng dụng trong sản xuất

Nếu một ứng dụng thực hiện nhiều cuộc gọi mạng bên ngoài, DNS có thể trở thành nút cổ chai trong trường hợp lưu lượng truy cập đang hoạt động, vì việc phân giải tên sẽ thực hiện nhiều truy vấn không cần thiết (trước khi hệ thống tìm đúng truy vấn). Các ứng dụng thường không thêm vùng gốc vào tên miền, nhưng điều này có vẻ giống như một trò hack. Tức là thay vì hỏi api.twitter.com, bạn có thể 'mã hóa cứng' nó api.twitter.com. (có dấu chấm) trong ứng dụng, thao tác này sẽ nhắc máy khách DNS thực hiện tra cứu chính thức trực tiếp trên miền tuyệt đối.

Ngoài ra, bắt đầu với Kubernetes phiên bản 1.14, các tiện ích mở rộng dnsConfig и dnsPolicy nhận được trạng thái ổn định. Do đó, khi triển khai một nhóm, bạn có thể giảm giá trị ndots, chẳng hạn, tối đa 3 (và thậm chí lên tới 1!). Vì điều này, mọi tin nhắn trong một nút sẽ phải bao gồm miền đầy đủ. Đây là một trong những sự đánh đổi kinh điển khi bạn phải lựa chọn giữa hiệu suất và tính di động. Đối với tôi, có vẻ như bạn chỉ nên lo lắng về điều này nếu độ trễ cực thấp là quan trọng đối với ứng dụng của bạn, vì kết quả DNS cũng được lưu vào bộ nhớ đệm nội bộ.

tài liệu tham khảo

Lần đầu tiên tôi biết đến tính năng này trên K8s-gặp mặt, được tổ chức vào ngày 25 tháng XNUMX. Đã có một cuộc thảo luận về vấn đề này, trong số những vấn đề khác.

Dưới đây là một số liên kết để khám phá thêm:

Lưu ý: Tôi đã chọn không sử dụng dig trong bài viết này. dig tự động thêm dấu chấm (mã định danh vùng gốc), làm cho tên miền "đủ điều kiện" (FQDN), không trước tiên hãy chạy nó qua danh sách tìm kiếm. Đã viết về điều này trong một trong những ấn phẩm trước đây. Tuy nhiên, điều khá ngạc nhiên là, nói chung, một cờ riêng biệt phải được chỉ định cho hành vi tiêu chuẩn.

Chúc mừng DNSing! Hẹn gặp lại!

Tái bút từ người dịch

Đọc thêm trên blog của chúng tôi:

Nguồn: www.habr.com

Thêm một lời nhận xét