โหนด GKE แบบส่วนตัวไม่ได้กำหนดว่า kubectl ใช้ API ใด

โหนดเป็นแบบส่วนตัว VPN เข้าถึงได้ แต่ kubectl ก็ยังคุยกับคลัสเตอร์ไม่ได้ ข้อเท็จจริงสองข้อนี้ไม่เกี่ยวข้องกัน ที่อยู่ที่ kubectl ใช้มาจาก URL ของเซิร์ฟเวอร์ที่เก็บไว้ใน kubeconfig ตอนที่ดึงข้อมูลรับรอง และไม่มีเส้นทางใดที่คุณเพิ่มเข้าไปจะเปลี่ยนมัน ในขณะเดียวกัน โหนดก็ไม่ใช่สิ่งที่ kubectl กำลังพยายามเข้าถึงตั้งแต่แรก

ห้าขั้นตอนตรวจสอบ เริ่มจากค่าที่สำคัญเพียงค่าเดียว

ตรวจสอบ 1: อ่าน URL ของเซิร์ฟเวอร์ใน kubeconfig

พิมพ์ปลายทางโดยไม่เปิดเผยข้อมูลรับรอง: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}" สตริงเดียวนี้บอกคุณว่าไคลเอนต์ชี้ไปที่ที่อยู่ IP ชื่อ DNS หรือที่อยู่ภายนอกที่คุณไม่ได้ตั้งใจ ทุกอย่างที่เหลือในการตรวจสอบนี้สืบเนื่องมาจากมัน

หาก URL ไม่ใช่ปลายทางที่คุณคิดว่าได้กำหนดค่าไว้ ส่วนที่เหลือของการวินิจฉัยก็เป็นเพียงการเบี่ยงเบนความสนใจ

ตรวจสอบ 2: จับคู่ URL กับชนิดของปลายทาง

GKE ปัจจุบันรองรับการเข้าถึงชุดควบคุมทั้งแบบอิง IP และแบบอิง DNS และข้อมูลรับรองที่คุณดึงมาจะเลือกอย่างใดอย่างหนึ่ง gcloud container clusters get-credentials NAME --location REGION --internal-ip เขียนปลายทาง IP ภายใน ขณะที่ --dns-endpoint เลือกการเข้าถึงแบบอิง DNS ไม่มีแฟล็กใดจัดหาเส้นทางเครือข่าย ซึ่งทำให้คนที่คาดว่าการดึงข้อมูลจะแก้การเชื่อมต่อได้ต้องประหลาดใจ ทำการดึงซ้ำอย่างตั้งใจแล้วอ่าน URL อีกครั้งหลังจากนั้น

การเปลี่ยนแฟล็กโดยไม่อ่าน URL ซ้ำคือวิธีที่แล็ปท็อปลงเอยด้วยข้อมูลรับรองของสองคลัสเตอร์และข้อผิดพลาดที่น่าสับสนหนึ่งข้อ

รายการเครือข่ายที่ได้รับอนุญาตกำหนดว่าใครเข้าถึงปลายทางภายนอกได้ และไม่ใช้กับปลายทางภายใน การขยายเพื่อทดสอบเส้นทางส่วนตัวเปลี่ยนการเปิดเผยของคุณ ไม่ใช่การวินิจฉัยของคุณ

ตรวจสอบ 3: พิสูจน์เส้นทางไปยังปลายทางนั้น

หาก URL เป็น IP ภายใน ให้ตรวจสอบเส้นทางจากเครือข่ายที่ไคลเอนต์อยู่จริง ช่วงต้นทางที่อนุญาต และการตั้งค่าการเข้าถึงระดับภูมิภาคหรือระดับโลกของคลัสเตอร์ ช่วงของชุดควบคุมและซับเน็ตของโหนดไม่ใช่ปลายทางเดียวกัน ดังนั้นเส้นทางที่ใช้ได้ไปยังโหนดจึงไม่ได้พิสูจน์อะไรเกี่ยวกับปลายทาง สำหรับการเข้าถึงแบบอิง DNS เส้นทางคือการเชื่อมต่อ Google API พร้อมการจัดวาง Private Google Access ที่มีเอกสารกำกับ ไม่ใช่เส้นทางไปยังซับเน็ตของผู้ปฏิบัติงาน ทดสอบปลายทางด้วยการเชื่อมต่อ TCP ธรรมดาก่อนตำหนิ kubectl

การหมดเวลาเป็นปัญหาเส้นทาง 403 เป็นปัญหานโยบาย ทั้งสองไม่มีวิธีแก้ร่วมกัน

ตรวจสอบ 4: แยกบันทึกและ exec ออกจากการเรียก API

หากคำขอ API ทั่วไปสำเร็จและ kubectl logs หรือ kubectl exec ล้มเหลว คุณผ่านการเลือกปลายทางไปแล้ว การดำเนินการเหล่านั้นต้องใช้สิทธิ์ Kubernetes ที่สอดคล้องและขึ้นกับการสื่อสารจากชุดควบคุมไปยังโหนด และความล้มเหลวอาจเป็นการตอบกลับ Forbidden แทนการหมดเวลา การเข้าถึง SSH ไปยังโหนดทดสอบบริการอื่นโดยสิ้นเชิงและไม่ได้สร้างสิ่งเหล่านั้น

อ่านคลาสของข้อผิดพลาดก่อนเปิดตั๋ว VPN อีกครั้ง เพราะสองคลาสอาศัยอยู่คนละที่

ตรวจสอบ 5: เก็บข้อสังเกตสามข้อไว้ให้คนถัดไป

บันทึก URL ของ API ที่เลือก ไม่ว่าคำขอ API ที่ได้รับอนุญาตหนึ่งคำขอจะทำงานหรือไม่ และการดำเนินการใดในภายหลังที่ล้มเหลวอย่างแน่นอน พร้อมข้อความข้อผิดพลาด สามบรรทัดนั้นแยกการเลือกปลายทางออกจากการเข้าถึงโหนด และป้องกันไม่ให้เส้นทาง VPN ที่ดีสมบูรณ์ถูกตำหนิสำหรับคำขอที่มันไม่เคยพาไป

วิศวกรคนถัดไปจะถามว่าอุโมงค์เสียหรือไม่ บันทึกของคุณควรตอบสิ่งนั้นไว้แล้ว