Galaxy学习笔记

Galaxy是TKEStack的一个网络组件，支持为TKE集群提供Overlay/Underlay容器网络。Galaxy的一个特性是能够提供浮动IP（弹性IP） —— 即使Pod因为节点宕机而漂移到其它节点，其IP地址也能够保持不变。

Galaxy提供四类网络，支持为每个工作负载单独配置网络模式。

默认模式，基于Flannel的VXLAN（IPIP）或者Host Gateway（路由）方案。同节点容器通信不走网桥，报文直接利用主机路由转发，跨节点容器通信利用VXLAN协议封装或者直接路由，节点间路由记录在Etcd中。优点：简单可靠，性能不错，支持网络策略。

tke-installer默认安装的TKEStack会自动配置Galaxy为Overlay模式，CNI配置：

在该模式下：

1. Flannel在每个Kubelet节点上分配一个子网，并将其保存在etcd和本地路径 /run/flannel/subnet.env
2. Kubelet调用Galaxy的CNI插件galaxy-sdn，该插件会通过UDS调用本机的Galaxy进程
3. Galaxy进程则又调用Flannel CNI，解析/run/flannel/subnet.env中的子网信息
4. Flannel CNI会调用：
   1. Bridge CNI或Veth CNI来为POD配置网络
   2. 调用host-lo

架构图：

该模式下，容器IP由宿主机网络提供，容器与宿主机可以直接路由，性能更好。支持基于Linux Bridge/MacVlan/IPVlan和SRIOV的容器-宿主机二层联通，可以根据业务场景和硬件环境，具体选择使用哪种网桥。

要使用Galaxy Underlay网络，需要启用Galaxy-ipam组件，该组件为Pod分配IP，浮动IP的能力也由它提供。

利用K8S的hostPort配置，将容器端口映射到宿主机端口。如果不指定hostPort，Galaxy进行随机映射。

利用K8S的HostNetwork模式，直接使用物理网络。

Galaxy有三类组件构成。

以DaemonSet方式运行在每个节点上，通过调用各种CNI插件来配置容器网络。

Galaxy将实际的创建CNI的工作委托给其它CNI插件，也就是说它扮演一个装饰器的角色。Galaxy支持任何标准CNI插件，它也内置了若干CNI插件。

是一个K8S Scheduler插件。kube-scheduler通过HTTP调用Galaxy-ipam，实现浮动IP的配置和管理。

因为仅仅在重新调度Pod的时候才会面临IP地址变化的问题，因此这个组件实现为Scheduler插件就很自然了。

Galaxy支持任何标准的CNI插件，你可以将其用作一个CNI框架，就像multus-cni那样。

Galaxy还包含了一系列内置的CNI插件：

插件	说明
SDN CNI	使用Overlay网络时，此插件是CNI的入口。该插件会通过UDS调用Galaxy守护进程，转发Kubelet提供的所有CNI参数
Veth CNI	用于Overlay网络中，创建一个VETH对来连接容器和宿主机命名空间。该插件从ipam插件得到Pod的IP
underlay-veth CNI	用于Underlay网络，创建VETH对来连接容器和宿主机命名空间，该插件不会创建网桥，而是使用宿主机路由规则来进行封包转发
Vlan CNI	用于Underlay网络，创建一个VETH对，连接容器和宿主机上的bridge/macvlan/ipvlan设备 此插件支持为Pod配置VLAN，它能够从CNI参数，例如ipinfos=[{"ip":"192.168.0.68/26","vlan":2,"gateway":"192.168.0.65"}] ，或者ipam CNI插件的结果中获得IP地址
SRIOV CNI	用于Underlay网络，利用以太网服务器适配器（Ethernet Server Adapter）的SR-IOV，能够创建VF设备并将其放入容器的网络命名空间
TKE route ENI CNI	用于腾讯云

清单文件可以到GitHub下载，默认内容如下：

根据实际运行环境、使用的网络模式，需要进行调整。

需要保证命令行标记： --network-plugin=cni --cni-bin-dir=/opt/cni/bin/，并重启Kubelet。

这种网络模式依赖于Flannel，参考Flannel学习笔记。

你需要修改上述Galaxy清单中的galaxy-etc，来配置默认网络（DefaultNetworks）：

可以为Pod指定注解： 

来提示Galaxy应该为它配置哪些网络。 

Galaxy可以和其它CNI插件同时存在。需要注意的一点是，--network-conf-dir目录下其它插件的配置文件，其文件名的字典排序不应该比00-galaxy.conf更小，否则Kubelet会在调用Galaxy CNI插件之前，调用其它CNI插件，这可能不符合预期。

Underlay网络必须配合Galaxy-ipam使用，Galaxy-ipam负责为Pod分配或释放IP地址：

1. 你需要规划容器网络中使用的Underlay IP范围（注意和物理网路上其它节点的IP冲突），并且配置到ConfigMap floatingip-config中
2. 调度Pod时，kube-scheduler会在filter/priority/bind方法中调用Galaxy-ipam
3. Galaxy-ipam检查Pod是否配置了Reserved IP，如果是，则Galaxy-ipam仅将此IP所在的可用子网的节点标记为有效节点，否则所有节点都将被标记为有效节点。在Pod绑定IP期间，Galaxy-ipam分配一个IP并将其写入到Pod annotations中
4. Galaxy从Pod的注解中获得IP，并将其作为参数传递给CNI，通过CNI配置Pod IP

Galaxy的浮动IP能力由Galaxy-ipam提供，后者是一个Kubernetes Scheudler Extender，K8S的调度器会调用Galaxy-ipam，影响其filtering/binding的过程。浮动IP必须配合Underlay网络使用。

整体工作流图如下：

清单文件可以到GitHub下载，默认内容如下：

你需要为K8S调度器配置调度策略，此策略现在可以放在ConfigMap中：

然后为调度器添加命令行标记： --policy-configmap=scheduler-policy即可。

运行在裸金属环境下时，可以使用如下配置：

一个nodeSubnet可以对应多个Pod Subnet，例如：

只要可分配的IP地址范围不重叠，多个nodeSubnet可以共享同一个Pod Subnet：

要保留一个IP不被分配，可以使用下面的FloatingIP资源： 

目前浮动IP仅仅支持Deployment、StatefulSet产生的工作负载。

生成的Pod中，通过注解 k8s.v1.cni.galaxy.io/args指明了它的IP地址等信息。CNI插件也是基于这些信息为容器网络命名空间设置IP地址、路由的：

为Deployment设置注解 tke.cloud.tencent.com/eni-ip-pool，可以让多个Deployment共享一个IP池。

使用IP池的情况下，默认的IP释放策略为never，除非通过注解 k8s.v1.cni.galaxy.io/release-policy指定其它策略。

默认情况下，IP池的大小随着Deployment/StatefulSet的副本数量的增加而增大，你可以设置固定尺寸的IP池：

通过HTTP接口创建IP池的时候，可以设置preAllocateIP=true来为池预先分配IP，通过kubectl创建CR时无法实现预分配。 

该CR保存了浮动IP，及其绑定的工作负载信息：

Galaxy-ipam提供了基于Swagger 2.0的API，为galaxy-ipam提供命令行选项 --swagger，则它能够在下面的URL展示此API：

http://${galaxy-ipam-ip}:9041/apidocs.json/v1

Deployment的默认更新策略是StrategyType=RollingUpdate，25% max unavailable, 25% max surge。这意味着这在滚动更新过程中，可能存在超过副本数限制25%的Pod。这可能导致死锁状态：

1. 假设Deployment副本数为3，那么有一个副本不可用，就超过25%的限制。Deployment的控制器只能先创建新Pod，然后等它就绪后再删除一个旧Pod
2. 如果浮动IP的释放策略被设置为immutable/never，这就意味着新的Pod需要从一个旧Pod那复用IP，然而旧Pod还尚未删除

这会导致新Pod卡斯在调度阶段。

使用K8S的NodePort服务，可以将一组Pod通过宿主机端口暴露到集群外部。但是如果希望访问StatefulSet的每个特定Pod的端口，使用K8S NodePort服务无法实现。

使用K8S的HostPort，则会存在两个Pod调度到同一节点，进而产生端口冲突的问题：

Galaxy提供了一个功能，可以进行随机的端口映射： 

这样Galaxy会利用iptables，随机的映射宿主机的端口到Pod的每个容器端口，并且将此随机端口回填到tkestack.io/portmapping注解中。

在TKEStack的缺省配置（基于Flannel的VXLAN模式的Overlay网络）下，每个节点只有一个CNI配置：

我们先看看这个CNI插件做的什么事情，又是如何和Flannel交互的。Galaxy所有自带的CNI插件都位于github.com/tkestack/galaxy/cni目录下，其中galaxy-sdn插件入口点如下：

可以看到galaxy-sdn就是个空壳子，所有工作都是委托给Galaxy守护进程处理的。 

整体流程：

VlanDriver是此CNI的核心。 

ADD/DEL命令都需要调用下面的方法加载CNI配置：

CNI配置定义如下：

ADD命令，加载完CNI配置后，首先是调用IPAM进行IP地址分配：

如果使用Galaxy IPAM提供的浮动IP功能，则上述代码会自动获取已经分配的IP信息并返回。

分配/获取IP地址之后，就执行VlanDriver的初始化：

可以看到，如果使用MacVlan或者IPVlan模式，则不会去管理宿主机上的网桥（这也是MacVlan/IPVlan的价值之一，不需要网桥）。否则，会创建网桥并转移走父接口的IP地址、路由。

最后，下面的函数负责配置好网络：  

如果使用MACVlan，则配置过程如下：

如果使用IPVlan，则配置过程如下： 

DEL命令比较简单：

1. 删除容器网络命名空间中所有VETH对
2. 释放IP，就是调用IPAM插件，如果没有插件则什么都不做。Galaxy IPAM不会被调用，它总是自己负责IP地址的回收

该插件用于解决使用IPVlan L2模式下Pod访问不了宿主机IP、Service IP的问题。使用该插件，需要配置Galaxy：

Pod注解需要使用两个网络：

代码解读： 

这个守护进程由DaemonSet galaxy提供，在所有K8S节点上运行，入口点如下：

Galaxy结构的规格如下：

初始化过程：

启动过程：

上述代码结尾的g.StartServer()会调用下面的方法注册路由：

当CNI插件galaxy-sdn调用Galaxy守护进程的/cni端点时，Galaxy会将请求从：

转换为PodRequest：

然后调用requestFunc方法处理转换后的CNI请求：

requestFunc方法就是查询出Pod，将其作为参数的一部分，再调用 cmdAdd方法。需要注意，由于CNI版本很低，仅仅支持ADD/DEL两个命令。

ADD命令的处理逻辑如下：