mirror of https://github.com/istio/istio.io.git
Fix Chinese spelling errors (#2044)
* Chinese: about/contribute/github/index.md - translate working with GitHub - translate contributing to docs index * Chinese: add two indexes for policy and telemetry - add policy and telemetry index - add adapters index * modify translation * Fix Chinese spelling errors - enable Chinese spelling checks - fix spelling errors - refer to #2038
This commit is contained in:
Jimmy Song
Martin Taillefer
parent
0e5068f1b9
commit
0492530216
|
|
@ -76,7 +76,7 @@ page_icon: /img/feature-status.svg
|
|||
| [认证策略](/docs/concepts/security/#authentication-policies) | Alpha
|
||||
| [End User（JWT）认证](/docs/concepts/security/#authentication) | Alpha
|
||||
| [VM：服务凭证分发](/docs/concepts/security/#key-management) | Beta
|
||||
| [增量 mTLS](/docs/tasks/security/mtls-migration) | Beta
|
||||
| [增量双向 TLS](/docs/tasks/security/mtls-migration) | Beta
|
||||
| [OPA Checker]({{< github_file >}}/mixer/adapter/opa/README.md) | Alpha
|
||||
| [认证（RBAC）](/docs/concepts/security/#authorization) | Alpha
|
||||
|
||||
|
|
@ -105,4 +105,4 @@ page_icon: /img/feature-status.svg
|
|||
|
||||
> {{< idea_icon >}}
|
||||
>
|
||||
> 如果您希望未来的版本中具有某些功能，请加入[社区](/about/community/)与我们联系！
|
||||
> 如果您希望未来的版本中具有某些功能，请加入[社区](/about/community/)与我们联系！
|
||||
|
|
|
|||
|
|
@ -8,68 +8,68 @@ page_icon: /img/notes.svg
|
|||
|
||||
## General
|
||||
|
||||
- **更新了配置模型**。 Istio 在Kubernetes中运行时，使用 Kubernetes [自定义资源](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)模型来描述和存储其配置,现在可以使用 `kubectl` 命令选择性地管理配置。
|
||||
- **更新了配置模型**。Istio 在Kubernetes中运行时，使用 Kubernetes [自定义资源](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)模型来描述和存储其配置,现在可以使用 `kubectl` 命令选择性地管理配置。
|
||||
|
||||
- **多命名空间支持**。 Istio 控制平面组件现在位于专用的 "istio-system" 命名空间中, Istio 可以管理其他非系统命名空间中的服务。
|
||||
- **多命名空间支持**。Istio 控制平面组件现在位于专用的 "istio-system" 命名空间中, Istio 可以管理其他非系统命名空间中的服务。
|
||||
|
||||
- **网格扩展**。 初始支持将非 Kubernetes 服务（以 VM 和/或物理机的形式）添加到网格中,这是此功能的早期版本，并且存在一些限制（例如需要跨容器和 VM 的扁平网络）。
|
||||
- **网格扩展**。初始支持将非 Kubernetes 服务（以 VM 和/或物理机的形式）添加到网格中,这是此功能的早期版本，并且存在一些限制（例如需要跨容器和 VM 的扁平网络）。
|
||||
|
||||
- **多环境支持**。 最初支持将 Istio 与其他服务注册表结合使用，包括 Consul 和 Eureka。
|
||||
- **多环境支持**。最初支持将 Istio 与其他服务注册表结合使用，包括 Consul 和 Eureka。
|
||||
|
||||
- **自动注入 sidecar**。 使用 Kubernetes 中的[Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署时自动将 Istio sidecar 注入到Pod 中。
|
||||
- **自动注入 sidecar**。使用 Kubernetes 中的[Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署时自动将 Istio sidecar 注入到Pod 中。
|
||||
|
||||
## 性能和质量
|
||||
|
||||
整个系统中有许多性能和可靠性改进,我们还没有考虑将 Istio 0.2 用于生产，但我们在这个方向上取得了很好的进展,以下是一些注意事项：
|
||||
|
||||
- **客户端缓存**。 Envoy 使用的 Mixer 客户端库现在为 Check 调用和批处理 Report 调用提供缓存，大大减少了端到端开销。
|
||||
- **客户端缓存**。Envoy 使用的 Mixer 客户端库现在为 Check 调用和批处理 Report 调用提供缓存，大大减少了端到端开销。
|
||||
|
||||
- **避免热重启**。 通过有效使用 LDS/RDS/CDS/EDS，大部分消除了热重启 Envoy 的需要。
|
||||
- **避免热重启**。通过有效使用 LDS/RDS/CDS/EDS，大部分消除了热重启 Envoy 的需要。
|
||||
|
||||
- **减少内存使用**。 显着减小了 sidecar 的 helper agent的内存占用，从 50Mb 降低到 7Mb。
|
||||
- **减少内存使用**。显着减小了 sidecar 的 helper agent的内存占用，从 50Mb 降低到 7Mb。
|
||||
|
||||
- **改进的 Mixer 延迟**。 Mixer 现在可以清楚地描述配置时间与请求时间计算，从而避免在请求时为初始请求执行额外的设置工作，从而提供更平滑的平均延迟,更好的资源缓存也有助于提高端到端性能。
|
||||
- **改进的 Mixer 延迟**。Mixer 现在可以清楚地描述配置时间与请求时间计算，从而避免在请求时为初始请求执行额外的设置工作，从而提供更平滑的平均延迟,更好的资源缓存也有助于提高端到端性能。
|
||||
|
||||
- **减少出口流量的延迟**。 我们现在直接从 sidecar 转发到外部服务。
|
||||
- **减少出口流量的延迟**。我们现在直接从 sidecar 转发到外部服务。
|
||||
|
||||
## 流量管理
|
||||
|
||||
- **出口规则**。 现在可以为出口流量指定路由规则。
|
||||
- **出口规则**。现在可以为出口流量指定路由规则。
|
||||
|
||||
- **新协议**。 Mesh 范围内对 WebSocket 连接的支持，MongoDB 代理和 Kubernetes [Headless 服务](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)。
|
||||
- **新协议**。Mesh 范围内对 WebSocket 连接的支持，MongoDB 代理和 Kubernetes [Headless 服务](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)。
|
||||
|
||||
- **其他改进**。 Ingress 正确支持 gRPC 服务，更好地支持健康检查和 Jaeger 跟踪。
|
||||
- **其他改进**。Ingress 正确支持 gRPC 服务，更好地支持健康检查和 Jaeger 跟踪。
|
||||
|
||||
## 遥测和增强策略
|
||||
|
||||
- **入口策略**。 除了东西向流量支持 0.1 ,现在可以将策略应用于南北向流量。
|
||||
- **入口策略**。除了东西向流量支持 0.1 ,现在可以将策略应用于南北向流量。
|
||||
|
||||
- **支持TCP服务**。 除了 0.1 中提供的 HTTP 级策略控制之外，0.2 还引入了 TCP 服务的策略控制。
|
||||
- **支持TCP服务**。除了 0.1 中提供的 HTTP 级策略控制之外，0.2 还引入了 TCP 服务的策略控制。
|
||||
|
||||
- **新的Mixer API**。 Envoy 用于与 Mixer 交互的 API 已经过全面重新设计，以提高稳健性，灵活性，并支持丰富的代理端缓存和批处理以提高性能。
|
||||
- **新的Mixer API**。Envoy 用于与 Mixer 交互的 API 已经过全面重新设计，以提高稳健性，灵活性，并支持丰富的代理端缓存和批处理以提高性能。
|
||||
|
||||
- **新的 Mixer 适配器模型**。 新的适配器组合模型通过模板添加全新的适配器类，可以更轻松地扩展Mixer,这个新模型将成为未来许多功能的基础构建模块,请参阅[适配器开发人员指南](https://github.com/istio/istio/wiki/Mixer-Adapter-Dev-Guide)了解具体写适配器的方法。
|
||||
- **新的 Mixer 适配器模型**。新的适配器组合模型通过模板添加全新的适配器类，可以更轻松地扩展Mixer,这个新模型将成为未来许多功能的基础构建模块,请参阅[适配器开发人员指南](https://github.com/istio/istio/wiki/Mixer-Adapter-Dev-Guide)了解具体写适配器的方法。
|
||||
|
||||
- **改进的 Mixer 构建模型**。 现在，构建包含自定义适配器的 Mixer 二进制文件变得更加容易。
|
||||
- **改进的 Mixer 构建模型**。现在，构建包含自定义适配器的 Mixer 二进制文件变得更加容易。
|
||||
|
||||
- **Mixer 适配器更新**。 所有内置适配器都已重写，以适应新的适配器型号,已为此版本添加了 stackdriver 适配器,实验性 redis 配额适配器已在 0.2 版本中删除，但预计将在 0.3 版本中恢复生产质量。
|
||||
- **Mixer 适配器更新**。所有内置适配器都已重写，以适应新的适配器型号,已为此版本添加了 `stackdriver` 适配器,实验性 redis 配额适配器已在 0.2 版本中删除，但预计将在 0.3 版本中恢复生产质量。
|
||||
|
||||
- **Mixer 呼叫跟踪**。 现在可以在 Zipkin 仪表板中跟踪和分析 Envoy 和 Mixer 之间的调用。
|
||||
- **Mixer 呼叫跟踪**。现在可以在 Zipkin 仪表板中跟踪和分析 Envoy 和 Mixer 之间的调用。
|
||||
|
||||
## 安全
|
||||
|
||||
- **TCP 流量的双向 TLS**。 除 HTTP 流量外，TCP 流量现在也支持相互 TLS。
|
||||
- **TCP 流量的双向 TLS**。除 HTTP 流量外，TCP 流量现在也支持相互 TLS。
|
||||
|
||||
- **虚拟机和物理机的身份配置**。 Auth 支持使用每节点代理进行身份配置的新机制,此代理在每个节点（VM /物理机）上运行，并负责生成和发送 CSR（证书签名请求）以从 Istio CA 获取证书。
|
||||
- **虚拟机和物理机的身份配置**。`Auth` 支持使用每节点代理进行身份配置的新机制,此代理在每个节点（VM /物理机）上运行，并负责生成和发送 CSR（证书签名请求）以从 Istio CA 获取证书。
|
||||
|
||||
- **带上您自己的CA证书**。 允许用户为 Istio CA 提供自己的密钥和证书。
|
||||
- **带上您自己的CA证书**。允许用户为 Istio CA 提供自己的密钥和证书。
|
||||
|
||||
- **持久性CA密钥/证书存储**。 Istio CA 现在将签名密钥/证书存储在持久存储中以便于 CA 重新启动。
|
||||
- **持久性CA密钥/证书存储**。Istio CA 现在将签名密钥/证书存储在持久存储中以便于 CA 重新启动。
|
||||
|
||||
## 已知的问题
|
||||
|
||||
- **用户在访问应用程序时可能会获得定期404**: 我们注意到 Envoy 偶尔不会正确获取路由，因此 404 会返回给用户,我们正积极致力于[问题](https://github.com/istio/istio/issues/1038)。
|
||||
|
||||
- **在Pilot实际准备就绪之前，Istio Ingress 或 Egress 报告已准备就绪**: 您可以在 `istio-system` 命名空间中检查 istio-ingress 和 istio-egress pods 状态，并在所有 Istio pod 达到就绪状态后等待几秒钟,我们正积极致力于[问题](https://github.com/istio/istio/pull/1055)。
|
||||
- **在Pilot实际准备就绪之前，Istio Ingress 或 Egress 报告已准备就绪**：您可以在 `istio-system` 命名空间中检查 istio-ingress 和 istio-egress pods 状态，并在所有 Istio pod 达到就绪状态后等待几秒钟,我们正积极致力于[问题](https://github.com/istio/istio/pull/1055)。
|
||||
|
||||
- **启用了 Istio Auth 的服务无法与没有 Istio 的服务通信**: 此限制将在不久的将来删除。
|
||||
- **启用了 `Istio Auth` 的服务无法与没有 Istio 的服务通信**：此限制将在不久的将来删除。
|
||||
|
|
|
|||
|
|
@ -8,15 +8,15 @@ page_icon: /img/notes.svg
|
|||
|
||||
## 网络
|
||||
|
||||
- **Custom Envoy Config**：现在 Pilot 能够将自定义 Envoy 配置分发给 Sidecar。[参考资料](https://github.com/mandarjog/istioluawebhook)
|
||||
- **Custom Envoy Configuration**：现在 Pilot 能够将自定义 Envoy 配置分发给 proxy。[参考资料](https://github.com/mandarjog/istioluawebhook)
|
||||
|
||||
## Mixer 适配器
|
||||
|
||||
- **SolarWinds**：Mixer 和 AppOptics 以及 Papertrail 成功对接。[参考资料](/docs/reference/config/policy-and-telemetry/adapters/solarwinds/)
|
||||
- **SolarWinds**。 Mixer 和 AppOptics 以及 Papertrail 成功对接。[参考资料](/docs/reference/config/policy-and-telemetry/adapters/solarwinds/)
|
||||
|
||||
- **Redisquota**. Mixer 为速率限制功能提供了基于 Redis 的适配器。[参考资料](/docs/reference/config/policy-and-telemetry/adapters/redisquota/)
|
||||
- **Redis Quota**。 Mixer 为速率限制功能提供了基于 Redis 的适配器。[参考资料](/docs/reference/config/policy-and-telemetry/adapters/redisquota/)
|
||||
|
||||
- **Datadog**. Mixer 实现了向 Datadog 代理输出指标数据的适配器。[参考资料](/docs/reference/config/policy-and-telemetry/adapters/datadog/)
|
||||
- **Datadog**。Mixer 实现了向 Datadog 代理输出指标数据的适配器。[参考资料](/docs/reference/config/policy-and-telemetry/adapters/datadog/)
|
||||
|
||||
## 其它
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ spec:
|
|||
- bookinfo.com
|
||||
gateways:
|
||||
- bookinfo-gateway # <---- bind to gateway
|
||||
http:
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
prefix: /reviews
|
||||
|
|
@ -195,7 +195,7 @@ spec:
|
|||
route:
|
||||
- destination:
|
||||
host: ratings
|
||||
...
|
||||
...
|
||||
{{< /text >}}
|
||||
|
||||
实际上在 `VirtualService` 中 hosts 部分设置只是虚拟的目的地,因此不一定是已在网格中注册的服务。这允许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。 通过将 `VirtualService` 绑定到同一 Host 的 `Gateway` 配置（如前一节所述 ），可向网格外部暴露这些 Host。
|
||||
|
|
@ -259,15 +259,15 @@ metadata:
|
|||
spec:
|
||||
hosts:
|
||||
- foo.com
|
||||
ports:
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
{{< /text >}}
|
||||
|
||||
也就是说，`ServiceEntry` 比它的前身具有更多的功能。首先，`ServiceEntry` 不限于外部服务配置，它可以有两种类型：网格内部或网格外部。网格内部条目只是用于向网格显式添加服务，添加的服务与其他内部服务一样。采用网格内部条目，可以把原本未被网格管理的基础设施也纳入到网格中（例如，把虚机中的服务添加到基于 Kubernetes 的服务网格中）。网格外部条目则代表了网格外部的服务。对于这些外部服务来说，mTLS 身份验证是禁用的，并且策略是在客户端执行的，而不是在像内部服务请求一样在服务器端执行策略。
|
||||
也就是说，`ServiceEntry` 比它的前身具有更多的功能。首先，`ServiceEntry` 不限于外部服务配置，它可以有两种类型：网格内部或网格外部。网格内部条目只是用于向网格显式添加服务，添加的服务与其他内部服务一样。采用网格内部条目，可以把原本未被网格管理的基础设施也纳入到网格中（例如，把虚机中的服务添加到基于 Kubernetes 的服务网格中）。网格外部条目则代表了网格外部的服务。对于这些外部服务来说，双向 TLS 身份验证是禁用的，并且策略是在客户端执行的，而不是在像内部服务请求一样在服务器端执行策略。
|
||||
|
||||
由于 `ServiceEntry` 配置只是将服务添加到网格内部的服务注册表中，因此它可以像注册表中的任何其他服务一样,与 `VirtualService` 和/或 `DestinationRule` 一起使用。例如，以下 `DestinationRule` 可用于启动外部服务的 mTLS 连接：
|
||||
由于 `ServiceEntry` 配置只是将服务添加到网格内部的服务注册表中，因此它可以像注册表中的任何其他服务一样,与 `VirtualService` 和/或 `DestinationRule` 一起使用。例如，以下 `DestinationRule` 可用于启动外部服务的 双向 TLS 连接：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Fortio 是一个快速、小巧、可重复使用、可嵌入的 go 库以及命
|
|||
|
||||
Fortio 也是 100％ 开源的，除了 go 和 gRPC 之外没有外部依赖，因此您可以轻松地重现我们的所有结果并添加您自己想要探索的变量或场景。
|
||||
|
||||
下面是一个在 `istio-0.7.1` 上绘制的，在网格（使用 mTLS，Mixer 检查和遥测）中的两个服务间以 400 每秒查询率（qps）进行测试的示例场景结果（我们为每个版本运行的 8 个场景之一）的延迟分布图：
|
||||
下面是一个在 `istio-0.7.1` 上绘制的，在网格（使用双向 TLS、Mixer 检查和遥测）中的两个服务间以 400 每秒查询率（qps）进行测试的示例场景结果（我们为每个版本运行的 8 个场景之一）的延迟分布图：
|
||||
|
||||
<iframe src="https://fortio.istio.io/browse?url=qps_400-s1_to_s2-0.7.1-2018-04-05-22-06.json&xMax=105&yLog=true" width="100%" height="1024" scrolling="no" frameborder="0"></iframe>
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ Acmeair 基准测试应用程序可以在这里找到：[IBM's BluePerf](https:/
|
|||
|
||||
* 截至 0.7.1 版本，service-service（涉及 2 个代理，mixer telemetry 和检查）延迟消耗/开销约为 [10 毫秒](https://fortio.istio.io/browse?url=qps_400-s1_to_s2-0.7.1-2018-04-05-22-06.json)，我们希望将其降低到个位数毫秒级别。
|
||||
|
||||
* 在 CPU 和延迟方面，AES-NI 硬件支持的 mTLS 成本可以忽略不计。
|
||||
* 在 CPU 和延迟方面，AES-NI 硬件支持的双向 TLS 成本可以忽略不计。
|
||||
|
||||
我们计划为采用 Istio "点菜（A la carte）” 的客户提供更详细的指导。
|
||||
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ Istio 安全工作流由部署和运行两阶段组成。Kubernetes 和虚拟机
|
|||
|
||||
Istio 提供了两种认证方式：
|
||||
|
||||
* 传输认证，或者说服务间认证：校验发起连接的直接客户端。Istio 提供了双向 TLS（mTLS）作为传输认证的全栈解决方案。可以方便的在不变更服务代码的条件下启用这一功能，该方案：
|
||||
* 传输认证，或者说服务间认证：校验发起连接的直接客户端。Istio 提供了双向 TLS（`mTLS`）作为传输认证的全栈解决方案。可以方便的在不变更服务代码的条件下启用这一功能，该方案：
|
||||
|
||||
* 为每个服务提供强认证，认证身份和角色相结合，能够在不同的集群甚至不同云上进行互操作
|
||||
* 加密服务和服务之间、最终用户和服务之间的通信
|
||||
|
|
@ -145,20 +145,20 @@ Istio 提供了两种认证方式：
|
|||
|
||||
在 Istio 服务网格中处理请求的服务，可以使用认证策略来为其指定认证需求。网格运维人员使用 `.yaml` 文件来配置这些策略。这些策略一经上传，会被保存到 Istio 的配置存储中。作为 Istio 的控制器，Pilot 会对配置存储进行监控。任何的策略变化，Pilot 都会把新的策略翻译为对应的配置格式，并告知 Sidecar 代理如何应用所需的认证机制。另外，Pilot 提供了 Istio 管理的密钥和证书的路径，并把他们安装到应用 Pod 中以便进行双向 TLS 连接。可以在 [PKI 和认证](/docs/concepts/security/#identity)一节中找到更多相关信息。Istio 会将配置异步的发送给目标端点。Sidecar 收到配置之后，Pod 就会立即启用新的认证需求。
|
||||
|
||||
发送请求的客户端服务，要负责完成必要的认证机制。对于 JWT 认证来说，应用应该获取 JWT 凭据，并把凭据附加到请求上进行传播。Istio 提供了[目标规则](/docs/concepts/traffic-management/#destination-rules)用于应对 mTLS 认证。运维人员可以使用目标规则来要求客户端 Sidecar 使用 TLS 证书向服务器发起连接。[PKI 和认证](/docs/concepts/security/#identity)一节中介绍了更多 mTLS 的相关内容。
|
||||
发送请求的客户端服务，要负责完成必要的认证机制。对于 JWT 认证来说，应用应该获取 JWT 凭据，并把凭据附加到请求上进行传播。Istio 提供了[目标规则](/docs/concepts/traffic-management/#destination-rules)用于应对双向 TLS 认证。运维人员可以使用目标规则来要求客户端 Sidecar 使用 TLS 证书向服务器发起连接。[PKI 和认证](/docs/concepts/security/#identity)一节中介绍了更多双向 TLS 的相关内容。
|
||||
|
||||
{{< image width="80%" ratio="75%"
|
||||
link="/docs/concepts/security/authn.svg"
|
||||
caption="认证策略架构"
|
||||
>}}
|
||||
|
||||
这两种认证信息都会被 Istio 输出，如果有其他申明也会在凭据中一起输出到下一层：[鉴权](/docs/concepts/security/#authorization)，另外运维人员还可以在 mTLS 和最终用户两个甚至中选择一个提供给 Istio 用作认证主体（`principal`）。
|
||||
这两种认证信息都会被 Istio 输出，如果有其他申明也会在凭据中一起输出到下一层：[鉴权](/docs/concepts/security/#authorization)，另外运维人员还可以在双向 TLS 和最终用户两个甚至中选择一个提供给 Istio 用作认证主体（`principal`）。
|
||||
|
||||
### 认证策略
|
||||
|
||||
本节中提供了更多 Istio 认证策略方面的细节。正如[认证架构](/docs/concepts/security/#authentication-architecture)中所说的，认证策略是对服务收到的请求生效的。要在 mTLS 中指定客户端认证策略，需要在 `DetinationRule` 中设置 `TLSSettings`。[TLS 设置参考文档](/docs/reference/config/istio.networking.v1alpha3/#TLSSettings)中有更多这方面的信息。和其他的 Istio 配置一样，可以用 `.yaml` 文件的形式来编写认证策略，然后使用 `istioctl` 进行部署。
|
||||
本节中提供了更多 Istio 认证策略方面的细节。正如[认证架构](/docs/concepts/security/#authentication-architecture)中所说的，认证策略是对服务收到的请求生效的。要在双向 TLS 中指定客户端认证策略，需要在 `DetinationRule` 中设置 `TLSSettings`。[TLS 设置参考文档](/docs/reference/config/istio.networking.v1alpha3/#TLSSettings)中有更多这方面的信息。和其他的 Istio 配置一样，可以用 `.yaml` 文件的形式来编写认证策略，然后使用 `istioctl` 进行部署。
|
||||
|
||||
下面例子中的认证策略要求 `reviews` 服务必须使用 mTLS：
|
||||
下面例子中的认证策略要求 `reviews` 服务必须使用双向 TLS：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "authentication.istio.io/v1alpha1"
|
||||
|
|
@ -168,7 +168,7 @@ metadata:
|
|||
spec:
|
||||
targets:
|
||||
- name: reviews
|
||||
peers:
|
||||
peers:
|
||||
- mtls: {}
|
||||
{{< /text >}}
|
||||
|
||||
|
|
@ -234,16 +234,16 @@ Istio 为服务选择策略的时候，按照 **服务级 > 命名空间级 >
|
|||
|
||||
#### 传输认证
|
||||
|
||||
`peers` 一节为传输认证策略定义了认证方法及其相关参数。这一节中可以列出多个方法，其中的方法至少要有一个通过才能完成认证。然而在 0.7 版本中，唯一的传输认证方法就是 mTLS。如果无需传输认证，跳过这节即可。
|
||||
`peers` 一节为传输认证策略定义了认证方法及其相关参数。这一节中可以列出多个方法，其中的方法至少要有一个通过才能完成认证。然而在 0.7 版本中，唯一的传输认证方法就是双向 TLS。如果无需传输认证，跳过这节即可。
|
||||
|
||||
下面的代码段展示了使用 `peers` 启用基于 mTLS 进行传输认证的方法：
|
||||
下面的代码段展示了使用 `peers` 启用基于双向 TLS 进行传输认证的方法：
|
||||
|
||||
{{< text yaml >}}
|
||||
peers:
|
||||
- mtls: {}
|
||||
{{< /text >}}
|
||||
|
||||
目前 mTLS 的设置不需要任何参数，`-mtls: {}`、`- mtls` 或者 `- mtls: null` 都是等价的。未来 mTLS 设置可能会加入参数用来提供不同的 mTLS 支持。
|
||||
目前双向 TLS 的设置不需要任何参数，`-mtls: {}`、`- mtls` 或者 `- mtls: null` 都是等价的。未来 双向 TLS 设置可能会加入参数用来提供不同的双向 TLS 支持。
|
||||
|
||||
#### 最终用户认证
|
||||
|
||||
|
|
@ -272,7 +272,7 @@ principalBinding: USE_ORIGIN
|
|||
|
||||
可以再任何时间对认证策略进行修改，Istio 会用近乎实时的的效率把变更推送给端点。然而 Istio 无法保证所有端点能够同时收到新策略。下面提供一些建议，以避免更新认证策略造成的服务中断。
|
||||
|
||||
* mTLS 的启用和禁用：使用一个临时策略，其中的 `mode` 字段设置为 `PERISSIVE`。这个配置让服务同时接受 mTLS 和明文通信。这样就不会丢失请求。一旦所有客户端都完成协议转换之后，就可以将 `PERMISSIVE` 策略切换到期望值了。[双向 TLS 的迁移](/docs/tasks/security/mtls-migration)任务中介绍了更多这一方式的细节。
|
||||
* 双向 TLS 的启用和禁用：使用一个临时策略，其中的 `mode` 字段设置为 `PERISSIVE`。这个配置让服务同时接受 双向 TLS 和明文通信。这样就不会丢失请求。一旦所有客户端都完成协议转换之后，就可以将 `PERMISSIVE` 策略切换到期望值了。[双向 TLS 的迁移](/docs/tasks/security/mtls-migration)任务中介绍了更多这一方式的细节。
|
||||
|
||||
{{< text yaml >}}
|
||||
peers:
|
||||
|
|
@ -448,7 +448,7 @@ spec:
|
|||
- user: "istio-ingress-service-account"
|
||||
properties:
|
||||
- request.auth.claims[email]: "a@foo.com"
|
||||
roleRef:
|
||||
roleRef:
|
||||
kind: ServiceRole
|
||||
name: "products-viewer"
|
||||
{{< /text >}}
|
||||
|
|
@ -464,7 +464,7 @@ metadata:
|
|||
spec:
|
||||
subjects:
|
||||
- user: "*"
|
||||
roleRef:
|
||||
roleRef:
|
||||
kind: ServiceRole
|
||||
name: "products-viewer"
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -624,7 +624,7 @@ spec:
|
|||
|
||||
`ServiceEntry` 中使用 `hosts` 字段来指定目标，字段值可以是一个完全限定名，也可以是个通配符域名。其中包含的白名单，包含一或多个允许网格中服务访问的服务。
|
||||
|
||||
`ServiceEntry` 的配置不仅限于外部服务，他可以有两种类型：网格内部和网格外部。网格内的条目和其他的内部服务类似，用于显式的将服务加入网格。可以用来把服务作为服务网格扩展的一部分加入不受管理的基础设置（例如加入到基于 Kubernetes 的服务网格中的虚拟机）中。网格外的条目用于表达网格外的服务。对这种条目来说，mTLS 认证是禁止的，策略实现需要在客户端执行，而不像内部服务请求中的服务端执行。
|
||||
`ServiceEntry` 的配置不仅限于外部服务，他可以有两种类型：网格内部和网格外部。网格内的条目和其他的内部服务类似，用于显式的将服务加入网格。可以用来把服务作为服务网格扩展的一部分加入不受管理的基础设置（例如加入到基于 Kubernetes 的服务网格中的虚拟机）中。网格外的条目用于表达网格外的服务。对这种条目来说，双向 TLS 认证是禁止的，策略实现需要在客户端执行，而不像内部服务请求中的服务端执行。
|
||||
|
||||
只要 `ServiceEntry` 涉及到了匹配 `host` 的服务，就可以和 `VirtualService` 以及 `DestinationRule` 配合工作。例如下面的规则可以和上面的 `ServiceEntry` 同时使用，在访问 `bar.foo.com` 的外部服务时，设置一个 10 秒钟的超时。
|
||||
|
||||
|
|
|
|||
|
|
@ -11,10 +11,10 @@ aliases:
|
|||
|
||||
Bookinfo 应用分为四个单独的微服务：
|
||||
|
||||
* *productpage* ：`productpage` 微服务会调用 `details` 和 `reviews` 两个微服务，用来生成页面。
|
||||
* *details* ：这个微服务包含了书籍的信息。
|
||||
* *reviews* ：这个微服务包含了书籍相关的评论。它还会调用 `ratings` 微服务。
|
||||
* *ratings* ：`ratings` 微服务中包含了由书籍评价组成的评级信息。
|
||||
* `productpage` ：`productpage` 微服务会调用 `details` 和 `reviews` 两个微服务，用来生成页面。
|
||||
* `details` ：这个微服务包含了书籍的信息。
|
||||
* `reviews` ：这个微服务包含了书籍相关的评论。它还会调用 `ratings` 微服务。
|
||||
* `ratings` ：`ratings` 微服务中包含了由书籍评价组成的评级信息。
|
||||
|
||||
`reviews` 微服务有 3 个版本：
|
||||
|
||||
|
|
|
|||
|
|
@ -24,116 +24,116 @@ weight: 50
|
|||
|
||||
## 标签（Label）
|
||||
|
||||
* **报告者（Reporter）**：这是请求报告者的标识符。报告从服务端 Istio 代理而来时设置为 `server`，从客户端 Istio 代理而来时设置为 `client`。
|
||||
* **报告者（Reporter）**：这是请求报告者的标识符。报告从服务端 Istio 代理而来时设置为 `server`，从客户端 Istio 代理而来时设置为 `client`。
|
||||
|
||||
{{< text yaml >}}
|
||||
reporter: conditional((context.reporter.kind | "inbound") == "outbound", "client", "server")
|
||||
{{< /text >}}
|
||||
|
||||
* **源 Namespace（Source Namespace）**：标识了产生流量的源工作负载实例的 namespace。
|
||||
* **源 Namespace（Source Namespace）**：标识了产生流量的源工作负载实例的 namespace。
|
||||
|
||||
{{< text yaml >}}
|
||||
source_namespace: source.namespace | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **源工作负载（Source Workload）**：标识了控制源的源工作负载名称。
|
||||
* **源工作负载（Source Workload）**：标识了控制源的源工作负载名称。
|
||||
|
||||
{{< text yaml >}}
|
||||
source_workload: source.workload.name | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **源工作负载 Namespace（Source Workload Namespace）**：标志了源工作负载的 namespace。
|
||||
* **源工作负载 Namespace（Source Workload Namespace）**：标志了源工作负载的 namespace。
|
||||
|
||||
{{< text yaml >}}
|
||||
source_workload_namespace: source.workload.namespace | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **源主体（Source Principal）**：标识了流量来源的对等主体。在使用对等身份验证时设置。
|
||||
* **源主体（Source Principal）**：标识了流量来源的对等主体。在使用对等身份验证时设置。
|
||||
|
||||
{{< text yaml >}}
|
||||
source_principal: source.principal | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **源应用（Source App）**：标识了源应用（基于源工作负载的 `app` 标签）。
|
||||
* **源应用（Source App）**：标识了源应用（基于源工作负载的 `app` 标签）。
|
||||
|
||||
{{< text yaml >}}
|
||||
source_app: source.labels["app"] | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **源版本（Source Version）**：标识了源工作负载的版本。
|
||||
* **源版本（Source Version）**：标识了源工作负载的版本。
|
||||
|
||||
{{< text yaml >}}
|
||||
source_version: source.labels["version"] | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的 Namespace（Destination Namespace）**：标识了流量到达的目的工作负载实例的 namespace。
|
||||
* **目的 Namespace（Destination Namespace）**：标识了流量到达的目的工作负载实例的 namespace。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_namespace: destination.namespace | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的工作负载（Destination Workload）**：标识了目的工作负载的名称。
|
||||
* **目的工作负载（Destination Workload）**：标识了目的工作负载的名称。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_workload: destination.workload.name | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的工作负载 Namespace（Destination Workload Namespace）**：标识了目的工作负载的 namespace。
|
||||
* **目的工作负载 Namespace（Destination Workload Namespace）**：标识了目的工作负载的 namespace。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_workload_namespace: destination.workload.namespace | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的主体（Destination Principal）**: 标识了流量目的对等主体。当使用对等身份认证时设置。
|
||||
* **目的主体（Destination Principal）**: 标识了流量目的对等主体。当使用对等身份认证时设置。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_principal: destination.principal | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的应用（Destination App）**：标识了目的应用（基于目的工作负载的 `app` 标签）。
|
||||
* **目的应用（Destination App）**：标识了目的应用（基于目的工作负载的 `app` 标签）。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_app: destination.labels["app"] | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的版本（Destination Version）**：标识了目的工作负载的版本。
|
||||
* **目的版本（Destination Version）**：标识了目的工作负载的版本。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_version: destination.labels["version"] | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的 Service（Destination Service）**：标识了负责处理传入请求的目的 service。例如：`details.default.svc.cluster.local`。
|
||||
* **目的 Service（Destination Service）**：标识了负责处理传入请求的目的 service。例如：`details.default.svc.cluster.local`。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_service: destination.service.host | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的 Service 名称（Destination Service Name）**：标识了目的 service 的名称。例如："details"。
|
||||
* **目的 Service 名称（Destination Service Name）**：标识了目的 service 的名称。例如："details"。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_service_name: destination.service.name | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **目的 Service Namespace（Destination Service Namespace）**：标识了目的 service 的 namespace。
|
||||
* **目的 Service Namespace（Destination Service Namespace）**：标识了目的 service 的 namespace。
|
||||
|
||||
{{< text yaml >}}
|
||||
destination_service_namespace: destination.service.namespace | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **请求协议（Request Protocol）**：标识了请求协议。当提供了 API 协议时设置为该值，否则设置为请求或连接协议。
|
||||
* **请求协议（Request Protocol）**：标识了请求协议。当提供了 API 协议时设置为该值，否则设置为请求或连接协议。
|
||||
|
||||
{{< text yaml >}}
|
||||
request_protocol: api.protocol | context.protocol | "unknown"
|
||||
{{< /text >}}
|
||||
|
||||
* **响应码（Response Code）**:标识了请求的响应码。该 label 仅在 HTTP metrics 中存在。
|
||||
* **响应码（Response Code）**:标识了请求的响应码。该 label 仅在 HTTP metrics 中存在。
|
||||
|
||||
{{< text yaml >}}
|
||||
response_code: response.code | 200
|
||||
{{< /text >}}
|
||||
|
||||
* **连接 mTLS（Connection mTLS）**: 标识请求使用的 service 认证策略。当 Istio 使用身份认证保证通信安全时设置为 `true`。
|
||||
* **连接安全策略**：这标识了请求的服务身份验证策略。当 Istio 用于使通信安全并且报告来自目的地时，它被设置为 `mutual_tls`。报告来自源时设置为 `unknown`，因为无法正确填充安全策略。
|
||||
|
||||
{{< text yaml >}}
|
||||
connection_mtls: connection.mtls | false
|
||||
connection_security_policy: conditional((context.reporter.kind | "inbound") == "outbound", "unknown", conditional(connection.mtls | false, "mutual_tls", "none"))
|
||||
{{< /text >}}
|
||||
|
|
@ -98,7 +98,7 @@ istio-pilot-58c65f74bc-2f5xn 2/2 Running 0 1m
|
|||
|
||||
## 卸载
|
||||
|
||||
* 对于选项1，使用 kubectl 进行卸载：
|
||||
* 对于选项1，使用 `kubectl` 进行卸载：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete -f $HOME/istio.yaml
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ $ @install/tools/setupMeshEx.sh@ machineSetup VM_NAME
|
|||
$ curl 'http://10.60.1.4:8080/v1/registration/istio-pilot.istio-system.svc.cluster.local|http-discovery'
|
||||
{{< /text >}}
|
||||
|
||||
* 解开 Istio 的 Secret 对象，并复制到服务器上。包含 Citadel 的 Istio，即使没有启用自动的 mTLS 认证，也会生成 Istio secret（每个 Service account 都会生成 Secret，命名为 `istio.<serviceaccount>`）。这里建议进行这个操作，这样以后启用 mTLS 或者未来升级到缺省启用 mTLS 的版本会更加方便。
|
||||
* 解开 Istio 的 Secret 对象，并复制到服务器上。包含 Citadel 的 Istio，即使没有启用自动的 双向 TLS 认证，也会生成 Istio secret（每个 Service account 都会生成 Secret，命名为 `istio.<serviceaccount>`）。这里建议进行这个操作，这样以后启用 双向 TLS 或者未来升级到缺省启用 双向 TLS 的版本会更加方便。
|
||||
|
||||
`ACCOUNT` 缺省就是 `default`，或者 `SERVICE_ACCOUNT` 环境变量。
|
||||
`NAMESPACE` 缺省为当前命名空间，或者 `SERVICE_NAMESPACE` 环境变量（这一步骤通过 machineSetup 完成）在 Mac 上可使用 `brew install base64` 或者 `set BASE64_DECODE="/usr/bin/base64 -D"`。
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ $ kubectl label secret ${CLUSTER_NAME} istio/multiCluster=true -n istio-system
|
|||
|
||||
## 在每个远程集群上安装 Istio 远程组件
|
||||
|
||||
Istio-remote 组件必须在每个远程集群上分别部署。有两种安装方式：使用 Helm 结合 Tiller，或者用 Helm 配合 kubectl。
|
||||
Istio-remote 组件必须在每个远程集群上分别部署。有两种安装方式：使用 Helm 结合 Tiller，或者用 Helm 配合 `kubectl`。
|
||||
|
||||
### 从 Istio 控制平面设置 Istio 远程组件所需的 Pod IP 环境变量
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ $ export TELEMETRY_POD_IP=$(kubectl -n istio-system get pod -l istio-mixer-type=
|
|||
$ export ZIPKIN_POD_IP=$(kubectl -n istio-system get pod -l app=jaeger -o jsonpath='{.items[0].status.podIP}')
|
||||
{{< /text >}}
|
||||
|
||||
### 使用 Helm + kubectl 把远程集群连接到本地
|
||||
### 使用 Helm + `kubectl` 把远程集群连接到本地
|
||||
|
||||
1. 在远程集群上用 Helm template 命令来指定 Istio 控制平面的服务端点：
|
||||
|
||||
|
|
@ -199,15 +199,15 @@ $ export ZIPKIN_POD_IP=$(kubectl -n istio-system get pod -l app=jaeger -o jsonpa
|
|||
|
||||
| Helm 变量 | 可接受取值 | 缺省值 | 作用 |
|
||||
| --- | --- | --- | --- |
|
||||
| `global.pilotEndpoint` | 一个有效的 IP 地址 | istio-pilot.istio-system | 指定 Istio 控制平面中的 Pilot 的 Pod IP 地址 |
|
||||
| `global.policyEndpoint` | 一个有效的 IP 地址 | istio-policy.istio-system | 指定 Istio 控制平面中的 策略组件的 Pod IP 地址 |
|
||||
| `global.statsdEndpoint` | 一个有效的 IP 地址 | istio-statsd-prom-bridge.istio-system | 指定 Istio 控制平面中的 stats 的 Pod IP 地址 |
|
||||
| `global.pilotEndpoint` | 一个有效的 IP 地址 | `istio-pilot.istio-system` | 指定 Istio 控制平面中的 Pilot 的 Pod IP 地址 |
|
||||
| `global.policyEndpoint` | 一个有效的 IP 地址 | `istio-policy.istio-system` | 指定 Istio 控制平面中的 策略组件的 Pod IP 地址 |
|
||||
| `global.statsdEndpoint` | 一个有效的 IP 地址 | `istio-statsd-prom-bridge.istio-system` | 指定 Istio 控制平面中的 `stats` 的 Pod IP 地址 |
|
||||
|
||||
## 删除
|
||||
|
||||
> 删除方法必须和之前的安装方法一致（`Helm and kubectl` 或者 `Helm and Tiller`）
|
||||
|
||||
### 使用 kubectl 删除 istio-remote
|
||||
### 使用 `kubectl` 删除 istio-remote
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete -f $HOME/istio-remote.yaml
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ caption="GKE-IAM Role"
|
|||
|
||||
部署完成后，在你安装好的 `gcloud` 的工作站里，完成以下事项：
|
||||
|
||||
1. 为你刚刚创建的 cluster 引导 kubectl，并确认 cluster 在运行中，并且 Istio 是启用状态。
|
||||
1. 为你刚刚创建的 cluster 引导 `kubectl`，并确认 cluster 在运行中，并且 Istio 是启用状态。
|
||||
|
||||
{{< text bash >}}
|
||||
$ gcloud container clusters list
|
||||
|
|
@ -158,7 +158,7 @@ istio-ingressgateway LoadBalancer 10.59.251.109 35.194.26.85 80:31380/TC
|
|||
|
||||
当你验证了 Istio 控制平面和样例应用正常工作后，尝试访问一下已经安装好的 Istio 插件。
|
||||
|
||||
如果你使用 Cloud Shell 而不是已经安装好的 `gcloud` 客户端，你可以使用 [Web Preview](https://cloud.google.com/shell/docs/using-web-preview#previewing_the_application) 功能来进行端口转发和代理。比如，你要用 Cloud Shell 访问 Grafana，那你需要把 kubectl 的端口映射从 3000:3000 改成 8080:3000。你可以通过 Web Preview 代理的 8080 到 8084 这些端口，同时预览其他4个控制台。
|
||||
如果你使用 Cloud Shell 而不是已经安装好的 `gcloud` 客户端，你可以使用 [Web Preview](https://cloud.google.com/shell/docs/using-web-preview#previewing_the_application) 功能来进行端口转发和代理。比如，你要用 Cloud Shell 访问 Grafana，那你需要把 `kubectl` 的端口映射从 3000:3000 改成 8080:3000。你可以通过 Web Preview 代理的 8080 到 8084 这些端口，同时预览其他4个控制台。
|
||||
|
||||
### Grafana
|
||||
|
||||
|
|
@ -244,8 +244,8 @@ $ kubectl port-forward -n istio-system $(kubectl get pod -n istio-system -l app=
|
|||
|
||||
## 卸载
|
||||
|
||||
1. 在 [https://console.cloud.google.com/deployments](https://console.cloud.google.com/deployments) 找到 Cloud Console 的 Deployments 章节
|
||||
1. 在 [https://console.cloud.google.com/deployments](https://console.cloud.google.com/deployments) 找到 Cloud Console 的 Deployments 章节。
|
||||
|
||||
1. 选择 deployment 并点击 **Delete**.
|
||||
1. 选择 `deployment` 并点击 **Delete**。
|
||||
|
||||
1. Deployment Manager 将会删除所有已经部署的 GKE 组件。但是，有一些元素会被保留，比如 `Ingress` 和 `LoadBalancers`。你可以通过再次进入 cloud console 的 [**Network Services** -> **LoadBalancers**](https://console.cloud.google.com/net-services/loadbalancing/loadBalancers/list) 来删除这些组件。
|
||||
1. Deployment Manager 将会删除所有已经部署的 GKE 组件。但是，有一些元素会被保留，比如 `Ingress` 和 `LoadBalancers`。你可以通过再次进入 cloud console 的 [**Network Services** -> **Load balancing**](https://console.cloud.google.com/net-services/loadbalancing/loadBalancers/list) 来删除这些组件。
|
||||
|
|
|
|||
|
|
@ -5,17 +5,17 @@ weight: 10
|
|||
keywords: [kubernetes]
|
||||
---
|
||||
|
||||
本页面在kubernetes集群中快速安装Istio service mesh的说明。
|
||||
本页面在 Kubernetes 集群中快速安装 Istio service mesh 的说明。
|
||||
|
||||
## 前置条件
|
||||
|
||||
下面的操作说明需要您可以访问 kubernetes **1.9 或更高版本** 的集群，并且启用了 [RBAC (基于角色的访问控制)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。您需要安装了 **1.9 或更高版本** 的 `kubectl` 命令。
|
||||
下面的操作说明需要您可以访问 Kubernetes **1.9 或更高版本**的集群，并且启用了。[RBAC (基于角色的访问控制)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)。您需要安装了 **1.9 或更高版本**的 `kubectl` 命令。
|
||||
|
||||
如果您希望启用[自动注入 sidecar](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection)，您必须使用 kubernetes 1.9或更高版本。
|
||||
如果您希望启用[自动注入 sidecar](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection)，您必须使用 Kubernetes 1.9 或更高版本。
|
||||
|
||||
> 如果您安装的是 Istio 0.2.x，在安装新版本之前请将其完全[卸载](https://archive.istio.io/v0.2/docs/setup/kubernetes/quick-start#uninstalling)（包括所有启用了 Istio 的 Pod 中的sidecar）。
|
||||
|
||||
* 安装或更新 kubernetes 命令行工具 [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 以匹配集群的版本 （1.9 或者更高，支持 CRD 功能）
|
||||
* 安装或更新 Kubernetes 命令行工具 [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 以匹配集群的版本 （1.9 或者更高，支持 CRD 功能）
|
||||
|
||||
### Minikube
|
||||
|
||||
|
|
@ -230,7 +230,7 @@ $ kubectl describe pod --namespace kube-system $(kubectl get pods --namespace ku
|
|||
|
||||
1. 解压安装文件，切换到文件所在目录。安装文件目录下包含：
|
||||
|
||||
* `install/` 目录下是 kubernetes 使用的 `.yaml` 安装文件
|
||||
* `install/` 目录下是 Kubernetes 使用的 `.yaml` 安装文件
|
||||
* `samples/` 目录下是示例程序
|
||||
* `istioctl` 客户端二进制文件在 `bin` 目录下。`istioctl` 文件用户手动注入 Envoy sidecar 代理、创建路由和策略等
|
||||
* `istio.VERSION` 配置文件
|
||||
|
|
@ -252,7 +252,7 @@ $ kubectl describe pod --namespace kube-system $(kubectl get pods --namespace ku
|
|||
|
||||
安装 Istio 的核心部分。从以下四种_**非手动**_部署方式中选择一种方式安装。然而，我们推荐您在生产环境时使用 [Helm Chart](/docs/setup/kubernetes/helm-install/) 来安装 Istio，这样可以按需定制配置选项。
|
||||
|
||||
* 安装 Istio 而不启用 sidecar 之间的[双向TLS验证](/docs/concepts/security/#mutual-tls-authentication)。对于现有应用程序的集群，使用 Istio sidecar 的服务需要能够与其他非 Istio Kubernetes 服务以及使用[存活和就绪探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)、headless 服务或 `StatefulSets` 的应用程序通信的应用程序选择此选项。
|
||||
* 安装 Istio 而不启用 sidecar 之间的[双向 TLS 验证](/docs/concepts/security/#mutual-tls-authentication)。对于现有应用程序的集群，使用 Istio sidecar 的服务需要能够与其他非 Istio Kubernetes 服务以及使用[存活和就绪探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)、headless 服务或 `StatefulSets` 的应用程序通信的应用程序选择此选项。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f install/kubernetes/istio.yaml
|
||||
|
|
@ -260,7 +260,7 @@ $ kubectl apply -f install/kubernetes/istio.yaml
|
|||
|
||||
或者
|
||||
|
||||
* 默认情况下安装 Istio，并强制在 sidecar 之间进行双向 TLS 身份验证。仅在保证新部署的工作负载安装了 Istio sidecar 的新建的 kubernetes 集群上使用此选项。
|
||||
* 默认情况下安装 Istio，并强制在 sidecar 之间进行双向 TLS 身份验证。仅在保证新部署的工作负载安装了 Istio sidecar 的新建的 Kubernetes 集群上使用此选项。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f install/kubernetes/istio-demo-auth.yaml
|
||||
|
|
@ -268,7 +268,7 @@ $ kubectl apply -f install/kubernetes/istio-demo-auth.yaml
|
|||
|
||||
或者
|
||||
|
||||
* [使用 Helm 渲染出 Kubernetes 配置清单然后使用 kubectl 部署](/docs/setup/kubernetes/helm-install/#option-1-install-with-helm-via-helm-template)
|
||||
* [使用 Helm 渲染出 Kubernetes 配置清单然后使用 `kubectl` 部署](/docs/setup/kubernetes/helm-install/#option-1-install-with-helm-via-helm-template)
|
||||
|
||||
或者
|
||||
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ spec:
|
|||
- name: foo
|
||||
ports:
|
||||
- number: 8000
|
||||
peers:
|
||||
peers:
|
||||
---
|
||||
apiVersion: "networking.istio.io/v1alpha3"
|
||||
kind: "DestinationRule"
|
||||
|
|
@ -196,7 +196,7 @@ trafficPolicy:
|
|||
|
||||
## 将 `mtls_excluded_services` 配置迁移到目标规则
|
||||
|
||||
如果您在启用双向 TLS 的情况下安装了 Istio，并且使用网格配置 `mtls_excluded_services` 来在连接这些服务（例如 kubernetes API server）时禁用双向 TLS，则需要通过添加目标规则来替换它。例如：
|
||||
如果您在启用双向 TLS 的情况下安装了 Istio，并且使用网格配置 `mtls_excluded_services` 来在连接这些服务（例如 Kubernetes API server）时禁用双向 TLS，则需要通过添加目标规则来替换它。例如：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ keywords: [security,authentication,migration]
|
|||
No resources found.
|
||||
{{< /text >}}
|
||||
|
||||
## 配置服务器使其同时能接收 mTLS 以及明文流量
|
||||
## 配置服务器使其同时能接收双向 TLS 以及明文流量
|
||||
|
||||
在认证策略中有一个 `PERMISSIVE` 模式，这种模式让服务器能够同时接收明文和双向 TLS 流量。下面就把服务器设置为这种模式：
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sle
|
|||
|
||||
## 锁定使用双向 TLS (可选)
|
||||
|
||||
把所有进行过 sidecar 注入的客户端到服务器流量都迁移到 mTLS 之后，就可以设置 `httpbin.foo` 只支持双向 TLS 流量了。
|
||||
把所有进行过 sidecar 注入的客户端到服务器流量都迁移到双向 TLS 之后，就可以设置 `httpbin.foo` 只支持双向 TLS 流量了。
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF | istioctl create -n foo -f -
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ $ istioctl delete -f @samples/bookinfo/platform/kube/rbac/namespace-policy.yaml@
|
|||
|
||||
浏览器打开 Bookinfo 的 `productpage` (`http://$GATEWAY_URL/productpage`)。会看到：`RBAC: access denied`。我们会在 Bookinfo 中逐步为服务加入访问许可。
|
||||
|
||||
### 第一步，允许到 “productpage” 服务的访问
|
||||
### 第一步，允许到 `productpage` 服务的访问
|
||||
|
||||
这里我们要创建一条策略，允许外部请求通过 Ingress 浏览 `productpage`。
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ keywords: [telemetry,metrics]
|
|||
|
||||
## 查询 Istio 度量标准
|
||||
|
||||
1. 验证 prometheus 服务是否在您的群集中运行（从 0.8 开始， 默认情况下 prometheus 设置包含在 `istio.yaml` 和 `istio-demo-auth.yaml` 中）
|
||||
1. 验证 `prometheus` 服务是否在您的群集中运行（从 0.8 开始， 默认情况下 `prometheus` 设置包含在 `istio.yaml` 和 `istio-demo-auth.yaml` 中）
|
||||
|
||||
在 Kubernetes 环境中，执行以下命令：
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ Mixer 中内置了 Prometheus 适配器，这一适配器将生成的指标值
|
|||
|
||||
1. *istio-mesh* (`istio-mixer.istio-system:42422`): 所有 Mixer 生成的网格指标。
|
||||
1. *mixer* (`istio-mixer.istio-system:9093`): 所有特定于 Mixer 的指标, 用于监控 Mixer 本身。
|
||||
1. *envoy* (`istio-mixer.istio-system:9102`): envoy 生成的原始统计数据（并从 statsd 转换为 prometheus ）。
|
||||
1. *envoy* (`istio-mixer.istio-system:9102`): envoy 生成的原始统计数据（并从 `statsd` 转换为 `prometheus` ）。
|
||||
|
||||
有关查询 Prometheus 的更多信息，请阅读他们的[查询文档](https://prometheus.io/docs/querying/basics/)。
|
||||
|
||||
|
|
|
|||
|
|
@ -114,12 +114,12 @@ keywords: [traffic-management,routing]
|
|||
1. 在浏览器中打开 Bookinfo 应用程序的 URL (`http://$GATEWAY_URL/productpage`)。
|
||||
回想一下，在部署 Bookinfo 示例时，应已参照[该说明](/docs/examples/bookinfo/#determining-the-ingress-ip-and-port)设置好了 `GATEWAY_URL` 。
|
||||
|
||||
您应该可以看到 Bookinfo 应用程序的 productpage 页面。
|
||||
您应该可以看到 Bookinfo 应用程序的 `productpage` 页面。
|
||||
请注意， `productpage` 页面显示的内容中没有评分星级，这是为 `reviews:v1` 服务不会访问 ratings 服务。
|
||||
|
||||
1. 将来自特定用户的请求路由到 `reviews:v2`。
|
||||
|
||||
通过将来自 productpage 的流量路由到 `reviews:v2` 实例，为测试用户 "jason” 启用 ratings 服务。
|
||||
通过将来自 `productpage` 的流量路由到 `reviews:v2` 实例，为测试用户 "jason” 启用 ratings 服务。
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
|
||||
|
|
@ -158,7 +158,7 @@ keywords: [traffic-management,routing]
|
|||
|
||||
## 理解原理
|
||||
|
||||
在此任务中，您首先使用 Istio 将 100% 的请求流量都路由到了 Bookinfo 服务的 v1 版本。 然后再设置了一条路由规则，该路由规则在 productpage 服务中添加基于请求的 "end-user" 自定义 header 选择性地将特定的流量路由到了 reviews 服务的 v2 版本。
|
||||
在此任务中，您首先使用 Istio 将 100% 的请求流量都路由到了 Bookinfo 服务的 v1 版本。 然后再设置了一条路由规则，该路由规则在 `productpage` 服务中添加基于请求的 "end-user" 自定义 header 选择性地将特定的流量路由到了 reviews 服务的 v2 版本。
|
||||
|
||||
请注意，为了利用 Istio 的 L7 路由功能，Kubernetes 中的服务（如本任务中使用的 Bookinfo 服务）必须遵守某些特定限制。
|
||||
参考 [sidecar 注入文档](/docs/setup/kubernetes/spec-requirements)了解详情。
|
||||
|
|
@ -173,4 +173,4 @@ keywords: [traffic-management,routing]
|
|||
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
1. 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/docs/examples/bookinfo/#cleanup) 的说明关闭应用程序。
|
||||
1. 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/docs/examples/bookinfo/#cleanup) 的说明关闭应用程序。
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ keywords: [debug,proxy,status,config,pilot,envoy]
|
|||
|
||||
## 开始之前
|
||||
|
||||
* 部署 Istio 和 Bookinfo 的 Kubernetes 集群（例如，如[安装步骤](/docs/setup/kubernetes/quick-start/#installation-steps)和 [bookinfo 安装步骤](/docs/examples/bookinfo/#if-you-are-running-on-kubernetes)中所述使用 `istio.yaml` 安装)。
|
||||
* 部署 Istio 和 Bookinfo 的 Kubernetes 集群（例如，如[安装步骤](/docs/setup/kubernetes/quick-start/#installation-steps)和 [Bookinfo 安装步骤](/docs/examples/bookinfo/#if-you-are-running-on-kubernetes)中所述使用 `istio.yaml` 安装)。
|
||||
|
||||
或者
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ istio-egressgateway.istio-system.svc.cluster.local
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
为了调试 Envoy，您需要了解 Envoy 集群/监听器/路由/端点以及它们之间如何进行交互。我们将使用带有 `-o json` 和过滤标志的 `proxy-config` 命令来跟踪 Envoy 以确定将请求从 productpage pod 发送到了 `reviews:9080` 的 reviews pod 上。
|
||||
为了调试 Envoy，您需要了解 Envoy 集群/监听器/路由/端点以及它们之间如何进行交互。我们将使用带有 `-o json` 和过滤标志的 `proxy-config` 命令来跟踪 Envoy 以确定将请求从 `productpage` pod 发送到了 `reviews:9080` 的 reviews pod 上。
|
||||
|
||||
1. 如果您在 pod 上查询监听器摘要，您会注意到 Istio 会生成以下监听器：
|
||||
* `0.0.0.0:15001` 上的监听器接收进出 pod 的所有流量，然后将请求移交给虚拟监听器。
|
||||
|
|
@ -271,4 +271,4 @@ $ istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-7d6874b48
|
|||
"buildVersion": "0/1.8.0-dev//RELEASE"
|
||||
},
|
||||
...
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ check_content() {
|
|||
}
|
||||
|
||||
check_content content --en-us
|
||||
#check_content content_zh --zh-cn
|
||||
check_content content_zh --zh-cn
|
||||
|
||||
grep -nr -e "ERROR: markdown" ./public
|
||||
if [ "$?" == "0" ]
|
||||
|
|
|
|||
Loading…
Reference in New Issue