流程：

1.考虑直接将operator镜像部署到云原生，发现内部使用的k3s，如此结构重复，而且k3s的需要使用云原生的kubeconfig才能进一步部署，这里会有权限问题。

2.尝试直接将内部k3s的资源部署到云原生，通过其docker-compose文件中的部署命令，找到内部使用cli进行部署，发现cli能够导出用于k8s部署的yaml文件。

3.直接将内部集群服务所需镜像上传到云原生，并修改导出的deployment.yaml，补齐缺失的secret等资源，ingress改nodeport，并在云原生上执行。

4.经常有pod在pending，调整部署配置后怀疑与pvc和cpu，内存资源有关，申请独立的集群确保cpu和内存资源足够，并继续尝试部署。

5.所有pod正常运行之后，发现有部分接口调用出错，与mysql有关，进入容器查询发现mysql迁移未成功，进一步发现db迁移的任务pod一直在running，没有completed，直接执行迁移命令 flask db upgarde 也的确会卡在某些步骤。

6.对比正常pod的资源，怀疑还是资源不够，调大迁移pod的资源，所有接口调用成功。

7.开始运行联邦任务，双边租户状态异常，日志中发现了连接问题，无法通信，租户会通过一个mq_proxy通信，使用ghostunnel 做加密通信，该pod会开放随机的nodeport，而外层的master容器没有开放这些端口，改为指定nodeport并开发容器端口之后，双边通信正常。

8.运行任务之后总有一方会找不到镜像，因为云原生只能用内部仓库，k3s只能用对应的registry仓库，在master中将内部仓库地址代理到registry服务，并重新tag相关镜像到该仓库。

心得：

主要困难来自于pl团队被端，接手人员沟通阻塞，所以很多问题只有自己去看底层逻辑才能弄明白。一开始看整个任务就像是一个黑盒，什么都不清楚，当了解清楚其中大部分逻辑的时候，很多问题就不是问题了。

会当凌绝顶，一览众山小。