diff --git "a/_posts/2018-05-12-\346\216\242\350\256\250\344\270\200\347\247\215\346\233\264\351\253\230\346\225\210\347\232\204\344\273\243\347\220\206\346\250\241\345\274\217.md" "b/_posts/2018-05-12-\346\216\242\350\256\250\344\270\200\347\247\215\346\233\264\351\253\230\346\225\210\347\232\204\344\273\243\347\220\206\346\250\241\345\274\217.md"
index d80d195..94d7cb4 100644
--- "a/_posts/2018-05-12-\346\216\242\350\256\250\344\270\200\347\247\215\346\233\264\351\253\230\346\225\210\347\232\204\344\273\243\347\220\206\346\250\241\345\274\217.md"
+++ "b/_posts/2018-05-12-\346\216\242\350\256\250\344\270\200\347\247\215\346\233\264\351\253\230\346\225\210\347\232\204\344\273\243\347\220\206\346\250\241\345\274\217.md"
@@ -1,6 +1,6 @@
 ---
 description: "
-Service Mesh 提供了微服务化开发的新思路，核心思想是构建一个代理转发网络并结合控制和转发分离的做法来对成千上万个微服务间做流量、策略、安全等管理，而另一方面 Linux Kernel 提供一种运行时高效扩可编程的网络注入机制 eBPF，借此能实现 L47 层代理转发。假设借助 eBPF，作为 Service Mesh 的数据转发层，对接 Pilot、Mixer 等控制面，实现策略、流量和安全管理，是不是一种更高效的方式？这会比 Envoy 拥有更好的性能，虽然性能未必是 Mesh 首要考虑的问题，后搜索发现 Cilium 果然做了类似的尝试，详情见 [http://docs.cilium.io/en/latest/gettingstarted/istio/](http://docs.cilium.io/en/latest/gettingstarted/istio/)，但对接的方式很特别，并不像 Envoy 一样，为每一个 Pod 部署一个 Envoy 容器，而是在多个 Pod 外部署一个 Cilium，以 Kubernetes Daemon Set 模式部署，为多个 Pod 进行代理，对控制器层面的 Pilot 做了定制，部署配置如下：
+Service Mesh 提供了微服务化开发的新思路，核心思想是构建一个代理转发网络并结合控制和转发分离的做法来对成千上万个微服务间做流量、策略、安全等管理，而另一方面 Linux Kernel 提供一种运行时高效扩可编程的网络注入机制 eBPF，借此能实现 L47 层代理转发。假设借助 eBPF，作为 Service Mesh 的数据转发层，对接 Pilot、Mixer 等控制面，实现策略、流量和安全管理，是不是一种更高效的方式？这会比 Envoy 拥有更好的性能，虽然性能未必是 Mesh 首要考虑的问题，后搜索发现 Cilium 果然做了类似的尝试，详情见 http://docs.cilium.io/en/latest/gettingstarted/istio/ ，但对接的方式很特别，并不像 Envoy 一样，为每一个 Pod 部署一个 Envoy 容器，而是在多个 Pod 外部署一个 Cilium，以 Kubernetes Daemon Set 模式部署，为多个 Pod 进行代理，对控制器层面的 Pilot 做了定制，部署配置如下：
 "
 ---