AKS không kéo được image từ registry riêng phía sau VPN
kubelet kéo qua mạng của node, không qua VPN của pod. Hãy quyết định theo tuyến của node, DNS của node, mọi endpoint mà lần kéo chạm tới, rồi TLS và danh tính.
Laptop của bạn kéo image không vấn đề gì, nhưng pod vẫn kẹt trong ImagePullBackOff và ai đó đề xuất chạy VPN client của công ty như sidecar. Điều đó không giúp được, vì việc kéo xảy ra trước khi container của bạn tồn tại: kubelet yêu cầu container runtime trên node lấy image, và runtime dùng network namespace của node.
Thứ tự thao tác quyết định tầng
Trước hết là phân giải tên, rồi kết nối, xác thực, tải các layer, và chỉ sau đó container mới khởi động. Mọi thứ pod làm với VPN đều diễn ra sau chuỗi đó, nên một tunnel chạy được trong cluster không phải bằng chứng về lần kéo.
Vì thế image trong cache là lời nói dối thuyết phục: node kéo image vài tuần trước vẫn tiếp tục phục vụ, deployment trông khỏe mạnh, và lỗi chỉ hiện ra khi scheduler đặt replica trên node mới hơn. scale-up hay thay node là yếu tố kích hoạt, không phải nguyên nhân.
Ba điều kiện quyết định cách sửa
Khả năng tiếp cận quy về định tuyến, phân giải tên và tập endpoint. Nếu subnet của node không định tuyến được tới mạng registry thì không thông tin đăng nhập nào giúp. Nếu tên không phân giải được qua đường DNS của node thì kết nối không bắt đầu. Nếu chỉ tới được manifest mà không tới blob, lần kéo sẽ hỏng giữa chừng.
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
Chỉ VNet peering không cung cấp mọi cấu hình gateway transit, và tuyến một chiều không phải tuyến hoạt động. Node cần đường được hỗ trợ qua VPN gateway đã định, phía registry cần tuyến quay lại subnet của node.
Đọc lỗi trước khi chọn cách sửa
Bắt đầu từ event của pod và node nơi nó hạ cánh, với tên thật của bạn: kubectl describe pod app-example -n team-example và kubectl get pod app-example -n team-example -o wide. Nội dung event phân biệt hostname không phân giải với timeout, từ chối certificate với image thiếu, và lỗi ủy quyền với tất cả những thứ đó.
Xác thực là đòn bẩy bị đánh giá quá cao nhất. imagePullSecret cấp thông tin đăng nhập registry cho runtime; nó không cài tuyến, không đổi resolver của node và không làm certificate không tin cậy trở nên hợp lệ. Nếu event nói lần kéo không được ủy quyền, hãy xem phạm vi danh tính; nếu nói kết nối hết thời gian, thông tin đăng nhập không liên quan.
Tài liệu image của Kubernetes là nguồn về hành vi kéo và thông tin đăng nhập registry riêng, và nên đọc một lần trước khi đổi mạng, vì nó làm rõ ranh giới giữa xác thực và truyền tải.
Xây con đường bên dưới pod
Làm theo thứ tự này. Trước hết định tuyến mạng của node: xác nhận subnet có đường được hỗ trợ tới mạng registry, kiểm tra tuyến hiệu lực trên node, quy tắc bảo mật ở hai đầu và tuyến quay lại phía registry.
Sau đó phân giải tên từ ngữ cảnh của node. Resolver của node không phải cấu hình DNS của pod, và thành công trong pod không phải bằng chứng cho host runtime. Dùng DNS riêng được quản lý thay vì mục hosts cố định; mục đó tồn tại tới khi node bị thay rồi biến mất lặng lẽ.
Sau đó chứng minh từng endpoint. Registry có thể cấp cho client một dịch vụ xác thực riêng và một nơi lưu blob riêng. Tới được manifest gần như không chứng minh gì về các layer. Cuối cùng hoàn tất TLS và ủy quyền: certificate hợp lệ cho tên registry và được tin cậy qua cấu hình node được hỗ trợ, cùng danh tính kéo chỉ giới hạn đọc repo đó.
Kiểm chứng trên node bạn không sửa bằng tay
Phép thử có ý nghĩa là một lần kéo mới và tải đầy đủ mọi layer trên node phù hợp, tốt nhất là node được tạo bằng scale hoặc thay thế. Nó bao phủ mọi pool có thể đặt workload, kể cả những pool bạn quên. Sửa tay trên một node không phải mô hình triển khai, và sự kiện autoscale tiếp theo sẽ tìm ra lỗ hổng.
Tạo lại cluster ở VNet khác có thể đổi đường đi, nhưng đó là phương án cuối chứ không phải bước chẩn đoán đầu tiên. Hãy so mạng node hiện có với tuyến riêng cần thiết và các kiểm soát mạng AKS được hỗ trợ trước khi đề xuất di chuyển, và giữ kết nối ứng dụng sau khi khởi động như một kiểm chứng riêng: pod nói chuyện với backend là phép kiểm khác với node tải image.