更新容器内容

.vuepress/config.js

@@ -266,9 +266,7 @@ export default defineUserConfig({
                         sidebarDepth: 1,
                         children: [
                            "/container/linux-vnet.md",
-                           "/container/container-network.md",
-                           "/container/Cilium.md"
-                        ]
+                           "/container/container-network.md"                        ]
                     },
                     '/container/storage.md',
                     '/container/resource-limit.md',
@@ -310,6 +308,7 @@ export default defineUserConfig({
                 link: '/ServiceMesh/summary.md',
                 children: [
                     '/ServiceMesh/MicroService-history.md',
+                    '/ServiceMesh/overview.md'
                 ]
             },
              {

ServiceMesh/MicroService-history.md

@@ -1,6 +1,7 @@
-# 8.1 微服务架构演进
+# 8.1 服务治理形式的演进
 
-自 2011 年微服务架构理念提出以来，10 余年间一批又一批技术框架和理念不断涌现出来，按照笔者的理解，这期间典型的架构模式已经迭代了四代。
+谈论微服务架构如何优雅之前，我们得清楚知道微服务架构是一个分布式架构，分布式架构的第一定律是“不要使用分布式”，
+自 2011 年微服务架构理念提出以来，10 余年间一批又一批技术框架和理念不断涌现出来，如果以技术的表现形式划分，服务治理的模式已经迭代了四代。
 
 在第一代微服务架构中，以 RPC 通信为代表，首要解决的是微服务之间的通信问题。技术框架代表如阿里 Dubbo，跨语言平台的框架 Thrift、gRPC...
 这个阶段，特别是早期版本的 RPC 框架，应用除了要实现业务逻辑之外，还需要自行解决上下游寻址、通信以及容错等问题。随着服务规模的扩大，服务寻址逻辑也愈加变的复杂，哪怕是同一种开发语言的另外一个应用，上述的微服务基础能力也要再重新实现一遍。
@@ -27,7 +28,9 @@
 	<img src="../assets/micro-service-arc-3.png" width = "480"  align=center />
 </div>
 
-第四代微服务架构是目前业界提出的多运行时微服务架构，利用最近的 FaaS 和 AWS 的 Lambda 等无服务器技术来进一步简化微服务的开发和交付。
+第四代微服务架构是目前业界提出的多运行时微服务架构，Service Mesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多需求，比如“协议转换”、“状态管理”等，Multi-Runtime 架构提出将各种各样的分布式能力外移到独立 Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime”（多运行时） 架构。
+
+利用最近的 FaaS 和 AWS 的 Lambda 等无服务器技术来进一步简化微服务的开发和交付。
 
 在第四代微服架构中，微服务由一个应用进一步简化为微逻辑(Micrologic)，变成短暂的功能的集合。 
 

ServiceMesh/overview.md

@@ -0,0 +1,17 @@
+# 服务网格的产品与生态
+
+互联网大厂凭借其技术方面的深厚功力与持续投入，在最近几年已经完成了服务网格从初期探索到大规模生产应用的跨越；中小型互联网公司也紧跟大厂步伐，顺应云原生技术浪潮，完成了服务网格“初体验”
+
+2016年1月，Buoyant 初次发布 Linkerd，第一代的 Linkerd 以Scala编写，作为业界第一个开源的service mesh方案，linkerd 绝大部分关注点都是如何做好 proxy 并完成一些通用控制面的功能，专注于 proxy 的还有 Lyft 开发的 envoy，envoy 基于C++ 11编写，是CNCF 继 Kubernetes、Prometheus 第三个孵化成熟的项目，无论是理论上还是实际上，后者性能都比 Linkderd 更好。这两个开源实现都是以 sidecar 为核心，，但是，当你在容器中大量部署 sidecar 以后，如何管理和控制这些 sidecar 本身就是一个不小的挑战。于是，第二代 Service Mesh 应运而生。
+
+还是仅限于数据层面的代理功能，虽然理念先进，但其明显的资源消耗、性能影响广受诟病。
+2017年5月，Google、IBM、Lyft 宣布新一代的服务网格 Istio 开源，有巨头背书以及新增控制平面的设计理念让 Istio 得到极大关注和发展，并迅速成为 ServiceMesh 的主流产品。
+
+ServiceMesh 最基础的功能毕竟是 sidecar proxy，提到 proxy，怎么能少得了以 Nginx 代表的远古代理亦或资深微服务API玩家。毫不意外，nginx 推出了其 service mesh 的开源实现：nginMesh。APISIX 也在 2010年 5月推出了 apisix-mesh-agent 产品。与 William Morgan 的死磕策略不同，这些在 Proxy 领域根基深厚玩家，从一开始就没有想过要做一套完整的第二代 Service Mesh 开源方案，而是直接宣布兼容 Istio, 作为 Istio 的数据面，由于 nginx 在反向代理方面广泛的使用，以及运维技术的相对成熟，nginMesh在sidecar proxy 领域应该会有一席之地。
+
+Kong 推出了 ServiceMesh kuma，有意思的是 Kong 选择了 Envoy 作为数据平面，而非 Kong 网关核心内核  nginx+openresty。远古玩家 Nginx 也祭出自己新一代的产品 Nginx Service Mesh，主打简化 Service Mesh，并顺势推出商业产品 Aspen Mesh。
+
+<div  align="center">
+	<img src="../assets/service-mesh-overview.png" width = "500"  align=center />
+	<p>ServiceMesh 生态</p>
+</div>

container/container-network.md

@@ -1,20 +1,33 @@
 # 容器间通信模型
 
-在 Docker、Kubernetes 之前，所有接触过 OpenStack 的人心里都有一个难以释怀的阴影，那就是网络问题。于是，后来者 kubernetes 明智地避开了这个“雷区”，把网络功能从容器运行时或者编排系统剥离出去，让更专业的提供商通过插件的设计实现。如此，把网络变成外部可扩展的功能，需要接入什么样的网络，设计一个对应的网络插件即可。
+这一节，我们走进容器网络通信，去了解容器间通信的逻辑以及 Kubernetes 集群的网络模型设计。如果把 Pod 比作超亲密容器组，那么根据亲密关系的远近，也带来以下几个以距离进行分类的容器通信场景。
 
-这一节，我们走进容器网络通信，去了解容器间通信的设计以及 Kubernetes 集群的网络模型定义。如果把 Pod 比作超亲密容器组。由亲密关系的远近，也带来以下几个以距离进行分类的容器通信模型。
 
-- 同一个 Pod 内容器 A 与 容器 B 是如何通信
-- 同一个 Node 中的 Pod 如何通信
+kubernetes 集群初始化配置文件 networking 部分如下。
 
-**不同 Node 之间的 Pod 如何通信**
+```
+...
+networking:
+  serviceSubnet: "172.18.0.0/20"
+  podSubnet: "172.16.0.0/16"
+  dnsDomain: "cluster.local"
+....
+```
+
+整个集群的 Service 和 Pod 的 CIDR 我们分别划分为 172.18.0.0/20、172.16.0.0/16 ，这样我们 65,536 个 Pod 的容量。
+
+
+根据上面的网络配置模型，Pod 完成了所示的本地通信、同节点通信、跨节点通信。
+
+- 本地通信就是 Pod 内部不同容器间的通信，同一个 Pod 内的容器共享同一个网络命名空间，所以它们之间通过 Loopback 回环接口，保证端口不冲突就能完成通信。
+- 同节点之间的通信，Pod 通过 veth 设备全部关联在同一个cni0网桥中，实际上就是虚拟 Linux 网桥内部的通信，和现实中二层局域网内部设备之间通信没有差别。
+- 跨节点的通信只能通过宿主机的物理网卡进行，cni0 网桥流转到宿主机的 eth0 接口，再发送给 VPC 路由，VPC 路由到目标节点。flannel 收到数据包之后解封，再发送到 cni0 网桥，然后完成通信。
 
-Kubernetes 的网络模型设计的一个基本原则，**每个 pod 都拥有一个独立的 IP 地址，而且假定所有的 Pod 都在一个可以直接联通的、扁平的网络空间中，不管它们是否运行在同一个 Node（宿主机）中，都可以直接通过对方的 IP 进行访问**。
 
 
 ## 网络插件生态
 
-Kubernetes 本身不实现集群内的网络模型，而是通过将其抽象出来提供了 CNI 接口给第三方实现，只要最终的网络模型符合标准即可。这样一来节省了开发资源可以集中精力到 Kubernetes 本身，二来可以利用开源社区的力量打造一整个丰富的生态。现如今，支持 CNI 的插件多达二十几种，如下图所示[^1]。
+Kubernetes 本身不实现集群内的网络模型，而是通过将其抽象出来提供了 CNI 接口由更专业的第三方提供商实现，如此，把网络变成外部可扩展的功能，需要接入什么样的网络，设计一个对应的网络插件即可。这样一来节省了开发资源可以集中精力到 Kubernetes 本身，二来可以利用开源社区的力量打造一整个丰富的生态。现如今，支持 CNI 的插件多达二十几种，如下图所示[^1]。
 
 <div  align="center">
 	<img src="../assets/cni-plugin.png" width = "500"  align=center />
@@ -23,9 +36,11 @@ Kubernetes 本身不实现集群内的网络模型，而是通过将其抽象出
 
 以上几十种网络插件笔者不可能逐一解释，但跨主机通信不论形式如何变化，总归为以下几种。
 
-- **Overlay 模式**：笔者在 VXLAN 篇已经介绍过 Overlay 网络通信的原理，这是一种虚拟的上层逻辑网络，其优点是不受底层网络限制，只要是三层网络互通，就能完成跨数据中心的网络互联，但弊端是数据封包、解包有一定的计算压力和网络延迟消耗。在一个网络受限的环境中（譬如不允许二层通信，只允许三层转发），那么就意味着只能使用 Overlay 模式网络插件。常见的 Overlay 模式网络插件有 Cilium（VXLAN 模式）、Calico（IPIP 模式）以及 Flannel（VXLAN）等。
+- **Overlay 模式**：笔者在 VXLAN 篇已经介绍过 Overlay 网络通信的原理，这是一种虚拟的上层逻辑网络，其优点是不受底层网络限制，只要是三层网络互通，就能完成跨数据中心的网络互联，但弊端是数据封包、解包有一定的计算压力和网络延迟消耗。在一个网络受限的环境中（譬如不允许二层通信，只允许三层转发），那么就意味着只能使用 Overlay 模式网络插件。常见的 Overlay 模式网络插件有 Cilium（VXLAN 模式）、老牌的 Calico（IPIP 模式）以及 Flannel（VXLAN）等。
+
+- **三层路由**，主要是借助 BGP/hostgw 等三层路由协议完成路由传递。这种方案优势是传输率较高，不需要封包、解包，缺点是 BGP 等协议在很多数据中心并不支持，且设置也很麻烦。常见的路由方案网络插件有 Calico（BGP 模式）、Cilium（BGP 模式）。
 
-- **三层路由**，主要是借助 BGP 等三层路由协议完成路由传递。这种方案优势是传输率较高，不需要封包、解包， 但 BGP 等协议在很多数据中心内部支持，设置较为麻烦。常见的路由方案网络插件有 Calico（BGP 模式）、Cilium（BGP 模式）。
+- **underlay 模式** 基于 macvlan、ipvlan 等，这种模式所配置的容器网络同主机网络在同一个 LAN 里面，可以具有和主机一样的网络能力，并且没有其它诸如 bridge 等方式带来的 bridge 处理和地址翻译的负担，这种方式能最大限度的利用硬件的能力，往往有着最优先的性能表现，但也由于它直接依赖硬件和底层网络环境限制，必须根据软硬件情况部署，没有 overlay 那样开箱即用的灵活性。
 
 
 此外，对于容器编排系统来说，网络并非孤立的功能模块，还要能提供各类的网络访问策略能力支持，譬如 Kubernetes 的 Network Policy 这种用于描述 Pod 之间访问这类 ACL 策略以及加密通信，这些也明显不属于 CNI 范畴，因此并不是每个 CNI 插件都会支持这些额外的功能。如果你有这方面的需求，那么第一个就要排除 Flannel 了，如果按功能的丰富度而言，受到广泛关注的无疑是 Calico 和 Cilium。

container/linux-vnet.md

@@ -120,7 +120,7 @@ VXLAN 你可能没有听说过，但 VLAN（Virtual Local Area Network，虚拟
 
 不过 VLAN 有一个非常明显的缺陷，就是 VLAN tag 的设计，当时的网络工程师未曾想到云计算在现在会如此普及，只有 12 位来存储 VLAN ID，标准定义中 VLAN 的数量只有 4000 个左右，这显然无法支持大型数据中心数以万记的设备数，另外，VLAN 的二层范围一般较小且固定，也无法支持虚拟机大范围的动态迁移。
 
-为了解决上面这些问题，IETF 定义了 XXLAN 规范，这是三层虚拟化网络（Network Virtualization over Layer 3，NVO3）的标准技术规范之一，是一种典型的 overlay 网络。VXLAN 完美地弥补了 VLAN 的上述不足，一方面通过 VXLAN 中的 24 比特 VNI 字段（如图 1-5 所示）提供多达 16M 租户的标识能力，远大于 VLAN 的 4000；另一方面，VXLAN 本质上在两台交换机之间构建了一条穿越数据中心基础 IP 网络的虚拟隧道，将数据中心网络虚拟成一个巨型“二层交换机”，满足虚拟机大范围动态迁移的需求。
+为了解决上面这些问题，IETF 定义了 VXLAN 规范，这是三层虚拟化网络（Network Virtualization over Layer 3，NVO3）的标准技术规范之一，是一种典型的 overlay 网络。VXLAN 完美地弥补了 VLAN 的上述不足，一方面通过 VXLAN 中的 24 比特 VNI 字段（如图 1-5 所示）提供多达 16M 租户的标识能力，远大于 VLAN 的 4000；另一方面，VXLAN 本质上在两台交换机之间构建了一条穿越数据中心基础 IP 网络的虚拟隧道，将数据中心网络虚拟成一个巨型“二层交换机”，满足虚拟机大范围动态迁移的需求。
 
 <div  align="center">
 	<img src="../assets/vxlan-data.png" width = "300"  align=center />