Docker Swarm ผ่าน VPN: งานรันอยู่ แต่การเรียกใช้บริการล้มเหลว

ผู้จัดการสามคนและผู้ปฏิบัติงานห้าคนในสองไซต์ เชื่อมต่อด้วยอุโมงค์ และ docker service ls แสดงงานที่รันอยู่ทั้งสองฝั่ง ขณะที่การเรียกใช้ระหว่างบริการหมดเวลา ไม่มีอะไรในบันทึกของ Swarm ดูผิดปกติ การรวมกันนี้คือลายเซ็นของปัญหาในระนาบข้อมูล: ระนาบควบคุมพบโหนดแล้ว และเฟรมที่ห่อหุ้มไว้ก็ไม่เคยเดินทางไปถึง

mesh ต้องมีก่อน overlay

overlay ของ Swarm ดันเฟรมที่ห่อหุ้มไว้ระหว่างที่อยู่ของโหนดโดยตรง ซึ่งหมายความว่าแต่ละโหนดต้องมีที่อยู่ที่ทุกโหนดอื่นเข้าถึงได้โดยไม่ต้องแปล บนอินเทอร์เฟซที่อุโมงค์ให้มา อุโมงค์ที่พาเฉพาะไคลเอนต์ไปยังพอร์ตที่เผยแพร่ไม่เพียงพอ ชั้นล่างต้องกำหนดเส้นทางจากโหนดถึงโหนดทั้งสองทิศทาง

ทดสอบสิ่งนี้ก่อนแตะ Swarm จากแต่ละโหนด ตรวจสอบเส้นทางไปยังที่อยู่ tunnel ของเพื่อน ping แล้วทดสอบพอร์ตควบคุม ถ้า ping ทำงานแต่พอร์ตไม่ แปลว่าอุโมงค์ปกติดีและมีฟิลเตอร์ขวางอยู่

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

ถ้าเส้นทางชี้ไปที่อินเทอร์เฟซจริงแทน tun0 หรือ wg0 overlay จะห่อหุ้มไปยังที่อยู่ที่ไซต์ไกลเอื้อมไม่ถึง และอาการจะดูเหมือนแพ็กเก็ตหาย

ตรวจสอบว่าแต่ละโหนดประกาศที่อยู่ใด

เดมอนประกาศที่อยู่หนึ่งรายการ และเพื่อนใช้ที่อยู่นั้นสำหรับระนาบข้อมูล บนโฮสต์ที่มีหลายเครือข่าย เป็นเรื่องง่ายที่จะประกาศที่อยู่ LAN หรือที่อยู่สาธารณะขณะที่อุโมงค์บรรทุกอย่างอื่น ตรวจสอบแทนการสันนิษฐาน และปักหมุดตอนเข้าร่วมด้วย --advertise-addr เมื่อค่าเริ่มต้นผิด โหนดที่ประกาศที่อยู่ซึ่งมีเพียงมันเองที่เข้าถึงได้ก็ยังเข้าร่วม swarm และความล้มเหลวจะปรากฏภายหลังเป็นบริการที่คุยข้ามไซต์ไม่ได้

การเปลี่ยนที่อยู่ที่ประกาศภายหลังไม่ใช่การแก้ไขคอนฟิก เพราะโหนดต้องออกและเข้าร่วมใหม่

บันทึกที่อยู่ที่ประกาศของแต่ละโหนดไว้ในโน้ตของคุณ เพราะมันอธิบายความล้มเหลวแบบอสมมาตรส่วนใหญ่

Masquerade คือผู้ต้องสงสัยตามปกติ

เมื่อมีเกตเวย์คั่นระหว่างโหนดกับอุโมงค์ ข้อผิดพลาดที่พบบ่อยคือใช้ masquerade กับทุกอย่างที่ออกจากอินเทอร์เฟซจริง นั่นเขียนที่อยู่ภายในของ overlay ใหม่ด้วย ทุกเพื่อนจึงดูเหมือนมาจากเกตเวย์ และเพื่อน VXLAN ก็เลิกจดจำกัน ผลลัพธ์คือทราฟฟิกที่ห่อหุ้มหายไปหรือไปทางเดียว ขณะที่ ping ธรรมดายังทำงาน

กำหนดเส้นทางคำนำหน้าของ overlay ผ่านเกตเวย์และปล่อยไว้ไม่แปล ถ้าต้องการแปลจริง ๆ สำหรับคำนำหน้าอื่น ให้จำกัดไว้ที่นั่นและห้ามใช้กับช่วงที่ overlay ใช้เด็ดขาด

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

ตรวจสอบลำดับของกฎและเนื้อหาด้วย เพราะ MASQUERADE แบบกว้างที่อยู่ก่อนในเชนชนะข้อยกเว้นแคบที่อยู่ภายหลัง

VXLAN ต้องมีพื้นที่ในแพ็กเก็ต

VXLAN เพิ่ม 50 ไบต์ให้เฟรมที่บรรทุก ชั้นล่างขนาด 1500 ไบต์ที่บรรทุกเฟรมภายในขนาด 1500 ไบต์จะสร้างแพ็กเก็ตที่ห่อหุ้มซึ่งไม่มีเส้นทางใดส่งถึง และความล้มเหลวจะดูเหมือนการค้นพบบริการเป็นช่วง ๆ ไม่ใช่ปัญหาเรื่องขนาด ลด MTU ของอุโมงค์ทั้งสองด้าน หรือตั้ง MTU ของ overlay ให้ไดรเวอร์ประกาศเพย์โหลดที่พอดี

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

เครือข่าย ingress ถูกสร้างอัตโนมัติ ดังนั้นการเปลี่ยนจึงหมายถึงการลบและสร้างใหม่ ไม่ใช่แก้ไขในที่

ถ้าแก้เพียงด้านเดียวของอุโมงค์ MTU ที่เล็กกว่าก็ยังเป็นตัวที่สำคัญ

ดูระนาบข้อมูล ไม่ใช่บันทึก

ดักพอร์ต VXLAN ทั้งสองด้าน เฟรมที่ออกจากด้านหนึ่งและมาถึงอีกด้านหมายถึงชั้นล่างปกติดีและปัญหาอยู่ใน overlay เฟรมที่ออกไปแล้วไม่เคยมาถึงหมายถึงเส้นทางหรือฟิลเตอร์ เฟรมที่ไม่เคยออกเลยหมายถึงที่อยู่ต้นทางผิด

ความล้มเหลวในการค้นพบบริการที่หายไปหลังจากไม่กี่วินาทีมักชี้ไปที่งบประมาณแพ็กเก็ตหรือเส้นทางที่ไม่เสถียร ไม่ใช่ควอรัมของ raft

เก็บแคปเจอร์จากช่วงที่ทำงานปกติไว้ เพราะการเทียบกับอันที่เสียเร็วกว่าการอ่านคอนฟิกซ้ำ