minikube เข้าถึง API ส่วนตัวไม่ได้? ตรวจสอบไดรเวอร์ก่อน
โฮสต์ โหนด และ Pod ต่างมีเส้นทางและ resolver ของตัวเอง ระบุชื่อไดรเวอร์ ทดสอบ endpoint เดียวกันจากทั้งสาม แล้วแก้บริบทที่ล้มเหลว
API ส่วนตัวตอบกลับจากแล็ปท็อปของคุณ แต่ Pod ใน minikube เข้าถึงไม่ได้ ก่อนจะเปลี่ยนอะไรบนโฮสต์ ให้ระบุชื่อไดรเวอร์ที่อยู่เบื้องหลังโปรไฟล์ที่ใช้งานอยู่ เพราะข้อเท็จจริงเดียวนี้เป็นตัวกำหนดว่าคำขอออกจากเครือข่ายใดจริง ๆ จากนั้นทดสอบ endpoint เดียวกันจากโฮสต์ จากโหนด และจาก Pod มีเพียงหนึ่งในสามเท่านั้นคือสิ่งที่ล้มเหลว และการเดาผิดทำให้เสียเวลาช่วงบ่าย
ขั้นตอนที่ 0: ระบุไดรเวอร์และต้นทาง
ถาม minikube ว่าโปรไฟล์ใดทำงานอยู่และทำงานอย่างไร ไดรเวอร์คอนเทนเนอร์วางโหนดไว้ในคอนเทนเนอร์บนเครื่องของคุณ ไดรเวอร์ VM วางโหนดไว้ในเครื่องเสมือน และไดรเวอร์ระยะไกลวางโหนดไว้ที่อื่นโดยสิ้นเชิง
minikube profile list
minikube status
kubectl config current-contextจากนั้นเขียนว่าคำขอมาจากไหน คำตอบกำหนดว่า resolver ของใครและเส้นทางใดสำคัญ และไม่ใช่ของโฮสต์เสมอไป โปรไฟล์สองอันบนแล็ปท็อปเครื่องเดียวกันอาจทำงานต่างกันอย่างสิ้นเชิงสำหรับ 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 |
ขั้นตอนที่ 1: ทดสอบ endpoint เดียวกันสามครั้ง
ใช้ endpoint ที่ไม่เป็นอันตรายหนึ่งรายการ และรักษาชื่อโฮสต์ พอร์ต และตระกูลที่อยู่ให้เหมือนกันในการทดสอบทั้งสามครั้ง หากเปลี่ยนสิ่งใดระหว่างการรัน ผลลัพธ์จะเทียบกันไม่ได้
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/healthการดึง image สำเร็จโดยโหนดไม่ได้พิสูจน์อะไรเกี่ยวกับการแปลงชื่อสำหรับโฮสต์ส่วนตัว คำขอสาธารณะที่สำเร็จพิสูจน์ได้น้อยกว่านั้นอีก แยกผลลัพธ์ตามบริบทไว้ เพราะรูปแบบในสามแถวคือการวินิจฉัย และความล้มเหลวเพียงครั้งเดียวคือเบาะแส
หากแถวของโฮสต์ล้มเหลวด้วย ให้หยุด คุณมีปัญหาเครือข่ายบนโฮสต์ และคลัสเตอร์เป็นเพียงสิ่งเบี่ยงเบนความสนใจ
ขั้นตอนที่ 2: รักษาเส้นทางของโฮสต์ไปยังคลัสเตอร์
มีทิศทางที่สองที่ผู้คนลืม: โฮสต์ต้องเข้าถึง API และบริการของคลัสเตอร์เองต่อไป ไคลเอนต์ VPN อาจติดตั้งเส้นทางที่แข่งขันกับคำนำหน้าที่ minikube ใช้สำหรับเครือข่ายโหนด ช่วงบริการ และช่วง Pod ของตน
เมื่อเกิดเหตุการณ์นั้น อาการจะสับสน เพราะอุโมงค์ทำงานได้ แต่ kubectl หยุดตอบสนองหรือ NodePort ปฏิเสธการเชื่อมต่อ มันดูเหมือนความผิดพลาดของคลัสเตอร์ แต่จริง ๆ แล้วเป็นความผิดพลาดของการกำหนดเส้นทางบนแล็ปท็อป
ตรวจสอบตารางเส้นทางของโฮสต์เทียบกับช่วงของ minikube ก่อนจะโทษอุโมงค์ในเรื่องอื่น การทับซ้อนมักปรากฏเป็นเส้นทางที่เจาะจงกว่าซึ่งชี้ไปที่อินเทอร์เฟซอุโมงค์สำหรับคำนำหน้าที่คลัสเตอร์ถือว่าเป็นของตน
ขั้นตอนที่ 3: แก้การทับซ้อนโดยไม่ปิด VPN
คู่มือ VPN และ proxy ของ minikube เองกล่าวถึงความขัดแย้งเหล่านี้ และถือว่าช่วงตัวอย่างเป็นสิ่งที่ต้องตรวจสอบ ไม่ใช่รายการสากล อ่านคู่กับโปรไฟล์ที่คุณมีจริง
เมื่อมีการทับซ้อนจริง คำตอบที่ได้รับการสนับสนุนคือช่วงที่ไม่ทับซ้อนหรือนโยบายการเข้าถึงภายในที่ตั้งใจและได้รับอนุมัติจากเจ้าของ VPN การเปลี่ยนช่วงบริการไม่เหมือนกับการเปลี่ยนช่วง Pod และทั้งสองอย่างก็ไม่เหมือนกับการเปลี่ยนเครือข่ายโหนด
การปิดอุโมงค์องค์กรเพื่อให้คลัสเตอร์ภายในทำงานได้ไม่ใช่ทางลัด แต่เป็นการตัดสินใจเชิงนโยบายที่คนอื่นต้องทำ ไปคุยกับคนนั้นแทนที่จะทำเงียบ ๆ หลังจากทุกคนกลับบ้านแล้ว หากคุณทำไปแล้ว ให้คืนก่อนที่จะถาม
ขั้นตอนที่ 4: แยก proxy, DNS และรูปแบบความล้มเหลวสี่แบบ
หากต้องใช้ proxy ให้ระบุว่าบริบทใดต้องการ การตั้งเบราว์เซอร์บนโฮสต์ไม่ได้กำหนดค่ากระบวนการภายในโหนด และ Pod ต้องการตัวแปรสภาพแวดล้อมหรือการกำหนดค่า proxy ระดับคลัสเตอร์
จากนั้นจัดประเภทความล้มเหลวแทนการบรรยาย ชื่อที่แปลงไม่ได้คือ DNS ชื่อที่แปลงได้แต่ปฏิเสธการเชื่อมต่อคือการกำหนดเส้นทางหรือ listener การเชื่อมต่อที่สร้างได้แต่ล้มเหลวที่ตัวตนคือ TLS การเชื่อมต่อที่สำเร็จพร้อมเนื้อหาข้อผิดพลาดคือแอปพลิเคชัน
แต่ละอย่างในสี่อย่างนี้ต้องแก้ต่างกัน และมีเพียงหนึ่งเดียวที่เกี่ยวกับ VPN เขียนว่าคุณสังเกตเห็นอะไรในแต่ละบริบท และคนถัดไปจะได้รับหลักฐานแทนเรื่องเล่า