1.环境准备
Kube-OVN 是一个符合 CNI 规范的网络组件,其运行需要依赖 Kubernetes 环境及对应的内核网络模块。 以下是通过测试的操作系统和软件版本,环境配置和所需要开放的端口信息。
1.1 软件版本
- Kubernetes >= 1.16 且 < 1.24,推荐 1.19 以上版本。
- Docker >= 1.12.6, Containerd >= 1.3.4。
- 操作系统: CentOS 7/8, Ubuntu 16.04/18.04/20.04。
- 其他 Linux 发行版,需要检查一下内核模块是否存在
geneve
,openvswitch
,ip_tables
和iptable_nat
,Kube-OVN 正常工作依赖上述模块
注意:
- 如果内核版本为 3.10.0-862 内核
netfilter
模块存在 bug 会导致 Kube-OVN 内置负载均衡器无法工作,需要对内核升级,建议使用 CentOS 官方对应版本最新内核保证系统的安全。相关内核 bug 参考 Floating IPs broken after kernel upgrade to Centos/RHEL 7.5 - DNAT not working。 - Rocky Linux 8.6 的内核 4.18.0-372.9.1.el8.x86_64 存在 TCP 通信问题 TCP connection failed in Rocky Linux 8.6,请升级内核至 4.18.0-372.13.1.el8_6.x86_64 或更高版本。
- 如果内核版本为 4.4 则对应的内核
openvswitch
模块存在问题,建议升级或手动编译openvswitch
新版本模块进行更新 - Geneve 隧道建立需要检查 IPv6,可通过
cat /proc/cmdline
检查内核启动参数, 相关内核 bug 请参考 Geneve tunnels don''
t work when ipv6 is disabled。
1.2 环境配置
- Kernel 启动需要开启 ipv6, 如果 kernel 启动参数包含
ipv6.disable=1
需要将其设置为 0。 kube-proxy
正常工作,Kube-OVN 可以通过 SVC IP 访问到kube-apiserver
。- 确认 kubelet 配置参数开启了 CNI,并且配置在标准路径下, kubelet 启动时应包含如下参数
--network-plugin=cni --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d
。 - 确认未安装其他网络插件,或者其他网络插件已经被清除,检查
/etc/cni/net.d/
路径下无其他网络插件配置文件。如果之前安装过其他网络插件,建议删除后重启机器清理残留网络资源。
1.3 端口信息
2. 一键安装
Kube-OVN 提供了一键安装脚本,可以帮助你快速安装一个高可用,生产就绪的 Kube-OVN 容器网络,默认部署为 Overlay 类型网络。
如果默认网络需要搭建 Underlay/Vlan 网络,请参考 [Underlay 网络支持](https://kubeovn.github.io/docs/v1.10.x/start/underlay/)。
2.1 下载安装脚本
在生产环境使用稳定的 release 版本:
wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.10/dist/images/install.sh
2.2 修改配置参数
编辑器打开脚本,并修改下列变量为预期值
REGISTRY="kubeovn" # 镜像仓库地址
VERSION="v1.10.7" # 镜像版本/Tag
POD_CIDR="10.16.0.0/16" # 默认子网 CIDR 不要和 SVC/NODE/JOIN CIDR 重叠
SVC_CIDR="10.96.0.0/12" # 需要和 apiserver 的 service-cluster-ip-range 保持一致
JOIN_CIDR="100.64.0.0/16" # Pod 和主机通信网络 CIDR,不要和 SVC/NODE/POD CIDR 重叠
LABEL="node-role.kubernetes.io/master" # 部署 OVN DB 节点的标签
IFACE="" # 容器网络所使用的的宿主机网卡名,如果为空则使用 Kubernetes 中的 Node IP 所在网卡
TUNNEL_TYPE="geneve" # 隧道封装协议,可选 geneve, vxlan 或 stt,stt 需要单独编译 ovs 内核模块
2.3 安装脚本
` bash install.sh` 等待安装完成
3. underlay网络安装
默认情况下 Kube-OVN 的默认子网使用 Geneve 对跨主机流量进行封装,在基础设施之上抽象出一层虚拟的 Overlay 网络。
对于希望容器网络直接使用物理网络地址段情况,可以将 Kube-OVN 的默认子网工作在 Underlay 模式,可以直接给容器分配物理网络中的地址资源,达到更好的性能以及和物理网络的连通性
3.1 功能限制
由于该模式下容器网络直接使用物理网络进行二层包转发,Overlay 模式下的 SNAT/EIP, 分布式网关/集中式网关等 L3 功能无法使用。
3.2 和 Macvlan 比较
- Macvlan 的内核路径更短,不需要 OVS 对数据包进行处理,Macvlan 在吞吐量和延迟性能指标上表现会更好。
- Kube-OVN 通过流表提供了 arp-proxy 功能,可以缓解大规模网络下的 arp 广播风暴风险。
- 由于 Macvlan 工作在内核底层,会绕过宿主机的 netfilter,Service 和 NetworkPolicy 功能需要额外开发。Kube-OVN 通过 OVS 流表提供了 Service 和 NetworkPolicy 的能力。
- Kube-OVN 的 Underlay 模式相比 Macvlan 额外提供了地址管理,固定IP 和 QoS 等功能
3.3 环境要求
在 Underlay 模式下, OVS 将会桥接一个节点网卡到 OVS 网桥,并将数据包直接通过该节点网卡对外发送,L2/L3 层面的转发能力需要依赖底层网络设备。 需要预先在底层网络设备配置对应的网关、Vlan 和安全策略等配置。
-
对于 OpenStack 的 VM 环境,需要将对应网络端口的
PortSecurity
关闭。 -
对于 VMware 的 vSwitch 网络,需要将
MAC Address Changes
,Forged Transmits
和Promiscuous Mode Operation
设置为allow
。 -
公有云,例如 AWS、GCE、阿里云等由于不支持用户自定义 Mac 无法支持 Underlay 模式网络。
-
桥接网卡不能为 Linux Bridge。
管理网和容器网使用同一个网卡的情况下,Kube-OVN 会将网卡的 Mac 地址、IP 地址、路由以及 MTU 将转移或复制至对应的 OVS Bridge, 以支持单网卡部署 Underlay 网络。OVS Bridge 名称格式为
br-PROVIDER_NAME
,PROVIDER_NAME
为 Provider 网络名称(默认为 provider)
3.4 部署时指定网络模式
部署模式将默认子网设置为 Underlay 模式,所有未指定子网的 Pod 均会默认运行在 Underlay 网络中。
- 下载安装脚本
wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.10/dist/images/install.sh
- 修改脚本中响应配置
NETWORK_TYPE # 设置为 vlan VLAN_INTERFACE_NAME # 设置为宿主机上承担容器流量的网卡,例如 eth1 VLAN_ID # 交换机所接受的 VLAN Tag,若设置为 0 则不做 VLAN 封装 POD_CIDR # 设置为物理网络 CIDR, 例如 192.168.1.0/24 POD_GATEWAY # 设置为物理网络网关,例如192.168.1.1 EXCLUDE_IPS # 排除范围,避免容器网段和物理网络已用 IP 冲突,例如 192.168.1.1..192.168.1.100
- 运行安装脚本
bash install.sh
4. 通过CRD动态创建Underlay网络
该方式可在安装后动态的创建某个 Underlay 子网供 Pod 使用。需要配置 `ProviderNetwork`,`Vlan` 和 `Subnet` 三种自定义资源。
4.1 创建ProviderNetwork
ProviderNetwork 提供了主机网卡到物理网络映射的抽象,将同属一个网络的网卡进行统一管理, 并解决在复杂环境下同机器多网卡、网卡名不一致、对应 Underlay 网络不一致等情况下的配置问题。
创建如下 ProviderNetwork 并应用:
apiVersion: kubeovn.io/v1
kind: ProviderNetwork
metadata:
name: net1
spec:
defaultInterface: eth1
customInterfaces:
- interface: eth2
nodes:
- node1
excludeNodes:
- node2
注意:ProviderNetwork 资源名称的长度不得超过 12
-
defaultInterface
: 为默认使用的节点网卡名称。 ProviderNetwork 创建成功后,各节点(除 excludeNodes 外)中会创建名为 br-net1(格式为br-NAME
)的 OVS 网桥,并将指定的节点网卡桥接至此网桥。 -
customInterfaces
: 为可选项,可针对特定节点指定需要使用的网卡。 -
excludeNodes
: 可选项,用于指定不桥接网卡的节点。该列表中的节点会被添加net1.provider-network.ovn.kubernetes.io/exclude=true
标签。
其它节点会被添加如下标签:
如果节点网卡上已经配置了 IP,则 IP 地址和网卡上的路由会被转移至对应的 OVS 网桥。
4.2 创建VLAN
Vlan 提供了将 Vlan Tag 和 ProviderNetwork 进行绑定的能力。
创建如下 VLAN 并应用:
apiVersion: kubeovn.io/v1
kind: Vlan
metadata:
name: vlan1
spec:
id: 0
provider: net1
id
: 为 VLAN ID/Tag,Kube-OVN 会对对该 Vlan 下的流量增加 Vlan 标签,为 0 时不增加任何标签。provider
: 为需要使用的 ProviderNetwork 资源的名称。多个 VLAN 可以引用同一个 ProviderNetwork。
4.3 创建Subnet
将 Vlan 和一个子网绑定,如下所示:
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
name: subnet1
spec:
protocol: IPv4
cidrBlock: 172.17.0.0/16
gateway: 172.17.0.1
vlan: vlan1
5. 容器创建
可按正常容器创建方式进行创建,查看容器 IP 是否在规定范围内,以及容器是否可以和物理网络互通。
如有固定 IP 需求,可参考 Pod 固定 IP 和 Mac
6. 使用逻辑网关
对于物理网络不存在网关的情况,Kube-OVN 支持在 Underlay 模式的子网中配置使用逻辑网关。 若要使用此功能,设置子网的 `spec.logicalGateway` 为 `true` 即可:
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
name: subnet1
spec:
protocol: IPv4
cidrBlock: 172.17.0.0/16
gateway: 172.17.0.1
vlan: vlan1
logicalGateway: true
开启此功能后,Pod 不使用外部网关,而是使用 Kube-OVN 创建的逻辑路由器(Logical Router)。对于跨网段通信进行转发。
7. 卸载
如果需要删除 Kube-OVN 并更换其他网络插件,请按照下列的步骤删除对应的 Kube-OVN 组件以及 OVS 配置,以避免对其他网络插件产生干扰。
7.1 删除在 Kubernetes 中创建的资源
下载下面的脚本,执行脚本删除在 Kubernetes 中创建的资源:
wget https://raw.githubusercontent.com/kubeovn/kube-ovn/release-1.10/dist/images/cleanup.sh
bash cleanup.sh
7.2 清理主机上的日志和配置文件
在每台机器上执行下列操作,清理 ovsdb 以及 openvswitch 保存的配置:
rm -rf /var/run/openvswitch
rm -rf /var/run/ovn
rm -rf /etc/origin/openvswitch/
rm -rf /etc/origin/ovn/
rm -rf /etc/cni/net.d/00-kube-ovn.conflist
rm -rf /etc/cni/net.d/01-kube-ovn.conflist
rm -rf /var/log/openvswitch
rm -rf /var/log/ovn
rm -fr /var/log/kube-ovn
7.3 重启节点
重启机器确保对应的网卡信息,iptable/ipset 规则得以清除,避免对其他网络插件的影响,也可以手动删除,建议重启
reboot