再来看一下容器的网络的实践。在很多公司上云的时候都会选择一些开源的网络插件，假设我们选择了开源的网络会遇到一些问题，首先，有两套网络体系，没办法做直连，还有很多中间件、数据库进行容器化。第二，很难做IP固定，因为K8s云原生是不推荐做IP固定，但是我们必须要做。第三拆包、分包过程中所导致的性能损耗以及不稳定的情况，在我们一些网联交易的系统里面耗时非常敏感，不可以接受。
考虑到上述问题，我们选择了直接使用underlay的网络架构。我们把虚拟机和容器放到了同个网络层面上，这样一来，容器网络运维就转化成了网络部门同事熟悉的虚拟机运维，使用相同的防火墙策略。
这里简单提一下，公有云场景下，我们使用vpc将cvm和容器打通。
在微众的私有云上，我们选择了underlay，所以我们自研了适配的网络插件wecni。其工作原理是把容器的虚拟网卡插到了网桥上，然后使用交换机做网关。
由于我们需要固定IP，而IP又是和母机所在的TOR关联，因此我们实现了ipamd模块记录了容器、ip、机架的关系，业务应用发版、重启保持ip不变。
我们生产上还有另一个需求，在DMZ/ECN区，容器需要支持同时连内外网。对此，我们wecni支持单容器多网卡特性，在容器里配置两块虚拟网卡，默认出外网，内网使用静态路由表。
公有云上我们也希望腾讯云能早日支持这种Pod级的外网方案。
平台解决完网络问题之后要需要解决调度的问题，K8s原生的调度编排能力无法满足我们在dcn架构下的高可用部署需求，每组DCN是由一组应用和DB组成的数据单元，每组DCN支持一定容量的客户，我们的调度策略首要是实现DCN级别的高可用，而K8s的调度只能看到本集群的状况，数据中心有很多K8s，因此我们开发了一个全局调度服务，要跨K8s集群，跨业务部门的统一服务，能够精确控制每个子系统在每个DCN实地的数量，也要同时考虑未容器化的vm上的实例。
我们的容器调度编排除了支持了复杂的DCN高可用规则外，还支持基于应用画像的调度策略。应用画像系统收集prometheus的动态监控数据、CMDB定义的元数据推送至大数据平台，通过一定的算法生成应用画像，对子系统和应用进行打标签，最后通过亲和度、应用优先级打散相似实例的分布。现在支持应用属性、监控数据、运维属性、依赖关系数据的聚合。
下面是关于微众银行在容器方面的一些实践相关的介绍。
首先，介绍微众的日志系统。日志系统由三个模块组成，数据采集模块、数据缓存模块、数据处理展示模块，日志采集模块是通过一个标准Daemonset部署的日志Agent进行采集，每个业务容器都会将日志挂载到母机的特定目录中，日志Agent采集到数据后将数据上传到数据缓存模块，最终通过数据处理模块统一进行数据的处理和展示。在日志系统中实现了这样一些功能，比如有异常展示功能，通过Opentracing协议做异常定位和分析，此外还按照监管的要求，统一进行日志归档。另外还有实时流计算、指标的聚合查询等功能，方便在出现问题的时候能够快速定位问题。