接下来是监控模块。在我们微众银行有一个统一的标准监控平台，因此，在进行容器化的时候，容器的监控必须要适配现存的这套标准的监控模块，所以，在监控方案做了拆分，主要分成两部分。第一部分容器指标采集相关的，用Prometheus和Thanos来做数据的聚合和采集，另外，我们还自研了一个模块，通过将容器的监控数据，比如CPU、内存、网络指标上传到统一的监控平台，做成与跟VM一致的监控数据。
接下来再给大家介绍一下容器部署平台。在原生的K8s中，发布的时候需要编辑yaml文件，通过kubectl的操作来将容器部署到集群中。这种发布方式是非常难以运维的，主要存在的问题是：发布的时候存在大量手工操作，容易误操作；在发布过程无法做发布的模板化和可视化；历史发布记录无法追溯、无法审计。为了解决这些问题，我们做了一套容器的部署系统，可以通过这套部署系统来完成容器发布的模板化、可视化、可审计化。容器的部署分成两部分，第一部分是宿主机的部署，我们主机的同学将初始好系统的容器宿主机登记到资源管理服务中，然后可以通过管理台对这个宿主机机进行K8s的初始化。初始化完之后，在资源池中就存在了可以分配的资源。业务方就可以通过流程管理系统发起一个应用实例的申请，实例分配好以后，将实例信息回写到元数据管理系统里，业务同学可以在发布平台中选中对应的实例，调用相应的服务来进行结构化的容器的发布。
接下来是统一的运维平台，与部署类似，通常在定位某个容器的问题的时候，需要通过kubectl exec的方式完成。这样的问题是，kubectl 权限过高，同时登陆到容器中时可能会有误操作，从而引发新的问题。为了解决这些问题，我们做了一个统一的运维平台。首先，我们封装了一个类似于kubectl的客户端，提供文件的上传、下载，快速拉起一个容器，调试某个容器等功能。这个客户端可以通过统一运维平台接入到K8s中，在运维平台中，我们可以收敛所有对容器的运维操作，可以审计、过滤在容器中 执行的命令。同时，我们在工具中封装大量的高频操作的命令，让工具更方便易用。因为金融安全的要求，容器是默认关闭特权模式的。在定位某些问题时，可以通过运维平台有计划地放开一些特权，让业务同学可以快速定位相关问题。
接下来介绍一些复杂应用的容器化，比如PaaS应用的容器化。普通业务应用大部分是是无状态的应用，非常容易进行容器化。但是如果PaaS应用跟普通业务应用有很大区别，很多PaaS应用的组件之间会有复杂上下游依赖关系，增加了容器化复杂性。这里我们以Redis为例来介绍PaaS应用的容器化。微众的Redis主要有管理台、Observer、Proxy、Cluster等几个模块。管理台主要负责整个集群的管理，负责发起集群的扩缩容，修改集群的配置等。Observer负责观察集群的状态，Proxy提供了访问鉴权和熔断、降级服务等工作，Cluster是负责KV存储的模块。在对Redis发起扩容的时候，首先要通过管理台进行发起，调用WCS API的服务，WCS会通过操作K8s，增加对应服务副本数，等相对应的容器启动完成后，会将实例信息通知管理台，管理台感知到这个新增的实例之后，就会把这个实例的信息下发至Proxy，Proxy就可以把接入流量打到新的实例上去。
接下来是我们在基础架构上的容器服务化的工作。之前，在申请一个应用实例往往要做大量工作，要申请一个VM、划分资源、LB的配置工作、申请网络策略，最终才能部署应用，交付业务使用。在容器化初期，我们将前面的申请VM和划分资源这两步合并了，后面的工作还是需要做。在进一步优化之后，我们的目标是将把申请网络策略，申请VIP等工作全部做成自动化，这样用户在申请资源后就可以使用，不需要再另外关注防火墙、VIP这些问题。