Các nút GKE riêng tư không quyết định kubectl dùng API nào

Các nút là riêng tư, VPN đến được chúng, và kubectl vẫn không nói chuyện được với cụm. Hai sự thật đó không liên quan đến nhau. Địa chỉ mà kubectl dùng đến từ URL máy chủ được lưu trong kubeconfig khi thông tin xác thực được lấy về, và không tuyến đường nào bạn thêm vào thay đổi được nó. Trong khi đó, các nút hoàn toàn không phải thứ kubectl đang cố gắng tiếp cận.

Năm bước kiểm tra, bắt đầu từ giá trị duy nhất quan trọng.

Kiểm tra 1: đọc URL máy chủ trong kubeconfig

In điểm cuối mà không làm lộ thông tin xác thực: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Chuỗi duy nhất đó cho bạn biết máy khách đang trỏ tới một địa chỉ IP, một tên DNS hay một địa chỉ bên ngoài mà bạn không định dùng. Mọi thứ khác trong cuộc điều tra này đều suy ra từ đó.

Nếu URL không phải điểm cuối mà bạn tưởng đã cấu hình, phần còn lại của chẩn đoán chỉ là sự phân tâm.

Kiểm tra 2: khớp URL với loại điểm cuối

GKE hiện tại hỗ trợ truy cập bảng điều khiển cả theo IP lẫn theo DNS, và thông tin xác thực bạn lấy về sẽ chọn một trong hai. gcloud container clusters get-credentials NAME --location REGION --internal-ip ghi điểm cuối IP nội bộ, trong khi --dns-endpoint chọn truy cập theo DNS. Không cờ nào cung cấp một đường mạng, điều khiến những người mong việc lấy thông tin xác thực sẽ sửa được kết nối phải ngạc nhiên. Hãy cố ý lấy lại rồi đọc URL một lần nữa sau đó.

Đổi cờ mà không đọc lại URL là cách một chiếc máy tính xách tay rơi vào tình trạng giữ thông tin xác thực của hai cụm và một lỗi khó hiểu.

Một mục trong mạng được phép quyết định ai được tiếp cận điểm cuối bên ngoài và không áp dụng cho điểm cuối bên trong. Mở rộng nó để thử một đường riêng tư sẽ thay đổi mức phơi nhiễm của bạn, không phải chẩn đoán của bạn.

Kiểm tra 3: chứng minh đường đi tới điểm cuối đó

Nếu URL là IP nội bộ, hãy kiểm tra tuyến từ mạng nơi máy khách thực sự nằm, dải nguồn được phép và cài đặt truy cập theo vùng hoặc toàn cầu của cụm. Dải của bảng điều khiển và mạng con của nút không phải cùng một đích, nên một tuyến hoạt động tới các nút không chứng minh được gì về điểm cuối. Với truy cập theo DNS, đường đi là kết nối tới Google API cùng cơ chế Private Google Access đã được tài liệu hóa, không phải tuyến tới mạng con của các máy chạy tác vụ. Hãy thử điểm cuối bằng một kết nối TCP thường trước khi đổ lỗi cho kubectl.

Hết thời gian là vấn đề đường đi. 403 là vấn đề chính sách. Chúng không dùng chung một cách sửa.

Kiểm tra 4: tách nhật ký và exec khỏi các lệnh gọi API

Nếu các yêu cầu API thông thường thành công mà kubectl logs hoặc kubectl exec thất bại, bạn đã đi qua bước chọn điểm cuối. Những thao tác đó cần các quyền Kubernetes tương ứng và phụ thuộc vào liên lạc từ bảng điều khiển tới các nút, và lỗi có thể là phản hồi Forbidden chứ không phải hết thời gian. Truy cập SSH tới một nút kiểm tra một dịch vụ hoàn toàn khác và không thiết lập được chúng.

Hãy đọc lớp lỗi trước khi mở lại phiếu VPN, vì hai lớp đó sống ở những nơi khác nhau.

Kiểm tra 5: giữ ba quan sát cho người tiếp theo

Ghi lại URL API đã chọn, liệu một yêu cầu API được phép có hoạt động không và chính xác thao tác nào sau đó thất bại, kèm văn bản lỗi. Ba dòng đó tách việc chọn điểm cuối khỏi truy cập nút, và ngăn một tuyến VPN hoàn toàn tốt bị đổ lỗi cho một yêu cầu mà nó chưa từng chở.

Kỹ sư tiếp theo sẽ hỏi liệu đường hầm có hỏng không. Ghi chú của bạn lẽ ra đã trả lời điều đó.