应用容器化改造难点之：容器化后核心系统和非核心系统如何共存在同一主机，兼顾成本和安全性？

首先，对于银行业，容器技术适用于敏态业务（互联网业务），虚机技术适用于稳态业务，容器技术不是一概而论的。
1、首先关于运行的系统进行讨论，无论是核心还是非核心系统，都是分布式的，都是多个节点的，理论上，一台物理机可以跑多个容器，即运行一个核心或者非核心的系统的多个服务实例（1个系统对应M个服务，1个服务运行N个实例）。
2、计算节点（物理机），无论是容器还是虚拟机都是运行在多个计算节点（冗余高可用），单个计算节点宕机，容器或虚机均会自动漂移至新计算节点，提供服务；而虚机内核crash，并不会漂移，而产生当然虚机的服务不可用，需手动重启。
3、根据上述描述，1）隔离性方面，一个核心系统和非核心系统共存在一台主机运行，存在相互影响的情况，但是容器会自动漂移重新提供服务。2）成本方面，如需进行隔离，则可采用核心业务非核心业务分计算集群的方式运行，而一个计算节点可以跑多个核心服务，一个计算节点发生crash时可以漂移至另一个计算节点，漂移过程中出现轻微服务波动的情况。
4、如果考虑核心业务的高SLA，那还是建议核心业务使用虚机或者物理机，而非核心业务使用容器技术，容器应用从非核心业务进行试点推广。

一般来说容器部署，底层物理设备都是多台X86服务器，很少有单点的。如果的确有这种需求，可以先把底层物理设备先进行虚拟化，再在虚拟机上面部署容器，通过虚拟化层面实现故障隔离，资源配额。

1. 个人觉得首先考虑应用和资源的分层问题。应用只是使用资源，资源统一由基础设施资源平台来管理，需要什么资源分配什么资源。
2. 不要尝试直接用docker或k8s cmd去管理应用，否则自己会玩死自己。应用管理平台要考虑产品化
3. 容器的优点在于弹性，云计算的优点在于体量，没有大量的需求，不会节约成本，反而造成浪费。
4. 安全性需要通过产品化和不同层次的安全措施实现。

目前我们的做法是核心业务和非核心业务承载在不同的K8S集群上。同一集群内的应用可以共享宿主机。为了避免因为单个节点故障影响应用，要求所有的应用必须至少部署2个副本，分布在不同的宿主机上，同时对于核心业务，要求应用必须双活部署，也即部署在双活数据中心的两个独立K8S集群上，前端通过负载均衡或者自动发现机制引流，这样即使某个数据中心发生了全局性故障，也不会影响应用。

基于软件（HAproxy）负载均衡服务，容器服务弹性伸缩时无需人工对负载均衡设备进行配置干预，即可保证容器化应用的持续、正常访问；可通过图形界面自定义负载均衡会话保持策略。
由于平台内部通过软件定义网络为每个应用容器分配了IP地址，而此地址是内网地址，因此外部客户无法直接访问到该地址，所以平台使用路由器转发外部的流量到集群内部具体的应用容器上，如果应用有多个容器实例，路由器也可实现负载均衡的功能。路由器会动态的检测平台的元数据仓库，当有新的应用部署或者应用实例发生变化时，路由器会自动根据变化更新路由信息，从而实现动态负载均衡的能力。