- 1.故障分析 | BAD HANDSHAKE，升级 5.7.28 引起的“血案”
- 2.聚合链路和网络故障排查
- 3.KUBERNETES网络故障排查实战之旅
- 4.阿里云全线产品突发史诗级故障，官方披露故障原因
1.故障分析 | BAD HANDSHAKE，升级 5.7.28 引起的“血案”
作者：陈俊聪
任职于中移信息基础平台部数据库组，负责 MYSQL 数据库运维工作。
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
引言
作为一名 DBA 碰到过升级出问题需要回退么？碰到过回退还解决不了问题么？我有幸遇到了一次凶险的升级“血案”。
问题来自协助客户升级 MYSQL，以修复一个安全漏洞。
升级版本为 5.7.30，但这个问题源于 5.7.28，并且影响 5.7.28 以上的版本，所以文章主要对比 5.7.27 和 5.7.28 版本。
注意不是 BUG，后面会详细说明！
一、现象
MYSQL 从 5.7.27 升级到 5.7.30。完成后应用连接测试发现页面异常，MYSQL ERROR 日志显示：
2020-05-05T22:10:57.976402+08:00 2 [NOTE] BAD HANDSHAKE没有报错，但这条 NOTE 级别的日志，引起了我的注意，之前从来没有见过。由于时间紧急，决定先回退 MYSQL 版本。回退后，问题未能解决。
BAD HANDSHAKE，"不好的握手"，网上查了资料，发现和 SSL 可能有关。这时业务也发来应用日志，日志有明显的 SSL 相关报错。
然后，我们去检查了 JDBC 连接串，连接串使用了 USESSL=TRUE，改为 USESSL=FALSE 后解决了。
二、分析
我们搭建了一套 JAVA 应用环境，在 5.7.27 版本和 5.7.28 版本分别测试了发生故障时的 JDBC 串：
SPRING.DATASOURCE.URL=JDBC:MYSQL://192.168.199.198:3307/SPRINGBOOTDB?USEUNICODE=TRUE&USESSL=TRUE&CHARACTERENCODING=UTF85.7.27 版本
1. 默认关闭了 SSL
MYSQL> SELECT @@VERSION;+————+| @@VERSION |+————+| 5.7.27-LOG |+————+1 ROW IN SET (0.00 SEC)MYSQL> SHOW VARIABLES LIKE '%SSL%';+—————+———-+| VARIABLE_NAME | VALUE |+—————+———-+| HAVE_OPENSSL | DISABLED || HAVE_SSL | DISABLED || SSL_CA | || SSL_CAPATH | || SSL_CERT | || SSL_CIPHER | || SSL_CRL | || SSL_CRLPATH | || SSL_KEY | |+—————+———-+9 ROWS IN SET (0.00 SEC)2. 应用页面正常
3. TOMCAT 日志正常
4. 抓包，确实没有用到 SSL，SQL 的明文被我抓出来了
[ROOT@FANDER ~]# TCPDUMP -I ENS33 PORT 3307 -L -S 0 -W – | STRINGSTCPDUMP: LISTENING ON ENS33, LINK-TYPE EN10MB (ETHERNET), CAPTURE SIZE 262144 BYTES^RY^,]SELECT ID, PROVINCE_ID, CITY_NAME, DESCRIPTION FROM CITY5. MYSQL ERR LOG 正常
小结
5.7.27 版本下，JDBC 连接串错误地配置了 USESSL=TRUE，并不会有问题，因为数据库不支持 SSL，所以连接实际上并不会使用到 SSL，一切正常。
5.7.28 版本
1. 升级后，默认居然开了 SSL
MYSQL> SHOW VARIABLES LIKE '%SSL%';+—————+—————–+| VARIABLE_NAME | VALUE |+—————+—————–+| HAVE_OPENSSL | YES || HAVE_SSL | YES || SSL_CA | CA.PEM || SSL_CAPATH | || SSL_CERT | SERVER-CERT.PEM || SSL_CIPHER | || SSL_CRL | || SSL_CRLPATH | || SSL_KEY | SERVER-KEY.PEM |+—————+—————–+9 ROWS IN SET (0.00 SEC)2. 应用页面异常
3. TOMCAT 日志异常
上面日志，能看出是 SSL 相关异常。并且能发现一个关键的报错，是握手异常，并且有证书相关的报错。 CAUSED BY: JAVAX.NET.SSL.SSLHANDSHAKEEXCEPTION: JAVA.SECURITY.CERT.CERTPATHVALIDATOREXCEPTION: PATH DOES NOT CHAIN WITH ANY OF THE TRUST ANCHORS后面我证实了，JDBC 连接要求 SSL 和 证书认证要一起使用。4. 抓包显示有加密信息，没有抓取到 SQL
[ROOT@FANDER ~]# TCPDUMP -I ENS33 PORT 3307 -L -S 0 -W – | STRINGSTCPDUMP: LISTENING ON ENS33, LINK-TYPE EN10MB (ETHERNET), CAPTURE SIZE 262144 BYTES@8Q=*8Q=+P@8Q=+5.7.30-LOG=LQIKF7MYSQL_NATIVE_PASSWORD8Q=}P@8Q=}B 8Q=}P@8Q=}@8Q=}0<1:081MYSQL_SERVER_5.7.30_AUTO_绵阳NERATED_CA_CERTIFICATE0200506110938Z300504110938Z0@1>0<5MYSQL_SERVER_5.7.30_AUTO_绵阳NERATED_SERVER_CERTIFICATE0 2NH=ZFX3[X=O(*C0TY5B0A,IY-{U60<1:081MYSQL_SERVER_5.7.30_AUTO_绵阳NERATED_CA_CERTIFICATE0200506110938Z300504110938Z0<1:081MYSQL_SERVER_5.7.30_AUTO_绵阳NERATED_CA_CERTIFICATE0>*[]DG^!!$Y[(JKH(NPJDVU{HMMOJBU38P3.^Z5. MYSQL ERR LOG 显示 "BAD HANDSHAKE"
2020-05-06T19:12:13.107321+08:00 2 [NOTE] BAD HANDSHAKE小结
5.7.28 版本下，JDBC 连接串错误地配置了 USESSL=TRUE，会有问题，因为数据库支持 SSL，所以连接实际上应用连接会真的去使用 SSL，但是因为证书问题，导致连接失败，造成了这次升级故障。
不加 USESSL 试试
有一些客户的连接串，是没有使用 USESSL 参数的。
于是，我去掉 USESSL=TRUE，把连接串改为
SPRING.DATASOURCE.URL=JDBC:MYSQL://192.168.199.198:3307/SPRINGBOOTDB?USEUNICODE=TRUE&CHARACTERENCODING=UTF8发现一切正常，但 TOMCAT 日志有以下的 WARNINGS：
WED MAY 06 20:54:47 CST 2020 WARN: ESTABLISHING SSL CONNECTION WITHOUT SERVER'S IDENTITY VERIFICATION IS NOT RECOMMENDED. ACCORDING TO MYSQL 5.5.45+, 5.6.26+ AND 5.7.6+ REQUIREMENTS SSL CONNECTION MUST BE ESTABLISHED BY DEFAULT IF EXPLICIT OPTION ISN'T SET. FOR COMPLIANCE WITH EXISTING APPLICATIONS NOT USING SSL THE VERIFYSERVERCERTIFICATE PROPERTY IS SET TO 'FALSE'. YOU NEED EITHER TO EXPLICITLY DISABLE SSL BY SETTING USESSL=FALSE, OR SET USESSL=TRUE AND PROVIDE TRUSTSTORE FOR SERVER CERTIFICATE VERIFICATION.
翻译：
- 不建议在未经服务器身份验证的情况下建立 SSL 连接。
- 根据 MYSQL 5.5.45+、5.6.26+ 和 5.7.6+ 的要求，如果未设置显式选项，则默认情况下必须建立 SSL 连接。
- 为了符合不使用 SSL 的现有应用程序，VERIFYSERVERCERTIFICATE 属性设置为“FALSE”。
- 您需要通过设置 USESSL=FALSE 显式禁用 SSL，
- 或者设置 USESSL=TRUE 并为服务器证书验证提供 TRUSTSTORE。
从这里的报错，我发现了另外一个连接串参数，VERIFYSERVERCERTIFICATE，这个参数默认为 TRUE，表示要验证服务器证书。
测试得出了以下表格：
三、原因
原因就是连接串错误地设置了 USESSL=TRUE。
在 5.7.27 版本由于实际上不支持 SSL 连接，所以设置 USESSL 居然不会报错，而会降级使用非 SSL 连接；而在 5.7.28 版本，实际上支持了 SSL 连接，所以根据 JDBC 配置 USESSL=TRUE，连接会真的采用 SSL，但应用服务器并没有为服务器证书验证提供 TRUSTSTORE 文件，所以报错了。
问题一：为什么 5.7.28 才支持 SSL？
翻阅官方文档 5.7.28 的 RELEASE NOTES，并没有发现新支持 SSL 的描述，所以应该原本也是支持 SSL 的。实际上的确如此，对于非 OPENSSL 编译的 MYSQL(5.7.27 及之前版本)，可以采用 LINUX 自带的 OPENSSL 和 MYSQL 自带的工具 MYSQL_SSL_RSA_SETUP，来生成"SSL 密钥和证书文件"，以支持 SSL 连接。
注意：ONLY OPENSSL
以往 MYSQL 社区版默认是使用 YASSL 编译，企业版默认使用 OPENSSL 编译，手动编译时可以选择 YASSL 或 OPENSSL。
目前仅支持 OPENSSL，YASSL 被移除了，默认编译用的是 OPENSSL，社区版和企业版支持并且只支持 OPENSSL 作为其 SSL 库。
至于为什么要使用 OPENSSL 替代 YASSL，我们不展开讨论。
在 MYSQLD.CC 源码里可以看到相关的一些代码改动，
左边 5.7.28，定义了 OPENSSL，则 INIT-RSA_KEYS
右边 5.7.27，定义了 OPENSSL，并且没有定义 YASSL，才 INIT_RSA_KEYS。
由于 5.7.27 默认是 YASSL 编译的，所以实际上不会执行 INIT_RSA_KEYS 那段代码。怀疑就是这个改动致使 5.7.28 才支持 SSL。
准确地说，是 5.7.28 才默认支持 SSL，之前版本需要手动使用工具 MYSQL_SSL_RSA_SETUP 来生成"SSL 密钥和证书文件"，以支持 SSL 连接。
1. 5.7.28 启动数据库时，会在数据目录自动生成以下文件，而 5.7.27 版本并没有。
CA-KEY.PEMCA.PEMCLIENT-CERT.PEMCLIENT-KEY.PEMPRIVATE_KEY.PEMPUBLIC_KEY.PEMSERVER-CERT.PEMSERVER-KEY.PEM这些文件实际上就是"SSL 密钥和证书文件"，用于支持 SSL 连接。
2. 那么为什么 5.7.28 会自动生成这些文件？
MYSQL –VERBOSE –HELP |LESS –AUTO-绵阳NERATE-CERTS AUTO 绵阳NERATE SSL CERTIFICATES AT SERVER STARTUP IF –SSL IS SET TO ON AND NONE OF THE OTHER SSL SYSTEM VARIABLES ARE SPECIFIED AND CERTIFICATE/KEY FILES ARE NOT PRESENT IN DATA DIRECTORY. (DEFAULTS TO ON; USE –SKIP-AUTO-绵阳NERATE-CERTS TO DISABLE.)在 5.7.28 版本，存在该服务器参数，但 5.7.27 未见此参数。
参数写的很清楚，默认是开的，用于自动生成"SSL 密钥和证书文件"，如果数据目录没有这堆文件的话。
相关的参数，还有这些：
- AUTO_绵阳NERATE_CERTS
- SHA256_PASSWORD_AUTO_绵阳NERATE_RSA_KEYS
- SHA256_PASSWORD_PRIVATE_KEY_PATH
- SHA256_PASSWORD_PUBLIC_KEY_PATH
- RSA_PUBLIC_KEY
官方文档并没有告诉我们这些参数是 5.7.28 新增的，原因是因为这些参数压根就不是新增的！这些参数是一直都有的！
如果你的 MYSQL 源码编译时用 OPENSSL，替代 YASSL，那就有这些参数！
所以 ONLY OPENSSL 这个新特性，实际上影响比官方文档写的要大，因为他实际上影响了 MYSQL 参数！影响了 MYSQL 默认开启了 SSL 的支持！
问题二：为什么降级回退 MYSQL 没有解决问题？
MYSQL 5.7.28 启动的时候，会自动生成这些"SSL 密钥和证书文件"，所以实际上开启了 SSL 支持。回退 MYSQL 5.7.27 时，这些文件和元数据无关，MYSQL_UPGRADE 程序是不会帮你删除这些"SSL 密钥和证书文件"的，所以回退后，5.7.27 实际上也开启了 SSL 支持！这导致我那个错误配置 USESSL=TRUE 但没有配置 TRUSTSTORE 文件的应用程序报错。
讨论解决办法
既然，有没有这堆文件，会导致实际上是否开启 SSL，那么解决办法可以是：
1. 删除这堆文件，然后重启 MYSQL。
在回退后的 5.7.27 版本是可以这么操作，但我们总归要升级回去 5.7.28 的，而5.7.28 启动又会自动生成这堆文件，开启 SSL，所以这方法不行。
2. 删除这堆文件的某个文件，然后重启 MYSQL。
这个方法看起来是可行的，例如删除了 CA.PEM 这个文件，文件不全会导致 SSL DISABLED，并且 MYSQLD 判断数据目录有部分 PEM 文件，于是不会重新生成。但这方法忽略了一个可能，就是如果数据库通过 XTRABACKUP 物理热备重做数据库后，因为 XTRABACKUP 实际上不会备份任何 PEM 文件，所以数据库重做启动后，因 MYSQLD 判断数据目录没有"SSL 密钥和证书文件"，这堆文件会全部重新生成。所以这方法不可行。
3. 配置 AUTO_绵阳NERATE_CERTS=OFF
让不生成 CERT 文件，即可默认 SSL DISABLED。
建议的解决办法
因为 5.7.27 之前实际上默认是不支持 SSL 连接的，所以为了升级数据库保持原样，只需要配置文件新增以下配置即可。
[MYSQLD]SKIP_SSL这方法，可以忽略"SSL 密钥和证书文件" ，不启用 SSL 。
总结
文章分享了 JDBC 应该如何配置，并且分享了一起官方文档没有提及的"默认参数变化"引起的升级故障，建议大家升级之前测试一下，对比一下参数，不要过度依赖于官方 RELEASE NOTES 文档。
2.聚合链路和网络故障排查
聚合链路是将多块网卡逻辑地连接到一起从而允许故障转移或者提高吞吐率的方法。提高服务器网络可用性。
BOND是将多块网卡虚拟成为一块网卡的技术，通过BOND技术让多块网卡看起来是一个单独的以太网接口设备并具有相同的IP地址。在LINUX下配置BOND，通过网卡绑定技术既能增加服务器的可靠性，又增加了可用网络宽带，为用户提供不间断的网络服务。
TEAM是另一种用来实现链路聚合和方法，类似于BOND，TEAM和BOND的区别在于，支持HASH加密，支持负载均衡，支持8块网卡，更好地支持IPV6
实现方式
BOND
MOD=0 ，即：(BALANCE-RR) ROUND-ROBIN POLICY（轮询）
聚合口数据报文按包轮询从物理接口转发。
负载均衡—所有链路处于负载均衡状态，轮询方式往每条链路发送报文这模式的特点增加了带宽，同时支持容错能力，当有链路出问题，会把流量切换到正常的链路上。
性能问题—一个连接或者会话的数据包如果从不同的接口发出的话，中途再经过不同的链路，在客户端很有可能会出现数据包无序到达的问题，而无序到达的数据包需要重新要求被发送，这样网络的吞吐量就会下降。BOND0在大压力的网络传输下，性能增长的并不是很理想。
需要交换机进行端口绑定
第二种模式：MOD=1，即： (ACTIVE-BACKUP) ACTIVE-BACKUP POLICY（主-备份策略）
只有ACTIVE状态的物理接口才转发数据报文。
容错能力—只有一个SLAVE是激活的(ACTIVE)。也就是说同一时刻只有一个网卡处于工作状态，其他的SLAVE都处于备份状态，只有在当前激活的SLAVE故障后才有可能会变为激活的(ACTIVE)。
无负载均衡—此算法的钦州是可以提供高网络连接的可用性，但是它的资源利用率较低，只有一个接口处于工作状态，在有 N 个网络接口的情况下，资源利用率为1/N。
第三种模式：MOD=2，即：(BALANCE-XOR) XOR POLICY（平衡策略）
聚合口数据报文按源目MAC、源目IP、源目端口进行异或HASH运算得到一个值，根据该值查找接口转发数据报文
负载均衡—基于指定的传输HASH策略传输数据包。
容错能力—这模式的特点增加了带宽，同时支持容错能力，当有链路出问题，会把流量切换到正常的链路上。
性能问题—该模式将限定流量，以保证到达特定对端的流量总是从同一个接口上发出。既然目的地是通过MAC地址来决定的，因此该模式在“本地”网络配置下可以工作得很好。如果所有流量是通过单个路由器，由于只有一个网关，源和目标MAC都固定了，那么这个算法算出的线路就一直是同一条，那么这种模式就没有多少意义了。
需要交换机配置为PORT CHANNEL
第四种模式：MOD=3，即：BROADCAST（广播策略）
这种模式的特点是一个报文会复制两份往BOND下的两个接口分别发送出去，当有对端交换机失效，我们感觉不到任何DOWNTIME，但此法过于浪费资源；不过这种模式有很好的容错机制。此模式适用于葫芦岛融行业，因为他们需要高可靠性的网络，不允许出现任何问题。
第五种模式：MOD=4，即：(802.3AD) IEEE 802.3AD DYNAMIC LINK AGG榆林ATION（IEEE 802.3AD 动态链接聚合）
在动态聚合模式下，聚合组内的成员端口上均启用LACP（链路汇聚控制协议）协议，其端口状态通过该协议自动进行维护。
负载均衡—基于指定的传输HASH策略传输数据包。默认算法与BLANCE-XOR一样。
容错能力—这模式的特点增加了带宽，同时支持容错能力，当有链路出问题，会把流量切换到正常的链路上。对比BLANCE-XOR，这种模式定期发送LACPDU报文维护链路聚合状态，保证链路质量。
需要交换机支持LACP协议
第六种模式：MOD=5，即：(BALANCE-TLB) ADAPTIVE TRANSMIT LOAD BALANCING（适配器传输负载均衡）
在每个物理接口上根据当前的负载（根据速度计算）分配外出流量。如果正在接收数据的物理接口口出故障了，另一个物理接口接管该故障物理口的MAC地址。
需要ETHTOOL支持获取每个SLAVE的速率
第七种模式：MOD=6，即：(BALANCE-雅安) ADAPTIVE LOAD BALANCING（适配器适应性负载均衡）
该模式包含了BALANCE-TLB模式，同时加上针对IPV4流量的接收负载均衡，而且不需要任何SWITCH(交换机)的支持。接收负载均衡是通过ARP协商实现的。BONDING驱动截获本机发送的ARP应答，并把源硬件地址改写为BOND中某个物理接口的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。
其实MOD=6与MOD=0的区别：MOD=6，先把ETH0流量占满，再占ETH1，….ETHX；而MOD=0的话，会发现2个口的流量都很稳定，基本一样的带宽。而MOD=6，会发现第一个口流量很高，第2个口只占了小部分流量
常用的模式为 0136
MODE 1、5、6不需要交换机设置
MODE 0、2、3、4需要交换机设置
案例
环境
系统：CENTOS8
网卡名称： ENS33（VMNET4） ENS37（VMNET4）
STEP1
查看环境
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION
NAME UUID TYPE DEVICE
ENS33 F035D150-9E89-4EE9-A657-03598D4B0940 ETHERNET ENS33
ENS37 7726249D-8281-45E8-A8E3-A6A023C64C66 ETHERNET ENS37STEP2
创建BOND虚拟网卡
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION ADD TYPE BOND CON-NAME BOND0 IFNAME BOND0 MODE 1 IPV4.ADDRESSES 192.168.98.200/24 IPV4.METHOD MANUAL AUTOCONNECT YES
#TYPE：创建的类型，这里选择BOND类型
#CON-NAME:这里写链接名，就是SHOW中第一列，这里写什么生成的文件就是什么名字
#IFNAME:网卡名，这里BOND0是虚拟出来的
#MODE:选择BOND模式，常用的有主备，轮询，广播，还有其他模式，用TAB补全可以看到所有，也可以使用数字0-6表示
#IPV4.MEHOD:表示自动还是手动，就是使用DHCP还是自己配置地址，关联配置文件中的BOOTPROTO段
#IPV4.ADDRESS：设置IP地址，注意记得加上掩码
#AUTOCONNECT 自动连接STEP3
为BOND网卡添加成员（邵阳网卡）
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION ADD TYPE BOND-SLAVE IFNAME ENS33 MASTER BOND0
连接 "BOND-SLAVE-ENS33" (9FB9B3FA-A477-4A6F-A3C1-79CBFE351C7D) 已成功添加。
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION ADD TYPE BOND-SLAVE IFNAME ENS37 MASTER BOND0
连接 "BOND-SLAVE-ENS37" (2B047E49-B606-4B67-9E5C-F721F1E2FF7A) 已成功添加。
#类型为BOND-SLAVE,表示这块邵阳网卡属于一块附属的网卡，原有配置的属性都不能使用了，MASTER表示这块从属网卡属于BOND0这个组注意：如果你的网卡没有启用的话需要启用
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION
NAME UUID TYPE DEVICE
BOND0 55E0AFDC-D2A6-4C93-B346-0CE207947B81 BOND BOND0
BOND-SLAVE-ENS33 9FB9B3FA-A477-4A6F-A3C1-79CBFE351C7D ETHERNET ENS33
BOND-SLAVE-ENS37 2B047E49-B606-4B67-9E5C-F721F1E2FF7A ETHERNET ENS37
ENS33 F035D150-9E89-4EE9-A657-03598D4B0940 ETHERNET —
ENS37 7726249D-8281-45E8-A8E3-A6A023C64C66 ETHERNET —
[ROOT@MANA绵阳01 ~]# IFCONFIG
BOND0: ETHER 00:0C:29:A6:AD:95 TXQUEUELEN 1000 (ETHERNET)
ENS33: ETHER 00:0C:29:A6:AD:95 TXQUEUELEN 1000 (ETHERNET)
ENS37: ETHER 00:0C:29:A6:AD:95 TXQUEUELEN 1000 (ETHERNET)
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION UP BOND-SLAVE-ENS33
连接已成功激活（D-BUS 活动路径：/ORG/FREEDESKTOP/NETWORKMANA绵阳R/ACTIVECONNECTION/81）
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION UP BOND-SLAVE-ENS37
连接已成功激活（D-BUS 活动路径：/ORG/FREEDESKTOP/NETWORKMANA绵阳R/ACTIVECONNECTION/82）
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION UP BOND0
连接已成功激活（MASTER WAITING FOR SLAVES）（D-BUS 活动路径：/ORG/FREEDESKTOP/NETWORKMANA绵阳R/ACTIVECONNECTION/83）
STEP4
查看链接信息并测试
#查看信息
[ROOT@MANA绵阳01 ~]# CAT /P永新/NET/BONDING/BOND0
ETHERNET CHANNEL BONDING DRIVER: V3.7.1 (APRIL 27, 2011)
BONDING MODE: FAULT-TOLERANCE (ACTIVE-BACKUP)#模式
PRIMARY SLAVE: NONE
CURRENTLY ACTIVE SLAVE: ENS33 #当前设备
MII STATUS: UP #启用状态
MII POLLING INTERVAL (MS): 100
UP DELAY (MS): 0
DOWN DELAY (MS): 0
SLAVE INTERFACE: ENS33 #从接口信息
MII STATUS: UP
SPEED: 1000 MBPS
DUPLEX: FULL
LINK FAILURE COUNT: 0
PERMANENT HW ADDR: 00:0C:29:A6:AD:95
SLAVE QUEUE ID: 0
SLAVE INTERFACE: ENS37 #另外一个从接口信息
MII STATUS: UP
SPEED: 1000 MBPS
DUPLEX: FULL
LINK FAILURE COUNT: 0
PERMANENT HW ADDR: 00:0C:29:A6:AD:9F
SLAVE QUEUE ID: 0
或者
[ROOT@MANA绵阳01 ~]# IP ADD
ENS33: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> MTU 1500 QDISC FQ_CODEL MASTER BOND0 STATE UP GROUP DEFAULT QLEN 1000
LINK/ETHER 00:0C:29:A6:AD:95 BRD FF:FF:FF:FF:FF:FF
ENS37: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> MTU 1500 QDISC FQ_CODEL MASTER BOND0 STATE UP GROUP DEFAULT QLEN 1000
LINK/ETHER 00:0C:29:A6:AD:95 BRD FF:FF:FF:FF:FF:FF
BOND0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> MTU 1500 QDISC NOQUEUE STATE UP GROUP DEFAULT QLEN 1000
LINK/ETHER 00:0C:29:A6:AD:95 BRD FF:FF:FF:FF:FF:FF
INET 192.168.98.200/24 BRD 192.168.98.255 SCOPE GLOBAL NOPREFIXROUTE BOND0
VALID_LFT FOREVER PREFERRED_LFT FOREVER
#找到另外一台主机使用PING进行测试
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION DOWN BOND-SLAVE-XXX
或者直接断开虚拟的网络连接测试还能否PING通删除
NMCLI CONNECTION DELETE BOND0 BOND-SLAVE-ENS33 BOND-SLAVE-ENS37注意：在配置聚合链路的时候如果使用虚拟机可能会弹出与MAC地址相关的信息提示，可以暂时不用去管，如果测试的时候发现断网卡之后无法PING通，则需要在相关网卡配置文件中添加参数，如：
[ROOT@MANA绵阳01 ~]# VIM /ETC/SYSCONFIG/NETWORK-SCRIPTS/IFCFG-BOND0
#添加一行内容
BONDING_OPTS="MIIMON=100 MODE=1 FAIL_OVER_MAC=1"
#MIIMON：链路检查时间为100MS
#MODE：模式为1，要与BOND的模式相同
#FAIL_OVER_MAC=1 MAC地址跟随正常工作的网卡，当第一块网卡挂掉之后，自动将MAC地址调整为第二块网卡的MAC
以上操作只有在虚拟机的环境中使用，生产环境一般不需要TEAM
STEP1
建立
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION ADD TYPE TEAM CON-NAME TEAM0 IFNAME TEAM0 CONFIG '{"RUNNER":{"NAME":"ACTIVEBACKUP","HWADDR_POLICY":"BY_ACTIVE"}}' IPV4.ADDRESSES 192.168.98.200/24 IPV4.METHOD MANUAL AUTOCONNECT YES
#JSON语湘西式如下：’{“RUNNER”:{“NAME”:“METHOD”}}’其中METHOD 是以下的其中一个
BROADCAST=MODE3
ROUNDROBIN=MODE0
ACTIVEBACKUP=MODE1
LOADBALANCE=MODE256
LACP=MODE4
#"HWADDR_POLICY":"BY_ACTIVE"：硬件地址跟随活跃的网卡，也就是未故障的网卡
#聚合链路获取MAC的地址有两种方式,一种是从第一个活跃网卡中获取MAC地址，然后其余的SLAVE网卡的MAC地址都使用该MAC地址;另一种是使用HWADDR_POLICY参数，TEAM使用当前活跃网卡的MAC地址，MAC地址随活跃网卡的转换而变，虚机不支持第一种获取MAC地址的方式。STEP2
添加网卡
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION ADD TYPE TEAM-SLAVE IFNAME ENS33 MASTER TEAM0
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION ADD TYPE TEAM-SLAVE IFNAME ENS37 MASTER TEAM0STEP3
启用连接
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION UP TEAM-SLAVE-ENS33
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION UP TEAM-SLAVE-ENS37
[ROOT@MANA绵阳01 ~]# NMCLI CONNECTION UP TEAM0STEP4
查看状态
[ROOT@MANA绵阳01 ~]# TEAMDCTL TEAM0 STAT
SETUP:
RUNNER: ACTIVEBACKUP
PORTS:
ENS33
LINK WATCHES:
LINK SUMMARY: UP
INSTANCE[LINK_WATCH_0]:
NAME: ETHTOOL
LINK: UP
DOWN COUNT: 0
ENS37
LINK WATCHES:
LINK SUMMARY: UP
INSTANCE[LINK_WATCH_0]:
NAME: ETHTOOL
LINK: UP
DOWN COUNT: 0
RUNNER:
ACTIVE PORT: ENS37测试
网络故障排查
在日常使用中，经常会出现无法连通的情况，这个时候我们就需要找到问题出在哪里，这里面给各位提供一个生产环境排查网络故障的大体思路，一般情况下如果遇到网络故障，都是通过筛选的方式一点一点地确定问题所在，首先判断是本机的问题还是网络上其它设备的问题，如果同一网络环境中的其它主机正常的，要去其它网络设备（路由器）上查看一下是否对网络有问题的主机设置了限制，如果没有的话，问题出在本机，这里面我们主要看下下本机容易出现哪些问题导致页面无法访问
1 网线和网卡
检查网卡的灯是否亮起，普通服务器的话应该是绿灯常亮为正常，交换机绿灯闪烁表示正在传输数据。也可以通过命令ETHTOOL ETHX来查看某一网卡的链路是否物理连通。
命令介绍
ETHTOOL
[ROOT@MANA绵阳01 ~]# ETHTOOL ENS33
SETTINGS FOR ENS33:
SUPPORTED PORTS: [ TP ]
#接口类型
#TP RJ45接口双绞线
#AUI “D”型15针接口
#BNC 细同轴电缆接口，类似于以前的有线电视
#MII 媒体独立接口，一种以太网行业标准
#FIBRE 光纤
SUPPORTED LINK MODES: 10BASET/HALF 10BASET/FULL
100BASET/HALF 100BASET/FULL
1000BASET/FULL
#支持的链接模式
SUPPORTED PAUSE FRAME USE: NO
#是否支持暂停帧–一种网卡流量控制技术
SUPPORTS AUTO-NEGOTIATION: YES
#是否支持自动协商，网络设备相互告知对方自己的工作方式，包括传输速度，双工状态等，然后选择一个最佳的
SUPPORTED FEC MODES: NOT REPORTED
#编码纠错模式，支持编码纠错可提高数据通讯可信度
ADVERTISED LINK MODES: 10BASET/HALF 10BASET/FULL
100BASET/HALF
100BASET/FULL
1000BASET/FULL
#宣告的链接模式
ADVERTISED PAUSE FRAME USE: NO
#宣告的是否支持帧暂停
ADVERTISED AUTO-NEGOTIATION: YES
#宣告的是否支持自动协商
ADVERTISED FEC MODES: NOT REPORTED
#宣告的是否FEC
SPEED: 1000MB/S
#当前速度
DUPLEX: FULL
#全双工还是半双工
PORT: TWISTED PAIR
#线缆类型为双绞线
PHYAD: 0
#PHY地址，主要指PHY芯片，用来发送和接收数据帧
TRANSCEIVER: INTERNAL
#收发器类型 INTERNAL/EXTERNAL（内部外部）是否是板载的
AUTO-NEGOTIATION: ON
#自动协商功能开启
MDI-X: OFF (AUTO)
#自适应功能
SUPPORTS WAKE-ON: D
#是否支持远程唤醒 D=禁用，P\U\M\B\A\G=不同唤醒方式
WAKE-ON: D
CURRENT MESSA绵阳 LEVEL: 0X00000007 (7) DRV PROBE LINK
LINK DETECTED: YES
#网卡已连接
##############常用参数
#-A 查看网卡中 接收模块RX、发送模块TX和AUTONEGOTIATE模块的状态：启动ON 或 停用OFF。主要指接收暂停，发送暂停和自动协商暂停功能，也就是暂停帧，主要用于控制数据路停止发送，可以防止瞬间压力过大导致缓冲区溢出而引发的帧丢失（丢包）
#[ROOT@MANA绵阳01 ~]# ETHTOOL -A ENS33
PAUSE PARAMETERS FOR ENS33:
AUTONEGOTIATE: ON
RX: OFF
TX: OFF
#-A 修改网卡中 接收模块RX、发送模块TX和AUTONEGOTIATE模块的状态：启动ON 或 停用OFF。
[ROOT@MANA绵阳01 ~]# ETHTOOL -A ENS33 RX/TX/AUTONEG ON
#-I 显示网卡驱动的信息，如驱动的名称、版本等。
[ROOT@MANA绵阳01 ~]# ETHTOOL -I ENS33
DRIVER: E1000
VERSION: 7.3.21-K8-NAPI
FIRMWARE-VERSION:
EXPANSION-ROM-VERSION:
BUS-INFO: 0000:02:01.0
SUPPORTS-STATISTICS: YES
SUPPORTS-TEST: YES
SUPPORTS-EEPROM-ACCESS: YES
SUPPORTS-榆林ISTER-DUMP: YES
SUPPORTS-PRIV-FLAGS: NO
#-K 显示网卡各项功能的支持和协议状态，如支持某个协议的功能是否开启等
#-P 用于区别不同ETHX对应网卡的物理位置，常用的方法是使网卡PORT上的LED不断的闪；N为网卡闪的持续时间，以秒为单位。
[ROOT@MANA绵阳01 ~]# ETHTOOL -P ENS33 10
#-R 如果自动协商状态为ON，则重启自动协商功能。
[ROOT@MANA绵阳01 ~]# ETHTOOL -R ENS33
#-S 显示统计参数，如网卡接收/发送的字节数、接收/发送的广播包个数等。
[ROOT@MANA绵阳01 ~]# ETHTOOL -S ENS33
NIC STATISTICS:
RX_PACKETS: 609
TX_PACKETS: 130
RX_BYTES: 121330
TX_BYTES: 16066
RX_BROADCAST: 0
#-S 修改网卡的部分配置，包括网卡速度、单工/全双工模式、MAC地址等。
ETHTOOL –S ETHX [SPEED 10|100|1000]
#设置网口速率10/100/1000M
[DUPLEX HALF|FULL]
#设置网口半/全双工
[AUTONEG ON|OFF]
#设置网口是否自协商
[PORT TP|AUI|BNC|MII]
#设置网口类型
[ROOT@MANA绵阳01 ~]# ETHTOOL -S ENS33 SPEED 1000 DUPLEX FULL AUTONEG ON PORT TP
2 SELINUX&防火墙
这两个是最容易产生干扰的项目，SELINUX和防火墙如何关闭，我们在前面的课程中有涉及，这里就不重复了
3 查看网卡IP地址，网关设置
使用IFCONFIG或者NMCLI命令查看/设置IP地址和网关
4 使用PING命令测试连通性
-C<完成次数>：设置完成要求回应的次数；
-F：洪水PING只有ROOT可以使用
-I<间隔秒数>：指定收发信息的间隔时间；
-N：只输出数值,不尝试去查找主机名
-S<数据包大小>：设置数据包的大小；
-I 指定源地址（源地址必须是本地网卡上存在的配置）
[ROOT@RS1 ~]# PING -C 3 -I 0.5 -N -S 1024 -I 192.168.2.220 192.168.2.220
PING 192.168.2.220 (192.168.2.220) FROM 192.168.2.220 : 1024(1052) BYTES OF DATA.
1032 BYTES FROM 192.168.2.220: ICMP_SEQ=1 TTL=64 TIME=0.047 MS
1032 BYTES FROM 192.168.2.220: ICMP_SEQ=2 TTL=64 TIME=0.060 MS
1032 BYTES FROM 192.168.2.220: ICMP_SEQ=3 TTL=64 TIME=0.053 MS
— 192.168.2.220 PING STATISTICS —
3 PACKETS TRANSMITTED, 3 RECEIVED, 0% PACKET LOSS, TIME 13MS
RTT MIN/AVG/MAX/MDEV = 0.047/0.053/0.060/0.008 MS5 路由
使用ROUTE命令查看或设置路由及网关，也可以通过修改静态路由配置文件实现
6 DNS
/ETC/HOSTS&/ETC/RESOLV.CONF
NS梅州
DIG
HOST
7追踪数据包
TRACEPATH [参数选项] HOSTNAME，域名或 IP地址
#替代了以前的TRACEROUTE
参数选项：
-4 使用IPV4
-6 使用IPV6=TRACEPATH6
-L 设置初始包的大小 默认IPV4 65535，IPV6 128000
-M 设置检测数据包的TTL，默认值为30次；
-N 显示IP地址，不查主机名。当DNS不起作用时常用到这个参数；
-B 显示主机名和IP地址
-P PORT 探测包使用的基本UDP端口设置为PORT ，默认值是33434
[ROOT@RS1 ~]# TRACEPATH -B WWW.BAIDU.COM -L 1000 -M 5
1: LOCALHOST (192.168.0.1) 18.324MS
2: LOCALHOST (192.168.1.1) 15.622MS
3: LOCALHOST (10.70.0.1) 18.640MS
4: 114.244.94.25 (114.244.94.25) 7.213MS
5: 124.65.56.141 (124.65.56.141) 16.020MS
TOO MANY HOPS: PMTU 1000
RESUME: PMTU 10008硬件故障
更换硬件
总结
BOND的方式实现方法
TEAM的方式实现方法
网络故障排查的思路
网络故障的排除方法
重点：两种不同的聚合链路的实现方式，网络故障的排查思路、网络故障排查时涉及到的相关工具
难点：能够独立完成BOND和TEAM的两种实现方式，网络故障排查过程中所涉及到的命令，及应用方向
3.KUBERNETES网络故障排查实战之旅
译自A HANDS-ON KUBERNETES NETWORK TROUBLESHOOTING JOURNEY。
在开发KATA/REMOTE-HYPERVISOR(也称为PEER-PODS)方案时，我遇到了一个问题，即KUBERNETES POD IP在工作节点上无法访问。在本博客中，我将描述KUBERNETES网络故障排查过程，希望对读者有帮助。
KATA远程管理程序(PEER-PODS)方案通过在AWS或MICROSOFT AZURE等基础设施环境中使用本机基础设施管理API(如在AWS上创建KATA VM时使用AWS API，在AZURE上创建时使用MICROSOFT AZURE API)，实现在任何基础设施环境中创建KATA VM。CNCF保密容器项目的CLOUD-API-ADAPTOR子项目实现了KATA远程管理程序。
如下图所示，在PEER-PODS方案中，POD(KATA)虚拟机在KUBERNETES(K8S)工作节点外部运行，通过VXLAN隧道从工作节点访问POD IP。使用隧道可以确保POD联网继续正常工作，无需对CNI网络做任何改变。
当使用KATA容器时，KUBERNETES POD在虚拟机内运行，因此我们将运行POD的虚拟机称为KATA VM或POD虚拟机。
问题
POD IP10.132.2.46，它位于POD虚拟机上(IP:192.168.10.201)，从工作节点虚拟机(IP:192.168.10.163)无法访问。
以下是我环境中的虚拟机详细信息 —— 工作节点虚拟机和POD(KATA)虚拟机。使用的KUBERNETES CNI是OVN-KUBERNETES。
+===========================+================+================+
| VM名称 | IP地址 | 备注 |
+===========================+================+================+
| OCP-412-OVN-WORKER-1 | 192.168.10.163 | 工作节点虚拟机 |
+—————————+—————-+—————-+
| PODVM-NGINX-PRIV-8B726648 | 192.168.10.201 | POD虚拟机 |
+—————————+—————-+—————-+
最简单的解决方案就是请网络专家来解决这个问题。然而，在我的情况下，由于其他紧迫问题，专家无法直接参与解决。此外，PEER-PODS网络拓扑结构还比较新，涉及多个网络栈 —— KUBERNETES CNI、KATA网络和VXLAN隧道，使得根本原因难以查明且非常耗时。
因此，我将这种情况视为提高我的KUBERNETES网络技能的机会。在一些LINUX网络核心专家的指导下，我开始自行调试。
在后续章节中，我将通过我的方法带您逐步了解调试过程和找到问题根本原因。我希望这个过程能对KUBERNETES网络问题故障排除有所帮助。
故障排查 – 第一阶段
在高层面上，我采取的方法包含以下两个步骤:
- 了解网络拓扑结构
- 从拓扑结构中识别有问题的部分
让我们从工作节点虚拟机PING IP:10.132.2.46，并跟踪网络栈中的流量:
[ROOT@OCP-412-WORKER-1 CORE]# PING 10.132.2.46LINUX会参考路由表来确定发送数据包的目的地。
[ROOT@OCP-412-WORKER-1 CORE]# IP ROUTE 绵阳T 10.132.2.46
10.132.2.46 DEV OVN-K8S-MP0 SRC 10.132.2.2 UID 0因此，到POD IP的路由是通过设备OVN-K8S-MP0
让我们获取工作节点网络详细信息，并检索有关OVN-K8S-MP0设备的信息。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP R
DEFAULT VIA 192.168.10.1 DEV BR-EX PROTO DHCP SRC 192.168.10.163 METRIC 48
10.132.0.0/14 VIA 10.132.2.1 DEV OVN-K8S-MP0
10.132.2.0/23 DEV OVN-K8S-MP0 PROTO KERNEL SCOPE LINK SRC 10.132.2.2
169.254.169.0/29 DEV BR-EX PROTO KERNEL SCOPE LINK SRC 169.254.169.2
169.254.169.1 DEV BR-EX SRC 192.168.10.163 MTU 1400
169.254.169.3 VIA 10.132.2.1 DEV OVN-K8S-MP0
172.30.0.0/16 VIA 169.254.169.4 DEV BR-EX MTU 1400
192.168.10.0/24 DEV BR-EX PROTO KERNEL SCOPE LINK SRC 192.168.10.163 METRIC 48
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP A
[SNIP]
2: ENS3: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 QDISC FQ_CODEL MASTER OVS-SYSTEM STATE UP GROUP DEFAULT QLEN 1000
LINK/ETHER 52:54:00:F9:70:58 BRD FF:FF:FF:FF:FF:FF
3: OVS-SYSTEM: <BROADCAST,MULTICAST> MTU 1500 QDISC NOOP STATE DOWN GROUP DEFAULT QLEN 1000
LINK/ETHER 32:7C:7A:20:6E:5A BRD FF:FF:FF:FF:FF:FF
4: 绵阳NEV_SYS_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 65000 QDISC NOQUEUE MASTER OVS-SYSTEM STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/ETHER 3A:9C:A8:4E:15:0C BRD FF:FF:FF:FF:FF:FF
INET6 FE80::389C:A8FF:FE4E:150C/64 SCOPE LINK
VALID_LFT FOREVER PREFERRED_LFT FOREVER
5: BR-INT: <BROADCAST,MULTICAST> MTU 1400 QDISC NOOP STATE DOWN GROUP DEFAULT QLEN 1000
LINK/ETHER D2:B6:67:15:EF:06 BRD FF:FF:FF:FF:FF:FF
6: OVN-K8S-MP0: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1400 QDISC NOQUEUE STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/ETHER EE:CB:ED:8E:F9:E0 BRD FF:FF:FF:FF:FF:FF
INET 10.132.2.2/23 BRD 10.132.3.255 SCOPE GLOBAL OVN-K8S-MP0
VALID_LFT FOREVER PREFERRED_LFT FOREVER
INET6 FE80::ECCB:EDFF:FE8E:F9E0/64 SCOPE LINK
VALID_LFT FOREVER PREFERRED_LFT FOREVER
8: BR-EX: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 QDISC NOQUEUE STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/ETHER 52:54:00:F9:70:58 BRD FF:FF:FF:FF:FF:FF
INET 192.168.10.163/24 BRD 192.168.10.255 SCOPE GLOBAL DYNAMIC NOPREFIXROUTE BR-EX
VALID_LFT 2266SEC PREFERRED_LFT 2266SEC
INET 169.254.169.2/29 BRD 169.254.169.7 SCOPE GLOBAL BR-EX
VALID_LFT FOREVER PREFERRED_LFT FOREVER
INET6 FE80::17F3:957B:5E8D:A4A6/64 SCOPE LINK NOPREFIXROUTE
VALID_LFT FOREVER PREFERRED_LFT FOREVER
[SNIP]
从上述输出可以看出，OVN-K8S-MP0接口的IP是10.132.2.2/23
让我们获取OVN-K8S-MP0接口的设备详细信息。
如下输出所示,这个接口是一个OVS实体。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP -D LI SH DEV OVN-K8S-MP0
6: OVN-K8S-MP0: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1400 QDISC NOQUEUE STATE UNKNOWN MODE DEFAULT GROUP DEFAULT QLEN 1000
LINK/ETHER EE:CB:ED:8E:F9:E0 BRD FF:FF:FF:FF:FF:FF PROMISCUITY 1 MINMTU 68 MAXMTU 65535
OPENVSWITCH ADDR绵阳NMODE EUI64 NUMTXQUEUES 1 NUMRXQUEUES 1 GSO_MAX_SIZE 65536 GSO_MAX_SEGS 65535
OVN-K8S-MP0是一个OVS桥吗？
从下面的命令输出可以清楚看到，OVN-K8S-MP0不是一个OVS桥。工作节点上存在的只有两个桥:BR-EX和BR-INT
[ROOT@OCP-412-OVN-WORKER-1 CORE]# OVS-VSCTL LIST-BR
BR-EX
BR-INT所以OVN-K8S-MP0是一个OVS端口。我们需要找出拥有这个端口的OVS桥。
从下面的命令输出可以清楚看到，OVN-K8S-MP0不是桥BR-EX的OVS端口。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# OVS-OFCTL DUMP-PORTS BR-EX OVN-K8S-MP0
OVS-OFCTL: BR-EX: UNKNOWN PORT `OVN-K8S-MP0`
从下面的命令输出可以清楚看到，OVN-K8S-MP0是一个OVS桥BR-INT的端口。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# OVS-OFCTL DUMP-PORTS BR-INT OVN-K8S-MP0
OFPST_PORT REPLY (XID=0X4): 1 PORTS
PORT "OVN-K8S-MP0": RX PKTS=1798208, BYTES=665641420, DROP=2, ERRS=0, FRAME=0, OVER=0, CRC=0TX PKTS=2614471, BYTES=1357528110, DROP=0, ERRS=0, COLL=0
总结一下，OVN-K8S-MP0是一个BR-INT** OVS桥上的端口。它也持有桥的IP，即**10.132.2.2/23
现在，让我们获取POD的网络配置详细信息。
必须知道POD网络命名空间才能确定POD网络详细信息。下面的命令通过IP找到POD网络命名空间。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# POD_IP=10.132.2.46; FOR NS IN $(IP NETNS LS | CUT -F 1 -D " "); DO IP NETNS EXEC $NS IP A | GREP -Q $POD_IP; STATUS=$?; [ $STATUS -EQ 0 ] && ECHO "POD NAMESPACE: $NS" ; DONE
POD NAMESPACE: C16C7A01-1BC5-474A-9EB6-15474B5FBF04
一旦知道了POD网络命名空间，就可以找到POD的网络配置详细信息，如下所示。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# NS=C16C7A01–1BC5–474A-9EB6–15474B5FBF04
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP NETNS EXEC $NS IP A
1: LO: <LOOPBACK,UP,LOWER_UP> MTU 65536 QDISC NOQUEUE STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/LOOPBACK 00:00:00:00:00:00 BRD 00:00:00:00:00:00
INET 127.0.0.1/8 SCOPE HOST LO
VALID_LFT FOREVER PREFERRED_LFT FOREVER
INET6 ::1/128 SCOPE HOST
VALID_LFT FOREVER PREFERRED_LFT FOREVER
2: ETH0@IF4256: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1400 QDISC NOQUEUE STATE UP GROUP DEFAULT QLEN 1000
LINK/ETHER 0A:58:0A:84:02:2E BRD FF:FF:FF:FF:FF:FF LINK-NETNS 59E250F6–0491–4FF4-BB22-BAA3BCA249F6
INET 10.132.2.46/23 BRD 10.132.3.255 SCOPE GLOBAL ETH0
VALID_LFT FOREVER PREFERRED_LFT FOREVER
INET6 FE80::858:AFF:FE84:22E/64 SCOPE LINK
VALID_LFT FOREVER PREFERRED_LFT FOREVER
4257: VXLAN1@IF4257: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 QDISC NOQUEUE STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/ETHER CA:40:81:86:FA:73 BRD FF:FF:FF:FF:FF:FF LINK-NETNS 59E250F6–0491–4FF4-BB22-BAA3BCA249F6
INET6 FE80::C840:81FF:FE86:FA73/64 SCOPE LINK
VALID_LFT FOREVER PREFERRED_LFT FOREVER
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP NETNS EXEC $NS IP R
DEFAULT VIA 10.132.2.1 DEV ETH0
10.132.2.0/23 DEV ETH0 PROTO KERNEL SCOPE LINK SRC 10.132.2.46
所以ETH0@IF4256是POD的主网络接口。
让我们获取ETH0设备的详细信息。
从下面的输出可以看出，POD网络命名空间中的ETH0设备是一个VETH设备。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP NETNS EXEC $NS IP -D LI SH DEV ETH0
LINK/ETHER 0A:58:0A:84:02:2E BRD FF:FF:FF:FF:FF:FF LINK-NETNS 59E250F6–0491–4FF4-BB22-BAA3BCA249F6
VETH ADDR绵阳NMODE EUI64 NUMTXQUEUES 8 NUMRXQUEUES 8 GSO_MAX_SIZE 65536 GSO_MAX_SEGS 65535 TSO_MAX_SIZE 524280 TSO_MAX_SEGS 65535 GRO_MAX_SIZE 65536众所周知VETH设备以对的形式工作；一端在INIT(或ROOT)命名空间中，另一端在(POD)网络命名空间中。
让我们在INIT命名空间中找到POD对应的VETH设备对。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP A | GREP -A1 ^4256
4256: 8B7266486EA2861@IF2: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1400 QDISC NOQUEUE MASTER OVS-SYSTEM STATE UP GROUP DEFAULT
LINK/ETHER DE:FB:3E:87:0F:D6 BRD FF:FF:FF:FF:FF:FF LINK-NETNS C16C7A01–1BC5–474A-9EB6–15474B5FBF04所以，8B7266486EA2861@IF2是INIT命名空间中的PODVETH设备端点。这个VETH对连接了INIT和POD网络命名空间。
让我们找出VETH设备端点的详细信息。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP -D LI SH DEV 8B7266486EA2861
4256: 8B7266486EA2861@IF2: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1400 QDISC NOQUEUE MASTER OVS-SYSTEM STATE UP MODE DEFAULT GROUP DEFAULT
LINK/ETHER DE:FB:3E:87:0F:D6 BRD FF:FF:FF:FF:FF:FF LINK-NETNS C16C7A01–1BC5–474A-9EB6–15474B5FBF04 PROMISCUITY 1 MINMTU 68 MAXMTU 65535
VETH
OPENVSWITCH_SLAVE ADDR绵阳NMODE EUI64 NUMTXQUEUES 4 NUMRXQUEUES 4 GSO_MAX_SIZE 65536 GSO_MAX_SEGS 65535所以8B7266486EA2861@IF2是一个OVS实体。转储OVS交换机详细信息将提供哪个OVS桥拥有此端口的详细信息。
如下输出所示，桥BR-INT拥有这个端口。
注意，使用OVS-VSCTL命令是之前OVS-OFCTL DUMP-PORTS <BRID绵阳> <PORT>命令的另一种选择。这是为了展示不同的命令可以帮助探索网络拓扑结构。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# OVS-VSCTL SHOW
[SNAP]
BRID绵阳 BR-INT
FAIL_MODE: SECURE
DATAPATH_TYPE: SYSTEM
[SNIP]
PORT "8B7266486EA2861"
INTERFACE "8B7266486EA2861"
[SNAP]
所以BR-INT拥有在INIT命名空间中具有PODVETH端点的端口。回想一下，它还持有OVN-K8S-MP0端口。
让我们也获取POD的VXLAN详细信息。
如下输出所示，VXLAN隧道的远端点是IP192.168.10.201。这是POD虚拟机的IP。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP NETNS EXEC $NS IP -D LI SH DEV VXLAN1
4257: VXLAN1@IF4257: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 QDISC NOQUEUE STATE UNKNOWN MODE DEFAULT GROUP DEFAULT QLEN 1000
LINK/ETHER CA:40:81:86:FA:73 BRD FF:FF:FF:FF:FF:FF LINK-NETNS 59E250F6–0491–4FF4-BB22-BAA3BCA249F6 PROMISCUITY 0 MINMTU 68 MAXMTU 65535
VXLAN ID 555005 REMOTE 192.168.10.201 SRCPORT 0 0 德州PORT 4789 NOLEARNING TTL AUTO A绵阳ING 300 UDPCSUM NOUDP6ZE永新SUMTX NOUDP6ZE永新SUMRX ADDR绵阳NMODE EUI64 NUMTXQUEUES 1 NUMRXQUEUES 1 GSO_MAX_SIZE 65536 GSO_MAX_SEGS 65535一个浮现的问题是数据包如何从ETH0接口发送到VXLAN1接口。
这是通过在网络命名空间中设置LINUX流量控制(TC)在ETH0和VXLAN1之间镜像流量来实现的。这是从KATA容器的设计中已知的。然而，我认为在故障排除网络问题时检查TC配置是一种好的实践。
下面的输出显示了我环境中POD网络命名空间中设备配置的TC过滤器。
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP NETNS EXEC $NS TC FILTER SHOW DEV ETH0 ROOT
FILTER PARENT FFFF: PROTOCOL ALL PREF 49152 U32 CHAIN 0
FILTER PARENT FFFF: PROTOCOL ALL PREF 49152 U32 CHAIN 0 FH 800: HT PISOR 1
FILTER PARENT FFFF: PROTOCOL ALL PREF 49152 U32 CHAIN 0 FH 800::800 ORDER 2048 KEY HT 800 BKT 0 TERMINAL FLOWID NOT_IN_HW
MATCH 00000000/00000000 AT 0
ACTION ORDER 1: MIRRED (EGRESS REDIRECT TO DEVICE VXLAN1) STOLEN
INDEX 1 REF 1 BIND 1
[ROOT@OCP-412-OVN-WORKER-1 CORE]# IP NETNS EXEC $NS TC FILTER SHOW DEV VXLAN1 ROOT
FILTER PARENT FFFF: PROTOCOL ALL PREF 49152 U32 CHAIN 0
FILTER PARENT FFFF: PROTOCOL ALL PREF 49152 U32 CHAIN 0 FH 800: HT PISOR 1
FILTER PARENT FFFF: PROTOCOL ALL PREF 49152 U32 CHAIN 0 FH 800::800 ORDER 2048 KEY HT 800 BKT 0 TERMINAL FLOWID NOT_IN_HW
MATCH 00000000/00000000 AT 0
ACTION ORDER 1: MIRRED (EGRESS REDIRECT TO DEVICE ETH0) STOLEN
INDEX 2 REF 1 BIND 1
ETH0的出口被重定向到了VXLAN1，而VXLAN1的出口被重定向到了ETH0
有了所有这些细节，就可以为参考和进一步分析绘制工作节点网络拓扑图。拓扑结构如下图所示。
现在，让我们把重点转到POD虚拟机上。
请注意，POD虚拟机的设计是使用一个名为PODNS的固定POD网络命名空间。
以下输出显示了POD虚拟机的网络配置:
UBUNTU@PODVM-NGINX-PRIV-8B726648:/HOME/UBUNTU# IP A
1: LO: <LOOPBACK,UP,LOWER_UP> MTU 65536 QDISC NOQUEUE STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/LOOPBACK 00:00:00:00:00:00 BRD 00:00:00:00:00:00
INET 127.0.0.1/8 SCOPE HOST LO
VALID_LFT FOREVER PREFERRED_LFT FOREVER
INET6 ::1/128 SCOPE HOST
VALID_LFT FOREVER PREFERRED_LFT FOREVER
2: ENS2: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 QDISC FQ_CODEL STATE UP GROUP DEFAULT QLEN 1000
LINK/ETHER 52:54:00:E1:58:67 BRD FF:FF:FF:FF:FF:FF
INET 192.168.10.201/24 BRD 192.168.10.255 SCOPE GLOBAL DYNAMIC ENS2
VALID_LFT 2902SEC PREFERRED_LFT 2902SEC
INET6 FE80::5054:FF:FEE1:5867/64 SCOPE LINK
VALID_LFT FOREVER PREFERRED_LFT FOREVER
ROOT@PODVM-NGINX-PRIV-8B726648:/HOME/UBUNTU# IP R
DEFAULT VIA 192.168.10.1 DEV ENS2 PROTO DHCP SRC 192.168.10.201 METRIC 100
192.168.10.0/24 DEV ENS2 PROTO KERNEL SCOPE LINK SRC 192.168.10.201
192.168.10.1 DEV ENS2 PROTO DHCP SCOPE LINK SRC 192.168.10.201 METRIC 100
ROOT@PODVM-NGINX-PRIV-8B726648:/HOME/UBUNTU# IPTABLES -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
以下输出显示了PODNS网络命名空间内的网络配置。
ROOT@PODVM-NGINX-PRIV-8B726648:/HOME/UBUNTU# IP NETNS EXEC PODNS IP A
1: LO: <LOOPBACK,UP,LOWER_UP> MTU 65536 QDISC NOQUEUE STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/LOOPBACK 00:00:00:00:00:00 BRD 00:00:00:00:00:00
INET 127.0.0.1/8 SCOPE HOST LO
VALID_LFT FOREVER PREFERRED_LFT FOREVER
INET6 ::1/128 SCOPE HOST
VALID_LFT FOREVER PREFERRED_LFT FOREVER
3: VXLAN0@IF3: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1400 QDISC NOQUEUE STATE UNKNOWN GROUP DEFAULT QLEN 1000
LINK/ETHER 7E:E5:F7:E6:F5:1A BRD FF:FF:FF:FF:FF:FF LINK-NETNSID 0
INET 10.132.2.46/23 BRD 10.132.3.255 SCOPE GLOBAL VXLAN0
VALID_LFT FOREVER PREFERRED_LFT FOREVER
INET6 FE80::7CE5:F7FF:FEE6:F51A/64 SCOPE LINK
VALID_LFT FOREVER PREFERRED_LFT FOREVER
ROOT@PODVM-NGINX-PRIV-8B726648:/HOME/UBUNTU# IP NETNS EXEC PODNS IP R
DEFAULT VIA 10.132.2.1 DEV VXLAN0
10.132.2.0/23 DEV VXLAN0 PROTO KERNEL SCOPE LINK SRC 10.132.2.46
ROOT@PODVM-NGINX-36590CCC:/HOME/UBUNTU# IP NETNS EXEC PODNS IP -D LI SH VXLAN0
3: VXLAN0@IF3: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1400 QDISC NOQUEUE STATE UNKNOWN MODE DEFAULT GROUP DEFAULT QLEN 1000
LINK/ETHER 7E:E5:F7:E6:F5:1A BRD FF:FF:FF:FF:FF:FF LINK-NETNSID 0 PROMISCUITY 0 MINMTU 68 MAXMTU 65535
VXLAN ID 555005 REMOTE 192.168.10.163 SRCPORT 0 0 德州PORT 4789 NOLEARNING TTL AUTO A绵阳ING 300 UDPCSUM NOUDP6ZE永新SUMTX NOUDP6ZE永新SUMRX ADDR绵阳NMODE EUI64 NUMTXQUEUES 1 NUMRXQUEUES 1 GSO_MAX_SIZE 65536 GSO_MAX_SEGS 65535
ROOT@PODVM-NGINX-PRIV-8B726648:/HOME/UBUNTU# IP NETNS EXEC PODNS IPTABLES -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
VXLAN隧道设置看起来正常。它显示了远程端点IP 192.168.10.163，这是工作节点虚拟机的IP。
此外，POD虚拟机中没有防火墙规则。
但是，你没有看到像在工作节点上一样的VETH对。现在，浮现的一个问题是，没有VETH对，INIT和PODNS网络命名空间之间如何进行通信。请注意，物理设备在INIT(ROOT)命名空间中，VXLAN设备在PODNS网络命名空间中。
感谢STEFANO BRIVIO指出了使这种情况发生的LINUX内核提交。
COMMIT F01EC1C017DEAD42092997A2B8684FCAB4CBF126
AUTHOR: NICOLAS DICHTEL <NICOLAS.DICHTEL@6WIND.COM>
DATE: THU APR 24 10:02:49 2014 +0200
VXLAN: ADD X-NETNS SUPPORT
THIS PATCH ALLOWS TO SWITCH THE NETNS WHEN PACKET IS ENCAPSULATED OR
DECAPSULATED.
THE VXLAN SOCKET IS OPENNED INTO THE I/O NETNS, IE INTO THE NETNS WHERE
ENCAPSULATED PACKETS ARE RECEIVED. THE SOCKET 梅州 IS DONE INTO THIS NETNS TO
FIND THE CORRESPONDING VXLAN TUNNEL. AFTER DECAPSULATION, THE PACKET IS
INJECTING INTO THE CORRESPONDING INTERFACE WHICH MAY STAND TO ANOTHER NETNS.
WHEN ONE OF THE TWO NETNS IS REMOVED, THE TUNNEL IS DESTROYED.
CONFIGURATION EXAMPLE:
IP NETNS ADD NETNS1
IP NETNS EXEC NETNS1 IP LINK SET LO UP
IP LINK ADD VXLAN10 TYPE VXLAN ID 10 GROUP 239.0.0.10 DEV ETH0 德州PORT 0
IP LINK SET VXLAN10 NETNS NETNS1
IP NETNS EXEC NETNS1 IP ADDR ADD 192.168.0.249/24 BROADCAST 192.168.0.255 DEV VXLAN10
IP NETNS EXEC NETNS1 IP LINK SET VXLAN10 UP
这也有一个STACKOVERFLOW主题对此进行了解释。
这些细节为我们提供了对POD虚拟机网络拓扑的良好概述，如下图所示。
让我们在VXLAN0接口上运行TCPDUMP，看ICMP请求是否从工作节点接收。
如下输出所示，ICMP请求已接收，但没有响应。
ROOT@PODVM-NGINX-PRIV-8B726648:/HOME/UBUNTU# IP NETNS EXEC PODNS TCPDUMP -I VXLAN0 -S0 -N -VV
TCPDUMP: LISTENING ON VXLAN0, LINK-TYPE EN10MB (ETHERNET), CAPTURE SIZE 262144 BYTES
[SNIP]
10.132.2.2 > 10.132.2.46: ICMP ECHO REQUEST, ID 20, SEQ 1, LENGTH 64
10:34:17.389643 IP (TOS 0X0, TTL 64, ID 27606, OFFSET 0, FLAGS [DF], PROTO ICMP (1), LENGTH 84)
10.132.2.2 > 10.132.2.46: ICMP ECHO REQUEST, ID 20, SEQ 2, LENGTH 64
10:34:18.413682 IP (TOS 0X0, TTL 64, ID 27631, OFFSET 0, FLAGS [DF], PROTO ICMP (1), LENGTH 84)
10.132.2.2 > 10.132.2.46: ICMP ECHO REQUEST, ID 20, SEQ 3, LENGTH 64
10:34:19.002837 IP (TOS 0X0, TTL 1, ID 28098, OFFSET 0, FLAGS [DF], PROTO UDP (17), LENGTH 69)
[SNIP]
现在，让我们总结一下情况。
通过这个练习，你对工作节点和POD虚拟机的网络拓扑有了很好的理解，隧道的设置看起来也没有问题。你也看到ICMP数据包被POD虚拟机接收，没有软件防火墙阻止数据包。那么下一步该做什么?
继续阅读以了解下一步该做什么:-)
故障排查 – 第二阶段
我使用WIRESHARK分析了来自工作正常(常规KATA)设置的TCPDUMP捕获。WIRESHARK图形界面可以方便地理解通过TCPDUMP捕获的网络跟踪。
在跟踪中没有观察到ARP请求和响应。但是，工作节点上的ARP表被填充，ARP表使用POD网络命名空间中的ETH0设备的MAC(在工作节点上)，而不是POD虚拟机上的PODNS命名空间中的VXLAN0设备的MAC。
? (10.132.2.46) AT 0A:58:0A:84:02:2E [ETHER] ON OVN-K8S-MP0
0A:58:0A:84:02:2E是工作节点上POD网络命名空间中ETH0接口的MAC，而7E:E5:F7:E6:F5:1A是POD虚拟机上PODNS命名空间中的VXLAN0接口的MAC。
这是问题的原因 – 从工作节点无法访问POD IP。ARP条目应指向POD虚拟机上PODNS命名空间中的VXLAN0设备的MAC(即7E:E5:F7:E6:F5:1A)。
事后看来，我本该首先查看ARP表条目。下次遇到类似问题我一定会这么做;)
解决方案
STEFANO BRIVIO的一个小技巧解决了这个问题。在POD虚拟机的VXLAN0接口上使用与工作节点上POD的ETH0接口相同的MAC地址可以解决连接问题。
IP NETNS EXEC PODNS IP LINK SET VXLAN0 DOWN
IP NETNS EXEC PODNS IP LINK SET DEV VXLAN0 ADDRESS 0A:58:0A:84:02:2E
IP NETNS EXEC PODNS IP LINK SET VXLAN0 UP
最终的网络拓扑结构如下所示。
结论
调试KUBERNETES集群中的网络问题并非易事。然而，通过明确的方法、专家的帮助和公开可用的资料，找到根本原因和修复问题是可能的。在这个过程中获得乐趣并掌握知识。
我希望这篇文章对你有帮助。
以下是在我的故障排除练习中非常有用的参考资料列表:
- HTTPS://LEARNK8S.IO/KUBERNETES-NETWORK-PACKETS
- HTTPS://PRO章丘MER.HELP/BLOGS/PRACTICE-VXLAN-UNDER-LINUX.HTML
- HTTPS://WWW.MAN7.ORG/LINUX/MAN-PA绵阳S/MAN7/OVN-ARCHITECTURE.7.HTML
- HTTPS://DEVELOPERS.REDHAT.COM/ARTICLES/2022/04/06/INTRODUCTION-LINUX-BRIDGING-COMMANDS-AND-FEATURES#VLAN_TUNNEL_MAPPING
- HTTPS://WWW.TKNG.IO/CNI/FLANNEL/
- HTTPS://ACCESS.REDHAT.COM/DOCUMENTATION/EN-US/OPENSHIFT_CONTAINER_PLATFORM/3.4/HTML/CLUSTER_ADMINISTRATION/ADMIN-GUIDE-SDN-TROUBLESHOOTING#DEBUGGING-LOCAL-NETWOR四平
4.阿里云全线产品突发史诗级故障，官方披露故障原因
【阿里巴巴旗下多款产品疑似瘫痪】近日，淘宝、闲鱼、阿里云盘、钉钉等阿里巴巴旗下的多款产品遭遇了一场故障，用户反映无法正常操作。消息一经曝光，立即引起了广泛的关注和讨论。截至2023年11月12日17:44，阿里云的控制台访问和API调用出现了异常，阿里云工程师正在紧急处理中。这次故障牵涉到了多个受影响的产品，包括企业级分布式应用服务、消息队列MQ、微服务引擎、链路追踪、应用高可用服务等。此外，还有智能推荐AIREC、智能开放搜索OPENSEARCH、云行情、数据总线DATAHUB等产品也受到了影响。对于阿里云来说，这绝非一个小问题。阿里云工程师正在全力以赴排查故障，并尽快恢复正常运行。然而，故障的原因以及解决方案目前尚未得出。对于依赖这些产品的用户来说，这无疑是一次巨大的挑战。因为他们可能无法正常购物、交流、存储数据等，这对于个人用户和企业用户来说都是致命的。
对于阿里巴巴来说，此次故障不仅是一次技术挑战，更是一次声誉挑战。作为中国最大的电商平台和云计算服务商，阿里巴巴的稳定性和可靠性一直是其核心竞争力之一。然而，这次故障的发生让用户对阿里巴巴的服务产生了质疑，也引发了公众对于大型互联网企业的信任危机。在这个数字化汕尾，互联网已经成为人们生活中不可或缺的一部分。这次阿里巴巴产品故障的发生再次提醒我们，即便是大型企业也难以避免技术故障的发生。因此，我们不能完全依赖于互联网，而是要保持对于传统方式的依赖和应对能力。总之，阿里巴巴产品故障事件给我们敲响了警钟，提醒我们在数字化汕尾也要保持对传统方式的依赖和防备意识。对于大型互联网企业而言，提高服务的稳定性和可靠性是至关重要的。只有这样，才能赢得用户的信任和口碑。那么，你对于此次阿里巴巴产品故障事件有什么看法？你认为大型企业应该如何应对类似的挑战？请留言分享你的观点。
标题：探索云计算汕尾的多元化应用场景引言：随着云计算技术的飞速发展，越来越多的企业开始将业务迁移到云端。而在云计算汕尾，各种多元化的应用场景也随之出现，为企业提供了更加灵活、高效的解决方案。本文将针对云计算的多种应用场景进行介绍和探讨，让您对云计算的多样性有更深入的了解。第一部分：存储与安全在云计算汕尾，数据存储和安全成为了企业关注的重点。储网关、文件存储 HDFS 版、块存储等各种存储服务可提供灵活、可扩展的数据存储方案。而混合云备份服务、密钥管理服务、云防火墙、数据库审计、加密服务等安全服务则可以保障数据的安全性和可靠性。第二部分：云计算的多样化应用除了存储和安全，云计算在各个领域都有着广泛的应用。运维安全中心（堡垒机）可以提供安全可控的运维管理解决方案。容器镜像服务、容器服务KUBERNETES版等容器相关服务则为企业提供了更加灵活、高效的应用部署和管理方式。
API 网关、资源编排等服务则可以实现不同系统之间的数据交互和资源管理。第三部分：数据库与数据分析在云计算汕尾，数据库和数据分析也得到了极大的发展。云原生数据仓库 ANALYTICDB POSTGRESQL版、图数据库、云原生内存数据库TAIR等数据库服务可以满足企业不同的数据存储和分析需求。同时，云数据库 REDIS 版、云原生关系型数据库 POLARDB等也提供了高性能、可扩展的数据库解决方案。第四部分：网络与通信在云计算汕尾，网络和通信也发生了巨大的变化。物联网平台、NAT网关、负载均衡等服务可以实现设备之间的连接和数据传输。私网连接、高速通道、IPV6 网关等网络服务则提供了更加安全、高效的网络连接方式。而专有网络VPC、云企业网等服务则可以实现企业内部网络的构建和管理。第五部分：弹性计算与人工智能在云计算汕尾，弹性计算和人工智能也成为了热门话题。
FPGA 云服务器、超级计算集群、批量计算等弹性计算服务可以实现快速、高效的计算能力扩展。而无影云桌面和人工智能相关服务则提供了智能化的办公和业务处理方式。总结：云计算汕尾带来了各种多元化的应用场景，从存储与安全、云计算的多样化应用、数据库与数据分析、网络与通信，到弹性计算与人工智能，都为企业提供了更加灵活、高效的解决方案。在面对这些多样化的应用场景时，企业需要根据自身需求选择合适的云计算服务，以提升业务的竞争力和创新能力。问题：您对云计算的多元化应用场景有何看法？在您的行业中，您认为云计算能够给企业带来哪些好处？防城港头条致力于为用户打造强大且多样化的云计算服务。无论是面向小型企业还是大型企业，我们都提供了一系列全面的云计算解决方案。其中包括弹性伸缩、弹性容器实例、弹性裸葫芦岛属服务器、云服务器ECS、轻量应用服务器等等。
这些服务不仅可以帮助企业提高效率，节省成本，还可以提供高性能计算和灵活的资源管理能力。除了基础的云计算服务，防城港头条还提供了一系列智能计算服务。比如函数计算，可以帮助开发人员轻松构建SERVERLESS应用；SERVERLESS应用引擎，可以帮助企业快速构建和部署应用；云托付，可以提供专有宿主机来满足企业的特定需求；GPU云服务器，可以提供强大的计算能力来支持图形处理和人工智能等应用。除了云计算服务，防城港头条还提供了一系列运维和客服相关的服务。比如运维编排，可以帮助企业实现自动化的运维管理；智能计算灵骏，可以帮助企业实时监控和管理云端资源；云呼叫中心，可以提供全面的客户服务解决方案；视觉智能开放平台，可以帮助企业实现图像识别和分析等功能。此外，防城港头条还提供了一系列与通信和数据管理相关的服务。
比如短信服务，可以帮助企业实现短信发送和接收的功能；云解析DNS，可以帮助企业管理域名解析；号码认证服务，可以帮助企业验证用户的手机号码；邮件推送，可以帮助企业实现邮件发送和接收的功能。当然，防城港头条也关注数据安全和内容安全。我们提供了一系列安全服务，包括安全管家、应用身份服务、实人认证、数字证书管理服务、风险识别、WEB应用防火墙等。这些服务可以帮助企业保护数据安全和网络安全，防止各种安全威胁。总而言之，防城港头条为企业提供了全面的云计算解决方案，涵盖了面向小型企业和大型企业的各种需求。我们相信通过我们的服务，企业可以获得更高效、更安全、更灵活的云计算体验。您对于云计算服务有什么看法和建议呢？你认为未来云计算会有怎样的发展趋势？欢迎留言评论。
物联网无线连接服务、CDN、云数据传输、数据语音、智能接入网关、全站加速、CHATAPP 消息、全球加速、安全加速 SCDN、边缘节点服务 ENS、访问控制、资源管理、云监控、配置审计；。这些都是百色互联网技术中不可或缺的部分，它们为我们的日常生活和工作提供了便利和便捷性。然而，最近阿里云服务出现了故障，影响到了许多地区，包括华北2（北京）、华北6（乌兰察布）、华北1（青岛）、华东2（上海）、华南2（河源）等地。这让我们不禁思考，百色科技是否真的可靠？我们是否可以依赖云计算和物联网技术来为我们提供持续的服务？根据阿里云官方的回应，故障原因与某个底层服务组件有关，工程师正在紧急处理中。但是，这个问题引发了我们对于互联网服务的依赖和安全性的思考。我们是否过分依赖互联网技术，而忽视了其可能存在的风险和漏洞？在这个信息爆炸的汕尾，我们需要拥抱技术的进步，但同时也需要保持警惕。
我们应该多关注和学习互联网技术的原理和运作方式，以便更好地理解和应对可能发生的故障和问题。作为普焦作户，我们应该保持对于互联网服务商的警惕和选择。我们应该选择那些有良好声誉和可靠的服务商，并且定期备份重要的数据，以防止意外情况的发生。同时，作为互联网行业的从业者，我们也需要不断努力提高自己的技术水平和服务质量，以确保我们能够为用户提供稳定、可靠的服务。总之，互联网技术的进步给我们带来了巨大的便利，但同时也伴随着一些风险。我们需要保持警惕和学习，以应对可能发生的问题。只有这样，我们才能更好地享受互联网科技带来的便利。你怎么看待互联网技术的不可靠性？你对于互联网服务商有什么要求和建议？请留下你的评论。【抢先报道】今晚恢复服务，异常情况逐步解决！随着18:54的钟声，备受关注的杭州、北京等地域的控制台和API服务已经恢复了。那么，这到底是怎么回事呢？
请跟随小编的脚步，一起来揭秘背后的故事！故障发生后，工程师们丝毫不敢掉以轻心，他们付出了不懈的努力。经过分批重启组件服务，绝大部分地域的控制台和API服务已经顺利恢复运行。紧接着，异常管控服务组件也顺利完成了重启，除了个别云产品还需要进一步处理外，其余的云产品控制台和API服务都已恢复。时间来到20:12，消息队列MQ在北京、杭州等地域也完成了重启，其他地域也在逐步恢复中。最终，在21:11的时候，受影响的云产品正式恢复了服务，不过由于故障的影响，部分云产品的数据可能会有一些延迟。这次故障主要影响了云产品控制台、管控API等功能，但幸运的是，大部分产品的实际运行并没有受到影响。不过，像OSS、OTS、SLS、MNS等产品的服务却受到了影响。小编在此希望大家能够理解并给予支持，毕竟技术故障是无法完全避免的。好消息接踵而至！不光是故障解决了，还有一个特别的消息要和大家分享。
XCOPS智能运维管理人年会正在火热报名中！如果你对这个话题感兴趣，那就点击下方的链接，了解详情吧！【总结回顾】今晚恢复服务，异常情况逐步解决。通过工程师们的不懈努力，大部分地域的控制台和API服务已经顺利恢复。虽然故障主要影响了云产品控制台和管控API等功能，但是大部分产品的实际运行并没有受到影响。不过，一些云产品的服务仍然受到了影响，并可能会有一些数据延迟。希望大家能够理解并给予支持。另外，XCOPS智能运维管理人年会正在报名中，快来了解一下吧！【观点建议】在技术发展日新月异的今天，故障是难以避免的，但是我们要对工程师们的努力和付出表示肯定与感谢。他们在第一时间投入到故障的解决中，并且通过不懈的努力，使得大部分用户的服务得以恢复。对于受到影响的用户，我们也要理解并给予支持。同时，我们也要认识到技术发展的风险与挑战，不断提升自身的技术能力，以应对可能出现的故障。
最后，希望类似的故障不再发生，技术工程师们能够继续努力，为用户提供更加稳定可靠的服务。【问题引导】你对技术故障如何看待？对于故障处理的方式有什么建议？你对XCOPS智能运维管理人年会感兴趣吗？欢迎留下你的观点和建议，与我们一起讨论！
