โหลดบาลานเซอร์ทำเครื่องหมายอินสแตนซ์สมาชิกกลุ่มใหม่ "ไม่ปลอดภัย" (อูบุนตู) หลังจากอัปเกรด dist

ฉันมี VM บางตัว (ทำงานเป็นเว็บเซิร์ฟเวอร์) ที่อยู่เบื้องหลัง กลุ่มอินสแตนซ์ บน GCloud ของฉัน

ฉันได้อัปเดตตามปกติ (ฉลาด dist-อัพเกรด) "vm-source-image" ของฉันสร้างขึ้นใหม่ แม่แบบ และเพิ่มลงในกลุ่มของฉัน

สมาชิกใหม่ที่ใช้เทมเพลตนี้ไม่เคยได้รับคำขอการทำงานจริงใดๆ จากโหลดบาลานซ์และ มันขึ้นและทำงาน แต่ ว่างงาน.

แพทช์ชั่วคราว

ฉันทำการอัปเดตเพียงบางส่วน (ไฟล์ พวกความปลอดภัย) โดย:

sudo อัปเกรดแบบอัตโนมัติ -d

นี่คือรายการแพ็คเกจที่เหลือที่สร้างปัญหา:

# รายการ apt --upgradable

cloud-init/bionic-updates 21.3-1-g6803368d-0ubuntu1~18.04.4 ทั้งหมด [อัพเกรดได้จาก: 21.2-3-g899bfaa9-0ubuntu2~18.04.1]
dnsmasq-base/bionic-updates 2.79-1ubuntu0.5 amd64 [อัพเกรดได้จาก: 2.79-1ubuntu0.4]
gce-compute-image-packages/bionic-updates 20210629.00-0ubuntu1~18.04.0 ทั้งหมด [อัพเกรดได้จาก: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine/bionic-updates 20210629.00-0ubuntu1~18.04.0 ทั้งหมด [อัปเกรดได้จาก: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine-oslogin/bionic-updates 20210728.00-0ubuntu1~18.04.0 amd64 [อัปเกรดได้จาก: 20210429.00-0ubuntu1~18.04.0]
google-guest-agent/bionic-updates 20210629.00-0ubuntu1~18.04.1 amd64 [อัปเกรดได้จาก: 20210414.00-0ubuntu1~18.04.0]
libgnutls30/bionic-updates 3.5.18-1ubuntu1.5 amd64 [อัพเกรดได้จาก: 3.5.18-1ubuntu1.4]
libnetplan0/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [อัพเกรดได้จาก: 0.99-0ubuntu3~18.04.4]
libpcre2-8-0/bionic 10.39-1+ubuntu18.04.1+deb.sury.org+1 amd64 [อัปเกรดได้จาก: 10.36-2+ubuntu18.04.1+deb.sury.org+2]
netplan.io/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [อัพเกรดได้จาก: 0.99-0ubuntu3~18.04.4]
nplan/bionic-updates 0.99-0ubuntu3~18.04.5 ทั้งหมด [อัพเกรดได้จาก: 0.99-0ubuntu3~18.04.4]
snapd/bionic-updates 2.51.1+18.04 amd64 [อัพเกรดได้จาก: 2.49.2+18.04]
ubuntu-advantage-tools/bionic-updates 27.3~18.04.1 amd64 [อัพเกรดได้จาก: 27.2.2~18.04.1]

ทางออกที่แท้จริง

เนื่องจากฉันไม่มีแพ็คเกจ "กำหนดเอง" ในเครื่องและต้นตอของปัญหานี้มาจากการอัปเดตระบบ ฉันไม่เห็นวิธีแก้ไขนอกจากชี้ให้เห็นปัญหาในโพสต์นี้

แน่นอนว่าฉันเฝ้าติดตามการอัปเดตใหม่โดยหวังว่าเวอร์ชันใหม่ของแพ็คเกจนี้จะแก้ปัญหาได้ แต่เป็นไปได้ไหมที่ไม่มีตัวเลือกที่ดีกว่านี้

ข้อมูลเพิ่มเติม

• กลุ่มนี้เป็นแบ็กเอนด์ของ "โหลดบาลานเซอร์ TCP ภายใน"
• ที่อยู่ IP ส่วนหน้าของตัวจัดสรรภาระงานคือ 10.0.0.116
• ที่อยู่ IP ของสมาชิกเก่า (และทำงานอยู่) คือ 10.0.0.48 (ดูบันทึกได้)
• ที่อยู่ IP ของสมาชิกใหม่ (และว่างงาน) คือ 10.0.0.54 (ดูบันทึกได้)
• ตัวจัดสรรภาระงานมีการตรวจสอบสถานะ HTTP อย่างง่ายที่เรียกว่า HTTPHC1.
• กลุ่มอินสแตนซ์มีการตรวจสอบสุขภาพ HTTP อย่างง่ายอีกชื่อหนึ่ง HTTPHC2.

เปรียบเทียบบันทึกการเข้าถึงของสมาชิกเก่า (และใช้งานได้) กับสมาชิกใหม่:

บันทึกของสมาชิก VM เก่า

35.191.1.148 "/" - - - [04/พ.ย./2021:10:34:59 +0000] 10.0.0.48 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.144 "/" ​​- - - [04/พ.ย./2021:10:35:00 +0000] 10.0.0.48 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.154 "/" ​​- - - [04/พ.ย./2021:10:35:00 +0000] 10.0.0.48 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.147 "/" - - - [04/พ.ย./2021:10:35:01 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.145 "/" - - - [04/พ.ย./2021:10:35:01 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.151 "/" - - - [04/พ.ย./2021:10:35:02 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.153 "/" - - - [04/พ.ย./2021:10:35:02 +0000] 10.0.0.48 "GET /?id=HTTPHC1 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"

บันทึกของสมาชิก VM ใหม่

35.191.1.152 "/" - - - [04/พ.ย./2021:10:31:01 +0000] 10.0.0.54 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.154 "/" ​​- - - [04/พ.ย./2021:10:31:02 +0000] 10.0.0.54 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"
35.191.1.148 "/" - - - [04/พ.ย./2021:10:31:02 +0000] 10.0.0.54 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"

ความแตกต่างแสดงให้เห็นถึงการหายไปของบันทึกของ HTTPHC1.

ดังนั้น new ใหม่ไม่ตอบการตรวจสอบความสมบูรณ์ของโหลดบาลานเซอร์ (HTTPHC1) และไม่ได้รับคำขอและนั่นคือปัญหา

ความผิดปกติอื่น ๆ เครื่องใหม่ไม่สามารถเข้าถึงได้โดย browser-window-SSH

เพิ่ม tcpdump

ระหว่าง HTTPHC1 ผู้ตรวจสุขภาพและสมาชิกผู้ว่างงาน:

# tcpdump -n โฮสต์ 35.191.1.151
tcpdump: เอาต์พุต verbose ถูกระงับ ใช้ -v หรือ -vv สำหรับการถอดรหัสโปรโตคอลแบบเต็ม
กำลังฟัง ens4, ประเภทลิงก์ EN10MB (Ethernet), ขนาดการบันทึก 262144 ไบต์
11:30:35.109469 IP 35.191.1.151.61838 > 10.0.0.116.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0
11:30:36.119470 IP 35.191.1.151.61838 > 10.0.0.116.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0
11:30:38.167436 IP 35.191.1.151.61838 > 10.0.0.116.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0
11:30:40.110784 IP 35.191.1.151.59900 > 10.0.0.116.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0
11:30:41.111176 IP 35.191.1.151.59900 > 10.0.0.116.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0
11:30:43.159164 IP 35.191.1.151.59900 > 10.0.0.116.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0
11:30:45.112162 IP 35.191.1.151.36064 > 10.0.0.116.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0

โปรดทราบว่า ปลายทางคือ IP ส่วนหน้าของตัวโหลดบาลานซ์: 10.0.0.116 และแน่นอนว่าเป็นแพ็กเก็ต Sync เท่านั้น

ระหว่าง HTTPHC2 ผู้ตรวจสุขภาพและสมาชิกผู้ว่างงาน:

# tcpdump -n โฮสต์ 35.191.1.148
tcpdump: เอาต์พุต verbose ถูกระงับ ใช้ -v หรือ -vv สำหรับการถอดรหัสโปรโตคอลแบบเต็ม
กำลังฟัง ens4, ประเภทลิงก์ EN10MB (Ethernet), ขนาดการบันทึก 262144 ไบต์
10:46:12.475724 IP 35.191.1.148.64638 > 10.0.0.54.80: ค่าสถานะ [S], ชนะ 65535, ตัวเลือก [mss 1420,sackOK,TS ecr 0,nop,wscale 8], ความยาว 0
10:46:12.475788 IP 10.0.0.54.80 > 35.191.1.148.64638: ค่าสถานะ [S.], ชนะ 64768, ตัวเลือก [mss 1420,sackOK,TS,nop,wscale 7], ความยาว 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: ค่าสถานะ [.], ack 1, ชนะ 256, ตัวเลือก [nop,nop,TS], ความยาว 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: ค่าสถานะ [P.], seq 1:117, ack 1, ชนะ 256, ตัวเลือก [nop,nop,TS], ความยาว 116: HTTP: GET /?id=HTTPHC2 HTTP/1.1.1
10:46:12.476301 IP 10.0.0.54.80 > 35.191.1.148.64638: ค่าสถานะ [.], ack 117, ชนะ 506, ตัวเลือก [nop,nop,TS], ความยาว 0
10:46:12.476546 IP 10.0.0.54.80 > 35.191.1.148.64638: ค่าสถานะ [P.], seq 1:867, ack 117, win 506, ตัวเลือก [nop,nop,TS], ความยาว 866: HTTP: HTTP /1.1 200 ตกลง
10:46:12.476659 IP 35.191.1.148.64638 > 10.0.0.54.80: ค่าสถานะ [.], ack 867, ชนะ 267, ตัวเลือก [nop,nop,TS], ความยาว 0
10:46:12.476679 IP 35.191.1.148.64638 > 10.0.0.54.80: แฟล็ก [F.], seq 117, ack 867, win 267, options [nop,nop,TS], ความยาว 0
10:46:12.476707 IP 10.0.0.54.80 > 35.191.1.148.64638: แฟล็ก [F.], seq 867, ack 118, win 506, options [nop,nop,TS], ความยาว 0
10:46:12.476879 IP 35.191.1.148.64638 > 10.0.0.54.80: ค่าสถานะ [.], ack 868, ชนะ 267, ตัวเลือก [nop,nop,TS], ความยาว 0

ที่นี่ทุกอย่างเรียบร้อยดี

เพิ่ม 2021-11-16

หลังจากการค้นคว้าบางอย่าง ฉันพบ IP alias ที่ขาดหายไปใน ท้องถิ่น ตาราง ไม่แปลกใจเลยที่จะเห็นว่าเป็นที่อยู่ IP ของ frontend-load-balancer ซึ่งมองเห็นเป็นโฮสต์ DST ในไฟล์ tcpdump!

นี่คือเครื่องทำงาน:

# เส้นทาง ip แสดง dev ens4 ตารางในเครื่อง
ท้องถิ่น 10.0.0.48 โปรโตเคอร์เนลขอบเขตโฮสต์ src 10.0.0.48 
local 10.0.0.116 proto 66 ขอบเขตโฮสต์ 
# uname -r
5.4.0-1056-gcp

และนี่คือเครื่องที่อัปเดตอย่างสมบูรณ์:

# เส้นทาง ip แสดง dev ens4 ตารางในเครื่อง
ท้องถิ่น 10.0.0.54 โปรโตเคอร์เนลขอบเขตโฮสต์ src 10.0.0.54
# uname -r
5.4.0-1057-gcp

เพิ่ม 2021-11-20

ตอนนี้กลายเป็นปัญหาที่ทราบแล้ว: [ระบบเครือข่ายคลาวด์] ปัญหาบริการที่อาจเกิดขึ้น: กำลังตรวจสอบ

Google Cloud Global TCP Proxy Load Balancer อาจไม่สามารถให้บริการได้ ปริมาณการใช้กฎการส่งต่อที่กำหนดค่าด้วย IP ใน 34.111.0.0/17 พิสัย. การแก้ไขถาวรสำหรับช่วง IP อยู่ระหว่างดำเนินการ

ฉันมีเครื่องที่ใช้ Ubuntu 18.04.5 พบปัญหาเดียวกันหลังจากใช้งาน ฉลาด dist-อัพเกรดนอกจากนี้ยังอัพเกรด google-guest-agent 20210629.00-0ubuntu1~18.04.1 (อัพเกรดได้จาก: 20210414.00-0ubuntu1~18.04.0).

การหาสิ่งนั้น google-guest-agent ไม่ทำงานหลังจากอัพเกรด เมื่อฉันดำเนินการ /usr/bin/google_guest_agent ด้วยตนเอง ปัญหาจะได้รับการแก้ไข

ยังไม่รู้ว่าทำไม google-guest-agent ไม่ได้ทำงานโดยอัตโนมัติ