银行实施容器平台是否需要考虑的周边系统整合？整合的方法？

一般容器云建设包括但不限于如下方面：

1） 云管平台的建设：主要实现整个云平台可视化的web管理平台，包括分配资源、管理容器、管理租户、管理应用和管理服务等操作功能；
2） CI/CD与平台的对接：以jenkins等软件为主实现与云平台基础功能的对接， 能够更好的支持灰度发布、蓝绿发布等多种应用更新升级方式，智能化的自动构建和部署，从而更好的支持软件敏捷开发；
3） 应用商城(镜像管理)：实现镜像的集中安全统一管理，实现企业软件资源积累和沉淀的一个工具化支持；
4） 应用日志和监控：实现对容器云平台运行的各个应用系统的日志统一管理和监控统一管理；
5） 应用编排：制定容器云平台的标准服务定义模型，从而保证应用的一键式部署、能够实现健康检查、自动伸缩、自动资源选择和调度、自动复制等功能，从而保证应用的整体服务能力；
6） 网络和存储：如何在容器中建立网络模型和存储模型，从而更好为容器提供网络通信和存储提供服务；

在DMZ区应用部署遵循以下策略：
• 已有应用迁移至容器云平台时的资源申请按现有配置设置，申请的服务器将仅供该使用
• 如果需要横向扩展，也仅在已分配的计算节点上，如果资源不足，应用项目组可再申请新的计算资源
• 本期项目中，XXX部署在DMZ区平台上，使用2个计算节点；XXX部署在内网平台上，使用2个计算节点
• 在实施时需要为相应的计算节点标记标签，使应用部署时部署到指定的计算节点上。
例如在DMZ网段对XXX应用所使用的2台计算节点打上标签
在部署XXX应用使，nodeSelector需要指明使用的节点的标签为XXX=XXX。

传统应用的访问策略：
• Openshift产品推荐通过NodePort类型的Service为某个应用对外暴露一个服务端口。NodePort类型的Service会在集群中的所有节点上监听一个特定的端口，访问任意一个计算机节点的端口，即可访问内部容器中的服务。在集群的所有节点的这个端口都会预留给该应用所用。
• 在F5 VS的Pool Member中配置所有节点，通过Keepalived来实现HA
• 应用系统和用户不用改变现有的访问方式

容器云的建设目标是为应用系统提供中间件服务，因此，容器平台需要实现与周边系统的整合，楼上已经总结很全面，本人只说一下对于整合的拙见
1）与日志平台和监控系统的对接和整合：应用在运行过程中，对故障的定位和解决往往需要全链路的监控和定位，一般企业已经具有完善的监控体系，那么容器级别、应用级别、中间件级别等均需对接监控系统，从而实现统一的监控管逻辑；
2）与自动化部署系统的对接和整合：应用部署方式由war包或者jar变为镜像部署，但从企业审核角度看，镜像的部署需要与自动化部署系统进行对接；
3）与CI/CD系统的对接和整合：应用系统的研发和管理一般企业都有企业级平台，比如统一的代码管理服务器，统一的代码构建服务器，平台需要与这些CICD工具进行对接
4）与网络和存储的对接和整合：作为容器运行所需要的基础资源，网络和存储一般也已存在现有一些系统或者平台，在平台研发时也需要与之进行对接和整合
5）与统一权限系统对接：云管理平台需要实现租户管理和资源额度管理，因此在设计管理平台时需要与已经的单点登录等权限系统实现组织机构和用户的对接
6）与底层IaaS的对接（可选）：如果需要实现与底层IaaS的对接，则需要实现对底层操作系统实例的创建、销毁等多种操作的API对接

有几个功能模块可能需要整合，具体还需看整个IT系统的规划：
1、监控告警：一般银行都有监控告警，包括物理主机、虚拟机、存储、网络等，都有一套成熟的监控告警系统，一般的容器平台也自带监控系统，我认为这部分可以整合；
2、日志：一般IT系统也有统一的ELK日志平台，这部分也可以整合
3、审批：可以结合企业的业务特性，在审批模块也可以考虑整合
4、CI和CD部分：容器平台很多是作为CD平台，有些也自带简单的CI功能，这部分可以结合企业已有的CI平台

对接方式有多种，主要还是看各个企业的业务需求。