Kubernetes(k8s) 网络策略及排错

k8s 网络策略

  • k8s 网络策略采用了比较严格的单向控制
  • {} 表示允许所有,[] 表示拒绝所有
# 所有pod允许所有流量进入
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
	podSelector: {}
	ingress:
	- {}
---

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
	# 筛选 pod 应用下面规则
  podSelector:
    matchLabels:
      role: db
  policyTypes:  # 不写,默认为 Ingress
  - Ingress
  - Egress
  # 管理进入流量 下面的规则都是独立的 不是和的关系
  ingress:
  - from:
    - ipBlock: # 在此ip范围,但不包含172.17.1.0/24的ip可与上述筛选的pod的80端口建立连接
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector: # 符合条件的 namespace 可与上述 pod 的 80 端口建立 tcp 连接
        matchLabels:
          project: myproject
    - podSelector: # default namespace 下,满足条件的 pod 可与上述 pod 建立连接 80 tcp
        matchLabels:
          role: frontend
  - ports:
    - protocol: TCP
      port: 80 # 指的是筛选出的 pod 端口
  # 管理出去流量
  egress:
  - to:
    - ipBlock:  # 允许上述筛选出的 pod 访问网段为 10.0.0.0/24 的 5978 端口
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978  # 指的是目的端口

k8s 网络故障定位指南

IP 转发和桥接

linux 内核设置低级别的集群 IP 负载均衡,除了 iptables 和 IPVS,还需要用到两个关键的模块:IP转发(IP forward)和桥接

IP 转发

  • 是一种内核态设置,允许将一个接口的流量转发到另一个接口
  • 该配置是内核将流量从容器路由到外部所必需的
  • 没有启动的话,会出现网络访问失败的情况。如,访问 Pod 服务连接超时
# 检查 ipv4 forwarding 是否开启
sysctl net.ipv4.ip_forward
# 0 意味着未开启
net.ipv4.ip_forward = 0

# 进行修复
sysctl -w net.ipv4.ip_forward=1
echo net.ipv4.ip_forward=1 >> /etc/sysconf.d/10-ipv4-forwarding-on.conf
# 验证并生效
sysctl -p

桥接

  • k8s 通过 bridge-netfilter 配置使 iptables 规则应用在 linux 网桥上
  • 该配置对内核进行宿主机和容器之间数据包的地址转换是必需的
  • 否则,Pod 进行外部服务网络请求使会出现,目标主机不可达或连接拒绝等错误
# 检查 bridge netfilter 是否开启
sysctl net.bridge.bridge-nf-call-iptables
# 0 表示未开启
net.bridge.bridge-nf-call-iptables = 0

# 开启这个 iptables 配置
sysctl -w net.bridge.bridge-nf-call-iptables=1
echo net.bridge.bridge-nf-call-iptables=1 >> /etc/sysconf.d/10-bridhe-nf-call-iptables.conf
sysctl -p

##Pod CIDR 冲突

  • 容器与容器之间通信建立了一层特殊的 overlay 网络(虚拟ip)
  • 若 Pod 子网和宿主机网络出现冲突是,就会产生问题,导致无法访问
  • 将主机 IP 范围和 API Server 中指定的子网进行比较
  • 可在 CNI 插件 或 kubelet 的 pod-cidr 参数中指定 IP 地址范围,避免冲突

hairpin

  • 就是 自己访问自己
  • 有时 Pod 无法通过 Service IP 访问自己,这就有可能是 hairpin 的配置问题了
  • 通常,当 kube-proxy 以 iptables 或 IPVS 模式运行,并且 Pod 与桥接网络连接时,就会发生这种情况
  • kubelet 的启动参数提供了一个 --hairpin-mode 标志,支持的值有 hairpin-veth 和 promiscuous-bridge
  • –hairpin-mode 被 kubelet 设置成 hairpin-veth 并且生效后,底层其实是在修改宿主机 /sys/devices/virtual/net 目录下设备文件 hairpin_mode de 值
# 查看是否修改成功
for intf in /sys/devices/virtual/net/cbr0/brif/; do cat $intf/hairpin_mode; done

查看 pod ip 地址

# 从外面看
kubectl get pod
kubectl describe pod

# 进入容器查看 假设Pod的pause容器名称为abc
# 获得容器 id 假设结果返回32166
docker inspect abc --format '{{ .State.Pid}}'
# 进入容器查看 
nsenter --target 32166 --net
ip addr

故障排查工具

  1. tcpdump 捕获网络流量

  2. 容器镜像内置常用网络工具

    • FROM library/python:3.3
      RUN apt-get update && apt-get -y install iptoute2 net-tools ethtool nano
      

为什么不推荐使用SNAT

  • 因为内核需要修改源地址和端口,并记录到表中,并发多时,会导致记录覆盖,因此产生丢包
  • SNAT导致内核丢包原因在于其conntrack的实现
  • 容器端口映射到主机端口,会从上次分配的主机端口,向下顺次搜索,返回可用端口,当高并发时,可能将一个端口返回给多个容器,并记录到了表中,导致之后的丢包
  • 因此之后产生了随机探测宿主机可用端口,来避免冲突,缓解此问题
    • NF_NAT_RANGE_PROTO_RANDOM 部分随机
    • NF_NAT_RANGE_PROTO_RANDOM_FULLY 完全随机
    • iptables 已经支持 --random-fully 这个 flag
  • 虽然缓解了此问题,但不表示根治,因此不推荐生产环境上使用 NodePort
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值