minikube không tới được API riêng? Hãy kiểm tra driver trước
Máy chủ, node và Pod mỗi bên có tuyến và resolver riêng. Gọi tên driver, kiểm tra cùng một endpoint từ cả ba, rồi sửa ngữ cảnh đã hỏng.
Một API riêng trả lời từ laptop của bạn và một Pod trong minikube không thể tới được nó. Trước khi thay đổi bất cứ thứ gì trên máy chủ, hãy gọi tên driver đứng sau profile đang hoạt động, vì riêng sự thật này quyết định yêu cầu thực sự rời khỏi mạng nào. Sau đó kiểm tra cùng một endpoint từ máy chủ, từ node và từ Pod. Chỉ một trong ba mới là thứ đã hỏng, và đoán sai tốn một buổi chiều.
Bước 0: gọi tên driver và nguồn gốc
Hỏi minikube xem profile nào đang hoạt động và nó chạy thế nào. Một driver container đặt node vào một container trên máy của bạn, driver VM đặt nó vào một máy ảo, và driver từ xa đặt nó ở một nơi hoàn toàn khác.
minikube profile list
minikube status
kubectl config current-contextTừ đó, ghi lại yêu cầu bắt nguồn từ đâu. Câu trả lời quyết định resolver của ai và những tuyến nào quan trọng, và không phải lúc nào cũng là của máy chủ. Hai profile trên cùng một laptop có thể hành xử hoàn toàn khác nhau với cùng một URL.
| Context | What has to work |
|---|---|
| Host process | Host resolver and host route to the private destination |
| minikube node | The node's own resolver and its outbound path |
| Pod | Pod DNS through cluster services plus the cluster network path |
Bước 1: kiểm tra cùng một endpoint ba lần
Dùng một endpoint vô hại và giữ nguyên tên máy chủ, cổng và họ địa chỉ trong cả ba lần kiểm tra. Thay đổi bất kỳ thứ nào trong số đó giữa các lần chạy sẽ khiến kết quả không thể so sánh.
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/healthMột lần kéo image thành công từ node không chứng minh gì về việc phân giải tên cho một máy chủ riêng. Một yêu cầu công khai thành công còn chứng minh ít hơn. Giữ kết quả tách theo ngữ cảnh, vì một mẫu trên ba hàng là chẩn đoán còn một thất bại đơn lẻ là manh mối.
Nếu hàng máy chủ cũng hỏng, hãy dừng. Bạn có vấn đề mạng trên máy chủ và cụm chỉ là thứ gây xao nhãng.
Bước 2: giữ đường của máy chủ tới cụm
Có một hướng thứ hai mà người ta quên: máy chủ phải tiếp tục tới được API và các dịch vụ của chính cụm. Một client VPN có thể cài những tuyến cạnh tranh với các tiền tố mà minikube dùng cho mạng node, dải dịch vụ và dải pod của nó.
Khi điều đó xảy ra, triệu chứng thật khó hiểu, vì đường hầm vẫn hoạt động mà kubectl ngừng phản hồi hoặc một NodePort từ chối kết nối. Nó trông như lỗi của cụm và thực ra là lỗi định tuyến của laptop.
Kiểm tra bảng định tuyến của máy chủ so với các dải của minikube trước khi đổ lỗi cho đường hầm về bất cứ điều gì khác. Sự chồng lấn thường hiện ra như một tuyến cụ thể hơn trỏ tới giao diện đường hầm cho một tiền tố mà cụm cho là của mình.
Bước 3: giải quyết chồng lấn mà không tắt VPN
Cuốn sổ tay VPN và proxy của chính minikube bàn về những xung đột này và coi các dải ví dụ của nó là thứ cần kiểm tra, không phải danh sách phổ quát. Hãy đọc nó cùng với profile bạn thực sự có.
Ở nơi có chồng lấn thật, câu trả lời được hỗ trợ là một dải không chồng lấn hoặc một chính sách truy cập nội bộ có chủ đích được người sở hữu VPN phê duyệt. Đổi dải dịch vụ không giống đổi dải pod, và cả hai đều không giống đổi mạng node.
Tắt đường hầm công ty để cụm nội bộ chạy được không phải là cách lách; đó là quyết định chính sách mà người khác phải đưa ra. Hãy đưa nó tới người đó thay vì làm lặng lẽ sau khi mọi người đã về nhà. Nếu bạn đã làm rồi, hãy khôi phục trước khi hỏi.
Bước 4: tách proxy, DNS và bốn dạng thất bại
Nếu cần proxy, hãy xác định ngữ cảnh nào cần nó. Một thiết lập trình duyệt trên máy chủ không cấu hình một tiến trình bên trong node, và một Pod cần biến môi trường hoặc cấu hình proxy ở cấp cụm.
Sau đó phân loại thất bại thay vì mô tả nó. Một tên không phân giải được là DNS. Một tên phân giải được và từ chối kết nối là định tuyến hoặc một listener. Một kết nối được thiết lập và hỏng ở danh tính là TLS. Một kết nối thành công kèm nội dung lỗi là ứng dụng.
Mỗi một trong bốn thứ đó thuộc về một cách sửa khác nhau, và chỉ một trong số chúng liên quan đến VPN. Ghi lại bạn đã quan sát thấy cái nào ở mỗi ngữ cảnh, và người tiếp theo sẽ thừa hưởng bằng chứng thay vì một câu chuyện.