阿里云首页

应急预案:敏捷标准版V3.5.0环境中由于iptables规则缺失导致后端SVC或Ingress不通的应急处理方法

1. 概述

本文主要介绍由于iptables条目缺失,导致后端SVC或Ingress不通的应急处理方法。

1.1. 适用范围

  • 敏捷标准版V3.5.0

1.2. 用户告知

  • 适用平台:x86
  • 授权级别:L3(产品研发工程师)
  • 临时或固化方案:临时
  • 操作复杂度:中
  • 预估执行时长:20分钟
  • 业务影响:是
  • 风险等级:低

2. 问题描述

由于iptables条目缺失,导致后端NodePort、LoadBalancer或Ingress不通,无法正常访问。

3. 解决方案

3.1. 环境检查

检查nat和raw表中规则是否缺失

  1. 登录Master节点,执行以下命令,检查环境中使用的网络插件是否为rama。
    kubectl get pod -n kube-system | grep rama 
    系统显示类似如下。
  2. 执行以下命令,查看所有subnet的CIDR。
    kubectl get subnet
    系统显示类似如下。
  3. 使用ping命令测试与CIDR对应的网关的连通性,并依次执行以下命令,查看iptables规则。
    iptables -t raw -S | grep RAMA-NODEPORT-BYPASS
    iptables -t nat -S | grep RAMA-NODEPORT-BYPASS
    系统显示类似如下,规则中的IP地址段对应上一步找到的subnet,可以与正常机器上的规则进行比对。每个subnet(CIDR)对应一条规则,以下nat和raw表中显示的规则一条都不能少。

  4. 如果经过以上前置排查没有异常,则不适用本方案,如果发现条目缺失,则需要按照以下方法进一步排查:

NodePort不通

  1. NodePort Service的目标IP可以是K8s集群中任一Node的IP地址,NodePort Service目标Port必须是K8s设置的端口范围中的端口,默认端口范围是3000~32767,目前专有云的场景都选择默认的端口范围。通过执行以下命令,进行确定NodePort。
    kubectl get svc [$Service_Name] -n [$Namespace]
    说明
    • [$Service_Name]为服务名。
    • [$Namespace]为Namespace。
    系统显示类似如下。
  2. 执行以下命令,确认RAMA版本。
    docker images | grep rama-daemon
    系统显示类似如下,rama-daemon的镜像版本V1.2.12即为rama-daemon的版本。

    • 小于等于V1.2.12版本
      1. 执行以下命令,查看所有subnet的CIDR,确认CIDR对应的网关可以ping通。
        kubectl get subnet
        系统显示类似如下。
      2. 登录到要访问的Node上,执行以下命令,查看iptables规则。
        iptables -t raw -S | grep RAMA-NODEPORT-BYPASS
        iptables -t nat -S | grep RAMA-NODEPORT-BYPASS
        系统显示类似如下,规则中的IP地址段对应上一步找到的subnet,每个subnet(CIDR)对应一条规则,以下nat和raw表中显示的规则一条都不能少。

        说明:也可以找其他正常机器进行比对,目前rama在各个机器配置的iptables规则都是相同的,直接比对差异,即可知道少了那一条规则。
    • 大于V1.2.12版本
      1. 执行以下命令,查看所有subnet的CIDR,确认CIDR对应的网关可以ping通。
        kubectl get subnet
      2. 登录到要访问的Node上,执行以下命令,查看iptables规则。
        iptables -t raw -S | grep RAMA-NODEPORT-BYPASS
        iptables -t raw -S | grep "mac+"
        iptables -t nat -S | grep RAMA-NODEPORT-BYPASS
        系统显示类似如下,规则中的IP地址段对应上边找到的subnet,以下显示的规则一条都不能少。


LoadBalancer不通

  1. 执行以下命令,确认LoadBalancer的信息是否正确。
    kubectl get svc [$Service_Name] -n [$Namespace]
    系统显示类似如下。

    LoadBalancer类型的Service一般会显示两个IP地址,一个是CLUSER-IP,集群内访问使用,访问路径和ClusterIP完全相同,另外一个是EXTERNAL-IP,一般是集群外访问,但是集群内也可以访问,如果是集群内访问,请参见集群内访问,如果是集群外访问,请参见集群外访问。
    • 集群内访问:与NodePort的排查方式相同,请参见NodePort不通
    • 集群外访问:集群外访问一般是通过MiniLVS、SLB或者外挂的第三方负载均衡器访问,如果是集群外访问出现问题,请从MiniLVS(敏捷版)、SLB(企业版)或者第三方的负载均衡器查起。

Ingress不通

Ingress主要提供外部的七层负载均衡,底层用了LoadBalancer Service,当然集群内可以访问,集群外也可以访问,目前Ingress底层用了四层的LoadBalancer Service,下面主要是排除四层的问题:

  1. 执行以下命令,确定ingress信息。
    kubectl get ingress [$Ingress_Name]
    说明:[$Ingress_Name]为Ingress的名称。
    系统显示类似如下。
  2. 在发起访问的地方使用telnet命令进行模拟,确认是否能通。
    telnet [$Ingress_VIP] [$Vport]
    说明
    • [$Ingress_VIP]:为ingress的VIP地址。
    • [$Vport]:为ingress的端口号。
    • 如果telnet能通,请继续排查。
    • 如果telnet不通,请参见LoadBalancer不通章节,排查LoadBalancer问题。
  3. 在发起访问的地方使用curl命令进行模拟,确认是否能通。
    curl [$Ingress_VIP]:[$Vport]
    • 如果telnet能通,但是curl不通,请参见LoadBalancer不通章节,排查LoadBalancer问题,如果LoadBalancer没有问题,请联系阿里云技术支持进行查看。
    • 如果curl能通,但是业务不通,请联系阿里云技术支持进行查看。

3.2. 实施步骤

如果在以上排查过程中发现缺少任意一条规则,应急恢复方式为手动增加这些iptables规则,方法如下:

  1. 先在其他Node上找到这些规则,比如丢失以下两条规则:
    -A RAMA-NODEPORT-BYPASS -s [$CIDR] -j ACCEPT
    -A RAMA-NODEPORT-BYPASS -s [$CIDR] -j ACCEPT
    说明:[$CIDR]是通过kubectl get subnet命令查询到的CIDR地址段。
  2. 直接登录到丢失规则的Node上,依次执行以下命令,添加规则。
    iptable -t nat -A RAMA-NODEPORT-BYPASS -s [$CIDR] -j ACCEPT
    iptable -t nat -A RAMA-NODEPORT-BYPASS -s [$CIDR] -j ACCEPT

3.3. 结果验证

在缺少iptables规则的Node节点上添加完成后,需要执行以下命令,进行验证,查看是否添加成功。将执行结果与其他正常Node上的规则进行对比,一致即可。

iptables -t nat -S | grep RAMA-NODEPORT-BYPASS

4. 回滚方案

无需回滚。

首页 应急预案:敏捷标准版V3.5.0环境中由于iptables规则缺失导致后端SVC或Ingress不通的应急处理方法