leo1234

这个问题问的有水平，适不适合，需不需要是金融行业it规划及系统建设所需重点考虑的。传统集中式架构是否已经不能支撑现行业务和未来规划，分布式微服务架构转型带来了什么价值和成本，另起炉灶重新构建单元化体系带来了什么

常见方案：1.基于harbor或其他发行版产品构建基于RBAC权限控制的镜像仓库。2.建立基础镜像准入机制，构建安全基础镜像，这阶段企业有能力自己解决，没有能力可找三方厂商，从网上随意拉的镜像有重大安全隐患。3.建设CI/CD工艺

信创从国家自主可控和安全角度来看，是一次进步，但是站在纯技术角度来看，是一场变革，带来的效果可能是倒退，容忍度需要高一些，关键系统国产化需要继续等待产业侧的成熟，或仔细考察成功案例，非关键系统上的问题就当积累经验吧。

还有在干容器化信用卡核心，容器化互联网核心，容器化核心的银行，别人都在干，只干不说

通过业务建模或者说功能架构的重新梳理， 解耦并重构系统中的业务模块，形成不同的微服务系统。对整个应用的系统接入层、控制层、服务流程层、业务服务/组件层、数据访问层等进行定义划分； 对划分的微服务进行流程编排，使

docker manifest功能了解一下，就是你的需求

数据库替代需要优先基于应用进行适配，poc不是过场，应用所需的功能、性能、高可用、管理、运维等用户关注的特性需要在适配阶段就发现问题。前面的工作做完了要做7*24稳定性、容灾rto、rpo方面的测评，一切都得基于行里的

核心从主机下移，按照先进行“应用分布式改造”，后使用“国产芯片服务器”的策略分阶段推进，重点突破分布式数据库技术，降低对国外高端产品的依赖，最终形成可推广的成熟解决方案。已经有金融机构在网云原生进行了探索，有银行

目前大部分信创服务器操作系统已经对基于K8S的容器管理集群和docker、containerd等运行时做了大量的适配，基本支持正常部署容器云。和非信创操作系统相比可能存在软件依赖包方面有差异，需要与信创操作系统厂商保持密切

export KUBECONFIG=config1,config2,config3kubectl config viewkubectl use-context <context-name> kubectl --kubeconfig /xx/xx/config get pod -A