TODO: NSM项目尚未能够完全成功运行! 需要通过Snort、ModSecurity等Docker做完善工作。
本文旨在介绍CNCF基金会下的Network Service Mesh的相关情况和使用方法总结。
Docker、Kubernetes、CNCF
Docker，作为轻量级虚拟化–容器的一种解决方案，在开源社区从诞生之初就备受瞩目。Docker能轻到近似二进制文件大小(可以参考裁减镜像)，占用极少的资源、同时保证isolation。但是在业务中部署容器却不是一件简单的事情，需要配置物理机和容器之间的交互，同时需要配置好各种监控以保证适时扩容。为了应对容器的这种问题，Kubernetes作为容器的编排工具出现了。Kubernetes是Google将其内部集群管理系统Borg(13年发布Omega)修改后于14年开源。2015年，谷歌和Linux基金会合作建立云原生计算基金会(CNCF)，旨在建立可持续的生态系统。Google此举可认为是通过开源打击其他云厂商，既然我商业化进展不顺、通过开源项目来引发混战也是不错的。Kubernetes在Security方面天然有Certificate和PKI、在Scheduling和Scalability天然考虑分布式(谷歌的分布式系统实力还是非常强大的)，加上虚拟化的一次开发到处部署，Restful API的现代化前端交互，Kubernetes集合了system设计的各种历史经验，对于云应用来说具有强大的吸引力。
随后，Kubernetes有了软件包管理系统Helm(类似Brew、apt或yum)、Minikube(本地可运行Kubernetes)、Prometheus(metric收集数据库)、OpenTracing(Debug工具)等等从2016年开始逐渐完善起来；到了2017年，Istio(微服务网络)发布，Kubernetes也在亚马逊、微软等开始推出商用，转眼到了2020年，Kubernetes可以说已经是System方向必须掌握的工具了。
目前围绕Kubernetes已有一系列的开源项目，相关信息都可以在CNCF的官网上找到。阿里、华为都有贡献开源项目。
NSM介绍
k8s在网络方面有一个缺陷，就是不能配置L2/L3层的处理；对于应用来说，看到TCP层已经足够了(分布式系统直接就基于RPC设计系统)，不需要L2/L3层的东西；k8s的访问安全性是通过Authentication实现的，因此不需要在意流量如何如何。但是如果想把k8s放到公网上，就不得不考虑更多的L2/L3层的网络功能，比如Middlebox(Firewall->DPI->VPN形成的基于安全的考虑设立的SFC)，比如电信网的计费网关、QoS功能模块等。但是从纯Zero-Trust的角度，MB似乎是要尽量舍弃的？
Network Service Mesh项目的设立之初就是为了应对这个问题，详细的说明介绍可以参考这个链接。有些重点内容挑出来如下
NSM并没有对Kubernetes的CNI模型进行扩展或者修改，而是采用了一套与CNI完全独立的新机制来以实现这些高级的网络需求。
NSM参考了Kubernetes中Service的概念提出了Network Service。Network Service对外提供的是L2/L3层的网络服务，即对数据包进行处理和转发，而不会终结数据包。
我们可以将NSM和SDN结合使用，可以通过NSM中的Network Service接入SDN提供的强大的网络服务。下图是在NSM中利用SDN为应用提供QoE（Quality of Experience）服务的一个例子。
NSM使用
NSM的直接安装
- 安装k8s以及k8s的包管理器helm
- 通过helm增加repo和安装
1 | helm repo add nsm https://helm.nsm.dev/ |
NSM的模拟使用
- 下载NSM代码和NSM example(在github中)到同一目录下
- 安装example给出的说明, 进行makefile的处理[^footnote-kind]。
- 安装
NSM在Github下载后
Reference
[^footnote-kind]: 主要是安装k8s本地模拟器: kind； 关于kind的简单说明可以查看ref。
