共计 3265 个字符，预计需要花费 9 分钟才能阅读完成。
* 在金融行业数字化转型的驱动下，国有银行、股份制银行和各级商业银行也纷纷步入容器化的过程。
如果以容器云上生产为指标，那么整个容器云平台的设计、建设和优化对于银行来说是一个微小的挑战。如何更好地利用云原生技术，帮忙银行实现麻利、轻量、疾速、高效地进行开发、测试、交付和运维一体化，从而重构业务，推动金融科技的倒退，是个长期课题。
上期咱们聊到云原生的底层计算资源该怎么选，本期金融云原生漫谈，将持续和大家独特探讨如何构建高可用、高并发、高性能的云原生容器网络。*
谈起云原生基础设施构建，就必然会提到云原生的容器网络。
家喻户晓，容器网络作为云原生的基石，是云原生平台必不可少的根底组件，也是云原生容器平台构建时的最大挑战之一。
随着银行利用数量和类型的进一步增多，对网络复杂度的要求也越来越高。银行的利用有本身特点，银行利用的治理级别不同，拜访特色也不同，须要思考如何兼容传统网络架构，实现传统网络和容器网络之间的互联互通，同时，传统利用容器化迁徙后如何实现固定 IP，以及对于容器多网络立体、多网卡的治理，多租户和跨云网络、容器流量的监测、调度与 QoS 等也都面临新的挑战。
目前有很多银行容器网络的外部其实是一个“黑盒”，容器外部和内部的网络没有买通，也无奈实现跨云多网络集群的互通，亟需进行转型革新。
在这种压力下，构建高性能的容器网络就显得尤为重要，然而：
- 两地三核心架构中的容器网络怎么革新可用性更高？
- 高并发场景下，银行的容器网络如何布局？
- 如何打造高性能的容器网络？
本篇文章将为你解答。
两地三核心架构中的容器网络怎么革新可用性更高？
面对利用的高可用性需要，很多银行都在踊跃建设两地三核心，或者异地灾备建设。那么如何对接或革新容器平台的网络，以满足容器平台中利用与传统虚拟机、物理机中旧业务零碎的互相通信，防止或尽可能减少对银行现有网络管理模式的冲击呢？
首先从整体来看，两地三核心架构下的容器网络革新，须要根据容器平台所依赖的 IaaS 能力而定。譬如容器平台部署在传统虚拟化平台，也没有启用 SDN 网络，如果容器网络设计为 hostnetwork 模式，则容器 POD 的利用和传统虚拟机、物理机的旧业务零碎是间接能够通信的。
如果容器平台的宿主节点在用 IaaS 的虚拟机，且启用了 SDN 网络，容器平台启用的 CNI 个性，则容器 POD 的利用能够和 IaaS 虚拟机的业务利用间接通信。如果和传统网络中的旧利用通信，则须要开启 IaaS 的 NAT 个性或者为宿主节点配置 EIP 地址。
银行容器平台中的容器利用与传统虚拟机、物理机中旧业务零碎的互相通信遇到最多的问题都集中在 IP 有状态这件事件上，因为传统容器平台上利用如果要实现对外通信，次要有两种形式：一种是基于宿主机 IP+ 端口，另外一种是基于域名，这两种利用的对外裸露模式都暗藏了容器平台上利用的实在 IP 信息，所以不仅会造成传统虚拟机、物理机中旧业务零碎无奈和容器平台中利用的 IP 扁平化拜访的问题，同时也让银行现有网络管理模式无奈对于容器平台上的利用进行 IP 定位和网络资源管理。
针对以上问题，银行在两地三核心架构中能够采纳 Kube-OVN Underlay 网络解决方案对接或革新容器平台网络，Kube-OVN underlay 网络解决方案通过采纳 OpenStack 的 ovs 二层虚构替换技术，将容器平台上的利用和传统虚拟机、物理机中旧业务零碎拉平到一个二层网络立体，让容器平台上的容器利用和传统虚拟机、物理机一样的应用底层网络资源并实现 IP 中转通信。这样能够使银行现有的网络管理模式在 Kube-OVN 的 underlay 容器网络下仍然无效。
高并发场景下，银行的容器网络如何布局？
在高并发场景下，银行传统的网络架构绝对短少灵活性，已无奈满足日益增长的敏态业务需要。采纳容器后，容器网络如何兼容传统网络和平安治理，并提供扩大的灵活性，是每一个银行用户都在关注的问题。
咱们在金融行业的大量实际中发现，云原生的平台化思维和传统 IT 的条线式思维存在着肯定矛盾。云原生心愿通过一个 yaml 文件形容利用，所有的部署工艺、利用的计算、存储、网络应该可能自动化生成，而银行专门的网络部门都有严格定义的网络标准，它们之间的矛盾在银行业是特地突出的。
从理论落地的角度来看，能够采取以下几点倡议来有针对性地解决这个矛盾，正当布局银行的容器网络。
首先，在技术思路方面，倡议 underlay 和 overlay 同时进行。目前容器网络两个根本技术思路是 overlay 和 underlay，overlay 是建设虚构网络，容器采纳虚构 IP；underlay 是复用上层物理网络，容器像虚拟机一样应用上层网络。从某种意义上说，overlay 是平台化思维的产物，underlay 是条线式治理思维的产物。某些银行能够容许大规模 overlay，个别场景采纳 underlay（例如多播、运管性能等），这样两个一起搞，同时兼顾。另外还有些银行目前根本没有 overlay 的空间，更多采纳 underlay 治理；而还有些银行在虚拟化上建设容器平台，underlay 不能用（underlay 可能会和 IaaS 网络有抵触），导致只能用 overlay。鉴于这些状况，我的倡议是两个都上，不同的集群采纳不同的计划，甚至通过多网卡同时采纳 underlay 和 overlay。即使仅有一种需要，也两种计划都布局到位，保障将来拓展的可能性。
在建设思维方面，能够参考 IaaS 的网络建设思维。IaaS 典型的网络思维是三网拆散、四网拆散，容器网络目前布局中，以前不太思考这种计划，这是因为以前更多是 IaaS 负责基础设施网络，然而如果一旦在裸金属上部署容器平台，那么 IaaS 原来遇到的问题，明天容器平台也会遇到。
在容器网络与内部网络通信管控方面，能够通过对立的接入点（ingress、egress）管控容器内网的网络互访，增强到“稳态”和“敏态”之间的平安交互。
在 networkpolicy 治理方面，如果有可能，更多采纳 networkpolicy 为每个利用设置平安管控策略，这也是更“云原生”的一种做法。
从集群治理角度来看，容器云有多个集群，其中高并发高性能集群中，宿主机上应用传统网络，容器网络应用 ovs。高容量高扩展性的集群，宿主机上采纳 IaaS 的基于 VPC 隔离的 SDN 网络，容器网络应用 CNI 组件，间接 offload 到宿主机网络上。
如何打造高性能的容器网络？
一些银行尽管针对传统网络曾经做了很多优化工作，因为网络插件的简化，还有许多性能问题没有解决，兴许这些问题在容器云里不是问题，然而到金融场景里就是比拟大的挑战了。
因而，咱们须要一个工具实现从传统网络向容器网络的平滑过渡，目前业内也曾经呈现了一些比拟好的 CNI 计划。以目前比拟沉闷的 Kube-OVN 网络计划为例，它以成熟的 OVS 作为容器网络底座，通过将 OpenStack 畛域成熟的网络性能平移到 Kubernetes，交融了平安强化、智能运维、硬件加速等多方面的个性，极大加强了 Kubernetes 容器网络的安全性、可运维性、管理性和性能。
通过 Kube-OVN 的一些调优，能够实现和现有容器网络有等同流量性能，并未产生性能损耗的景象。比方某股份制银行，之前用到 Calico 计划，是最靠近于物理网络性能的吞吐量，通过比照，Kube-OVN 在性能上与 Calico 是相当的，另外它还能够反对 OVS、DPDK 这种自定义协定栈以及硬件加速计划，能够晋升整个的容器性能。通常金融行业在上外围零碎时要通过严格的容器网络性能的压测，测试后果根本能达到预期，解决了性能上的后顾之忧。
另外还联合了一些在不同的银行里落地的教训，尤其是把一些平安或者管控、监管侧的要求，联合起来做了相应的构建，可能无效地帮忙银行用户构建更加适配金融云原生的高性能容器网络。
感兴趣的敌人们也能够具体理解一下（https://github.com/kubeovn/ku…）。
最初，心愿大家都可能根据本身企业的理论状况，顺利构建高并发、高可用、高性能的云原生容器网络，持重、高效地实现云原生化转型。
