主页 / server / 问题 / 1082601
Accepted
Ivan Buttinoni
Asked: 2021-11-05 03:17:57 +0800 CST

dist-upgrade 后负载均衡器标记“unhealthy”新组成员实例（ubuntu）

  • 772

我的GCloud 上的一个实例组后面有一些虚拟机（用作 Web 服务器） 。

像往常一样，我更新了（apt dist-upgrade）我的“vm-source-image”，创建了一个新模板并将其添加到我的组中。

使用此模板的新成员从未收到来自负载均衡器的任何实际工作请求，它已启动并运行但未使用。

临时补丁

我只通过以下方式进行部分更新（安全更新）：

sudo unattended-upgrade -d

这里是造成问题的剩余软件包的列表：

# apt list --upgradable

cloud-init/bionic-updates 21.3-1-g6803368d-0ubuntu1~18.04.4 all [upgradable from: 21.2-3-g899bfaa9-0ubuntu2~18.04.1]
dnsmasq-base/bionic-updates 2.79-1ubuntu0.5 amd64 [upgradable from: 2.79-1ubuntu0.4]
gce-compute-image-packages/bionic-updates 20210629.00-0ubuntu1~18.04.0 all [upgradable from: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine/bionic-updates 20210629.00-0ubuntu1~18.04.0 all [upgradable from: 20201222.00-0ubuntu2~18.04.0]
google-compute-engine-oslogin/bionic-updates 20210728.00-0ubuntu1~18.04.0 amd64 [upgradable from: 20210429.00-0ubuntu1~18.04.0]
google-guest-agent/bionic-updates 20210629.00-0ubuntu1~18.04.1 amd64 [upgradable from: 20210414.00-0ubuntu1~18.04.0]
libgnutls30/bionic-updates 3.5.18-1ubuntu1.5 amd64 [upgradable from: 3.5.18-1ubuntu1.4]
libnetplan0/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [upgradable from: 0.99-0ubuntu3~18.04.4]
libpcre2-8-0/bionic 10.39-1+ubuntu18.04.1+deb.sury.org+1 amd64 [upgradable from: 10.36-2+ubuntu18.04.1+deb.sury.org+2]
netplan.io/bionic-updates 0.99-0ubuntu3~18.04.5 amd64 [upgradable from: 0.99-0ubuntu3~18.04.4]
nplan/bionic-updates 0.99-0ubuntu3~18.04.5 all [upgradable from: 0.99-0ubuntu3~18.04.4]
snapd/bionic-updates 2.51.1+18.04 amd64 [upgradable from: 2.49.2+18.04]
ubuntu-advantage-tools/bionic-updates 27.3~18.04.1 amd64 [upgradable from: 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/Nov/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/Nov/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/Nov/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/Nov/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/Nov/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/Nov/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/Nov/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/Nov/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/Nov/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/Nov/2021:10:31:02 +0000] 10.0.0.54 "GET /?id=HTTPHC2 HTTP/1.1" 200 612 "-" "GoogleHC/1.0"

差异表明HTTPHC1的日志丢失。

所以新的新不响应负载均衡器（HTTPHC1）的健康检查并且不接收请求，这就是问题所在。

其他故障 新机也无法通过浏览器-window-SSH访问 在此处输入图像描述

添加 tcpdump

HTTPHC1健康检查员和失业成员之间：

# tcpdump -n host 35.191.1.151
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
11:30:35.109469 IP 35.191.1.151.61838 > 10.0.0.116.80: Flags [S], win 65535, options [mss 1420,sackOK,TS  ecr 0,nop,wscale 8], length 0
11:30:36.119470 IP 35.191.1.151.61838 > 10.0.0.116.80: Flags [S], win 65535, options [mss 1420,sackOK,TS  ecr 0,nop,wscale 8], length 0
11:30:38.167436 IP 35.191.1.151.61838 > 10.0.0.116.80: Flags [S], win 65535, options [mss 1420,sackOK,TS  ecr 0,nop,wscale 8], length 0
11:30:40.110784 IP 35.191.1.151.59900 > 10.0.0.116.80: Flags [S], win 65535, options [mss 1420,sackOK,TS  ecr 0,nop,wscale 8], length 0
11:30:41.111176 IP 35.191.1.151.59900 > 10.0.0.116.80: Flags [S], win 65535, options [mss 1420,sackOK,TS ecr 0,nop,wscale 8], length 0
11:30:43.159164 IP 35.191.1.151.59900 > 10.0.0.116.80: Flags [S], win 65535, options [mss 1420,sackOK,TS ecr 0,nop,wscale 8], length 0
11:30:45.112162 IP 35.191.1.151.36064 > 10.0.0.116.80: Flags [S], win 65535, options [mss 1420,sackOK,TS  ecr 0,nop,wscale 8], length 0

请注意，目标是负载平衡器前端 IP：10.0.0.116，当然它们只是同步数据包。

HTTPHC2健康检查器和失业成员之间：

# tcpdump -n host 35.191.1.148
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
10:46:12.475724 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [S], win 65535, options [mss 1420,sackOK,TS ecr 0,nop,wscale 8], length 0
10:46:12.475788 IP 10.0.0.54.80 > 35.191.1.148.64638: Flags [S.], win 64768, options [mss 1420,sackOK,TS,nop,wscale 7], length 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [.], ack 1, win 256, options [nop,nop,TS], length 0
10:46:12.476239 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [P.], seq 1:117, ack 1, win 256, options [nop,nop,TS], length 116: HTTP: GET /?id=HTTPHC2 HTTP/1.1
10:46:12.476301 IP 10.0.0.54.80 > 35.191.1.148.64638: Flags [.], ack 117, win 506, options [nop,nop,TS], length 0
10:46:12.476546 IP 10.0.0.54.80 > 35.191.1.148.64638: Flags [P.], seq 1:867, ack 117, win 506, options [nop,nop,TS], length 866: HTTP: HTTP/1.1 200 OK
10:46:12.476659 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [.], ack 867, win 267, options [nop,nop,TS], length 0
10:46:12.476679 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [F.], seq 117, ack 867, win 267, options [nop,nop,TS], length 0
10:46:12.476707 IP 10.0.0.54.80 > 35.191.1.148.64638: Flags [F.], seq 867, ack 118, win 506, options [nop,nop,TS], length 0
10:46:12.476879 IP 35.191.1.148.64638 > 10.0.0.54.80: Flags [.], ack 868, win 267, options [nop,nop,TS], length 0

这里一切都很好。

添加 2021-11-16

经过一番研究，我发现本地表中缺少 IP 别名，毫不奇怪，这是前端负载均衡器 IP 地址，在tcpdump!

这里的工作机器：

# ip route show dev ens4 table local
local 10.0.0.48 proto kernel scope host src 10.0.0.48 
local 10.0.0.116 proto 66 scope host 
# uname -r
5.4.0-1056-gcp

这里是完全更新的机器：

# ip route show dev ens4 table local
local 10.0.0.54 proto kernel scope host src 10.0.0.54
# uname -r
5.4.0-1057-gcp

添加 2021-11-20

现在它成为一个已知问题：[Cloud Networking] 潜在服务问题：正在调查

Google Cloud 全局 TCP 代理负载平衡器可能无法通过使用 34.111.0.0/17 范围内的 IP 配置的转发规则来提供流量。IP 范围的永久修复正在进行中

load-balancing apt google-cloud-platform gcloud

2 个回答

  1. Best Answer

    经过测试，cloud-init是根本原因。

    根据这个注释，disable_network_activation: true应该设置避免与 google-guest-agent服务冲突。

    解决方案是在 config.xml 中添加设置cloud-init。

    cat > /etc/cloud/cloud.cfg.d/99-disable-network-activation.cfg <<EOF
# Disable network activation to prevent \`cloud-init\` from making network
# changes that conflict with \`google-guest-agent\`.
# See: https://github.com/canonical/cloud-init/pull/1048

disable_network_activation: true
EOF

    该文件存在于官方镜像ubuntu-1804-bionic-v20211103中。

    添加此文件后，google-guest-agent运行正常。

    • 3

  2. 我有一台运行 Ubuntu 18.04.5 的机器，运行后遇到了同样的问题apt dist-upgrade，也升级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没有自动运行。

    • 0

相关问题