fanux
commented
3 years ago 政采云需求：
[ ]【进行中】1. 镜像缓存成本太高，要拉起一个新集群。 个人觉得：fake一个kubernetes的api server收集镜像的方式很geek也很完美，没必要启集群来收集镜像。 [ ]【webhook不是一个好的方案，稳定性很差，而且建立映射是个对用户有感知的过程】2. 有些纠结针对docker和registry的hack， 其实我们更倾向于利用准入控制来实现镜像地址的替换。当然如果registry和docker能接受PR合并就完美了。 [x]【进行中】3. registry地址是写死在代码里面的，要支持定制。 【镜像标准稳定下来了我们就会批量构建rootfs】4. kubernetes的版本选择不多。 跟随kubernetes版本的rootfs的自动化CI 有没有计划安排。想玩玩1.20 [x]【进行中，用config的方式支持最新版本calico】5. cni配置的可定制性太弱。自动换成host-gateway模式，但是VPC下不支持ARP广播导致pod间无法通信。感觉有些过度设计，一些配置应该默认使用经过验证的最佳实践， 例如ipip模式，建议提供默认值且不要用逻辑帮用户做决定而是暴露一些参数使高级用户可以修改。傻瓜一点，一个小白用户也能交付一个安全可靠的集群。 [x]【已支持，现在registry不会所有节点都分发】6. rootfs复制成本太高， 实际交付场景下我们的应用镜像17G。。。分发到所有节点实在没必要。 [ ]【待讨论】7. master[0] 这个设计感觉有些奇怪， 一些指令可以随便选一台机器去执行例如kubectl， 但是不应该依赖iplist中的顺序。 [ ]【目前应该脚本有检测保持一致的】8. Cgroup 驱动 docker与systemd保持一致使用：cgroupdriver https://kubernetes.io/zh/docs/setup/production-environment/container-runtimes/
Q: 第一个：就是我在a机器上进行build操作，clusterfile上指定master节点的ip是b机器，build的过程其实是去b机器起一个k8s集群，然后按照自己写的kubefile去一个个执行命令，把东西都起起来。最后把这个起起来可运行的多个容器，打成一个快照生成镜像。所以我在a机器上是找不到打出来的镜像，要在b机器上才有。是这么一个原理么。 A: 是的，还可以使用其它的build方式，参考文档：https://github.com/alibaba/sealer/blob/main/docs/build/build_zh.md
Q: 第二：比如说我需要在集群镜像中跑了很多个应用，也可以理解为我要打出来的集群镜像很大，然后去打镜像的时候，也就需要考虑到机器能不能承载这么多的资源咯，否则因为机器性能不足根本打不出来集群镜像 A: 是的，大概有多大，不过一般机器都有几百G吧，难道镜像比几百G还大？
Q: 第三：昨天群里有个问题就是，在build的时候，报错码exit status 127，对于用户来说根本不能理解这个码，我觉得应该把解释也带上 A: 这个问题可以给我们提个issue哈。
Q: 第四：报错127是命令不存在，能否有机制去check命令，比如说wget的时候，去check命令，或者说去check一些命令集，甚至说可以直接自动yum install掉去，因为昨天是申请了新机器，但是新机器上没有wget命令，导致了问题的排查 A: 我觉得像docker一样能把command not found提示出来就可以
明源云诉求:
1.应用镜像缓存支持打包进集群镜像，目前测试发现应用镜像没有打包进集群。需要支持完全离线场景 2.针对国产化场景，支持arm架构的实例，目前主要在华为云麒麟上测试 3.集群运行起来后检查网络连通情况，检查主机路由等，集群运行起来了，但是存在pod相互访问，跨节点访问等不通的情况。导致在kubefile里面写的应用安装步骤无法正常进行 4.状态检测，离线环境会使用到存储方案，我们目前使用的是ceph，ceph初始化过程比较长，且容易遇到阻断问题，我们的应用完全依赖ceph存储，在kubefile运行过程中无法检测ceph状态，容易阻断应用安装。 5.kubefile运行helm命令支持超时跳过这条命令，helm安装应用如果应用pod处于pending状态(比如无法申请到ceph提供的存储卷)，最后导致kubefile构建失败。