一般由全局负载均衡来分发。

k8s的集群信息应该可以通过kubectl top pod -n 集群命名空间进行查询，每个集群肯定有单独的命名空间，这时候只需要把每个命名空间下的pod资源加起来应该就是每个集群实际使用的资源量，这里主要是cpu和内存...

采用配置中心吧？例如Apollo或是nacos做应用配置中心，进行配置的统一管理

基于应用类型进行容器区域划分，例如一类应用容器，二类应用容器。多中心容器有自己镜像仓库和存储库。

        技术中台是一个相对较大的概念，中台意味着企业级功能或能力的复用，容器集群相对来说是一个偏标准的底层基础设施，并不具备过强的企业级业务属性。所以可以算作技术中台中，不同技术组件和技术栈的底层支撑，技术中台的实现，是需要依靠容器平台的，但是又不可能完全...

      首先，容器平台是微服务落地的一个最佳承载的实例，因为分别是面向云原生业务系统的技术框架和计算资源，但是微服务框架早就出现，更多的微服务组件还是运行在传统虚拟机之上，只不过随着新的微服务治理框架出现，如istio等，才会越来越多的运行在容器之上，甚至springcloud...

建议集群内服务器配置保持完全一致，服务器出现问题时可以自动迁移或者通过手工迁移，整个集群通用的文件可以通过共用一个nas实现，上面可以存储共用的运维脚本等，包括定时自动清理日志，自动定时清理和备份数据库等，也包括平时上线包都可以放在共享nas上...

一般分为平台和业务安全风险；平台审计主要是平台操作记录，用于审计；业务安全风险包括镜像安全(静态和运行态)、服务安全等，国内大厂一般都有镜像安全方案，一些初创公司也有。