6.1.3 落地实践
6.1.3.1 注册集群
首先需要将自建的集群注册到阿里云。注意使用的 VPC 的网段不能和集群的 Service CIDR 冲突，否则无法注册。VPC 的虚拟交换机和 Pod 虚拟交换机的 CIDR 也不能和机房内使用的 网段重合，否则会有路由冲突。注册成功后，需要部署 ACK Agent。它的作用是主动建立从机 房到阿里云的长链接，接收控制台的请求并转发给 apiserver。对于没有专线的环境，此机制可 以避免将 apiserver 暴露在公网。控制台到 apiserver 的链路如下:
阿里云 ACK 控制台 <--> ACK Stub(部署在阿里云) <--> ACK Agent(部署在 K8s) <--> K8s apiserver
控制台到集群的请求是安全可控的。Agent 连接 Stub 时，会带上配置的 token 和证书;链 接采用了 TLS 1.2 协议，保证数据加密;可以通过 ClusterRole 来配置控制台对 K8s 的访问 权限。
6.1.3.2 容器网络配置
K8S的容器网络要求 Pod 和 Pod、Pod 和宿主机之间通讯正常，平台采用了 Calico + Terway 的网络方案。机房内的工作节点采用 Calico BGP，Route Reflflector 会将 Pod 的路 由信息同步给交换机，物理机和云主机都能正常访问 Pod IP。阿里云上的工作节点会采用 Terway 共享网卡模式，Pod 会从 Pod 虚拟交换机配置的网段中分配到 IP，该 IP 在机房内 可以访问。平台给云主机打上标签，配置 calico-node 组件的 nodeAffiffiffinity，不调度到云主机 上;同时配置 Terway 组件的 node Affiffiffinity，让其只运行在云主机上。这样实现了物理机和云 主机使用不同的网络组件。在部署和使用 Terway 中，我们遇到并解决了以下三个问题:
1.terway 容器创建失败，报/opt/cni/bin 目录不存在。通过修改 terway daemonset 中该路径的 hostPath 的 type，从 Directory 改为 Directory OrCreate 可以解决上述问题
2.业务容器创建失败，报找不到 loopback 插件。terway 没有像 calico-node 一样在/opt/cni/bin/目录下部署 loopback 插件(创建回环网络 接口)。我们给 terway daemonset 添加了 InitContainer 来部署 loopback 插件，解决了问 题。
3.业务容器分配的 IP 是属于主机交换机网段。 这是因为在使用中，我们新增了一个可用区，但是没有把可用区的 Pod 虚拟交互机的信息配 置给 terway。通过在 terway 配置的 vswitches 字段新增可用区的 Pod 虚拟交换机信息， 可以解决问题。
6.1.3.2 云主机加入集群
将云主机加入集群的流程和物理机基本一致。首先通过公司云平台申请云主机，然后通过 VCo ntainer 的自动化平台将云主机初始化并加到集群中。最后给云主机打上云主机专有的标签。关 于自动化平台的介绍，可以参见 vivo AI 计算平台云原生自动化实践。
6.1.3.2 降低专线压力
机房到阿里云的专线是公司所有业务共用的，如果平台占用过多专线带宽，会影响到其他业务 的稳定性。在落地时我们发现深度学习训练任务从机房的存储集群拉取数据，确实对专线造成 压力，为此平台采取了以下措施:
1.监控云主机的网络使用情况，由网络组协助监控对专线的影响。
2.使用 tc 工具对云主机 eth0 网卡的下行带宽进行限流。
3.支持业务使用云主机的数据盘，将训练数据进行预加载，避免反复从机房拉取数据。
