容器平台建设有哪些风险点需要注意？


@Garyy  系统工程师 某保险：

我们在项目的进行中遇到过一些问题可以分享分享，也是大家需要注意的：

（1）首先是将WebLogic容器化的问题，严格来说，将WebLogic放到Docker中运行是不太合适的，因为Docker本身是轻量级的，而WebLogic是比较重的，把WebLogic做成基础镜像后大概1.4G，而且运行在WebLogic中的JAVA进程都是分配2G左右的内存，内存消耗还是比较高的。

但是，我们还是将WebLogic容器化了，主要原因是为了减少对应用系统运行时环境的改变。我们准备上容器平台的几个应用都是运行在WebLogic中的JAVA应用，如果换用其他中间件，就需要在应用容器化前，先进行更换中间件环境的大量验证，以防迁移至容器云平台后发生问题时，难以及时确定是哪种因素导致的。而这种验证将会耗费我们大量的时间和精力，并将会影响整个项目的进度。

将WebLogic容器化后，对开发和运维现有的工作习惯都会有一些影响，比如部署应用、配置JDBC的时候，之前都是在控制台上进行的，容器化后WebLogicConsole将不能访问。为解决这个问题，我们在部署的时候，使用WebLogic的WLST工具进行部署，同时将JDBC配置文件参数外部化，放在了配置中心。为了提高安全性，配置文件中的数据库用户名和密码均为空，这些信息保存在了容器平台中并进行了加密。解决方案是：改用容器平台的router提供的域名访问方式（K8S的Ingress方式）；

（2）其次是应用访问方式的问题，我们容器平台中，app1/app2应用的访问方式统一为通过域名访问，但一开始我们使用的并不是这种方式，而是NodePort方式，后来发现这种方式不适合业务场景。

app1和app2系统应用容器化前，对外提供的访问方式为IP+端口，周边系统的服务器上都没有配置DNS SERVER，不能解析应用系统的域名，为了减少对应用本身的改造及周边系统调用方式的改变，当时决定采用NodePort作为容器平台内应用的访问方式；

我们的业务系统大多为BS架构的web应用，大多需要使用基于cookie的会话保持功能；NodePort的实现方式是通过直接访问计算节点的端口，通过计算节点的iptables来转发请求至POD，而iptables只能基于源IP地址做会话保持，不能基于cookie等信息，由于计算节点接收到请求的源IP都为F5的地址，所以基于iptables的源地址会话保持机制，会将访问的所有流量都转发到一个POD中，导致在有多个POD的情况，只有一个POD有业务访问流量，其他POD没有负载，不能做到流量负载均衡；

容器平台的router通过haproxy来实现，haproxy能够基于cookie等信息做会话保持，并且能够做负载均衡，将请求分发至后端多个POD。但使用容器平台的router，需要将应用对外提供的访问方式调整为域名，这就需要周边调用方的系统修改调用接口地址，并且所在的服务器能够解析该域名。

（3）然后是网络管理问题，我们的私有云环境根据业务类型，划分为了不同区域，如管理区、web区、应用区等，每个区域都有一道防火墙，如果两个区域要通信，则需要互相开通防火墙策略；这种规划对容器平台node扩容，及新系统上容器平台，都带来大量的网络防火墙变更。

据我们统计，在私有云容器平台中新增加两个node节点，需要开通58条防火墙策略；

迁移至容器云平台的新系统，与传统环境的业务系统之间也存在众多交互，也有较多防火墙策略要开通，但有些防火墙策略与之前已开通的策略其实是重复的，比如与大地基础公共服务（ESB、单点登录等）之间的网络策略。解决方案是，在私有云环境的服务器中建立安全组，同一安全组内新增服务器，默认共享已开通的网络策略。这样就解决了容器平台node扩容，以及新系统上容器平台时，面临的网络防火墙开通问题。

（4）最后说一下某个app系统，我们将这个系统容器化后，经过几周的试运行，最终没有正式切换，主要有三个原因：

首先是应用本身的问题，app应用由十多个服务组成，但部署在同一个WebLogic实例上，端口是同一个端口，但有些服务不能同时启动两个进程，有些基础服务基本不需要更新，而有些服务则需要频繁更新发布，如果仍按之前的部署方式，将这些服务运行在一个容器中显然是不合适的，所以我们对其按功能进行了拆分改造，新分配了一些服务端口，但引入的问题是内部服务间调用也都要经过F5，给F5带来比较大的压力；

其次，当时采用的是NodePort的访问方式，配置了基于源IP地址的会话保持，也就是说，只有一个pod接收到了业务流量，其他pod处于热备状态；但某app系统当时处于业务推广期，系统用户数规划在容器化期间从2千余人快速增长至1万人，超出预期规划，单个POD无法支撑业务。

最后一个问题是，某app项目本身有大量的开发需求任务，对于上述两个问题的优化建议，项目组由于人员有限，难以有效的配合，其实对于上面两个问题都有相应的解决方案，比如问题一，需要对这些服务之间的调用关系重新进行梳理，进一步拆分改造；问题二需要调整应用访问方式，但是由于当时业务上的压力太大，没有足够的时间完成这些优化，只能继续使用之前的传统环境。最终我们只好更换了另外一个系统来进行容器化—也就是某app2系统。


@Caikai  系统架构师  KYLERC：

主要从以下几个方面：运维监控能力、业务运行日志收集、容器底层资源供给的协调、容器平台和其它系统的网络连通、通信安全（防火墙、漏洞扫描和修补）