diff --git a/content/zh/blog/2018/delayering-istio/index.md b/content/zh/blog/2018/delayering-istio/index.md index 0b7315d9673e6..1852487d82b4b 100644 --- a/content/zh/blog/2018/delayering-istio/index.md +++ b/content/zh/blog/2018/delayering-istio/index.md @@ -34,11 +34,11 @@ Sidecar proxy 模式成就了很多奇迹。Sidecar 身处微服务的数据路 值得注意的一点是，AppSwitch 的客户端和服务器之间不做任何数据转发。它们中间会通过 Unix socket 交换文件描述符，从而避免数据拷贝。另外客户端也不是独立进程，而是运行在应用本身的上下文之中的，因此应用和 AppSwitch 之间也不存在数据拷贝的操作。 -## 删减堆栈层{#Delayering-the-stack} +## 删减堆栈层 {#delayering-the-stack} 现在我们大概知道了 AppSwitch 的功能，接下来看看它从标准服务网格中优化掉的层。 -### 网络的去虚拟化{#network-devirtualization} +### 网络的去虚拟化 {#network-devirtualization} Kubernetes 为运行其上的微服务应用提供了简单的设计优良的网络结构。然而为了支持这些设计，也为下层网络强加了特定的 [需求](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/)。要符合这些需求并不简单。通常会通过另加一层的方式来满足要求。典型方案就是在下层网络和 Kubernetes 之间加入叠加层。应用产生的流量会在源头进行封包，在目的地进行解包，这一过程消耗的不仅是网络资源，还包括 CPU。 @@ -46,19 +46,19 @@ AppSwitch 会通过和平台之间的接触，来决定应用程序的可见范 AppSwitch 能注入到标准的 Kubernetes 清单文件之中（和 Istio 注入类似），这样应用的网络就直接被 AppSwitch 控制，跳过任何的网络叠加过程。稍后介绍更多细节。 -### 容器网络的组件{#artifacts-of-container-networking} +### 容器网络的组件 {#artifacts-of-container-networking} 将网络从主机扩展到容器是一个 [巨大挑战](https://kubernetes.io/blog/2016/01/why-kubernetes-doesnt-use-libnetwork/)。新的网络层应运而生。容器中的进程只是主机上的一个进程。然而应用所期待的网络抽象和容器网络命名空间之间存在一个 [错位](http://appswitch.io/blog/kubernetes_istio_and_network_function_devirtualization_with_appswitch/)，进程无法直接访问主机网络。应用程序眼里的网络是 Socket 或者 Session，而网络命名空间暴露的是设备抽象。一旦进入网络命名空间，进程会失去所有连接。为此发明了 `veth-pair` 之类的工具用来弥合这一鸿沟。数据现在必须从主机接口进入虚拟交换机，然后通过 `veth-pair` 才能进入容器网络空间里面的虚拟网络接口。 AppSwitch 能够有效的移除连接两端的虚拟交换机和 `veth-pair` 层。运行在主机上的守护进程所用的主机网络既然已经就绪，就无需再使用网桥方式把主机网络桥接到容器了。主机上创建的 Socket 文件描述符被传递给运行在 Pod 网络命名空间中的应用程序。应用收到 FD 之后，控制路径的所有工作都已就绪，就可以使用 FD 进行实际 IO 了。 -### 跳过共生端点的 TCP/IP{#skip-TCP-IP-for-colocated-endpoints} +### 跳过共生端点的 TCP/IP {#skip-tcp-ip-for-colocated-endpoints} TCP/IP 几乎是所有通信过程的媒介。如果恰好应用端点处于同一主机，还有必要继续使用 TCP/IP 么？毕竟 TCP/IP 会完成很多工作，并且非常复杂。Unix Socket 是为主机内通信设计的，AppSwitch 可以透明的将共生端点之间的通信切换到 Unix Socket 上。 应用所监听的每个 Socket，AppSwitch 都会管理两个监听 Socket，一个对应 TCP，一个对应 Unix。当客户端尝试连接到的服务器恰好在同一主机，AppSwitch 守护进程就会选择连接到服务器的 Unix 监听 Socket 上。连接两端的 Unix Socket 被传递给相应的应用程序之中。返回完成的连接 FD 之后，应用会把它当做简单的字节管道。协议真的不重要。有个应用偶尔会做一些协议相关的调用，例如 `getsockname(2)`，AppSwitch 会自行处理。它会提供一致的响应，保证程序持续运行。 -### 数据推送代理{#data-pushing-proxy} +### 数据推送代理 {#data-pushing-proxy} 我们一直在讨论移除层的问题，再回头看看代理层自身的需求。有时候代理服务器可能退化成为普通的数据推送装置： @@ -80,7 +80,7 @@ TCP/IP 几乎是所有通信过程的媒介。如果恰好应用端点处于同 想象一下，如果应用跳过两个代理，直接连接到 Memcached。数据会在应用和 Memcached 服务之间直接流动。AppSwitch 在 Python 应用发起 `connect(2)` 系统调用时会透明地对系统调用的目标地址进行调整。 -### 无代理的协议解码{#proxyless-protocol-decoding} +### 无代理的协议解码 {#proxyless-protocol-decoding} 这一节要谈的事情有点奇怪。在前面我们看到，在无需了解流量内容的情况下，可以跳过代理服务器。但是其它场景呢？也是可以的。 @@ -88,7 +88,7 @@ TCP/IP 几乎是所有通信过程的媒介。如果恰好应用端点处于同 虽说 AppSwitch 并非代理，它会对应用端点之间的连接进行仲裁，还能访问对应 Socket 的文件描述符。通常 AppSwitch 简单的把这些 FD 传给应用。但是它也可以使用 `recvfrom(2)` 系统调用的 `MSG_PEEK` 选项查看连接上收到的初始消息。这样 AppSwitch 就能在不从 Socket 缓冲区中取出信息的情况下获取流量的内容。当 AppSwitch 将 FD 发给应用并退出数据路径之后，应用程序才会对连接进行真正的读取。AppSwitch 使用这一技术，对应用级的流量进行深层分析，在不进入数据路径的前提下，实现下面将要谈到的复杂网络功能。 -### 零损耗的负载均衡器、防火墙和网络分析器{#zero-cost-load-balancer-firewall-and-network-analyzer} +### 零损耗的负载均衡器、防火墙和网络分析器 {#zero-cost-load-balancer-firewall-and-network-analyzer} 负载均衡器和防火墙这样的典型网络功能，通常的实现方式都是引入一个中间层，介入到数据/包之中。Kubernetes 的负载均衡器（`kube-proxy`）实现利用 iptables 完成对数据包流的探测，Istio 也在代理层中实现了同样的功能。但是如果目标只是根据策略来对连接进行重定向或者丢弃，那么在整个连接过程中都介入到数据通路上是不必要的。AppSwitch 能够更有效的处理这些任务，只要简单的在 API 层面处理控制路径即可。AppSwitch 和应用紧密结合，因此还能够获取更多的应用信息，例如堆栈动态和堆利用情况、服务就绪时间以及活动连接属性等，这些信息可以为监控和分析提供更大发的操作空间。 @@ -96,7 +96,7 @@ TCP/IP 几乎是所有通信过程的媒介。如果恰好应用端点处于同 实际上还存在一种可能的黑魔法就是，无需进入数据路径，也能够对应用的数据流进行修改，后面我会专门撰文描述这一功能。目前如果有对应用协议流量进行修改的需要，AppSwitch 当前的实现是使用一个代理，AppSwitch 使用一种高度优化的机制来完成代理任务，下一节将继续说明。 -### 流量重定向{#traffic-redirection} +### 流量重定向 {#traffic-redirection} Sidecar 代理要获知应用的协议流量，首先需要接入连接。利用包过滤层改写包，让数据包进入对应的 Sidecar，从而完成对应用程序进入和发出连接的重定向任务。要实现重定向规则，就意味着要编写大量规则，这是很繁琐的工作。Sidecar 捕获的目标子网发生变化时，规则的应用和更新也是很昂贵的操作。 @@ -104,7 +104,7 @@ Sidecar 代理要获知应用的协议流量，首先需要接入连接。利用 AppSwitch 提供了无需 root 特权就能重定向应用连接的方法。这样一个无特权应用也能够连接任何主机。应用程序的所有者无需额外权限，就可以修改应用的 `connect(2)` 调用时的主机地址。 -#### Socket 委托{#socket-delegation} +#### Socket 委托 {#socket-delegation} 接下来看看 AppSwitch 如何在不使用 iptables 的情况下进行连接重定向。想象一下，应用程序能够以某种方式主动传递它用于与 Sidecar 通信的 Socket 文件描述符的话，就不需要 iptables 了。AppSwitch 提供了一种称为 **Socket 委托**的机制用于完成这一任务。这个功能让 Sidecar 在不更改应用程序的情况下，透明的访问应用程序用于通信的 Socket 文件描述符的副本。 @@ -130,7 +130,7 @@ AppSwitch 提供了无需 root 特权就能重定向应用连接的方法。这 1. Sidecar 会解开这两个 Socket FD - 一个 Unix Socket FD 连接到应用，另一个 TCP Socket FD 连接到远程客户端。 1. Sidecar 会读取守护进程提供的关于远程客户端的元数据，并执行正常操作。 -#### Sidecar 感知的应用{#sidecar-aware-applications} +#### Sidecar 感知的应用 {#sidecar-aware-applications} Socket 委托功能对于知晓 Sidecar 存在并希望利用其能力的应用非常有用。应用程序可以通过相同的功能，把 Socket 传递给 Sidecar，委托其进行网络交互。一定程度上，AppSwitch 透明的把每个应用都转换成为了 Sidecar 感知应用。 @@ -140,7 +140,7 @@ Socket 委托功能对于知晓 Sidecar 存在并希望利用其能力的应用 接下来讲讲 AppSwitch 可以如何初步集成到 Istio 之中。这不是设计文档，其中涉及到的可能的集成方式并没有经过完全的验证，一些细节还没能解决。这里的尝试是一个大致的将两个系统组合在一起的概要。在这一方案中 AppSwitch 作为一个类似垫片的东西出现在 Istio（应该是网格内应用——译者注）和真正的代理之间。它会作为一个快速通路，用绕过 Sidecar 代理的方式更高效的运作。对于需要使用代理的场合，也会通过移除层的方式缩短数据路径。这篇[博客](http://appswitch.io/blog/kubernetes_istio_and_network_function_devirtualization_with_appswitch/)中记录了更多这方面的细节。 -### AppSwitch 的客户端注入{#appswitch-client-injection} +### AppSwitch 的客户端注入 {#appswitch-client-injection} 和 Istio 的 sidecar-injector 类似，AppSwitch 提供了一个 `ax-injector` 工具用来把 AppSwitch 客户端注入到标准的 Kubernetes 清单文件中。被注入的客户端会透明的监测应用，并把应用程序生成的控制路径上的网络 API 事件报告给 AppSwitch 守护进程。 @@ -154,7 +154,7 @@ Socket 委托功能对于知晓 Sidecar 存在并希望利用其能力的应用 AppSwitch 守护进程可以配置成 `DaemonSet` 的运行方式，也可以作为直接注入应用程序清单的扩展。两种方式下都能够处理来自受支持应用的网络事件。 -### 用于获取策略的 Agent{#agent-for-policy-acquisition} +### 用于获取策略的 Agent {#agent-for-policy-acquisition} 这一组件用来将 Istio 的配置和策略转达给 AppSwitch。它实现了 xDS API，用来监听 Pilot，并调用对应的 AppSwitch API，来完成守护进程的程控。例如可以把 `istioctl` 制定的负载均衡策略翻译成等效的 AppSwitch 能力。 @@ -162,7 +162,7 @@ AppSwitch 守护进程可以配置成 `DaemonSet` 的运行方式，也可以作 AppSwitch 是存在于应用网络 API 的控制路径上的，因此也就具备了访问集群上服务拓扑的能力。AppSwitch 用服务注册表的形式公布信息，这个注册表会随着应用和服务的变化来自动的进行同步更新。Kubernetes 之外的平台适配器，例如 Eureka，会为 Istio 提供上游服务的详细信息。这虽然并非必要，但更有助于上面提到的 AppSwitch Agent 关联从 Pilot 接收到的端点信息。 -### 代理集成和链路{#proxy-integration-and-chaining} +### 代理集成和链路 {#proxy-integration-and-chaining} 通过前面讨论过的 Socket 委托机制，能够将需要深度扫描和应用程序流量突变的连接传递给外部代理。这一过程使用了一个扩展的[代理服务器协议](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)。在简单的代理协议参数之外，加入了其它的元数据（包括从 Socket 缓冲区中获取的协议 Header）以及活跃的 Socket FD（代表应用的连接），转发给代理服务器。 @@ -171,25 +171,25 @@ AppSwitch 是存在于应用网络 API 的控制路径上的，因此也就具 这个机制中有一点比较有趣，当代理从 AppSwitch 接收一个 Socket 的时候，它可以把这个委托转交给其它代理。实际上 AppSwitch 目前就是这么做的。它会用一个简单的内置代理来检查元数据，然后决定在内部处理连接，还是交出去给外部代理（Envoy）。这种机制可以扩展为插件链条，每个环节都 在其中查找特定签名，链条最后一节完成真正的代理工作。 -## 不仅仅是性能{#it-is-not-just-about-performance} +## 不仅仅是性能 {#it-is-not-just-about-performance} 从数据路径上移除中间层，不仅仅意味着性能的提高。性能提高是好事，但这仅仅是一个副产品。在 API 级别上，有更多的重要提升。 -### 应用接入和策略生成的自动化{#automatic-application-onboarding-and-policy-authoring} +### 应用接入和策略生成的自动化 {#automatic-application-onboarding-and-policy-authoring} 在微服务和服务网格之前，流量管理由负载均衡器完成，而访问控制则由防火墙完成。通过 IP 地址和 相对静态的 DNS 名称来鉴别应用。实际上这仍然是当前大多数环境的现状。这样的环境将从服务网格中受益匪浅。相对于新功能的开发来说，转型难度并不高，但是需要对整个基础设施进行重新思考和重新实现，这就需要投入了。目前多数策略和配置存在于负载均衡和防火墙中，现存的上下文需要有一个可扩展的路径来完成到服务网格模型的过渡。 AppSwitch 能够大大简化接入流程。它可以把应用程序源环境投射到目标环境。如果传统应用的配置文件包含了硬编码的 IP 地址或者 DNS 名称，通常是难于迁移的。AppSwitch 可以协助捕获这些应用及其配置，在无需更改的情况下将其接入服务网格。 -### 更大范围的应用和协议支持{#broader-application-and-protocol-support} +### 更大范围的应用和协议支持 {#broader-application-and-protocol-support} 众所周知，HTTP 是的现代应用程序领域的主导协议，但是一旦涉及传统应用和环境，我们会遇到各种协议和传输方式。有时候连 UDP 的支持都是必要选项，例如 IBM 的 WebSphere 就广泛的依赖 UDP，多数多媒体应用也在使用 UDP 媒体流。当然，DNS 可能是最多使用的 UDP 应用。AppSwitch 在 API 级别为 UDP 提供了和 TCP 非常相似的支持，它检测到 UDP 连接之后，会透明的在快速路径中进行处理，而不是委托给代理。 -### 保留客户端 IP 以及端到端原则{#client-IP-preservation-and-end-to-end-principle} +### 保留客户端 IP 以及端到端原则 {#client-IP-preservation-and-end-to-end-principle} 和保留源网络环境的机制类似，同样也可以保留服务器视角的客户端 IP 地址。在 Sidecar 的干扰下，连接通常是来自于 Sidecar 而非客户端，这样服务端应用看到的对端地址就被替换为代理服务器的 IP。AppSwitch 能让服务器看到客户端的真实地址，进行正确的记录，并且能够通过该地址进行准确的决策。另外 AppSwitch 保留了[端到端原则](https://en.wikipedia.org/wiki/End-to-end_principle)，中间层的存在会打破这一规则，并对真正的底层上下文造成混淆。 -### 访问加密 Header 以增强应用信号{#enhanced-application-signal-with-access-to-encrypted-headers} +### 访问加密 Header 以增强应用信号 {#enhanced-application-signal-with-access-to-encrypted-headers} 加密流量会阻止服务网格对流量的分析。API 级别的介入提供了一种可行的解决方法。AppSwitch 目前的实现能够在系统调用层面获得对应用网络 API 的访问。然而还有进一步的可能，在应用尚未加密或者已经加密的高级 API 边界上对应用程序施加影响。最终的视角上，应用生成明文数据，在发出之前的某个时间点进行加密。既然 AppSwitch 运行在应用的内存上下文中，因此就可能在更高层的数据中获取到明文。当然要完成这种功能，应用需要进行明确定义并且适合介入。同时这一功能还要访问应用二进制文件的符号表。目前 AppSwitch 还没有实现这一功能。 @@ -203,7 +203,7 @@ AppSwitch 从标准服务网格中移除了一组层次和操作。到底会对 初步显示，p50 延迟在有无 AppSwitch 的情况下有高达 18 倍的差距（3.99 毫秒 vs 72.96 毫秒）。如果禁用了日志和 Mixer，差距会缩减为 8 倍。很明显，这一差距就是因为数据路径上的多余层造成的。客户端和服务器分属两台不同主机，因此 Unix Socket 优化在这一场景上没有触发，有理由相信，如果客户端和服务器恰好在同一节点上，延迟会进一步缩小。究其根本，在 Kubernetes 上各自 Pod 中运行的服务器和客户端是通过 GKE 网络上的 TCP Socket 直接连接的——没有隧道、网桥或者代理。 -## Net Net{#net-net} +## 结论 {#net-net} 从 David Wheeler 的引言开始说到，另起一层并非解决层次过多问题的方案。我的博客中经常提到，目前的网络栈已经层次太多，应该精简，但是 AppSwitch 是不是又加了一层？ @@ -215,7 +215,7 @@ AppSwitch 从标准服务网格中移除了一组层次和操作。到底会对 计算机科学中的所有问题，都可以用另一个层来解决，**即使**是层数太多的问题。 {{< /quote >}} -## 感谢{#acknowledgements} +## 感谢 {#acknowledgements} 感谢 Mandar Jog（Google）进行了多次沟通，讨论 AppSwitch 对 Istio 的存在价值。同时也要感谢对本文稿件进行 Review 的几位朋友（以字母排序）： diff --git a/content/zh/blog/2018/egress-https/index.md b/content/zh/blog/2018/egress-https/index.md index f948e252a4647..a9f8dbd9d012e 100644 --- a/content/zh/blog/2018/egress-https/index.md +++ b/content/zh/blog/2018/egress-https/index.md @@ -19,7 +19,7 @@ target_release: 1.1 我将展示如何使用 _mesh-external service entries_ 在 Istio 中启用外部 HTTPS 流量。最后， 我解释了当前与 Istio 出口流量控制相关的问题。 -## 初始设定{#initial-setting} +## 初始设定 {#initial-setting} 为了演示使用外部 Web 服务的场景，我首先使用安装了 [Istio](/zh/docs/setup/getting-started/) 的 Kubernetes 集群, 然后我部署 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/), @@ -39,7 +39,7 @@ target_release: 1.1 执行[部署应用程序](/zh/docs/examples/bookinfo/#deploying-the-application)、[确认应用正在运行](/zh/docs/examples/bookinfo/#confirm-the-app-is-accessible-from-outside-the-cluster)，以及 [应用默认目标规则](/zh/docs/examples/bookinfo/#apply-default-destination-rules)中的步骤部分。 -### Bookinfo 使用 HTTPS 访问 Google 图书网络服务{#Bookinfo-with-https-access-to-a-google-books-web-service} +### Bookinfo 使用 HTTPS 访问 Google 图书网络服务 {#bookinfo-with-https-access-to-a-google-books-web-service} 让我们添加一个新版本的 _details_ 微服务，_v2_，从 [Google Books APIs](https://developers.google.com/books/docs/v1/getting_started) 中获取图书详细信息。 它设定了服务容器的 `DO_NOT_ENCRYPT` 环境变量为 `false`。此设置将指示已部署服务使用 HTTPS（而不是 HTTP ）来访问外部服务。 @@ -81,7 +81,7 @@ $ kubectl apply -f @samples/bookinfo/networking/virtual-service-details-v2.yaml@ 默认情况下，Istio sidecar 代理（[Envoy proxies](https://www.envoyproxy.io)） **阻止到集群外目的地的所有流量**, 要启用此类流量，我们必须定义 [mesh-external service entry](/zh/docs/reference/config/networking/service-entry/)。 -### 启用对 Google Books 网络服务的 HTTPS 访问{#enable-https-access-to-a-google-books-web-service} +### 启用对 Google Books 网络服务的 HTTPS 访问 {#enable-https-access-to-a-google-books-web-service} 不用担心，让我们定义**网格外部 `ServiceEntry`** 并修复我们的应用程序。您还必须定义 _virtual service_ 使用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 对外部服务执行路由。 @@ -148,7 +148,7 @@ serviceentry "googleapis" deleted 正如我们所看到的，与许多其他 Istio 配置一样，`ServiceEntry` 是**动态定义**的 , Istio 运算符可以动态决定 它们允许微服务访问哪些域, 他们可以动态启用和禁用外部域的流量，而无需重新部署微服务。 -### 清除对 Google 图书网络服务的 HTTPS 访问权限{#cleanup-of-https-access-to-a-google-books-web-service} +### 清除对 Google 图书网络服务的 HTTPS 访问权限 {#cleanup-of-https-access-to-a-google-books-web-service} {{< text bash >}} $ kubectl delete serviceentry googleapis @@ -157,7 +157,7 @@ $ kubectl delete -f @samples/bookinfo/networking/virtual-service-details-v2.yaml $ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo-details-v2.yaml@ {{< /text >}} -## 由 Istio 发起的 TLS{#TLS-origination-by-Istio} +## 由 Istio 发起的 TLS {#tls-origination-by-istio} 这个故事有一个警告。假设您要监视您的微服务使用 [Google API](https://developers.google.com/apis-explorer/) 的哪个特定集 （[书籍](https://developers.google.com/books/docs/v1/getting_started)，[日历](https://developers.google.com/calendar/)，[任务](https://developers.google.com/tasks/)等） @@ -208,7 +208,7 @@ env: 在下一节中，您将配置 TLS 发起以访问外部 Web 服务。 -## 具有 TLS 的 Bookinfo 起源于 Google Books 网络服务{#Bookinfo-with-TLS-origination-to-a-google-books-web-service} +## 具有 TLS 的 Bookinfo 起源于 Google Books 网络服务 {#bookinfo-with-TLS-origination-to-a-google-books-web-service} 1. 部署 _details v2_ 版本，将 HTTP 请求发送到 [Google Books API](https://developers.google.com/books/docs/v1/getting_started)。 在 [`bookinfo-details-v2.yaml`]({{}}/samples/bookinfo/platform/kube/bookinfo-details-v2.yaml) 中， @@ -292,7 +292,7 @@ env: 请注意日志中的 URL 路径，可以监视路径并根据它来应用访问策略。要了解有关 HTTP 出口流量的监控和访问策略 的更多信息，请查看[归档博客之出口流量监控之日志](https://archive.istio.io/v0.8/blog/2018/egress-monitoring-access-control/#logging)。 -### 清除 TLS 原始数据到 Google Books 网络服务{#cleanup-of-TLS-origination-to-a-google-books-web-service} +### 清除 TLS 原始数据到 Google Books 网络服务 {#cleanup-of-tls-origination-to-a-google-books-web-service} {{< text bash >}} $ kubectl delete serviceentry googleapis @@ -302,7 +302,7 @@ $ kubectl delete -f @samples/bookinfo/networking/virtual-service-details-v2.yaml $ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo-details-v2.yaml@ {{< /text >}} -### Istio 双向 TLS 的关系{#relation-to-Istio-mutual-TLS} +### Istio 双向 TLS 的关系 {#relation-to-istio-mutual-tls} 请注意，在这种情况下，TLS 的源与 Istio 应用的[双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication) 无关, 无论 Istio 双向 TLS 是否启用，外部服务的 TLS 源都将起作用 , 保证服务网**内**的服务到服务通信， @@ -310,7 +310,7 @@ $ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo-details-v2.yaml@ 这是用于保护 Web 浏览器和 Web 服务器之间通信的相同机制 , TLS 应用于与外部服务的通信， 以验证外部服务器的身份并加密流量。 -## 结论{#conclusion} +## 结论 {#conclusion} 在这篇博文中，我演示了 Istio 服务网格中的微服务如何通过 HTTPS 使用外部 Web 服务, 默认情况下， Istio 会阻止集群外主机的所有流量, 要启用此类流量，请使用 mesh-external, 必须为服务网格创建 `ServiceEntry` , diff --git a/content/zh/blog/2018/egress-mongo/index.md b/content/zh/blog/2018/egress-mongo/index.md index c73f51f462b08..b529a14fe8981 100644 --- a/content/zh/blog/2018/egress-mongo/index.md +++ b/content/zh/blog/2018/egress-mongo/index.md @@ -13,11 +13,11 @@ target_release: 1.1 服务。您将使用 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)，它的书籍评级数据保存在 MongoDB 数据库中。您会将此数据库部署在集群外部，并配置 `ratings` 微服务使用它。您将学习控制到外部 MongoDB 服务流量的多种选择及其利弊。 -## 使用外部 ratings 数据库的 Bookinfo {#Bookinfo-with-external-ratings-database} +## 使用外部 ratings 数据库的 Bookinfo {#bookinfo-with-external-ratings-database} 首先，在您的 Kubernetes 集群外部建立一个 MongoDB 数据库实例以保存书籍评级数据。然后修改 [Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)使用该数据库。 -### 建立 ratings 数据库{#setting-up-the-ratings-database} +### 建立 ratings 数据库 {#setting-up-the-ratings-database} 在这个任务中您将建立一个 [MongoDB](https://www.mongodb.com) 实例。您可以使用任何 MongoDB 实例；我使用 [Compose for MongoDB](https://www.ibm.com/cloud/compose/mongodb)。 @@ -83,7 +83,7 @@ target_release: 1.1 bye {{< /text >}} -### Bookinfo 应用程序的初始设置{#Initial-setting-of-Bookinfo-application} +### Bookinfo 应用程序的初始设置 {#initial-setting-of-bookinfo-application} 为了演示使用外部数据库的场景，请首先运行一个[安装了 Istio](/zh/docs/setup/getting-started/) 的 Kubernetes 集群。然后部署 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)并[应用默认 destination rules](/zh/docs/examples/bookinfo/#apply-default-destination-rules) 和[改变 Istio 到 blocking-egress-by-default 策略](/zh/docs/tasks/traffic-management/egress/egress-control/#change-to-the-blocking-by-default-policy)。 @@ -97,7 +97,7 @@ target_release: 1.1 {{< image width="80%" link="/zh/docs/examples/bookinfo/withistio.svg" caption="The original Bookinfo application" >}} -### 在 Bookinfo 应用程序中使用外部数据库{#use-the-external-database-in-Bookinfo-application} +### 在 Bookinfo 应用程序中使用外部数据库 {#use-the-external-database-in-bookinfo-application} 1. 部署使用 MongoDB 数据库的 _ratings_ 微服务（_ratings v2_）： @@ -131,7 +131,7 @@ target_release: 1.1 请注意，MongoDB 数据库位于 Istio 服务网格之外，或者更确切地说是在 Kubernetes 集群之外。服务网格的边界使用虚线标记。 -### 访问网页{#access-the-webpage} +### 访问网页 {#access-the-webpage} [确认 ingress IP 和端口之后](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port)，访问应用程序的网页。 @@ -141,7 +141,7 @@ target_release: 1.1 在以下部分中，您将使用不同的 Istio egress 控制选项，配置对外部 MongoDB 服务的访问。 -## TCP 的 egress 控制{#egress-control-for-TCP} +## TCP 的 egress 控制 {#egress-control-for-tcp} 由于 [MongoDB 协议](https://zh/docs.mongodb.com/manual/reference/mongodb-wire-protocol/)运行在 TCP 之上，您可以像控制到[其余 TCP 服务](/zh/blog/2018/egress-tcp/)的流量一样控制到 MongoDB 的 egress 流量。为了控制 TCP 流量，您必须指定一个 [CIDR](https://tools.ietf.org/html/rfc2317) 表示的 IP 块，该 IP 块包含 MongoDB 的地址。需要注意的是，有时候 MongoDB 主机的 IP 并不稳定或无法事先得知。 @@ -153,7 +153,7 @@ target_release: 1.1 $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4) {{< /text >}} -### 在没有 gateway 的情况下控制 TCP egress 流量{#control-TCP-egress-traffic-without-a-gateway} +### 在没有 gateway 的情况下控制 TCP egress 流量 {#control-tcp-egress-traffic-without-a-gateway} 如果您不用通过 [egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#use-case) 定向流量，例如不要求所有流量都通过 gateway 流出网格时，请遵循以下部分的说明。或者，如果您确实希望通过 egress gateway 定向流量，请继续阅读[通过 egress gateway 定向 TCP egress 流量](#direct-tcp-egress-traffic-through-an-egress-gateway)。 @@ -193,7 +193,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4) 1. 如果要通过出口网关引导流量，请继续下一节。否则，请执行 [cleanup](#cleanup-of-TCP-egress-traffic-control). -### 通过 egress gateway 定向 TCP Egress 流量{#direct-TCP-egress-traffic-through-an-egress-gateway} +### 通过 egress gateway 定向 TCP Egress 流量 {#direct-tcp-egress-traffic-through-an-egress-gateway} 在本节中，您将处理通过 [egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#use-case) 定向流量的情况。Sidecar 代理通过匹配 MongoDB 主机的 IP 地址（一个 32 位长度的 CIDR 块），将 TCP 连接从 MongoDB 客户端路由到 egress gateway。Egress gateway 按照其 hostname，转发流量到 MongoDB 主机。 @@ -205,7 +205,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4) 如果你不想开启双向 TLS，参考 [Mutual TLS between the sidecar proxies and the egress gateway](#mutual-TLS-between-the-sidecar-proxies-and-the-egress-gateway) 小节 否则，请继续以下部分。 -#### 配置从 sidecar 到 egress gateway 的 TCP 流量{#configure-TCP-traffic-from-sidecars-to-the-egress-gateway} +#### 配置从 sidecar 到 egress gateway 的 TCP 流量 {#configure-tcp-traffic-from-sidecars-to-the-egress-gateway} 1. 定义 `EGRESS_GATEWAY_MONGODB_PORT` 环境变量来保存用于通过 egress gateway 定向流量的端口，例如 `7777`。必须选择没有被网格中其余 service 使用的端口。 @@ -315,7 +315,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4) 1. [验证 TCP egress 流量是否被定向到 egress gateway](#verify-that-egress-traffic-is-directed-through-the-egress-gateway). -#### Sidecar 代理和 egress gateway 之间的双向 TLS{#mutual-TLS-between-the-sidecar-proxies-and-the-egress-gateway} +#### Sidecar 代理和 egress gateway 之间的双向 TLS {#mutual-tls-between-the-sidecar-proxies-and-the-egress-gateway} 1. 删除前面小节中的配置： @@ -430,7 +430,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4) 1. 继续下一节。 -#### 验证 TCP egress 流量是否通过 egress gateway 定向{#verify-that-egress-traffic-is-directed-through-the-egress-gateway} +#### 验证 TCP egress 流量是否通过 egress gateway 定向 {#verify-that-egress-traffic-is-directed-through-the-egress-gateway} 1. 再次刷新应用程序的网页，并验证等级是否仍正确显示。 @@ -453,7 +453,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo mongo --ignore-not-foun $ kubectl delete policy istio-egressgateway -n istio-system --ignore-not-found=true {{< /text >}} -## TLS egress 控制{#egress-control-for-TLS} +## TLS egress 控制 {#egress-control-for-tls} 在现实生活中，绝大多数到外部服务的通信都必须被加密，而 [MongoDB 协议在 TLS 之上运行](https://zh/docs.mongodb.com/manual/tutorial/configure-ssl/)。 并且，TLS 客户端经常发送[服务器名称指示](https://en.wikipedia.org/wiki/Server_Name_Indication)，SNI，作为握手的一部分。 @@ -469,7 +469,7 @@ $ openssl s_client -connect $MONGODB_HOST:$MONGODB_PORT -servername $MONGODB_HOS 如果上述命令打印了一个服务器返回的证书，说明该服务器支持 TLS。如果没有，您就需要像前面小节描述的一样在 TCP 层面控制 MongoDB egress 流量。 -### 无 gateway 情况下控制 TLS egress 流量{#control-TLS-egress-traffic-without-a-gateway} +### 无 gateway 情况下控制 TLS egress 流量 {#control-tls-egress-traffic-without-a-gateway} 如果您[不需要 egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#use-case)，请遵循本小节中的说明。 如果您需要通过 egress gateway 定向流量，请继续阅读[通过 egress gateway 定向 TCP Egress 流量](#direct-tcp-egress-traffic-through-an-egress-gateway)。 @@ -495,7 +495,7 @@ $ openssl s_client -connect $MONGODB_HOST:$MONGODB_PORT -servername $MONGODB_HOS 1. 刷新应用程序的网页。应用程序应该正确显示评级数据。 -#### 清理 TLS 的 egress 配置{#cleanup-of-the-egress-configuration-for-TLS} +#### 清理 TLS 的 egress 配置 {#cleanup-of-the-egress-configuration-for-tls} {{< text bash >}} $ kubectl delete serviceentry mongo @@ -696,7 +696,7 @@ Egress gateway 在 443 端口上接受 MongoDB 流量，按照 SNI 匹配 MongoD 1. [验证 TCP egress 流量是否通过 egress gateway 定向](#verify-that-egress-traffic-is-directed-through-the-egress-gateway) -#### 清除通过 egress gateway 定向 TLS Egress 流量的配置{#cleanup-directing-TLS-Egress-traffic-through-an-egress-gateway} +#### 清除通过 egress gateway 定向 TLS Egress 流量的配置 {#cleanup-directing-tls-Egress-traffic-through-an-egress-gateway} {{< text bash >}} $ kubectl delete serviceentry mongo @@ -705,7 +705,7 @@ $ kubectl delete virtualservice direct-mongo-through-egress-gateway $ kubectl delete destinationrule egressgateway-for-mongo {{< /text >}} -### 启用到任意通配符域名的 MongoDB TLS egress 流量{#enable-MongoDB-TLS-egress-traffic-to-arbitrary-wildcarded-domains} +### 启用到任意通配符域名的 MongoDB TLS egress 流量 {#enable-mongodb-tls-egress-traffic-to-arbitrary-wildcarded-domains} 有时，您希望将 egress 流量配置为来自同一域的多个主机名，例如到 `*..com` 中的所有 MongoDB service。 您不希望创建多个配置项，而是一个用于公司中所有 MongoDB service 的通用配置项。 @@ -718,7 +718,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo 要为通配符域名配置 egress gateway 流量， 您需要使用[一个额外的 SNI 代理](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#wildcard-configuration-for-arbitrary-domains)来部署一个自定义的 egress gateway。由于 Envoy（Istio egress gateway 使用的标准代理）目前的限制，这是必须的。 -#### 准备一个 SNI 代理使用新的 egress gateway{#prepare-a-new-egress-gateway-with-an-SNI-proxy} +#### 准备一个 SNI 代理使用新的 Egress Gateway {#prepare-a-new-egress-gateway-with-an-sni-proxy} 在本节中，除了标准的 Istio Envoy 代理之外，您还将部署具有 SNI 代理的 egress gateway。您可以使用任何能够根据任意未预先配置的 SNI 值路由流量的 SNI 代理；我们使用 [Nginx](http://nginx.org) 来实现这一功能。 @@ -852,7 +852,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo EOF {{< /text >}} -#### 使用新 egress gateway 配置到 `*.com` 的访问{#configure-access-to-com-using-the-new-egress-gateway} +#### 使用新 egress gateway 配置到 `*.com` 的访问 {#configure-access-to-com-using-the-new-egress-gateway} 1. 为 `*.com` 定义一个 `ServiceEntry`： @@ -1023,7 +1023,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo 127.0.0.1 [23/Aug/2018:03:28:18 +0000] TCP []200 2590 1248 0.095 {{< /text >}} -#### 理解原理{#understanding-what-happened} +#### 理解原理 {#understanding-what-happened} 在本节中，您使用通配符域名为您的 MongoDB 主机配置了 egress 流量。对于单个 MongoDB 主机使用通配符域名没有任何好处（可以指定确切的主机名）， 而当集群中的应用程序需要访问多个匹配某个通配符域名的 MongoDB 主机时可能有用。 @@ -1033,7 +1033,7 @@ egress 流量可以使用针对泛域名 `*.composedb.com` 的单个配置实现 当配置一个应用使用另一个主机名匹配本小节中的通配符域名的 MongoDB 实例时，不需要额外的 Istio 配置。 我将这留作一个练习，让读者自行验证。 -#### 清理到任意通配符域名的 MongoDB TLS egress 流量的配置{#cleanup-of-configuration-for-MongoDB-TLS-egress-traffic-to-arbitrary-wildcarded-domains} +#### 清理到任意通配符域名的 MongoDB TLS egress 流量的配置{#cleanup-of-configuration-for-mongodb-tls-egress-traffic-to-arbitrary-wildcarded-domains} 1. 删除针对 `*.com` 的配置项： @@ -1061,7 +1061,7 @@ egress 流量可以使用针对泛域名 `*.composedb.com` 的单个配置实现 $ rm ./nginx-sni-proxy.conf {{< /text >}} -## 清理{#cleanup} +## 清理 {#cleanup} 1. 删除`bookinfo`用户： @@ -1102,7 +1102,7 @@ egress 流量可以使用针对泛域名 `*.composedb.com` 的单个配置实现 deployment "ratings-v2" deleted {{< /text >}} -## 总结{#conclusion} +## 总结 {#conclusion} 在这篇博文中，我演示了 MongoDB egress 流量控制的各种选项。您可以在 TCP 或 TLS 层面上控制 MongoDB egress 流量。 根据您的组织的安全需求，在 TCP 和 TLS 场景下您都可以将流量从 sidecar 代理定向到外部 MongoDB 主机 diff --git a/content/zh/blog/2018/egress-tcp/index.md b/content/zh/blog/2018/egress-tcp/index.md index 5a7a03d7fcb06..eeb9df4837285 100644 --- a/content/zh/blog/2018/egress-tcp/index.md +++ b/content/zh/blog/2018/egress-tcp/index.md @@ -17,11 +17,11 @@ target_release: 1.0 在我之前的博客文章[使用外部 Web 服务](/zh/blog/2018/egress-https/)中，我描述了如何通过 HTTPS 在网格 Istio 应用程序中使用外部服务，在这篇文章中，我演示了通过 TCP 使用外部服务。你会用到 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)，这是将书籍评级数据保存在 MySQL 数据库中的版本。你会在集群外部署此数据库并配置 _ratings_ 服务以使用它，你还会定义[服务 Entry](/zh/docs/reference/config/networking/service-entry/) 以允许网格内应用程序访问外部数据库。 -## Bookinfo 示例应用程序与外部评级数据库{#Bookinfo-sample-application-with-external-ratings-database} +## Bookinfo 示例应用程序与外部评级数据库 {#bookinfo-sample-application-with-external-ratings-database} 首先，在 Kubernetes 集群之外设置了一个 MySQL 数据库实例来保存 Bookinfo 评级数据，然后修改 [Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)以使用这个数据库。 -### 为评级数据设置数据库{#setting-up-the-database-for-ratings-data} +### 为评级数据设置数据库 {#setting-up-the-database-for-ratings-data} 为此，你设置了 [MySQL](https://www.mysql.com) 的实例，你可以使用任何 MySQL 实例; 我使用 [Compose for MySQL](https://www.ibm.com/cloud/compose/mysql)，我使用 `mysqlsh`（[MySQL Shell](https://dev.mysql.com/doc/mysql-shell/en/)）作为 MySQL 客户端来提供评级数据。 @@ -128,7 +128,7 @@ target_release: 1.0 现在你已经可以去部署使用外部数据库的 Bookinfo 应用程序版本了。 -### Bookinfo 应用程序的初始设置{#initial-setting-of-Bookinfo-application} +### Bookinfo 应用程序的初始设置 {#initial-setting-of-bookinfo-application} 为了演示使用外部数据库的场景，你首先使用安装了 [Istio](/zh/docs/setup/getting-started/) 的 Kubernetes 集群，然后部署 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)、[应用默认的 destination rule](/zh/docs/examples/bookinfo/#apply-default-destination-rules) 并[将 Istio 默认策略修改为禁止 Egress](/zh/docs/tasks/traffic-management/egress/egress-control/#change-to-the-blocking-by-default-policy)。 @@ -143,7 +143,7 @@ target_release: 1.0 caption="原始的 Bookinfo 应用程序" >}} -### 将数据库用于 Bookinfo 应用程序中的评级数据{#use-the-database-for-ratings-data-in-Bookinfo-application} +### 将数据库用于 Bookinfo 应用程序中的评级数据 {#use-the-database-for-ratings-data-in-bookinfo-application} 1. 修改使用 MySQL 数据库的 _ratings_ 服务版本的 `deployment spec`，以使用你的数据库实例。该 `spec` 位于 Istio 发行档案的 [`samples/bookinfo/platform/kube/bookinfo-ratings-v2-mysql.yaml`]({{}}/samples/bookinfo/platform/kube/bookinfo-ratings-v2-mysql.yaml) 中。编辑以下几行： @@ -185,7 +185,7 @@ target_release: 1.0 请注意，MySQL 数据库位于 Istio 服务网格之外，或者更准确地说是在 Kubernetes 集群之外，服务网格的边界由虚线标记。 -### 访问网页{#access-the-webpage} +### 访问网页 {#access-the-webpage} 在[确定入口 IP 和端口](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port)之后，访问应用程序的网页。 @@ -197,7 +197,7 @@ target_release: 1.0 你遇到的问题与[使用外部 Web 服务](/zh/blog/2018/egress-https/)中的问题相同，即 Kubernetes 集群外的所有流量（TCP 和 HTTP）都被 sidecar 代理默认阻止，要为 TCP 启用此类流量，必须定义 TCP 的网格外部服务入口。 -### 外部 MySQL 实例的网格外部服务入口{#mesh-external-service-entry-for-an-external-MySQL-instance} +### 外部 MySQL 实例的网格外部服务入口 {#mesh-external-service-entry-for-an-external-mysql-instance} "TCP 网格外部服务入口"功能可以解决上面的问题。 @@ -252,13 +252,13 @@ target_release: 1.0 与 HTTP/HTTPS 的服务入口一样，你可以动态地使用 `kubectl` 删除和创建 TCP 的服务入口。 -## 出口 TCP 流量控制的动机{#motivation-for-egress-TCP-traffic-control} +## 出口 TCP 流量控制的动机 {#motivation-for-egress-tcp-traffic-control} 一些网内 Istio 应用程序必须访问外部服务，例如遗留系统，在许多情况下，不通过 HTTP 或 HTTPS 协议执行访问，使用其他 TCP 协议，例如 [MongoDB Wire 协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)和 [MySQL 客户端/服务器协议](https://dev.mysql.com/doc/internals/en/client-server-protocol.html)等特定于数据库的协议，与外部数据库通信。 接下来我会再说说 TCP 流量的服务入口。 -## TCP 流量的服务入口{#service-entries-for-tcp-traffic} +## TCP 流量的服务入口 {#service-entries-for-tcp-traffic} 启用到特定端口的 TCP 流量的服务入口必须指定 `TCP` 作为端口的协议，此外，对于 [MongoDB Wire 协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)，协议可以指定为 `MONGO`，而不是 `TCP`。 @@ -270,14 +270,14 @@ target_release: 1.0 另请注意，外部服务的 IP 并不总是静态的，例如在 [CDN](https://en.wikipedia.org/wiki/Content_delivery_network) 的情况下，有时 IP 在大多数情况下是静态的，但可以不时地更改，例如由于基础设施的变化。在这些情况下，如果已知可能 IP 的范围，则应通过 CIDR 块指定范围。如果不知道可能的 IP 的范围，则不能使用 TCP 服务入口，并且[必须直接调用外部服务](/zh/docs/tasks/traffic-management/egress/egress-control/#direct-access-to-external-services)，绕过 sidecar 代理。 -## 与网格扩展的关系{#relation-to-virtual-machines-support} +## 与网格扩展的关系 {#relation-to-virtual-machines-support} 请注意，本文中描述的场景与[集成虚拟机](/zh/docs/examples/virtual-machines/bookinfo/)示例中描述的网格扩展场景不同。在这种情况下，MySQL 实例在与 Istio 服务网格集成的外部（集群外）机器（裸机或 VM）上运行 ，MySQL 服务成为网格的一等公民，具有 Istio 的所有有益功能，除此之外，服务可以通过本地集群域名寻址，例如通过 `mysqldb.vm.svc.cluster.local`，并且可以通过[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication)保护与它的通信，无需创建服务入口来访问此服务; 但是，该服务必须在 Istio 注侧，要启用此类集成，必须在计算机上安装 Istio 组件（_Envoy proxy_ ，_node-agent_ ，`_istio-agent_` ），并且必须可以从中访问 Istio 控制平面（_Pilot_ ，_Mixer_ ，_Citadel_ ）。有关详细信息，请参阅 [Istio VM 相关](/zh/docs/examples/virtual-machines/)。 在这个的示例中，MySQL 实例可以在任何计算机上运行，也可以由云提供商作为服务进行配置，无需集成机器 与 Istio ，无需从机器访问 Istio 控制平面，在使用 MySQL 作为服务的情况下，运行 MySQL 的计算机可能无法访问，并且可能无法在其上安装必需的组件。在这个的例子中，MySQL 实例可以通过其全局域名进行寻址，如果消费应用程序希望使用该域名，这可能是有益的，当在消费应用程序的部署配置中无法更改预期的域名时，这尤其重要。 -## 清理{#cleanup} +## 清理 {#cleanup} 1. 删除 `test` 数据库和 `bookinfo` 用户： @@ -315,6 +315,6 @@ target_release: 1.0 Deleted config: serviceentry mysql-external {{< /text >}} -## 结论{#conclusion} +## 结论 {#conclusion} 在这篇博文中，我演示了 Istio 服务网格中的微服务如何通过 TCP 使用外部服务，默认情况下，Istio 会阻止所有流量（TCP 和 HTTP）到集群外的主机，要为 TCP 启用此类流量，必须为服务网格创建 TCP 网格外部服务入口。 diff --git a/content/zh/blog/2018/soft-multitenancy/index.md b/content/zh/blog/2018/soft-multitenancy/index.md index 1fa7e8faadffe..140c3da691db9 100644 --- a/content/zh/blog/2018/soft-multitenancy/index.md +++ b/content/zh/blog/2018/soft-multitenancy/index.md @@ -10,7 +10,7 @@ target_release: 0.7 多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。[Kubernetes 多租户工作组](https://github.com/kubernetes/community/blob/master/wg-multitenancy/README.md)致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有"软性多租户”支持是可行的。 -## 软性多租户{#soft-multi-tenancy} +## 软性多租户 {#soft-multi-tenancy} 文中提到的"软性多租户”的定义指的是单一 Kubernetes 控制平面和多个 Istio 控制平面以及多个服务网格相结合；每个租户都有自己的一个控制平面和一个服务网格。集群管理员对所有 Istio 控制面都有控制和监控的能力，而租户管理员仅能得到指定 Istio 的控制权。使用 Kubernetes 的命名空间和 RBAC 来完成不同租户的隔离。 @@ -22,9 +22,9 @@ target_release: 0.7 这里仅就在有限多租户环境中部署 Istio 做一些概要描述。当官方多租户支持实现之后，会在[文档](/zh/docs/)中具体阐述。 {{< /tip >}} -## 部署{#deployment} +## 部署 {#deployment} -### 多个 Istio 控制面{#multiple-Istio-control-planes} +### 多个 Istio 控制面 {#multiple-istio-control-planes} 要部署多个 Istio 控制面，首先要在 Istio 清单文件中对所有的 `namespace` 引用进行替换。以 `istio.yaml` 为例：如果需要两个租户级的 Istio 控制面，那么第一个租户可以使用 `istio.yaml` 中的缺省命名空间也就是 `istio-system`；而第二个租户就要生成一个新的 yaml 文件，并在其中使用不同的命名空间。例如使用下面的命令创建一个使用 `istio-system1` 命名空间的 yaml 文件： @@ -58,11 +58,11 @@ istio-system1 istio-pilot-5bb6b7669c-779vb 2/2 Running 0 需要由集群管理员、而不是租户自己的管理员来加载这两组 yaml 文件。另外，要把租户管理员的操作权限限制在各自的命名空间内，还需要额外的 RBAC 配置。 -### 区分通用资源和命名空间资源{#split-common-and-namespace-specific-resources} +### 区分通用资源和命名空间资源 {#split-common-and-namespace-specific-resources} Istio 仓库中的清单文件中会创建两种资源，一种是能够被所有 Istio 控制面访问的通用资源，另一种是每个控制平面一份的专属资源。上面所说的在 yaml 文件中替换 `istio-system` 命名空间的方法自然是很简单的，更好的一种方法就是把 yaml 文件拆分为两块，一块是所有租户共享的通用部分；另一块就是租户自有的部分。根据 [CRD 资源定义（Custom Resource Definitions）](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) 中的说法，角色和角色绑定资源需要从 Istio 文件中进行剥离。另外，清单文件中提供的角色和角色绑定的定义可能不适合多租户环境，还需要进一步的细化和定制。 -### Istio 控制面的 Kubernetes RBAC 设置{#Kubernetes-rbac-for-Istio-control-plane-resources} +### Istio 控制面的 Kubernetes RBAC 设置 {#kubernetes-rbac-for-istio-control-plane-resources} 租户管理员应该被限制在单独的 Istio 命名空间中，要完成这个限制，集群管理员需要创建一个清单，其中至少要包含一个 `Role` 和 `RoleBinding` 的定义，类似下面的文件所示。例子中定义了一个租户管理员，命名为 *sales-admin*，他被限制在命名空间 `istio-system1` 之中。完整的清单中可能要在 `Role` 中包含更多的 `apiGroups` 条目，来定义租户管理员的资源访问能力。 @@ -92,7 +92,7 @@ roleRef: apiGroup: rbac.authorization.k8s.io {{< /text >}} -### 关注特定命名空间进行服务发现{#watching-specific-namespaces-for-service-discovery} +### 关注特定命名空间进行服务发现 {#watching-specific-namespaces-for-service-discovery} 除了创建 RBAC 规则来限制租户管理员只能访问指定 Istio 控制平面之外，Istio 清单还需要为 Istio Pilot 指定一个用于应用程序的命名空间，以便生成 xDS 缓存。Pilot 组件提供了命令行参数 `--appNamespace, ns-1` 可以完成这一任务。*ns-1* 就是租户用来部署自己应用的命名空间。`istio-system1.yaml` 中包含的相关代码大致如下： @@ -122,7 +122,7 @@ spec: - containerPort: 443 {{< /text >}} -### 在特定命名空间中部署租户应用{#deploying-the-tenant-application-in-a-namespace} +### 在特定命名空间中部署租户应用 {#deploying-the-tenant-application-in-a-namespace} 现在集群管理员已经给租户创建了命名空间（`istio-system1`），并且对 Istio Pilot 的服务发现进行了配置，要求它关注应用的命名空间（`ns-1`），创建应用的 yaml 文件，将其部署到租户的专属命名空间中： @@ -147,7 +147,7 @@ metadata: 虽然没有展示出来，但是应用的命名空间也应该有 RBAC 设置，用来对特定资源进行访问控制。集群管理员和租户管理员都有权完成这种 RBAC 限制。 -### 在多租户环境中使用 `istioctl`{#using-in-a-multi-tenant-environment} +### 在多租户环境中使用 `istioctl` {#using-in-a-multi-tenant-environment} 定义[路由规则](https://archive.istio.io/v0.7/docs/reference/config/istio.routing.v1alpha1/#RouteRule)或者[目标策略](https://archive.istio.io/v0.7/docs/reference/config/istio.routing.v1alpha1/#DestinationPolicy)时，要确认 `istioctl` 命令是针对专有的 Istio 控制面所在的命名空间运行的。另外规则自身的定义也要限制在租户的命名空间里，这样才能保证规则在租户自己的网格中生效。*-i* 选项用来在 Istio 控制面所属的命名空间中创建（get 和 describe 也一样）规则。*-n* 参数会限制规则的所在范围是租户的网格，取值就是租户应用所在的命名空间。如果 yaml 文件中的资源已经指定了范围，*-n* 参数会被跳过。 @@ -170,7 +170,7 @@ reviews-default RouteRule.v1alpha2.config.istio.io ns-1 [Multiple Istio control planes](/zh/blog/2018/soft-multitenancy/#multiple-Istio-control-planes) 中讲述了更多多租户环境下 `命名空间` 的相关问题。 -### 测试结果{#test-results} +### 测试结果 {#test-results} 根据前文的介绍，一个集群管理员能够创建一个受限于 RBAC 和命名空间的环境，租户管理员能在其中进行部署。 @@ -225,15 +225,15 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p 如果部署了[遥测组件](/zh/docs/tasks/observability/), 例如 [Prometheus](/zh/docs/tasks/observability/metrics/querying-metrics/)（限制在 Istio 的 `namespace`），其中获得的统计结果展示的也只是租户应用命名空间的私有数据。 -## 结语{#conclusion} +## 结语 {#conclusion} 上面的一些尝试表明 Istio 有足够的能力和安全性，符合少量多租户的用例需求。另外也很明显的，Istio 和 Kubernetes **无法**提供足够的能力和安全性来满足其他的用例，尤其是在租户之间要求完全的安全性和隔离的要求的用例。只有等容器技术（例如 Kubernetes ）能够提供更好的安全模型以及隔离能力，我们才能进一步的增强这方面的支持，Istio 的支持并不是很重要。 -## 问题{#issues} +## 问题 {#issues} * 一个租户（例如，`istio-system` 命名空间）的 CA(Certificate Authority) 和 Mixer 的 Pod 中产生的 Log 包含了另一个租户（例如，`istio-system1` 命名空间）的控制面的 `info` 信息。 -## 其他多租户模型的挑战{#challenges-with-other-multi-tenancy-models} +## 其他多租户模型的挑战 {#challenges-with-other-multi-tenancy-models} 还有其他值得考虑的多租户部署模型： @@ -251,11 +251,11 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p 第三个方式对多数案例都是不合适的，毕竟多数集群管理员倾向于将同一个 Kubernetes 控制面作为 [PaaS](https://en.wikipedia.org/wiki/Platform_as_a_service) 提供给他们的租户。 -## 未来{#future-work} +## 未来 {#future-work} 很明显，单一 Istio 控制面控制多个网格可能是下一个功能。还有可能就是在同一个网格中支持多个租户，并提供某种程度的隔离和安全保障。要完成这样的能力，就需要像 Kubernetes 中对命名空间的的操作那样，在一个单独的控制平面中进行分区，社区中发出了[这篇文档](https://docs.google.com/document/d/14Hb07gSrfVt5KX9qNi7FzzGwB_6WBpAnDpPG6QEEd9Q)来定义其他的用例，以及要支持这些用例所需要的 Istio 功能。 -## 参考{#references} +## 参考 {#references} * 视频：[用 RBAC 和命名空间支持的多租户功能及安全模型](https://www.youtube.com/watch?v=ahwCkJGItkU), [幻灯片](https://schd.ws/hosted_files/kccncna17/21/Multi-tenancy%20Support%20%26%20Security%20Modeling%20with%20RBAC%20and%20Namespaces.pdf). * `Kubecon` 讨论，关于对“协同软性多租户”的支持 [Building for Trust: How to Secure Your Kubernetes](https://www.youtube.com/watch?v=YRR-kZub0cA). diff --git a/content/zh/blog/2019/appswitch/index.md b/content/zh/blog/2019/appswitch/index.md index 78f91368fa12e..fb2716a70b5b8 100644 --- a/content/zh/blog/2019/appswitch/index.md +++ b/content/zh/blog/2019/appswitch/index.md @@ -10,7 +10,7 @@ target_release: 1.0 我们正在经历一个有趣事情，对应用程序进行拆分和重组。虽然微服务需要把单体应用分解为多个微型服务，但服务网格会把这些服务连结为一个应用程序。因此，微服务是逻辑上分离而又不是相互独立的。它们通常是紧密相互依赖的，而拆分单体应用的同时会引入了许多新的问题，例如服务之间需要双向认证等。而 Istio 恰巧能解决大多数问题。 -## 依赖性排序问题{#dependency-ordering-problem} +## 依赖性排序问题 {#dependency-ordering-problem} 依赖性排序的问题是由于应用程序拆分而导致的问题且 Istio 也尚未解决 - 确保应用程序整体快速正确地的顺序启动应用程序的各个服务。在单体应用程序中，内置所有组件，组件之间的依赖顺序由内部锁机制强制执行。但是，如果单个服务分散在服务网格的集群中，则启动服务需要首先检查它所依赖的服务是否已启动且可用。 @@ -18,7 +18,7 @@ target_release: 1.0 除了在服务启动之间引入足够长的睡眠之外，还有一个常见的模式是，在启动服务之前检查被依赖的服务是否已经准备就绪。在 Kubernetes 中，可以用在 Pod 的 Init 容器中加入等待脚本的方式来完成。但是，这意味着整个应用程序将被暂停，直到所有的依赖服务都准备就绪。有时，应用程序会在启动第一次出站连接之前花几分钟时间初始化自己。不允许服务启动会增加应用程序整体启动时间的大量开销。此外，等待 init 容器的策略不适用于同一 pod 中的多个服务相互依赖的情况。 -### 示例场景：IBM WebSphere ND{#example-scenario-IBM-WebSphere} +### 示例场景：IBM WebSphere ND {#example-scenario-ibm-websphere} IBM WebSphere ND 是一个常见的应用程序中间件，通过对它的观察，能够更好地理解这种问题。它本身就是一个相当复杂的框架，由一个名为 Deployment manager（`dmgr`）的中央组件组成，它管理一组节点实例。它使用 UDP 协商节点之间的集群成员资格，并要求部署管理器在任何节点实例出现并加入集群之前已启动并可运行。 @@ -28,11 +28,11 @@ IBM WebSphere ND 是一个常见的应用程序中间件，通过对它的观察 一个 `dmgr` 及其节点实例是 WebSphere ND 的基本部署配置。构建在生产环境中运行的 WebSphere ND 之上的 IBM Business Process Manager 等应用程序包括其他一些服务。在这些配置中，可能存在一系列相互依赖关系。根据节点实例托管的应用程序，它们之间也可能存在排序要求。使用较长的服务初始化时间和崩溃循环重启，应用程序几乎没有机会在任何合理的时间内启动。 -### Istio 中的 Sidecar 依赖{#sidecar-dependency-in-Istio} +### Istio 中的 Sidecar 依赖 {#sidecar-dependency-in-istio} Istio 本身受依赖性排序问题版本的影响。由于在 Istio 下运行的服务的连接通过其 sidecar 代理重定向，因此在应用程序服务及其 sidecar 之间创建了隐式依赖关系。除非 sidecar 完全正常运行，否则所有来自服务的请求都将被丢弃。 -## 使用 AppSwitch 进行依赖性排序{#dependency-ordering-with-AppSwitch} +## 使用 AppSwitch 进行依赖性排序 {#dependency-ordering-with-appswitch} 那么我们如何解决这些问题呢？一种方法是将其推迟到应用程序并说它们应该“表现良好”并实施适当的逻辑以使自己免受启动顺序问题的影响。但是，许多应用程序（尤其是传统应用程序）如果错误则会超时或死锁。即使对于新的应用程序，为每个服务实现一个关闭逻辑也是最大的额外负担，最好避免。服务网格需要围绕这些问题提供足够的支持。毕竟，将常见模式分解为底层框架实际上是服务网格的重点。 @@ -42,7 +42,7 @@ Istio 本身受依赖性排序问题版本的影响。由于在 Istio 下运行 依赖图的要点是知道哪些客户端依赖于特定服务，以便让客户端能够等待被依赖服务准备就绪。但具体客户真的重要吗？归根结底，一个服务的所有客户端，都是依赖这个服务的。AppSwitch 正是利用这一点来解决依赖问题。事实上，这完全避免了依赖性排序。可以同时调度应用程序中的所有服务，而无需考虑启动顺序。它们之间的相互依赖性会根据各个请求和响应的粒度自动完成，从而实现快速，正确的应用程序启动。 -### AppSwitch 模型和构造{#AppSwitch-model-and-constructs} +### AppSwitch 模型和构造 {#appswitch-model-and-constructs} 既然我们对 AppSwitch 的高级方法有了概念性的理解，那么让我们来看看所涉及的结构。但首先要对使用模型进行快速总结。尽管它是针对不同的上下文编写的，但在此主题上查看我之前的 [blog](/zh/blog/2018/delayering-istio/) 也很有用。为了完整起见，我还要注意 AppSwitch 不会打扰非网络依赖。例如，两个服务可能使用 IPC 机制或通过共享文件系统进行交互。像这样的深层联系的流程通常是同一服务的一部分，并且不需要主动地对应用程序的正常执行进行干预。 @@ -52,7 +52,7 @@ AppSwitch 的核心能够使用 BSD Socket API 及其相关的其它调用（例 （3）它可以作为普通用户运行（非 root）。事实上，该机制甚至可以通过删除对网络容器的根要求来运行[非 root 的 Docker 守护进程](https://linuxpiter.com/en/materials/2478) （4）它可以不加更改的用于任何类型的应用程序上，适用于任何类型的应用程序 - 从 WebSphere ND 和 SAP 到自定义 C 应用程序，再到静态链接的 `Go` 应用程序。Linux/x86 是仅有的运行需求。 -### 将服务与其引用分离{#decoupling-services-from-their-references} +### 将服务与其引用分离 {#decoupling-services-from-their-references} AppSwitch 建立在应用程序应与其引用分离的基本前提之上。传统上，应用程序的标识源自它们运行的​​ 主机的标识。但是，应用程序和主机是需要独立引用的非常不同的对象。本[主题](https://arxiv.org/abs/1711.02294)介绍了围绕此主题的详细讨论以及 AppSwitch 的概念基础。 @@ -60,26 +60,26 @@ AppSwitch 建立在应用程序应与其引用分离的基本前提之上。传 为了便于发现可通过服务引用访问的服务，AppSwitch 提供了一个 _auto-curated 服务注册表_。根据 AppSwitch 跟踪的网络 API，当服务进出群集时，注册表会自动保持最新。注册表中的每个条目都包含相应服务绑定的 IP 和端口。除此之外，它还包括一组标签，指示此服务所属的应用程序，应用程序在创建服务时通过 Socket API 传递的 IP 和端口，AppSwitch 实际绑定基础主机上的服务的 IP 和端口此外，在 AppSwitch 下创建的应用程序带有一组用户传递的标签，用于描述应用程序以及一些默认系统标签，指示创建应用程序的用户和运行应用程序的主机等。这些标签都可以在服务引用所携带的标签选择器中表示。通过创建服务引用，可以使客户端访问注册表中的服务。然后，客户端将能够以引用的名称（IP：端口）访问服务。现在让我们来看看 AppSwitch 如何在目标服务尚在启动的过程中就让服务引用开始生效的。 -### 非阻塞请求{#non-blocking-requests} +### 非阻塞请求 {#non-blocking-requests} AppSwitch 利用 BSD Socket API 的语义，确保服务引用从客户的角度看起来是有效的，因为相应的服务出现了。当客户端对一个尚未启动的服务发起阻塞式连接调用时，AppSwitch 会阻止该调用一段时间等待目标服务变为活动状态。由于已知目标服务是应用程序的一部分并且预计很快就会出现，因此客户端会被阻塞，而不是收到 ECONNREFUSED 之类的返回信息导致启动失败。如果服务没有及时出现，则会向应用程序返回一个错误，以便像 Kubernetes 崩溃循环这样的框架级机制可以启动。 如果客户端请求被标记为非阻塞，则 AppSwitch 通过返回 `EAGAIN` 来处理该请求以通知应用程序重试而不是放弃。再次，这与 Socket API 的语义一致，并防止由于启动竞争而导致的失败。AppSwitch 通过对 BSD Socket API 的支持，将重试逻辑内置到应用程序之中，从而透明的为应用提供了依赖排序支持。 -### 应用程序超时{#application-timeouts} +### 应用程序超时 {#application-timeouts} 如果应用程序基于其自己的内部计时器超时怎么办？说实话，如果需要，AppSwitch 还可以伪造应用程序对时间的感知，但这种做法不仅越界，而且并无必要。应用程序决定并知道它应该等待多长时间，这对 AppSwitch 来说是不合适的。应用程序超过保守时长，如果目标服务仍未及时出现，则不太可能是依赖性排序问题。一定是出现了其它问题，AppSwitch 不应掩盖这些问题。 -### 为 Sidecar 提供服务引用的通配符支持{#wildcard-service-references-for-sidecar-dependency} +### 为 Sidecar 提供服务引用的通配符支持 {#wildcard-service-references-for-sidecar-dependency} 服务引用可用于解决前面提到的 Istio sidecar 依赖性问题。AppSwitch 用 IP：端口的方式来描述对服务的引用，这种描述中是可以使用通配符的。也就是说，服务引用描述中可以用 IP 掩码的形式来表达要捕捉的 IP 地址的范围。如果服务引用的标签选择器指向 sidecar 服务，则应用此服务引用的任何应用程序的所有传出连接将被透明地重定向到 sidecar。当然，在 Sidecar 启动过程中，服务引用仍然是有效的。 使用 sidecar 依赖性排序的服务引用也隐式地将应用程序的连接重定向到 sidecar ，而不需要 iptables 和随之而来的权限问题。基本上它就像应用程序直接连接到 sidecar 而不是目标目的地一样工作，让 sidecar 负责做什么。AppSwitch 将使用 sidecar 可以在将连接传递到应用程序之前解码的代理协议将关于原始目的地等的元数据插入到连接的数据流中。其中一些细节已在[此处](/zh/blog/2018/delayering-istio/)进行了讨论。出站连接是这样处理的，那么入站连接呢？由于所有服务及其 sidecar 都在 AppSwitch 下运行，因此来自远程节点的任何传入连接都将被重定向到各自的远程 sidecar 。所以传入连接没有什么特别处理。 -## 总结{#summary} +## 总结 {#summary} 依赖顺序是一个讨厌的问题。这主要是由于无法访问有关服务间交互的细粒度应用程序级事件。解决这个问题通常需要应用程序来实现自己的内部逻辑。但 AppSwitch 使这些内部应用程序事件无需更改应用程序即可进行检测。然后，AppSwitch 利用对 BSD Socket API 的普遍支持来回避排序依赖关系的要求。 -## 致谢{#acknowledgements} +## 致谢 {#acknowledgements} 感谢 Eric Herness 和团队对 IBM WebSphere 和 BPM 产品的见解和支持，我们将它们应用到现代化 Kubernetes 平台，还要感谢 Mandar Jog，Martin Taillefer 和 Shriram Rajagopalan 对于此博客早期草稿的评审。 diff --git a/content/zh/blog/2019/egress-performance/index.md b/content/zh/blog/2019/egress-performance/index.md index ce5569c29ea6f..0621429174514 100644 --- a/content/zh/blog/2019/egress-performance/index.md +++ b/content/zh/blog/2019/egress-performance/index.md @@ -23,9 +23,9 @@ target_release: 1.0 下面会讲到一些从网格中访问外部数据库的具体案例。 -## Egress 流量案例{#egress-traffic-cases} +## Egress 流量案例 {#egress-traffic-cases} -### 案例 1：绕过 Sidecar{#case-1-bypassing-the-sidecar} +### 案例 1：绕过 Sidecar {#case-1-bypassing-the-sidecar} 在这个案例中，Sidecar 对应用和外部数据库之间的通信不做拦截。这一配置是通过初始化容器中的 `-x` 参数来完成的，将其内容设置为 MongoDB 的 CIDR 即可。这种做法导致 Sidecar 忽略流入/流出指定 IP 地址的流量。举例来说： @@ -37,7 +37,7 @@ target_release: 1.0 caption="绕过 Sidecar 和外部 MongoDB 进行通信" >}} -### 案例 2：使用 Service Entry，通过 Sidecar 完成访问{#case-2-through-the-sidecar-with-service-entry} +### 案例 2：使用 Service Entry，通过 Sidecar 完成访问 {#case-2-through-the-sidecar-with-service-entry} 在 Sidecar 已经注入到应用 Pod 之后，这种方式是缺省（访问外部服务）的方式。所有的流量都被 Sidecar 拦截，然后根据配置好的规则路由到目的地，这里所说的目的地也包含了外部服务。下面为 MongoDB 配置一个 `ServiceEntry`。 @@ -46,7 +46,7 @@ target_release: 1.0 caption="Sidecar 拦截对外部 MongoDB 的流量" >}} -### 案例 3: Egress 网关{#case-3-egress-gateway} +### 案例 3: Egress 网关 {#case-3-egress-gateway} 配置 Egress 网关以及配套的 Destination Rule 和 Virtual Service，用于访问 MongoDB。所有进出外部数据库的流量都从 Egress 网关（Envoy）通过。 @@ -55,7 +55,7 @@ target_release: 1.0 caption="使用 Egress 网关访问 MongoDB" >}} -### 案例 4：在 Sidecar 和 Egress 网关之间的双向 TLS{#case-4-mutual-TLS-between-sidecars-and-the-egress-gateway} +### 案例 4：在 Sidecar 和 Egress 网关之间的双向 TLS {#case-4-mutual-tls-between-sidecars-and-the-egress-gateway} 这种方式中，在 Sidecar 和 网关之中多出了一个安全层，所以会影响性能。 @@ -64,7 +64,7 @@ target_release: 1.0 caption="在 Sidecar 和 Egress 网关之间启用双向 TLS" >}} -### 案例 5：带有 SNI Proxy 的 Egress 网关{#case-5-egress-gateway-with-SNI-proxy} +### 案例 5：带有 SNI Proxy 的 Egress 网关 {#case-5-egress-gateway-with-sni-proxy} 这个场景中，因为 Envoy 目前存在的一些限制，需要另一个代理来访问通配符域名。这里创建了一个 Nginx 代理，在 Egress 网关 Pod 中作为 Sidecar 来使用。 @@ -73,17 +73,17 @@ target_release: 1.0 caption="带有 SNI Proxy 的 Egress 网关" >}} -## 环境{#environment} +## 环境 {#environment} * Istio 版本：1.0.2 * `K8s` 版本：`1.10.5_1517` * Acmeair 应用：4 个服务（每个服务一个实例），跨服务事务，外部 MongoDB，平均载荷：620 字节。 -## 结果{#results} +## 结果 {#results} 使用 `Jmeter` 来生成负载，负载包含了一组持续五分钟的访问，每个阶段都会逐步提高客户端数量来发出 http 请求。客户端数量为：1、5、10、20、30、40、50 和 60。 -### 吞吐量{#throughput} +### 吞吐量 {#throughput} 下图展示了不同案例中的吞吐量： @@ -94,7 +94,7 @@ target_release: 1.0 如图可见，在应用和外部数据库中加入 Sidecar 和 Egress 网关并没有对性能产生太大影响；但是启用双向 TLS、又加入 SNI 代理之后，吞吐量分别下降了 10% 和 24%。 -### 响应时间{#response-time} +### 响应时间 {#response-time} 在 20 客户端的情况下，我们对不同请求的平均响应时间也进行了记录。下图展示了各个案例中平均、中位数、90%、95% 以及 99% 百分位的响应时间。 @@ -105,7 +105,7 @@ target_release: 1.0 跟吞吐量类似，前面三个案例的响应时间没有很大区别，但是双向 TLS 和 额外的代理造成了明显的延迟。 -### CPU 用量{#CPU-utilization} +### CPU 用量 {#cpu-utilization} 运行过程中还搜集了所有 Istio 组件以及 Sidecar 的 CPU 使用情况。为了公平起见，用吞吐量对 Istio 的 CPU 用量进行了归一化。下图中展示了这一结果： @@ -116,6 +116,6 @@ target_release: 1.0 经过归一化处理之后的 CPU 用量数据表明，Istio 在使用 Egress 网关 + SNI 代理的情况下，消耗了更多的 CPU。 -## 结论{#conclusion} +## 结论 {#conclusion} 在这一系列的测试之中，我们用不同的方式来访问一个启用了 TLS 的 MongoDB 来进行性能对比。Egress 网关的引用没有对性能和 CPU 消耗的显著影响。但是启用了 Sidecar 和 Egress 网关之间的双向 TLS 或者为通配符域名使用了额外的 SNI 代理之后，会看到性能降级的现象。 diff --git a/content/zh/blog/2019/introducing-istio-operator/index.md b/content/zh/blog/2019/introducing-istio-operator/index.md index c4f40e69dcb32..15e40b95d2473 100644 --- a/content/zh/blog/2019/introducing-istio-operator/index.md +++ b/content/zh/blog/2019/introducing-istio-operator/index.md @@ -77,7 +77,7 @@ $ istioctl manifest apply --set telemetry.enabled=false 更多信息请参考 Istio [安装说明](/zh/docs/setup/install/istioctl)。 -## Istio Controller (alpha){#Istio-controller-alpha} +## Istio Controller (alpha) {#istio-controller-alpha} Operator 实现使用 Kubernetes controller 来持续监控它们的自定义资源并应用相应的配置更改。Istio controller 监控一个 `IstioControlPlane` 资源，并通过更新相应集群中的 Istio 安装配置来响应更改。 @@ -98,7 +98,7 @@ $ kubectl edit istiocontrolplane example-istiocontrolplane -n istio-system Operator controller 和 `istioctl` 命令共享相同的实现。重要的区别在于其执行上下文。对于 `istioctl`，操作在管理用户的命令执行和安全上下文中运行。对于 controller，集群中的一个 pod 在其安全上下文中运行代码。在这两种情况下，都根据一个 schema 来验证配置，并执行相同的正确性检查。 -## 从 Helm 迁移{#migration-from-helm} +## 从 Helm 迁移 {#migration-from-helm} 为了方便从使用 Helm 过渡，`istioctl` 和 controller 支持对 Helm 安装 API 的透传访问。 @@ -120,13 +120,13 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true 另一个可以帮助从 Helm 迁移的特性是这个 alpha 命令：[{{< istioctl >}} manifest migrate](/zh/docs/reference/commands/istioctl/#istioctl-manifest-migrate)。 此命令可用于将 Helm `values.yaml` 文件自动转换为相应的 `IstioControlPlane` 配置。 -## 实现{#implementation} +## 实现 {#implementation} 已经创建了几个框架，通过为部分或所有组件生成存根来帮助实现 Operator。Istio Operator 是在 [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) 和 [Operator Framework](https://github.com/operator-framework) 的帮助下创建的。Istio 的安装现在使用 proto 来描述 API，这样就可以通过 schema 对执行运行时进行验证。 有关实现的更多信息可以在 [Istio Operator 仓库](https://github.com/istio/operator) 中的 README 和 ARCHITECTURE 文档中找到。 -## 总结{#summary} +## 总结 {#summary} 从 Istio 1.4 开始，Helm 安装将被新的 `istioctl` 命令所取代，该命令使用新的 Operator 自定义资源定义，`IstioControlPlane`，作为配置 API。一个 alpha controller 也被提供用于 Operator 的早期实验。 diff --git a/content/zh/blog/2019/istio1.1_perf/index.md b/content/zh/blog/2019/istio1.1_perf/index.md index ec4760c452062..cc7c6ed2f7e6c 100644 --- a/content/zh/blog/2019/istio1.1_perf/index.md +++ b/content/zh/blog/2019/istio1.1_perf/index.md @@ -26,7 +26,7 @@ target_release: 1.1 祝贺那些来自世界各地的为此次版本发布做出贡献的 Istio 专家。我们对这些结果无比高兴。 -## Istio 1.1 性能增强{Istio-1-1-performance-enhancements} +## Istio 1.1 性能增强 {#istio-1-1-performance-enhancements} 作为 Istio Performance and Scalability （性能和可伸缩）工作组的成员，我们进行了广泛的性能评估。我们与其他 Istio 贡献者合作，为 Istio 1.1 引入了许多旨在提高性能的新特性。1.1 中一些显著的性能增强包括: @@ -38,22 +38,22 @@ target_release: 1.1 - 为限制遥测数据的可配置过滤器 - 解除同步瓶颈 -## 持续的代码质量和性能验证{continuous-code-quality-and-performance-verification} +## 持续的代码质量和性能验证 {#continuous-code-quality-and-performance-verification} 回归巡检促进了 Istio 性能和质量的不断提高，在幕后帮助 Istio 开发者识别并修正代码错误。每天的构建都会经过以客户为中心的性能基准 [BluePerf](https://github.com/blueperf/) 的性能检测。测试结果会展示在 [Istio 社区门户网站](https://ibmcloud-perf.istio.io/regpatrol/)。评估了各种应用配置以帮助洞悉 Istio 组件的性能。 另一个用于评估 Istio 构建性能的工具是 [Fortio](https://fortio.org/)，它提供了一个综合的端到端的压力测试基准。 -## 概要{summary} +## 概要 {#summary} Istio 1.1 旨在提高性能和可扩展性。Istio Performance and Scalability （性能和可扩展性）工作组实现了自 1.0 以来显著的性能改进。 Istio 1.1 提供的新特性和功能优化，提高了服务网格对企业工作负载的支撑能力。Istio 1.1 性能和调优指南记录了性能模拟，提供了调整和容量规划指导，并包含了调优客户用例的最佳实践。 -## 有用的链接{useful-links} +## 有用的链接 {#useful-links} - [Istio 服务网格性能 (34:30)](https://www.youtube.com/watch?time_continue=349&v=G4F5aRFEXnU), 作者：Surya Duggirala, Laurent Demailly 和 Fawad Khaliq 于 KubeCon Europe 2018 - [Istio 性能和可扩展性讨论专题](https://discuss.istio.io/c/performance-and-scalability) -## 免责声明{disclaimer} +## 免责声明 {#disclaimer} 这里展示的性能数据是在一个可控的隔离环境中产生的。在其他环境中获得的实际结果可能存在较大差异。无法保证在其他地方获得相同或类似的结果。 diff --git a/content/zh/blog/2019/knative-activator-adapter/index.md b/content/zh/blog/2019/knative-activator-adapter/index.md index 9d8880941509f..8294dd56730b8 100644 --- a/content/zh/blog/2019/knative-activator-adapter/index.md +++ b/content/zh/blog/2019/knative-activator-adapter/index.md @@ -10,7 +10,7 @@ target_release: 1.3 这篇文章演示了如何使用 [Mixer](/zh/faq/mixer/) 把应用逻辑放进 Istio。它描述了一个用简单的代码实现了 Knative scale-from-zero 逻辑的 Mixer 适配器，该适配器和原有实现的性能相差无几。 -## Knative Serving{#Knative-serving} +## Knative Serving [Knative Serving](https://knative.dev/docs/serving/) 基于 [Kubernetes](https://kubernetes.io/zh-cn/) 来支持 Serverless 应用的部署和服务（Serving）。一个 Serverless 平台的核心功能就是 scale-to-zero，该功能可减少非活动工作负载的资源使用量和成本。当空闲应用收到新请求时，需要一种新的机制来 scale-from-zero。 @@ -26,7 +26,7 @@ target_release: 1.3 一旦应用启动并再次运行，Knative 就会把请求路由到正在运行的应用上（之前请求是路由到 **Activator** 的）。 -## Mixer 适配器{#mixer-adapter} +## Mixer 适配器 {#mixer-adapter} [Mixer](/zh/faq/mixer/) 在 Istio 组件和基础设施后端之间提供了一个丰富的中介层。它是独立于 [Envoy](https://www.envoyproxy.io/) 的组件，并且具有简单的可扩展性模型，该扩展模型使 Istio 可以与大部分后端进行交互。Mixer 本质上比 Envoy 更容易扩展。 @@ -51,7 +51,7 @@ Istio 的 Mixer 适配器模式使得我们可以用更简单的方式实现原 当适配器从 **Mixer** 接收到消息时，它会使用 Knative 协议直接向 **Autoscaler** 发送一个 `StatMessage`。Istio 代理将 **Autoscaler** 所需的元数据信息（`namespace` 和 `service name`）传输到 **Mixer**，再从那里传输到适配器。 -## 总结{#summary} +## 总结 {#summary} 我将 Knative 原有的参考架构的冷启动（cold-start）时间与新的 Istio Mixer 适配器参考架构进行了比较。结果显示它们的冷启动时间很接近。使用 Mixer 适配器的实现更加简单。无需处理基于底层网络的机制，因为这些机制是由 Envoy 处理的。 diff --git a/content/zh/blog/2019/performance-best-practices/index.md b/content/zh/blog/2019/performance-best-practices/index.md index 208c794dedf48..9a1f35b91c498 100644 --- a/content/zh/blog/2019/performance-best-practices/index.md +++ b/content/zh/blog/2019/performance-best-practices/index.md @@ -16,7 +16,7 @@ keywords: [performance,scalability,scale,benchmarks] 在 [Istio Tools 仓库](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark)中，您将找到用于测量 Istio 数据平面性能的脚本和说明，以及有关如何使用另一服务网格实现 [Linkerd](https://linkerd.io) 运行脚本的其他说明。在我们详细介绍性能测试框架的每个步骤的一些最佳实践时，请[遵循](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#setup)。 -## 1. 使用生产就绪的 Istio 安装{#1-use-a-production-ready-Istio-installation} +## 1. 使用生产就绪的 Istio 安装 {#1-use-a-production-ready-istio-installation} 为了准确地大规模度量服务网格的性能，使用[适当大小的](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install#istio-setup) Kubernetes 集群很重要。我们使用三个工作节点进行测试，每个工作节点至少具有 4 vCPU 和 15 GB 的内存。 @@ -24,7 +24,7 @@ keywords: [performance,scalability,scale,benchmarks] {{< warning_icon >}} Istio 的 [demo 安装](/zh/docs/setup/getting-started/)不适合进行性能测试，因为它被设计为部署在小型试用群集中，并且具有完整的跟踪和访问日志，可显示 Istio 的功能。 -## 2. 专注于数据平面{#2-focus-on-the-data-plane} +## 2. 专注于数据平面 {#2-focus-on-the-data-plane} 我们的基准测试脚本专注于评估 Istio 数据平面：{{}}Envoy{{}} 代理，可在应用容器之间进行流量调度。为什么要关注数据平面？因为在大规模使用大量应用容器时，数据平面的 **内存** 和 **CPU** 使用率很快就会超过 Istio 控制平面。让我们看一个具体的例子： @@ -43,7 +43,7 @@ keywords: [performance,scalability,scale,benchmarks] 为什么只用两个 pod 测试？因为增加吞吐量（RPS）和连接（线程）对 Envoy 的性能的影响比增加服务注册表的总大小（或 Kubernetes 集群中 Pod 和服务的总数）更大。当服务注册表的大小增加时，Envoy 必须跟踪更多的端点，并且每个请求的查找时间确实增加了，但是增加了一个很小的常数。如果您有许多服务，并且此常数成为延迟问题，则 Istio 提供 [Sidecar 资源](/zh/docs/reference/config/networking/sidecar/)，它使您可以限制每个 Envoy 知道的服务。 -## 3. 有/无 度量的代理{#3-measure-with-and-without-proxies} +## 3. 有/无 度量的代理 {#3-measure-with-and-without-proxies} 尽管 Istio 的许多特性，例如[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication)，都依赖于应用 pod 的 Envoy 代理，但是您可以[选择性地禁用](/zh/docs/setup/additional-setup/sidecar-injection/#disabling-or-updating-the-webhook)一些网格服务的 sidecar 代理注入。在扩展 Istio 以进行生产时，您可能需要将 sidecar 代理增量添加到工作负载中。 @@ -51,7 +51,7 @@ keywords: [performance,scalability,scale,benchmarks] 您还可以在性能测试期间禁用 [Mixer](/zh/docs/concepts/observability/) 以停止 Istio 的遥测，这将得到与 Mixer V2 工作完成时我们期望的性能相符的结果。Istio 还支持 [Envoy 本地遥测](https://github.com/istio/istio/wiki/Envoy-native-telemetry)，其功能类似于禁用 Istio 的遥测。 -## Istio 1.2 性能{#Istio-1-2-performance} +## Istio 1.2 性能 {#istio-1-2-performance} 让我们看看如何使用该测试环境来分析 Istio 1.2 数据平面的性能。我们还提供了运行 [Linkerd 数据平面的相同性能测试](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark/linkerd)的说明。Linkerd 目前仅支持延迟基准测试。 @@ -93,7 +93,7 @@ keywords: [performance,scalability,scale,benchmarks] caption="" >}} -## 总结{#summary} +## 总结 {#summary} 在对 Istio 的性能进行基准测试的过程中，我们吸取了一些重要的经验教训： diff --git a/content/zh/blog/2021/better-external-authz/index.md b/content/zh/blog/2021/better-external-authz/index.md index 9ce051a5ed977..9a5899e10c755 100644 --- a/content/zh/blog/2021/better-external-authz/index.md +++ b/content/zh/blog/2021/better-external-authz/index.md @@ -467,7 +467,7 @@ EOF {{< /tabset >}} -### 测试 OPA 策略 {##test-the-opa-policy} +### 测试 OPA 策略 {#test-the-opa-policy} 1. 创建一个客户端 Pod 来发送请求： diff --git a/content/zh/docs/ops/best-practices/security/index.md b/content/zh/docs/ops/best-practices/security/index.md index dd15ce2d3646c..c5f5d95859ecf 100644 --- a/content/zh/docs/ops/best-practices/security/index.md +++ b/content/zh/docs/ops/best-practices/security/index.md @@ -445,7 +445,7 @@ Istio 代理，以便现有的连接将被关闭，新的连接将受到新策 当结合[网络策略](/zh/docs/tasks/traffic-management/egress/egress-gateway/#apply-kubernetes-network-policies)一起使用时， 您可以强制所有出站流量，或者部分通过 Egress 网关。这确保了即使客户端因意外或者被恶意绕过它的代理，请求将会被阻止。 -## 当使用 TLS 源时在目标规则上配置 TLS 验证 {#configure-TLS-verification-in-destination-rule-when-using-TLS-origination} +## 当使用 TLS 源时在目标规则上配置 TLS 验证 {#configure-tls-verification-in-destination-rule-when-using-tls-origination} Istio 提供了从 Sidecar 代理或者网关上[发起 TLS](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/) 的能力。这使得从应用发出的明文 HTTP 流量可以透明地“升级”到 HTTPS。 @@ -538,7 +538,7 @@ servers: 同时在一个共享的网关实例上运行多个较不敏感的域，例如 `blog.example.com` 和 `store.example.com`。 这种方式提供了更好的纵深防御并且利于实现监管准则。 -### 显式阻止所有的敏感 http 主机被宽泛的 SNI 匹配 {#explicitly-disable-all-the-sensitive-http-host-under-relaxed-SNI-host-matching} +### 显式阻止所有的敏感 http 主机被宽泛的 SNI 匹配 {#explicitly-disable-all-the-sensitive-http-host-under-relaxed-sni-host-matching} 使用多个 `Gateway` 资源来在不同的主机上定义多个双向或者单向 TLS 是很合理的。 例如，在 SNI 主机 `admin.example.com` 上使用双向 TLS，在 SNI 主机 `*.example.com` 上使用单向 TLS。 @@ -614,7 +614,7 @@ Istio 可以[自动确定流量协议](/zh/docs/ops/configuration/traffic-manage 但为了避免意外或者有意的误检测，从而导致意外流量行为发生。 推荐[显式地声明协议](/zh/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection)。 -## CNI 网络容器接口 {#CNI} +## CNI 网络容器接口 {#cni} 为了透明地劫持所以流量，Istio 依赖 通过 `istio-init` `initContainer` 配置 `iptables` 规则。 这增加了一个[要求](/zh/docs/ops/deployment/application-requirements/)，即需要提供给 Pod `NET_ADMIN` diff --git a/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md b/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md index 8d93ee92ac185..2c9e37be881b7 100644 --- a/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md +++ b/content/zh/docs/ops/configuration/traffic-management/dns-proxy/index.md @@ -81,7 +81,7 @@ spec: 默认启用基础 DNS 代理。 {{< /tip >}} -## DNS 捕获 {#DNS-capture-in-action} +## DNS 捕获 {#dns-capture-in-action} 为了尝试 DNS 捕获，首先为某些外部服务启动一个 `ServiceEntry`： diff --git a/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md b/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md index de2e9a48c2a2b..0737225b93ae8 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md @@ -6,11 +6,11 @@ aliases: - /zh/about/notes/1.1 --- -## 从 1.0 开始的不兼容变更{#incompatible-changes-from-1-0} +## 从 1.0 开始的不兼容变更 {#incompatible-changes-from-1-0} 除了下面列出的新功能和改进之外，Istio 从 1.0 开始就引入了许多重要改进，这些改进可以更改应用程序的行为。在[升级说明](/zh/news/releases/1.1.x/announcing-1.1/upgrade-notes)中可以找到这些改进的简明清单。 -## 升级{#upgrades} +## 升级 {#upgrades} 我们建议手动将控制平面和数据平面升级到 1.1。有关更多信息，请参见[升级文档](/zh/docs/setup/upgrade/)。 @@ -18,7 +18,7 @@ aliases: 在将 deployment 升级到 Istio 1.1 之前，请务必查看[升级说明](/zh/news/releases/1.1.x/announcing-1.1/upgrade-notes)以获得您应该了解的简要清单。 {{< /warning >}} -## 安装{#installation} +## 安装 {#installation} - **将 CRD 安装从 Istio 安装中分离出来**。将 Istio 的自定义资源（CRD）放入 `istio-init` Helm chart 中。将 CRD 放置在自己的 Helm chart 中，可以在升级过程中保留自定义资源内容的数据连续性，并进一步使 Istio 能够超越基于 Helm 的安装。 @@ -26,7 +26,7 @@ aliases: - **改进多集群集成**。将 `istio-remote` chart 1.0 合并到 Istio Helm chart 中，从而简化操作体验，其先前用于[多集群 VPN](/zh/docs/setup/install/multicluster/shared-vpn/) 和[多集群水平拆分](/zh/docs/setup/install/multicluster/shared-gateways/)远程集群安装。 -## 流量管理{#traffic-management} +## 流量管理 {#traffic-management} - **新的 `Sidecar` 资源**。通过新的 [sidecar](/zh/docs/concepts/traffic-management/#sidecars) 资源，可以更精细地控制附加到命名空间中工作负载的 sidecar 代理的行为。特别是，它增加了对限制 sidecar 向其发送流量的服务集的支持。这减少了计算和传输给代理的配置量，从而改善了启动时间、资源消耗和控制平面可伸缩性。对于复杂部署，我们建议为每个命名空间添加 sidecar 资源。我们还为高级用例的端口、协议和流量捕获提供了控件。 @@ -46,7 +46,7 @@ aliases: - **默认关闭访问日志**。默认情况下，禁用所有 Envoy sidecar 的访问日志以提高性能。 -### 安全{#security} +### 安全 {#security} - **就绪和存活探针**。添加了对 Kubernetes HTTP [就绪和存活探针](/zh/faq/security/#k8s-health-checks)的支持（启用双向 TLS 时）。 @@ -64,7 +64,7 @@ aliases: - **自定义信任域（非`cluster.local`）**。在标识中增加了对特定于组织或群集的信任域的支持。 -## 策略和遥测{#policies-and-telemetry} +## 策略和遥测 {#policies-and-telemetry} - **默认关闭策略检查**。默认情况下，修改后的策略检查是关闭的，以提高大多数客户方案的性能。[启用策略执行](/zh/docs/tasks/policy-enforcement/enabling-policy/)详细说明了如何根据需要开启 Istio 策略检查。 @@ -100,13 +100,13 @@ aliases: - **更加灵活的 `statsd` 收集器**。删除了内置的 `statsd` 收集器。Istio 现在支持您自己的 `statsd`，以提高现有 Kubernetes 部署的灵活性。 -### 配置管理{#configuration-management} +### 配置管理 {#configuration-management} - **Galley**。添加 [Galley](/zh/docs/ops/deployment/architecture/#galley) 作为 Istio 主要的配置收集和分发装置。它提供了一个健壮的模型来验证，转换配置状态并将其分配给 Istio 组件，从而将 Istio 组件与 Kubernetes 详细信息隔离开来。Galley 使用[网格配置协议](https://github.com/istio/api/tree/{{}}/mcp)与组件进行交互。 - **监听端口**。将 Galley 的默认监听端口从 9093 修改为 15014。 -## `istioctl` 和 `kubectl`{#Istio-and-Kube} +## `istioctl` 和 `kubectl` {#istioctl-and-kubectl} - **验证命名**。添加 [`istioctl validate`](/zh/docs/reference/commands/istioctl/#istioctl-validate) 命令，用于 Istio Kubernetes 资源的离线验证。 diff --git a/content/zh/news/releases/1.12.x/announcing-1.12/_index.md b/content/zh/news/releases/1.12.x/announcing-1.12/_index.md index 8065a272fc5c2..9e75abdf672c7 100644 --- a/content/zh/news/releases/1.12.x/announcing-1.12/_index.md +++ b/content/zh/news/releases/1.12.x/announcing-1.12/_index.md @@ -23,7 +23,7 @@ Istio 1.12.0 在 Kubernetes `1.19` 到 `1.22` 版本上得到了官方支持。 以下是该版本的一些亮点： -## WebAssembly API{#WebAssembly-API} +## WebAssembly API [WebAssembly](/zh/docs/concepts/wasm/) 一直是一个重要的项目，已经开发了 [3 年多](/zh/blog/2020/wasm-announce/)，通过允许用户在运行时动态加载自定义扩展，为 Istio 带来高级的可扩展性。 然而，到目前为止，配置 WebAssembly 插件还处于实验阶段，并且很难使用。 @@ -34,7 +34,7 @@ Istio 1.12.0 在 Kubernetes `1.19` 到 `1.22` 版本上得到了官方支持。 该 API 目前处于 alpha 阶段并在不断发展。感谢[您的反馈](/zh/get-involved/)！ -## Telemetry API{#Telemetry-API} +## Telemetry API 在 Istio 1.11 中，我们引入了一个全新的 [`Telemetry` API](/zh/docs/reference/config/telemetry/)，带来了一个标准化的 API，用于在 Istio 中配置跟踪、日志记录和指标。 @@ -49,7 +49,7 @@ Istio 1.12.0 在 Kubernetes `1.19` 到 `1.22` 版本上得到了官方支持。 该 API 目前处于 alpha 阶段并在不断发展。感谢[您的反馈](/zh/get-involved/)！ -## Helm 支持{#helm-support} +## Helm 支持 {#helm-support} Istio 1.12 对我们的 [Helm 安装支持](/zh/docs/setup/install/helm/)进行了许多改进，并为该功能在未来升级到测试版铺平了道路。 @@ -61,7 +61,7 @@ Istio 1.12 对我们的 [Helm 安装支持](/zh/docs/setup/install/helm/)进行 此外，还发布了新的精制的 [`gateway` chart](https://artifacthub.io/packages/helm/istio-official/gateway) 图表。 这个 chart 取代了旧的 `istio-ingressgateway` 和 `istio-egressgateway` charts，极大地简化了网关的管理，并遵循 Helm 的最佳实践。请访问网关注入页面，了解迁移到 helm chart 的说明。 -## Kubernetes Gateway API{#Kubernetes-Gateway-API} +## Kubernetes Gateway API Istio 已经完全支持 `v1alpha2` 版本的 [Kubernetes Gateway API](http://gateway-api.org/)。 该 API 的目的是统一 Istio、Kubernetes `Ingress` 和其他代理使用的各种 API 集，以定义一个强大的、可扩展的 API 来配置流量路由。 @@ -69,7 +69,7 @@ Istio 已经完全支持 `v1alpha2` 版本的 [Kubernetes Gateway API](http://ga 虽然 API 还没有针对生产工作负载，但 API 和 Istio 的实现正在迅速发展。 要试用它，请查看 [Kubernetes Gateway API](/zh/docs/tasks/traffic-management/ingress/gateway-api/) 文档。 -## 还有很多很多{#and-much-much-more} +## 还有很多很多 {#and-much-much-more} * Default Retry Policies 已经被添加到 [Mesh Config](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig)，允许用户在单个位置配置默认的重试策略，而不是在每个 VirtualService 中重复配置。 * 一个新的 `failoverPriority` 配置已经添加到[Locality Load Balancing 配置](/zh/docs/reference/config/networking/destination-rule/#LocalityLoadBalancerSetting)中，允许自定义 Pod 的优先级。例如，同一网络中的 Pod 可以被赋予额外的优先级。 diff --git a/content/zh/news/releases/1.13.x/announcing-1.13.1/index.md b/content/zh/news/releases/1.13.x/announcing-1.13.1/index.md index 98ceb46d2a97d..ef67633c84053 100644 --- a/content/zh/news/releases/1.13.x/announcing-1.13.1/index.md +++ b/content/zh/news/releases/1.13.x/announcing-1.13.1/index.md @@ -13,12 +13,12 @@ aliases: {{< relnote >}} -## 安全更新{#security-update} +## 安全更新 {#security-update} - __[CVE-2022-23635](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2022-23635)__: CVE-2022-23635 (CVSS Score 7.5, High): Istio 控制平面容易受到请求处理错误的影响，允许未经身份验证的恶意攻击者发送特制消息，从而导致控制平面崩溃。 -### Envoy CVEs{#envoy-cves} +### Envoy CVE {#envoy-cves} 目前，人们认为 Istio 不会受到 Envoy 中这些 CVE 的攻击。然而还是将它们在下面列举出来，以让 Istio 的使用者们都能够知道。 @@ -40,7 +40,7 @@ aliases: - __[CVE-2022-23606](https://github.com/envoyproxy/envoy/security/advisories/GHSA-9vp2-4cp7-vvxf)__: (CVSS Score 4.4, Moderate): 当通过 Cluster Discovery Service 删除集群时，堆栈耗尽。 -# 改变{#changes} +# 改变 {#changes} - **修复** 修复了 `istioctl x describe svc` 无法正确评估 `appProtocol` 协议端口的问题。 ([Issue #37159](https://github.com/istio/istio/issues/37159)) diff --git a/content/zh/news/releases/1.13.x/announcing-1.13.2/index.md b/content/zh/news/releases/1.13.x/announcing-1.13.2/index.md index 97d4a9020c36b..f5405e9f51af3 100644 --- a/content/zh/news/releases/1.13.x/announcing-1.13.2/index.md +++ b/content/zh/news/releases/1.13.x/announcing-1.13.2/index.md @@ -14,12 +14,12 @@ aliases: {{< relnote >}} -## 安全更新{#security-update} +## 安全更新 {#security-update} - __[CVE-2022-24726](https://github.com/istio/istio/security/advisories/GHSA-8w5h-qr4r-2h6g)__: (CVSS Score 7.5, High): Istio 控制平面容易受到请求处理错误的影响，允许未经验证的恶意攻击者发送特制或超大消息，从而堆栈耗尽造成控制平面崩溃。 -## 新增{#changes} +## 新增 {#changes} - **新增** 新增一个 OpenTelemetry 访问日志程序。 ([Issue #36637](https://github.com/istio/istio/issues/36637)) @@ -36,7 +36,7 @@ aliases: - **修复** 修复了使用 Telemetry API 启用 Stackdriver 指标收集时，在某些场景中错误地启用日志记录的问题。 ([Issue #37667](https://github.com/istio/istio/issues/37667)) -### Envoy CVEs{#envoy-cves} +### Envoy CVE {#envoy-cves} 目前，人们认为 Istio 不会受到 Envoy 中这些 CVE 的攻击。然而还是将它们在下面列举出来， 以让 Istio 的使用者们都能够知道。 diff --git a/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md b/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md index 83798a03d12f3..62d647e521b1f 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md @@ -60,7 +60,7 @@ aliases: 要看全部的变动，请参阅[安装选项变动页面](/zh/news/releases/1.2.x/announcing-1.2/helm-changes/)。 -## `istioctl` 和 `kubectl` {#Istio-control-and-Kube-control} +## `istioctl` 和 `kubectl` {#istioctl-and-kubectl} - **毕业** `istioctl verify-install` 走出实验标签。 - **改进** `istioctl verify-install` 可以验证给定的 Kubernetes 环境是否满足 Istio 的要求。 diff --git a/content/zh/news/releases/1.4.x/announcing-1.4.10/index.md b/content/zh/news/releases/1.4.x/announcing-1.4.10/index.md index 05e56b57a55cf..970bc8cd4a8ba 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4.10/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4.10/index.md @@ -17,7 +17,7 @@ aliases: {{< relnote >}} -## 安全更新 +## 安全更新 {#security-update} - **ISTIO-SECURITY-2020-006** 处理了当有过多参数的 HTTP/2 SETTINGS 帧时 CPU 的使用率过高，可能导致服务禁止的问题。 @@ -31,6 +31,6 @@ __[CVE-2020-11080](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11080 - **修复** 修复了当 DNS 不可访问时，Istio CNI 导致 pod 初始化时花费 30-40 秒的延迟的问题。 ([Issue 23770](https://github.com/istio/istio/issues/23770)) -## 安全修复 Bookinfo 示例应用程序{#Bookinfo sample application security fixes} +## 安全修复 Bookinfo 示例应用程序 {#bookinfo-sample-application-security-fixes} 我们更新了 Bookinfo 示例应用程序中使用的 Node.js 和 jQuery 的版本。 Node.js 已经从 12.9 版本升级到 12.18 版本。jQuery 已经从 2.1.4 版本升级到 3.5.0。评分最高的漏洞已修复：*HTTP 请求夹带使用 Transfer-Encoding 头 (Critical) (CVE-2019-15605)* diff --git a/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md b/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md index d47c6700c894b..f786521889ebb 100644 --- a/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md +++ b/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md @@ -6,7 +6,7 @@ weight: 20 此页面描述了从 Istio 1.4.x 升级到 1.5.x 时需要注意的更改。在这里，我们详细介绍了有意不再向下兼容情况。还提到了保留向下兼容但引入了新行为的情况，熟悉 Istio 1.4 的使用和操作的人可能会感到惊讶。 -## 重构控制平面{#control-plane-restructuring} +## 重构控制平面 {#control-plane-restructuring} 在 Istio 1.5 中，我们开始使用新的控制平面 deployment 模型，其中整合了许多组件。下面各功能迁移位置的说明。 @@ -14,7 +14,7 @@ weight: 20 Istio 1.5，会有一个新的 deployment：`istiod`。该组件是控制平面的核心，负责处理配置、证书分发以及 sidecar 注入等。 -### sidecar 注入{#sidecar-injection} +### sidecar 注入 {#sidecar-injection} 以前，sidecar 注入是通过一个可变的 webhook 处理的，该 webhook 由名为 `istio-sidecar-injector` 的 deployment 处理。在 Istio 1.5 中，保留了相同的可变 webhook，但现在它指向 `istiod` deployment，其它所有注入逻辑保持不变。 @@ -28,7 +28,7 @@ Istio 1.5，会有一个新的 deployment：`istiod`。该组件是控制平面 以前，Citadel 有两个功能：将证书写入至每个命名空间中的 secret、在使用 SDS 时通过 gRPC 将 secret 提供给 `nodeagent`。在 Istio 1.5 中，secret 不再写入至每个命名空间。而是仅通过 gRPC 提供服务。并且，此功能已迁移至 `istiod` deployment。 -### SDS 节点代理{#sds-node-agent} +### SDS 节点代理 {#sds-node-agent} 移除 `nodeagent` deployment。现在，此功能存在于 Envoy sidecar 中。 @@ -44,7 +44,7 @@ Istio 1.5，会有一个新的 deployment：`istiod`。该组件是控制平面 移除 `istio-pilot` deployment，以便支持 `istiod` deployment，`istiod` 包含了 Pilot 曾经拥有的所有功能。为了向下兼容，保留了一些对 Pilot 的引用。 -## 弃用 Mixer{#mixer-deprecation} +## 弃用 Mixer {#mixer-deprecation} Mixer，即 `istio-telemetry` 和 `istio-policy` deployment 背后的过程，在 1.5 版本中被弃用了。Istio 1.3 开始，默认禁用了 `istio-policy`，而 Istio 1.5 ，默认禁用了 `istio-telemetry`。 @@ -56,7 +56,7 @@ Mixer，即 `istio-telemetry` 和 `istio-policy` deployment 背后的过程， 查看[弃用 Mixer](https://tinyurl.com/mixer-deprecation) 获取详细信息。 -### Telemetry V2 和 Mixer Telemetry 的差异{#feature-gaps-between-telemetry-v2-and-mixer-telemetry} +### Telemetry V2 和 Mixer Telemetry 的差异 {#feature-gaps-between-telemetry-v2-and-mixer-telemetry} * 不支持网格外遥测。如果流量源或目的地未注入 sidecar，则会缺少某些遥测数据。 * [不支持](https://github.com/istio/istio/issues/19385) Egress gateway 遥测。 @@ -64,7 +64,7 @@ Mixer，即 `istio-telemetry` 和 `istio-policy` deployment 背后的过程， * 不支持针对 TCP 和 HTTP 的黑洞遥测。 * 直方图与 [Mixer Telemetry](https://github.com/istio/istio/issues/20483) 显著不同，且无法更改。 -## 认证策略{#authentication-policy} +## 认证策略 {#authentication-policy} Istio 1.5 引入了 [`PeerAuthentication`](/zh/docs/reference/config/security/peer_authentication/) 和 [`RequestAuthentication`](/zh/docs/reference/config/security/request_authentication) （它们取代了 Authentication API 的 Alpha 版本）。有关新 API 的更多信息，请参见 [authentication policy](/zh/docs/tasks/security/authentication/authn-policy) 教程。 @@ -77,12 +77,12 @@ $ kubectl delete policies.authentication.istio.io --all-namespaces --all $ kubectl delete meshpolicies.authentication.istio.io --all {{< /text >}} -## Istio workload 密钥及证书配置{#Istio-workload-key-and-certificate-provisioning} +## Istio workload 密钥及证书配置 {#istio-workload-key-and-certificate-provisioning} * 我们已经稳定了 SDS 证书和密钥配置流程。现在，Istio workload 使用 SDS 来提供证书。不建议再使用通过 secret 卷挂载的方法。 * 请注意，启用双向 TLS 后，需要手动修改 Prometheus deployment 以监控 workload。详细信息在此 [issue](https://github.com/istio/istio/issues/21843) 中。该问题将在 1.5.1 中解决。 -## 控制平面安全{#control-plane-security} +## 控制平面安全 {#control-plane-security} 作为 Istiod 努力的一部分，我们已经更改了代理与控制平面安全通信的方式。在以前的版本中，当配置了 `values.global.controlPlaneSecurityEnabled=true` 设置时，代理将安全地连接到控制平面，这也是 Istio 1.4 的默认设置。每个控制平面组件都运行带有 Citadel 证书的 sidecar，并且代理通过端口 15011 连接到 Pilot。 @@ -90,7 +90,7 @@ $ kubectl delete meshpolicies.authentication.istio.io --all 注意：尽管如此，但在 Istio 1.5 中，将 `controlPlaneSecurityEnabled` 设置为 `false` 时，默认情况下控制平面之间的通信已经是安全的。 -## 多集群安装{#multicluster-setup} +## 多集群安装 {#multicluster-setup} {{< warning >}} 如果您使用的是多集群，建议您不要升级到 Istio 1.5.0! @@ -98,6 +98,6 @@ $ kubectl delete meshpolicies.authentication.istio.io --all 多集群 Istio 1.5.0 目前存在几个已知问题，这些问题（[27102](https://github.com/istio/istio/issues/21702), [21676](https://github.com/istio/istio/issues/21676)）使其在共享控制平面和控制平面副本集 deployment 中均无法使用。这些问题将在 Istio 1.5.1 中解决。 {{< /warning >}} -## Helm 升级{#helm-upgrade} +## Helm 升级 {#helm-upgrade} 如果您使用 `helm upgrade` 将群集更新到较新的 Istio 版本，则建议您使用 [`istioctl upgrade`](/zh/docs/setup/upgrade/istioctl-upgrade/) 或遵循 [helm template](/zh/docs/setup/upgrade/cni-helm-upgrade/) 的步骤。 diff --git a/content/zh/news/releases/1.7.x/announcing-1.7.6/index.md b/content/zh/news/releases/1.7.x/announcing-1.7.6/index.md index 54bcd8312300d..a4f600589615e 100644 --- a/content/zh/news/releases/1.7.x/announcing-1.7.6/index.md +++ b/content/zh/news/releases/1.7.x/announcing-1.7.6/index.md @@ -13,7 +13,7 @@ aliases: {{< relnote >}} -## 变动#{changes} +## 变动 {#changes} - **修复** 导致遥测 HPA 设置被在线副本覆盖的问题。([Issue #28916](https://github.com/istio/istio/issues/28916)) diff --git a/content/zh/news/security/istio-security-2022-001/index.md b/content/zh/news/security/istio-security-2022-001/index.md index b9d2542b25290..52245350eccfb 100644 --- a/content/zh/news/security/istio-security-2022-001/index.md +++ b/content/zh/news/security/istio-security-2022-001/index.md @@ -13,19 +13,19 @@ skip_seealso: true {{< security_bulletin >}} -## CVE{#CVE} +## CVE -### CVE-2022-21679{#CVE-2022-21679} +### CVE-2022-21679 Istio 1.12.0/1.12.1 会为 1.11 版本的代理生成不正确的配置，影响授权策略中的 `hosts` 和 `notHosts` 字段。错误的配置可能会导致请求在使用 `hosts` 和 `notHosts` 字段时意外绕过或被授权策略拒绝。 当 1.12.0/1.12.1 控制平面和 1.11 数据平面混合使用，并在授权策略中使用 `hosts` 或 `notHosts` 字段时，会出现该问题。 -### 补救措施{#mitigation} +### 补救措施 {#mitigation} * 升级到最新的 1.12.2 或者； * 如果在授权策略中使用 `hosts` 或者 `notHosts` 字段，请勿将 1.12.0/1.12.1 控制平面和 1.11 数据平面混合使用。 -## 赞扬{#credit} +## 赞扬 {#credit} 我们要感谢 Yangmin Zhu 和 @Aakash2017。 diff --git a/content/zh/news/security/istio-security-2022-003/index.md b/content/zh/news/security/istio-security-2022-003/index.md index f7441f32fec5d..ea626aa71207e 100644 --- a/content/zh/news/security/istio-security-2022-003/index.md +++ b/content/zh/news/security/istio-security-2022-003/index.md @@ -13,9 +13,9 @@ skip_seealso: true {{< security_bulletin >}} -## CVE{#CVE} +## CVE -### CVE-2022-23635{#CVE-2022-23635} +### CVE-2022-23635 - __[CVE-2022-23635](https://github.com/istio/istio/security/advisories/GHSA-856q-xv3c-7f2f)__: (CVSS 评分 7.5，高): 控制平面不能拒绝未经身份验证的服务攻击。 @@ -26,7 +26,7 @@ Istio 控制平面 istiod 容易受到请求处理错误的影响，允许恶意 对于简单的安装，istiod 通常只能从集群内访问，从而限制了受影响的半径。但是，对于某些部署，尤其是[多集群拓扑](/zh/docs/setup/install/multicluster/primary-remote/)，该端口会通过公网公开。 -### Envoy CVEs{#envoy-cves} +### Envoy CVE {#envoy-cves} 目前，人们认为 Istio 不会受到 Envoy 中的这些 CVE 的攻击。然而，还是在下面把它们列出来了， 以让大家都了解。 @@ -43,10 +43,10 @@ Istio 控制平面 istiod 容易受到请求处理错误的影响，允许恶意 | [CVE-2022-21656](https://github.com/envoyproxy/envoy/security/advisories/GHSA-c9g7-xwcv-pjx2) | 3.1, 低 | X.509 `subjectAltName` 匹配（和 `nameConstraints`） 旁路。 | 是 | 是 | Envoy 没有向后移植此修复程序。 | | [CVE-2022-21657](https://github.com/envoyproxy/envoy/security/advisories/GHSA-837m-wjrv-vm5g) | 3.1, 低 | X.509 Extended Key Usage 和 Trust Purposes 旁路 | 不，下一个版本。 | 不，下一个版本。 | 不，下一个版本。 | -## 我受到影响了吗？{#am-i-impacted?} +## 我受到影响了吗？{#am-i-impacted} 如果您在多集群环境中运行 Istio，或者如果您已将 istiod 暴露在外部，那么您面临的风险最大。 -## 赞扬{#credit} +## 赞扬 {#credit} 我们要感谢 Adam Korczynski（[`ADA Logics`](https://adalogics.com)）和 John Howard（Google）的报告和修复。 diff --git a/content/zh/news/security/istio-security-2022-004/index.md b/content/zh/news/security/istio-security-2022-004/index.md index ea9c680328ace..7d6537b2c9200 100644 --- a/content/zh/news/security/istio-security-2022-004/index.md +++ b/content/zh/news/security/istio-security-2022-004/index.md @@ -13,9 +13,9 @@ skip_seealso: true {{< security_bulletin >}} -## CVE{#cve} +## CVE -### CVE-2022-24726{#cve-2022-24726} +### CVE-2022-24726 - __[CVE-2022-24726](https://github.com/istio/istio/security/advisories/GHSA-8w5h-qr4r-2h6g)__: (CVSS Score 7.5, High): 由于堆栈耗尽而导致控制平面不能拒绝未经身份验证的服务攻击。 @@ -26,7 +26,7 @@ Istio 控制平面 istiod 容易受到请求处理错误的影响，允许恶意 由于 Go 团队发布了 [CVE-2022-24921](https://github.com/advisories/GHSA-6685-ffxp-xm6f)，所以 Istio 认为这是一个零日漏洞。 -### Envoy CVEs{#envoy-cves} +### Envoy CVE {#envoy-cves} 以下的 Envoy CVE 也针对 Istio 1.11.8、1.12.5 和 Istio 1.13.2 进行了修复。它们已在 [https://github.com/envoyproxy/envoy](https://github.com/envoyproxy/envoy) 中公开修复，用于早先 Istio 版本中使用的 Envoy 版本。如 [ISTIO-SECURITY-2022-003](/zh/news/security/istio-security-2022-003) 中所述，Istio 不会受到 Envoy 中的这些 CVE 的攻击。 @@ -38,10 +38,10 @@ Istio 控制平面 istiod 容易受到请求处理错误的影响，允许恶意 - __[CVE-2022-21656](https://github.com/envoyproxy/envoy/security/advisories/GHSA-c9g7-xwcv-pjx2)__ (CVSS Score 3.1, Low): X.509 `subjectAltName` 匹配（和 `nameConstraints`） 旁路。 -## 我受到影响了吗？{#am-i-impacted?} +## 我受到影响了吗？ {#am-i-impacted} 如果您在外部 istiod 环境中运行 Istio，或者您已将 istiod 暴露在外部，那么您面临的风险最大。 -## 赞扬{#credit} +## 赞扬 {#credit} 我们要感谢来自谷歌的 John Howard 的报告和修复。 diff --git a/content/zh/news/security/istio-security-2022-005/index.md b/content/zh/news/security/istio-security-2022-005/index.md index 05dadbd820a1c..9b0c8c28f7856 100644 --- a/content/zh/news/security/istio-security-2022-005/index.md +++ b/content/zh/news/security/istio-security-2022-005/index.md @@ -13,13 +13,13 @@ skip_seealso: true {{< security_bulletin >}} -## CVE{#cve} +## CVE -### CVE-2022-31045{#cve-2022-31045} +### CVE-2022-31045 - [CVE-2022-31045](https://github.com/istio/istio/security/advisories/GHSA-xwx5-5c9g-x68x) (CVSS score 5.9, Medium): 内存访问冲突：在某些配置中，发送给 Envoy 的格式错误的请求头可能导致意外的内存访问错误，从而产生未定义的行为或崩溃。 -### Envoy CVEs{#envoy-cves} +### Envoy CVE {#envoy-cves} 这些 Envoy CVE 不会直接影响 Istio 功能，但我们仍会将它们包含在 1.12.8、1.13.5 和 1.14.1 的补丁版本中。 @@ -33,10 +33,10 @@ skip_seealso: true - [CVE-2022-29227](https://github.com/envoyproxy/envoy/security/advisories/GHSA-rm2p-qvf6-pvr6) (CVSS score 7.5, High): 如果重定向提示 Envoy-generated 的本地回复，则 Envoy 内部重定向带有正文或关键片段的请求是不安全的，攻击者利用该漏洞可以使服务崩溃。 -## 我受到影响了吗？{#am-i-impacted?} +## 我受到影响了吗？ {#am-i-impacted} 如果您有一个暴露于外部流量的 Istio 入口网关，那么您面临的风险最大。 -## 致谢{#credit} +## 致谢 {#credit} 我们要感谢 Red Hat 的 Otto van der Schaaf 的报告。 diff --git a/content/zh/news/security/istio-security-2023-001/index.md b/content/zh/news/security/istio-security-2023-001/index.md index 8ecbe0c536f24..7ea841cbec8d8 100644 --- a/content/zh/news/security/istio-security-2023-001/index.md +++ b/content/zh/news/security/istio-security-2023-001/index.md @@ -16,7 +16,7 @@ skip_seealso: true ## CVE -### Envoy CVEs{#envoy-cves} +### Envoy CVE {#envoy-cves} - __[CVE-2023-27487](https://github.com/envoyproxy/envoy/security/advisories/GHSA-5375-pq35-hf2g)__: (CVSS Score 8.2, High)：客户端可能会伪造 `x-envoy-original-path` 头信息。 @@ -36,6 +36,6 @@ skip_seealso: true - __[CVE-2023-27496](https://github.com/envoyproxy/envoy/security/advisories/GHSA-j79q-2g66-2xv5)__: (CVSS Score 6.5, Moderate)：在 OAuth 过滤器中收到没有 state 参数的重定向 URL 时导致崩溃。 -## 我受到影响了吗？{#am-i-impacted} +## 我受到影响了吗？ {#am-i-impacted} 如果您使用了 Istio Gateway 或者使用外部 istiod 可能面临风险。