一、简介

OVS甚至可以说是网络虚拟化里最重要的工业级开源产品，OVS模仿物理交换机设备的工作流程，实现了很多物理交换机当时才支持的许多网络功能。OVN提供了许多原生的虚拟网络功能，提升了OVS的工作效率和性能。
OVN是OpenvSwitch项目组为OpenvSwitch开发SDN控制器，同其他SDN产品相比，OVN对OpenvSwitch 及OpenStack有更好的兼容性和性能。
在2016年的OpenStack Austin 峰会上，OVN项目组有个演讲提到了的OVN存在的意义（目标），原文是

• Production-quality
• Straightforward design
• Scale to 1000s of hypervisors (each with many VMs/containers)
• Improved performance and stability over existing OpenStack OVS plugin
• Become preferred method for OpenStack+OVS integration for the majority of use cases

中文翻译如下：

• 可用于生产环境
• 简洁的设计
• 支持1000台以上的物理机环境（也支持相当数量的虚拟机/容器环境）
• 基于已有的OpenStack OVS 插件 来提升性能和稳定性
• 成为OpenStack+OVS集成场景下的首选方案

二、OVN的实现了哪些功能？拥有哪些特性？

Logical switches：逻辑交换机，用来做二层转发。
L2/L3/L4 ACLs：二到四层的 ACL，可以根据报文的 MAC 地址，IP 地址，端口号来做访问控制。
Logical routers：逻辑路由器，分布式的，用来做三层转发。
Multiple tunnel overlays：支持多种隧道封装技术，有 Geneve，STT 和 VXLAN。
TOR switch or software logical switch gateways：支持使用硬件 TOR switch 或者软件逻辑 switch 当作网关来连接物理网络和虚拟网络。

OVN网关发布的时候，还存在着某些限制：

• 网关路由器仅可以经由逻辑交换机连接到其他路由器，而DLR已经可以经由一条链路直连路由器。社区正在进行相关工作来解决掉这个限制。

• OVN支持多个网关路由器绑定到环境中，这意味着可以逻辑空间执行入站ECMP路由。然而，OVN当前不支持网关路由器之间的出站ECMP。这个特性也同样是OVN未来需要加强的。

三、架构

基于OVN的neutron网络架构如下

总的来说，ovn的出现 既大大精简了openstack neutron侧架构的实现，又提高了网络侧的性能。

[ovs ovn 学习资料]

1、Open Virtual Networking With Docker

http://docs.openvswitch.org/en/latest/howto/docker/

2、Multi-Host Docker network

https://wiredcraft.com/blog/multi-host-docker-network/

3、ovn-namespace

https://github.com/shettyg/ovn-namespace

4、OVN简介PPT

http://openvswitch.org/support/slides/OVN_Barcelona.pdf

5、What is Open Virtual Network (OVN)? How It Works （包含了各种关于网络虚拟化的介绍的连接）

https://www.sdxcentral.com/sdn/network-virtualization/definitions/what-is-open-virtual-network-ovn-how-it-works/

6、Open vSwitch 相关论文

http://openvswitch.org/support/papers/

７、OVN, Bringing Native Virtual Networking to OVS

https://networkheresy.com/category/open-vswitch/

8、基于Open vSwitch的OpenFlow实践

http://www.chenshake.com/based-on-openflow-practices-open-vswitch/

9、ovs源码分析

http://blog.csdn.net/column/details/openvswitch.html

10、ovs orbit

https://ovsorbit.org/

11、introduction to ovn

http://galsagie.github.io/2015/04/20/ovn-1/

12、Russell Bryant的博客

https://blog.russellbryant.net/category/ovs/

13、ovn architecture

http://openvswitch.org/support/dist-docs/ovn-architecture.7.html

14、OVN Logical Flows and ovn-trace

https://blog.russellbryant.net/2016/11/11/ovn-logical-flows-and-ovn-trace/

15、Justin Pettit的个人主页（其中包含了ovs, ovn相关的各种论文，博客和视频）

http://yuba.stanford.edu/~jpettit/

16、ovs 2.5.0源码分析

http://blog.csdn.net/one_clouder/article/category/6359278/1

17、netwoking-ovn - OpenStack Neutron integration with OVN

https://docs.openstack.org/networking-ovn/latest/

18、OVN路由功能详解

https://www.ibm.com/developerworks/cn/cloud/library/1605-ovn-introduction/index.html

19、OVS博客

http://www.cnblogs.com/popsuper1982/p/5848879.html

20、OVSDB RFC

https://datatracker.ietf.org/doc/rfc7047/

21、openstack底层技术-openflow在ovs中的应用

http://www.isjian.com/openstack/openstack-base-openflow-in-openvswitch/

大家好，我是小白。今天给白白们讲解一下Kubernetes中的概念CRI (Container Runtime Interface)- 容器运行时接口。
一、CRI的由来
容器的兴起起自Docker，后来有了Kubernetes，所以在Kubernetes CRI 出现之前（也就是 Kubernetes v1.5 之前），Docker 作为第一个容器运行时，Kubelet 通过内嵌的 dockershim 操作 Docker API 来操作容器，进而达到一个面向终态的效果。在这之后，又出现了一种新的容器运行时 - rkt，它也想要成为 Kubernetes 支持的一个容器运行时，当时它也合到了 Kubelet 的代码之中。这两个容器运行时的加入使得 Kubernetes 的代码越来越复杂、难以维护。之后 hyber.sh 加入社区，也想成为第三个容器运行时。

此时就有人站出来说，想到了标准化，将容器运行时的操作抽象出一个接口，将 Kubelet 代码与具体的容器运行时的实现代码解耦开，只要实现了这样一套接口，就能接入到 Kubernetes 的体系中，这就是我们后来见到的 Container Runtime Interface (CRI)。

Read More

大家好，我是小白。今天给大家讲解一下Linux下的资源控制cgroup。
提到cgroup，可能有的同学一时不太清楚做什么用的，但大家应该都用过openstack虚拟机或者docker/kubernetes容器，套餐1C2G，如何实现的呢，答案就是cgroup啦~

一、何为cgroup
Linux cgroups 的全称是 Linux Control Groups，它是 Linux 内核的特性，主要作用是限制、记录和隔离进程组（process groups）使用的物理资源（cpu、memory、IO 等）。
cgroups 从设计之初使命就很明确，为进程提供资源控制，它主要的功能包括：
资源限制：限制进程使用的资源上限，比如最大内存、文件系统缓存使用限制
优先级控制：不同的组可以有不同的优先级，比如 CPU 使用和磁盘 IO 吞吐
审计：计算 group 的资源使用情况，可以用来计费
控制：挂起一组进程，或者重启一组进程
目前 cgroups 已经成为很多技术的基础，比如 Openstack、LXC、Docker、Kubernetes、systemd等。

Read More

大家好，我是小白。今天给大家讲解一下grpc通信

一、先了解rpc
远程过程调用（英语：Remote Procedure Call，缩写为 RPC）这个应该都有所耳闻，这是一种计算机通信协议。该协议允许运行于一台计算机的程序调用另一个地址空间（通常为一个开放网络的一台计算机）的子程序，而程序员就像调用本地程序一样，无需额外地为这个交互作用编程（无需关注细节）。RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。
二、了解gRPC
这些年云计算最火热的莫过于Kubernetes，随之带动了微服务的发展。而分布式/微服务之间的通信, 自然会联想到rpc通信。
gRPC是一个由Google开源的，跨语言的，高性能的远程过程调用（RPC）框架，能够运行于任意环境之中。最初由谷歌进行开发。它使用HTTP/2作为传输协议，使用 Protocol Buffers 作为序列化协议。
三、gRPC好处
*现代高性能轻量级 RPC 框架。
*协定优先 API 开发，默认使用协议缓冲区，允许与语言无关的实现。
*可用于多种语言的工具，以生成强类型服务器和客户端。
*支持客户端、服务器和双向流式处理调用。
*使用 Protobuf 二进制序列化这会大幅减少需要传输的数据量，从而大幅提高性能。
*gRPC可以方便地支持流式通信。

Read More

Kubernetes 主要概念和对象介绍有下面这些。
Autoscaling (HPA)
ConfigMap
CronJob
CustomResourceDefinition
DaemonSet
Deployment
Ingress
Job
LocalVolume
Namespace
NetworkPolicy
Node
PersistentVolume
Pod
PodPreset
ReplicaSet
Resource Quota
Secret
SecurityContext
Service
ServiceAccount
StatefulSet
Volume

Read More

大家好，我是小白。今天给大家讲解一下云原生界的监控扛把子普罗米修斯Prometheus。

一、开源监控方案
开源监控系统种类繁多，随着这么多年技术的革新，云计算大数据等技术的发展, 目前还比较流行的是Prometheus、Nightingale、Open-falcon、Zabbix.
大家感兴趣可以自行Google了解一下这些监控系统，我理解各有利弊吧，根据实际场合选择最合适的吧,总而言之，Prometheus更适合云场景下吧。

二、Prometheus简介
Prometheus受启发于Google的Brogmon监控系统（相似的Kubernetes是从Google的Brog系统演变而来），从2012年开始由前Google工程师在Soundcloud以开源软件的形式进行研发，并且于2015年早期对外发布早期版本。2016年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目，同年6月正式发布1.0版本。2017年底发布了基于全新存储层的2.0版本，能更好地与容器平台、云平台配合。

Prometheus作为新一代的云原生监控系统，目前已经有超过650+位贡献者参与到Prometheus的研发工作上，并且超过120+项的第三方集成。

三、Prometheus优缺点
优点:
*自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)
*非常高效的存储 平均一个采样数据占 ~3.5 bytes左右，320万的时间序列，每30秒采样，保持60天，消耗磁盘大概228G。
*在多维度上灵活且强大的查询语言(PromQl), 数据查询语句表现力更强大，内置更强大的统计函数。
*不依赖分布式存储，支持单主节点工作
*通过基于HTTP的pull方式采集时序数据
*可以通过push gateway进行时序列数据推送(pushing)
*可以通过服务发现或者静态配置去获取要采集的目标服务器
*多种可视化图表及仪表盘支持
*支持对云或容器的监控，其他大多数监控系统主要对主机监控。
缺点:
*Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件(Event)、调用链(Tracing)。
*Prometheus 默认是 Pull 模型，HTTP请求 target的url 地址, 合理规划你的网络，尽量不要转发。
*Prometheus不提供持久的长期存储、异常检测、自动水平缩放和用户管理,需要合理选择 Federate、Cortex、Thanos等方案。

四、Prometheus监控全家桶
Prometheus主要由Prometheus Server、Pushgateway、Job/Exporter、Service Discovery、Alertmanager、Dashboard这6个核心模块构成。Prometheus通过服务发现机制发现target，这些目标可以是长时间执行的Job，也可以是短时间执行的Job，还可以是通过Exporter监控的第三方应用程序。被抓取的数据会存储起来，通过PromQL语句在仪表盘等可视化系统中供查询，或者向Alertmanager发送告警信息，告警会通过页面、电子邮件、钉钉信息或者其他形式呈现。

大家好，我是小白。上文中给白白们讲解了docker的入门知识，今天讲解一下docker的干活，常规以及高级用法吧。

下面以自定义启动一台nginx server为例为大家延时一下docker的魅力吧~
一、镜像使用
镜像是 Docker 的三大组件之一。
Docker 运行容器前需要本地存在对应的镜像，如果镜像不存在本地，Docker 会从镜像仓库下载（默认是 Docker Hub 公共注册服务器中的仓库），我们也可以搭建一个本地的镜像仓库比如docker registry或者harbor等。
默认社区docker hub已经提供了很丰富的镜像，比如直接docker pull nginx 即可，这里以自定义diy一下nginx镜像为例尝试一下吧。

下载镜像

1

#docker pull centos:7

Read More

大家好，我是小白。下面由我给白白们讲解一下火热的容器技术Docker

Linux容器技术

Linux 容器LXC 是一个在单一 Linux 主机上提供多个隔离的 Linux 环境的操作系统级虚拟技术。不像虚拟机（VM），容器并不需要运行专用的访客guest操作系统。容器们共享宿主机的host操作系统内核，并使用访客操作系统的系统库来提供所需的功能。由于不需要专用的操作系统，因此容器要比虚拟器启动快得多。
容器借助 Linux 内核的 Namespaces、Apparmor、SELinux 情景模式profile、chroot 和 CGroup 等功能来提供类似于虚拟机的隔离环境。Linux 的安全模块可以确保正确地控制容器对宿主机和内核的访问，从而避免各种入侵活动。此外，在宿主机上可以运行不同的 Linux 发行版，只要它们运行在同样的 CPU 架构下。

简单来说，容器技术就是基于Linux内核提供的一套进程隔离技术，提供的是一种基于各种 Linux 发行版创建容器镜像的方法、一套管理容器生命周期的 API、与该 API 交互的客户端工具、保存快照的功能、在宿主机之间迁移容器实例的能力，等等。

Read More

大家好，我是小白。下面由我给白白们讲解一下Kata Container…

一、Kata Container背景

我们知道，容器的本质是宿主机上的进程，通过namespace实现资源隔离，通过cgroups实现资源限制，通过写时复制机制实现高效的文件操作。所以，容器和宿主机使用的是同一操作系统内核,如果公有云用户使用容器过程中探测到内核安全漏洞，后果可想而知。那么问题来了，如何提高容器的安全性？答案就是kata Container！

Kata Container的设计思路:

1. 如今最安全的莫过于VM虚拟机，只要能做到「secure of VM」，那这个安全性就可以满足公有云的需求了
2. 操作系统本身的容器机制没法解决安全性问题，需要一个隔离层，
   借鉴虚拟机的实现方式吧
3. 虚拟机中如果有个内核，就可以支持我们刚才所提到的 OCI 的定义，也就是说提供了 Linux ABI 的运行环境，在这个运行环境中跑一个 Linux 应用不太难实现。

Read More