Kube-OVN子网

子网是 Kube-OVN 中的一个核心概念和基本使用单元,Kube-OVN 会以子网来组织 IP 和网络配置,每个 Namespace 可以归属于特定的子网, Namespace 下的 Pod 会自动从所属的子网中获取 IP 并共享子网的网络配置(CIDR,网关类型,访问控制,NAT控制等)。

在 Kube-OVN 中子网为一个全局的虚拟网络配置,同一个子网的地址可以分布在任意一个节点上
在这里插入图片描述

1. 默认子网

在 Overlay 模式下,默认子网使用了分布式网关并对出网流量进行 NAT 转换,其行为和 Flannel 的默认行为基本一致, 用户无需额外的配置即可使用到大部分的网络功能。

在 Underlay 模式下,默认子网使用物理网关作为出网网关,并开启 arping 检查网络连通性。

查看默认子网

默认子网 spec 中的 default 字段为 true,一个集群下只有一个默认子网,默认名为 ovn-default

# kubectl get subnet ovn-default -o yaml
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  creationTimestamp: "2019-08-06T09:33:43Z"
  generation: 1
  name: ovn-default
  resourceVersion: "1571334"
  selfLink: /apis/kubeovn.io/v1/subnets/ovn-default
  uid: 7e2451f8-fb44-4f7f-b3e0-cfd27f6fd5d6
spec:
  cidrBlock: 10.16.0.0/16
  default: true
  excludeIps:
  - 10.16.0.1
  gateway: 10.16.0.1
  gatewayType: distributed
  natOutgoing: true
  private: false
  protocol: IPv4

2. Join子网

在 Kubernetes 的网络规范中,要求 Node 可以和所有的 Pod 直接通信。 为了在 Overlay 网络模式下达到这个目的, Kube-OVN 创建了一个 join 子网, 并在每个 Node 节点创建了一块虚拟网卡 ovn0 接入 join 子网,通过该网络完成节点和 Pod 之间的网络互通。

查看join子网

子网默认名为 join 一般无需对该子网 CIDR 外的其他网络配置进行修改

# kubectl get subnet join -o yaml
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  creationTimestamp: "2019-08-06T09:33:43Z"
  generation: 1
  name: join
  resourceVersion: "1571333"
  selfLink: /apis/kubeovn.io/v1/subnets/join
  uid: 9c744810-c678-4d50-8a7d-b8ec12ef91b8
spec:
  cidrBlock: 100.64.0.0/16
  default: false
  excludeIps:
  - 100.64.0.1
  gateway: 100.64.0.1
  gatewayNode: ""
  gatewayType: ""
  natOutgoing: false
  private: false
  protocol: IPv4

在 node 节点查看 ovn0 网卡:

# ifconfig ovn0
ovn0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1420
        inet 100.64.0.4  netmask 255.255.0.0  broadcast 100.64.255.255
        inet6 fe80::800:ff:fe40:5  prefixlen 64  scopeid 0x20<link>
        ether 0a:00:00:40:00:05  txqueuelen 1000  (Ethernet)
        RX packets 18  bytes 1428 (1.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 19  bytes 1810 (1.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

3. 创建自定义子网

创建子网

cat <<EOF | kubectl create -f -
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: subnet1
spec:
  protocol: IPv4
  cidrBlock: 10.66.0.0/16
  excludeIps:
  - 10.66.0.1..10.66.0.10
  - 10.66.0.101..10.66.0.151
  gateway: 10.66.0.1
  gatewayType: distributed
  natOutgoing: true
  namespaces:
  - ns1
  - ns2
EOF

验证子网绑定生效

# kubectl create ns ns1
namespace/ns1 created

# kubectl run nginx --image=nginx:alpine -n ns1
deployment.apps/nginx created

# kubectl get pod -n ns1 -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
nginx-74d5899f46-n8wtg   1/1     Running   0          10s   10.66.0.11   node1   <none>           <none>

4. Overlay 子网网关配置

该功能只对 Overlay 模式子网生效,Underlay 类型子网访问外部网络需要借助底层物理网关。

Overlay 子网下的 Pod 需要通过网关来访问集群外部网络,Kube-OVN 目前支持两种类型的网关: 分布式网关和集中式网关,用户可以在子网中对网关的类型进行调整。

两种类型网关均支持 natOutgoing 设置,用户可以选择 Pod 访问外网时是否需要进行 snat。

分布式网关

子网的默认类型网关,每个 node 会作为当前 node 上 pod 访问外部网络的网关。 数据包会通过本机的 ovn0 网卡流入主机网络栈,再根据主机的路由规则进行出网。 当 natOutgoingtrue 时,Pod 访问外部网络将会使用当前所在宿主机的 IP。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GuzG6TZv-1670161299419)(assets/image-20221127201726-go3abfx.png)]

子网示例,其中 gatewayType 字段为 distributed

apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: distributed
spec:
  protocol: IPv4
  cidrBlock: 10.166.0.0/16
  default: false
  excludeIps:
  - 10.166.0.1
  gateway: 10.166.0.1
  gatewayType: distributed
  natOutgoing: true

集中式开关

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YKvgJctU-1670161299420)(assets/image-20221127201940-alarij2.png)]

子网内流量访问外网使用固定的 IP,以便审计和白名单等安全操作,可以在子网中设置网关类型为集中式网关。

在集中式网关模式下,Pod 访问外网的数据包会首先被路由到特定节点的 ovn0 网卡,再通过主机的路由规则进行出网。 当 natOutgoingtrue 时,Pod 访问外部网络将会使用特定宿主机的 IP。

子网示例,其中 gatewayType 字段为 centralizedgatewayNode 为特定机器在 Kubernetes 中的 NodeName。 其中 gatewayNode 字段可以为逗号分隔的多台主机。

apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: centralized
spec:
  protocol: IPv4
  cidrBlock: 10.166.0.0/16
  default: false
  excludeIps:
  - 10.166.0.1
  gateway: 10.166.0.1
  gatewayType: centralized
  gatewayNode: "node1,node2"
  natOutgoing: true
  • 集中式网关通过指定机器的特定网卡进行出网,gatewayNode 可更改为 kube-ovn-worker:172.18.0.2, kube-ovn-control-plane:172.18.0.3 格式。
  • 集中式网关默认为主备模式,只有主节点进行流量转发, 如果需要切换为 ECMP 模式,请参考集中式网关 ECMP 开启设置

5. 子网ACL设置

对于有细粒度 ACL 控制的场景,Kube-OVN 的 Subnet 提供了 ACL 规则的设置,可以实现网络规则的精细控制。

Subnet 中的 ACL 规则和 OVN 的 ACL 规则一致,相关字段内容可以参考 ovn-nb ACL Tablematch 字段支持的字段可参考 ovn-sb Logical Flow Table

允许 IP 地址为 10.10.0.2 的 Pod 访问所有地址,但不允许其他地址主动访问自己的 ACL 规则示例如下:

apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: acl
spec:
  acls:
    - action: drop
      direction: to-lport
      match: ip4.dst == 10.10.0.2 && ip
      priority: 1002
    - action: allow-related
      direction: from-lport
      match: ip4.src == 10.10.0.2 && ip
      priority: 1002
  cidrBlock: 10.10.0.0/24

6. 子网隔离设置

子网 ACL 的功能可以覆盖子网隔离的功能,并有更好的灵活性,我们推荐使用子网 ACL 来做相应的配置。

如需对子网间的访问进行控制,可以在子网 CRD 中将 private 设置为 true,则该子网将和其他子网以及外部网络隔离, 只能进行子网内部的通信。

如需开白名单,可以通过 allowSubnets 进行设置。allowSubnets 内的网段和该子网可以双向互访。

开启访问控制的子网示例

apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: private
spec:
  protocol: IPv4
  default: false
  namespaces:
  - ns1
  - ns2
  cidrBlock: 10.69.0.0/16
  private: true
  allowSubnets:
  - 10.16.0.0/16
  - 10.18.0.0/16

7. Underlay 相关选项

该部分功能只对 Underlay 类型子网生效

  • vlan: 如果使用 Underlay 网络,该字段用来控制该 Subnet 和哪个 Vlan CR 进行绑定。该选项默认为空字符串,即不使用 Underlay 网络。
  • logicalGateway: 一些 Underlay 环境为纯二层网络,不存在物理的三层网关。在这种情况下可以借助 OVN 本身的能力设置一个虚拟网关,将 Underlay 和 Overlay 网络打通。默认值为:false

8. 网关检查设置

默认情况下 kube-ovn-cni 在启动 Pod 后会使用 ICMP 或 ARP 协议请求网关并等待返回, 以验证网络工作正常,在部分 Underlay 环境网关无法响应 ARP 请求,或无需网络外部联通的场景 可以关闭网关检查。

apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: disable-gw-check
spec:
  disableGatewayCheck: true
### 关于 Kube-OVN `br-init` 配置及其初始化问题 #### 什么是 `br-init` 在 Kube-OVN 中,`br-init` 是指桥接网络接口的初始化过程。这一过程通常涉及创建 Open vSwitch (OVS) 桥梁并将其绑定到 Kubernetes 节点上。此桥梁用于支持 Pod 和 Service 的网络通信。 Kube-OVN 使用 OVS 来实现其 CNI 功能,因此正确配置和初始化 OVS 桥梁对于整个集群的正常运行至关重要[^1]。 --- #### 如何配置 `br-init` Kube-OVN 提供了一个默认的 OVS 桥名称 `ovn-k8s-br`,该名称可以通过修改配置文件中的参数来自定义。以下是与 `br-init` 相关的关键配置项: - **bridgeName**: 定义使用的 OVS 桥梁名称,默认为 `ovn-k8s-br`。 - **hybridOverlayBridge**: 如果启用了混合覆盖模式,则需要额外指定一个专用桥梁。 - **nodeNicCidr**: 设置节点 NIC CIDR 地址范围,这会影响如何分配 IP 给 Pods。 这些配置可以在 Kube-OVN 的 CRD 或者 YAML 文件中找到,并通过自定义资源对象进一步调整[^4]。 示例配置片段如下所示: ```yaml apiVersion: kubeovn.io/v1 kind: Network metadata: name: default spec: bridge: ovn-k8s-br # 自定义桥梁名 cidrBlock: 10.16.0.0/16 # 子网范围 ``` 如果遇到初始化失败的情况,可以尝试手动验证以下几点: 1. 确认目标节点是否存在对应的物理网卡设备; 2. 检查是否有冲突的现有 OVS 桥梁; 3. 查看日志输出以定位具体错误原因。 执行调试命令时可参考以下方法: ```bash # 显示当前系统的 OVS 桥梁状态 ovs-vsctl show # 手动添加测试用桥梁 sudo ovs-vsctl add-br test-br ``` 上述操作有助于排查潜在的基础架构层面问题[^2]。 --- #### 常见初始化问题及解决方案 ##### 1. 桥梁未成功创建 可能的原因包括权限不足或者已有同名桥梁存在。建议先清理残留数据再重试部署流程。 修复步骤: ```bash kubectl delete -f https://raw.githubusercontent.com/kubeovn/kube-ovn/master/dist/yaml/cleanup.yaml kubectl apply -f https://raw.githubusercontent.com/kubeovn/kube-ovn/master/dist/yaml/kube-ovn.yaml ``` ##### 2. 日志显示无法访问特定端口 某些安全组策略可能会阻止必要的流量进入节点。需确认防火墙设置允许相关服务端口开放(如 Geneve 协议所需端口)。 ##### 3. 控制器逻辑异常 当控制器未能正确定位到新加入节点上的硬件信息时也可能引发此类状况。此时应深入分析 controller 的行为轨迹。 查阅源码得知,实际调用路径是从 `main.go` 开始逐步传递控制权至各个模块直至完成最终处理[^3]。 --- #### 总结 针对 Kube-OVN 的 `br-init` 初始阶段所面临的技术挑战,合理规划基础资源配置以及遵循官方文档指导能够有效降低复杂度。同时借助社区反馈不断优化实践方案亦是非常重要的环节之一。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值