From d6e6e65271e19e8cebf76113ed8064a03a01fe45 Mon Sep 17 00:00:00 2001 From: 2BFL Date: Tue, 10 Mar 2020 13:29:30 +0800 Subject: [PATCH] fmt for zh content (#6816) --- content/zh/about/bugs/index.md | 6 ++-- content/zh/about/community/join/index.md | 2 +- .../zh/about/contribute/add-content/index.md | 8 ++--- .../zh/about/contribute/code-blocks/index.md | 8 ++--- content/zh/about/contribute/diagrams/index.md | 6 ++-- content/zh/about/contribute/github/index.md | 10 +++--- content/zh/about/contribute/review/index.md | 6 ++-- .../zh/about/contribute/style-guide/index.md | 2 +- content/zh/about/media-resources/index.md | 2 +- content/zh/about/release-cadence/index.md | 2 +- content/zh/blog/2017/0.1-auth/index.md | 4 +-- content/zh/blog/2017/0.1-canary/index.md | 14 ++++---- .../2017/0.1-using-network-policy/index.md | 8 ++--- content/zh/blog/2017/adapter-model/index.md | 6 ++-- content/zh/blog/2018/aws-nlb/index.md | 8 ++--- .../zh/blog/2018/delayering-istio/index.md | 2 +- content/zh/blog/2018/egress-https/index.md | 18 +++++----- content/zh/blog/2018/egress-mongo/index.md | 12 +++---- .../egress-monitoring-access-control/index.md | 20 +++++------ content/zh/blog/2018/egress-tcp/index.md | 8 ++--- .../export-logs-through-stackdriver/index.md | 24 ++++++------- .../zh/blog/2018/istio-authorization/index.md | 12 +++---- .../zh/blog/2018/istio-twitch-stream/index.md | 6 ++-- .../zh/blog/2018/soft-multitenancy/index.md | 4 +-- .../zh/blog/2018/traffic-mirroring/index.md | 2 +- .../zh/blog/2018/v1alpha3-routing/index.md | 22 ++++++------ .../2019/announcing-istio-client-go/index.md | 6 ++-- .../app-identity-and-access-adapter/index.md | 2 +- content/zh/blog/2019/appswitch/index.md | 8 ++--- .../blog/2019/custom-ingress-gateway/index.md | 8 ++--- .../zh/blog/2019/data-plane-setup/index.md | 8 ++--- .../zh/blog/2019/egress-performance/index.md | 4 +-- .../index.md | 6 ++-- .../index.md | 4 +-- .../index.md | 2 +- .../blog/2019/evolving-istios-apis/index.md | 6 ++-- .../2019/introducing-istio-operator/index.md | 6 ++-- .../zh/blog/2019/isolated-clusters/index.md | 4 +-- .../index.md | 8 ++--- .../multicluster-version-routing/index.md | 10 +++--- .../2019/performance-best-practices/index.md | 18 +++++----- .../zh/blog/2019/trustworthy-jwt-sds/index.md | 2 +- .../multi-cluster-mesh-automation/index.md | 4 +-- content/zh/blog/2020/tradewinds-2020/index.md | 6 ++-- .../boilerplates/before-you-begin-egress.md | 2 +- .../experimental-feature-warning.md | 2 +- .../zh/boilerplates/helm-security-warning.md | 2 +- content/zh/boilerplates/index.md | 2 +- content/zh/boilerplates/trace-generation.md | 4 +-- content/zh/docs/_index.md | 2 +- .../zh/docs/concepts/observability/index.md | 2 +- content/zh/docs/concepts/policies/index.md | 2 +- content/zh/docs/concepts/security/index.md | 8 ++--- .../docs/concepts/traffic-management/index.md | 6 ++-- content/zh/docs/examples/bookinfo/index.md | 2 +- .../microservices-istio/single/index.md | 2 +- .../virtual-machines/bookinfo/index.md | 2 +- .../virtual-machines/multi-network/index.md | 4 +-- .../virtual-machines/single-network/index.md | 10 +++--- .../traffic-management/index.md | 2 +- .../common-problems/network-issues/index.md | 4 +-- .../observability-issues/index.md | 4 +-- .../common-problems/security-issues/index.md | 2 +- .../ops/common-problems/validation/index.md | 4 +-- .../mesh/app-health-check/index.md | 8 ++--- .../mesh/injection-concepts/index.md | 2 +- .../ops/configuration/mesh/webhook/index.md | 4 +-- .../security/harden-docker-images/index.md | 2 +- .../telemetry/envoy-stats/index.md | 4 +-- .../in-proxy-service-telemetry/index.md | 4 +-- content/zh/docs/ops/deployment/_index.md | 2 +- .../performance-and-scalability/index.md | 4 +-- .../docs/ops/deployment/requirements/index.md | 4 +-- .../component-logging/index.md | 2 +- .../istioctl-analyze/index.md | 8 ++--- .../istioctl-describe/index.md | 2 +- .../ops/diagnostic-tools/istioctl/index.md | 4 +-- .../ops/diagnostic-tools/proxy-cmd/index.md | 2 +- .../docs/reference/config/analysis/_index.md | 2 +- .../config/analysis/ist0113/index.md | 2 +- .../config/analysis/ist0118/index.md | 2 +- .../config/analysis/message-format/index.md | 2 +- .../config/installation-options/index.md | 18 +++++----- .../policy-and-telemetry/adapters/_index.md | 2 +- .../expression-language/index.md | 4 +-- .../policy-and-telemetry/metrics/index.md | 4 +-- .../mixer-overview/index.md | 14 ++++---- .../constraints-and-properties/index.md | 2 +- .../zh/docs/reference/glossary/attribute.md | 2 +- .../zh/docs/reference/glossary/identity.md | 2 +- .../glossary/managed-control-plane.md | 2 +- .../reference/glossary/mesh-federation.md | 2 +- .../zh/docs/reference/glossary/multi-mesh.md | 2 +- .../docs/reference/glossary/multicluster.md | 2 +- content/zh/docs/reference/glossary/pod.md | 2 +- .../docs/reference/glossary/routing-rules.md | 2 +- .../reference/glossary/service-endpoint.md | 2 +- .../reference/glossary/service-producer.md | 2 +- .../reference/glossary/service-version.md | 2 +- content/zh/docs/reference/glossary/service.md | 4 +-- .../reference/glossary/workload-instance.md | 2 +- .../additional-setup/config-profiles/index.md | 2 +- .../zh/docs/setup/getting-started/index.md | 10 +++--- content/zh/docs/setup/install/helm/index.md | 20 +++++------ .../zh/docs/setup/install/istioctl/index.md | 12 +++---- .../install/multicluster/gateways/index.md | 6 ++-- .../multicluster/shared-gateways/index.md | 6 ++-- .../install/multicluster/shared-vpn/index.md | 2 +- .../install/multicluster/simplified/index.md | 4 +-- .../setup/platform-setup/MicroK8s/index.md | 2 +- .../docs/setup/platform-setup/azure/index.md | 6 ++-- .../docs/setup/platform-setup/docker/index.md | 2 +- .../setup/platform-setup/gardener/index.md | 2 +- .../zh/docs/setup/platform-setup/gke/index.md | 2 +- .../setup/platform-setup/minikube/index.md | 2 +- .../zh/docs/setup/platform-setup/oci/index.md | 2 +- .../setup/upgrade/cni-helm-upgrade/index.md | 2 +- .../setup/upgrade/istioctl-upgrade/index.md | 6 ++-- .../distributed-tracing/jaeger/index.md | 4 +-- .../distributed-tracing/lightstep/index.md | 4 +-- .../distributed-tracing/overview/index.md | 10 +++--- .../distributed-tracing/zipkin/index.md | 8 ++--- .../docs/tasks/observability/kiali/index.md | 4 +-- .../observability/logs/access-log/index.md | 4 +-- .../tasks/observability/logs/fluentd/index.md | 2 +- .../metrics/collecting-metrics/index.md | 2 +- .../metrics/querying-metrics/index.md | 2 +- .../metrics/using-istio-dashboard/index.md | 4 +-- .../control-headers/index.md | 8 ++--- .../denial-and-list/index.md | 2 +- .../policy-enforcement/rate-limiting/index.md | 2 +- .../tasks/security/authentication/_index.md | 2 +- .../authentication/authn-policy/index.md | 20 +++++------ .../authentication/auto-mtls/index.md | 6 ++-- .../authentication/mtls-migration/index.md | 4 +-- .../authentication/mutual-tls/index.md | 8 ++--- .../authorization/authz-http/index.md | 2 +- .../authorization/rbac-groups/index.md | 2 +- .../security/citadel-config/auth-sds/index.md | 10 +++--- .../citadel-config/plugin-ca-cert/index.md | 4 +-- .../zh/docs/tasks/security/webhook/index.md | 4 +-- .../circuit-breaking/index.md | 8 ++--- .../egress/egress-control/index.md | 14 ++++---- .../egress-gateway-tls-origination/index.md | 8 ++--- .../egress-kubernetes-services/index.md | 4 +-- .../index.md | 12 +++---- .../egress/wildcard-egress-hosts/index.md | 4 +-- .../fault-injection/index.md | 4 +-- .../ingress/ingress-control/index.md | 14 ++++---- .../ingress/ingress-sni-passthrough/index.md | 2 +- .../ingress/secure-ingress-mount/index.md | 2 +- .../ingress/secure-ingress-sds/index.md | 6 ++-- .../traffic-management/mirroring/index.md | 4 +-- .../request-routing/index.md | 2 +- .../request-timeouts/index.md | 2 +- .../tcp-traffic-shifting/index.md | 2 +- .../zh/events/banners/kubecon-america-2019.md | 2 +- .../zh/events/banners/kubecon-europe-2020.md | 2 +- content/zh/events/banners/latest-release.md | 2 +- content/zh/events/index.md | 2 +- content/zh/faq/_index.md | 2 +- content/zh/faq/applications/cassandra.md | 2 +- .../distributed-tracing/disabling-tracing.md | 2 +- .../how-distributed-tracing-works.md | 2 +- .../how-envoy-based-tracing-works.md | 2 +- .../how-mixer-based-tracing-works.md | 2 +- .../distributed-tracing/istio-copy-headers.md | 2 +- .../minimal-requirements.md | 2 +- .../zh/faq/general/how-do-i-get-started.md | 4 +-- content/zh/faq/general/istio-doesnt-work.md | 2 +- content/zh/faq/general/roadmap.md | 2 +- .../zh/faq/general/what-does-istio-mean.md | 2 +- content/zh/faq/general/what-is-istio.md | 2 +- content/zh/faq/mixer/header-rules.md | 4 +-- .../security/accessing-non-istio-services.md | 2 +- content/zh/faq/security/auth-mix-and-match.md | 2 +- content/zh/faq/security/k8s-health-checks.md | 2 +- content/zh/faq/security/mysql-with-mtls.md | 2 +- content/zh/faq/security/secret-encryption.md | 4 +-- content/zh/faq/security/use-k8s-secrets.md | 6 ++-- .../news/releases/0.x/announcing-0.1/index.md | 8 ++--- .../news/releases/0.x/announcing-0.2/index.md | 24 ++++++------- .../news/releases/0.x/announcing-0.4/index.md | 2 +- .../news/releases/0.x/announcing-0.5/index.md | 2 +- .../releases/1.0.x/announcing-1.0.1/index.md | 4 +-- .../releases/1.0.x/announcing-1.0.3/index.md | 4 +-- .../releases/1.0.x/announcing-1.0/index.md | 34 +++++++++---------- .../releases/1.1.x/announcing-1.1.16/index.md | 2 +- .../releases/1.1.x/announcing-1.1.17/index.md | 2 +- .../releases/1.1.x/announcing-1.1.4/index.md | 2 +- .../releases/1.1.x/announcing-1.1/_index.md | 6 ++-- .../announcing-1.1/change-notes/index.md | 8 ++--- .../announcing-1.1/helm-changes/index.md | 2 +- .../announcing-1.1/upgrade-notes/index.md | 4 +-- .../releases/1.2.x/announcing-1.2.10/index.md | 2 +- .../releases/1.2.x/announcing-1.2.3/index.md | 2 +- .../releases/1.2.x/announcing-1.2.7/index.md | 2 +- .../releases/1.2.x/announcing-1.2.8/index.md | 2 +- .../announcing-1.2/change-notes/index.md | 12 +++---- .../releases/1.3.x/announcing-1.3.2/index.md | 2 +- .../releases/1.3.x/announcing-1.3.6/index.md | 2 +- .../releases/1.3.x/announcing-1.3.8/index.md | 2 +- .../releases/1.3.x/announcing-1.3/_index.md | 4 +-- .../announcing-1.3/change-notes/index.md | 8 ++--- .../announcing-1.3/helm-changes/index.md | 4 +-- .../announcing-1.3/upgrade-notes/index.md | 2 +- .../releases/1.4.x/announcing-1.4.1/index.md | 2 +- .../releases/1.4.x/announcing-1.4.2/index.md | 2 +- .../releases/1.4.x/announcing-1.4.4/index.md | 2 +- .../releases/1.4.x/announcing-1.4/_index.md | 2 +- .../announcing-1.4/change-notes/index.md | 2 +- .../announcing-1.4/upgrade-notes/index.md | 4 +-- .../incorrect-sidecar-image-1.2.4/index.md | 2 +- .../security/istio-security-2019-002/index.md | 2 +- .../security/istio-security-2019-003/index.md | 2 +- .../security/istio-security-2019-004/index.md | 8 ++--- .../security/istio-security-2019-005/index.md | 6 ++-- .../security/istio-security-2019-006/index.md | 2 +- .../security/istio-security-2020-002/index.md | 2 +- .../support/announcing-1.0-eol-final/index.md | 2 +- .../news/support/announcing-1.0-eol/index.md | 4 +-- .../support/announcing-1.1-eol-final/index.md | 4 +-- .../news/support/announcing-1.1-eol/index.md | 2 +- .../support/announcing-1.2-eol-final/index.md | 6 ++-- .../news/support/announcing-1.2-eol/index.md | 2 +- .../support/announcing-1.3-eol-final/index.md | 2 +- .../news/support/announcing-1.3-eol/index.md | 2 +- 227 files changed, 548 insertions(+), 548 deletions(-) diff --git a/content/zh/about/bugs/index.md b/content/zh/about/bugs/index.md index ab945380da..ef06f39d84 100644 --- a/content/zh/about/bugs/index.md +++ b/content/zh/about/bugs/index.md @@ -13,9 +13,9 @@ icon: bugs ## 产品错误{#product-bugs} -搜索我们的 [问题数据库](https://github.com/istio/istio/issues/) 来查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中没有找到你的问题，请打开一个 [新问题](https://github.com/istio/istio/issues/new/choose) 让我们知道出现了什么错误。 +搜索我们的[问题数据库](https://github.com/istio/istio/issues/)来查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中没有找到你的问题，请打开一个[新问题](https://github.com/istio/istio/issues/new/choose)让我们知道出现了什么错误。 -如果您认为错误实际上是一个安全漏洞，请访问 [报告安全漏洞](/zh/about/security-vulnerabilities/) 了解如何处理。 +如果您认为错误实际上是一个安全漏洞，请访问[报告安全漏洞](/zh/about/security-vulnerabilities/)了解如何处理。 ### Kubernetes 集群状态档案{#Kubernetes-cluster-state-archives} @@ -81,4 +81,4 @@ icon: bugs ## 文档错误{#documentation-bugs} -搜索我们的 [文档问题数据库](https://github.com/istio/istio.io/issues/) 以查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中找不到问题，请导航到这个问题的页面，然后在页面的右上角选择齿轮菜单，最后选择 *Report a Site Bug*。 +搜索我们的[文档问题数据库](https://github.com/istio/istio.io/issues/)以查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中找不到问题，请导航到这个问题的页面，然后在页面的右上角选择齿轮菜单，最后选择 *Report a Site Bug*。 diff --git a/content/zh/about/community/join/index.md b/content/zh/about/community/join/index.md index 15184010c2..8de805ad87 100644 --- a/content/zh/about/community/join/index.md +++ b/content/zh/about/community/join/index.md @@ -19,7 +19,7 @@ Istio 是一个开源项目，拥有一个支持其使用和持续开发的活 {{< community_item logo="./slack.svg" alt="Slack" >}} 如果您想与我们的社区成员进行实时互动，可以加入 [Istio 的 Slack](https://istio.slack.com) 工作区。 -填写 [这个表格](https://docs.google.com/forms/d/e/1FAIpQLSfdsupDfOWBtNVvVvXED6ULxtR4UIsYGCH_cQcRr0VcG1ZqQQ/viewform) +填写[这个表格](https://docs.google.com/forms/d/e/1FAIpQLSfdsupDfOWBtNVvVvXED6ULxtR4UIsYGCH_cQcRr0VcG1ZqQQ/viewform) 加入我们。 {{< /community_item >}} diff --git a/content/zh/about/contribute/add-content/index.md b/content/zh/about/contribute/add-content/index.md index a8464c80ae..4a23b49858 100644 --- a/content/zh/about/contribute/add-content/index.md +++ b/content/zh/about/contribute/add-content/index.md @@ -38,7 +38,7 @@ keywords: [contribute] 要避免的最重要也是最常见的错误，是简单地向读者提供您拥有的所有信息，因为您不确定他们需要什么信息。 -如果您需要帮助特定内容的受众，我们很乐意在 [文档工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md#istio-working-groups) 每两周一次的会议上帮助您并回答您的所有问题。 +如果您需要帮助特定内容的受众，我们很乐意在[文档工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md#istio-working-groups)每两周一次的会议上帮助您并回答您的所有问题。 ## 内容类型{#content-types} @@ -87,7 +87,7 @@ keywords: [contribute] 着重于完成 Istio 部署所需的安装步骤。安装页面必须包括自动测试，因为它们已经过测试和维护以确保技术准确性。 - 想要完成部署的新旧Istio用户。 + 想要完成部署的新旧 Istio 用户。 博客文章 @@ -133,7 +133,7 @@ keywords: [contribute] ## 将您的贡献提交到 GitHub{#submit-your-contribution-to-GitHub} -如果您不熟悉GitHub，请参阅 [使用 GitHub 参与社区活动](/zh/about/contribute/github)，以了解如何提交文档更改。 +如果您不熟悉 GitHub，请参阅[使用 GitHub 参与社区活动](/zh/about/contribute/github)，以了解如何提交文档更改。 -如果您想了解有关发表文稿的方式和时间的更多信息，请参阅 [分支策略](/zh/about/contribute/github#branching-strategy)， +如果您想了解有关发表文稿的方式和时间的更多信息，请参阅[分支策略](/zh/about/contribute/github#branching-strategy)， 以了解我们如何使用分支和 `cherry picking` 来发布我们的内容。 diff --git a/content/zh/about/contribute/code-blocks/index.md b/content/zh/about/contribute/code-blocks/index.md index 66e7dcdbfc..d319b75319 100644 --- a/content/zh/about/contribute/code-blocks/index.md +++ b/content/zh/about/contribute/code-blocks/index.md @@ -206,7 +206,7 @@ The file has three separate snippets: `SNIP1`, `SNIP2`, and `SNIP3`. The convent ## 链接 GitHub 上的文件{#link-2-files} -有些代码块需要引用 [Istio 的 GitHub 仓库](https://github.com/istio/istio) 中的文件。其中最常见的情况就是引用 YAML 配置文件。无需将 YAML 文件的全部内容复制到您的代码块中，您可以使用 `@` 符号将文件的相对路径名括起来。此标记会将路径渲染为指向 GitHub 中当前发行版本分支的文件的链接，例如： +有些代码块需要引用 [Istio 的 GitHub 仓库](https://github.com/istio/istio)中的文件。其中最常见的情况就是引用 YAML 配置文件。无需将 YAML 文件的全部内容复制到您的代码块中，您可以使用 `@` 符号将文件的相对路径名括起来。此标记会将路径渲染为指向 GitHub 中当前发行版本分支的文件的链接，例如： {{< text markdown >}} {{}} @@ -265,8 +265,8 @@ $ kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer |`url` | 在代码块中显示的文档的 URL。 |`syntax` | 代码块的语法。 |`outputis` | 当语法为 bash 时，该属性指定命令输出结果的语法。 -|`downloadas` | 当用户 [下载该代码块时](#download-name) 默认的文件名。 -|`expandlinks` | 是否在代码块中为 [GitHub 文件引用](#link-2-files) 开启链接扩展。 +|`downloadas` | 当用户[下载该代码块时](#download-name)默认的文件名。 +|`expandlinks` | 是否在代码块中为 [GitHub 文件引用](#link-2-files)开启链接扩展。 |`snippet` | 要从代码块中提取的内容的 [snippet](#snippets) 名称。 |`repo` | The repository to use for [GitHub links](#link-2-files) embedded in preformatted blocks. |`repo` | 嵌入代码块中的仓库的 [GitHub 链接](#link-2-files)。 @@ -288,4 +288,4 @@ func HelloWorld() { - 对于内联内容，使用的当前页面的标题 - 导入代码的源文件的名称 -- 导入代码的源的URL +- 导入代码的源的 URL diff --git a/content/zh/about/contribute/diagrams/index.md b/content/zh/about/contribute/diagrams/index.md index 86c371c4a8..d2a1d2d83b 100644 --- a/content/zh/about/contribute/diagrams/index.md +++ b/content/zh/about/contribute/diagrams/index.md @@ -7,7 +7,7 @@ keywords: [contribute,diagram,documentation,guide] 欢迎学习 Istio 图表指南！ -本指南通过一个 [SVG 文件](./diagram-guidelines.svg) 或者 [Google Draw 文件](https://docs.google.com/drawings/d/1f3NyutAQIDOA8ojGNyMA5JAJllDShZGQAFfdD01XdSc/edit) 使您可以轻松的复用 shape 和 style。 +本指南通过一个 [SVG 文件](./diagram-guidelines.svg)或者 [Google Draw 文件](https://docs.google.com/drawings/d/1f3NyutAQIDOA8ojGNyMA5JAJllDShZGQAFfdD01XdSc/edit)使您可以轻松的复用 shape 和 style。 通过本指南，您可以使用任何矢量图绘制工具（例如，Google Draw、InkScape、Illustrator）为 Istio 站点创建 SVG 图表。 请保持图表中的文本处于可编辑状态。 @@ -17,11 +17,11 @@ keywords: [contribute,diagram,documentation,guide] 若要创建您的图表，请参照下面的步骤： -1. 参考 [指南](./diagram-guidelines.svg)，并根据需要从中复制粘贴。 +1. 参考[指南](./diagram-guidelines.svg)，并根据需要从中复制粘贴。 1. 用适当的线条连接 shape。 1. 用简短的描述性文字标记 shape 和线条。 1. 为多次应用的标签添加图例。 -1. 将您的图表 [贡献](/zh/about/contribute/add-content) 给我们的文档。 +1. 将您的图表[贡献](/zh/about/contribute/add-content)给我们的文档。 如果您是在 Google Draw 中创建图表，请参照下面的步骤： diff --git a/content/zh/about/contribute/github/index.md b/content/zh/about/contribute/github/index.md index 77e718d31d..ba9cb5460d 100644 --- a/content/zh/about/contribute/github/index.md +++ b/content/zh/about/contribute/github/index.md @@ -32,7 +32,7 @@ Istio 文档协作遵循标准的 [GitHub 协作流](https://guides.github.com/i 1. 创建 [GitHub 帐户](https://github.com)。 -1. 签署 [贡献者许可协议](https://github.com/istio/community/blob/master/CONTRIBUTING.md#contributor-license-agreements)。 +1. 签署[贡献者许可协议](https://github.com/istio/community/blob/master/CONTRIBUTING.md#contributor-license-agreements)。 1. 安装 [Docker](https://www.docker.com/get-started)，以预览和测试您的文档更改。 @@ -61,17 +61,17 @@ Istio 文档存储库使用多个分支发布所有 Istio 版本的文档。每 这种分支策略允许我们提供以下 Istio 在线资源： -- [发布站点](/zh/docs/) 提供当前最新发布分支的内容。 +- [发布站点](/zh/docs/)提供当前最新发布分支的内容。 - 预备站点 `https://preliminary.istio.io` 发布了当前 Master 分支上的最新内容。 -- [存档站点](https://archive.istio.io) 提供所有已发布分支的内容。 +- [存档站点](https://archive.istio.io)提供所有已发布分支的内容。 考虑到分支的工作原理，如果您提交修改到 master 分支，在 Istio 的下一个 major 版本发布前，这些更改都不会被应用到 istio.io。 如果您的文档更改和当前 Istio 版本密切相关，也可以将更改应用到当前版本的 Release 分支。您可以通过在文档的 PR 上使用 cherry-pick 标签，自动地执行此操作。 例如，如果您在 PR 中向 master 分支引入了更正，则可以通过 `cherrypick/release-1.4` 标签以将此更改合并到 `release-1.4` 分支。 -一旦您的初始PR被合并，将自动在 Release 分支创建一个包含您的更改的 PR。为了使 `CLA` 机器人可以继续工作，您可能需要在 PR 上添加一个内容为 `@googlebot I consent` 的评论。 +一旦您的初始 PR 被合并，将自动在 Release 分支创建一个包含您的更改的 PR。为了使 `CLA` 机器人可以继续工作，您可能需要在 PR 上添加一个内容为 `@googlebot I consent` 的评论。 在极少数情况下，cherry picks 功能可能无效。发生这种情况时，自动化程序将在原始 PR 中留下一条注释，表明它已失败。发生这种情况时，您将需要手动创建 cherry pick，并处理阻止该过程自动运行的合并问题。 @@ -83,4 +83,4 @@ Istio 文档存储库使用多个分支发布所有 Istio 版本的文档。每 访问我们的[社区角色页面](https://github.com/istio/community/blob/master/ROLES.md#role-summary)，在此页面您可以了解角色、相关的要求和职责以及与角色相关联的特权。 -访问我们的 [社区](https://github.com/istio/community)，您可以全面了解有关 Istio 社区的更多信息。 \ No newline at end of file +访问我们的[社区](https://github.com/istio/community)，您可以全面了解有关 Istio 社区的更多信息。 diff --git a/content/zh/about/contribute/review/index.md b/content/zh/about/contribute/review/index.md index dc7a849e6d..ab361d2b7a 100644 --- a/content/zh/about/contribute/review/index.md +++ b/content/zh/about/contribute/review/index.md @@ -5,7 +5,7 @@ weight: 6 keywords: [contribute,community,github,pr,documentation,review, approval] --- -Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对 [Istio 网站](/zh/docs/) 的所有更改。 +Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对 [Istio 网站](/zh/docs/)的所有更改。 **文档审阅者** 是一个受信任的贡献者，负责批准符合[审阅标准](#review-criteria)的内容。 所有审阅都遵循 [PR 内容审阅](#review-content-prs)中描述的流程。 @@ -25,7 +25,7 @@ Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对 1. 如果贡献者尚未加入任何与贡献内相关的技术工作组，则**审阅者**可将其加入到相应工作组。 1. **贡献者**和**审阅者**协同工作，直到内容符合所有[绝对验收标准](#required-acceptance-criteria)，且 Issue 得到完全解决。 1. 如果内容非常紧急，且满足[补充验收标准](#required-acceptance-criteria)需要大量工作，**审阅者** 可在 istio.io 仓库提交[跟进 Issue](#follow-up-issues)，以在后续处理这些问题。 -1. **贡献者**根据审阅者和贡献者的意见，处理所有反馈。[跟进 Issue](#follow-up-issues)中提到的问题将在后续解决。 +1. **贡献者**根据审阅者和贡献者的意见，处理所有反馈。[跟进 Issue](#follow-up-issues) 中提到的问题将在后续解决。 1. 当 **技术**工作组负责人或维护者批准 PR 内容，**审阅者** 可以批准 PR。 1. 如果 Docs WG 维护者或负责人审阅了内容，则他们不仅会批准内容，还会对其进行合并。否则，维护者和负责人将自动收到**审阅者**的批准通知，并优先批准和合并已审阅的内容。 @@ -70,4 +70,4 @@ Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对 - 图形附件：遵循 Istio [图形创建指南](/zh/about/contribute/diagrams/)。 - 示例代码：提供与内容密切相关且可测试的有效代码示例。 - 内容服用：任何可重复的内容都遵循使用样板文本的可重用性策略。 -- 术语：所有新的术语都已经添加到术语表中，且定义清晰。 \ No newline at end of file +- 术语：所有新的术语都已经添加到术语表中，且定义清晰。 diff --git a/content/zh/about/contribute/style-guide/index.md b/content/zh/about/contribute/style-guide/index.md index 1487d022e3..4ad7eeb3d8 100644 --- a/content/zh/about/contribute/style-guide/index.md +++ b/content/zh/about/contribute/style-guide/index.md @@ -8,7 +8,7 @@ aliases: keywords: [contribute] --- -Istio 文档所有的内容都必须 **清晰明了** 且 **易于理解**。我们根据 Google 开发者风格指南中的 [重点](https://developers.google.com/style/highlights) 和 [通则](https://developers.google.com/style/tone) 定义了标准。关于您贡献的内容是如何被审核、接受的，请参见[审核页面](/zh/about/contribute/review)获取详情。 +Istio 文档所有的内容都必须 **清晰明了** 且 **易于理解**。我们根据 Google 开发者风格指南中的[重点](https://developers.google.com/style/highlights)和[通则](https://developers.google.com/style/tone)定义了标准。关于您贡献的内容是如何被审核、接受的，请参见[审核页面](/zh/about/contribute/review)获取详情。 您可以在此通过 Istio 特有的示例，找到 Istio 遵循的基本风格与实践指南的所有场景。 diff --git a/content/zh/about/media-resources/index.md b/content/zh/about/media-resources/index.md index 71acb28d78..05a8da6a75 100644 --- a/content/zh/about/media-resources/index.md +++ b/content/zh/about/media-resources/index.md @@ -47,7 +47,7 @@ icon: istio-blue-logo diff --git a/content/zh/about/release-cadence/index.md b/content/zh/about/release-cadence/index.md index 6a12ec977d..02941e16f0 100644 --- a/content/zh/about/release-cadence/index.md +++ b/content/zh/about/release-cadence/index.md @@ -33,4 +33,4 @@ LTS 版本的命名模式为： .-alpha. {{< /text >}} -其中 `.` 代表下一个LTS，`` 代表此版本构建基于的git提交。 \ No newline at end of file +其中 `.` 代表下一个 LTS，`` 代表此版本构建基于的 git 提交。 diff --git a/content/zh/blog/2017/0.1-auth/index.md b/content/zh/blog/2017/0.1-auth/index.md index 55667ffbc3..231d008367 100644 --- a/content/zh/blog/2017/0.1-auth/index.md +++ b/content/zh/blog/2017/0.1-auth/index.md @@ -44,7 +44,7 @@ Istio Auth 基于双向 TLS 和 X.509 等行业标准。 此外，Google 还积 ### 强身份认证{#strong-identity} -Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 来识别服务运行的身份。 身份用于建立信任和定义服务级别访问策略。 身份在服务部署时分配，并在 X.509 证书的 SAN（主题备用名称）字段中进行编码。 使用服务帐户作为身份具有以下优点： +Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)来识别服务运行的身份。 身份用于建立信任和定义服务级别访问策略。 身份在服务部署时分配，并在 X.509 证书的 SAN（主题备用名称）字段中进行编码。 使用服务帐户作为身份具有以下优点： * 管理员可以使用 Kubernetes 1.6 中引入的 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 功能配置谁有权访问服务帐户 @@ -72,7 +72,7 @@ Istio Auth 为每个集群提供 CA（证书颁发机构），并可对密钥和 {{< image link="istio_auth_workflow.svg" caption="Istio Auth 工作流程" >}} -Istio Auth 是更广泛的容器安全中的一部分。 Red Hat 是 Kubernetes 开发的合作伙伴，定义了 [10 层](https://www.redhat.com/en/resources/container-security-openshift-cloud-devops-whitepaper) 容器安全。 Istio 和 Istio Auth 解决了其中两个层：”网络隔离” 和 “API 和服务端点管理”。 随着集群联邦在 Kubernetes 和其他平台上的发展，我们的目的是让 Istio 对跨越多个联邦集群的服务间通信提供保护。 +Istio Auth 是更广泛的容器安全中的一部分。 Red Hat 是 Kubernetes 开发的合作伙伴，定义了 [10 层](https://www.redhat.com/en/resources/container-security-openshift-cloud-devops-whitepaper)容器安全。 Istio 和 Istio Auth 解决了其中两个层：”网络隔离” 和 “API 和服务端点管理”。 随着集群联邦在 Kubernetes 和其他平台上的发展，我们的目的是让 Istio 对跨越多个联邦集群的服务间通信提供保护。 ## Istio Auth 的优点{#benefits-of-Istio-authentication} diff --git a/content/zh/blog/2017/0.1-canary/index.md b/content/zh/blog/2017/0.1-canary/index.md index e5aa0c3908..fc6c5a9f1b 100644 --- a/content/zh/blog/2017/0.1-canary/index.md +++ b/content/zh/blog/2017/0.1-canary/index.md @@ -15,13 +15,13 @@ aliases: 采用 [Istio](/zh/) 项目的一大好处就是为服务金丝雀方式部署提供了控制便利。金丝雀部署（或上线）背后的想法是通过让一小部分用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。如在过程中出现任何问题，则可以中止并回滚到旧版本。最简单的方式，是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的区域，用户或其他属性。 -基于领域的专业水平，您可能想知道为什么需要 Istio 来支持金丝雀部署，因为像 Kubernetes 这样的平台已经提供了进行 [版本上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 和 [金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 的方法。问题解决了吗 ？不完全是。虽然以这种方式进行部署可以在简单的情况下工作，但功能非常有限，特别是在大规模自动缩放的云环境中大流量的情况下。 +基于领域的专业水平，您可能想知道为什么需要 Istio 来支持金丝雀部署，因为像 Kubernetes 这样的平台已经提供了进行[版本上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)和[金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)的方法。问题解决了吗 ？不完全是。虽然以这种方式进行部署可以在简单的情况下工作，但功能非常有限，特别是在大规模自动缩放的云环境中大流量的情况下。 ## Kubernetes 中的金丝雀部署{#canary-deployment-in-Kubernetes} -假设我们有一个已部署的 **helloworld** 服务 **v1** 版本，我们想要测试（或简单上线）新版本 **v2**。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 中的镜像并自动进行部署来 [上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 新版本的 **helloworld** 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment)上线时有足够的 **v1** 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment)。最好，我们也能够对 Deployment 设置 [HPA](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#scaling-a-deployment)，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。 +假设我们有一个已部署的 **helloworld** 服务 **v1** 版本，我们想要测试（或简单上线）新版本 **v2**。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 中的镜像并自动进行部署来[上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)新版本的 **helloworld** 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment)上线时有足够的 **v1** 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment)。最好，我们也能够对 Deployment 设置 [HPA](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#scaling-a-deployment)，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。 -尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有 [公共 pod 标签](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) 的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。 +尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有[公共 pod 标签](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。 无论我们使用一个或者两个部署，使用 Docker，Mesos/Marathon 或 Kubernetes 等容器编排平台进行的金丝雀发布管理都存在一个根本问题：使用实例扩容来管理流量；版本流量分发和副本部署在上述平台中并独立。所有 pod 副本，无论版本如何，在 `kube-proxy` 循环池中都被一视同仁地对待，因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比维持金丝雀流量需要许多副本（例如，1％ 将需要至少 100 个副本）。即使我们可以忽略这个问题，部署方式功能仍然非常有限，因为它只支持简单（随机百分比）金丝雀部署。如果我们想根据某些特定规则将请求路由到金丝雀版本上，我们仍然需要另一种解决方案。 @@ -29,7 +29,7 @@ aliases: 使用 Istio，流量路由和副本部署是两个完全独立的功能。服务的 pod 数量可以根据流量负载灵活伸缩，与版本流量路由的控制完全正交。这在自动缩放的情况下能够更加简单地管理金丝雀版本。事实上，自动缩放管理器仍然独立运行，其在响应因流量路由导致的负载变化与其他原因导致负载变化的行为上没有区别。 -Istio 的 [路由规则](/zh/docs/concepts/traffic-management/#routing-rules) 也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％ 的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 **helloworld** 服务的简单便捷。 +Istio 的[路由规则](/zh/docs/concepts/traffic-management/#routing-rules)也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％ 的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 **helloworld** 服务的简单便捷。 首先我们定义 **helloworld** 服务，和普通 **Kubernetes** 服务一样，如下所示： @@ -81,9 +81,9 @@ spec: ... {{< /text >}} -需要注意的是，这与使用普通 Kubernetes 进行 [金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％ 的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。 +需要注意的是，这与使用普通 Kubernetes 进行[金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％ 的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。 -但是在 [启用 Istio](/zh/docs/setup/) 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％ 的流量发送到金丝雀版本本，我们可以使用 `kubectl` 来设置以下的路由规则： +但是在[启用 Istio](/zh/docs/setup/) 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％ 的流量发送到金丝雀版本本，我们可以使用 `kubectl` 来设置以下的路由规则： {{< text bash >}} $ kubectl apply -f - <}}/samples/helloworld) 查看示例代码。 +可在[此处]({{}}/samples/helloworld) 查看示例代码。 diff --git a/content/zh/blog/2017/0.1-using-network-policy/index.md b/content/zh/blog/2017/0.1-using-network-policy/index.md index 0bb22bfa06..51c4ae39ff 100644 --- a/content/zh/blog/2017/0.1-using-network-policy/index.md +++ b/content/zh/blog/2017/0.1-using-network-policy/index.md @@ -21,11 +21,11 @@ target_release: 0.1 ## 层级{#layer} -从 OSI 模型的角度来看7层（应用程序），Istio 策略运行在网络应用程序的“服务”层。但事实上云原生应用程序模型是7层实际上至少包含两层：服务层和内容层。服务层通常是 HTTP ，它封装了实际的应用程序数据（内容层）。Istio 的 Envoy 代理运行的 HTTP 服务层。相比之下，网络策略在 OSI 模型中的第3层（网络）和第4层（传输）运行。 +从 OSI 模型的角度来看 7 层（应用程序），Istio 策略运行在网络应用程序的“服务”层。但事实上云原生应用程序模型是 7 层实际上至少包含两层：服务层和内容层。服务层通常是 HTTP ，它封装了实际的应用程序数据（内容层）。Istio 的 Envoy 代理运行的 HTTP 服务层。相比之下，网络策略在 OSI 模型中的第 3 层（网络）和第 4 层（传输）运行。 -运行在服务层为 Envoy 代理提供了一组丰富的属性，以便基础协议进行策略决策，其中包括 HTTP/1.1 和 HTTP/2（ gRPC 运行在 HTTP/2 上）。因此，您可以基于虚拟主机、URL或其他 HTTP 头部应用策略。在未来，Istio 将支持广泛的7层协议、以及通用的 TCP 和 UDP 传输。 +运行在服务层为 Envoy 代理提供了一组丰富的属性，以便基础协议进行策略决策，其中包括 HTTP/1.1 和 HTTP/2（ gRPC 运行在 HTTP/2 上）。因此，您可以基于虚拟主机、URL 或其他 HTTP 头部应用策略。在未来，Istio 将支持广泛的 7 层协议、以及通用的 TCP 和 UDP 传输。 -相比之下，Istio 策略运行在网络层具有通用的优势，因为所有网络应用程序都使用IP。无论7层协议如何，您都可以在网络层应用策略：DNS 、SQL 数据库、实时流以及许多不使用 HTTP 的其他服务都可以得到保护。网络策略不仅限于经典防火墙的 IP 地址、 协议和端口三元组， Istio 和网络策略都可以使用丰富的 Kubernetes 标签来描述 pod 端点。 +相比之下，Istio 策略运行在网络层具有通用的优势，因为所有网络应用程序都使用 IP。无论 7 层协议如何，您都可以在网络层应用策略：DNS 、SQL 数据库、实时流以及许多不使用 HTTP 的其他服务都可以得到保护。网络策略不仅限于经典防火墙的 IP 地址、 协议和端口三元组， Istio 和网络策略都可以使用丰富的 Kubernetes 标签来描述 pod 端点。 ## 实现{#implementation} @@ -49,7 +49,7 @@ Envoy 代理的策略执行是在 pod 中，作为同一网络命名空间中的 ## 举例{#examples} -让我们来看一些Istio应用程序使用 Kubernetes 网络策略的示例。 下面我们以 Bookinfo 应用程序为例，介绍网络策略功能的用例： +让我们来看一些 Istio 应用程序使用 Kubernetes 网络策略的示例。 下面我们以 Bookinfo 应用程序为例，介绍网络策略功能的用例： - 减少应用程序入口的攻击面 - 在应用程序中实现细粒度隔离 diff --git a/content/zh/blog/2017/adapter-model/index.md b/content/zh/blog/2017/adapter-model/index.md index f82c5ca844..16bf23f411 100644 --- a/content/zh/blog/2017/adapter-model/index.md +++ b/content/zh/blog/2017/adapter-model/index.md @@ -26,7 +26,7 @@ Mixer 服务作为 Istio 和一套开放式基础设施之间的抽象层。Isti ## 设计哲学{#philosophy} -Mixer 本质上就是一个处理属性和路由的机器。代理将 [属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes) 作为预检和遥测报告的一部分发送出来，并且转换为一系列对适配器的调用。运维人员提供了用于描述如何将传入的属性映射为适配器的配置。 +Mixer 本质上就是一个处理属性和路由的机器。代理将[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)作为预检和遥测报告的一部分发送出来，并且转换为一系列对适配器的调用。运维人员提供了用于描述如何将传入的属性映射为适配器的配置。 {{< image width="60%" link="/zh/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg" @@ -53,7 +53,7 @@ Mixer 使用的每个适配器都需要一些配置才能运行。一般来说 你可以通过创建 [*instances*](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#instances) 来决定哪些数据被传递给特定的适配器。Instances 决定了 Mixer 如何通过 [attributes](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes) 把来自代理的属性拆分为各种数据然后分发给不同的适配器。 -创建实例通常需要使用 [attribute expressions](/zh/docs/reference/config/policy-and-telemetry/expression-language/) 。这些表达式的功能是使用属性和常量来生成结果数据，用于给instance字段进行赋值。 +创建实例通常需要使用 [attribute expressions](/zh/docs/reference/config/policy-and-telemetry/expression-language/) 。这些表达式的功能是使用属性和常量来生成结果数据，用于给 instance 字段进行赋值。 在模板中定义的每个 instance 字段、每个属性、每个表达式都有一个 [type](https://github.com/istio/api/blob/{{< source_branch_name >}}/policy/v1beta1/value_type.proto)，只有兼容的数据类型才能进行赋值。例如不能把整型的表达式赋值给字符串类型。强类型设计的目的就是为了降低配置出错引发的风险。 @@ -75,4 +75,4 @@ Rule 中包含有匹配断言，这个断言是一个返回布尔值的属性表 Handler 为各个适配器提供了配置数据，Template 用于在运行时确定不同的适配器所需的数据类型，Instance 让运维人员准备这些数据，Rule 将这些数据提交给一个或多个 Handler 进行处理。 -更多信息可以关注 [这里](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/)。更多关于 templates, handlers,和 rules 的内容可以关注 [这里](/zh/docs/reference/config/policy-and-telemetry/)。你也可以在[这里]({{< github_tree >}}/samples/bookinfo) 找到对应的示例。 +更多信息可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/)。更多关于 templates, handlers, 和 rules 的内容可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/)。你也可以在[这里]({{}}/samples/bookinfo) 找到对应的示例。 diff --git a/content/zh/blog/2018/aws-nlb/index.md b/content/zh/blog/2018/aws-nlb/index.md index 0df91bed87..dab396f95a 100644 --- a/content/zh/blog/2018/aws-nlb/index.md +++ b/content/zh/blog/2018/aws-nlb/index.md @@ -1,6 +1,6 @@ --- -title: 使用AWS NLB 配置 Istio Ingress -description: 描述如何在AWS上使用网络负载均衡器配置 Istio Ingress。 +title: 使用 AWS NLB 配置 Istio Ingress +description: 描述如何在 AWS 上使用网络负载均衡器配置 Istio Ingress。 publishdate: 2018-04-20 last_update: 2019-01-16 subtitle: Ingress AWS 网络负载均衡器 @@ -13,9 +13,9 @@ target_release: 1.0 本文已于 2019 年 1 月 16 日更新，其中包含一些使用警告。 {{< /tip >}} -本文提供了使用 [AWS 网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 配置 ingress Istio 的说明。 +本文提供了使用 [AWS 网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)配置 ingress Istio 的说明。 -可以使用网络负载均衡器 (NLB) 来代替传统的负载均衡器。 你可以查看不同的 AWS `负载均衡器` 之间的 [比较](https://aws.amazon.com/elasticloadbalancing/details/#Product_comparisons)以获取更多的解释。 +可以使用网络负载均衡器 (NLB) 来代替传统的负载均衡器。 你可以查看不同的 AWS `负载均衡器` 之间的[比较](https://aws.amazon.com/elasticloadbalancing/details/#Product_comparisons)以获取更多的解释。 ## 先行条件{#prerequisites} diff --git a/content/zh/blog/2018/delayering-istio/index.md b/content/zh/blog/2018/delayering-istio/index.md index c70090b096..cdf61b9c76 100644 --- a/content/zh/blog/2018/delayering-istio/index.md +++ b/content/zh/blog/2018/delayering-istio/index.md @@ -30,7 +30,7 @@ Sidecar proxy 模式成就了很多奇迹。Sidecar 身处微服务的数据路 ## AppSwitch -和容器运行时相比，AppSwitch 由客户端和一个守护进程组成，二者通过 HTTP 协议的 REST API 进行通信。客户端和守护进程构建为一个自包含的二进制文件 `ax`。客户端透明的注入s应用程序，并追踪网络相关的系统调用，随后通知守护进程。例如一个应用进行了 `connect(2)` 系统调用，目标是一个 Kubernetes 服务的 IP。AppSwitch 客户端拦截这一调用并令其失效，然后把这一事件及其参数和上下文环境告知守护进程。守护进程会处理系统调用，例如代表应用程序直接连接到上游服务器的 Pod IP。 +和容器运行时相比，AppSwitch 由客户端和一个守护进程组成，二者通过 HTTP 协议的 REST API 进行通信。客户端和守护进程构建为一个自包含的二进制文件 `ax`。客户端透明的注入 s 应用程序，并追踪网络相关的系统调用，随后通知守护进程。例如一个应用进行了 `connect(2)` 系统调用，目标是一个 Kubernetes 服务的 IP。AppSwitch 客户端拦截这一调用并令其失效，然后把这一事件及其参数和上下文环境告知守护进程。守护进程会处理系统调用，例如代表应用程序直接连接到上游服务器的 Pod IP。 值得注意的一点是，AppSwitch 的客户端和服务器之间不做任何数据转发。它们中间会通过 Unix socket 交换文件描述符，从而避免数据拷贝。另外客户端也不是独立进程，而是运行在应用本身的上下文之中的，因此应用和 AppSwitch 之间也不存在数据拷贝的操作。 diff --git a/content/zh/blog/2018/egress-https/index.md b/content/zh/blog/2018/egress-https/index.md index 5eac06e5a3..0dae251b92 100644 --- a/content/zh/blog/2018/egress-https/index.md +++ b/content/zh/blog/2018/egress-https/index.md @@ -14,7 +14,7 @@ target_release: 1.1 但是在迁移这些系统之前，必须让服务网格内的应用程序能访问它们。还有其他情况， 应用程序使用外部组织提供的 Web 服务，通常是通过万维网提供的服务。 -在这篇博客文章中，我修改了[Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)让它可以 +在这篇博客文章中，我修改了 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)让它可以 从外部 Web 服务（[Google Books APIs](https://developers.google.com/books/docs/v1/getting_started) ）获取图书详细信息。 我将展示如何使用 _mesh-external service entries_ 在 Istio 中启用外部 HTTPS 流量。最后， 我解释了当前与 Istio 出口流量控制相关的问题。 @@ -41,7 +41,7 @@ target_release: 1.1 ### 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)中获取图书详细信息。 +让我们添加一个新版本的 _details_ 微服务，_v2_，从 [Google Books APIs](https://developers.google.com/books/docs/v1/getting_started) 中获取图书详细信息。 它设定了服务容器的 `DO_NOT_ENCRYPT` 环境变量为 `false`。此设置将指示已部署服务使用 HTTPS（而不是 HTTP ）来访问外部服务。 {{< text bash >}} @@ -68,7 +68,7 @@ $ kubectl apply -f @samples/bookinfo/networking/virtual-service-details-v2.yaml@ 在[确定 ingress 的 IP 和端口](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port)之后， 让我们访问应用程序的网页。 -糟糕...页面显示 _Error fetching product details_，而不是书籍详细信息： +糟糕... 页面显示 _Error fetching product details_，而不是书籍详细信息： {{< image width="80%" link="errorFetchingBookDetails.png" caption="获取产品详细信息的错误消息" >}} @@ -77,14 +77,14 @@ $ kubectl apply -f @samples/bookinfo/networking/virtual-service-details-v2.yaml@ 仍然提供了应用程序的大多数功能, 我们有**优雅的服务降级**：正如您所看到的，评论和评级正确显示， 应用程序仍然有用。 -那可能出了什么问题？ 啊......答案是我忘了启用从网格内部到外部服务的流量，在本例中是 Google Book Web 服务。 +那可能出了什么问题？ 啊...... 答案是我忘了启用从网格内部到外部服务的流量，在本例中是 Google Book Web 服务。 默认情况下，Istio sidecar 代理（[Envoy proxies](https://www.envoyproxy.io)） -**阻止到集群外目的地的所有流量**, 要启用此类流量，我们必须定义[mesh-external service entry](/zh/docs/reference/config/networking/service-entry/)。 +**阻止到集群外目的地的所有流量**, 要启用此类流量，我们必须定义 [mesh-external service entry](/zh/docs/reference/config/networking/service-entry/)。 ### 启用对 Google Books 网络服务的 HTTPS 访问{#enable-https-access-to-a-google-books-web-service} 不用担心，让我们定义**网格外部 `ServiceEntry`** 并修复我们的应用程序。您还必须定义 _virtual -service_ 使用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)对外部服务执行路由。 +service_ 使用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 对外部服务执行路由。 {{< text bash >}} $ kubectl apply -f - <}} ### 在 Bookinfo 应用程序中使用外部数据库{#use-the-external-database-in-Bookinfo-application} -1.部署使用 MongoDB 数据库的 _ratings_ 微服务（_ratings v2_）： +1. 部署使用 MongoDB 数据库的 _ratings_ 微服务（_ratings v2_）： {{< text bash >}} $ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-ratings-v2.yaml@ @@ -199,7 +199,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4) 1. [部署 Istio egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#deploy-Istio-egress-gateway). -1. 如果您未执行 [上一节](#control-TCP-egress-traffic-without-a-gateway) 中的步骤，则立即执行这些步骤。 +1. 如果您未执行[上一节](#control-TCP-egress-traffic-without-a-gateway)中的步骤，则立即执行这些步骤。 1. 您可能希望启用 sidecar 代理和 MongoDB 客户端之间以及 egress gateway 的 {{< gloss >}}mutual TLS Authentication{{< /gloss >}}，以使 egress gateway 监控来源 pod 的身份并基于该 identity 启用 Mixer 策略。启用双向 TLS 时同样对流量进行了加密。 如果你不想开启双向 TLS，参考 [Mutual TLS between the sidecar proxies and the egress gateway](#mutual-TLS-between-the-sidecar-proxies-and-the-egress-gateway) 小节 @@ -434,7 +434,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4) 1. 再次刷新应用程序的网页，并验证等级是否仍正确显示。 -1. [开启 Envoy访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging) +1. [开启 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging) 1. 检查 egress gateway 的 Envoy 的统计数据，找到对应请求 MongoDB service 的 counter。如果 Istio 步骤在 `istio-system` namespace 中，打印 counter 的命令为： @@ -877,7 +877,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo {{< /text >}} 1. 为 *.com 创建一个 egress Gateway，使用 443 端口和 TLS 协议。创建一个 destination rule 来为 gateway 设置 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)。 -以及为 Envoy 过滤器，以防止恶意应用程序篡改SNI (过滤器验证这个应用程序发布的 SNI与报告给 Mixer 的 SNI是否相同) +以及为 Envoy 过滤器，以防止恶意应用程序篡改 SNI (过滤器验证这个应用程序发布的 SNI 与报告给 Mixer 的 SNI 是否相同) {{< text bash >}} $ kubectl apply -f - <}} - 你依然会得到关于访问[edition.cnn.com/politics](https://edition.cnn.com/politics)的信息和错误消息，然而这次 `responseCode` 会像我们预想的那样返回 `404` 。 + 你依然会得到关于访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的信息和错误消息，然而这次 `responseCode` 会像我们预想的那样返回 `404` 。 -虽然在这个简单的例子中使用 Istio 路由实现访问控制是可行的，但是在更复杂的例子中就不够了。例如，组织可能希望在某些条件下允许访问[edition.cnn.com/politics](https://edition.cnn.com/politics)，因此需要比仅通过 URL 路径过滤更复杂的策略逻辑。您可能想要应用 Istio Mixer 适配器，例如允许/禁止 URL 路径的[白名单或黑名单](/zh/docs/tasks/policy-enforcement/denial-and-list/#attribute-based-whitelists-or-blacklists)。策略规则允许指定复杂的条件，用丰富的表达式语言指定，其中包括与和或逻辑运算符。这些规则可用于日志记录和策略检查。更高级的用户可能希望应用基于 [Istio 角色访问控制](/zh/docs/concepts/security/#authorization)。 +虽然在这个简单的例子中使用 Istio 路由实现访问控制是可行的，但是在更复杂的例子中就不够了。例如，组织可能希望在某些条件下允许访问 [edition.cnn.com/politics](https://edition.cnn.com/politics)，因此需要比仅通过 URL 路径过滤更复杂的策略逻辑。您可能想要应用 Istio Mixer 适配器，例如允许/禁止 URL 路径的[白名单或黑名单](/zh/docs/tasks/policy-enforcement/denial-and-list/#attribute-based-whitelists-or-blacklists)。策略规则允许指定复杂的条件，用丰富的表达式语言指定，其中包括与和或逻辑运算符。这些规则可用于日志记录和策略检查。更高级的用户可能希望应用基于 [Istio 角色访问控制](/zh/docs/concepts/security/#authorization)。 另一方面是与远程访问策略系统的集成。如果在我们的用例中组织操作一些[标识和访问管理](https://en.wikipedia.org/wiki/Identity_management)系统，您可能希望配置 Istio 来使用来自这样一个系统的访问策略信息。您可以通过应用 [Istio Mixer 适配器](/zh/blog/2017/adapter-model/)来实现这种集成。 @@ -339,7 +339,7 @@ target_release: 1.1 EOF {{< /text >}} -1. 执行常规测试，将 HTTP 请求发送到[edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。正如所料，对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ （禁止）。 +1. 执行常规测试，将 HTTP 请求发送到 [edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。正如所料，对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ （禁止）。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health' @@ -352,7 +352,7 @@ target_release: 1.1 在我们用例中的组织设法配置日志和访问控制之后，它决定扩展它的访问策略，允许具有特殊[服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)的应用程序访问 _cnn.com_ 的任何主题，而不受监控。您将看到如何在 Istio 中配置此需求。 -1. 使用 `politics` 服务账户开启[sleep]({{< github_tree >}}/samples/sleep) 示例程序。 +1. 使用 `politics` 服务账户开启 [sleep]({{< github_tree >}}/samples/sleep) 示例程序。 {{< text bash >}} $ sed 's/: sleep/: politics/g' samples/sleep/sleep.yaml | kubectl create -f - @@ -432,7 +432,7 @@ target_release: 1.1 200 {{< /text >}} - 由于 `SOURCE_POD` 没有 `politics` 服务帐户，所以像以前一样访问[edition.cnn.com/politics](https://edition.cnn.com/politics) 会被禁止。 + 由于 `SOURCE_POD` 没有 `politics` 服务帐户，所以像以前一样访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 会被禁止。 1. 从 `SOURCE_POD_POLITICS` 中执行之前的测试： @@ -471,7 +471,7 @@ link="https-to-gateway.svg" caption="HTTPS egress 流量通过 egress 网关" >}} -从安全的角度来看，端到端 HTTPS 被认为是一种更好的方法。然而，由于流量是加密的，Istio 代理和出口网关只能看到源和目标 IP 以及目标的 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)。由于您将 Istio 配置为在 sidecar 代理和 egress 网关之间使用相互的 TLS ，所以[源标识](/zh/docs/concepts/security/#istio-identity)也是已知的。网关无法检查 URL 路径、HTTP 方法和请求的头，因此无法基于 HTTP 信息进行监控和策略。在我们的用例中，组织将能够允许访问 _edition.cnn.com_ 并指定允许哪些应用程序访问 _edition.cnn.com_ 。但是，将不可能允许或阻止对 _edition.cnn.com_ 的特定URL路径的访问。使用HTTPS方法既不能阻止对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的访问，也不能监控此类访问。 +从安全的角度来看，端到端 HTTPS 被认为是一种更好的方法。然而，由于流量是加密的，Istio 代理和出口网关只能看到源和目标 IP 以及目标的 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)。由于您将 Istio 配置为在 sidecar 代理和 egress 网关之间使用相互的 TLS ，所以[源标识](/zh/docs/concepts/security/#istio-identity)也是已知的。网关无法检查 URL 路径、HTTP 方法和请求的头，因此无法基于 HTTP 信息进行监控和策略。在我们的用例中，组织将能够允许访问 _edition.cnn.com_ 并指定允许哪些应用程序访问 _edition.cnn.com_ 。但是，将不可能允许或阻止对 _edition.cnn.com_ 的特定 URL 路径的访问。使用 HTTPS 方法既不能阻止对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的访问，也不能监控此类访问。 我们认为，每个组织都应充分考虑这两种方法的优缺点，并选择最适合其需要的方法。 diff --git a/content/zh/blog/2018/egress-tcp/index.md b/content/zh/blog/2018/egress-tcp/index.md index 423ecf2203..709f64cf00 100644 --- a/content/zh/blog/2018/egress-tcp/index.md +++ b/content/zh/blog/2018/egress-tcp/index.md @@ -132,7 +132,7 @@ target_release: 1.0 为了演示使用外部数据库的场景，你首先使用安装了 [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)。 -此应用程序使用 `ratings` 微服务来获取书籍评级，评分在1到5之间。评级显示为每个评论的星号，有几个版本的 `ratings` 微服务。有些人使用 [MongoDB](https://www.mongodb.com)，有些使用 [MySQL](https://www.mysql.com) 作为他们的数据库。 +此应用程序使用 `ratings` 微服务来获取书籍评级，评分在 1 到 5 之间。评级显示为每个评论的星号，有几个版本的 `ratings` 微服务。有些人使用 [MongoDB](https://www.mongodb.com)，有些使用 [MySQL](https://www.mysql.com) 作为他们的数据库。 这篇博客例子里的命令是以 Istio 0.8 以上版本为基础的，无论启用或不启用[双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication)。 @@ -145,7 +145,7 @@ target_release: 1.0 ### 将数据库用于 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)中。编辑以下几行： +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) 中。编辑以下几行： {{< text yaml >}} - name: MYSQL_DB_HOST @@ -260,9 +260,9 @@ target_release: 1.0 ## TCP 流量的服务入口{#service-entries-for-tcp-traffic} -启用到特定端口的 TCP 流量的服务入口必须指定 `TCP` 作为端口的协议，此外，对于 [MongoDB Wire协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)，协议可以指定为 `MONGO`，而不是 `TCP`。 +启用到特定端口的 TCP 流量的服务入口必须指定 `TCP` 作为端口的协议，此外，对于 [MongoDB Wire 协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)，协议可以指定为 `MONGO`，而不是 `TCP`。 -对于服务入口配置的 `addresses` 字段，必须使用 [CIDR](https://tools.ietf.org/html/rfc2317)表示法中的 IP 块。注意在 TCP 服务入口配置中，`host` 字段会被忽略。 +对于服务入口配置的 `addresses` 字段，必须使用 [CIDR](https://tools.ietf.org/html/rfc2317) 表示法中的 IP 块。注意在 TCP 服务入口配置中，`host` 字段会被忽略。 要通过其主机名启用到外部服务的 TCP 流量，必须指定主机名的所有 IP，每个 IP 必须由 CIDR 块指定。 diff --git a/content/zh/blog/2018/export-logs-through-stackdriver/index.md b/content/zh/blog/2018/export-logs-through-stackdriver/index.md index d273cb4187..8ee97821b1 100644 --- a/content/zh/blog/2018/export-logs-through-stackdriver/index.md +++ b/content/zh/blog/2018/export-logs-through-stackdriver/index.md @@ -13,11 +13,11 @@ target_release: 0.8 ## 开始之前{#before-you-begin} -在集群中[`安装 Istio`](/zh/docs/setup/) 并部署应用程序。 +在集群中 [`安装 Istio`](/zh/docs/setup/) 并部署应用程序。 ## 配置 Istio 导出日志{#configuring-Istio-to-export-logs} -Istio 使用 `logentry` [`模板`](/zh/docs/reference/config/policy-and-telemetry/templates/logentry)导出日志。这里指定了可用于分析的所有变量。它包含源服务、目标服务、`auth` 指标（即将实现......）等信息。以下是示意图： +Istio 使用 `logentry` [`模板`](/zh/docs/reference/config/policy-and-telemetry/templates/logentry) 导出日志。这里指定了可用于分析的所有变量。它包含源服务、目标服务、`auth` 指标（即将实现......）等信息。以下是示意图： {{< image width="75%" link="./istio-analytics-using-stackdriver.png" caption="导出日志到 Stackdriver 进行分析的图释" >}} @@ -29,33 +29,33 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为 1. 为项目启用 [`Stackdriver Monitoring API`](https://cloud.google.com/monitoring/api/enable-api) 。 1. 确保配置的接收器的 `principalEmail` 具有对项目写入的权限和日志管理员角色的权限。 -1. 确保已设置 `GOOGLE_APPLICATION_CREDENTIALS` 环境变量。请按照[`此处`](https://cloud.google.com/docs/authentication/getting-started)的说明进行设置。 +1. 确保已设置 `GOOGLE_APPLICATION_CREDENTIALS` 环境变量。请按照 [`此处`](https://cloud.google.com/docs/authentication/getting-started) 的说明进行设置。 #### BigQuery{#big-query} -1. [`创建 BigQuery 数据集`](https://cloud.google.com/bigquery/docs/datasets)作为日志导出的目标。 +1. [`创建 BigQuery 数据集`](https://cloud.google.com/bigquery/docs/datasets) 作为日志导出的目标。 1. 记录数据集的 ID。 这里需要设置 Stackdriver 处理程序。它的格式为 `bigquery.googleapis.com/projects/[PROJECT_ID]/datasets/[DATASET_ID]` -1. 给[`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：cloud-logs@system.gserviceaccount.com。它具有 IAM 中的 BigQuery Data Editor 的角色。 +1. 给 [`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：cloud-logs@system.gserviceaccount.com。它具有 IAM 中的 BigQuery Data Editor 的角色。 1. 如果使用 [`Google Kubernetes Engine`](/zh/docs/setup/platform-setup/gke/)，请确保在集群上启用了 `bigquery` [`Scope`](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create)。 #### Google Cloud Storage (GCS){#google-cloud-storage} 1. [`创建 GCS 存储桶`](https://cloud.google.com/storage/docs/creating-buckets)，希望导出日志到 GCS 中。 1. 记录存储桶的 ID。这里需要配置 Stackdriver。它的形式为 `storage.googleapis.com/[BUCKET_ID]`。 -1. 给[`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Storage Object Creator 的角色。 +1. 给 [`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Storage Object Creator 的角色。 #### Google Cloud Pub/Sub{#google-cloud-pub-sub} -1. [`创建主题`](https://cloud.google.com/pubsub/docs/admin)，希望导出日志到Google Cloud Pub/Sub 中。 +1. [`创建主题`](https://cloud.google.com/pubsub/docs/admin)，希望导出日志到 Google Cloud Pub/Sub 中。 1. 记录主题的 ID。这里需要配置 Stackdriver。它的形式为`pubsub.googleapis.com/projects/[PROJECT_ID]/topics/[TOPIC_ID]`。 -1. 给[`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Pub/Sub Publisher 角色。 +1. 给 [`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Pub/Sub Publisher 角色。 1. 如果使用 [`Google Kubernetes Engine`](/zh/docs/setup/platform-setup/gke/)，请确保在集群中启动了 `pubsub` [`Scope`](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create)。 ### 设置 Stackdriver{#setting-up-stack-driver} -必须创建 Stackdriver 处理程序，将数据导出到 Stackdriver。Stackdriver 处理程序的配置在[`此处`](/zh/docs/reference/config/policy-and-telemetry/adapters/stackdriver/)描述。 +必须创建 Stackdriver 处理程序，将数据导出到 Stackdriver。Stackdriver 处理程序的配置在 [`此处`](/zh/docs/reference/config/policy-and-telemetry/adapters/stackdriver/) 描述。 -1. 保存如下的yaml文件为 `stackdriver.yaml` 。并替换 `, +1. 保存如下的 yaml 文件为 `stackdriver.yaml` 。并替换 `, , , ` 为相应的值。 {{< text yaml >}} @@ -189,7 +189,7 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为 filter: '' {{< /text >}} -在上面的配置中，sinkInfo 包含有关日志导出到所需接收器的信息。有关如何填写不同接收器的更多信息，请参阅[`此处`](https://cloud.google.com/logging/docs/export/#sink-terms)。 +在上面的配置中，sinkInfo 包含有关日志导出到所需接收器的信息。有关如何填写不同接收器的更多信息，请参阅 [`此处`](https://cloud.google.com/logging/docs/export/#sink-terms)。   1. 为 Stackdriver 添加规则 @@ -218,4 +218,4 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为 ## 日志导出的可用性{#availability-of-logs-in-export-sinks} -导出到 BigQuery 只需几分钟（可以认为是瞬间完成的），不过GCS要延迟2 至 12 小时，而Pub/Sub 则几乎没有延迟。 +导出到 BigQuery 只需几分钟（可以认为是瞬间完成的），不过 GCS 要延迟 2 至 12 小时，而 Pub/Sub 则几乎没有延迟。 diff --git a/content/zh/blog/2018/istio-authorization/index.md b/content/zh/blog/2018/istio-authorization/index.md index d899142580..5fbfc05d65 100644 --- a/content/zh/blog/2018/istio-authorization/index.md +++ b/content/zh/blog/2018/istio-authorization/index.md @@ -29,8 +29,8 @@ Micro-Segmentation 是一种安全技术，可在云部署中创建安全区域 ### 具有条件的基于角色的访问控制{#role-based-access-control-with-conditions} -授权是[基于角色的访问控制（RBAC）](https://en.wikipedia.org/wiki/Role-based_access_control)系统， -将此与[基于属性的访问控制（ABAC）](https://en.wikipedia.org/wiki/Attribute-based_access_control)系统对比。 +授权是[基于角色的访问控制（RBAC）](https://en.wikipedia.org/wiki/Role-based_access_control) 系统， +将此与[基于属性的访问控制（ABAC）](https://en.wikipedia.org/wiki/Attribute-based_access_control) 系统对比。 与 ABAC 相比，RBAC 具有以下优势： * **角色允许对属性进行分组。** 角色是权限组，用于指定允许的操作在系统上执行。用户根据组织内的角色进行分组。 @@ -56,13 +56,13 @@ Micro-Segmentation 是一种安全技术，可在云部署中创建安全区域 除主要标识外，您还可以自己定义标识。例如，您可以将客户端标识指定为“用户 `Alice` 从 `Bookstore` 前端服务调用”，在这种情况下， 你有一个调用服务（`Bookstore frontend`）和最终用户（`Alice`）的组合身份。 -要提高安全性，您应该启用[认证功能](/zh/docs/concepts/security/#authentication),并在授权策略中使用经过验证的身份。但是， +要提高安全性，您应该启用[认证功能](/zh/docs/concepts/security/#authentication), 并在授权策略中使用经过验证的身份。但是， 使用授权不强迫一定要有身份验证。Istio 授权可以使用或不使用身份。如果您正在使用遗留系统，您可能没有网格的双向 TLS 或 JWT 身份验证 设置。在这种情况下，识别客户端的唯一方法是，例如，通过 IP。您仍然可以使用 Istio 授权来控制允许哪些 IP 地址或 IP 范围访问您的服务。 ## 示例{#examples} -[授权任务](/zh/docs/tasks/security/authorization/authz-http)通过 [Bookinfo 应用](/zh/docs/examples/bookinfo) 向您展示如何使用 Istio 的授权功能来控制命名空间级别 +[授权任务](/zh/docs/tasks/security/authorization/authz-http)通过 [Bookinfo 应用](/zh/docs/examples/bookinfo)向您展示如何使用 Istio 的授权功能来控制命名空间级别 和服务级别的访问。在本节中，您将看到更多使用 Istio 授权进行权限细分的示例。 ### 通过 RBAC + 条件进行命名空间级别细分{#namespace-level-segmentation-via-rbac-conditions} @@ -124,7 +124,7 @@ spec: #### 使用经过身份验证的客户端身份{#using-authenticated-client-identities} 假设你想把这个 `book-reader` 角色授予你的 `bookstore-frontend` 服务。如果您已启用 -您的网格的[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication),您可以使用服务帐户，以识别您的 `bookstore-frontend` 服务。授予 `book-reader` 角色到 `bookstore-frontend` 服务可以通过创建一个 `ServiceRoleBinding` 来完成，如下所示： +您的网格的[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication), 您可以使用服务帐户，以识别您的 `bookstore-frontend` 服务。授予 `book-reader` 角色到 `bookstore-frontend` 服务可以通过创建一个 `ServiceRoleBinding` 来完成，如下所示： {{< text yaml >}} apiVersion: "rbac.istio.io/v1alpha1" @@ -179,4 +179,4 @@ spec: ## 概要{#summary} -Istio 在命名空间级别，服务级别和方法级别粒度上提供授权功能。它采用“ RBAC + 条件”模型，使其成为易于使用和理解的 RBAC 系统，同时提供 ABAC 系统级别的灵活性。由于 Istio 授权在 Envoy 上本地运行，它有很高的性能。Istio 授权既可以与 [Istio 认证功能](/zh/docs/concepts/security/#authentication) 一起提供最佳的安全性，也可以用于为没有身份验证的旧系统提供访问控制。 +Istio 在命名空间级别，服务级别和方法级别粒度上提供授权功能。它采用“ RBAC + 条件”模型，使其成为易于使用和理解的 RBAC 系统，同时提供 ABAC 系统级别的灵活性。由于 Istio 授权在 Envoy 上本地运行，它有很高的性能。Istio 授权既可以与 [Istio 认证功能](/zh/docs/concepts/security/#authentication)一起提供最佳的安全性，也可以用于为没有身份验证的旧系统提供访问控制。 diff --git a/content/zh/blog/2018/istio-twitch-stream/index.md b/content/zh/blog/2018/istio-twitch-stream/index.md index f422c84934..f185b020a5 100644 --- a/content/zh/blog/2018/istio-twitch-stream/index.md +++ b/content/zh/blog/2018/istio-twitch-stream/index.md @@ -7,7 +7,7 @@ attribution: Spencer Krum, IBM target_release: 1.0 --- -为了庆祝 Istio 1.0 版本的发布并向更广泛的受众推广该软件，8月17日 Istio 社区在 Twitch 举办了一天的实况直播。 +为了庆祝 Istio 1.0 版本的发布并向更广泛的受众推广该软件，8 月 17 日 Istio 社区在 Twitch 举办了一天的实况直播。 ## Twitch 是什么？{#what-is-twitch} @@ -15,11 +15,11 @@ target_release: 1.0 ## 它用 Istio 做了什么？{#what-does-this-have-to-do-with-Istio} -Istio 在平台上发布的全天的内容，希望可以给观众讲解如何将深度技术内容、初级内容和业务线内容做良好融合。我们有开发人员、用户和布道者来分享示例和故事。期待现场编码，QA 和一些惊喜。我们有来自 IBM、Google、Datadog、Pivotal和更多的明星嘉宾。 +Istio 在平台上发布的全天的内容，希望可以给观众讲解如何将深度技术内容、初级内容和业务线内容做良好融合。我们有开发人员、用户和布道者来分享示例和故事。期待现场编码，QA 和一些惊喜。我们有来自 IBM、Google、Datadog、Pivotal 和更多的明星嘉宾。 ## 如何观看{#recordings} -很简单！只要在8月17日上午10点导航到[这里](https://twitch.tv/ibmcode)。 +很简单！只要在 8 月 17 日上午 10 点导航到[这里](https://twitch.tv/ibmcode)。 ## 安排{#schedule} diff --git a/content/zh/blog/2018/soft-multitenancy/index.md b/content/zh/blog/2018/soft-multitenancy/index.md index 6d5f7ac5e2..07ffecb687 100644 --- a/content/zh/blog/2018/soft-multitenancy/index.md +++ b/content/zh/blog/2018/soft-multitenancy/index.md @@ -60,7 +60,7 @@ istio-system1 istio-pilot-5bb6b7669c-779vb 2/2 Running 0 ### 区分通用资源和命名空间资源{#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 仓库中的清单文件中会创建两种资源，一种是能够被所有 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} @@ -259,7 +259,7 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p * 视频：[用 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). -* Kubernetes [RBAC 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 以及 [命名空间文档](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/). +* Kubernetes [RBAC 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)以及[命名空间文档](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/). * `Kubecon` 幻灯片 [Multi-tenancy Deep Dive](https://schd.ws/hosted_files/kccncna17/a9/kubecon-multitenancy.pdf). * Google 文档 [Multi-tenancy models for Kubernetes](https://docs.google.com/document/d/15w1_fesSUZHv-vwjiYa9vN_uyc--PySRoLKTuDhimjc). (需要授权) * Cloud Foundry 提出的文档：[Multi-cloud and Multi-tenancy](https://docs.google.com/document/d/14Hb07gSrfVt5KX9qNi7FzzGwB_6WBpAnDpPG6QEEd9Q) diff --git a/content/zh/blog/2018/traffic-mirroring/index.md b/content/zh/blog/2018/traffic-mirroring/index.md index 3f8362dc82..b0a9abcfbc 100644 --- a/content/zh/blog/2018/traffic-mirroring/index.md +++ b/content/zh/blog/2018/traffic-mirroring/index.md @@ -10,7 +10,7 @@ target_release: 0.5 在非生产/测试环境中，尝试穷举一个服务所有可能的测试用例组合是个令人望而生畏的任务, 在某些情况下，您会发现编写这些用例的所有工作都与实际生产用例不匹配, 理想情况下，我们可以使用实时生产用例和流量来帮助说明我们可能在更人为的测试环境中错过的所测试服务的所有功能区域。 -Istio 可以在这里提供帮助, 随着[Istio 0.5.0](/zh/news/releases/0.x/announcing-0.5)的发布，Istio 可以镜像流量来帮助测试您的服务, 您可以编写类似于以下内容的路由规则来启用流量镜像： +Istio 可以在这里提供帮助, 随着 [Istio 0.5.0](/zh/news/releases/0.x/announcing-0.5) 的发布，Istio 可以镜像流量来帮助测试您的服务, 您可以编写类似于以下内容的路由规则来启用流量镜像： {{< text yaml >}} apiVersion: config.istio.io/v1alpha2 diff --git a/content/zh/blog/2018/v1alpha3-routing/index.md b/content/zh/blog/2018/v1alpha3-routing/index.md index b689f355da..2dc122334b 100644 --- a/content/zh/blog/2018/v1alpha3-routing/index.md +++ b/content/zh/blog/2018/v1alpha3-routing/index.md @@ -1,6 +1,6 @@ --- title: Istio v1aplha3 路由 API 介绍 -description: Istio v1alpha3 路由 API 介绍,动机及其设计原则。 +description: Istio v1alpha3 路由 API 介绍, 动机及其设计原则。 publishdate: 2018-04-25 subtitle: attribution: Frank Budinsky (IBM) and Shriram Rajagopalan (VMware) @@ -8,13 +8,13 @@ keywords: [traffic-management] target_release: 0.7 --- -到目前为止，Istio 提供了一个简单的API来进行流量管理，该API包括了四种资源：`RouteRule`，`DestinationPolicy`，`EgressRule` 和 （Kubernetes 的）`Ingress`。借助此 API，用户可以轻松管理 Istio 服务网格中的流量。该 API 允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等，所有这些功能都不必更改应用程序本身的代码。 +到目前为止，Istio 提供了一个简单的 API 来进行流量管理，该 API 包括了四种资源：`RouteRule`，`DestinationPolicy`，`EgressRule` 和 （Kubernetes 的）`Ingress`。借助此 API，用户可以轻松管理 Istio 服务网格中的流量。该 API 允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等，所有这些功能都不必更改应用程序本身的代码。 虽然目前 API 的功能已被证明是 Istio 非常引人注目的一部分，但用户的反馈也表明，这个 API 确实有一些缺点，尤其是在使用它来管理包含数千个服务的非常大的应用程序，以及使用 HTTP 以外的协议时。 此外，使用 Kubernetes Ingress 资源来配置外部流量的方式已被证明不能满足需求。 -为了解决上述缺陷和其他的一些问题，Istio 引入了新的流量管理 API v1alpha3，新版本的 API 将完全取代之前的 API。 尽管 v1alpha3 和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧API的模型需要进行手动转换。 +为了解决上述缺陷和其他的一些问题，Istio 引入了新的流量管理 API v1alpha3，新版本的 API 将完全取代之前的 API。 尽管 v1alpha3 和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧 API 的模型需要进行手动转换。 -为了证明该非兼容升级的必要性，v1alpha3 API 经历了漫长而艰苦的社区评估过程，以希望新的API能够大幅改进，并经得起时间考验。 在本文中，我们将介绍新的配置模型，并试图解释影响这次变化的一些动机和设计原则。 +为了证明该非兼容升级的必要性，v1alpha3 API 经历了漫长而艰苦的社区评估过程，以希望新的 API 能够大幅改进，并经得起时间考验。 在本文中，我们将介绍新的配置模型，并试图解释影响这次变化的一些动机和设计原则。 ## 设计原则{#design-principles} @@ -31,7 +31,7 @@ target_release: 0.7 {{< image width="80%" link="gateways.svg" alt="Role of gateways in the mesh" - caption="Istio服务网格中的网关" + caption="Istio 服务网格中的网关" >}} 考虑到上述因素，`v1alpha3`引入了以下这些新的配置资源来控制进入网格，网格内部和离开网格的流量路由。 @@ -47,7 +47,7 @@ target_release: 0.7 {{< image width="80%" link="virtualservices-destrules.svg" - caption="不同v1alpha3元素之间的关系" + caption="不同 v1alpha3 元素之间的关系" >}} ### `Gateway` @@ -56,7 +56,7 @@ target_release: 0.7 对于入口流量管理，您可能会问： _为什么不直接使用 Kubernetes Ingress API_ ？ 原因是 Ingress API 无法表达 Istio 的路由需求。 Ingress 试图在不同的 HTTP 代理之间取一个公共的交集，因此只能支持最基本的 HTTP 路由，最终导致需要将代理的其他高级功能放入到注解（annotation）中，而注解的方式在多个代理之间是不兼容的，无法移植。 -Istio `Gateway` 通过将 L4-L6 配置与L7配置分离的方式克服了 `Ingress` 的这些缺点。 `Gateway` 只用于配置 L4-L6 功能（例如，对外公开的端口，TLS 配置），所有主流的L7代理均以统一的方式实现了这些功能。 然后，通过在 `Gateway` 上绑定 `VirtualService` 的方式，可以使用标准的 Istio 规则来控制进入 `Gateway` 的 HTTP 和 TCP 流量。 +Istio `Gateway` 通过将 L4-L6 配置与 L7 配置分离的方式克服了 `Ingress` 的这些缺点。 `Gateway` 只用于配置 L4-L6 功能（例如，对外公开的端口，TLS 配置），所有主流的 L7 代理均以统一的方式实现了这些功能。 然后，通过在 `Gateway` 上绑定 `VirtualService` 的方式，可以使用标准的 Istio 规则来控制进入 `Gateway` 的 HTTP 和 TCP 流量。 例如，下面这个简单的 `Gateway` 配置了一个 Load Balancer，以允许访问 host `bookinfo.com` 的 https 外部流量进入网格中： @@ -198,7 +198,7 @@ spec: ... {{< /text >}} -实际上在 `VirtualService` 中 hosts 部分设置只是虚拟的目的地,因此不一定是已在网格中注册的服务。这允许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。 通过将 `VirtualService` 绑定到同一 Host 的 `Gateway` 配置（如前一节所述 ），可向网格外部暴露这些 Host。 +实际上在 `VirtualService` 中 hosts 部分设置只是虚拟的目的地, 因此不一定是已在网格中注册的服务。这允许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。 通过将 `VirtualService` 绑定到同一 Host 的 `Gateway` 配置（如前一节所述 ），可向网格外部暴露这些 Host。 除了这个重大的重构之外， `VirtualService` 还包括其他一些重要的改变： @@ -206,7 +206,7 @@ spec: 1. 每个服务版本都有一个名称（称为服务子集）。 属于某个子集的一组 Pod/VM 在 `DestinationRule` 定义，具体定义参见下节。 -1. 通过使用带通配符前缀的 DNS 来指定 `VirtualService` 的 host，可以创建单个规则以作用于所有匹配的服务。 例如，在 Kubernetes 中，在 `VirtualService` 中使用 `*.foo.svc.cluster.local` 作为 host ,可以对 `foo` 命名空间中的所有服务应用相同的重写规则。 +1. 通过使用带通配符前缀的 DNS 来指定 `VirtualService` 的 host，可以创建单个规则以作用于所有匹配的服务。 例如，在 Kubernetes 中，在 `VirtualService` 中使用 `*.foo.svc.cluster.local` 作为 host , 可以对 `foo` 命名空间中的所有服务应用相同的重写规则。 ### `DestinationRule` @@ -267,7 +267,7 @@ spec: 也就是说，`ServiceEntry` 比它的前身具有更多的功能。首先，`ServiceEntry` 不限于外部服务配置，它可以有两种类型：网格内部或网格外部。网格内部条目只是用于向网格显式添加服务，添加的服务与其他内部服务一样。采用网格内部条目，可以把原本未被网格管理的基础设施也纳入到网格中（例如，把虚机中的服务添加到基于 Kubernetes 的服务网格中）。网格外部条目则代表了网格外部的服务。对于这些外部服务来说，双向 TLS 身份验证是禁用的，并且策略是在客户端执行的，而不是在像内部服务请求一样在服务器端执行策略。 -由于 `ServiceEntry` 配置只是将服务添加到网格内部的服务注册表中，因此它可以像注册表中的任何其他服务一样,与 `VirtualService` 和/或 `DestinationRule` 一起使用。例如，以下 `DestinationRule` 可用于启动外部服务的 双向 TLS 连接： +由于 `ServiceEntry` 配置只是将服务添加到网格内部的服务注册表中，因此它可以像注册表中的任何其他服务一样, 与 `VirtualService` 和/或 `DestinationRule` 一起使用。例如，以下 `DestinationRule` 可用于启动外部服务的 双向 TLS 连接： {{< text yaml >}} apiVersion: networking.istio.io/v1alpha3 @@ -312,7 +312,7 @@ $ kubectl apply -f my-updated-rules-for-destination-abc.yaml ## 总结{#summary} -Istio `v1alpha3` 路由 API 具有比其前身更多的功能，但不幸的是新的 API 并不向后兼容，旧的模型升级需要一次手动转换。 Istio 0.9以后将不再支持 `RouteRule`，`DesintationPolicy` 和 `EgressRule` 这些以前的配置资源 。Kubernetes 用户可以继续使用 `Ingress` 配置边缘负载均衡器来实现基本的路由。 但是，高级路由功能（例如，跨两个版本的流量分割）则需要使 `用Gateway` ，这是一种功能更强大，Istio 推荐的 `Ingress` 替代品。 +Istio `v1alpha3` 路由 API 具有比其前身更多的功能，但不幸的是新的 API 并不向后兼容，旧的模型升级需要一次手动转换。 Istio 0.9 以后将不再支持 `RouteRule`，`DesintationPolicy` 和 `EgressRule` 这些以前的配置资源 。Kubernetes 用户可以继续使用 `Ingress` 配置边缘负载均衡器来实现基本的路由。 但是，高级路由功能（例如，跨两个版本的流量分割）则需要使 `用 Gateway` ，这是一种功能更强大，Istio 推荐的 `Ingress` 替代品。 ## 致谢{#acknowledgments} diff --git a/content/zh/blog/2019/announcing-istio-client-go/index.md b/content/zh/blog/2019/announcing-istio-client-go/index.md index aac1f021e1..cb97826554 100644 --- a/content/zh/blog/2019/announcing-istio-client-go/index.md +++ b/content/zh/blog/2019/announcing-istio-client-go/index.md @@ -67,14 +67,14 @@ func main() { } {{< /text >}} -您可以在 [这里](https://github.com/istio/client-go/blob/{{< source_branch_name >}}/cmd/example/client.go) 找到更详尽的示例。 +您可以在[这里](https://github.com/istio/client-go/blob/{{}}/cmd/example/client.go) 找到更详尽的示例。 ## 为生成 Istio client go 而创建的工具{#useful-tools-created-for-generating-Istio-client-go} -如果您想知道为什么花费大量时间也很难生成此客户端，本小节将对此进行说明。在 `Istio` 中，我们使用[protobuf](https://developers.google.com/protocol-buffers) 规范编写 `API`，然后使用 `protobuf` 工具链将其转换为 `Go` 定义。如果尝试从 `protobuf` 的 `API` 生成 `Kubernetes` 客户端，可能会面临三个主要的挑战： +如果您想知道为什么花费大量时间也很难生成此客户端，本小节将对此进行说明。在 `Istio` 中，我们使用 [protobuf](https://developers.google.com/protocol-buffers) 规范编写 `API`，然后使用 `protobuf` 工具链将其转换为 `Go` 定义。如果尝试从 `protobuf` 的 `API` 生成 `Kubernetes` 客户端，可能会面临三个主要的挑战： * **创建 Kubernetes 装饰器类型** - Kubernetes [客户端生成库](https://github.com/kubernetes/code-generator/tree/master/cmd/client-gen) -仅适用于遵循 `Kubernetes` 对象规范的 `Go` 对象， 例如： [Authentication Policy Kubernetes Wrappers](https://github.com/istio/client-go/blob/{{< source_branch_name >}}/pkg/apis/authentication/v1alpha1/types.gen.go)。这意味着对于需要程序访问的每个API，您都需要创建这些装饰器。此外，每个 `CRD` 组，版本和种类都需要大量的样板，需要用客户端代码生成。为了自动化该过程，我们创建了一个 [Kubernetes type +仅适用于遵循 `Kubernetes` 对象规范的 `Go` 对象， 例如： [Authentication Policy Kubernetes Wrappers](https://github.com/istio/client-go/blob/{{< source_branch_name >}}/pkg/apis/authentication/v1alpha1/types.gen.go)。这意味着对于需要程序访问的每个 API，您都需要创建这些装饰器。此外，每个 `CRD` 组，版本和种类都需要大量的样板，需要用客户端代码生成。为了自动化该过程，我们创建了一个 [Kubernetes type generator](https://github.com/istio/tools/tree/master/cmd/kubetype-gen) 工具，可以基于注释去自动创建 `Kubernetes`类型。该工具的注释和各种可用选项在 [README](https://github.com/istio/tools/blob/master/cmd/kubetype-gen/README.md) 中进行了说明。请注意，如果您使用 `protobuf` 工具生成 `Go` 类型，则需要将这些注释添加到 `proto` 文件中，以便注释出现在生成的 `Go` 文件中，然后供该工具使用。 * **生成 deep copy 方法** - 在 `Kubernetes` 客户端机制中，如果您想对从客户端集返回的任何对象进行修改，则需要创建该对象的副本以防止直接修改缓存中的对象。为了不直接修改缓存中的对象，我们一般是在所有嵌套类型上创建一个 `deep copy` 方法。我们开发了一个 [protoc deep copy diff --git a/content/zh/blog/2019/app-identity-and-access-adapter/index.md b/content/zh/blog/2019/app-identity-and-access-adapter/index.md index 02b1028dd4..a877a93b02 100644 --- a/content/zh/blog/2019/app-identity-and-access-adapter/index.md +++ b/content/zh/blog/2019/app-identity-and-access-adapter/index.md @@ -22,7 +22,7 @@ Istio 使用 [Envoy sidecar 代理] 来调整服务网格中所有 Pod 的入站 APP 身份和访问适配器通过分析针对服务网格上各种访问控制策略的遥测数据（属性）扩展 Mixer 的功能。访问控制策略可以关联到具体的 Kubernetes 服务，并且可以微调到特定的服务端点。关于策略和遥测信息的详情请看 Istio 的文档。 -当 [App 身份和访问适配器](https://github.com/ibm-cloud-security/app-identity-and-access-adapter) 结合到 Istio 中后，为多云架构提供可扩展的、集成身份和访问解决方案，而且不需要修改任何应用程序代码。 +当 [App 身份和访问适配器](https://github.com/ibm-cloud-security/app-identity-and-access-adapter)结合到 Istio 中后，为多云架构提供可扩展的、集成身份和访问解决方案，而且不需要修改任何应用程序代码。 ## 安装 {#installation} diff --git a/content/zh/blog/2019/appswitch/index.md b/content/zh/blog/2019/appswitch/index.md index 3d7cc41f39..5296b8865d 100644 --- a/content/zh/blog/2019/appswitch/index.md +++ b/content/zh/blog/2019/appswitch/index.md @@ -49,12 +49,12 @@ Istio 本身受依赖性排序问题版本的影响。由于在 Istio 下运行 AppSwitch 的核心能够使用 BSD Socket API 及其相关的其它调用（例如 `fcntl` 和 ioctl）来完成对 Socket 的处理。它的实现细节很有意思，但是为了防止偏离本文的主题，这里仅对其独特的关键属性进行一个总结。 （1）速度很快。它使用 `seccomp` 过滤和二进制检测的组合来积极地限制应用程序正常执行的干预。AppSwitch 特别适用于服务网格和应用程序网络用例，因为它实现了这些功能，而无需实际触摸数据。相反，网络级方法会导致每个数据包的成本。看看这个[博客](/zh/blog/2018/delayering-istio/)进行一些性能测量。 （2）它不需要任何内核支持，内核模块或补丁，可以在标准的发行版内核上运行 -（3）它可以作为普通用户运行（非 root）。事实上，该机制甚至可以通过删除对网络容器的根要求来运行 [非 root 的 Docker 守护进程](https://linuxpiter.com/en/materials/2478) +（3）它可以作为普通用户运行（非 root）。事实上，该机制甚至可以通过删除对网络容器的根要求来运行[非 root 的 Docker 守护进程](https://linuxpiter.com/en/materials/2478) （4）它可以不加更改的用于任何类型的应用程序上，适用于任何类型的应用程序 - 从 WebSphere ND 和 SAP 到自定义 C 应用程序，再到静态链接的 `Golang` 应用程序。Linux/x86 是仅有的运行需求。 ### 将服务与其引用分离{#decoupling-services-from-their-references} -AppSwitch 建立在应用程序应与其引用分离的基本前提之上。传统上，应用程序的标识源自它们运行的​​主机的标识。但是，应用程序和主机是需要独立引用的非常不同的对象。本 [主题](https://arxiv.org/abs/1711.02294)介绍了围绕此主题的详细讨论以及 AppSwitch 的概念基础。 +AppSwitch 建立在应用程序应与其引用分离的基本前提之上。传统上，应用程序的标识源自它们运行的​​ 主机的标识。但是，应用程序和主机是需要独立引用的非常不同的对象。本[主题](https://arxiv.org/abs/1711.02294)介绍了围绕此主题的详细讨论以及 AppSwitch 的概念基础。 实现服务对象及其身份之间解耦的中央 AppSwitch 构造是 _service reference_（简称 _reference_ ）。AppSwitch 基于上面概述的 API 检测机制实现服务引用。服务引用由 IP：端口对（以及可选的 DNS 名称）和标签选择器组成，标签选择器选择引用所代表的服务以及此引用所适用的客户端。引用支持一些关键属性。（1）它的名称可以独立于它所引用的对象的名称。也就是说，服务可能正在侦听 IP 和端口，但是引用允许在用户选择的任何其他 IP 和端口上达到该服务。这使 AppSwitch 能够运行从源环境中捕获的传统应用程序，通过静态 IP 配置在 Kubernetes 上运行，为其提供必要的 IP 地址和端口，而不管目标网络环境如何。（2）即使目标服务的位置发生变化，它也保持不变。引用自动重定向自身，因为其标签选择器现在解析为新的服务实例（3）对于此讨论最重要的是，在目标服务的启动过程中，引用就已经生效了。 @@ -72,9 +72,9 @@ AppSwitch 利用 BSD Socket API 的语义，确保服务引用从客户的角度 ### 为 Sidecar 提供服务引用的通配符支持{#wildcard-service-references-for-sidecar-dependency} -服务引用可用于解决前面提到的 Istio sidecar 依赖性问题。AppSwitch 用 IP：端口的方式来描述对服务的引用，这种描述中是可以使用通配符的。也就是说，服务引用描述中可以用IP 掩码的形式来表达要捕捉的 IP 地址的范围。如果服务引用的标签选择器指向 sidecar 服务，则应用此服务引用的任何应用程序的所有传出连接将被透明地重定向到 sidecar。当然，在 Sidecar 启动过程中，服务引用仍然是有效的。 +服务引用可用于解决前面提到的 Istio sidecar 依赖性问题。AppSwitch 用 IP：端口的方式来描述对服务的引用，这种描述中是可以使用通配符的。也就是说，服务引用描述中可以用 IP 掩码的形式来表达要捕捉的 IP 地址的范围。如果服务引用的标签选择器指向 sidecar 服务，则应用此服务引用的任何应用程序的所有传出连接将被透明地重定向到 sidecar。当然，在 Sidecar 启动过程中，服务引用仍然是有效的。 -使用 sidecar 依赖性排序的服务引用也隐式地将应用程序的连接重定向到 sidecar ，而不需要 iptables 和随之而来的权限问题。基本上它就像应用程序直接连接到 sidecar 而不是目标目的地一样工作，让 sidecar 负责做什么。AppSwitch 将使用 sidecar 可以在将连接传递到应用程序之前解码的代理协议将关于原始目的地等的元数据插入到连接的数据流中。其中一些细节已在 [此处](/zh/blog/2018/delayering-istio/) 进行了讨论。出站连接是这样处理的，那么入站连接呢？由于所有服务及其 sidecar 都在 AppSwitch 下运行，因此来自远程节点的任何传入连接都将被重定向到各自的远程 sidecar 。所以传入连接没有什么特别处理。 +使用 sidecar 依赖性排序的服务引用也隐式地将应用程序的连接重定向到 sidecar ，而不需要 iptables 和随之而来的权限问题。基本上它就像应用程序直接连接到 sidecar 而不是目标目的地一样工作，让 sidecar 负责做什么。AppSwitch 将使用 sidecar 可以在将连接传递到应用程序之前解码的代理协议将关于原始目的地等的元数据插入到连接的数据流中。其中一些细节已在[此处](/zh/blog/2018/delayering-istio/)进行了讨论。出站连接是这样处理的，那么入站连接呢？由于所有服务及其 sidecar 都在 AppSwitch 下运行，因此来自远程节点的任何传入连接都将被重定向到各自的远程 sidecar 。所以传入连接没有什么特别处理。 ## 总结{#summary} diff --git a/content/zh/blog/2019/custom-ingress-gateway/index.md b/content/zh/blog/2019/custom-ingress-gateway/index.md index ad8a6034da..17df1c4ae0 100644 --- a/content/zh/blog/2019/custom-ingress-gateway/index.md +++ b/content/zh/blog/2019/custom-ingress-gateway/index.md @@ -14,7 +14,7 @@ target_release: 1.0 ## 开始之前{#before-you-begin} -* 根据 [安装指南](/zh/docs/setup/) 完成 Istio 的部署。 +* 根据[安装指南](/zh/docs/setup/)完成 Istio 的部署。 * 用 Helm [Chart](https://github.com/helm/charts/tree/master/stable/cert-manager#installing-the-chart) 部署 `cert-manager`。 * 我们会使用 `demo.mydemo.com` 进行演示，因此你的 DNS 解析要能够解析这个域名。 @@ -37,7 +37,7 @@ target_release: 1.0 1. 要创建集群的证书签发者，可以使用如下的配置： {{< tip >}} - 用自己的配置修改集群的 [证书签发者](https://cert-manager.readthedocs.io/en/latest/reference/issuers.html)。例子中使用的是 `route53`。 + 用自己的配置修改集群的[证书签发者](https://cert-manager.readthedocs.io/en/latest/reference/issuers.html)。例子中使用的是 `route53`。 {{< /tip >}} {{< text yaml >}} @@ -127,7 +127,7 @@ target_release: 1.0 desiredReplicas: 1 {{< /text >}} -1. 使用 [附件 YAML 中的定义](/zh/blog/2019/custom-ingress-gateway/deployment-custom-ingress.yaml)进行部署。 +1. 使用[附件 YAML 中的定义](/zh/blog/2019/custom-ingress-gateway/deployment-custom-ingress.yaml)进行部署。 {{< tip >}} 其中类似 `aws-load-balancer-type` 这样的注解，只对 AWS 生效。 @@ -229,4 +229,4 @@ target_release: 1.0 SSL certificate verify ok. {{< /text >}} -**恭喜你！** 现在你可以使用自定义的 `istio-custom-gateway` [网关](/zh/docs/reference/config/networking/gateway/) 对象了。 \ No newline at end of file +**恭喜你！** 现在你可以使用自定义的 `istio-custom-gateway` [网关](/zh/docs/reference/config/networking/gateway/)对象了。 diff --git a/content/zh/blog/2019/data-plane-setup/index.md b/content/zh/blog/2019/data-plane-setup/index.md index e2224bd669..d0ebf0da20 100644 --- a/content/zh/blog/2019/data-plane-setup/index.md +++ b/content/zh/blog/2019/data-plane-setup/index.md @@ -10,7 +10,7 @@ target_release: 1.0 --- Istio 服务网格体系结构的简单概述总是从控制平面和数据平面开始。 -从 [Istio 的文档](/zh/docs/ops/deployment/architecture/): +从 [Istio 的文档](/zh/docs/ops/deployment/architecture/) : {{< quote >}} Istio 服务网格在逻辑上分为数据平面和控制平面。 @@ -33,7 +33,7 @@ Istio 服务网格在逻辑上分为数据平面和控制平面。 简单来说，Sidecar 注入会将额外容器的配置添加到 Pod 模板中。Istio 服务网格目前所需的容器有： `istio-init` -[init 容器](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) 用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同： +[init 容器](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同： - 它在启动应用容器之前运行，并一直运行直至完成。 - 如果有多个初始化容器，则每个容器都应在启动下一个容器之前成功完成。 @@ -41,7 +41,7 @@ Istio 服务网格在逻辑上分为数据平面和控制平面。 因此，您可以看到，对于不需要成为实际应用容器一部分的设置或初始化作业来说，这种容器是多么的完美。在这种情况下，`istio-init` 就是这样做并设置了 `iptables` 规则。 `istio-proxy` -这个容器是真正的 sidecar 代理（基于Envoy）。 +这个容器是真正的 sidecar 代理（基于 Envoy）。 ### 手动注入{#manual-injection} @@ -306,7 +306,7 @@ spec: - 默认策略（在 ConfigMap `istio-sidecar-injector` 中配置） - 每个 pod 的重载注解（`sidecar.istio.io/inject`） -[注入状态表](/zh/docs/ops/common-problems/injection/) 根据上述变量的值清晰显示了最终注入状态。 +[注入状态表](/zh/docs/ops/common-problems/injection/)根据上述变量的值清晰显示了最终注入状态。 ## 从应用容器到 Sidecar 代理的流量{#traffic-flow-from-application-container-to-sidecar-proxy} diff --git a/content/zh/blog/2019/egress-performance/index.md b/content/zh/blog/2019/egress-performance/index.md index 0a635e3059..f9316b18a7 100644 --- a/content/zh/blog/2019/egress-performance/index.md +++ b/content/zh/blog/2019/egress-performance/index.md @@ -8,7 +8,7 @@ keywords: [performance,traffic-management,egress,mongo] target_release: 1.0 --- -为了从网格中访问外部服务（本例中使用的是 MongoDB），需要加入 Egress gateway，本次测试的主要目的就是调查这一行为对性能和资源使用造成的影响。在博客 [使用外部 MongoDB 服务](/zh/blog/2018/egress-mongo/) 中介绍了为外部 MongoDB 配置 Egress gateway 的具体步骤。 +为了从网格中访问外部服务（本例中使用的是 MongoDB），需要加入 Egress gateway，本次测试的主要目的就是调查这一行为对性能和资源使用造成的影响。在博客[使用外部 MongoDB 服务](/zh/blog/2018/egress-mongo/)中介绍了为外部 MongoDB 配置 Egress gateway 的具体步骤。 本次测试中使用的应用是 Acmeair 的 Java 版，这个应用会模拟一个航空订票系统。在 Istio 的每日构建中会使用该应用来进行性能的回归测试，但是在回归测试过程中，这些应用会使用自己的 Sidecar 来访问外部的 MongoDB，而不是 Egress gateway。 @@ -118,4 +118,4 @@ target_release: 1.0 ## 结论{#conclusion} -在这一系列的测试之中，我们用不同的方式来访问一个启用了 TLS 的 MongoDB 来进行性能对比。Egress gateway 的引用没有对性能和 CPU 消耗的显著影响。但是启用了 Sidecar 和 Egress gateway 之间的双向 TLS 或者为通配符域名使用了额外的 SNI 代理之后，会看到性能降级的现象。 \ No newline at end of file +在这一系列的测试之中，我们用不同的方式来访问一个启用了 TLS 的 MongoDB 来进行性能对比。Egress gateway 的引用没有对性能和 CPU 消耗的显著影响。但是启用了 Sidecar 和 Egress gateway 之间的双向 TLS 或者为通配符域名使用了额外的 SNI 代理之后，会看到性能降级的现象。 diff --git a/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md b/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md index cc89879003..503fd7a259 100644 --- a/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md +++ b/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md @@ -39,7 +39,7 @@ _1.3.4 不允许持卡人数据环境没有授权的出站流量进入互联网 出口流量安全管控的意思是监控出口流量并且针对出口流量应用所有的安全策略。 监控出口流量，可以对它进行分析（可能是离线的），即便你无法实时阻止攻击，也要检测攻击事件。 -另外一个减少攻击可能性的方法是遵循[需要知道](https://en.wikipedia.org/wiki/Need_to_know#In_computer_technology]) 的原则进行指定限制访问策略。 +另外一个减少攻击可能性的方法是遵循[需要知道](https://en.wikipedia.org/wiki/Need_to_know#In_computer_technology])的原则进行指定限制访问策略。 现在来看看已经收集到的出口流量管控要求。 @@ -82,7 +82,7 @@ Istio 1.1 满足所有的收集要求： 第三个要求指出：Istio 运维人员必须能为整个集群所有的出口流量定规策略。策略指出集群中的 pod 可能会访问哪些外部服务。外部服务可以通过服务的[全域名](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) （比如 `www.ibm.com`）或者泛域名（比如：`*.ibm.com`）进行标示。只有指定的外部服务可以访问，其它所有的出口流量都要被阻止。 -这个要求是为了阻止攻击者访问恶意站点而提出的，比如下载更新/操作他们的恶意软件。同样也想去限制攻击者可以访问和攻击的外部站点的数量。只允许集群内应用程序需要访问的外部站点并且阻止其它所拥有的服务访问，这样减少了[攻击面](https://en.wikipedia.org/wiki/Attack_surface)。当外部服务有了它们自己的安全机制，你想使用[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 并且使用多个安全层：除了外部系统的安全层外，集群内还有一个安全层。 +这个要求是为了阻止攻击者访问恶意站点而提出的，比如下载更新/操作他们的恶意软件。同样也想去限制攻击者可以访问和攻击的外部站点的数量。只允许集群内应用程序需要访问的外部站点并且阻止其它所拥有的服务访问，这样减少了[攻击面](https://en.wikipedia.org/wiki/Attack_surface)。当外部服务有了它们自己的安全机制，你想使用[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))并且使用多个安全层：除了外部系统的安全层外，集群内还有一个安全层。 这个要求意味着外部服务必须能用域名来标示。我们把出口管控系统的这个特性叫做 DNS 感知。如果系统不是 DNS 可感知的，外部服务必须用 IP 地址标示。 使用 IP 地址不方便而且经常不灵活，因为服务的 IP 地址会变的。有时候服务的所有 IP 地址甚至都不知道，比如：[CDN](https://en.wikipedia.org/wiki/Content_delivery_network)。 @@ -98,4 +98,4 @@ Istio 1.1 满足所有的收集要求： ## 总结 {#summary} -希望您确信对于集群安全来说出口流量管控是非常重要的。在[这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/) 我讲述了使用 Istio 实现出口流量安全管控的方法。在[这个系列文章的第三部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/) 我和其它方案进行了对比，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)以及已有的其它出口代理/防火墙方案。 +希望您确信对于集群安全来说出口流量管控是非常重要的。在[这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/)我讲述了使用 Istio 实现出口流量安全管控的方法。在[这个系列文章的第三部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/)我和其它方案进行了对比，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)以及已有的其它出口代理/防火墙方案。 diff --git a/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md b/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md index c2dce36e0f..de340939a8 100644 --- a/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md +++ b/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md @@ -9,7 +9,7 @@ target_release: 1.2 --- 欢迎来看 Istio 对出口流量进行安全管控系列文章的第 2 部分。 -在[这个系列文章的第一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-1/),我提出了出口流量相关攻击和针对出口流量进行安全管控我们收集的要求点。 +在[这个系列文章的第一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-1/), 我提出了出口流量相关攻击和针对出口流量进行安全管控我们收集的要求点。 在这一期中，我会讲述对出口流量进行安全管控的 Istio 方式，并且展示 Istio 如何帮你阻止攻击。 ## Istio 中的出口流量安全管控 {#secure-control-of-egress-traffic-in-Istio} @@ -23,7 +23,7 @@ target_release: 1.2 如果应用程序发送 HTTP 请求，并且由出口网关发起执行 TLS，你就可以监控 HTTP 信息，像 HTTP 方法、HTTP 头和 URL 路径。也可以根据上面说的 HTTP 信息来[定义策略](/zh/blog/2018/egress-monitoring-access-control)。如果是由应用程序发起执行 TLS，你就可以对源 pod 的 TLS 流量的 [SNI 和服务账号进行监控](/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/)，并且基于 SNI 和服务账号定义策略。 你必须确保你集群到外部的流量不能绕过出口网关。Istio 不能给你确保这一点，所以你必需使用一些[附加的安全机制](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)或者 L3 防火墙。 看一个 [Kubernetes 网络策略配置](/zh/docs/tasks/traffic-management/egress/egress-gateway/#apply-Kubernetes-network-policies)的例子。 -根据[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 的概念，为同一个目标使用的安全机制越多越安全。 +根据[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))的概念，为同一个目标使用的安全机制越多越安全。 你也必需也要确保 Istio 控制平面和出口网关不能被破坏。你的集群里面可能有成百上千的应用程序 pod，而只有十几个 Istio 控制平面 pod 和网关。 你可以也应该聚焦在保护控制平面 pod 和网关，因为这比较容易（需要保护的 pod 数量很少），并且这对集群的安全性是最关键的。 diff --git a/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md b/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md index d67c916f03..6923e62c21 100644 --- a/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md +++ b/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md @@ -101,4 +101,4 @@ Istio 是我所知的唯一解决方案，它可以让你： 以我之见，如果你在寻找你的第一个 Istio 应用场景，安全管控出口流量是一个非常好的选择。在这个场景中，Istio 甚至在你使用它所有其它功能之前就已经为你提供了一些优势： [流量管理](/zh/docs/tasks/traffic-management/)，[安全性](/zh/docs/tasks/security/)，[策略](/zh/docs/tasks/policy-enforcement/)和[可观测性](/zh/docs/tasks/observability/)，上面的功能都可以用在在集群内的微服务之间的流量上。 -所以，如果你还没有机会使用 Istio，那就在你集群上[安装 Istio](/zh/docs/setup/install/) 并且检查[出口流量管控任务](/zh/docs/tasks/traffic-management/egress/) 再执行其它 [Istio 特性](/zh/docs/tasks/)的任务。我们也想收到你的反馈，请在[discuss.istio.io](https://discuss.istio.io)加入我们。 +所以，如果你还没有机会使用 Istio，那就在你集群上[安装 Istio](/zh/docs/setup/install/) 并且检查[出口流量管控任务](/zh/docs/tasks/traffic-management/egress/)再执行其它 [Istio 特性](/zh/docs/tasks/)的任务。我们也想收到你的反馈，请在 [discuss.istio.io](https://discuss.istio.io) 加入我们。 diff --git a/content/zh/blog/2019/evolving-istios-apis/index.md b/content/zh/blog/2019/evolving-istios-apis/index.md index dff7d824e6..378253ea26 100644 --- a/content/zh/blog/2019/evolving-istios-apis/index.md +++ b/content/zh/blog/2019/evolving-istios-apis/index.md @@ -20,7 +20,7 @@ Istio API 进化的下一步重心是在 Istio 用户的角色上。一个安全 1. Istio API 应该寻求： - 正确地表示他们映射到的基础资源 - 不应该隐藏任何基础资源的有用功能 -1. Istio API 也应该是 [可组合的](https://en.wikipedia.org/wiki/Composability)，因此终端用户能以适合其自身需求的方式组合基础 API。 +1. Istio API 也应该是[可组合的](https://en.wikipedia.org/wiki/Composability)，因此终端用户能以适合其自身需求的方式组合基础 API。 1. Istio API 也应该是灵活的：在一个组织内部，应该有可能对基础资源有不同的表现形式，并且对每个团队都有意义。 在接下来的几个版本中，我们将分享我们的进展，我们将加强 Istio API 与 Istio 用户角色之间的一致性。 @@ -35,11 +35,11 @@ Kubernetes 可组合性的一个具体示例是部署应用时有一系列的对 可以在 [Google Cloud HTTP(S) Load Balancer](https://cloud.google.com/load-balancing/docs/https/) (GCLB) 找到网络空间可组合性的另一个例子。要正确使用 GCLB 的一个实例，需要创建和配置 6 个不同的基础对象。这样的设计是我们操作分布式系统 20 年经验的一个结果，并且[为什么每一个对象和其他对象相互独立是有原因的](https://www.youtube.com/watch?v=J5HJ1y6PeyE)。但你通过 Google Cloud 控制台创建一个实例的步骤是被简化过的。我们提供越多的通用的面向终端用户/以角色为中心的配置，以后你们配置的通用设置越少。最终，基础 API 的目标是在不牺牲功能的情况下提供最大的灵活性。 -[Knative](http://knative.dev) 是一个创建、运行并且操作无服务器工作负载的平台，它提供了一个以角色为中心的现实世界绝佳的示例，更高层次的 API。[Knative Serving](https://knative.dev/docs/serving/)，Knative 的一个组件，基于 Kubernetes 和 Istio 服务于无服务器应用和功能，为应用开发人员管理服务的路由和修订提供了一个稳定的工作流。由于采用这种稳定的方式，Knative Serving 将 Istio 的 [`VirtualService`](/zh/docs/reference/config/networking/virtual-service/) 和 [`DestinationRule`](/zh/docs/reference/config/networking/destination-rule/) 资源，抽象成一个简化的支持修订和流量路由的 [路由](https://github.com/knative/docs/blob/master/docs/serving/spec/knative-api-specification-1.0.md#route) 对象，将与应用开发人员最紧密相关的 Istio 网络 API 的一个子集暴露出来。 +[Knative](http://knative.dev) 是一个创建、运行并且操作无服务器工作负载的平台，它提供了一个以角色为中心的现实世界绝佳的示例，更高层次的 API。[Knative Serving](https://knative.dev/docs/serving/)，Knative 的一个组件，基于 Kubernetes 和 Istio 服务于无服务器应用和功能，为应用开发人员管理服务的路由和修订提供了一个稳定的工作流。由于采用这种稳定的方式，Knative Serving 将 Istio 的 [`VirtualService`](/zh/docs/reference/config/networking/virtual-service/) 和 [`DestinationRule`](/zh/docs/reference/config/networking/destination-rule/) 资源，抽象成一个简化的支持修订和流量路由的[路由](https://github.com/knative/docs/blob/master/docs/serving/spec/knative-api-specification-1.0.md#route)对象，将与应用开发人员最紧密相关的 Istio 网络 API 的一个子集暴露出来。 随着 Istio 的成熟，我们还看到生产用户在 Istio 的基础 API 之上开发了针对特定工作负载和组织的抽象层。 -AutoTrader UK 提供了一个基于 Istio 定制平台的我们最喜欢的例子。在 [来自 Google 的 Kubernetes Podcast 的一个采访](https://kubernetespodcast.com/episode/052-autotrader/) 中，Russel Warman 和 Karl Stoney 描述了他们基于 Kubernetes 的交付平台，和 [用 Prometheus 和 Grafana 搭建的成本 Dashboard](https://karlstoney.com/2018/07/07/managing-your-costs-on-kubernetes/)。他们毫不费力地添加了配置项使网络达到他们的开发人员希望配置成的样子，并且现在它管理着的 Istio 的对象让这一切成为可能。在企业和云原生公司中构建了无数其他的平台：一些旨在替换公司特定的自定义脚本的网络，而另一些旨在成为通用的公共工具。随着越来越多的公司开始公开谈论他们的工具，我们将把他们的故事带到此博客。 +AutoTrader UK 提供了一个基于 Istio 定制平台的我们最喜欢的例子。在[来自 Google 的 Kubernetes Podcast 的一个采访](https://kubernetespodcast.com/episode/052-autotrader/)中，Russel Warman 和 Karl Stoney 描述了他们基于 Kubernetes 的交付平台，和[用 Prometheus 和 Grafana 搭建的成本 Dashboard](https://karlstoney.com/2018/07/07/managing-your-costs-on-kubernetes/)。他们毫不费力地添加了配置项使网络达到他们的开发人员希望配置成的样子，并且现在它管理着的 Istio 的对象让这一切成为可能。在企业和云原生公司中构建了无数其他的平台：一些旨在替换公司特定的自定义脚本的网络，而另一些旨在成为通用的公共工具。随着越来越多的公司开始公开谈论他们的工具，我们将把他们的故事带到此博客。 ## 接下来会发生什么{#what’s-coming-next} diff --git a/content/zh/blog/2019/introducing-istio-operator/index.md b/content/zh/blog/2019/introducing-istio-operator/index.md index a3e2a50853..3ec51f5c3c 100644 --- a/content/zh/blog/2019/introducing-istio-operator/index.md +++ b/content/zh/blog/2019/introducing-istio-operator/index.md @@ -17,13 +17,13 @@ Kubernetes [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/oper - 不在 API 中的小型定制不需要更改 chart 或 API - 版本特定的升级 hook 可以很容易和稳健地实现 -[Helm 安装](/zh/docs/setup/install/helm/)方法正在弃用中。从 Istio 1.4 升级到一个默认没有安装 Helm 的版本也会被一个新的[{{< istioctl >}} 升级特性](/zh/docs/setup/upgrade/istioctl-upgrade/)所取代。 +[Helm 安装](/zh/docs/setup/install/helm/)方法正在弃用中。从 Istio 1.4 升级到一个默认没有安装 Helm 的版本也会被一个新的 [{{< istioctl >}} 升级特性](/zh/docs/setup/upgrade/istioctl-upgrade/)所取代。 新的 `istioctl` 安装命令使用一个[自定义资源](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)来配置安装。自定义资源是新的 Istio operator 实现的一部分，该实现旨在简化安装、升级和复杂的 Istio 配置更改等常见管理任务。安装和升级的验证和检查与工具紧密集成，以防止常见错误并简化故障排除。 ## Operator API{#the-Operator-API} -每个 operator 实现都需要一个[自定义资源定义（CRD）](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) 来定义它的自定义资源，即它的API。Istio 的 operator API 由 [`IstioControlPlane` CRD](/zh/docs/reference/config/istio.operator.v1alpha12.pb/) 定义，它是由一个 [`IstioControlPlane` 原型](https://github.com/istio/operator/blob/release-1.4/pkg/apis/istio/v1alpha2/istiocontrolplane_types.proto)生成的。API 支持所有 Istio 当前的[配置文件](/zh/docs/setup/additional-setup/config-profiles/) ，通过使用一个字段来选择 profile。例如，下面的 `IstioControlPlane` 资源使用 `demo` profile 配置 Istio： +每个 operator 实现都需要一个[自定义资源定义（CRD）](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) 来定义它的自定义资源，即它的 API。Istio 的 operator API 由 [`IstioControlPlane` CRD](/zh/docs/reference/config/istio.operator.v1alpha12.pb/) 定义，它是由一个 [`IstioControlPlane` 原型](https://github.com/istio/operator/blob/release-1.4/pkg/apis/istio/v1alpha2/istiocontrolplane_types.proto)生成的。API 支持所有 Istio 当前的[配置文件](/zh/docs/setup/additional-setup/config-profiles/) ，通过使用一个字段来选择 profile。例如，下面的 `IstioControlPlane` 资源使用 `demo` profile 配置 Istio： {{< text yaml >}} apiVersion: install.istio.io/v1alpha2 @@ -114,7 +114,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true 你也可以在一个 `IstioControlPlane` 自定义资源中设置 Helm 配置值。参见[使用 Helm 自定义 Istio 设置](/zh/docs/setup/install/istioctl/#customize-Istio-settings-using-the-helm-API)。 -另一个可以帮助从 Helm 迁移的特性是这个 alpha 命令：[{{< istioctl >}} manifest migrate](/zh/docs/reference/commands/istioctl/#istioctl-manifest-migrate)。此命令可用于将Helm `values.yaml` 文件自动转换为相应的 `IstioControlPlane` 配置。 +另一个可以帮助从 Helm 迁移的特性是这个 alpha 命令：[{{< istioctl >}} manifest migrate](/zh/docs/reference/commands/istioctl/#istioctl-manifest-migrate)。此命令可用于将 Helm `values.yaml` 文件自动转换为相应的 `IstioControlPlane` 配置。 ## 实现{#implementation} diff --git a/content/zh/blog/2019/isolated-clusters/index.md b/content/zh/blog/2019/isolated-clusters/index.md index 2a92128e76..b44c4f71d8 100644 --- a/content/zh/blog/2019/isolated-clusters/index.md +++ b/content/zh/blog/2019/isolated-clusters/index.md @@ -29,7 +29,7 @@ target_release: 1.3 ## 隔离和边界保护{#isolation-and-boundary-protection} -隔离和边界保护机制在 [NIST 特殊出版物 800-53，修订4，联邦信息系统和组织的安全和隐私控制](http://dx.doi.org/10.6028/NIST.SP.800-53r4)，_附录 F，安全控制目录，SC-7 边界保护中进行了说明_。 +隔离和边界保护机制在 [NIST 特殊出版物 800-53，修订 4，联邦信息系统和组织的安全和隐私控制](http://dx.doi.org/10.6028/NIST.SP.800-53r4)，_附录 F，安全控制目录，SC-7 边界保护中进行了说明_。 特别是 _边界保护，隔离信息系统组件_ 控制增强： @@ -37,7 +37,7 @@ target_release: 1.3 组织可以隔离执行不同任务和/或业务功能的信息系统组件。这种隔离限制了系统组件之间未经授权的信息流，并且还提供了为所选组件部署更高级别的保护的机会。使用边界保护机制将系统组件分开提供了增强对单个组件的保护并更有效地控制这些组件之间的信息流的能力。这种类型的增强保护可限制网络攻击和错误带来的潜在危害。提供的分离程度取决于所选的机制。边界保护机制包括，路由器、网关和防火墙等，将系统组件分离为物理上分离的网络或子网；跨域设备将子网分离；虚拟化技术；以及使用不同的加密密钥对系统组件之间的信息流进行加密。 {{< /quote >}} -各种合规性标准隔离建议，用于处理组织其余部分的敏感数据的环境。[支付卡行业（PCI）数据安全标准](https://www.pcisecuritystandards.org/pci_security/)建议为 _持卡人数据_ 环境实现网络隔离，并要求将此环境与 [DMZ](https://en.wikipedia.org/wiki/DMZ_(computing)) 隔离。[FedRAMP 边界授权指南](https://www.fedramp.gov/assets/resources/documents/CSP_A_FedRAMP_Authorization_Boundary_Guidance.pdf) 描述了联邦信息和数据的 _授权边界_，而 [NIST 特别出版物 800-37，修订版 2，信息系统和组织的风险管理框架：用于安全性和隐私的系统生命周期方法](https://doi.org/10.6028/NIST.SP.800-37r2) _附录 G，授权边界注意事项_ 建议保护这样的边界： +各种合规性标准隔离建议，用于处理组织其余部分的敏感数据的环境。[支付卡行业（PCI）数据安全标准](https://www.pcisecuritystandards.org/pci_security/)建议为 _持卡人数据_ 环境实现网络隔离，并要求将此环境与 [DMZ](https://en.wikipedia.org/wiki/DMZ_(computing)) 隔离。[FedRAMP 边界授权指南](https://www.fedramp.gov/assets/resources/documents/CSP_A_FedRAMP_Authorization_Boundary_Guidance.pdf)描述了联邦信息和数据的 _授权边界_，而 [NIST 特别出版物 800-37，修订版 2，信息系统和组织的风险管理框架：用于安全性和隐私的系统生命周期方法](https://doi.org/10.6028/NIST.SP.800-37r2) _附录 G，授权边界注意事项_ 建议保护这样的边界： {{< quote >}} 将系统划分为子系统（即分而治之）有助于针对性地应用控制措施，以实现足够的安全性，保护个人隐私和具有成本效益的风险管理流程。将复杂的系统划分为子系统也支持域分离和网络分段的重要安全概念，这在处理高价值资产时可能非常重要。将系统划分为子系统时，组织可以选择制定单独的子系统安全和隐私计划，也可以选择在相同的安全和隐私计划中处理系统和子系统。 diff --git a/content/zh/blog/2019/monitoring-external-service-traffic/index.md b/content/zh/blog/2019/monitoring-external-service-traffic/index.md index f4333def57..bfdc1acb3d 100644 --- a/content/zh/blog/2019/monitoring-external-service-traffic/index.md +++ b/content/zh/blog/2019/monitoring-external-service-traffic/index.md @@ -25,9 +25,9 @@ Istio 控制平面使用了预定义集群 BlackHoleCluster 和 Passthrough 来 例如，在 Kubernetes 集群中，Istio 会为所有 Kubernetes 服务配置 sidecar，以保留所有能够与其他服务通信的服务的默认 Kubernetes 行为。 外部服务是不属于平台的服务，即不在网格内的服务。 -对于外部服务，Istio提供了两个选项，一个是阻止所有外部服务访问（通过将 `global.outboundTrafficPolicy.mode` 设置 -为 `REGISTRY_ONLY` 启用）,另一个是允许所有对外部服务的访问（通过将 `global.outboundTrafficPolicy.mode` 设置为 `ALLOW_ANY` 启用）。 -从Istio 1.3开始，此设置的默认选项是允许所有外部服务访问。此选项可以通过[网格配置](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-Mode)进行配置。 +对于外部服务，Istio 提供了两个选项，一个是阻止所有外部服务访问（通过将 `global.outboundTrafficPolicy.mode` 设置 +为 `REGISTRY_ONLY` 启用）, 另一个是允许所有对外部服务的访问（通过将 `global.outboundTrafficPolicy.mode` 设置为 `ALLOW_ANY` 启用）。 +从 Istio 1.3 开始，此设置的默认选项是允许所有外部服务访问。此选项可以通过[网格配置](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-Mode)进行配置。 这就是使用 BlackHole 和 Passthrough 集群的地方。 @@ -71,7 +71,7 @@ Istio 控制平面使用了预定义集群 BlackHoleCluster 和 Passthrough 来 } {{< /text >}} - 该路由被设置为响应码是 502 的 [直接响应](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route_components.proto#envoy-api-field-route-route-direct-response)，这意味着如果没有其他路由匹配，则 Envoy 代理将直接返回 502 HTTP 状态代码。 + 该路由被设置为响应码是 502 的[直接响应](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route_components.proto#envoy-api-field-route-route-direct-response)，这意味着如果没有其他路由匹配，则 Envoy 代理将直接返回 502 HTTP 状态代码。 * **PassthroughCluster** - 当将 `global.outboundTrafficPolicy.mode` 设置为 `ALLOW_ANY` 时， PassthroughCluster 是在 Envoy 配置中创建的虚拟集群。在此模式下，允许流向外部服务的所有流量。 diff --git a/content/zh/blog/2019/multicluster-version-routing/index.md b/content/zh/blog/2019/multicluster-version-routing/index.md index 6387912544..5fc2463d3b 100644 --- a/content/zh/blog/2019/multicluster-version-routing/index.md +++ b/content/zh/blog/2019/multicluster-version-routing/index.md @@ -8,11 +8,11 @@ keywords: [traffic-management,multicluster] target_release: 1.0 --- -如果花一点时间对 Istio 进行了解，你可能会注意到，大量的功能都可以在单一的 Kubernetes 集群中，用简单的 [任务](/zh/docs/tasks) 和 [示例](/zh/docs/examples/) 所表达的方式来运行。但是真实世界中的云计算和基于微服务的应用往往不是这么简单的，会需要在不止一个地点分布运行，用户难免会产生怀疑，生产环境中是否还能这样运行？ +如果花一点时间对 Istio 进行了解，你可能会注意到，大量的功能都可以在单一的 Kubernetes 集群中，用简单的[任务](/zh/docs/tasks)和[示例](/zh/docs/examples/)所表达的方式来运行。但是真实世界中的云计算和基于微服务的应用往往不是这么简单的，会需要在不止一个地点分布运行，用户难免会产生怀疑，生产环境中是否还能这样运行？ -幸运的是，Istio 提供了多种服务网格的配置方式，应用能够用近乎透明的方式加入一个跨越多个集群运行的服务网格之中，也就是 [多集群服务网格](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 。最简单的设置多集群网格的方式，就是使用 [多控制平面拓扑](/zh/docs/ops/deployment/deployment-models/#control-plane-models) ，这种方式不需要特别的网络依赖。在这种条件下，每个 Kubernetes 集群都有自己的控制平面，但是每个控制平面都是同步的，并接受统一的管理。 +幸运的是，Istio 提供了多种服务网格的配置方式，应用能够用近乎透明的方式加入一个跨越多个集群运行的服务网格之中，也就是[多集群服务网格](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 。最简单的设置多集群网格的方式，就是使用[多控制平面拓扑](/zh/docs/ops/deployment/deployment-models/#control-plane-models) ，这种方式不需要特别的网络依赖。在这种条件下，每个 Kubernetes 集群都有自己的控制平面，但是每个控制平面都是同步的，并接受统一的管理。 -本文中，我们会在多控制平面拓扑形式的多集群网格中尝试一下 Istio 的 [流量管理](/zh/docs/concepts/traffic-management/) 功能。我们会展示如何配置 Istio 路由规则，在多集群服务网格中部署 [Bookinfo 示例]({{}}/samples/bookinfo)，`reviews` 服务的 `v1` 版本运行在一个集群上，而 `v2` 和 `v3` 运行在另一个集群上，并完成远程服务调用。 +本文中，我们会在多控制平面拓扑形式的多集群网格中尝试一下 Istio 的[流量管理](/zh/docs/concepts/traffic-management/)功能。我们会展示如何配置 Istio 路由规则，在多集群服务网格中部署 [Bookinfo 示例]({{}}/samples/bookinfo)，`reviews` 服务的 `v1` 版本运行在一个集群上，而 `v2` 和 `v3` 运行在另一个集群上，并完成远程服务调用。 ## 集群部署 {#setup-clusters} @@ -250,7 +250,7 @@ EOF ## 在 `cluster1` 上为远端的 `reviews` 服务创建 `ServiceEntry` 以及 `DestinationRule` -根据 [配置指南](/zh/docs/setup/install/multicluster/gateways/#setup-DNS) 中的介绍，远程服务可以用一个 `.global` 的 DNS 名称进行访问。在我们的案例中，就是 `reviews.default.global`，所以我们需要为这个主机创建 `ServiceEntry` 和 `DestinationRule`。`ServiceEntry` 会使用 `cluster2` 网关作为端点地址来访问服务。可以使用网关的 DNS 名称或者公共 IP： +根据[配置指南](/zh/docs/setup/install/multicluster/gateways/#setup-DNS)中的介绍，远程服务可以用一个 `.global` 的 DNS 名称进行访问。在我们的案例中，就是 `reviews.default.global`，所以我们需要为这个主机创建 `ServiceEntry` 和 `DestinationRule`。`ServiceEntry` 会使用 `cluster2` 网关作为端点地址来访问服务。可以使用网关的 DNS 名称或者公共 IP： {{< text bash >}} $ export CLUSTER2_GW_ADDR=$(kubectl get --context=$CTX_CLUSTER2 svc --selector=app=istio-ingressgateway \ @@ -302,7 +302,7 @@ spec: EOF {{< /text >}} -`ServiceEntry` 的地址 `240.0.0.3` 可以是任意的未分配 IP。在 `240.0.0.0/4` 的范围里面进行选择是个不错的主意。阅读 [通过网关进行连接的多集群](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services) 一文，能够获得更多相关信息。 +`ServiceEntry` 的地址 `240.0.0.3` 可以是任意的未分配 IP。在 `240.0.0.0/4` 的范围里面进行选择是个不错的主意。阅读[通过网关进行连接的多集群](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services)一文，能够获得更多相关信息。 注意 `DestinationRule` 中的 `subset` 的标签，`cluster: cluster2` 对应的是 `cluster2` 网关。一旦流量到达目标集群，就会由本地目的 `DestinationRule` 来鉴别实际的 Pod 标签（`version: v1` 或者 `version: v2`） diff --git a/content/zh/blog/2019/performance-best-practices/index.md b/content/zh/blog/2019/performance-best-practices/index.md index d8a9d21acf..2edf4f706c 100644 --- a/content/zh/blog/2019/performance-best-practices/index.md +++ b/content/zh/blog/2019/performance-best-practices/index.md @@ -10,19 +10,19 @@ keywords: [performance,scalability,scale,benchmarks] 服务网格为应用部署增加了很多功能，包括[流量策略](/zh/docs/concepts/what-is-istio/#traffic-management)、[可观察性](/zh/docs/concepts/what-is-istio/#observability)和[安全通信](/zh/docs/concepts/what-is-istio/#security)。但是，无论是时间（增加的延迟）还是资源（CPU 周期），向环境中添加服务网格都是有代价的。要就服务网格是否适合您的情况做出明智的决定，评估应用与服务网格一起部署时的性能非常重要。 -今年早些时候，我们发布了关于 Istio 1.1 性能改进的 [博客](/zh/blog/2019/istio1.1_perf/)。在发布 [Istio 1.2](/zh/news/releases/1.2.x/announcing-1.2) 之后，我们希望提供指导和工具，以帮助您在可用于生产的 Kubernetes 环境中对 Istio 的数据平面性能进行基准测试。 +今年早些时候，我们发布了关于 Istio 1.1 性能改进的[博客](/zh/blog/2019/istio1.1_perf/)。在发布 [Istio 1.2](/zh/news/releases/1.2.x/announcing-1.2) 之后，我们希望提供指导和工具，以帮助您在可用于生产的 Kubernetes 环境中对 Istio 的数据平面性能进行基准测试。 -总体而言，我们发现 Istio [sidecar 代理](/zh/docs/ops/deployment/architecture/#envoy) 的延迟取决于并发连接数。以每秒 1000 个请求（RPS）的速度，通过 16 个连接，Istio 延迟在 50% 时增加 **3 毫秒**，在 99% 时增加 **10 毫秒**。 +总体而言，我们发现 Istio [sidecar 代理](/zh/docs/ops/deployment/architecture/#envoy)的延迟取决于并发连接数。以每秒 1000 个请求（RPS）的速度，通过 16 个连接，Istio 延迟在 50% 时增加 **3 毫秒**，在 99% 时增加 **10 毫秒**。 -在[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)。 +在 [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} -为了准确地大规模度量服务网格的性能，使用 [适当大小的](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install#istio-setup) Kubernetes 集群很重要。我们使用三个工作节点进行测试，每个工作节点至少具有 4 vCPU 和 15 GB 的内存。 +为了准确地大规模度量服务网格的性能，使用[适当大小的](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install#istio-setup) Kubernetes 集群很重要。我们使用三个工作节点进行测试，每个工作节点至少具有 4 vCPU 和 15 GB 的内存。 -然后，在该群集上使用可用于生产的 Istio **安装配置文件** 很重要。这使我们能够实现面向性能的设置，例如控制平面 pod 自动伸缩，并确保资源限制适用于繁重的流量负荷。[默认](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template) Istio 安装适用于大多数基准测试用例。为了进行广泛的性能基准测试，并提供数千种注入代理的服务，我们还提供了 [调整后的 Istio 安装](https://github.com/istio/tools/blob/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install/values.yaml)，可为 Istio 控制平面分配额外的内存和 CPU。 +然后，在该群集上使用可用于生产的 Istio **安装配置文件** 很重要。这使我们能够实现面向性能的设置，例如控制平面 pod 自动伸缩，并确保资源限制适用于繁重的流量负荷。[默认](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template) Istio 安装适用于大多数基准测试用例。为了进行广泛的性能基准测试，并提供数千种注入代理的服务，我们还提供了[调整后的 Istio 安装](https://github.com/istio/tools/blob/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install/values.yaml)，可为 Istio 控制平面分配额外的内存和 CPU。 -{{< warning_icon >}} Istio 的 [demo 安装](/zh/docs/setup/getting-started/) 不适合进行性能测试，因为它被设计为部署在小型试用群集中，并且具有完整的跟踪和访问日志，可显示 Istio 的功能。 +{{< warning_icon >}} Istio 的 [demo 安装](/zh/docs/setup/getting-started/)不适合进行性能测试，因为它被设计为部署在小型试用群集中，并且具有完整的跟踪和访问日志，可显示 Istio 的功能。 ## 2. 专注于数据平面{#2-focus-on-the-data-plane} @@ -37,7 +37,7 @@ keywords: [performance,scalability,scale,benchmarks] 当 [Mixer V2](https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s) 将所有策略和遥测功能直接移到代理中时，这两个例外都会在将来的 Istio 版本中消失。 -接下来，在大规模测试 Istio 的数据平面性能时，不仅要以每秒递增的请求进行测试，而且还要以越来越多的 **并发** 连接进行测试，这一点很重要。这是因为现实世界中的高吞吐量流量来自多个客户端。我们 [提供了脚本](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#run-performance-tests) 允许您以递增的 RPS 对任意数量的并发连接执行相同的负载测试。 +接下来，在大规模测试 Istio 的数据平面性能时，不仅要以每秒递增的请求进行测试，而且还要以越来越多的 **并发** 连接进行测试，这一点很重要。这是因为现实世界中的高吞吐量流量来自多个客户端。我们[提供了脚本](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#run-performance-tests)允许您以递增的 RPS 对任意数量的并发连接执行相同的负载测试。 最后，我们的测试环境可以测量两个 pod 之间少量的请求。客户端 pod 是 [Fortio](http://fortio.org/)，它将流量发送到服务端 pod。 @@ -45,7 +45,7 @@ keywords: [performance,scalability,scale,benchmarks] ## 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 代理增量添加到工作负载中。 +尽管 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 代理增量添加到工作负载中。 为此，测试脚本提供了[三种不同模式](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#run-performance-tests)。当请求同时通过客户端和服务器代理（`both`）、仅通过服务器代理（`serveronly`）和都不通过代理（`baseline`）时，这些模式将分析 Istio 的性能。 @@ -108,4 +108,4 @@ keywords: [performance,scalability,scale,benchmarks] Istio 的性能取决于您的具体设置和流量负载情况。由于存在这种差异，请确保您的测试设置能够准确反映您的生产工作负载。要试用基准测试脚本，请转到 [Istio Tools 库](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark)。 {{< /tip >}} -另外，请查阅 [Istio 性能和可伸缩性指南](/zh/docs/ops/deployment/performance-and-scalability) 获取最新的性能数据。感谢您的阅读，祝您基准测试愉快！ +另外，请查阅 [Istio 性能和可伸缩性指南](/zh/docs/ops/deployment/performance-and-scalability)获取最新的性能数据。感谢您的阅读，祝您基准测试愉快！ diff --git a/content/zh/blog/2019/trustworthy-jwt-sds/index.md b/content/zh/blog/2019/trustworthy-jwt-sds/index.md index 6af880ceff..66b612486e 100644 --- a/content/zh/blog/2019/trustworthy-jwt-sds/index.md +++ b/content/zh/blog/2019/trustworthy-jwt-sds/index.md @@ -14,7 +14,7 @@ target_release: 1.2 在 Kubernetes 1.12 之前，Kubernetes API 服务器的 JWT 存在以下问题： 1. 令牌没有重要字段来限制其使用范围，例如 `aud` 或 `exp`。有关更多信息，请参见[绑定服务令牌](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/bound-service-account-tokens.md)。 -1.令牌安装在所有 pod 上，无法退出。请参见[服务帐户令牌数量](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/svcacct-token-volume-source.md)了解其机制。 +1. 令牌安装在所有 pod 上，无法退出。请参见[服务帐户令牌数量](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/svcacct-token-volume-source.md)了解其机制。 Kubernetes 1.12 引入了 `可信任` JWT 来解决这些问题。但是，直到 [Kubernetes 1.13](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.13.md) 才支持 `aud` 字段与 API 服务器受众具有不同的值。为了更好地保护网格，Istio 1.3 仅支持 `可信任` JWT，并且在启用 SDS 时要求 `aud` 字段的值为 `istio-ca`。在启用 SDS 的情况下将 Istio 部署升级到 1.3 之前，请验证您是否使用了 Kubernetes 1.13 或更高版本。 diff --git a/content/zh/blog/2020/multi-cluster-mesh-automation/index.md b/content/zh/blog/2020/multi-cluster-mesh-automation/index.md index 9fcc16cc15..e36e86fb9f 100644 --- a/content/zh/blog/2020/multi-cluster-mesh-automation/index.md +++ b/content/zh/blog/2020/multi-cluster-mesh-automation/index.md @@ -8,7 +8,7 @@ keywords: [traffic-management,automation,configuration,multicluster,multi-mesh,g target_release: 1.5 --- -在 Intuit 公司，我们看到了博客 [用于隔离和边界保护的多网格部署](/zh/blog/2019/isolated-clusters/)，其中提到的某些问题与我们有关系。我们意识到，即使我们想要配置单网格多集群，而不是博客中描述的多个网格联邦，也会在我们的环境中遇到相同的非统一命名问题。这篇博客介绍了我们如何使用 [Admiral](https://github.com/istio-ecosystem/admiral) 解决这些问题，该项目是 GitHub 组织 `istio-ecosystem` 下的一个开源项目。 +在 Intuit 公司，我们看到了博客[用于隔离和边界保护的多网格部署](/zh/blog/2019/isolated-clusters/)，其中提到的某些问题与我们有关系。我们意识到，即使我们想要配置单网格多集群，而不是博客中描述的多个网格联邦，也会在我们的环境中遇到相同的非统一命名问题。这篇博客介绍了我们如何使用 [Admiral](https://github.com/istio-ecosystem/admiral) 解决这些问题，该项目是 GitHub 组织 `istio-ecosystem` 下的一个开源项目。 ## 背景{#background} @@ -26,7 +26,7 @@ target_release: 1.5 经过进一步的调查，很明显，配置需要根据上下文来确定：每个集群都需要根据其场景定制配置。 -例如，我们有一个被订单和报告消费的支付服务。支付服务在 `us-east`（集群 3）和 `us-west`（集群 2）之间进行了 HA/DR 部署。支付服务部署在两个区域不同名的命名空间中。订单服务作为支付方式，部署在 `us-west` 另一个集群中（集群 1）。报告服务与 `us-west` 中的支付服务部署在同一群集中（群集2）。 +例如，我们有一个被订单和报告消费的支付服务。支付服务在 `us-east`（集群 3）和 `us-west`（集群 2）之间进行了 HA/DR 部署。支付服务部署在两个区域不同名的命名空间中。订单服务作为支付方式，部署在 `us-west` 另一个集群中（集群 1）。报告服务与 `us-west` 中的支付服务部署在同一群集中（群集 2）。 {{< image width="75%" link="./Istio_mesh_example.svg" diff --git a/content/zh/blog/2020/tradewinds-2020/index.md b/content/zh/blog/2020/tradewinds-2020/index.md index 53c0512242..7587a7653b 100644 --- a/content/zh/blog/2020/tradewinds-2020/index.md +++ b/content/zh/blog/2020/tradewinds-2020/index.md @@ -33,7 +33,7 @@ Istio 的[认证](/zh/docs/concepts/security/#authentication-policies)和[授权 通过 `preview` 配置文件安装 Istio 1.5 不会再安装 Mixer。安全起见，如果您是从以前的版本升级，或通过 `default` 配置文件安装，我们仍会保留 Mixer。当使用 Prometheus 或 Stackdriver 进行度量时，建议您尝试新模式并查看性能提高了多少。 -如果有需要，您可以保持安装并启用 Mixer。最终，Mixer 将成为 Istio 单独的发行组件，成为 [istio-ecosystem](https://github.com/istio-ecosystem/)的一部分。 +如果有需要，您可以保持安装并启用 Mixer。最终，Mixer 将成为 Istio 单独的发行组件，成为 [istio-ecosystem](https://github.com/istio-ecosystem/) 的一部分。 ## 减少移动部分{#fewer-moving-parts} @@ -58,7 +58,7 @@ Istio 的[认证](/zh/docs/concepts/security/#authentication-policies)和[授权 caption="Istio 2020 年的架构" >}} -2020年，我们将继续专注于普及，实现默认 `零配置` 的目标，该默认设置不需要您更改应用程序的任何配置即可使用 Istio 的大多数功能。 +2020 年，我们将继续专注于普及，实现默认 `零配置` 的目标，该默认设置不需要您更改应用程序的任何配置即可使用 Istio 的大多数功能。 ## 改进生命周期管理{#improved-lifecycle-management} @@ -92,4 +92,4 @@ Istio 已经为强大的服务安全性提供了基础：可靠的 workload 身 - [增强存储库](https://github.com/istio/enhancements/)，以便开发追踪功能。 - 让没有 Kubernetes 的 Istio 可以更轻松地运行！ -从大海到[天空](https://www.youtube.com/watch?v=YjZ4AZ7hRM0)，Istio 期待您的加入！ \ No newline at end of file +从大海到[天空](https://www.youtube.com/watch?v=YjZ4AZ7hRM0)，Istio 期待您的加入！ diff --git a/content/zh/boilerplates/before-you-begin-egress.md b/content/zh/boilerplates/before-you-begin-egress.md index ec85e9b528..96fe5d5070 100644 --- a/content/zh/boilerplates/before-you-begin-egress.md +++ b/content/zh/boilerplates/before-you-begin-egress.md @@ -25,4 +25,4 @@ {{< text bash >}} $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) - {{< /text >}} \ No newline at end of file + {{< /text >}} diff --git a/content/zh/boilerplates/experimental-feature-warning.md b/content/zh/boilerplates/experimental-feature-warning.md index c6bde0478f..531b4b98e2 100644 --- a/content/zh/boilerplates/experimental-feature-warning.md +++ b/content/zh/boilerplates/experimental-feature-warning.md @@ -2,4 +2,4 @@ --- {{< warning >}} 以下信息描述了一个实验性功能，仅用于评估。 -{{< /warning >}} \ No newline at end of file +{{< /warning >}} diff --git a/content/zh/boilerplates/helm-security-warning.md b/content/zh/boilerplates/helm-security-warning.md index 39d73469d4..f65aaaa8ae 100644 --- a/content/zh/boilerplates/helm-security-warning.md +++ b/content/zh/boilerplates/helm-security-warning.md @@ -3,4 +3,4 @@ {{< warning >}} 本文档中介绍如何使用带 Tiller 的 Helm 不使用安全默认值。 有关基于 Tiller 安全安装的进一步步骤请参考[安全安装 Helm](https://helm.sh/docs/intro/install/)。 -{{< /warning >}} \ No newline at end of file +{{< /warning >}} diff --git a/content/zh/boilerplates/index.md b/content/zh/boilerplates/index.md index cbe5fa40d7..b5797c65ef 100644 --- a/content/zh/boilerplates/index.md +++ b/content/zh/boilerplates/index.md @@ -2,4 +2,4 @@ headless: true --- -这个文件告诉 Hugo 引擎，在生成页面时，当前目录树下的所有文件都不应该在站点中被渲染为普通页面。 \ No newline at end of file +这个文件告诉 Hugo 引擎，在生成页面时，当前目录树下的所有文件都不应该在站点中被渲染为普通页面。 diff --git a/content/zh/boilerplates/trace-generation.md b/content/zh/boilerplates/trace-generation.md index 1366a04c05..f2c31e92bc 100644 --- a/content/zh/boilerplates/trace-generation.md +++ b/content/zh/boilerplates/trace-generation.md @@ -1,9 +1,9 @@ --- --- 要查看追踪数据，必须向服务发送请求。请求的数量取决于 Istio 的采样率。 -采样率在安装 Istio 时设置，默认采样速率为 1%。在第一个跟踪可见之前，您需要发送至少100个请求。 +采样率在安装 Istio 时设置，默认采样速率为 1%。在第一个跟踪可见之前，您需要发送至少 100 个请求。 使用以下命令向 `productpage` 服务发送 100 个请求： {{< text bash >}} $ for i in `seq 1 100`; do curl -s -o /dev/null http://$GATEWAY_URL/productpage; done -{{< /text >}} \ No newline at end of file +{{< /text >}} diff --git a/content/zh/docs/_index.md b/content/zh/docs/_index.md index be49f3ad86..8a515b537d 100644 --- a/content/zh/docs/_index.md +++ b/content/zh/docs/_index.md @@ -11,4 +11,4 @@ icon: docs - [FAQ](/zh/faq) - [词汇表](/zh/docs/reference/glossary)。 -- [文档归档](https://archive.istio.io/)中包括了历史版本的快照。 \ No newline at end of file +- [文档归档](https://archive.istio.io/)中包括了历史版本的快照。 diff --git a/content/zh/docs/concepts/observability/index.md b/content/zh/docs/concepts/observability/index.md index 0d8e730d6b..3a0eba641a 100644 --- a/content/zh/docs/concepts/observability/index.md +++ b/content/zh/docs/concepts/observability/index.md @@ -18,7 +18,7 @@ Istio 生成以下类型的遥测数据，以提供对整个服务网格的可 - [**指标**](#metrics)。Istio 基于 4 个监控的黄金标识（延迟、流量、错误、饱和）生成了一系列服务指标。Istio 还为[网格控制平面](/zh/docs/ops/deployment/architecture/)提供了更详细的指标。除此以外还提供了一组默认的基于这些指标的网格监控仪表板。 - [**分布式追踪**](#distributed-traces)。Istio 为每个服务生成分布式追踪 span，运维人员可以理解网格内服务的依赖和调用流程。 -- [**访问日志**](#access-logs)。当流量流入网格中的服务时，Istio 可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个[工作负载实例](/zh/docs/reference/glossary/#workload-instance) 的级别。 +- [**访问日志**](#access-logs)。当流量流入网格中的服务时，Istio 可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个[工作负载实例](/zh/docs/reference/glossary/#workload-instance)的级别。 ## 指标 {#metrics} diff --git a/content/zh/docs/concepts/policies/index.md b/content/zh/docs/concepts/policies/index.md index 817bf4f370..1a44d1e89f 100644 --- a/content/zh/docs/concepts/policies/index.md +++ b/content/zh/docs/concepts/policies/index.md @@ -13,4 +13,4 @@ Istio 允许您为应用程序自定义策略，用以在运行时强制执行 Istio 还允许您创建自己的[策略适配器](/zh/docs/tasks/policy-enforcement/control-headers)，比如，您自定义的授权行为。 -您必须为您的服务网格[启用策略实施](/zh/docs/tasks/policy-enforcement/enabling-policy) 以后才能使用此功能。 +您必须为您的服务网格[启用策略实施](/zh/docs/tasks/policy-enforcement/enabling-policy)以后才能使用此功能。 diff --git a/content/zh/docs/concepts/security/index.md b/content/zh/docs/concepts/security/index.md index ac0009eb5e..d361fda985 100644 --- a/content/zh/docs/concepts/security/index.md +++ b/content/zh/docs/concepts/security/index.md @@ -140,7 +140,7 @@ Istio 提供了在 Kubernetes 中使用节点代理进行证书和密钥分配 Istio 提供两种类型的身份验证： - **传输身份验证**，也称为**服务间身份验证**：验证建立连接的直接客户端。 - Istio 提供 [双向 TLS](https://en.wikipedia.org/wiki/Mutual_authentication) 作为传输身份验证的完整堆栈解决方案。 + Istio 提供[双向 TLS](https://en.wikipedia.org/wiki/Mutual_authentication) 作为传输身份验证的完整堆栈解决方案。 您可以轻松打开此功能，而无需更改服务代码。这个解决方案： - 为每个服务提供强大的身份，表示其角色，以实现跨群集和云的互操作性。 @@ -185,7 +185,7 @@ Istio 双向 TLS 具有一个宽容模式（permissive mode），允许 service 您可以使用身份认证策略为在 Istio 网格中接收请求的服务指定身份验证要求。网格操作者使用 `.yaml` 文件来指定策略。部署后，策略将保存在 Istio 配置存储中。Pilot、Istio 控制器监视配置存储。一有任何的策略变更，Pilot 会将新策略转换为适当的配置，告知 Envoy sidecar 代理如何执行所需的身份验证机制。Pilot 可以获取公钥并将其附加到 JWT 验证配置。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们挂载到应用程序 pod 以进行双向 TLS。您可以在 [PKI 部分](/zh/docs/concepts/security/#PKI)中找到更多信息。Istio 异步发送配置到目标端点。代理收到配置后，新的身份验证要求会立即生效。 -发送请求的客户端服务负责遵循必要的身份验证机制。对于源身份验证（JWT），应用程序负责获取 JWT 凭据并将其附加到请求。对于双向 TLS，Istio 提供[目标规则](/zh/docs/concepts/traffic-management/#destination-rules)。运维人员可以使用目标规则来指示客户端代理使用 TLS 与服务器端预期的证书进行初始连接。您可以在 [双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)中找到有关双向 TLS 如何在 Istio 中工作的更多信息。 +发送请求的客户端服务负责遵循必要的身份验证机制。对于源身份验证（JWT），应用程序负责获取 JWT 凭据并将其附加到请求。对于双向 TLS，Istio 提供[目标规则](/zh/docs/concepts/traffic-management/#destination-rules)。运维人员可以使用目标规则来指示客户端代理使用 TLS 与服务器端预期的证书进行初始连接。您可以在[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)中找到有关双向 TLS 如何在 Istio 中工作的更多信息。 {{< image width="60%" link="./auth.svg" caption="认证架构" >}} @@ -493,8 +493,8 @@ spec: #### 自定义条件{#custom-conditions} 您还可以使用 `when` 部分指定其他条件。 -例如，下面的 `AuthorizationPolicy` 定义包括以下条件：`request.headers[version]` 是 `v1` 或 `v2`。 -在这种情况下，key 是 `request.headers[version]`，它是 Istio 属性 `request.headers`（是个字典）中的一项。 +例如，下面的 `AuthorizationPolicy` 定义包括以下条件：`request.headers [version]` 是 `v1` 或 `v2`。 +在这种情况下，key 是 `request.headers [version]`，它是 Istio 属性 `request.headers`（是个字典）中的一项。 {{< text yaml >}} apiVersion: security.istio.io/v1beta1 diff --git a/content/zh/docs/concepts/traffic-management/index.md b/content/zh/docs/concepts/traffic-management/index.md index 398ff25dac..25593bf482 100644 --- a/content/zh/docs/concepts/traffic-management/index.md +++ b/content/zh/docs/concepts/traffic-management/index.md @@ -41,7 +41,7 @@ Istio 基本的服务发现和负载均衡能力为您提供了一个可用的 ## 虚拟服务 {#virtual-services} -[虚拟服务（Virtual Service）](/zh/docs/reference/config/networking/virtual-service/#VirtualService)和[目标规则（Destination Rule）](#destination-rules)是 Istio 流量路由功能的关键拼图。虚拟服务让您配置如何在服务网格内将请求路由到服务，这基于 Istio 和平台提供的基本的连通性和服务发现能力。每个虚拟服务包含一组路由规则，Istio 按顺序评估它们，Istio 将每个给定的请求匹配到虚拟服务指定的实际目标地址。您的网格可以有多个虚拟服务，也可以没有，取决于您的使用场景。 +[虚拟服务（Virtual Service）](/zh/docs/reference/config/networking/virtual-service/#VirtualService) 和[目标规则（Destination Rule）](#destination-rules) 是 Istio 流量路由功能的关键拼图。虚拟服务让您配置如何在服务网格内将请求路由到服务，这基于 Istio 和平台提供的基本的连通性和服务发现能力。每个虚拟服务包含一组路由规则，Istio 按顺序评估它们，Istio 将每个给定的请求匹配到虚拟服务指定的实际目标地址。您的网格可以有多个虚拟服务，也可以没有，取决于您的使用场景。 ### 为什么使用虚拟服务？{#why-use-virtual-services} @@ -51,7 +51,7 @@ Istio 基本的服务发现和负载均衡能力为您提供了一个可用的 使用虚拟服务，您可以为一个或多个主机名指定流量行为。在虚拟服务中使用路由规则，告诉 Envoy 如何发送虚拟服务的流量到适当的目标。路由目标地址可以是同一服务的不同版本，也可以是完全不同的服务。 -一个典型的用例是将流量发送到被指定为服务子集的服务的不同版本。客户端将虚拟服务视为一个单一实体，将请求发送至虚拟服务主机，然后 Envoy 根据虚拟服务规则把流量路由到不同的版本。例如，“20%的调用转到新版本”或“将这些用户的调用转到版本 2”。这允许您创建一个金丝雀发布，逐步增加发送到新版本服务的流量百分比。流量路由完全独立于实例部署，这意味着实现新版本服务的实例可以根据流量的负载来伸缩，完全不影响流量路由。相比之下，像 Kubernetes 这样的容器编排平台只支持基于实例缩放的流量分发，这会让情况变得复杂。您可以在[使用 Istio 进行金丝雀部署](/zh/blog/2017/0.1-canary/)的文章里阅读到更多用虚拟服务实现金丝雀部署的内容。 +一个典型的用例是将流量发送到被指定为服务子集的服务的不同版本。客户端将虚拟服务视为一个单一实体，将请求发送至虚拟服务主机，然后 Envoy 根据虚拟服务规则把流量路由到不同的版本。例如，“20% 的调用转到新版本”或“将这些用户的调用转到版本 2”。这允许您创建一个金丝雀发布，逐步增加发送到新版本服务的流量百分比。流量路由完全独立于实例部署，这意味着实现新版本服务的实例可以根据流量的负载来伸缩，完全不影响流量路由。相比之下，像 Kubernetes 这样的容器编排平台只支持基于实例缩放的流量分发，这会让情况变得复杂。您可以在[使用 Istio 进行金丝雀部署](/zh/blog/2017/0.1-canary/)的文章里阅读到更多用虚拟服务实现金丝雀部署的内容。 虚拟服务可以让您： @@ -314,7 +314,7 @@ spec: ## 服务入口 {#service-entries} -使用[服务入口（Service Entry）](/zh/docs/reference/config/networking/service-entry/#ServiceEntry)来添加一个入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样。配置服务入口允许您管理运行在网格外的服务的流量，它包括以下几种能力： +使用[服务入口（Service Entry）](/zh/docs/reference/config/networking/service-entry/#ServiceEntry) 来添加一个入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样。配置服务入口允许您管理运行在网格外的服务的流量，它包括以下几种能力： - 为外部目标 redirect 和转发请求，例如来自 web 端的 API 调用，或者流向遗留老系统的服务。 - 为外部目标定义[重试](#retries)、[超时](#timeouts)和[故障注入](#fault-injection)策略。 diff --git a/content/zh/docs/examples/bookinfo/index.md b/content/zh/docs/examples/bookinfo/index.md index d8a071a9cd..5ecae1d50a 100755 --- a/content/zh/docs/examples/bookinfo/index.md +++ b/content/zh/docs/examples/bookinfo/index.md @@ -68,7 +68,7 @@ Bookinfo 应用中的几个微服务是由不同的语言编写的。 {{< /text >}} {{< warning >}} - 如果您在安装过程中禁用了 Sidecar 自动注入功能而选择[手动注入 Sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection)，请在部署应用之前使用 [`istioctl kube-inject`](/zh/docs/reference/commands/istioctl/#istioctl-kube-inject)命令修改 `bookinfo.yaml` 文件。 + 如果您在安装过程中禁用了 Sidecar 自动注入功能而选择[手动注入 Sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection)，请在部署应用之前使用 [`istioctl kube-inject`](/zh/docs/reference/commands/istioctl/#istioctl-kube-inject) 命令修改 `bookinfo.yaml` 文件。 {{< text bash >}} $ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo.yaml@) diff --git a/content/zh/docs/examples/microservices-istio/single/index.md b/content/zh/docs/examples/microservices-istio/single/index.md index 9cb967a8c7..6d900ecb25 100644 --- a/content/zh/docs/examples/microservices-istio/single/index.md +++ b/content/zh/docs/examples/microservices-istio/single/index.md @@ -28,7 +28,7 @@ weight: 10 请按照下列步骤下载应用程序的代码，安装其依赖项，然后在本地运行它： -1. 将 [服务代码]({{< github_blob >}}/samples/bookinfo/src/ratings/ratings.js) 和 +1. 将[服务代码]({{}}/samples/bookinfo/src/ratings/ratings.js) 和 [其 package 文件]({{< github_blob >}}/samples/bookinfo/src/ratings/package.json) 下载到一个单独的目录中： diff --git a/content/zh/docs/examples/virtual-machines/bookinfo/index.md b/content/zh/docs/examples/virtual-machines/bookinfo/index.md index 69d3fb7256..4c07e0c155 100644 --- a/content/zh/docs/examples/virtual-machines/bookinfo/index.md +++ b/content/zh/docs/examples/virtual-machines/bookinfo/index.md @@ -29,7 +29,7 @@ https://docs.google.com/drawings/d/1G1592HlOVgtbsIqxJnmMzvy6ejIdhajCosxF1LbvspI/ ## 开始之前{#before-you-begin} -- 按照[安装指南](/zh/docs/setup/getting-started/) 中的说明安装 Istio。 +- 按照[安装指南](/zh/docs/setup/getting-started/)中的说明安装 Istio。 - 部署 [Bookinfo](/zh/docs/examples/bookinfo/) 示例应用程序（在 `bookinfo` 命名空间中）。 diff --git a/content/zh/docs/examples/virtual-machines/multi-network/index.md b/content/zh/docs/examples/virtual-machines/multi-network/index.md index e52167258c..3aa82a3b14 100644 --- a/content/zh/docs/examples/virtual-machines/multi-network/index.md +++ b/content/zh/docs/examples/virtual-machines/multi-network/index.md @@ -121,7 +121,7 @@ aliases: $ sudo dpkg -i istio-sidecar.deb {{< /text >}} -1. 添加 Istio gateway 的 IP 地址到 `/etc/hosts` 中。重新查看 [集群上定制化安装 Istio](#customized-installation-of-Istio-on-the-cluster) 部分学习怎样获取 IP 地址。 +1. 添加 Istio gateway 的 IP 地址到 `/etc/hosts` 中。重新查看[集群上定制化安装 Istio](#customized-installation-of-Istio-on-the-cluster) 部分学习怎样获取 IP 地址。 下面的示例演示更新 `/etc/hosts` 文件中的 Istio gateway 地址： {{< text bash >}} @@ -322,4 +322,4 @@ $ curl -v httpbin.bar.global:8000 $ istioctl experimental remove-from-mesh -n ${SERVICE_NAMESPACE} vmhttp Kubernetes Service "vmhttp.vm" has been deleted for external service "vmhttp" Service Entry "mesh-expansion-vmhttp" has been deleted for external service "vmhttp" -{{< /text >}} \ No newline at end of file +{{< /text >}} diff --git a/content/zh/docs/examples/virtual-machines/single-network/index.md b/content/zh/docs/examples/virtual-machines/single-network/index.md index 30ffbb2de0..a01f830351 100644 --- a/content/zh/docs/examples/virtual-machines/single-network/index.md +++ b/content/zh/docs/examples/virtual-machines/single-network/index.md @@ -17,7 +17,7 @@ aliases: ## 准备环境{#prerequisites} - 您已经在 Kubernetes 上部署了 Istio。如果尚未这样做， - 则可以在[安装指南](/zh/docs/setup/getting-started/) 中找到方法。 + 则可以在[安装指南](/zh/docs/setup/getting-started/)中找到方法。 - 虚拟机（VM）必须具有网格中 endpoint 的 IP 连接。 这通常需要 VPC 或者 VPN，以及需要提供直接（没有 NAT 或者防火墙拒绝访问） @@ -39,7 +39,7 @@ aliases: 当将非 Kubernetes 服务添加到 Istio 网格中时，首先配置 Istio 它自己的设施，并生成配置文件使 VM 连接网格。在具有集群管理员特权的计算机上，使用以下命令为 VM 准备集群： -1. 使用类似于以下的命令，为生成的 CA 证书创建 Kubernetes secret。请参阅[证书办法机构 (CA) 证书](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/#plugging-in-the-existing-certificate-and-key) 获取更多的详细信息。 +1. 使用类似于以下的命令，为生成的 CA 证书创建 Kubernetes secret。请参阅[证书办法机构 (CA) 证书](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/#plugging-in-the-existing-certificate-and-key)获取更多的详细信息。 {{< warning >}} 样本目录中的 root 证书和中间证书已经大范围分发并被识别。 @@ -99,7 +99,7 @@ aliases: ISTIO_SERVICE_CIDR=10.55.240.0/20 {{< /text >}} -1. 如果 VM 仅在网格中调用服务，您可以跳过这2一步骤。否则，使用以下命令为 VM 新增公开端口到 `cluster.env` 文件下。 +1. 如果 VM 仅在网格中调用服务，您可以跳过这 2 一步骤。否则，使用以下命令为 VM 新增公开端口到 `cluster.env` 文件下。 如有必要，您可以稍后更改端口。 {{< text bash >}} @@ -136,7 +136,7 @@ aliases: $ sudo dpkg -i istio-sidecar.deb {{< /text >}} -1. 将 Istio 的网关 IP 地址添加到 `/etc/hosts`。重新访问 [集群准备](#preparing-the-Kubernetes-cluster-for-VMs) 部分以了解如何获取 IP 地址。 +1. 将 Istio 的网关 IP 地址添加到 `/etc/hosts`。重新访问[集群准备](#preparing-the-Kubernetes-cluster-for-VMs)部分以了解如何获取 IP 地址。 以下示例使用 Istio 网关地址修改 `/etc/hosts` 文件： {{< text bash >}} @@ -182,7 +182,7 @@ aliases: 设置完后，机器可以访问运行在 Kubernetes 集群上的服务，或者其他的 VM。 以下示例展示了使用 `/etc/hosts/` 如何从 VM 中访问 Kubernetes 集群上运行的服务， -这里使用 [Bookinfo 示例](/zh/docs/examples/bookinfo/) 中的服务。 +这里使用 [Bookinfo 示例](/zh/docs/examples/bookinfo/)中的服务。 1. 首先，在集群管理机器上获取服务的虚拟 IP 地址（`clusterIP`）： diff --git a/content/zh/docs/ops/best-practices/traffic-management/index.md b/content/zh/docs/ops/best-practices/traffic-management/index.md index 088cc7f327..5805952fe4 100644 --- a/content/zh/docs/ops/best-practices/traffic-management/index.md +++ b/content/zh/docs/ops/best-practices/traffic-management/index.md @@ -219,7 +219,7 @@ metadata: 当为现有主机应用第二个及更多的 `VirtualService`时，`istio-pilot` 会将附加的路由规则合并到主机的现有配置中。但是，在使用此功能时，有一些注意事项。 1. 尽管会保留任何给定源 `VirtualService` 中规则的评估顺序，但跨资源的顺序是 UNDEFINED。换句话说，无法保证片段配置中规则的评估顺序，因此，只有在片段规则之间没有冲突的规则或者顺序依赖性时，它才具有可预测的行为。 -1.片段中应该只有一个“catch-all”规则（即与任何请求路径或 header 都匹配的规则）。所有这些“catch-all”规则将在合并配置中移至列表的末尾，但是由于它们捕获了所有请求，因此，首先应用的那个规则，实际上会覆盖并禁用其它的规则。 +1. 片段中应该只有一个“catch-all”规则（即与任何请求路径或 header 都匹配的规则）。所有这些“catch-all”规则将在合并配置中移至列表的末尾，但是由于它们捕获了所有请求，因此，首先应用的那个规则，实际上会覆盖并禁用其它的规则。 1. 如果想将 `VirtualService` 绑定到网关，则只能以这种方式进行分段。sidecar 不支持主机合并。 也可以使用类似的合并语义和限制将 `DestinationRule` 分段。 diff --git a/content/zh/docs/ops/common-problems/network-issues/index.md b/content/zh/docs/ops/common-problems/network-issues/index.md index 00249ebc55..e973359cb6 100644 --- a/content/zh/docs/ops/common-problems/network-issues/index.md +++ b/content/zh/docs/ops/common-problems/network-issues/index.md @@ -17,7 +17,7 @@ aliases: $ kubectl logs PODNAME -c istio-proxy -n NAMESPACE {{< /text >}} -在默认的访问日志输出格式中，Envoy 响应标志和 Mixer 策略状态位于响应状态码之后，如果你使用自定义日志输出格式，请确保包含 `%RESPONSE_FLAGS%` 和 `%DYNAMIC_METADATA(istio.mixer:status)%`。 +在默认的访问日志输出格式中，Envoy 响应标志和 Mixer 策略状态位于响应状态码之后，如果你使用自定义日志输出格式，请确保包含 `%RESPONSE_FLAGS%` 和 `%DYNAMIC_METADATA(istio.mixer:status) %`。 参考 [Envoy 响应标志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#config-access-log-format-response-flags)查看更多有关响应标志的细节。 @@ -254,7 +254,7 @@ server { - `VirtualService` 将 `vs1` 配置为主机 `service1.test.com` 并且 gateway 配置为 `gw` - `VirtualService` 将 `vs2` 配置为主机 `service2.test.com` 并且 gateway 配置为 `gw` -## 在网关中配置多个TLS主机时端口冲突{#port-conflict-when-configuring-multiple-TLS-hosts-in-a-gateway} +## 在网关中配置多个 TLS 主机时端口冲突{#port-conflict-when-configuring-multiple-TLS-hosts-in-a-gateway} 如果您应用的 `Gateway` 配置与另一个现有的 `Gateway` 具有相同的 `selector` 标签，如果它们都暴露了相同的 HTTPS 端口，那您必须确保它们具有唯一的端口名。 否则，该配置在应用时不会立即显示错误指示，但在运行时网关配置中将忽略该配置。 diff --git a/content/zh/docs/ops/common-problems/observability-issues/index.md b/content/zh/docs/ops/common-problems/observability-issues/index.md index a44b20fb8d..f382a13afa 100644 --- a/content/zh/docs/ops/common-problems/observability-issues/index.md +++ b/content/zh/docs/ops/common-problems/observability-issues/index.md @@ -122,7 +122,7 @@ istio-system tcpkubeattrgenrulerule 4h 1. 与`istio-telemetry` 自监控端点建立连接，按照上文[确认 Mixer 可以收到指标报告的调用](#verify-mixer-is-receiving-report-calls)的描述设置一个到 `istio-telemetry` 自监控端口的转发。 -1. 确认以下的指标的最新的值是0： +1. 确认以下的指标的最新的值是 0： * `mixer_config_adapter_info_config_errors_total` @@ -142,7 +142,7 @@ istio-system tcpkubeattrgenrulerule 4h 在显示 Mixer 自监控 endpoint 的页面上，搜索上面列出的每个指标。如果所有配置正确，您应该不能找的那些指标值。 -如果存在某个指标值，请确认该指标值的最大配置 ID 是0。这可以验证 Mixer 在处理最近提供配置过程中没有发生任何错误。 +如果存在某个指标值，请确认该指标值的最大配置 ID 是 0。这可以验证 Mixer 在处理最近提供配置过程中没有发生任何错误。 ### 验证 Mixer 可以将指标实例发送到 Prometheus 适配器{#verify-Mixer-is-sending-Metric-instances-to-the-Prometheus-adapter} diff --git a/content/zh/docs/ops/common-problems/security-issues/index.md b/content/zh/docs/ops/common-problems/security-issues/index.md index 064113cb28..0651473824 100644 --- a/content/zh/docs/ops/common-problems/security-issues/index.md +++ b/content/zh/docs/ops/common-problems/security-issues/index.md @@ -504,7 +504,7 @@ Citadel 不支持多个实例运行，否则会造成竞争状态并导致系统 在 Citadel 维护禁用期间，带有新 ServiceAccount 的负载不能够启动，因为它不能从 Citadel 获取生成的证书。 {{< /warning >}} -Citadel 不是关键的数据平面组件。默认的工作负载证书有效期是3个月。证书在过期前会被 Citadel 轮换。如果在 Citadel 短暂的维护期间内，已经存在的 双向 TLS 不会受影响。 +Citadel 不是关键的数据平面组件。默认的工作负载证书有效期是 3 个月。证书在过期前会被 Citadel 轮换。如果在 Citadel 短暂的维护期间内，已经存在的 双向 TLS 不会受影响。 如果您怀疑 Citadel 无法正常工作，请验证 `istio-citadel` pod 的状态： diff --git a/content/zh/docs/ops/common-problems/validation/index.md b/content/zh/docs/ops/common-problems/validation/index.md index cfebd9c236..9e7f9e6289 100644 --- a/content/zh/docs/ops/common-problems/validation/index.md +++ b/content/zh/docs/ops/common-problems/validation/index.md @@ -11,7 +11,7 @@ aliases: ## 看似有效的配置不生效 {#valid-configuration-is-rejected} -手动验证您的配置是否正确，当有必要的时候请参照[Istio API 文档](/zh/docs/reference/config) 。 +手动验证您的配置是否正确，当有必要的时候请参照 [Istio API 文档](/zh/docs/reference/config) 。 ## 接受无效配置 {#invalid-configuration-is-accepted} @@ -126,7 +126,7 @@ webhooks: ## 创建配置失败报错： x509 certificate errors {#x509-certificate-errors} -`x509: certificate signed by unknown authority` 错误通常和 webhook 配置中的空 `caBundle` 有关，所以要确认它不为空 (请查阅 [验证 webhook 配置](#invalid-configuration-is-accepted))。Istio 有意识的使用 `istio-validation` `configmap` 和根证书，调整了 webhook 配置。 +`x509: certificate signed by unknown authority` 错误通常和 webhook 配置中的空 `caBundle` 有关，所以要确认它不为空 (请查阅[验证 webhook 配置](#invalid-configuration-is-accepted))。Istio 有意识的使用 `istio-validation` `configmap` 和根证书，调整了 webhook 配置。 1. 验证 `istio-pilot` pod 是否在运行： diff --git a/content/zh/docs/ops/configuration/mesh/app-health-check/index.md b/content/zh/docs/ops/configuration/mesh/app-health-check/index.md index 87ad1d402c..b4d0849a96 100644 --- a/content/zh/docs/ops/configuration/mesh/app-health-check/index.md +++ b/content/zh/docs/ops/configuration/mesh/app-health-check/index.md @@ -20,11 +20,11 @@ keywords: [security,health-check] 本节将阐述如何在启用了双向 TLS 的 Istio 中使用这三种方式。 -注意，无论是否启用了双向 TLS 认证，命令和 TCP 请求方式都可以与 Istio 一起使用。HTTP请求方式则要求启用了 TLS 的 Istio 使用不同的配置。 +注意，无论是否启用了双向 TLS 认证，命令和 TCP 请求方式都可以与 Istio 一起使用。HTTP 请求方式则要求启用了 TLS 的 Istio 使用不同的配置。 ## 在学习本节之前{#before-you-begin} -* 理解 Kubernetes 的 [Liveness 和 Readiness 探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，Istio 的 [认证策略](/zh/docs/concepts/security/#authentication-policies) 和 [双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication) 概念。 +* 理解 Kubernetes 的 [Liveness 和 Readiness 探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，Istio 的[认证策略](/zh/docs/concepts/security/#authentication-policies)和[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)概念。 * 有一个安装了 Istio 的 Kubernetes 集群，并且未开启全局双向 TLS 认证。 @@ -172,7 +172,7 @@ NAME READY STATUS RESTARTS AGE liveness-http-975595bb6-5b2z7c 2/2 Running 0 1m {{< /text >}} -默认情况下未启用此功能。 我们希望 [收到您的反馈](https://github.com/istio/istio/issues/10357)， +默认情况下未启用此功能。 我们希望[收到您的反馈](https://github.com/istio/istio/issues/10357)， 是否应将其更改为 Istio 安装过程中的默认行为。 ### 端口分离{#separate-port} @@ -194,7 +194,7 @@ NAME READY STATUS RESTARTS AGE liveness-http-67d5db65f5-765bb 2/2 Running 0 1m {{< /text >}} -请注意，[liveness-http]({{< github_file >}}/samples/health-check/liveness-http.yaml) 的镜像公开了两个端口：8001 和 8002 ([源码]({{< github_file >}}/samples/health-check/server.go))。在这个部署方式里面，端口8001用于常规流量，而端口8002给 Liveness 探针使用。 +请注意，[liveness-http]({{< github_file >}}/samples/health-check/liveness-http.yaml) 的镜像公开了两个端口：8001 和 8002 ([源码]({{< github_file >}}/samples/health-check/server.go))。在这个部署方式里面，端口 8001 用于常规流量，而端口 8002 给 Liveness 探针使用。 ### 清除{#cleanup} diff --git a/content/zh/docs/ops/configuration/mesh/injection-concepts/index.md b/content/zh/docs/ops/configuration/mesh/injection-concepts/index.md index 0335be2963..d4c0c630f4 100644 --- a/content/zh/docs/ops/configuration/mesh/injection-concepts/index.md +++ b/content/zh/docs/ops/configuration/mesh/injection-concepts/index.md @@ -24,7 +24,7 @@ Sidecar 是否会被自动注入取决于下面 3 条配置和 2 条安全规则 安全规则: - sidecar 默认不能被注入到 `kube-system` 和 `kube-public` 这两个 namespace -- sidecar 不能被注入到使用 `host network` 网络的pod里 +- sidecar 不能被注入到使用 `host network` 网络的 pod 里 下面的表格展示了基于上述三个配置条件的最终注入状态。上述的安全规则不会被覆盖。 diff --git a/content/zh/docs/ops/configuration/mesh/webhook/index.md b/content/zh/docs/ops/configuration/mesh/webhook/index.md index d88328ed34..af487b9170 100644 --- a/content/zh/docs/ops/configuration/mesh/webhook/index.md +++ b/content/zh/docs/ops/configuration/mesh/webhook/index.md @@ -19,7 +19,7 @@ Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识 ## 验证动态准入 Webhook 前置条件 -请参阅 [平台设置说明](/zh/docs/setup/platform-setup/)。如果集群配置错误，Webhook 将无法正常工作。集群配置后，当动态 Webhook 和相关特性不能正常工作时，你可以通过以下步骤进行检查。 +请参阅[平台设置说明](/zh/docs/setup/platform-setup/)。如果集群配置错误，Webhook 将无法正常工作。集群配置后，当动态 Webhook 和相关特性不能正常工作时，你可以通过以下步骤进行检查。 1. 验证当前是否使用正确版本的 [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 和 Kubernetes 服务 @@ -38,4 +38,4 @@ Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识 1. 验证 `kube-apiserver --enable-admission-plugins` 配置中插件 `MutatingAdmissionWebhook` 和 `ValidatingAdmissionWebhook` 是否被启用。通过检查[指定规范](/zh/docs/setup/platform-setup/)中的标志（`--enable-admission-plugins`）。 -1. 验证 Kubernetes api-server 与 Webhook 所在 Pod 的网络连通是否正常。例如错误配置 `http_proxy` 可能干扰 api-server 正常运行（详细信息请参阅[pr](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443)和[issue](https://github.com/kubernetes/kubeadm/issues/666))。 +1. 验证 Kubernetes api-server 与 Webhook 所在 Pod 的网络连通是否正常。例如错误配置 `http_proxy` 可能干扰 api-server 正常运行（详细信息请参阅 [pr](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) 和 [issue](https://github.com/kubernetes/kubeadm/issues/666))。 diff --git a/content/zh/docs/ops/configuration/security/harden-docker-images/index.md b/content/zh/docs/ops/configuration/security/harden-docker-images/index.md index e705bd1bf3..920ff07d42 100644 --- a/content/zh/docs/ops/configuration/security/harden-docker-images/index.md +++ b/content/zh/docs/ops/configuration/security/harden-docker-images/index.md @@ -32,7 +32,7 @@ aliases: - 攻击面减小了。包括尽可能少的漏洞。 - 镜像更小了，启动更快。 -请参考官方非发行版 README 的[为何我选择非发行版镜像？](https://github.com/GoogleContainerTools/distroless#why-should-i-use-distroless-images)章节。 +请参考官方非发行版 README 的[为何我选择非发行版镜像？](https://github.com/GoogleContainerTools/distroless#why-should-i-use-distroless-images) 章节。 {{< warning >}} 请注意，通常的调试工具如 `bash`、`curl`、`netcat`、`tcpdump` 等在非发行版镜像中是不可用的。 diff --git a/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md b/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md index 7fde4c5331..52584dfe98 100644 --- a/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md +++ b/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md @@ -9,7 +9,7 @@ aliases: Envoy 代理收集保留了关于网络流量的详细统计信息。 -Envoy 的统计信息只覆盖了特定 Envoy 实例的流量。参考 [可观测性](/zh/docs/tasks/observability/) +Envoy 的统计信息只覆盖了特定 Envoy 实例的流量。参考[可观测性](/zh/docs/tasks/observability/) 了解关于服务级别的 Istio 遥测方面的内容。这些由 Envoy 代理产生的统计数据记录能够提供更多关于 pod 实例的具体信息。 查看某个 pod 的统计信息： @@ -32,7 +32,7 @@ Istio 默认配置下 Envoy 只会记录最小化的统计信息。缺省的关 要查看关于统计数据收集的 Envoy 配置，可以使用 [`istioctl proxy-config bootstrap`](/zh/docs/reference/commands/istioctl/#istioctl-proxy-config-bootstrap) 命令，还可以参考 -[深入研究 Envoy 配置](/zh/docs/ops/diagnostic-tools/proxy-cmd/#deep-dive-into-envoy-configuration) 更加深入的了解相关的配置。 +[深入研究 Envoy 配置](/zh/docs/ops/diagnostic-tools/proxy-cmd/#deep-dive-into-envoy-configuration)更加深入的了解相关的配置。 需要注意的是, 只有那些 `stats_matcher` JSON 字段能匹配上 `inclusion_list` 的元件，Envoy 才会去收集他们的统计数据。 要想让 Envoy 去收集出站和入站流量的统计信息，只需将 `sidecar.istio.io/statsInclusionPrefixes` 注解加到 Kubernetes `Deployment` 的 pod 模板里去。 diff --git a/content/zh/docs/ops/configuration/telemetry/in-proxy-service-telemetry/index.md b/content/zh/docs/ops/configuration/telemetry/in-proxy-service-telemetry/index.md index 07991dbe6a..2f1d6e6596 100644 --- a/content/zh/docs/ops/configuration/telemetry/in-proxy-service-telemetry/index.md +++ b/content/zh/docs/ops/configuration/telemetry/in-proxy-service-telemetry/index.md @@ -43,7 +43,7 @@ Istio 1.4 对直接在 Envoy 代理中生成服务级别的 HTTP 指标添加了 我们不考虑将这个特性提升到 **Beta** 或者 **Stable** [状态](/zh/about/feature-stages/#feature-phase-definitions)，直到我们完成性能和可扩展性的提升以及评估。 -你的网格的性能依赖于你的配置。要了解更多，请看我们的 [性能最佳实践帖](/zh/blog/2019/performance-best-practices/)。 +你的网格的性能依赖于你的配置。要了解更多，请看我们的[性能最佳实践帖](/zh/blog/2019/performance-best-practices/)。 {{< /warning >}} @@ -52,7 +52,7 @@ Istio 1.4 对直接在 Envoy 代理中生成服务级别的 HTTP 指标添加了 - 在 `istio-proxy` 容器中所有的过滤器一起使用比运行 Mixer 过滤器减少了 10% 的 CPU 资源。 - 和不配置遥测过滤器的 Envoy 代理相比，新增加的过滤器会导致在 1000 rps 时增加约 5ms P90 的时延。 - 如果你只使用 `istio-telemetry` 服务来生成服务级别的指标，你可以关闭 `istio-telemetry` 服务。 - 这样网格中每 1000 rps 流量可以为你节省约 0.5 vCPU，并且可以在收集 [标准指标](/zh/docs/reference/config/policy-and-telemetry/metrics/) 时将 Istio 消耗的 CPU 减半。 + 这样网格中每 1000 rps 流量可以为你节省约 0.5 vCPU，并且可以在收集[标准指标](/zh/docs/reference/config/policy-and-telemetry/metrics/)时将 Istio 消耗的 CPU 减半。 ## 已知的限制{#known-limitations} diff --git a/content/zh/docs/ops/deployment/_index.md b/content/zh/docs/ops/deployment/_index.md index 35bed77d31..bdd0bd71d5 100644 --- a/content/zh/docs/ops/deployment/_index.md +++ b/content/zh/docs/ops/deployment/_index.md @@ -9,4 +9,4 @@ keywords: - requirements - installation - configuration ---- \ No newline at end of file +--- diff --git a/content/zh/docs/ops/deployment/performance-and-scalability/index.md b/content/zh/docs/ops/deployment/performance-and-scalability/index.md index f635a3d940..d8db839664 100644 --- a/content/zh/docs/ops/deployment/performance-and-scalability/index.md +++ b/content/zh/docs/ops/deployment/performance-and-scalability/index.md @@ -31,7 +31,7 @@ Istio 的数据平面组件 Envoy 代理用来处理通过系统的数据流。 - 通过代理的 QPS 有 1000 时，Envoy 使用了 **0.5 vCPU** 和 **50 MB 内存**。 - 网格总的 QPS 为 1000 时，`istio-telemetry` 服务使用了 **0.6 vCPU**。 - Pilot 使用了 **1 vCPU** 和 1.5 GB 内存。 -- 90%的情况 Envoy 代理只增加了 6.3 ms 的延迟。 +- 90% 的情况 Envoy 代理只增加了 6.3 ms 的延迟。 ## 控制平面性能 {#control-plane-performance} @@ -43,7 +43,7 @@ Pilot 根据用户编写的配置文件和系统当前状态来配置 sidecar - 配置改变的频率。 - 连接到 Pilot 的代理数量。 -这部分本身是水平可伸缩的。当 [命名空间隔离](/zh/docs/reference/config/networking/sidecar/) 选项被打开，一个单一的 Pilot 实例仅用 1 vCPU 和 1.5 GB 的内存就可以支持 1000 个服务和 2000 个 sidecar。你可以增加 Pilot 实例的数量来降低它花在推送配置到所有代理的耗时。 +这部分本身是水平可伸缩的。当[命名空间隔离](/zh/docs/reference/config/networking/sidecar/)选项被打开，一个单一的 Pilot 实例仅用 1 vCPU 和 1.5 GB 的内存就可以支持 1000 个服务和 2000 个 sidecar。你可以增加 Pilot 实例的数量来降低它花在推送配置到所有代理的耗时。 ## 数据平面性能 {#data-plane-performance} diff --git a/content/zh/docs/ops/deployment/requirements/index.md b/content/zh/docs/ops/deployment/requirements/index.md index 6adf4ee1ef..30f5891fe6 100644 --- a/content/zh/docs/ops/deployment/requirements/index.md +++ b/content/zh/docs/ops/deployment/requirements/index.md @@ -69,7 +69,7 @@ Istio 使用了如下的端口和协议。请确保没有 TCP Headless Service ## 所需的 Pod 功能{#required-pod-capabilities} -如果集群中的 [Pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) 被[强制执行](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies)，并且除非您使用 Istio CNI 插件，否则您的 Pod 必须具有允许的 `NET_ADMIN` 功能。Envoy 代理的初始化容器需要此功能。 +如果集群中的 [Pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)被[强制执行](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies)，并且除非您使用 Istio CNI 插件，否则您的 Pod 必须具有允许的 `NET_ADMIN` 功能。Envoy 代理的初始化容器需要此功能。 要检查您的 Pod 是否支持 `NET_ADMIN` 功能，您需要检查其 [service account(服务账户)](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 是否可以使用允许 `NET_ADMIN` 功能的 Pod 安全策略。如果尚未在 Pod 的部署中指定服务帐户，则 Pod 将在其部署的命名空间中使用 `默认` 服务帐户运行。 @@ -85,4 +85,4 @@ $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{' $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done {{< /text >}} -如果您在服务帐户允许的策略的功能列表中看到 `NET_ADMIN` 或者 `*`，则您的 Pod 有权利运行 Istio 初始化容器。否则，您将需要[提供许可认证](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#authorizing-policies)。 \ No newline at end of file +如果您在服务帐户允许的策略的功能列表中看到 `NET_ADMIN` 或者 `*`，则您的 Pod 有权利运行 Istio 初始化容器。否则，您将需要[提供许可认证](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#authorizing-policies)。 diff --git a/content/zh/docs/ops/diagnostic-tools/component-logging/index.md b/content/zh/docs/ops/diagnostic-tools/component-logging/index.md index f8178937df..98681bed31 100644 --- a/content/zh/docs/ops/diagnostic-tools/component-logging/index.md +++ b/content/zh/docs/ops/diagnostic-tools/component-logging/index.md @@ -14,7 +14,7 @@ Istio 组件使用一个灵活的日志框架来构建，该框架提供了许 组件输出的日志信息按 `作用域` 分类，一个作用域代表可以被控制的相关日志信息的整体。根据组件提供的功能，不同的组件具有不同的作用域。所有组件都有 `default` 作用域，该作用域用于未分类的日志信息。 -例如，在撰写本文时，Mixer 有5个作用域，代表了 Mixer 中的不同功能区域： +例如，在撰写本文时，Mixer 有 5 个作用域，代表了 Mixer 中的不同功能区域： - `adapters` - `api` diff --git a/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md b/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md index 0ada300f1e..b80db4a077 100644 --- a/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md +++ b/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md @@ -53,7 +53,7 @@ $ istioctl analyze *.yaml 如果您发现了一些 Istio 配置 “陷阱”，一些导致您的使用出现问题的棘手情况，请提出问题并告知我们。 我们也许可以自动标记此问题，以便其他人可以提前发现并避免该问题。 -为此，请您 [开启一个 issue](https://github.com/istio/istio/issues) 来描述您的情况。例如： +为此，请您[开启一个 issue](https://github.com/istio/istio/issues) 来描述您的情况。例如： - 查看所有 virtual services - 循环查看 virtual services 的 gateways 列表 @@ -73,7 +73,7 @@ $ istioctl analyze *.yaml - **现在支持哪些分析器？** - 我们仍在努力编写分析器文档。目前，您可以在 [Istio 源代码]({{}}/galley/pkg/config/analysis/analyzers) 中看到所有分析器。 + 我们仍在努力编写分析器文档。目前，您可以在 [Istio 源代码]({{}}/galley/pkg/config/analysis/analyzers)中看到所有分析器。 你还可以了解一下目前支持哪些[配置分析消息](/zh/docs/reference/config/analysis/)。 @@ -157,7 +157,7 @@ status: `enableAnalysis` 在后台运行，并将使资源的状态字段保持其当前验证状态的最新状态。请注意，这不能代替 `istioctl analyze`： - 并非所有资源都有自定义状态字段 (例如 Kubernetes `namespace` 资源)，因此附加到这些资源的消息将不会显示验证消息。 -- `enableAnalysis` 仅适用于从1.4开始的 Istio 版本，而 `istioctl analysis` 可以用于较早的版本。 +- `enableAnalysis` 仅适用于从 1.4 开始的 Istio 版本，而 `istioctl analysis` 可以用于较早的版本。 - 尽管可以轻松查看特定资源的问题所在，但要在网格中全面了解验证状态更加困难。 您可以通过以下方式启用此功能： @@ -203,4 +203,4 @@ $ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST {{< text bash >}} $ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST0107,IST0002 -{{< /text >}} \ No newline at end of file +{{< /text >}} diff --git a/content/zh/docs/ops/diagnostic-tools/istioctl-describe/index.md b/content/zh/docs/ops/diagnostic-tools/istioctl-describe/index.md index f45f072682..9da727a4bf 100644 --- a/content/zh/docs/ops/diagnostic-tools/istioctl-describe/index.md +++ b/content/zh/docs/ops/diagnostic-tools/istioctl-describe/index.md @@ -161,7 +161,7 @@ $ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@ ## 验证流量路由{#verifying-traffic-routes} `istioctl describe` 命令还可以展示流量的分隔权重。 -例如，运行如下命令将 90% 的流量路由到 `revis` 服务的 `v1` 子集，将10% 路由到 `v2` 子集： +例如，运行如下命令将 90% 的流量路由到 `revis` 服务的 `v1` 子集，将 10% 路由到 `v2` 子集： {{< text bash >}} $ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-90-10.yaml@ diff --git a/content/zh/docs/ops/diagnostic-tools/istioctl/index.md b/content/zh/docs/ops/diagnostic-tools/istioctl/index.md index d57169adfe..7c9267c28b 100644 --- a/content/zh/docs/ops/diagnostic-tools/istioctl/index.md +++ b/content/zh/docs/ops/diagnostic-tools/istioctl/index.md @@ -95,7 +95,7 @@ $ istioctl proxy-config endpoints [flags] {{< tab name="macOS" category-value="macos" >}} -如果您使用的是 macOS 操作系统的Bash终端，确认已安装 `bash-completion` 包。使用 macOS 下 [brew](https://brew.sh) 包管理器，您可以通过以下命令检查 `bash-completion` 包是否已经安装： +如果您使用的是 macOS 操作系统的 Bash 终端，确认已安装 `bash-completion` 包。使用 macOS 下 [brew](https://brew.sh) 包管理器，您可以通过以下命令检查 `bash-completion` 包是否已经安装： {{< text bash >}} $ brew info bash-completion @@ -140,7 +140,7 @@ $ brew install bash-completion 安装 bash 自动补全文件 -如果您使用 bash，`istioctl` 自动补全的文件位于 `tools` 目录。通过复制 `istioctl.bash` 文件到您的 home 目录，然后添加下行内容到您的 `.bashrc` 文件执行 `istioctl` tab补全文件： +如果您使用 bash，`istioctl` 自动补全的文件位于 `tools` 目录。通过复制 `istioctl.bash` 文件到您的 home 目录，然后添加下行内容到您的 `.bashrc` 文件执行 `istioctl` tab 补全文件： {{< text bash >}} $ source ~/istioctl.bash diff --git a/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md b/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md index 569b881d9d..5a6c2294d9 100644 --- a/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md +++ b/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md @@ -14,7 +14,7 @@ Istio 提供了两个非常有价值的命令来帮助诊断流量管理配置 如果您想尝试以下的命令，需要： * 有一个安装了 Istio 和 Bookinfo 应用的 Kubernetes 集群（正如在 -[安装步骤](/zh/docs/setup/getting-started/) 和 +[安装步骤](/zh/docs/setup/getting-started/)和 [Bookinfo 安装步骤](/zh/docs/examples/bookinfo/#deploying-the-application)所描述的那样）。 或者 diff --git a/content/zh/docs/reference/config/analysis/_index.md b/content/zh/docs/reference/config/analysis/_index.md index cbbbe06add..5e7517780c 100644 --- a/content/zh/docs/reference/config/analysis/_index.md +++ b/content/zh/docs/reference/config/analysis/_index.md @@ -5,4 +5,4 @@ weight: 70 layout: analysis-landing --- -[`istioctl`](/zh/docs/reference/commands/istioctl/#istioctl-analyze) 提供了对 Istio 配置状态的丰富分析，以便标识无效或次优的配置。这是此分析可能产生的错误或警告消息的列表。 \ No newline at end of file +[`istioctl`](/zh/docs/reference/commands/istioctl/#istioctl-analyze) 提供了对 Istio 配置状态的丰富分析，以便标识无效或次优的配置。这是此分析可能产生的错误或警告消息的列表。 diff --git a/content/zh/docs/reference/config/analysis/ist0113/index.md b/content/zh/docs/reference/config/analysis/ist0113/index.md index 53d1c13568..ba9e72cc88 100644 --- a/content/zh/docs/reference/config/analysis/ist0113/index.md +++ b/content/zh/docs/reference/config/analysis/ist0113/index.md @@ -87,7 +87,7 @@ object "my-namespace/my-policy" specifies Plaintext. * 修改策略资源 `my-namespace/my-policy` 以将双向 TLS 作为身份验证模式。 通常，可以通过在资源中添加一个 `peer` 属性来实现，其子属性为 `mtls`。您可以在 - [策略对象参考](/zh/docs/reference/config/security/istio.authentication.v1alpha1/#Policy) 中阅读有关策略对象的更多信息。 + [策略对象参考](/zh/docs/reference/config/security/istio.authentication.v1alpha1/#Policy)中阅读有关策略对象的更多信息。 * 修改目标规则 `istio-system/default-rule`，删除 `ISTIO_MUTUAL` 以不使用双向 TLS。 请注意，`default-rule` 在 `istio-system` 命名空间中， 默认情况下 `istio-system` 命名空间被认为是配置的根命名空间（尽管可以通过资源中的 `rootNamespace` 属性来覆盖它）。 diff --git a/content/zh/docs/reference/config/analysis/ist0118/index.md b/content/zh/docs/reference/config/analysis/ist0118/index.md index 39d502f1f1..1fd4f5057b 100644 --- a/content/zh/docs/reference/config/analysis/ist0118/index.md +++ b/content/zh/docs/reference/config/analysis/ist0118/index.md @@ -3,7 +3,7 @@ title: PortNameIsNotUnderNamingConvention layout: analysis-message --- -当端口不遵循 [Istio 服务端口命名约定](/zh/docs/ops/deployment/requirements/) 或端口未命名时，会出现此消息。 +当端口不遵循 [Istio 服务端口命名约定](/zh/docs/ops/deployment/requirements/)或端口未命名时，会出现此消息。 ## 示例{#example} diff --git a/content/zh/docs/reference/config/analysis/message-format/index.md b/content/zh/docs/reference/config/analysis/message-format/index.md index 024f86f0f1..e169e3e6eb 100644 --- a/content/zh/docs/reference/config/analysis/message-format/index.md +++ b/content/zh/docs/reference/config/analysis/message-format/index.md @@ -20,4 +20,4 @@ title: Analyzer Message Format Error [IST0101] (VirtualService httpbin.default) Referenced gateway not found: "httpbin-gateway-bogus" {{< /text >}} -包含详细描述的 `` 字段也许可以帮你进一步解决问题,对于集群范围的资源，例如 `namespace`，将省略其后缀。 +包含详细描述的 `` 字段也许可以帮你进一步解决问题, 对于集群范围的资源，例如 `namespace`，将省略其后缀。 diff --git a/content/zh/docs/reference/config/installation-options/index.md b/content/zh/docs/reference/config/installation-options/index.md index 5dfb69c419..17a81e6f11 100644 --- a/content/zh/docs/reference/config/installation-options/index.md +++ b/content/zh/docs/reference/config/installation-options/index.md @@ -218,9 +218,9 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | `global.proxy.logLevel` | `""` | `代理的日志级别，应用于网关和 sidecars。如果为空，则使用 "warning"。期望值是：trace\|debug\|info\|warning\|error\|critical\|off` | | `global.proxy.componentLogLevel` | `""` | `每个组件的代理日志级别，应用于网关和 sidecars。如果组件级别没设置，全局的 "logLevel" 将启用。如果为空，"misc:error" 将启用` | | `global.proxy.dnsRefreshRate` | `300s` | `配置类型为 STRICT_DNS 的 Envoy 集群的 DNS 刷新率，必须以秒为单位。例如：300s 是合法的但 5m 不合法。` | -| `global.proxy.protocolDetectionTimeout` | `10ms` | `自动协议检测使用一组试探法来确定连接是否使用TLS（服务端），以及正在使用的应用程序协议（例如 http 和 tcp）。 试探法依赖于客户端发送的第一个数据位。对于像 Mysql，MongoDB 这样的服务器的第一协议来说，在指定的时间段之后，Envoy 将对协议检测超时，默认为非 mTLS 的 TCP 流量。设置此字段以调整 Envoy 将等待客户端发送第一个数据位的时间。（必须 >=1ms）` | +| `global.proxy.protocolDetectionTimeout` | `10ms` | `自动协议检测使用一组试探法来确定连接是否使用 TLS（服务端），以及正在使用的应用程序协议（例如 http 和 tcp）。 试探法依赖于客户端发送的第一个数据位。对于像 Mysql，MongoDB 这样的服务器的第一协议来说，在指定的时间段之后，Envoy 将对协议检测超时，默认为非 mTLS 的 TCP 流量。设置此字段以调整 Envoy 将等待客户端发送第一个数据位的时间。（必须 >=1ms）` | | `global.proxy.privileged` | `false` | `如果设置为 true，istio-proxy 容器将享有 securityContext 的权限。` | -| `global.proxy.enableCoreDump` | `false` | `如果设置，新注入的sidecars将启用 core dumps。` | +| `global.proxy.enableCoreDump` | `false` | `如果设置，新注入的 sidecars 将启用 core dumps。` | | `global.proxy.enableCoreDumpImage` | `ubuntu:xenial` | `镜像用于开启 core dumps。仅在 "enableCoreDump" 设置为 true 时使用。` | | `global.proxy.statusPort` | `15020` | `Pilot 代理健康检查的默认端口。值为 0 将关闭健康检查。` | | `global.proxy.readinessInitialDelaySeconds` | `1` | `readiness 探针的初始延迟秒数。` | @@ -240,7 +240,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | `global.proxy.envoyMetricsService.host` | `` | `例：metrics-service.istio-system` | | `global.proxy.envoyMetricsService.port` | `` | `例：15000` | | `global.proxy.tracer` | `"zipkin"` | `指定使用以下哪一个追踪器：zipkin，lightstep， datadog，stackdriver。 如果使用外部 GCP 的 stackdriver 追踪器，设置环境变量 GOOGLE_APPLICATION_CREDENTIALS 为 GCP 的凭证文件。` | -| `global.proxy_init.image` | `proxy_init` | `proxy_init 容器的基本名称，用于配置iptables。` | +| `global.proxy_init.image` | `proxy_init` | `proxy_init 容器的基本名称，用于配置 iptables。` | | `global.imagePullPolicy` | `IfNotPresent` | | | `global.controlPlaneSecurityEnabled` | `false` | `启用 controlPlaneSecurityEnabled enabled。当密钥被传输时，将导致启动 pod 的延迟，不建议用于测试。` | | `global.disablePolicyChecks` | `true` | `disablePolicyChecks 关闭 mixer 策略检查。如果 mixer.policy.enabled==true 那么 disablePolicyChecks 生效。当在 istio config map 中设置此值时 —— pilot 需要重启才能生效。` | @@ -271,7 +271,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | `global.trustDomain` | `""` | | | `global.meshID` | `""` | `Mesh ID 意为 Mesh 标识符。在网格相互作用的范围内，它应该是唯一的，但不要求它是全局/普遍唯一的。例如，如果下面条件任意一个为真，那么两个网格必须有不同的 Mesh ID：—— 网格将遥测聚合在一个地方 —— 网格将连接在一起 —— 如果管理员期望这些条件中的任何一个在将来可能成为现实，那么策略将被从一个网格写入到另一个引用它的网格，他们需要保证这些网格被指定了不同的 Mesh ID。在一个多集群网格下，每一个集群必须（手动或自动）配置相同的 Mesh ID。如果一个存在的集群“加入”多集群网格，它需要被迁移到新的 mesh ID。详细的迁移还在制定中，在安装后更改 Mesh ID 可能会造成混乱。如果这个网格没有指定一个特定值，Istio 将使用该网格信任域的值。最佳实践是选择适当的信任域值。` | | `global.outboundTrafficPolicy.mode` | `ALLOW_ANY` | | -| `global.sds.enabled` | `false` | `启用 SDS。如果设置为 true，sidecars 的 mTLS 证书将通过 SecretDiscoveryService 分发，而不是使用 K8S secret来挂载。` | +| `global.sds.enabled` | `false` | `启用 SDS。如果设置为 true，sidecars 的 mTLS 证书将通过 SecretDiscoveryService 分发，而不是使用 K8S secret 来挂载。` | | `global.sds.udsPath` | `""` | | | `global.meshNetworks` | `{}` | | | `global.localityLbSetting.enabled` | `true` | | @@ -345,7 +345,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | 关键字 | 默认值 | 描述 | | --- | --- | --- | -| `kiali.enabled` | `false` | `注意当通过 Helm 安装，使用 demo yaml时，默认值为 true。` | +| `kiali.enabled` | `false` | `注意当通过 Helm 安装，使用 demo yaml 时，默认值为 true。` | | `kiali.replicaCount` | `1` | | | `kiali.hub` | `quay.io/kiali` | | | `kiali.image` | `kiali` | | @@ -393,7 +393,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | `mixer.telemetry.rollingMaxUnavailable` | `25%` | | | `mixer.telemetry.sessionAffinityEnabled` | `false` | | | `mixer.telemetry.loadshedding.mode` | `enforce` | `disabled，logonly 或 enforce` | -| `mixer.telemetry.loadshedding.latencyThreshold` | `100ms` | `根据测量值把100ms p50 转换成 1s 以下的 p99。这对于本质上是异步的遥测来说是可以接受的。` | +| `mixer.telemetry.loadshedding.latencyThreshold` | `100ms` | `根据测量值把 100ms p50 转换成 1s 以下的 p99。这对于本质上是异步的遥测来说是可以接受的。` | | `mixer.telemetry.resources.requests.cpu` | `1000m` | | | `mixer.telemetry.resources.requests.memory` | `1G` | | | `mixer.telemetry.resources.limits.cpu` | `4800m` | `最好使用适当的 cpu 分配来实现 Mixer 的水平扩展。我们已经通过实验发现这些数值工作的很好。` | @@ -482,7 +482,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | `security.replicaCount` | `1` | | | `security.rollingMaxSurge` | `100%` | | | `security.rollingMaxUnavailable` | `25%` | | -| `security.enableNamespacesByDefault` | `true` | `确定名称空间没有被密钥创建的 Citadel 标记 ca.istio.io/env 和ca.istio.io/override 标签。` | +| `security.enableNamespacesByDefault` | `true` | `确定名称空间没有被密钥创建的 Citadel 标记 ca.istio.io/env 和 ca.istio.io/override 标签。` | | `security.image` | `citadel` | | | `security.selfSigned` | `true` | `表明自签名 CA 是否使用。` | | `security.createMeshPolicy` | `true` | | @@ -490,7 +490,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | `security.tolerations` | `[]` | | | `security.citadelHealthCheck` | `false` | | | `security.workloadCertTtl` | `2160h` | `90*24 小时 = 2160h` | -| `security.enableNamespacesByDefault` | `true` | `指定 Citadel 的默认行为，如果ca.istio.io/env 或 ca.istio.io/override 标签没有在给定的命名空间发现。例如：考虑一个叫 "target" 的命名空间，既没有 "ca.istio.io/env" 也没有 "ca.istio.io/override" 标签。决定是否为这个 “target” 命名空间的服务账号创建密钥，Citadel 讲参考这一选项。在这个例子中如果值为 "true"，密钥将为 "target" 命名空间生成。如果值是 "false"，Citadel 不会在创建服务账户时产生密钥。` | +| `security.enableNamespacesByDefault` | `true` | `指定 Citadel 的默认行为，如果 ca.istio.io/env 或 ca.istio.io/override 标签没有在给定的命名空间发现。例如：考虑一个叫 "target" 的命名空间，既没有 "ca.istio.io/env" 也没有 "ca.istio.io/override" 标签。决定是否为这个 “target” 命名空间的服务账号创建密钥，Citadel 讲参考这一选项。在这个例子中如果值为 "true"，密钥将为 "target" 命名空间生成。如果值是 "false"，Citadel 不会在创建服务账户时产生密钥。` | | `security.podAntiAffinityLabelSelector` | `[]` | | | `security.podAntiAffinityTermLabelSelector` | `[]` | | @@ -546,4 +546,4 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true | `tracing.service.name` | `http` | | | `tracing.service.type` | `ClusterIP` | | | `tracing.service.externalPort` | `9411` | | -| `tracing.ingress.enabled` | `false` | | \ No newline at end of file +| `tracing.ingress.enabled` | `false` | | diff --git a/content/zh/docs/reference/config/policy-and-telemetry/adapters/_index.md b/content/zh/docs/reference/config/policy-and-telemetry/adapters/_index.md index 4c9092eda2..247bbe875d 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/adapters/_index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/adapters/_index.md @@ -15,4 +15,4 @@ aliases: 下表显示了由每个支持的适配器实现的[模板](/zh/docs/reference/config/policy-and-telemetry/templates)。 -{{< adapter_table >}} \ No newline at end of file +{{< adapter_table >}} diff --git a/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md b/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md index 955ed4c21e..ea03e39009 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md @@ -10,8 +10,8 @@ aliases: ## 底层{#background} -Mixer 配置使用了一种表达式语言(CEXL)去描述 match expressions 以及 [mapping expressions](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attribute-expressions)。 -CEXL 表达式为有类型的[值](https://github.com/istio/api/blob/{{< source_branch_name >}}/policy/v1beta1/value_type.proto)映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。 +Mixer 配置使用了一种表达式语言(CEXL) 去描述 match expressions 以及 [mapping expressions](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attribute-expressions)。 +CEXL 表达式为有类型的[值](https://github.com/istio/api/blob/{{}}/policy/v1beta1/value_type.proto) 映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。 ## 语法{#syntax} diff --git a/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md b/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md index 5d8742a776..1de36153bf 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md @@ -4,7 +4,7 @@ description: 通过 Mixer 从 Istio 导出的默认监控指标。 weight: 50 --- -此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{< github_file >}}/manifests/UPDATING-CHARTS.md)的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/zh/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。 +此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{}}/manifests/UPDATING-CHARTS.md) 的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/zh/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。 我们将首先描述监控指标，然后描述每个指标的标签。 @@ -134,7 +134,7 @@ Istio 为 HTTP、HTTP/2 和 GRPC 流量创建了下列指标： connection_security_policy: conditional((context.reporter.kind | "inbound") == "outbound", "unknown", conditional(connection.mtls | false, "mutual_tls", "none")) {{< /text >}} -* **Response Flags**: 来自代理服务器，包含了响应或者连接的额外细节。如果是 Envoy 代理，可以参考 [Envoy 访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#configuration) 中的 `%RESPONSE_FLAGS%` 相关说明。 +* **Response Flags**: 来自代理服务器，包含了响应或者连接的额外细节。如果是 Envoy 代理，可以参考 [Envoy 访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#configuration)中的 `%RESPONSE_FLAGS%` 相关说明。 {{< text yaml >}} response_flags: context.proxy_error_code | "-" diff --git a/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md b/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md index dd5802b941..f0827ebac2 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md @@ -45,7 +45,7 @@ Mixer 处理不同基础架构后端的灵活性来自其通用插件模型。 caption="Mixer and its Adapters" >}} -了解有关[适配器支持](/zh/docs/reference/config/policy-and-telemetry/adapters/) 的更多信息。 +了解有关[适配器支持](/zh/docs/reference/config/policy-and-telemetry/adapters/)的更多信息。 ## 属性{#attributes} @@ -72,11 +72,11 @@ Mixer 本质上是一种属性处理器。Envoy sidecar 为每个请求调用 Mi 给定的 Istio deployment 具有它了解的固定属性词汇表。该特定词汇表由 deployment 中使用的一组属性生成器确定。尽管专用的 Mixer 适配器也可以生成属性，但 Istio 中主要的属性生成器是 Envoy。 -了解有关 [Istio 中大多数部署可用的通用基准属性集](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/) 的更多信息。 +了解有关 [Istio 中大多数部署可用的通用基准属性集](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)的更多信息。 ### 属性表达式{#attribute-expressions} -当配置[实例](#instances) 时需要使用使用属性表达式。 +当配置[实例](#instances)时需要使用使用属性表达式。 这是一个使用表达式的示例： {{< text yaml >}} @@ -95,7 +95,7 @@ destination_version: destination.labels["version"] | "unknown" 通过上述操作，`destination_version` 标签被分配的值为 `destination.labels["version"]`。 但是，如果属性不存在，将使用 `"unknown"` 值。 -有关更多信息，请参阅[属性表达式](/zh/docs/reference/config/policy-and-telemetry/expression-language/) 页面。 +有关更多信息，请参阅[属性表达式](/zh/docs/reference/config/policy-and-telemetry/expression-language/)页面。 ## 配置模型{#configuration-model} @@ -121,7 +121,7 @@ Rules 由 *match* 表达式和 *actions* 组成。该匹配表达式控制何时 ### Handlers{#handlers} 适配器封装了 Mixer 与特定的外部基础结构后端例如 [Prometheus](https://prometheus.io) 或 [Stackdriver](https://cloud.google.com/logging) 交互所需的逻辑。 -_handler_ 是负责保存适配器所需的配置状态的资源。例如，一个日志适配器可能需要日志收集后端的IP地址和端口。 +_handler_ 是负责保存适配器所需的配置状态的资源。例如，一个日志适配器可能需要日志收集后端的 IP 地址和端口。 这是一个示例，显示了如何为适配器创建 handler。`listchecker` 适配器对照列表检查输入值。 如果将适配器配置为白名单，则在列表中找到输入值时，它将返回成功。 @@ -173,7 +173,7 @@ spec: bounds: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10] {{< /text >}} -每个适配器定义自己的特定格式的配置数据。了解更多有关[全部适配器及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/adapters/) 的信息。 +每个适配器定义自己的特定格式的配置数据。了解更多有关[全部适配器及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/adapters/)的信息。 ### Instances{#instances} @@ -198,7 +198,7 @@ spec: {{< /text >}} 请注意，需要在映射中指定了处理程序配置中期望的所有情况。 -模板定义了各个实例的特定必需内容。了解更多关于[模板及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/templates/) 的信息。 +模板定义了各个实例的特定必需内容。了解更多关于[模板及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/templates/)的信息。 ### Rules{#rules} diff --git a/content/zh/docs/reference/config/security/constraints-and-properties/index.md b/content/zh/docs/reference/config/security/constraints-and-properties/index.md index a4bf3a6773..d2ba65fb0d 100644 --- a/content/zh/docs/reference/config/security/constraints-and-properties/index.md +++ b/content/zh/docs/reference/config/security/constraints-and-properties/index.md @@ -18,7 +18,7 @@ RBAC 策略中的约束和属性已经被 `AuthorizationPolicy` 中的条件取 不支持的键和值将被忽略。 {{< /warning >}} -有关更多信息，请参阅 [授权概念页面](/zh/docs/concepts/security/#authorization)。 +有关更多信息，请参阅[授权概念页面](/zh/docs/concepts/security/#authorization)。 ## 支持的约束{#supported-constraints} diff --git a/content/zh/docs/reference/glossary/attribute.md b/content/zh/docs/reference/glossary/attribute.md index e9944d9fa6..06e0ddedf5 100644 --- a/content/zh/docs/reference/glossary/attribute.md +++ b/content/zh/docs/reference/glossary/attribute.md @@ -13,4 +13,4 @@ source.ip: 192.168.0.1 destination.workload.name: example {{< /text >}} -属性被 Istio 的 [策略和遥测](/zh/docs/reference/config/policy-and-telemetry/) 功能所使用。 +属性被 Istio 的[策略和遥测](/zh/docs/reference/config/policy-and-telemetry/)功能所使用。 diff --git a/content/zh/docs/reference/glossary/identity.md b/content/zh/docs/reference/glossary/identity.md index fad9dabbbf..b3816bc9dc 100644 --- a/content/zh/docs/reference/glossary/identity.md +++ b/content/zh/docs/reference/glossary/identity.md @@ -25,4 +25,4 @@ Istio 在不同的平台上支持以下服务身份： - 本地 （非 Kubernetes）：用户账户、客户服务账户、服务名称、Istio 服务账户，或者 GCP 服务账户。 客户服务账户指现有的服务账户，就像客户身份目录中管理的身份。 -通常，[信任域](/zh/docs/reference/glossary/#trust-domain) 指定身份所属的网格。 +通常，[信任域](/zh/docs/reference/glossary/#trust-domain)指定身份所属的网格。 diff --git a/content/zh/docs/reference/glossary/managed-control-plane.md b/content/zh/docs/reference/glossary/managed-control-plane.md index f6fe98f7db..5c6d9312f1 100644 --- a/content/zh/docs/reference/glossary/managed-control-plane.md +++ b/content/zh/docs/reference/glossary/managed-control-plane.md @@ -2,5 +2,5 @@ title: Managed Control Plane --- -托管控制平面是一个为客户提供管理的 [控制平面](/zh/docs/reference/glossary/#control-plane)。 +托管控制平面是一个为客户提供管理的[控制平面](/zh/docs/reference/glossary/#control-plane)。 托管控制平面降低了用户部署的复杂性，并通常保证一定水平的性能和可用性。 diff --git a/content/zh/docs/reference/glossary/mesh-federation.md b/content/zh/docs/reference/glossary/mesh-federation.md index da032dc35a..6b1d7805c5 100644 --- a/content/zh/docs/reference/glossary/mesh-federation.md +++ b/content/zh/docs/reference/glossary/mesh-federation.md @@ -3,4 +3,4 @@ title: Mesh Federation --- 网格联邦是在网格之间公开服务的一种行为，并且能跨越网格边界进行通信。每一个网格或许会公开其一部分的服务，使一个或多个其他网格使用此公开的服务。 -您可以使用网格联邦来启用网格之间的通信，可参阅 [多个网格部署](/zh/docs/ops/deployment/deployment-models/#multiple-meshes)。 +您可以使用网格联邦来启用网格之间的通信，可参阅[多个网格部署](/zh/docs/ops/deployment/deployment-models/#multiple-meshes)。 diff --git a/content/zh/docs/reference/glossary/multi-mesh.md b/content/zh/docs/reference/glossary/multi-mesh.md index fee66d0817..39e7baf579 100644 --- a/content/zh/docs/reference/glossary/multi-mesh.md +++ b/content/zh/docs/reference/glossary/multi-mesh.md @@ -4,4 +4,4 @@ title: Multi-Mesh Multi-mesh 是由两个或多个[服务网格](/zh/docs/reference/glossary/#service-mesh)组成的部署模型。 每个网格都有独立的命名管理和身份管理，但是您可以通过[网格联邦](/zh/docs/reference/glossary/#mesh-federation)来暴露 -网格之间的服务,最终构成一个多网格部署。 +网格之间的服务, 最终构成一个多网格部署。 diff --git a/content/zh/docs/reference/glossary/multicluster.md b/content/zh/docs/reference/glossary/multicluster.md index 4d828779ad..8b39c184d1 100644 --- a/content/zh/docs/reference/glossary/multicluster.md +++ b/content/zh/docs/reference/glossary/multicluster.md @@ -2,4 +2,4 @@ title: Multicluster --- -Multicluster 是一种部署模型， 由具有多个 [集群](/zh/docs/reference/glossary/#cluster) 的 [网格](/zh/docs/reference/glossary/#service-mesh) 组成。 +Multicluster 是一种部署模型， 由具有多个[集群](/zh/docs/reference/glossary/#cluster)的[网格](/zh/docs/reference/glossary/#service-mesh)组成。 diff --git a/content/zh/docs/reference/glossary/pod.md b/content/zh/docs/reference/glossary/pod.md index e1966ed5eb..0ad5eb9c10 100644 --- a/content/zh/docs/reference/glossary/pod.md +++ b/content/zh/docs/reference/glossary/pod.md @@ -3,4 +3,4 @@ title: Pod --- Pod 中包含了一个或多个共享存储和网络的容器 （例如 [Docker](https://www.docker.com/) 容器）， 以及如何运行容器的规范。 -Pod 是 Istio 的 [Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 部署中的一个 [工作负载实例](#workload-instance)。 +Pod 是 Istio 的 [Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 部署中的一个[工作负载实例](#workload-instance)。 diff --git a/content/zh/docs/reference/glossary/routing-rules.md b/content/zh/docs/reference/glossary/routing-rules.md index d8a9c00cb3..4ed7171d6e 100644 --- a/content/zh/docs/reference/glossary/routing-rules.md +++ b/content/zh/docs/reference/glossary/routing-rules.md @@ -1,6 +1,6 @@ --- title: Routing Rules --- -您在 [虚拟服务](/zh/docs/concepts/traffic-management/#virtual-services) 中配置的路由规则，遵循服务网格定义了请求的路径。 +您在[虚拟服务](/zh/docs/concepts/traffic-management/#virtual-services)中配置的路由规则，遵循服务网格定义了请求的路径。 使用路由规则，您可以定义将寻址到虚拟服务主机的流量路由到指定目标的工作负载。 路由规则使您可以控制流量，以实现如 A/B 测试、金丝雀发布以及按百分比分配流量的分阶段发布等任务。 diff --git a/content/zh/docs/reference/glossary/service-endpoint.md b/content/zh/docs/reference/glossary/service-endpoint.md index 6faada9b89..7f41d2114d 100644 --- a/content/zh/docs/reference/glossary/service-endpoint.md +++ b/content/zh/docs/reference/glossary/service-endpoint.md @@ -1,4 +1,4 @@ --- title: Service Endpoint --- -Service Endpoint 是一个 [service](#service) 的网络可达表现形式。Service endpoint 由 [工作负载实例](#workload-instance) 暴露，但并不是所有的服务都有 service endpoint。 +Service Endpoint 是一个 [service](#service) 的网络可达表现形式。Service endpoint 由[工作负载实例](#workload-instance)暴露，但并不是所有的服务都有 service endpoint。 diff --git a/content/zh/docs/reference/glossary/service-producer.md b/content/zh/docs/reference/glossary/service-producer.md index 4d8c912412..1c06eb5b29 100644 --- a/content/zh/docs/reference/glossary/service-producer.md +++ b/content/zh/docs/reference/glossary/service-producer.md @@ -1,4 +1,4 @@ --- title: Service Producer --- -创建[服务](#service)的 pilot-agent。 \ No newline at end of file +创建[服务](#service)的 pilot-agent。 diff --git a/content/zh/docs/reference/glossary/service-version.md b/content/zh/docs/reference/glossary/service-version.md index 1315c74104..0a757acfd5 100644 --- a/content/zh/docs/reference/glossary/service-version.md +++ b/content/zh/docs/reference/glossary/service-version.md @@ -1,4 +1,4 @@ --- title: Service Version --- -区分一系列[服务](#service)，通常通过 [工作负载](#workload) 二进制文件的不同版本来帮助确定。在一些场景多服务版本是需要的，比如 A/B 测试和金丝雀发布。 +区分一系列[服务](#service)，通常通过[工作负载](#workload)二进制文件的不同版本来帮助确定。在一些场景多服务版本是需要的，比如 A/B 测试和金丝雀发布。 diff --git a/content/zh/docs/reference/glossary/service.md b/content/zh/docs/reference/glossary/service.md index 16ccc309ef..58b6eb5c68 100644 --- a/content/zh/docs/reference/glossary/service.md +++ b/content/zh/docs/reference/glossary/service.md @@ -1,7 +1,7 @@ --- title: Service --- -使用 [服务名称](#service-name)标识一组具有关联行为的服务 [服务网格](#service-mesh)， +使用[服务名称](#service-name)标识一组具有关联行为的服务[服务网格](#service-mesh)， 并使用这些名称应用 Istio 策略（例如负载均衡和路由）。 -服务通常由一个或多个 [服务 Endpoint](#service-endpoint)实现，并且或许包含多个 +服务通常由一个或多个[服务 Endpoint](#service-endpoint) 实现，并且或许包含多个 [服务版本](#service-version)。 diff --git a/content/zh/docs/reference/glossary/workload-instance.md b/content/zh/docs/reference/glossary/workload-instance.md index ce6fdfca74..6ab504ed33 100644 --- a/content/zh/docs/reference/glossary/workload-instance.md +++ b/content/zh/docs/reference/glossary/workload-instance.md @@ -13,4 +13,4 @@ title: Workload Instance - 标签 - 主体 -通过访问 [`source.*` 和 `destination.*` 下面的属性](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)，在 Istio 的策略和遥测配置功能中，可以用到这些属性。 \ No newline at end of file +通过访问 [`source.*` 和 `destination.*` 下面的属性](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)，在 Istio 的策略和遥测配置功能中，可以用到这些属性。 diff --git a/content/zh/docs/setup/additional-setup/config-profiles/index.md b/content/zh/docs/setup/additional-setup/config-profiles/index.md index 063b021dd5..bef13c46a9 100644 --- a/content/zh/docs/setup/additional-setup/config-profiles/index.md +++ b/content/zh/docs/setup/additional-setup/config-profiles/index.md @@ -51,7 +51,7 @@ keywords: [profiles,install,helm] ## 多集群配置{#multicluster-profiles} -Istio 提供了两个附加的内置配置文件，被专门用于配置[多集群部署](/zh/docs/ops/deployment/deployment-models/#multiple-clusters): +Istio 提供了两个附加的内置配置文件，被专门用于配置[多集群部署](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) : 1. **remote**: 用于配置通过[共享控制平面](/zh/docs/setup/install/multicluster/shared-vpn/)搭建的多集群网格里的远程集群。 diff --git a/content/zh/docs/setup/getting-started/index.md b/content/zh/docs/setup/getting-started/index.md index 225432fe33..4c98396884 100644 --- a/content/zh/docs/setup/getting-started/index.md +++ b/content/zh/docs/setup/getting-started/index.md @@ -9,7 +9,7 @@ aliases: keywords: [getting-started, install, bookinfo, quick-start, kubernetes] --- -本指南面向 Istio 的新用户，让您通过安装 `demo` [配置文件](/zh/docs/setup/additional-setup/config-profiles/) 快速评估 Istio。 +本指南面向 Istio 的新用户，让您通过安装 `demo` [配置文件](/zh/docs/setup/additional-setup/config-profiles/)快速评估 Istio。 如果您已经熟悉 Istio 或对安装其他配置文件或更高级的[部署模型](/zh/docs/ops/deployment/deployment-models/)感兴趣， 请遵循[使用 {{< istioctl >}} 的安装说明文档](/zh/docs/setup/install/istioctl)。 @@ -32,7 +32,7 @@ Istio {{< istio_version >}} 已经在 Kubernetes 版本 {{< supported_kubernetes - 通过选择合适的 [platform-specific setup instructions](/zh/docs/setup/platform-setup/) 来创建一个集群。 -有些平台提供了 {{< gloss >}}managed control plane{{< /gloss >}}，您可以使用它来代替手动安装Istio。 如果您选择的平台支持这种方式，并且您选择使用它，那么，在创建完集群后，您将完成 Istio 的安装。因此，可以跳过以下说明。 +有些平台提供了 {{< gloss >}}managed control plane{{< /gloss >}}，您可以使用它来代替手动安装 Istio。 如果您选择的平台支持这种方式，并且您选择使用它，那么，在创建完集群后，您将完成 Istio 的安装。因此，可以跳过以下说明。 ## 下载 Istio {#download} @@ -128,7 +128,7 @@ Istio {{< istio_version >}} 已经在 Kubernetes 版本 {{< supported_kubernetes 应用程序必须使用 HTTP/1.1 或 HTTP/2.0 协议用于 HTTP 通信；HTTP/1.0 不支持。 {{< /warning >}} -当使用 `kubectl apply` 来部署应用时，如果 pod 启动在标有 `istio-injection=enabled` 的命名空间中，那么，[Istio sidecar 注入器](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection) 将自动注入 Envoy 容器到应用的 pod 中： +当使用 `kubectl apply` 来部署应用时，如果 pod 启动在标有 `istio-injection=enabled` 的命名空间中，那么，[Istio sidecar 注入器](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection)将自动注入 Envoy 容器到应用的 pod 中： {{< text bash >}} $ kubectl label namespace istio-injection=enabled @@ -142,7 +142,7 @@ $ istioctl kube-inject -f .yaml | kubectl apply -f - {{< /text >}} 如果您不确定要从哪开始，可以先[部署 Bookinfo 示例](/zh/docs/examples/bookinfo/)，它会让您体验到 Istio 的流量路由、故障注入、速率限制等功能。 -然后您可以根据您的兴趣浏览各种各样的[Istio 任务](/zh/docs/tasks/)。 +然后您可以根据您的兴趣浏览各种各样的 [Istio 任务](/zh/docs/tasks/)。 下列任务都是初学者开始学习的好入口： @@ -164,7 +164,7 @@ $ istioctl kube-inject -f .yaml | kubectl apply -f - - [Pod 需求](/zh/docs/ops/deployment/requirements/) - [常规安装说明](/zh/docs/setup/) -使用 Istio 过程中有任何问题，请来信告知我们，并欢迎您加入我们的 [社区](/zh/about/community/join/)。 +使用 Istio 过程中有任何问题，请来信告知我们，并欢迎您加入我们的[社区](/zh/about/community/join/)。 ## 卸载 {#uninstall} diff --git a/content/zh/docs/setup/install/helm/index.md b/content/zh/docs/setup/install/helm/index.md index b6fbfeac82..6bc5c13780 100644 --- a/content/zh/docs/setup/install/helm/index.md +++ b/content/zh/docs/setup/install/helm/index.md @@ -13,7 +13,7 @@ icon: helm {{< warning >}} Helm 的安装方法已被弃用。 -请改用 [使用 {{< istioctl >}} 安装](/zh/docs/setup/install/istioctl/)。 +请改用[使用 {{< istioctl >}} 安装](/zh/docs/setup/install/istioctl/)。 {{< /warning >}} 请按照本指南安装和配置 Istio 网格，以进行深入评估或用于生产。 @@ -51,8 +51,8 @@ $ helm repo add istio.io https://storage.googleapis.com/istio-release/releases/{ 将目录切换到 Istio 发行版的根目录，然后在以下两个**互斥**选项选择一种安装： -1. 如果您不使用 Tiller 部署 Istio，请查看 [方案 1](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template)。 -1. 如果您使用 [Helm 的 Tiller pod](https://helm.sh/) 来管理 Istio 发行版, 请查看 [方案 2](/zh/docs/setup/install/helm/#option-2-install-with-helm-and-tiller-via-helm-install)。 +1. 如果您不使用 Tiller 部署 Istio，请查看[方案 1](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template)。 +1. 如果您使用 [Helm 的 Tiller pod](https://helm.sh/) 来管理 Istio 发行版, 请查看[方案 2](/zh/docs/setup/install/helm/#option-2-install-with-helm-and-tiller-via-helm-install)。 {{< tip >}} 默认情况下，Istio 使用 `LoadBalancer` 服务类型。 而有些平台是不支持 `LoadBalancer` @@ -80,12 +80,12 @@ $ helm repo add istio.io https://storage.googleapis.com/istio-release/releases/{ 1. {{< boilerplate verify-crds >}} -1. 选择一个 [配置文件](/zh/docs/setup/additional-setup/config-profiles/) +1. 选择一个[配置文件](/zh/docs/setup/additional-setup/config-profiles/) 接着部署与您选择的配置文件相对应的 Istio 核心组件。 我们建议在生产环境使用**默认**的配置文件： {{< tip >}} - 您可以添加一个或多个 `--set =` 来进一步自定义 helm 命令的 [安装选项](/zh/docs/reference/config/installation-options/) 。 + 您可以添加一个或多个 `--set =` 来进一步自定义 helm 命令的[安装选项](/zh/docs/reference/config/installation-options/) 。 {{< /tip >}} {{< tabset category-name="helm_profile" >}} @@ -172,7 +172,7 @@ $ helm template install/kubernetes/helm/istio --name istio --namespace istio-sys 1. {{< boilerplate verify-crds >}} -1. 选择一个 [配置文件](/zh/docs/setup/additional-setup/config-profiles/) +1. 选择一个[配置文件](/zh/docs/setup/additional-setup/config-profiles/) 接着部署与您选择的配置文件相对应的 `istio` 的核心组件。 我们建议在生成环境部署中使用**默认**配置文件: @@ -239,7 +239,7 @@ $ helm install install/kubernetes/helm/istio --name istio --namespace istio-syst ## 验证安装 -1. 查询 [配置文件](/zh/docs/setup/additional-setup/config-profiles/) 的组件表，验证是否已部署了与您选择的配置文件相对应的 Kubernetes 服务 +1. 查询[配置文件](/zh/docs/setup/additional-setup/config-profiles/)的组件表，验证是否已部署了与您选择的配置文件相对应的 Kubernetes 服务 {{< text bash >}} $ kubectl get svc -n istio-system @@ -311,7 +311,7 @@ $ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=k {{< /tabset >}} -- 如果您使用的Helm 和 Tiller 安装的 Istio,使用如下命令卸载： +- 如果您使用的 Helm 和 Tiller 安装的 Istio, 使用如下命令卸载： {{< text bash >}} $ helm delete --purge istio @@ -328,8 +328,8 @@ Istio 的设计中，其自定义资源以 CRD 的形式存在于 Kubernetes 环 CRD 的删除，意味着删掉所有的用户配置。 {{< /warning >}} -`istio-init` Chart 包含了 `istio-init/files` 目录中的所有原始 CRD。下载该 Chart 之后，可以简单的使用 `kubectl` 删除 CRD。要永久删除 Istio 的 CRD 以及所有 Istio 配置,请运行如下命令 +`istio-init` Chart 包含了 `istio-init/files` 目录中的所有原始 CRD。下载该 Chart 之后，可以简单的使用 `kubectl` 删除 CRD。要永久删除 Istio 的 CRD 以及所有 Istio 配置, 请运行如下命令 {{< text bash >}} $ kubectl delete -f install/kubernetes/helm/istio-init/files -{{< /text >}} \ No newline at end of file +{{< /text >}} diff --git a/content/zh/docs/setup/install/istioctl/index.md b/content/zh/docs/setup/install/istioctl/index.md index d117656829..a673a80c1b 100644 --- a/content/zh/docs/setup/install/istioctl/index.md +++ b/content/zh/docs/setup/install/istioctl/index.md @@ -6,12 +6,12 @@ keywords: [istioctl, kubernetes] --- 请按照本指南安装和配置 Istio 网格，以进行深入评估或用于生产。 -如果您刚接触 Istio 或者只是要简单试用，请参考 [开始](/zh/docs/setup/getting-started) 文档进行操作。 +如果您刚接触 Istio 或者只是要简单试用，请参考[开始](/zh/docs/setup/getting-started)文档进行操作。 本指南使用可以高度自定义 Istio 控制平面和数据平面的 [`istioctl`](/zh/docs/reference/commands/istioctl/) 命令行工具。 该命令行工具具有用户输入校验功能，可以防止错误的安装和自定义选项。 -使用这些命令说明，您可以选择 Istio 的任何内置 [配置文件](/zh/docs/setup/additional-setup/config-profiles/) 然后 +使用这些命令说明，您可以选择 Istio 的任何内置[配置文件](/zh/docs/setup/additional-setup/config-profiles/)然后 根据您的特定需求进一步自定义配置。 ## 前提条件{#prerequisites} @@ -19,12 +19,12 @@ keywords: [istioctl, kubernetes] 开始之前，请检查以下前提条件： 1. [下载 Istio 发行版本](/zh/docs/setup/getting-started/#download)。 -1. 执行任何必要的 [特定于平台的设置](/zh/docs/setup/platform-setup/)。 +1. 执行任何必要的[特定于平台的设置](/zh/docs/setup/platform-setup/)。 1. 检查 [Pods 和 Services 的要求](/zh/docs/ops/deployment/requirements/)。 ## 使用默认配置文件安装 Istio{#install-Istio-using-the-default-profile} -最简单的选择是安装 `default` Istio [配置文件](/zh/docs/setup/additional-setup/config-profiles/) 使用以下命令： +最简单的选择是安装 `default` Istio [配置文件](/zh/docs/setup/additional-setup/config-profiles/)使用以下命令： {{< text bash >}} $ istioctl manifest apply @@ -226,7 +226,7 @@ $ istioctl verify-install -f $HOME/generated-manifest.yaml ## 定制配置{#customizing-the-configuration} -除了安装 Istio 的任何内置组件 [配置文件](/zh/docs/setup/additional-setup/config-profiles/)， +除了安装 Istio 的任何内置组件[配置文件](/zh/docs/setup/additional-setup/config-profiles/)， `istioctl manifest` 提供了用于自定义配置的完整 API。 - [The `IstioOperator` API](/zh/docs/reference/config/istio.operator.v1alpha1/) @@ -369,7 +369,7 @@ spec: 1. [Strategy](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 1. [Env](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) -所有这些 Kubernetes 设置都使用 Kubernetes API 定义，因此 [Kubernetes文档](https://kubernetes.io/docs/concepts/) 可以用作参考。 +所有这些 Kubernetes 设置都使用 Kubernetes API 定义，因此 [Kubernetes 文档](https://kubernetes.io/docs/concepts/)可以用作参考。 以下示例覆盖文件调整了 Pilot 的 resource 和 pod 水平自动伸缩的设置： diff --git a/content/zh/docs/setup/install/multicluster/gateways/index.md b/content/zh/docs/setup/install/multicluster/gateways/index.md index a58b44f05f..8b64e0c0af 100644 --- a/content/zh/docs/setup/install/multicluster/gateways/index.md +++ b/content/zh/docs/setup/install/multicluster/gateways/index.md @@ -10,7 +10,7 @@ aliases: keywords: [kubernetes,multicluster,gateway] --- -请参照本指南安装具有副本集 [控制平面](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 实例的 +请参照本指南安装具有副本集[控制平面](/zh/docs/ops/deployment/deployment-models/#multiple-clusters)实例的 Istio [多集群部署](/zh/docs/ops/deployment/deployment-models/#control-plane-models)，并在每个群集中使用 gateway 来提供跨集群连接服务。 在此配置中，每个集群都使用它自己的 Istio 控制平面来完成安装，并管理自己的 endpoint， @@ -79,7 +79,7 @@ Istio [多集群部署](/zh/docs/ops/deployment/deployment-models/#control-plane -f install/kubernetes/operator/examples/multicluster/values-istio-multicluster-gateways.yaml {{< /text >}} - 想了解更多细节和自定义选项，请参考 [使用 Istioctl 安装](/zh/docs/setup/install/istioctl/)。 + 想了解更多细节和自定义选项，请参考[使用 Istioctl 安装](/zh/docs/setup/install/istioctl/)。 ## 配置 DNS{#setup-DNS} @@ -274,7 +274,7 @@ service entry 使用的 host 应该采用如下格式：`..glob 如果 `cluster2` 运行在一个不支持对外负载均衡的环境下，您需要使用 nodePort 访问 gateway。 有关获取使用 IP 的说明，请参见教程：[控制 Ingress 流量](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)。 在后面的步骤中，您还需要将 service entry 的 endpoint 的端口从 15443 修改为其对应的 nodePort - （例如，`kubectl --context=$CTX_CLUSTER2 get svc -n istio-system istio-ingressgateway -o=jsonpath='{.spec.ports[?(@.port==15443)].nodePort}'`）。 + （例如，`kubectl --context=$CTX_CLUSTER2 get svc -n istio-system istio-ingressgateway -o=jsonpath='{.spec.ports [?(@.port==15443)].nodePort}'`）。 {{< /tip >}} diff --git a/content/zh/docs/setup/install/multicluster/shared-gateways/index.md b/content/zh/docs/setup/install/multicluster/shared-gateways/index.md index 2146c6211a..4acf9d1ab5 100644 --- a/content/zh/docs/setup/install/multicluster/shared-gateways/index.md +++ b/content/zh/docs/setup/install/multicluster/shared-gateways/index.md @@ -49,7 +49,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置 1. 在 `cluster1` 中部署 Istio： {{< warning >}} - 当启用多集群所需的附加组件时，Istio 控制平面的资源占用量可能会增长，甚至超过 Kubernetes 集群安装[平台安装](/zh/docs/setup/platform-setup/) 步骤中的默认容量。 + 当启用多集群所需的附加组件时，Istio 控制平面的资源占用量可能会增长，甚至超过 Kubernetes 集群安装[平台安装](/zh/docs/setup/platform-setup/)步骤中的默认容量。 如果因 CPU 或内存资源不足导致 Istio 服务无法调度，可以考虑在集群中添加更多节点，或按需升级为更大内存容量的实例。 {{< /warning >}} @@ -117,7 +117,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置 $ kubectl config use-context $CTX_CLUSTER1 {{< /text >}} - 1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports) 中的说明，设置环境变量 `INGRESS_HOST` 及 `SECURE_INGRESS_PORT`。 + 1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的说明，设置环境变量 `INGRESS_HOST` 及 `SECURE_INGRESS_PORT`。 1. 恢复之前的 `kubectl` 上下文： @@ -201,7 +201,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置 $ kubectl config use-context $CTX_CLUSTER2 {{< /text >}} - 1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports) 中的说明，设置环境变量 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT`。 + 1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的说明，设置环境变量 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT`。 1. 恢复之前的 `kubectl` 上下文： diff --git a/content/zh/docs/setup/install/multicluster/shared-vpn/index.md b/content/zh/docs/setup/install/multicluster/shared-vpn/index.md index c8b01ddb9a..b766802648 100644 --- a/content/zh/docs/setup/install/multicluster/shared-vpn/index.md +++ b/content/zh/docs/setup/install/multicluster/shared-vpn/index.md @@ -222,7 +222,7 @@ Kubernetes secret 数据密钥必须符合 `DNS-1123 subdomain` [格式](https:/ 对远程集群执行下列步骤。 -在开始之前，请按照[设置环境变量部分](#environment-var)中的说明设置端点IP环境变量。 +在开始之前，请按照[设置环境变量部分](#environment-var)中的说明设置端点 IP 环境变量。 1. 安装 Istio 远程配置文件： diff --git a/content/zh/docs/setup/install/multicluster/simplified/index.md b/content/zh/docs/setup/install/multicluster/simplified/index.md index 24b1542548..77b8646220 100644 --- a/content/zh/docs/setup/install/multicluster/simplified/index.md +++ b/content/zh/docs/setup/install/multicluster/simplified/index.md @@ -1,5 +1,5 @@ --- -title: 简化地多集群安装 [实验性] +title: 简化地多集群安装[实验性] description: 配置一个跨多个 Kubernetes 集群的 Istio 网格。 weight: 1 keywords: [kubernetes,multicluster] @@ -78,7 +78,7 @@ keywords: [kubernetes,multicluster] $ cd ${WORKDIR} {{< /text >}} -1. 下载[设置脚本]({{< github_file >}}/samples/multicluster/setup-mesh.sh)到您的工作目录。 +1. 下载[设置脚本]({{}}/samples/multicluster/setup-mesh.sh) 到您的工作目录。 该脚本负责创建必要的证书以启用跨集群通信，它为您准备了默认配置文件，并将在每个集群中部署和配置 Istio。 1. 最后，运行下载的脚本以准备网格。这会创建一个将用于保护网格中群集之间的通信安全的根密钥和证书，以及用于控制所有群集上部署的 Istio 的配置的 `base.yaml` 文件： diff --git a/content/zh/docs/setup/platform-setup/MicroK8s/index.md b/content/zh/docs/setup/platform-setup/MicroK8s/index.md index a96a4fc021..9c54880dca 100644 --- a/content/zh/docs/setup/platform-setup/MicroK8s/index.md +++ b/content/zh/docs/setup/platform-setup/MicroK8s/index.md @@ -34,4 +34,4 @@ keywords: [platform-setup,kubernetes,MicroK8s] {{< text bash >}} $ watch microk8s.kubectl get all --all-namespaces - {{< /text >}} \ No newline at end of file + {{< /text >}} diff --git a/content/zh/docs/setup/platform-setup/azure/index.md b/content/zh/docs/setup/platform-setup/azure/index.md index 377dd6b90b..56b8e34779 100644 --- a/content/zh/docs/setup/platform-setup/azure/index.md +++ b/content/zh/docs/setup/platform-setup/azure/index.md @@ -54,7 +54,7 @@ keywords: [platform-setup,azure] ## AKS-Engine -1. [跟随这些命令](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/quickstart.md#install-aks-engine) 来获取和安装 `aks-engine` 的二进制版本。 +1. [跟随这些命令](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/quickstart.md#install-aks-engine)来获取和安装 `aks-engine` 的二进制版本。 1. 下载支持部署 Istio 的 `aks-engine` API 模型定义： @@ -62,10 +62,10 @@ keywords: [platform-setup,azure] $ wget https://raw.githubusercontent.com/Azure/aks-engine/master/examples/service-mesh/istio.json {{< /text >}} - 注意：可能使用其他可以和 Istio 一起工作的 api 模型定义。MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 准入控制标识和 RBAC 被默认打开。从 [aks-engine api 模型默认值](https://github.com/Azure/aks-engine/blob/master/docs/topics/clusterdefinitions.md) 获取更多信息。 + 注意：可能使用其他可以和 Istio 一起工作的 api 模型定义。MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 准入控制标识和 RBAC 被默认打开。从 [aks-engine api 模型默认值](https://github.com/Azure/aks-engine/blob/master/docs/topics/clusterdefinitions.md)获取更多信息。 1. 使用 `istio.json` 模板来部署你的集群。你能发现对于参数的参考在 - [官方文档](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/deploy.md#step-3-edit-your-cluster-definition) 中。 + [官方文档](https://github.com/Azure/aks-engine/blob/master/docs/tutorials/deploy.md#step-3-edit-your-cluster-definition)中。 | 参数 | 期望值 | |---------------------------------------|----------------------------| diff --git a/content/zh/docs/setup/platform-setup/docker/index.md b/content/zh/docs/setup/platform-setup/docker/index.md index 9a4adc65c0..1018f22fdd 100644 --- a/content/zh/docs/setup/platform-setup/docker/index.md +++ b/content/zh/docs/setup/platform-setup/docker/index.md @@ -13,7 +13,7 @@ keywords: [platform-setup,kubernetes,docker-desktop] 1. 如果你想在 Docker Desktop 下运行 Istio，则需要安装受支持的 Kubernetes 版本 ({{< supported_kubernetes_versions >}})。 -1. 如果你想在 Docker Desktop 内置的 Kubernetes 下运行Istio，你可能需要在 Docker 首选项的 Advanced 面板下增加 Docker 的内存限制。设置可用的内存资源为 8.0 `GB` 以及 4 核心 `CPUs`. +1. 如果你想在 Docker Desktop 内置的 Kubernetes 下运行 Istio，你可能需要在 Docker 首选项的 Advanced 面板下增加 Docker 的内存限制。设置可用的内存资源为 8.0 `GB` 以及 4 核心 `CPUs`. {{< image width="60%" link="./dockerprefs.png" caption="Docker Preferences" >}} diff --git a/content/zh/docs/setup/platform-setup/gardener/index.md b/content/zh/docs/setup/platform-setup/gardener/index.md index 1410c02add..94259e4ad6 100644 --- a/content/zh/docs/setup/platform-setup/gardener/index.md +++ b/content/zh/docs/setup/platform-setup/gardener/index.md @@ -34,7 +34,7 @@ keywords: [platform-setup,kubernetes,gardener,sap] ### 创建 Kubernetes 集群{#creating-a-Kubernetes-cluster} -您可以通过提供集群规范 yaml 文件，使用 `kubectl` cli 创建集群。 您可以在 [这博客里](https://github.com/gardener/gardener/blob/master/example/90-shoot.yaml) 找到关于 GCP 的示例。 +您可以通过提供集群规范 yaml 文件，使用 `kubectl` cli 创建集群。 您可以在[这博客里](https://github.com/gardener/gardener/blob/master/example/90-shoot.yaml)找到关于 GCP 的示例。 确保名称空间与您的项目名称空间匹配。然后只需将准备好的 "shoot" 群集 CRD 与 `kubectl` 配合使用： {{< text bash >}} diff --git a/content/zh/docs/setup/platform-setup/gke/index.md b/content/zh/docs/setup/platform-setup/gke/index.md index f01faf34f6..a1d2df9f35 100644 --- a/content/zh/docs/setup/platform-setup/gke/index.md +++ b/content/zh/docs/setup/platform-setup/gke/index.md @@ -35,7 +35,7 @@ Google 为 GKE 提供了一个插件， {{< tip >}} 默认安装 Mixer 要求节点的 vCPU 大于 1。 - 如果您要使用 [演示配置文件](/zh/docs/setup/additional-setup/config-profiles/)， + 如果您要使用[演示配置文件](/zh/docs/setup/additional-setup/config-profiles/)， 您可以删除 `--machine-type` 参数，以使用较小 `n1-standard-1` 机器配置代替。 {{< /tip >}} diff --git a/content/zh/docs/setup/platform-setup/minikube/index.md b/content/zh/docs/setup/platform-setup/minikube/index.md index 7626339787..f31eb32bbc 100644 --- a/content/zh/docs/setup/platform-setup/minikube/index.md +++ b/content/zh/docs/setup/platform-setup/minikube/index.md @@ -15,7 +15,7 @@ keywords: [platform-setup,kubernetes,minikube] - 运行 minikube 需要管理员权限。 -- 如果要启用 [秘钥发现服务](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration)（SDS），需要为 Kubernetes deployment 添加[额外的配置](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)。 +- 如果要启用[秘钥发现服务](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration)（SDS），需要为 Kubernetes deployment 添加[额外的配置](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)。 访问 [`api-server` 参考文档](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)查看最新的可选参数。 ## 安装步骤{#installation-steps} diff --git a/content/zh/docs/setup/platform-setup/oci/index.md b/content/zh/docs/setup/platform-setup/oci/index.md index f230878de2..1cfa07e2ca 100644 --- a/content/zh/docs/setup/platform-setup/oci/index.md +++ b/content/zh/docs/setup/platform-setup/oci/index.md @@ -11,7 +11,7 @@ keywords: [platform-setup,kubernetes,oke,oci,oracle] 根据如下介绍，为 Istio 配置 OKE 集群环境。 -1. 在您的 OCI 租户中，创建一个新的 OKE 集群。最简单的方式就是使用 [web 控制台](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengcreatingclusterusingoke.htm) 中的 'Quick Cluster' 选项。您也可以使用下面的 [OCI cli](https://docs.cloud.oracle.com/iaas/Content/API/SDKDocs/cliinstall.htm) 命令: +1. 在您的 OCI 租户中，创建一个新的 OKE 集群。最简单的方式就是使用 [web 控制台](https://docs.cloud.oracle.com/iaas/Content/ContEng/Tasks/contengcreatingclusterusingoke.htm)中的 'Quick Cluster' 选项。您也可以使用下面的 [OCI cli](https://docs.cloud.oracle.com/iaas/Content/API/SDKDocs/cliinstall.htm) 命令: {{< text bash >}} $ oci ce cluster create --name oke-cluster1 \ diff --git a/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md b/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md index 918ca74ebf..4b270bde52 100644 --- a/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md +++ b/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md @@ -116,7 +116,7 @@ Pilot, Galley, 策略, 遥测和 Sidecar 注入器。 --namespace istio-system | kubectl apply -f - {{< /text >}} - 您必须使用与首次 [安装 Istio](/zh/docs/setup/install/helm) 相同的配置。 + 您必须使用与首次[安装 Istio](/zh/docs/setup/install/helm) 相同的配置。 滚动更新进程会将所有的部署组件和 configmap 升级到新版本。当此进程执行完毕后，您的 Istio 控制平面将会升级到新版本。 diff --git a/content/zh/docs/setup/upgrade/istioctl-upgrade/index.md b/content/zh/docs/setup/upgrade/istioctl-upgrade/index.md index 31bf605376..1d097652de 100644 --- a/content/zh/docs/setup/upgrade/istioctl-upgrade/index.md +++ b/content/zh/docs/setup/upgrade/istioctl-upgrade/index.md @@ -11,7 +11,7 @@ keywords: [kubernetes,upgrading] 升级命令也可为 Istio 降级。 -查看 [`istioctl` 升级参考](/zh/docs/reference/commands/istioctl/#istioctl-experimental-upgrade) 来获取 `istioctl experimental upgrade` 命令的更多功能。 +查看 [`istioctl` 升级参考](/zh/docs/reference/commands/istioctl/#istioctl-experimental-upgrade)来获取 `istioctl experimental upgrade` 命令的更多功能。 ## 升级前置条件{#upgrade-prerequisites} @@ -19,7 +19,7 @@ keywords: [kubernetes,upgrading] * 已安装 Istio 1.3.3 或更高版本。 -* Istio 是 [使用 {{< istioctl >}}](/zh/docs/setup/install/istioctl/) 命令安装的。 +* Istio 是[使用 {{< istioctl >}}](/zh/docs/setup/install/istioctl/) 命令安装的。 ## 升级步骤{#upgrade-steps} @@ -77,7 +77,7 @@ keywords: [kubernetes,upgrading] * 已安装 Istio 1.4 或更高版本。 -* Istio 是 [使用 {{< istioctl >}}](/zh/docs/setup/install/istioctl/) 命令安装的。 +* Istio 是[使用 {{< istioctl >}}](/zh/docs/setup/install/istioctl/) 命令安装的。 * 降级命令 `istioctl` 的版本需要与要降级到的 Istio 版本相对应。例如：要将 Istio 从版本 1.4 降级到 1.3.3，需要使用 1.3.3 版本的 `istioctl` 命令。 diff --git a/content/zh/docs/tasks/observability/distributed-tracing/jaeger/index.md b/content/zh/docs/tasks/observability/distributed-tracing/jaeger/index.md index 7160af964a..eb5775b29c 100644 --- a/content/zh/docs/tasks/observability/distributed-tracing/jaeger/index.md +++ b/content/zh/docs/tasks/observability/distributed-tracing/jaeger/index.md @@ -7,7 +7,7 @@ aliases: - /zh/docs/tasks/telemetry/distributed-tracing/jaeger/ --- -完成此任务后，您将了解如何让您的应用程序参与 [Jaeger](https://www.jaegertracing.io/)的追踪， +完成此任务后，您将了解如何让您的应用程序参与 [Jaeger](https://www.jaegertracing.io/) 的追踪， 而不管您用来构建应用程序的语言、框架或平台是什么。 此任务使用 [Bookinfo](/zh/docs/examples/bookinfo/) 作为演示的应用程序。 @@ -20,7 +20,7 @@ aliases: a) 通过设置 `--set values.tracing.enabled = true` 安装选项以启用 tracing 的“开箱即用”的演示/测试环境 - b) 通过使用现有 Jaeger 实例（例如使用 [operator](https://github.com/jaegertracing/jaeger-operator)进行创建，然后设置`--set values.global.tracer.zipkin.address = .:9411` 的安装选项。 + b) 通过使用现有 Jaeger 实例（例如使用 [operator](https://github.com/jaegertracing/jaeger-operator) 进行创建，然后设置`--set values.global.tracer.zipkin.address = .:9411` 的安装选项。 {{< warning >}} 启用跟踪时，可以设置 Istio 用于跟踪的采样率。 diff --git a/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md b/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md index 335fb54ac6..581aac662d 100644 --- a/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md +++ b/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md @@ -104,7 +104,7 @@ LightStep 可以分析来自大规模生产级软件的 100% 未采样的事务 这个截图显示了该追踪是由一组 span 组成。每一个 span 对应着在执行 `/productpage` 请求期间调用的一个 Bookinfo 服务。 -追踪中的两个 spans 表示一个 RPC请求。例如，从 `productpage` 到 `reviews` 的请求调用，以操作标签 `reviews.default.svc.cluster.local:9080/*` 和服务标签 `productpage.default: proxy client` 的 span 开始。该服务表示是这个调用的客户端 span。截图显示此次调用耗时 15.30 毫秒。第二个 span 标记有操作标签 `reviews.default.svc.cluster.local:9080/*` 操作和服务标签 `reviews.default: proxy server` 。第二个 span 是第一个 span 的下一级，表示调用的服务端 span。截图显示此次调用耗时 14.60 毫秒。 +追踪中的两个 spans 表示一个 RPC 请求。例如，从 `productpage` 到 `reviews` 的请求调用，以操作标签 `reviews.default.svc.cluster.local:9080/*` 和服务标签 `productpage.default: proxy client` 的 span 开始。该服务表示是这个调用的客户端 span。截图显示此次调用耗时 15.30 毫秒。第二个 span 标记有操作标签 `reviews.default.svc.cluster.local:9080/*` 操作和服务标签 `reviews.default: proxy server` 。第二个 span 是第一个 span 的下一级，表示调用的服务端 span。截图显示此次调用耗时 14.60 毫秒。 {{< warning >}} 集成后的 LightStep 当前无法捕获由 Istio 的内部操作组件（如 Mixer）生成的 span。 @@ -119,7 +119,7 @@ Istio 通过配置追踪采样百分比来捕获追踪信息。想了解如何 如果你不想继续执测试操作任务，可以从集群中删除 Bookinfo 示例应用程序和所有的 LightStep 密钥。 -1. 删除 Bookinfo 应用程序，请参阅[清除 Bookinfo](/zh/docs/examples/bookinfo/#cleanup)说明。 +1. 删除 Bookinfo 应用程序，请参阅[清除 Bookinfo](/zh/docs/examples/bookinfo/#cleanup) 说明。 1. 删除给 LightStep 生成的密钥： diff --git a/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md b/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md index d6c33ece55..9808addf08 100644 --- a/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md +++ b/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md @@ -7,9 +7,9 @@ aliases: - /zh/docs/tasks/telemetry/distributed-tracing/overview/ --- -分布式追踪可以让用户对跨多个分布式服务网格的1个请求进行追踪分析。这样进而可以通过可视化的方式更加深入地了解请求的延迟，序列化和并行度。 +分布式追踪可以让用户对跨多个分布式服务网格的 1 个请求进行追踪分析。这样进而可以通过可视化的方式更加深入地了解请求的延迟，序列化和并行度。 -Istio 利用 [Envoy 的分布式追踪](https://www.envoyproxy.io/docs/envoy/v1.10.0/intro/arch_overview/tracing) 功能提供了开箱即用的追踪集成。确切地说，Istio 提供了安装各种各种追踪后端服务的选项，并且通过配置代理来自动发送追踪 span 到追踪后端服务。 +Istio 利用 [Envoy 的分布式追踪](https://www.envoyproxy.io/docs/envoy/v1.10.0/intro/arch_overview/tracing)功能提供了开箱即用的追踪集成。确切地说，Istio 提供了安装各种各种追踪后端服务的选项，并且通过配置代理来自动发送追踪 span 到追踪后端服务。 请参阅 [Zipkin](../zipkin/)， [Jaeger](../jaeger/) 和 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 的任务文档来了解 Istio 如何与这些分布式追踪系统一起工作。 @@ -29,7 +29,7 @@ Istio 利用 [Envoy 的分布式追踪](https://www.envoyproxy.io/docs/envoy/v1. * `x-b3-flags` * `x-ot-span-context` -例如，如果你看 Python 的 `productpage` 服务这个例子，可以看到这个应用程序使用了 [OpenTracing](https://opentracing.io/) 库从HTTP请求中提取所需的头信息： +例如，如果你看 Python 的 `productpage` 服务这个例子，可以看到这个应用程序使用了 [OpenTracing](https://opentracing.io/) 库从 HTTP 请求中提取所需的头信息： {{< text python >}} def getForwardHeaders(request): @@ -84,7 +84,7 @@ public Response bookReviewsById(@PathParam("productId") int productId, 默认情况下，使用 demo 配置文件安装时，Istio 会捕获所有请求的追踪信息。例如，当使用上面的 Bookinfo 示例应用时，每次访问 `/productpage` 接口时，你都可以在 dashboard 中看到一条相应的追踪信息。此采样频率适用于测试或低流量网格。对于高流量网格你可以通过下面的两种方法之一来降低追踪采样频率： -* 在网格安装时，使用可选项 `values.pilot.traceSampling` 来设置采样百分比。参考 [通过 {{< istioctl >}} 安装](/zh/docs/setup/install/istioctl/) 文档查看详细的配置可选项。 +* 在网格安装时，使用可选项 `values.pilot.traceSampling` 来设置采样百分比。参考[通过 {{< istioctl >}} 安装](/zh/docs/setup/install/istioctl/)文档查看详细的配置可选项。 * 在运行中的网格，可以通过编辑 `istio-pilot` deployment 并通过以下步骤来改变环境变量： 1. 运行下面的命令来打开编辑器并加载 deployment 配置文件： @@ -95,4 +95,4 @@ public Response bookReviewsById(@PathParam("productId") int productId, 1. 找到 `PILOT_TRACE_SAMPLING` 环境变量，将 `value:` 设置成你想要的百分比。 -在这两种情况下，有效值的范围从 0.0 到 100.0，精度为 0.01。 \ No newline at end of file +在这两种情况下，有效值的范围从 0.0 到 100.0，精度为 0.01。 diff --git a/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md b/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md index 0194a57e1c..22d42e91d7 100644 --- a/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md +++ b/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md @@ -12,11 +12,11 @@ aliases: 本任务使用 [Bookinfo](/zh/docs/examples/bookinfo/) 作为示例应用程序。 -要了解 Istio 如何处理追踪，请访问此任务的 [概述](../overview/)。 +要了解 Istio 如何处理追踪，请访问此任务的[概述](../overview/)。 ## 开始之前{#before-you-begin} -1. 参考 [安装指南](/zh/docs/setup/install/istioctl) 中的说明， +1. 参考[安装指南](/zh/docs/setup/install/istioctl)中的说明， 使用如下配置安装 Istio： a) 通过配置 `--set values.tracing.enabled=true` 和 `--set values.tracing.provider=zipkin` 选项可以安装一个“开箱即用”的演示或测试环境。 @@ -32,7 +32,7 @@ aliases: ## 访问仪表盘{#accessing-the-dashboard} -[远程访问遥测组件](/zh/docs/tasks/observability/gateways) 详细描述了如何通过配置网关以访问 Istio 组件。或者，如果要使用 Kubernetes ingress, 请在安装时配置 `--set values.tracing.ingress.enabled=true` 选项。 +[远程访问遥测组件](/zh/docs/tasks/observability/gateways)详细描述了如何通过配置网关以访问 Istio 组件。或者，如果要使用 Kubernetes ingress, 请在安装时配置 `--set values.tracing.ingress.enabled=true` 选项。 对于测试（和临时访问），您也可以使用端口转发。假设已将 Zipkin 部署到 `istio-system` 命名空间，请使用以下方法： @@ -69,6 +69,6 @@ $ istioctl dashboard zipkin {{< /text >}} 1. 如果您不打算继续深入探索任何后续任务，请 - 参考 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup) 说明 + 参考 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup)说明 关闭应用程序。 diff --git a/content/zh/docs/tasks/observability/kiali/index.md b/content/zh/docs/tasks/observability/kiali/index.md index 3575461eb6..3986c8be5e 100644 --- a/content/zh/docs/tasks/observability/kiali/index.md +++ b/content/zh/docs/tasks/observability/kiali/index.md @@ -28,7 +28,7 @@ aliases: ### 创建 secret{#create-a-secret} {{< tip >}} -如果您打算按照 [Istio 快速入门](/zh/docs/setup/getting-started/) 说明使用 Istio 演示配置文件安装 Kiali，则会为您创建一个默认 secret，用户名为 `admin` ，密码为 `admin`。 因此，您可以跳过此部分。 +如果您打算按照 [Istio 快速入门](/zh/docs/setup/getting-started/)说明使用 Istio 演示配置文件安装 Kiali，则会为您创建一个默认 secret，用户名为 `admin` ，密码为 `admin`。 因此，您可以跳过此部分。 {{< /tip >}} 在 Istio 命名空间中创建一个 Secret，作为 Kiali 的身份验证凭据。 @@ -79,7 +79,7 @@ EOF ### 通过 `istioctl` 安装{#install-Via-`istioctl`} -创建 Kiali secret 后，请参照 `istioctl` [安装说明](/zh/docs/setup/install/istioctl/) 来安装 Kiali。 +创建 Kiali secret 后，请参照 `istioctl` [安装说明](/zh/docs/setup/install/istioctl/)来安装 Kiali。 例如： {{< text bash >}} diff --git a/content/zh/docs/tasks/observability/logs/access-log/index.md b/content/zh/docs/tasks/observability/logs/access-log/index.md index e5fda88969..f2ac5ade86 100644 --- a/content/zh/docs/tasks/observability/logs/access-log/index.md +++ b/content/zh/docs/tasks/observability/logs/access-log/index.md @@ -8,7 +8,7 @@ aliases: - /zh/docs/tasks/telemetry/logs/access-log/ --- -Istio 最简单的日志类型是[Envoy 的访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log)。Envoy 代理打印访问信息到标准输出。Envoy 容器的标准输出能够通过 `kubectl logs` 命令打印出来。 +Istio 最简单的日志类型是 [Envoy 的访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log)。Envoy 代理打印访问信息到标准输出。Envoy 容器的标准输出能够通过 `kubectl logs` 命令打印出来。 {{< boilerplate before-you-begin-egress >}} @@ -77,7 +77,7 @@ configmap "istio" replaced [2019-03-06T09:31:27.360Z] "GET /status/418 HTTP/1.1" 418 - "-" 0 135 5 2 "-" "curl/7.60.0" "d209e46f-9ed5-9b61-bbdd-43e22662702a" "httpbin:8000" "127.0.0.1:80" inbound|8000|http|httpbin.default.svc.cluster.local - 172.30.146.73:80 172.30.146.82:38618 outbound_.8000_._.httpbin.default.svc.cluster.local {{< /text >}} -请注意，与请求相对应的信息分别出现在源（`sleep`）和目标（`httpbin`）的 Istio 代理日志中。您可以在日志中看到 HTTP 动词(`GET`)、HTTP 路径(`/status/418`)、响应码(`418`)和其他[请求相关信息](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#format-rules)。 +请注意，与请求相对应的信息分别出现在源（`sleep`）和目标（`httpbin`）的 Istio 代理日志中。您可以在日志中看到 HTTP 动词(`GET`)、HTTP 路径(`/status/418`)、响应码(`418`) 和其他[请求相关信息](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#format-rules)。 ## 清除{#cleanup} diff --git a/content/zh/docs/tasks/observability/logs/fluentd/index.md b/content/zh/docs/tasks/observability/logs/fluentd/index.md index e3c5a7d131..20e7c8e00d 100644 --- a/content/zh/docs/tasks/observability/logs/fluentd/index.md +++ b/content/zh/docs/tasks/observability/logs/fluentd/index.md @@ -354,4 +354,4 @@ $ kubectl apply -f @samples/bookinfo/telemetry/fluentd-istio-crd.yaml@ $ killall kubectl {{< /text >}} -* 如果您不打算继续探索后续任务，请参考 [Bookinfo 清除](/zh/docs/examples/bookinfo/#cleanup) 以关闭应用程序。 +* 如果您不打算继续探索后续任务，请参考 [Bookinfo 清除](/zh/docs/examples/bookinfo/#cleanup)以关闭应用程序。 diff --git a/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md b/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md index 2d7315fbdd..3b8a8e8894 100644 --- a/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md +++ b/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md @@ -128,4 +128,4 @@ Mixer instances 通过 `instance_name` 参数与 Prometheus 指标匹配。 $ killall kubectl {{< /text >}} -* 如果您不打算继续浏览后续的任务，请参考 [Bookinfo 清除](/zh/docs/examples/bookinfo/#cleanup) 说明以关闭该应用。 +* 如果您不打算继续浏览后续的任务，请参考 [Bookinfo 清除](/zh/docs/examples/bookinfo/#cleanup)说明以关闭该应用。 diff --git a/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md b/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md index 89bcf2a4b8..432e85e8ec 100644 --- a/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md +++ b/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md @@ -14,7 +14,7 @@ aliases: ## 开始之前{#before-you-begin} -在自身集群中 [安装 Istio](/zh/docs/setup/) 并部署一个应用。 +在自身集群中[安装 Istio](/zh/docs/setup/) 并部署一个应用。 ## 查询 Istio 度量指标{#query-mesh-metrics} diff --git a/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md b/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md index ee341818af..03a10294a4 100644 --- a/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md +++ b/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md @@ -14,7 +14,7 @@ aliases: ## 在开始之前{#before-you-begin} -* 在集群中[安装 Istio](/zh/docs/setup)。如果在您选择的配置文件中未启用 Grafana 附加组件，您可以通过 `--set values.grafana.enabled=true` [选项](/zh/docs/reference/config/installation-options/) 启用。 +* 在集群中[安装 Istio](/zh/docs/setup)。如果在您选择的配置文件中未启用 Grafana 附加组件，您可以通过 `--set values.grafana.enabled=true` [选项](/zh/docs/reference/config/installation-options/)启用。 * 部署 [Bookinfo](/zh/docs/examples/bookinfo/) 应用。 ## 查看 Istio Dashboard{#viewing-the-Istio-dashboard} @@ -118,4 +118,4 @@ Istio Dashboard 包括三个主要部分： $ killall kubectl {{< /text >}} -* 如果不打算探索任何后续任务，请参阅 [清除 Bookinfo](/zh/docs/examples/bookinfo/#cleanup) 的说明来关闭应用。 +* 如果不打算探索任何后续任务，请参阅[清除 Bookinfo](/zh/docs/examples/bookinfo/#cleanup) 的说明来关闭应用。 diff --git a/content/zh/docs/tasks/policy-enforcement/control-headers/index.md b/content/zh/docs/tasks/policy-enforcement/control-headers/index.md index f8257682f3..edec38b21f 100644 --- a/content/zh/docs/tasks/policy-enforcement/control-headers/index.md +++ b/content/zh/docs/tasks/policy-enforcement/control-headers/index.md @@ -9,14 +9,14 @@ keywords: [policies,routing] ## 开始之前{#before-you-begin} -* 遵循 [安装指南](/zh/docs/setup/) 中的说明在 Kubernetes 集群上安装 Istio 。 +* 遵循[安装指南](/zh/docs/setup/)中的说明在 Kubernetes 集群上安装 Istio 。 {{< warning >}} - **必须** 在你的集群上启用策略检查。请按照 [启用策略检查](/zh/docs/tasks/policy-enforcement/enabling-policy/) + **必须** 在你的集群上启用策略检查。请按照[启用策略检查](/zh/docs/tasks/policy-enforcement/enabling-policy/) 中的步骤操作，以确保启用了策略检查 。 {{< /warning >}} -* 按照 [ingress 任务](/zh/docs/tasks/traffic-management/ingress/) 中的设置说明，使用 Gateway 配置 ingress。 +* 按照 [ingress 任务](/zh/docs/tasks/traffic-management/ingress/)中的设置说明，使用 Gateway 配置 ingress。 * 为 `httpbin` 服务定义一个包含两条路由规则的 [virtual service](/zh/docs/reference/config/networking/virtual-service/)，以接收来自路径 `/headers` 和 `/status` 的请求： @@ -199,4 +199,4 @@ $ kubectl delete service keyval -n istio-system $ kubectl delete deployment keyval -n istio-system {{< /text >}} -完成 [ingress 任务](/zh/docs/tasks/traffic-management/ingress/) 中的清理说明。 +完成 [ingress 任务](/zh/docs/tasks/traffic-management/ingress/)中的清理说明。 diff --git a/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md b/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md index eb7c328f75..f466e0003a 100644 --- a/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md +++ b/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md @@ -192,4 +192,4 @@ Istio 支持基于 IP 地址的 _白名单_ 和 _黑名单_ 。 $ kubectl delete -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@ {{< /text >}} -* 如果您不打算探索任何后续任务，请参考[清除 Bookinfo](/zh/docs/examples/bookinfo/#cleanup) 指南来关闭应用程序。 \ No newline at end of file +* 如果您不打算探索任何后续任务，请参考[清除 Bookinfo](/zh/docs/examples/bookinfo/#cleanup) 指南来关闭应用程序。 diff --git a/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md b/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md index e7eaf58a21..346b200bd2 100644 --- a/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md +++ b/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md @@ -186,7 +186,7 @@ Mixer 返回一个 `RESOURCE_EXHAUSTED` 消息给 Envoy 代理，然后 Envoy `memquota` 适配器使用一个亚秒级的滑动窗口来执行速率限制。 -`redisquota` 适配器可以配置使用[`ROLLING_WINDOW` 或 `FIXED_WINDOW`](/zh/docs/reference/config/policy-and-telemetry/adapters/redisquota/#Params-QuotaAlgorithm) +`redisquota` 适配器可以配置使用 [`ROLLING_WINDOW` 或 `FIXED_WINDOW`](/zh/docs/reference/config/policy-and-telemetry/adapters/redisquota/#Params-QuotaAlgorithm) 算法之一来执行速率限制。 适配器配置内的 `maxAmount` 为所有关联到 quota 实例的计数器设置了默认限制。这个默认限制应用在其他优先规则没有被匹配到的时候。 diff --git a/content/zh/docs/tasks/security/authentication/_index.md b/content/zh/docs/tasks/security/authentication/_index.md index 689cfa825e..968d4139dc 100644 --- a/content/zh/docs/tasks/security/authentication/_index.md +++ b/content/zh/docs/tasks/security/authentication/_index.md @@ -1,5 +1,5 @@ --- title: 认证 -description: 管控网格服务间的双向TLS和终端用户的身份认证。 +description: 管控网格服务间的双向 TLS 和终端用户的身份认证。 weight: 10 --- diff --git a/content/zh/docs/tasks/security/authentication/authn-policy/index.md b/content/zh/docs/tasks/security/authentication/authn-policy/index.md index a7ea097cb7..0d6d635dfa 100644 --- a/content/zh/docs/tasks/security/authentication/authn-policy/index.md +++ b/content/zh/docs/tasks/security/authentication/authn-policy/index.md @@ -8,12 +8,12 @@ aliases: - /zh/docs/tasks/security/authn-policy/ --- -本任务涵盖了您在启用、配置和使用 Istio 认证策略时可能需要做的主要工作。更多基本概念介绍请查看 [认证总览](/zh/docs/concepts/security/#authentication)。 +本任务涵盖了您在启用、配置和使用 Istio 认证策略时可能需要做的主要工作。更多基本概念介绍请查看[认证总览](/zh/docs/concepts/security/#authentication)。 ## 开始之前{#before-you-begin} -* 理解 Istio [认证策略](/zh/docs/concepts/security/#authentication-policies) 和 [双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication) 相关概念。 -* 在 Kubernetes 集群中安装 Istio 并禁用全局双向 TLS (例如，使用[安装步骤](/zh/docs/setup/getting-started) 提到的 demo 配置文件，或者设置 `global.mtls.enabled` 安装选项为 false )。 +* 理解 Istio [认证策略](/zh/docs/concepts/security/#authentication-policies)和[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)相关概念。 +* 在 Kubernetes 集群中安装 Istio 并禁用全局双向 TLS (例如，使用[安装步骤](/zh/docs/setup/getting-started)提到的 demo 配置文件，或者设置 `global.mtls.enabled` 安装选项为 false )。 ### 设置{#setup} @@ -112,7 +112,7 @@ sleep.bar to httpbin.foo: 503 sleep.bar to httpbin.bar: 503 {{< /text >}} -配置客户端，您需要设置 [destination rules](/zh/docs/concepts/traffic-management/#destination-rules)来使用双向 TLS。也可以使用多 destination rules，为每个合适的服务（或命名空间）都配置一个。不过，更方便地方式是创建一个规则使用通配符 `*` 匹配所有服务，因此这也和网格范围的认证策略作用等同。 +配置客户端，您需要设置 [destination rules](/zh/docs/concepts/traffic-management/#destination-rules) 来使用双向 TLS。也可以使用多 destination rules，为每个合适的服务（或命名空间）都配置一个。不过，更方便地方式是创建一个规则使用通配符 `*` 匹配所有服务，因此这也和网格范围的认证策略作用等同。 {{< text bash >}} $ kubectl apply -f - <}}/security/tools/jwt/samples/demo.jwt) 和 [JWKS endpoint]({{< github_file >}}/security/tools/jwt/samples/jwks.json) -同时，为了方便，通过 `ingressgateway` 暴露 `httpbin.foo`（更多细节，查看[ingress 任务](/zh/docs/tasks/traffic-management/ingress/)）。 +同时，为了方便，通过 `ingressgateway` 暴露 `httpbin.foo`（更多细节，查看 [ingress 任务](/zh/docs/tasks/traffic-management/ingress/)）。 {{< text bash >}} $ kubectl apply -f - <}} -现在，为 `httpbin.foo` 添加一个要求配置终端用户 JWT 的策略。下面的命令假定 `httpbin.foo` 没有特定服务策略（如果您执行了[清除](#cleanup-part-2) 所述的操作，就会是这样）。您可以执行 `kubectl get policies.authentication.istio.io -n foo` 进行确认。 +现在，为 `httpbin.foo` 添加一个要求配置终端用户 JWT 的策略。下面的命令假定 `httpbin.foo` 没有特定服务策略（如果您执行了[清除](#cleanup-part-2)所述的操作，就会是这样）。您可以执行 `kubectl get policies.authentication.istio.io -n foo` 进行确认。 {{< text bash >}} $ cat <}} -为了观察 JWT 验证的其它方面，使用脚本[`gen-jwt.py`]({{< github_tree >}}/security/tools/jwt/samples/gen-jwt.py) 生成新 tokens 带上不同的发行人、受众、有效期等等进行测试。这个脚本可以从 Istio 库下载： +为了观察 JWT 验证的其它方面，使用脚本 [`gen-jwt.py`]({{< github_tree >}}/security/tools/jwt/samples/gen-jwt.py) 生成新 tokens 带上不同的发行人、受众、有效期等等进行测试。这个脚本可以从 Istio 库下载： {{< text bash >}} $ wget {{< github_file >}}/security/tools/jwt/samples/gen-jwt.py @@ -568,10 +568,10 @@ $ wget {{< github_file >}}/security/tools/jwt/samples/key.pem {{< /text >}} {{< tip >}} -下载[jwcrypto](https://pypi.org/project/jwcrypto) 库，如果您还没有在您的系统上安装的话。 +下载 [jwcrypto](https://pypi.org/project/jwcrypto) 库，如果您还没有在您的系统上安装的话。 {{< /tip >}} -例如，下述命令创建一个5秒钟过期的 token。如您所见，Istio 使用这个 token 刚开始认证请求成功，但是5秒后拒绝了它们。 +例如，下述命令创建一个 5 秒钟过期的 token。如您所见，Istio 使用这个 token 刚开始认证请求成功，但是 5 秒后拒绝了它们。 {{< text bash >}} $ TOKEN=$(./gen-jwt.py ./key.pem --expire 5) @@ -763,4 +763,4 @@ command terminated with exit code 56 {{< text bash >}} $ kubectl delete ns foo bar legacy - {{< /text >}} \ No newline at end of file + {{< /text >}} diff --git a/content/zh/docs/tasks/security/authentication/auto-mtls/index.md b/content/zh/docs/tasks/security/authentication/auto-mtls/index.md index a74106997f..f0ecc11562 100644 --- a/content/zh/docs/tasks/security/authentication/auto-mtls/index.md +++ b/content/zh/docs/tasks/security/authentication/auto-mtls/index.md @@ -14,8 +14,8 @@ Istio 跟踪迁移到 sidecar 的服务端工作负载，并将客户端 sidecar ## 开始之前{#before-you-begin} -* 理解 Istio [认证策略](/zh/docs/concepts/security/#authentication-policies) 和关于 -[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication) 章节的内容。 +* 理解 Istio [认证策略](/zh/docs/concepts/security/#authentication-policies)和关于 +[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)章节的内容。 * 安装 Istio 时，配置 `global.mtls.enabled` 选项为 false，`global.mtls.auto` 选项为 true。 以安装 `demo` 配置文件为例： @@ -321,7 +321,7 @@ spec: EOF {{< /text >}} -由于在前面的步骤中，我们已经禁用了 `httpbin.full` 的身份验证策略，以禁用双向TLS，现在应该看到来自 `sleep.full` 的流量开始失败。 +由于在前面的步骤中，我们已经禁用了 `httpbin.full` 的身份验证策略，以禁用双向 TLS，现在应该看到来自 `sleep.full` 的流量开始失败。 {{< text bash >}} $ for from in "full" "legacy"; do for to in "full" "partial" "legacy"; do echo "sleep.${from} to httpbin.${to}";kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.${to}:8000/headers -s -w "response code: %{http_code}\n" | egrep -o 'URI\=spiffe.*sa/[a-z]*|response.*$'; echo -n "\n"; done; done diff --git a/content/zh/docs/tasks/security/authentication/mtls-migration/index.md b/content/zh/docs/tasks/security/authentication/mtls-migration/index.md index a143fea149..0dea9c5d79 100644 --- a/content/zh/docs/tasks/security/authentication/mtls-migration/index.md +++ b/content/zh/docs/tasks/security/authentication/mtls-migration/index.md @@ -16,7 +16,7 @@ aliases: ## 开始之前{#before-you-begin} -* 理解 Istio [认证策略](/zh/docs/concepts/security/#authentication-policies) 以及相关的[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication) 概念。 +* 理解 Istio [认证策略](/zh/docs/concepts/security/#authentication-policies)以及相关的[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)概念。 * 准备一个 Kubernetes 集群并部署好 Istio，不要开启全局双向 TLS （如：可以使用[安装步骤](/zh/docs/setup/getting-started)中提供的 demo 配置 profile，或者将安装选项 `global.mtls.enabled` 设置为 false）。 @@ -127,7 +127,7 @@ sleep.legacy to httpbin.foo: 503 若无法将所有服务迁移至 Istio （注入 Envoy sidecar），则必须开启 `PERMISSIVE` 模式。 然而，开启 `PERMISSIVE` 模式时，系统默认不对明文请求进行认证或授权检查。 -推荐使用 [Istio 授权](/zh/docs/tasks/security/authorization/authz-http/) 来为不同的请求路径配置不同的授权策略。 +推荐使用 [Istio 授权](/zh/docs/tasks/security/authorization/authz-http/)来为不同的请求路径配置不同的授权策略。 ## 清除{#cleanup} diff --git a/content/zh/docs/tasks/security/authentication/mutual-tls/index.md b/content/zh/docs/tasks/security/authentication/mutual-tls/index.md index b948259700..44e74494ea 100644 --- a/content/zh/docs/tasks/security/authentication/mutual-tls/index.md +++ b/content/zh/docs/tasks/security/authentication/mutual-tls/index.md @@ -9,10 +9,10 @@ aliases: 通过本任务，你可以进一步了解双向 TLS 以及如何配置。本任务假设： -* 您已经完成[认证策略](/zh/docs/tasks/security/authentication/authn-policy/) 任务. +* 您已经完成[认证策略](/zh/docs/tasks/security/authentication/authn-policy/)任务. * 您熟悉如何通过认证策略开启双向 TLS。 * Istio 在 Kubernetes 上运行，并且开启全局双向 TLS。可以参考 [Istio 安装说明文档](/zh/docs/setup/)。 -如果已经安装 Istio，可以根据[为所有服务启用双向 TLS 认证](/zh//docs/tasks/security/authentication/authn-policy/#globally-enabling-Istio-mutual-TLS) 任务中说明，通过增加或者修改认证策略和目的规则来开启双向 TLS。 +如果已经安装 Istio，可以根据[为所有服务启用双向 TLS 认证](/zh//docs/tasks/security/authentication/authn-policy/#globally-enabling-Istio-mutual-TLS)任务中说明，通过增加或者修改认证策略和目的规则来开启双向 TLS。 * [httpbin]({{< github_tree >}}/samples/httpbin) 和 [sleep]({{< github_tree >}}/samples/sleep) 已经部署在了 `default` namespace，并且这两个应用带有 Envoy sidecar. 例如，可以通过以下命令[手动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection) 来完成服务的部署: {{< text bash >}} @@ -22,7 +22,7 @@ aliases: ## 检查 Citadel 是否运行正常{#verify-citadel-runs-properly} -[Citadel](/zh/docs/concepts/security/#PKI) 是Istio 的密钥管理服务，它必须正常运行才能使双向 TLS 正常工作。 +[Citadel](/zh/docs/concepts/security/#PKI) 是 Istio 的密钥管理服务，它必须正常运行才能使双向 TLS 正常工作。 使用以下命令验证 Citadel 在集群中是否正确运行： {{< text bash >}} @@ -65,7 +65,7 @@ $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.na URI:spiffe://cluster.local/ns/default/sa/default {{< /text >}} -请参阅 [Istio 认证](/zh/docs/concepts/security/#istio-identity) 一节，可以了解更多**服务身份**方面的内容。 +请参阅 [Istio 认证](/zh/docs/concepts/security/#istio-identity)一节，可以了解更多**服务身份**方面的内容。 ## 验证双向 TLS 配置{#verify-mutual-TLS-configuration} diff --git a/content/zh/docs/tasks/security/authorization/authz-http/index.md b/content/zh/docs/tasks/security/authorization/authz-http/index.md index b3cbc34e51..0cbb3a48dc 100644 --- a/content/zh/docs/tasks/security/authorization/authz-http/index.md +++ b/content/zh/docs/tasks/security/authorization/authz-http/index.md @@ -53,7 +53,7 @@ aliases: EOF {{< /text >}} - 打开浏览器访问 Bookinfo 的 `productpage` (`http://$GATEWAY_URL/productpage`)页面。你将会看到 `"RBAC: access denied"`。该错误表明配置的 `deny-all` 策略按期望生效了，并且 Istio 没有任何规则允许对网格中的工作负载进行任何访问。 + 打开浏览器访问 Bookinfo 的 `productpage` (`http://$GATEWAY_URL/productpage`) 页面。你将会看到 `"RBAC: access denied"`。该错误表明配置的 `deny-all` 策略按期望生效了，并且 Istio 没有任何规则允许对网格中的工作负载进行任何访问。 1. 运行下面的命令创建一个 `productpage-viewer` 策略以容许通过 `GET` 方法访问 `productpage` 工作负载。该策略没有在 `rules` 中设置 `from` 字段，这意味着所有的请求源都被容许访问，包括所有的用户和工作负载： diff --git a/content/zh/docs/tasks/security/authorization/rbac-groups/index.md b/content/zh/docs/tasks/security/authorization/rbac-groups/index.md index 81a6dc5f6a..37eb479da4 100644 --- a/content/zh/docs/tasks/security/authorization/rbac-groups/index.md +++ b/content/zh/docs/tasks/security/authorization/rbac-groups/index.md @@ -59,7 +59,7 @@ aliases: 您接下来应用的认证策略会强制要求访问 `httpbin` 服务需要具备有效的 JWT。 策略中定义的 JSON Web 密钥集（ JWKS ）端点必须对 JWT 进行签名。 -本教程使用 Istio 代码库中的 [JWKS 端点]({{< github_file >}}/security/tools/jwt/samples/jwks.json)并使用[此示例 JWT]({{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt)。 +本教程使用 Istio 代码库中的 [JWKS 端点]({{}}/security/tools/jwt/samples/jwks.json) 并使用[此示例 JWT]({{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt)。 示例 JWT 包含一个标识为 `groups` 的声明键和一个 [`"group1"`，`"group2"`] 字符串列表的声明值。 JWT 声明值可以是字符串或字符串列表；两种类型都支持。 diff --git a/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md b/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md index 2e88e53b02..284d6d4fe7 100644 --- a/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md +++ b/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md @@ -7,7 +7,7 @@ aliases: - /zh/docs/tasks/security/auth-sds/ --- -这个任务是讲述 Istio 中如何通过启动 [SDS（密钥发现服务）](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration)来进行身份认证的。 +这个任务是讲述 Istio 中如何通过启动 [SDS（密钥发现服务）](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration) 来进行身份认证的。 在 Istio 1.1 之前，Istio workload 的密钥和证书都是由 Citadel 生成的，并且通过挂载 secret-volume 文件的方式下发给 sidecar 上。 这种做法有下面一些小缺陷： @@ -37,7 +37,7 @@ aliases: ## 开始之前{## before-you-begin} -参考[Istio 安装指南](/zh/docs/setup/install/istioctl/) 使用 SDS 配置文件设置 Istio。 +参考 [Istio 安装指南](/zh/docs/setup/install/istioctl/)使用 SDS 配置文件设置 Istio。 ## 通过 SDS 使用密钥/证书为服务到服务提供双向 TLS{## service-to-service-mutual-TLS-using key/certificate-provisioned-through-SDS} @@ -76,11 +76,11 @@ $ kubectl exec -it $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..me Istio 的密钥发现服务（SDS）使用 Citadel 代理通过 Unix domain 套接字来给 Envoy 边车分发证书。 所有在同一个 Kubernetes 节点上的 pod 通过 Unix domain 套接字共享同一个 Citadel 代理。 -为了防止对 Unix domain 套接字的意外修改，需要启用[pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)来限制 pod 对 Unix domain 套接字的权限。否则，有权限修改 deployment 的恶意用户会劫持 Unix domain 套接字来断开 SDS 服务，或者会从运行在同一个 Kubernetes 节点上的其它 pod 那里偷取身份证书。 +为了防止对 Unix domain 套接字的意外修改，需要启用 [pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)来限制 pod 对 Unix domain 套接字的权限。否则，有权限修改 deployment 的恶意用户会劫持 Unix domain 套接字来断开 SDS 服务，或者会从运行在同一个 Kubernetes 节点上的其它 pod 那里偷取身份证书。 可以通过执行以下步骤来启用 pod 安全策略： -1. Citadel代理创建成功 Unix domain 套接字才能启动成功。通过实施下面的 pod 安全策略才能只启用 Citadel 代理对 Unix domain 套接字的修改权限。 +1. Citadel 代理创建成功 Unix domain 套接字才能启动成功。通过实施下面的 pod 安全策略才能只启用 Citadel 代理对 Unix domain 套接字的修改权限。 {{< text bash >}} $ cat <}} -* 移除 Istio 组件：按照 [卸载说明](/zh/docs/setup/getting-started/#uninstall) 进行删除。 +* 移除 Istio 组件：按照[卸载说明](/zh/docs/setup/getting-started/#uninstall)进行删除。 diff --git a/content/zh/docs/tasks/security/webhook/index.md b/content/zh/docs/tasks/security/webhook/index.md index 00da8de535..0ad574bbbe 100644 --- a/content/zh/docs/tasks/security/webhook/index.md +++ b/content/zh/docs/tasks/security/webhook/index.md @@ -1,5 +1,5 @@ --- -title: Istio Webhook 管理 [实验性] +title: Istio Webhook 管理[实验性] description: 如何在 Istio 中使用 istioctl 工具管理 webhooks。 weight: 100 keywords: [security,webhook] @@ -234,4 +234,4 @@ X509v3 Subject Alternative Name: $ kubectl delete ns test-injection test-validation $ kubectl delete -f galley-webhook.yaml $ kubectl delete -f sidecar-injector-webhook.yaml -{{< /text >}} \ No newline at end of file +{{< /text >}} diff --git a/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md b/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md index 49ada17a38..1596b0dcb7 100644 --- a/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md +++ b/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md @@ -14,7 +14,7 @@ keywords: [traffic-management,circuit-breaking] ## 开始之前{#before-you-begin} -* 跟随 [安装指南](/zh/docs/setup/) 安装 Istio。 +* 跟随[安装指南](/zh/docs/setup/)安装 Istio。 {{< boilerplate start-httpbin-service >}} @@ -22,11 +22,11 @@ keywords: [traffic-management,circuit-breaking] ## 配置熔断器{#configuring-the-circuit-breaker} -1. 创建一个 [目标规则](/zh/docs/reference/config/networking/destination-rule/)，在调用 `httpbin` +1. 创建一个[目标规则](/zh/docs/reference/config/networking/destination-rule/)，在调用 `httpbin` 服务时应用熔断设置： {{< warning >}} - 如果您的 Istio 启用了双向 TLS 身份验证，则必须在应用目标规则之前将 TLS 流量策略 `mode：ISTIO_MUTUAL` 添加到 `DestinationRule` 。否则请求将产生 503 错误，如 [这里](/zh/docs/ops/common-problems/network-issues/#service-unavailable-errors-after-setting-destination-rule) 所述。 + 如果您的 Istio 启用了双向 TLS 身份验证，则必须在应用目标规则之前将 TLS 流量策略 `mode：ISTIO_MUTUAL` 添加到 `DestinationRule` 。否则请求将产生 503 错误，如[这里](/zh/docs/ops/common-problems/network-issues/#service-unavailable-errors-after-setting-destination-rule)所述。 {{< /warning >}} {{< text bash >}} @@ -241,4 +241,4 @@ keywords: [traffic-management,circuit-breaking] {{< text bash >}} $ kubectl delete deploy httpbin fortio-deploy $ kubectl delete svc httpbin - {{< /text >}} \ No newline at end of file + {{< /text >}} diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md index 91e835ad1c..965f7ec401 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md @@ -18,9 +18,9 @@ keywords: [traffic-management,egress] ## 开始之前{#before-you-begin} -* 根据 [安装指南](/zh/docs/setup/) 中的命令设置 Istio。 +* 根据[安装指南](/zh/docs/setup/)中的命令设置 Istio。 * 部署 [sleep]({{< github_tree >}}/samples/sleep) 这个示例应用，用作发送请求的测试源。 - 如果你启用了 [自动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection)，使用以下的命令来部署示例应用： + 如果你启用了[自动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection)，使用以下的命令来部署示例应用： {{< text bash >}} $ kubectl apply -f @samples/sleep/sleep.yaml@ @@ -44,7 +44,7 @@ keywords: [traffic-management,egress] ## Envoy 转发流量到外部服务{#envoy-passthrough-to-external-services} -Istio 有一个 [安装选项](/zh/docs/reference/config/installation-options/)， +Istio 有一个[安装选项](/zh/docs/reference/config/installation-options/)， `global.outboundTrafficPolicy.mode`，它配置 sidecar 对外部服务（那些没有在 Istio 的内部服务注册中定义的服务）的处理方式。如果这个选项设置为 `ALLOW_ANY`，Istio 代理允许调用未知的服务。如果这个选项设置为 `REGISTRY_ONLY`，那么 Istio 代理会阻止任何没有在网格中定义的 HTTP 服务或 service entry 的主机。`ALLOW_ANY` 是默认值，不控制对外部服务的访问，方便你快速地评估 Istio。你可以稍后再[配置对外部服务的访问](#controlled-access-to-external-services) 。 1. 要查看这种方法的实际效果，你需要确保 Istio 的安装配置了 `global.outboundTrafficPolicy.mode` 选项为 `ALLOW_ANY`。它在默认情况下是开启的，除非你在安装 Istio 时显式地将它设置为 `REGISTRY_ONLY`。 @@ -276,10 +276,10 @@ $ kubectl delete virtualservice httpbin-ext --ignore-not-found=true ## 直接访问外部服务{#direct-access-to-external-services} -如果要让特定范围的 ​​IP 完全绕过Istio，则可以配置 Envoy sidecars 以防止它们[拦截](/zh/docs/concepts/traffic-management/)外部请求。要设置绕过 Istio，请更改 `global.proxy.includeIPRanges` 或 `global.proxy.excludeIPRanges` 配置选项，并使用 `kubectl apply` 命令更新 `istio-sidecar-injector` 的[配置](/zh/docs/reference/config/installation-options/)。`istio-sidecar-injector` 配置的更新，影响的是新部署应用的 pod。 +如果要让特定范围的 ​​IP 完全绕过 Istio，则可以配置 Envoy sidecars 以防止它们[拦截](/zh/docs/concepts/traffic-management/)外部请求。要设置绕过 Istio，请更改 `global.proxy.includeIPRanges` 或 `global.proxy.excludeIPRanges` 配置选项，并使用 `kubectl apply` 命令更新 `istio-sidecar-injector` 的[配置](/zh/docs/reference/config/installation-options/)。`istio-sidecar-injector` 配置的更新，影响的是新部署应用的 pod。 {{< warning >}} -与 [Envoy 转发流量到外部服务](#envoy-passthrough-to-external-services) 不同，后者使用 `ALLOW_ANY` 流量策略来让 Istio sidecar 代理将调用传递给未知服务， +与 [Envoy 转发流量到外部服务](#envoy-passthrough-to-external-services)不同，后者使用 `ALLOW_ANY` 流量策略来让 Istio sidecar 代理将调用传递给未知服务， 该方法完全绕过了 sidecar，从而实质上禁用了指定 IP 的所有 Istio 功能。你不能像 `ALLOW_ANY` 方法那样为特定的目标增量添加 service entries。 因此，仅当出于性能或其他原因无法使用边车配置外部访问时，才建议使用此配置方法。 {{< /warning >}} @@ -411,12 +411,12 @@ $ istioctl manifest apply 恶意程序可以绕过 Istio Sidecar 代理并在没有 Istio 控制的情况下访问任何外部服务。 {{< /warning >}} -为了以更安全的方式实施出口流量控制，你必须 [通过egress gateway 引导出口流量](/zh/docs/tasks/traffic-management/egress/egress-gateway/)， +为了以更安全的方式实施出口流量控制，你必须[通过 egress gateway 引导出口流量](/zh/docs/tasks/traffic-management/egress/egress-gateway/)， 并查看[其他安全注意事项](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)部分中描述的安全问题。 ## 清理{#cleanup} -关闭服务 [sleep]({{< github_tree >}}/samples/sleep): +关闭服务 [sleep]({{< github_tree >}}/samples/sleep) : {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md index f93df0847d..1c9734891c 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md @@ -19,7 +19,7 @@ aliases: * 启动 [sleep]({{< github_tree >}}/samples/sleep) 样本应用，作为外部请求的测试源。 - 若已开启 [自动 sidecar 注入](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection)，执行 + 若已开启[自动 sidecar 注入](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection)，执行 {{< text bash >}} $ kubectl apply -f @samples/sleep/sleep.yaml@ @@ -46,7 +46,7 @@ aliases: ## 通过 egress 网关发起 TLS 连接{#perform-TLS-origination-with-an-egress-gateway} -本节描述如何使用 egress 网关发起与示例[为 Egress 流量发起 TLS 连接](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/) 中一样的 TLS。 +本节描述如何使用 egress 网关发起与示例[为 Egress 流量发起 TLS 连接](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中一样的 TLS。 注意，这种情况下，TLS 的发起过程由 egress 网关完成，而不是像之前示例演示的那样由 sidecar 完成。 1. 为 `edition.cnn.com` 定义一个 `ServiceEntry`： @@ -240,7 +240,7 @@ aliases: ... {{< /text >}} - 输出将与在示例 [为 Egress 流量发起 TLS 连接](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/) 中显示的一样，发起 TLS 连接后，不再显示 _301 Moved Permanently_ 消息。 + 输出将与在示例[为 Egress 流量发起 TLS 连接](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中显示的一样，发起 TLS 连接后，不再显示 _301 Moved Permanently_ 消息。 1. 检查 `istio-egressgateway` pod 的日志，将看到一行与请求相关的记录。 若 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： @@ -319,7 +319,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn 为了模拟一个真实的支持双向 TLS 协议的外部服务， 在 Kubernetes 集群中部署一个 [NGINX](https://www.nginx.com) 服务器，该服务器运行在 Istio 服务网格之外，譬如：运行在一个没有开启 Istio sidecar proxy 注入的命名空间中。 -1. 创建一个命名空间，表示 Istio 网格之外的服务， `mesh-external`。注意在这个命名空间中，sidecar 自动注入是没有[开启](/zh/docs/setup/additional-setup/sidecar-injection/#deploying-an-app) 的，不会在 pods 中自动注入 sidecar proxy。 +1. 创建一个命名空间，表示 Istio 网格之外的服务， `mesh-external`。注意在这个命名空间中，sidecar 自动注入是没有[开启](/zh/docs/setup/additional-setup/sidecar-injection/#deploying-an-app)的，不会在 pods 中自动注入 sidecar proxy。 {{< text bash >}} $ kubectl create namespace mesh-external diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md index 24c6ac0f71..b755152415 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md @@ -1,5 +1,5 @@ --- -title: Kubernetes Egress流量服务 +title: Kubernetes Egress 流量服务 description: 展示如何配置 Istio Kubernetes 外部服务。 keywords: [traffic-management,egress] weight: 60 @@ -7,7 +7,7 @@ weight: 60 Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) 服务和带 [Endpoints](https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors) 的 Kubernetes 服务使你可以创建一个外部服务的本地 DNS 别名。这个 DNS 别名与本地服务的 DNS 条目具有相同的形式，即 `..svc.cluster.local`。DNS 别名为您的工作负载提供“位置透明性”：工作负载可以以相同的方式调用本地和外部服务。如果您决定在某个时间在集群内部部署外部服务，您只需更新其 Kubernetes 服务以引用本地版本即可。工作负载将继续运行，而不会有任何变化。 -这部分内容表明这些访问外部服务的 Kubernetes 机制在 Istio 中依然有效。您只需要配置使用 TLS 模式即可，并不需要 Istio 的[双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication)。因为外部服务不是 Istio 服务网格的一部分，所以它们无法执行 Istio 的双向 TLS。您在配置TLS 模式时，一要按照外部服务的 TLS 模式的要求、二要遵从您的工作负载访问外部服务的方式。当您的工作负载发起的是 HTTP 请求但是外部服务需要 TLS，你可以通过 Istio 发起 TLS。当您的工作负载已经使用 TLS 来加密流量，您可以禁用 Istio 的双向 TLS。 +这部分内容表明这些访问外部服务的 Kubernetes 机制在 Istio 中依然有效。您只需要配置使用 TLS 模式即可，并不需要 Istio 的[双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication)。因为外部服务不是 Istio 服务网格的一部分，所以它们无法执行 Istio 的双向 TLS。您在配置 TLS 模式时，一要按照外部服务的 TLS 模式的要求、二要遵从您的工作负载访问外部服务的方式。当您的工作负载发起的是 HTTP 请求但是外部服务需要 TLS，你可以通过 Istio 发起 TLS。当您的工作负载已经使用 TLS 来加密流量，您可以禁用 Istio 的双向 TLS。 虽然此部分的示例使用 HTTP 协议，但是用于引导出口流量的 Kubernetes 服务也可以与其他协议一起使用。 diff --git a/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md b/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md index 1119b642e6..4ae3723c3c 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md @@ -7,7 +7,7 @@ aliases: - /zh/docs/examples/advanced-gateways/egress_sni_monitoring_and_policies/ --- -前面的任务 [使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/) 描述了如何为公共域 `*.wikipedia.org` 中的一组主机启用 Egress 流量，本文基于该任务， +前面的任务[使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/)描述了如何为公共域 `*.wikipedia.org` 中的一组主机启用 Egress 流量，本文基于该任务， 演示如何为 TLS Egress 配置 SNI 监控和策略。 {{< boilerplate before-you-begin-egress >}} @@ -16,10 +16,10 @@ aliases: * [开启 Envoy 的访问日志记录](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging) -* 参考 [使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/) 任务中的 [步骤](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#wildcard-configuration-for-arbitrary-domains)，配置流量流向 `*.wikipedia.org`，且**启用双向 TLS**。 +* 参考[使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/)任务中的[步骤](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#wildcard-configuration-for-arbitrary-domains)，配置流量流向 `*.wikipedia.org`，且**启用双向 TLS**。 {{< warning >}} - **必须** 在你的集群上启用策略检查。请按照 [启用策略检查](/zh/docs/tasks/policy-enforcement/enabling-policy/) + **必须** 在你的集群上启用策略检查。请按照[启用策略检查](/zh/docs/tasks/policy-enforcement/enabling-policy/) 中的步骤操作，以确保策略检查已启用 。 {{< /warning >}} @@ -86,8 +86,8 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ ## 监控 SNI 和源身份标识，并基于它们执行访问策略{#monitor-the-SNI-and-the-source-identity-and-enforce-access-policies-based-on-them} -由于您在 sidecar 代理和 egress 网关之间启用了双向 TLS，因此您可以监控访问外部服务的应用程序的 [服务标识](/zh/docs/ops/deployment/architecture/#citadel)，并根据流量来源的身份标识执行访问策略。 -在 Kubernetes 上的 Istio 中，源身份标识基于 [服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)。 +由于您在 sidecar 代理和 egress 网关之间启用了双向 TLS，因此您可以监控访问外部服务的应用程序的[服务标识](/zh/docs/ops/deployment/architecture/#citadel)，并根据流量来源的身份标识执行访问策略。 +在 Kubernetes 上的 Istio 中，源身份标识基于[服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)。 本小节中，您将在 `sleep-us` 和 `sleep-canada` 服务账户下分别部署 `sleep-us` 和 `sleep-canada` 两个容器。 然后定义一个策略，该策略允许具有 `sleep-us` 标识的应用访问 English 和 Spanish 版本的 Wikipedia 站点，并允许具有 `sleep-canada` 身份标识的应用访问 English 和 French 版本的 Wikipedia 站点。 @@ -180,7 +180,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-serviceaccount.yaml@ ## 清除{#cleanup} -1. 执行 [使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/) 任务的 [清除步骤](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#cleanup-wildcard-configuration-for-arbitrary-domains)。 +1. 执行[使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/)任务的[清除步骤](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#cleanup-wildcard-configuration-for-arbitrary-domains)。 1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务: diff --git a/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md b/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md index 1ebe629ebe..bf9b1a98da 100644 --- a/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md @@ -7,7 +7,7 @@ aliases: - /zh/docs/examples/advanced-gateways/wildcard-egress-hosts/ --- -[控制 Egress 流量](/zh/docs/tasks/traffic-management/egress/) 任务和[配置一个 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/) 示例描述如何配置特定主机的 egress 流量，如：`edition.cnn.com`。本示例描述如何为通用域中的一组特定主机开启 egress 流量，譬如：`*.wikipedia.org`，无需单独配置每一台主机。 +[控制 Egress 流量](/zh/docs/tasks/traffic-management/egress/)任务和[配置一个 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/)示例描述如何配置特定主机的 egress 流量，如：`edition.cnn.com`。本示例描述如何为通用域中的一组特定主机开启 egress 流量，譬如：`*.wikipedia.org`，无需单独配置每一台主机。 ## 背景{#background} @@ -79,7 +79,7 @@ $ kubectl delete virtualservice wikipedia ## 配置访问 wildcard 主机的 egress 网关{#configure-egress-gateway-traffic-to-a-wildcard-host} 能否配置通过 egress 网关访问 wildcard 主机取决于这组 wildcard 域名有唯一一个通用主机。 -以 _*.wikipedia.org_ 为例。每个语种特殊的站点都有自己的 _wikipedia.org_ 服务器。您可以向任意一个 _*.wikipedia.org_ 站点的 IP 发送请求，包括 _www.wikipedia.org_，该站点 [管理服务](https://en.wikipedia.org/wiki/Virtual_hosting) 所有特定主机。 +以 _*.wikipedia.org_ 为例。每个语种特殊的站点都有自己的 _wikipedia.org_ 服务器。您可以向任意一个 _*.wikipedia.org_ 站点的 IP 发送请求，包括 _www.wikipedia.org_，该站点[管理服务](https://en.wikipedia.org/wiki/Virtual_hosting)所有特定主机。 通常情况下，通用域中的所有域名并不由一个唯一的 hosting server 提供服务。此时，需要一个更加复杂的配置。 diff --git a/content/zh/docs/tasks/traffic-management/fault-injection/index.md b/content/zh/docs/tasks/traffic-management/fault-injection/index.md index aef567f393..538fc5b964 100644 --- a/content/zh/docs/tasks/traffic-management/fault-injection/index.md +++ b/content/zh/docs/tasks/traffic-management/fault-injection/index.md @@ -16,7 +16,7 @@ aliases: * 部署示例应用程序 [Bookinfo](/zh/docs/examples/bookinfo/)，并应用 [默认目标规则](/zh/docs/examples/bookinfo/#apply-default-destination-rules)。 -* 在[流量管理](/zh/docs/concepts/traffic-management) 概念文档中查看有关故障注入的讨论。 +* 在[流量管理](/zh/docs/concepts/traffic-management)概念文档中查看有关故障注入的讨论。 * 通过执行[配置请求路由](/zh/docs/tasks/traffic-management/request-routing/)任务或运行以下命令来初始化应用程序版本路由： @@ -191,4 +191,4 @@ Istio 的故障注入规则可以帮助您识别此类异常，而不会影响 $ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@ {{< /text >}} -1. 如果您不打算探索任何后续任务，请参阅[Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup)说明以关闭应用程序。 +1. 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup)说明以关闭应用程序。 diff --git a/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md b/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md index 5d5e77d374..66c99722d1 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md @@ -8,7 +8,7 @@ aliases: - /zh/docs/tasks/ingress --- -在 Kubernetes 环境中，使用 [Kubernetes Ingress 资源](https://kubernetes.io/docs/concepts/services-networking/ingress/) 来指定需要暴露到集群外的服务。 +在 Kubernetes 环境中，使用 [Kubernetes Ingress 资源](https://kubernetes.io/docs/concepts/services-networking/ingress/)来指定需要暴露到集群外的服务。 在 Istio 服务网格中，更好的选择（同样适用于 Kubernetes 及其他环境）是使用一种新的配置模型，名为 [Istio Gateway](/zh/docs/reference/config/networking/gateway/)。 `Gateway` 允许应用一些诸如监控和路由规则的 Istio 特性来管理进入集群的流量。 @@ -122,7 +122,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 其中配置了对外暴露的端口、协议等。 但是，不像 [Kubernetes Ingress 资源](https://kubernetes.io/docs/concepts/services-networking/ingress/)，ingress Gateway 不包含任何流量路由配置。Ingress 流量的路由使用 Istio 路由规则来配置，和内部服务请求完全一样。 -让我们一起来看如何为 HTTP 流量在80端口上配置 `Gateway`。 +让我们一起来看如何为 HTTP 流量在 80 端口上配置 `Gateway`。 1. 创建 Istio `Gateway`： @@ -172,7 +172,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 EOF {{< /text >}} - 已为 `httpbin` 服务创建了[虚拟服务](/zh/docs/reference/config/networking/virtual-service/) 配置，包含两个路由规则，允许流量流向路径 `/status` 和 `/delay`。 + 已为 `httpbin` 服务创建了[虚拟服务](/zh/docs/reference/config/networking/virtual-service/)配置，包含两个路由规则，允许流量流向路径 `/status` 和 `/delay`。 [gateways](/zh/docs/reference/config/networking/virtual-service/#VirtualService-gateways) 列表规约了哪些请求允许通过 `httpbin-gateway` 网关。 所有其他外部请求均被拒绝并返回 404 响应。 @@ -181,7 +181,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 来自网格内部其他服务的内部请求无需遵循这些规则，而是默认遵守轮询调度路由规则。 你可以为 `gateways` 列表添加特定的 `mesh` 值，将这些规则同时应用到内部请求。 由于服务的内部主机名可能与外部主机名不一致（譬如： `httpbin.default.svc.cluster.local`），你需要同时将内部主机名添加到 `hosts` 列表中。 - 详情请参考 [操作指南](/zh/docs/ops/common-problems/network-issues#route-rules-have-no-effect-on-ingress-gateway-requests)。 + 详情请参考[操作指南](/zh/docs/ops/common-problems/network-issues#route-rules-have-no-effect-on-ingress-gateway-requests)。 {{< /warning >}} 1. 使用 _curl_ 访问 _httpbin_ 服务： @@ -198,7 +198,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 x-envoy-upstream-service-time: 48 {{< /text >}} - 注意上文命令使用 `-H` 标识将 HTTP头部参数 _Host_ 设置为 "httpbin.example.com"。 + 注意上文命令使用 `-H` 标识将 HTTP 头部参数 _Host_ 设置为 "httpbin.example.com"。 该操作为必须操作，因为 ingress `Gateway` 已被配置用来处理 "httpbin.example.com" 的服务请求，而在测试环境中并没有为该主机绑定 DNS 而是简单直接地向 ingress IP 发送请求。 1. 访问其他没有被显式暴露的 URL 时，将看到 HTTP 404 错误： @@ -213,7 +213,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 ## 通过浏览器访问 ingress 服务{#accessing-ingress-services-using-a-browser} -在浏览器中输入 `httpbin` 服务的URL 不能获得有效的响应，因为无法像 `curl` 那样，将请求头部参数 _Host_ 传给浏览器。在现实场景中，这并不是问题，因为你需要合理配置被请求的主机及可解析的 DNS，从而在 URL 中使用主机的域名，譬如： `https://httpbin.example.com/status/200`。 +在浏览器中输入 `httpbin` 服务的 URL 不能获得有效的响应，因为无法像 `curl` 那样，将请求头部参数 _Host_ 传给浏览器。在现实场景中，这并不是问题，因为你需要合理配置被请求的主机及可解析的 DNS，从而在 URL 中使用主机的域名，譬如： `https://httpbin.example.com/status/200`。 为了在简单的测试和演示中绕过这个问题，请在 `Gateway` 和 `VirtualService` 配置中使用通配符 `*`。譬如，修改 ingress 配置如下： @@ -255,7 +255,7 @@ spec: EOF {{< /text >}} -此时，便可以在浏览器中输入包含 `$INGRESS_HOST:$INGRESS_PORT` 的URL。譬如，输入`http://$INGRESS_HOST:$INGRESS_PORT/headers`，将显示浏览器发送的所有 headers 信息。 +此时，便可以在浏览器中输入包含 `$INGRESS_HOST:$INGRESS_PORT` 的 URL。譬如，输入`http://$INGRESS_HOST:$INGRESS_PORT/headers`，将显示浏览器发送的所有 headers 信息。 ## 理解原理{#understanding-what-happened} diff --git a/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md b/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md index ba75301b6e..43834e2c39 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md @@ -211,7 +211,7 @@ aliases: EOF {{< /text >}} -1. 根据 [确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports) 中的指令来定义环境变量 `SECURE_INGRESS_PORT` 和 `INGRESS_HOST`。 +1. 根据[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的指令来定义环境变量 `SECURE_INGRESS_PORT` 和 `INGRESS_HOST`。 1. 从集群外访问 NGINX 服务。注意，服务端返回了正确的证书，并且该证书已成功验证（输出了 _SSL certificate verify ok_ ）。 diff --git a/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md b/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md index 3a84e1da3a..875e46204e 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md @@ -319,7 +319,7 @@ $ openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_se ### 配置 `bookinfo.com` 主机的流量{#configure-traffic-for-the-book-info-host} -1. 部署[Bookinfo 示例应用](/zh/docs/examples/bookinfo/)，但不要部署网关： +1. 部署 [Bookinfo 示例应用](/zh/docs/examples/bookinfo/)，但不要部署网关： {{< text bash >}} $ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@ diff --git a/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md b/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md index 16f2e50144..3c36df0924 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md @@ -7,7 +7,7 @@ aliases: keywords: [traffic-management,ingress,sds-credentials] --- -[控制 Ingress 流量任务](/zh/docs/tasks/traffic-management/ingress) 中描述了如何进行配置， +[控制 Ingress 流量任务](/zh/docs/tasks/traffic-management/ingress)中描述了如何进行配置， 通过 Ingress Gateway 把服务的 HTTP 端点暴露给外部。 这里更进一步，使用单向或者双向 TLS 来完成开放服务的任务。 @@ -15,7 +15,7 @@ keywords: [traffic-management,ingress,sds-credentials] ## 开始之前 {#before-you-begin} -1. 首先执行 [Ingress 任务的初始化步骤](/zh/docs/tasks/traffic-management/ingress/ingress-control#before-you-begin)，然后执行[Ingress 流量控制](/zh/docs/tasks/traffic-management/ingress/ingress-control)部分中[获取 Ingress 的地址和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)，在完成这些步骤之后，也就是完成了 Istio 和 [httpbin]({{< github_tree >}}/samples/httpbin) 的部署，并设置了 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT` 两个环境变量的值。 +1. 首先执行 [Ingress 任务的初始化步骤](/zh/docs/tasks/traffic-management/ingress/ingress-control#before-you-begin)，然后执行 [Ingress 流量控制](/zh/docs/tasks/traffic-management/ingress/ingress-control)部分中[获取 Ingress 的地址和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)，在完成这些步骤之后，也就是完成了 Istio 和 [httpbin]({{< github_tree >}}/samples/httpbin) 的部署，并设置了 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT` 两个环境变量的值。 1. macOS 用户应该检查一下本机的 `curl` 是否是使用 [LibreSSL](http://www.libressl.org) 库进行编译的： @@ -27,7 +27,7 @@ keywords: [traffic-management,ingress,sds-credentials] 如果上面的命令输出了一段 LibreSSL 的版本信息，就说明你的 `curl` 命令可以完成本任务的内容。否则就要想办法换一个不同的 `curl` 了，例如可以换用一台运行 Linux 的工作站。 {{< tip >}} -如果使用[基于文件安装的方法](/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount)配置了 ingress gateway ，并且想要迁移 ingress gateway 使用SDS方法。 无需其他步骤。 +如果使用[基于文件安装的方法](/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount)配置了 ingress gateway ，并且想要迁移 ingress gateway 使用 SDS 方法。 无需其他步骤。 {{< /tip >}} ## 为服务器和客户端生成证书 {#generate-client-and-server-certificates-and-keys} diff --git a/content/zh/docs/tasks/traffic-management/mirroring/index.md b/content/zh/docs/tasks/traffic-management/mirroring/index.md index 536b6de916..eb92e9915a 100644 --- a/content/zh/docs/tasks/traffic-management/mirroring/index.md +++ b/content/zh/docs/tasks/traffic-management/mirroring/index.md @@ -230,7 +230,7 @@ keywords: [traffic-management,mirroring] 这个路由规则发送 100% 流量到 `v1`。最后一段表示你将镜像流量到 `httpbin:v2` 服务。当流量被镜像时，请求将发送到镜像服务中，并在 `headers` 中的 `Host/Authority` 属性值上追加 `-shadow`。例如 `cluster-1` 变为 `cluster-1-shadow`。 - 此外，重点注意这些被镜像的流量是『即发即弃』的，就是说镜像请求的响应会被丢弃。 + 此外，重点注意这些被镜像的流量是『 即发即弃』 的，就是说镜像请求的响应会被丢弃。 您可以使用 `mirror_percent` 属性来设置镜像流量的百分比，而不是镜像全部请求。为了兼容老版本，如果这个属性不存在，将镜像所有流量。 1. 发送流量： @@ -362,7 +362,7 @@ keywords: [traffic-management,mirroring] ..t...|. {{< /text >}} - 您可以看到流量​​的请求和响应内容。 + 您可以看到流量​​ 的请求和响应内容。 ## 清理{#cleaning-up} diff --git a/content/zh/docs/tasks/traffic-management/request-routing/index.md b/content/zh/docs/tasks/traffic-management/request-routing/index.md index 4fc93d7d78..685dce4a14 100644 --- a/content/zh/docs/tasks/traffic-management/request-routing/index.md +++ b/content/zh/docs/tasks/traffic-management/request-routing/index.md @@ -196,4 +196,4 @@ Istio [Bookinfo](/zh/docs/examples/bookinfo/) 示例包含四个独立的微服 $ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@ {{< /text >}} -1. 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup) 的说明关闭应用程序。 +1. 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup)的说明关闭应用程序。 diff --git a/content/zh/docs/tasks/traffic-management/request-timeouts/index.md b/content/zh/docs/tasks/traffic-management/request-timeouts/index.md index 7e809f7698..15a12292be 100644 --- a/content/zh/docs/tasks/traffic-management/request-timeouts/index.md +++ b/content/zh/docs/tasks/traffic-management/request-timeouts/index.md @@ -127,4 +127,4 @@ http 请求的超时可以用[路由规则](/zh/docs/reference/config/networking $ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@ {{< /text >}} -* 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup) 的说明关闭应用程序。 +* 如果您不打算探索任何后续任务，请参阅 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup)的说明关闭应用程序。 diff --git a/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md b/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md index c1a10d029e..e4956da229 100644 --- a/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md +++ b/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md @@ -17,7 +17,7 @@ aliases: * 按照[安装指南](/zh/docs/setup/)中的说明安装 Istio。 -* 回顾[流量管理](/zh/docs/concepts/traffic-management) 概念文档。 +* 回顾[流量管理](/zh/docs/concepts/traffic-management)概念文档。 ## 应用基于权重的 TCP 路由{#apply-weight-based-tcp-routing} diff --git a/content/zh/events/banners/kubecon-america-2019.md b/content/zh/events/banners/kubecon-america-2019.md index caa3430585..ae9386c65f 100644 --- a/content/zh/events/banners/kubecon-america-2019.md +++ b/content/zh/events/banners/kubecon-america-2019.md @@ -6,4 +6,4 @@ max_impressions: 20 timeout: 20 --- -KubeCon 2019 北美会议， 11 月 18 日至 11月 21 日，在圣地亚哥举办。 \ No newline at end of file +KubeCon 2019 北美会议， 11 月 18 日至 11 月 21 日，在圣地亚哥举办。 diff --git a/content/zh/events/banners/kubecon-europe-2020.md b/content/zh/events/banners/kubecon-europe-2020.md index 906e55b645..4a84a40846 100644 --- a/content/zh/events/banners/kubecon-europe-2020.md +++ b/content/zh/events/banners/kubecon-europe-2020.md @@ -6,4 +6,4 @@ max_impressions: 20 timeout: 20 --- -KubeCon 2020 欧洲会议， 3 月 30 日至 4 月 2 日，在阿姆斯特丹举办。 \ No newline at end of file +KubeCon 2020 欧洲会议， 3 月 30 日至 4 月 2 日，在阿姆斯特丹举办。 diff --git a/content/zh/events/banners/latest-release.md b/content/zh/events/banners/latest-release.md index 16d035ad1d..e5318b5080 100644 --- a/content/zh/events/banners/latest-release.md +++ b/content/zh/events/banners/latest-release.md @@ -6,4 +6,4 @@ max_impressions: 3 link: /docs/setup/getting-started/#download --- -Istio {{< istio_version >}} 现在可用！点击这里下载。 \ No newline at end of file +Istio {{< istio_version >}} 现在可用！点击这里下载。 diff --git a/content/zh/events/index.md b/content/zh/events/index.md index d4097be175..0e5c52b221 100644 --- a/content/zh/events/index.md +++ b/content/zh/events/index.md @@ -2,4 +2,4 @@ headless: true --- -这个文件告诉 Hugo 引擎，在生成页面时，所有放置在当前目录树下的文件都不需要生成独立的页面在站点中显示。 \ No newline at end of file +这个文件告诉 Hugo 引擎，在生成页面时，所有放置在当前目录树下的文件都不需要生成独立的页面在站点中显示。 diff --git a/content/zh/faq/_index.md b/content/zh/faq/_index.md index b320e52486..6ccbd568a5 100644 --- a/content/zh/faq/_index.md +++ b/content/zh/faq/_index.md @@ -1,6 +1,6 @@ --- title: FAQ -description: 关于Istio的常见问题。 +description: 关于 Istio 的常见问题。 weight: 1 layout: faq-landing aliases: diff --git a/content/zh/faq/applications/cassandra.md b/content/zh/faq/applications/cassandra.md index ed6994166b..d754f4cec9 100644 --- a/content/zh/faq/applications/cassandra.md +++ b/content/zh/faq/applications/cassandra.md @@ -10,4 +10,4 @@ keywords: [cassandra] 有两个配置参数要注意： [`listen_address`](http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html?highlight=listen_address#listen-address) 和 [`broadcast_address`](http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html?highlight=listen_address#broadcast-address)。为了在 Istio 网格中运行 Cassandra，应该将 `listen_address` 参数设置为 `127.0.0.1`，将 `broadcast_address` 参数设置为 Pod IP 地址。 -这些配置参数在 Cassandra 配置目录（例如 `/etc/cassandra`）的 `cassandra.yaml` 中定义。有多种用于启动 Cassandra 的脚本（和 yaml 文件），应注意这些脚本如何设置这些参数。例如，一些用于配置和启动 Cassandra 的脚本使用环境变量 `CASSANDRA_LISTEN_ADDRESS` 的值来设置 `listen_address`。 \ No newline at end of file +这些配置参数在 Cassandra 配置目录（例如 `/etc/cassandra`）的 `cassandra.yaml` 中定义。有多种用于启动 Cassandra 的脚本（和 yaml 文件），应注意这些脚本如何设置这些参数。例如，一些用于配置和启动 Cassandra 的脚本使用环境变量 `CASSANDRA_LISTEN_ADDRESS` 的值来设置 `listen_address`。 diff --git a/content/zh/faq/distributed-tracing/disabling-tracing.md b/content/zh/faq/distributed-tracing/disabling-tracing.md index c4803a14f7..be2d590ab0 100644 --- a/content/zh/faq/distributed-tracing/disabling-tracing.md +++ b/content/zh/faq/distributed-tracing/disabling-tracing.md @@ -17,4 +17,4 @@ $ kubectl -n istio-system edit deployment istio-telemetry 然后遵循[分布式追踪任务的清理部分](/zh/docs/tasks/observability/distributed-tracing/zipkin/#cleanup)的步骤进行后续操作。 -如果您不想要追踪功能，那么就在安装 Istio 时[禁用追踪](/zh/docs/tasks/observability/distributed-tracing/zipkin/#before-you-begin)。 \ No newline at end of file +如果您不想要追踪功能，那么就在安装 Istio 时[禁用追踪](/zh/docs/tasks/observability/distributed-tracing/zipkin/#before-you-begin)。 diff --git a/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md b/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md index b5d1a41c11..35c2bac32a 100644 --- a/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md +++ b/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md @@ -5,4 +5,4 @@ weight: 0 Istio 以两种不同的方式与分布式追踪系统集成: 基于 [Envoy](#how-envoy-based-tracing-works)(#how-mixer-based-tracing-works) 的和基于 [Mixer](#how-mixer-based-tracing-works) 的。 这两种追踪集成方法，都由[应用程序负责为后续传出请求转发追踪的 header 信息](#istio-copy-headers)。 -您可以在 Istio 分布式追踪（[Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/), [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/), [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/)）任务以及 [Envoy 追踪文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing) 中找到更多信息。 +您可以在 Istio 分布式追踪（[Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/), [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/), [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/)）任务以及 [Envoy 追踪文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing)中找到更多信息。 diff --git a/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md b/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md index 7d8a1922d1..070225d37f 100644 --- a/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md +++ b/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md @@ -12,4 +12,4 @@ Envoy： - 将生成的跟踪范围发送到跟踪后端 - 将跟踪头转发到代理的应用程序 -Istio 支持基于 Envoy 的 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 和 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/) 的集成， 以及所有与 Zipkin API 兼容的后端，包括 [Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)。 \ No newline at end of file +Istio 支持基于 Envoy 的 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 和 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/) 的集成， 以及所有与 Zipkin API 兼容的后端，包括 [Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)。 diff --git a/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md b/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md index c75b96a27f..df4bb9aa38 100644 --- a/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md +++ b/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md @@ -16,4 +16,4 @@ Mixer： - 基于 *operator-supplied* 配置为每个请求生成跟踪的范围 - 将生成的跟踪范围发送到 *operator-designated* 跟踪后端 -使用 Istio 的 [Stackdriver 跟踪集成](https://cloud.google.com/istio/docs/istio-on-gke/installing#tracing_and_logging) 是通过 Mixer 进行跟踪集成的一个示例。 +使用 Istio 的 [Stackdriver 跟踪集成](https://cloud.google.com/istio/docs/istio-on-gke/installing#tracing_and_logging)是通过 Mixer 进行跟踪集成的一个示例。 diff --git a/content/zh/faq/distributed-tracing/istio-copy-headers.md b/content/zh/faq/distributed-tracing/istio-copy-headers.md index 7eeea1fd99..60adeb3ed1 100644 --- a/content/zh/faq/distributed-tracing/istio-copy-headers.md +++ b/content/zh/faq/distributed-tracing/istio-copy-headers.md @@ -3,4 +3,4 @@ title: 为什么 Istio 不能代替应用程序传播标头？ weight: 20 --- -尽管 Istio Sidecar 将处理关联应用程序实例的入站和出站请求，它没有将出站请求与导致它们的入站请求相关联的隐式方法。可以实现这种关联的唯一方法是通过应用程序传播相关信息（例如标头）从入站请求到出站请求。头传播可以通过客户端库或手动完成。提供了进一步的讨论 [使用 Istio 进行分布式跟踪需要什么？](/zh/faq/distributed-tracing/#how-to-support-tracing). +尽管 Istio Sidecar 将处理关联应用程序实例的入站和出站请求，它没有将出站请求与导致它们的入站请求相关联的隐式方法。可以实现这种关联的唯一方法是通过应用程序传播相关信息（例如标头）从入站请求到出站请求。头传播可以通过客户端库或手动完成。提供了进一步的讨论[使用 Istio 进行分布式跟踪需要什么？](/zh/faq/distributed-tracing/#how-to-support-tracing). diff --git a/content/zh/faq/distributed-tracing/minimal-requirements.md b/content/zh/faq/distributed-tracing/minimal-requirements.md index fe34473ad0..06d3ea8521 100644 --- a/content/zh/faq/distributed-tracing/minimal-requirements.md +++ b/content/zh/faq/distributed-tracing/minimal-requirements.md @@ -3,4 +3,4 @@ title: 分布式追踪所需的 Istio 最低配置是什么？ weight: 13 --- -启用了追踪功能的 Istio [最低配置文件](/zh/docs/setup/install/helm/)是 Istio 与 Zipkin 兼容后端集成所需的全部内容。 \ No newline at end of file +启用了追踪功能的 Istio [最低配置文件](/zh/docs/setup/install/helm/)是 Istio 与 Zipkin 兼容后端集成所需的全部内容。 diff --git a/content/zh/faq/general/how-do-i-get-started.md b/content/zh/faq/general/how-do-i-get-started.md index d265e631f4..e9133d9d31 100644 --- a/content/zh/faq/general/how-do-i-get-started.md +++ b/content/zh/faq/general/how-do-i-get-started.md @@ -3,6 +3,6 @@ title: 我如何开始使用 Istio ？ weight: 30 --- -我们建议从 [指南](/zh/docs/examples/) 开始，该指南以教程的形式介绍了 Istio 不同的核心概念。该指南中的案例包括了智能路由、策略执行、安全、遥测等。 +我们建议从[指南](/zh/docs/examples/)开始，该指南以教程的形式介绍了 Istio 不同的核心概念。该指南中的案例包括了智能路由、策略执行、安全、遥测等。 -要在现有 Kubernetes 或 Consul 上部署和使用 Istio，请参阅我们的 [安装说明](/zh/docs/setup/)。 \ No newline at end of file +要在现有 Kubernetes 或 Consul 上部署和使用 Istio，请参阅我们的[安装说明](/zh/docs/setup/)。 diff --git a/content/zh/faq/general/istio-doesnt-work.md b/content/zh/faq/general/istio-doesnt-work.md index 0fe84f5f64..5cb84a5abf 100644 --- a/content/zh/faq/general/istio-doesnt-work.md +++ b/content/zh/faq/general/istio-doesnt-work.md @@ -3,4 +3,4 @@ title: Istio 不工作了应该怎么做？ weight: 90 --- -查看 [操作指南](/zh/docs/ops/) 寻找解决方案或者 [错误报告](/zh/about/bugs/) 页面去提交错误。 +查看[操作指南](/zh/docs/ops/)寻找解决方案或者[错误报告](/zh/about/bugs/)页面去提交错误。 diff --git a/content/zh/faq/general/roadmap.md b/content/zh/faq/general/roadmap.md index f903667120..2c015d18e8 100644 --- a/content/zh/faq/general/roadmap.md +++ b/content/zh/faq/general/roadmap.md @@ -3,4 +3,4 @@ title: Istio 的路线图是什么？ weight: 140 --- -查看我们的 [功能状态页面](/zh/about/feature-stages/) 和 [新闻](/zh/news) 获取最新动态。 +查看我们的[功能状态页面](/zh/about/feature-stages/)和[新闻](/zh/news)获取最新动态。 diff --git a/content/zh/faq/general/what-does-istio-mean.md b/content/zh/faq/general/what-does-istio-mean.md index 7dabfb620f..5ce6a61a93 100644 --- a/content/zh/faq/general/what-does-istio-mean.md +++ b/content/zh/faq/general/what-does-istio-mean.md @@ -3,4 +3,4 @@ title: “Istio” 这个词是什么意思？ weight: 160 --- -它是希腊语中的 “sail”。 \ No newline at end of file +它是希腊语中的 “sail”。 diff --git a/content/zh/faq/general/what-is-istio.md b/content/zh/faq/general/what-is-istio.md index c174675485..ddaea2b8a6 100644 --- a/content/zh/faq/general/what-is-istio.md +++ b/content/zh/faq/general/what-is-istio.md @@ -11,4 +11,4 @@ Istio 是一个开放的、与平台无关的服务网格，提供了流量管 *服务网格* ：Istio 的设计目标是管理微服务间和应用程序间的通信问题。而不用修改底层服务，Istio 针对所有服务之间的通信提供了自动的基线流量弹性，服务指标收集，分布式追踪，流量加密，协议升级和高级路由功能。 -更多介绍，请看这里[Istio 是什么](/zh/docs/concepts/what-is-istio/) +更多介绍，请看这里 [Istio 是什么](/zh/docs/concepts/what-is-istio/) diff --git a/content/zh/faq/mixer/header-rules.md b/content/zh/faq/mixer/header-rules.md index 6edfd95d9b..8e98085392 100644 --- a/content/zh/faq/mixer/header-rules.md +++ b/content/zh/faq/mixer/header-rules.md @@ -3,8 +3,8 @@ title: 为什么我的规则无法匹配? weight: 50 --- -Mixer 的规则必须在运行时验证。这意味着匹配条件的必须是 [语言](/zh/docs/reference/config/policy-and-telemetry/expression-language/) 中定义良好的表达式， -属性是 [属性清单](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/) 中声明过的， +Mixer 的规则必须在运行时验证。这意味着匹配条件的必须是[语言](/zh/docs/reference/config/policy-and-telemetry/expression-language/)中定义良好的表达式， +属性是[属性清单](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)中声明过的， 并且规则所指向的 handler 和 instance 也必须存在。 在执行规则之前，属性值通常会被标准化。比如，在 `request.headers` 和 `response.headers` 属性中，HTTP 头的键是小写的。 diff --git a/content/zh/faq/security/accessing-non-istio-services.md b/content/zh/faq/security/accessing-non-istio-services.md index af4a94eef0..899bd708c0 100644 --- a/content/zh/faq/security/accessing-non-istio-services.md +++ b/content/zh/faq/security/accessing-non-istio-services.md @@ -25,4 +25,4 @@ EOF 如果安装 Istio 时就启用了双向 TLS，那这个目标规则已经添加到 system 了。 {{< /tip >}} -类似的，你也可以为其它非 Istio 服务添加目标规则。了解更多实例，参见 [任务](/zh/docs/tasks/security/authentication/authn-policy/#request-from-Istio-services-to-non-Istio-services)。 +类似的，你也可以为其它非 Istio 服务添加目标规则。了解更多实例，参见[任务](/zh/docs/tasks/security/authentication/authn-policy/#request-from-Istio-services-to-non-Istio-services)。 diff --git a/content/zh/faq/security/auth-mix-and-match.md b/content/zh/faq/security/auth-mix-and-match.md index 4ddf999cb4..aa6231091a 100644 --- a/content/zh/faq/security/auth-mix-and-match.md +++ b/content/zh/faq/security/auth-mix-and-match.md @@ -3,5 +3,5 @@ title: 在同一集群中，我可以为部分服务开启 TLS 双向认证， weight: 20 --- -[认证策略](/zh/docs/concepts/security/#authentication-policies) 可以配置为 mesh-wide（影响网络中的所有服务）、namespace-wide（namespace 中的所有服务）或某个特定服务。 +[认证策略](/zh/docs/concepts/security/#authentication-policies)可以配置为 mesh-wide（影响网络中的所有服务）、namespace-wide（namespace 中的所有服务）或某个特定服务。 您可以根据需要对集群中的服务配置一种或多种 TLS 双向认证策略。 diff --git a/content/zh/faq/security/k8s-health-checks.md b/content/zh/faq/security/k8s-health-checks.md index 0d8cb387de..b28a1fd8df 100644 --- a/content/zh/faq/security/k8s-health-checks.md +++ b/content/zh/faq/security/k8s-health-checks.md @@ -4,7 +4,7 @@ weight: 50 --- 如果启用了双向 TLS 认证，则来自 kubelet 的 HTTP 和 TCP 健康检查将不能正常工作，因为 kubelet 没有 Istio 颁发的证书。 -从Istio 1.1 开始，我们提供了多种解决方案。 +从 Istio 1.1 开始，我们提供了多种解决方案。 1. 使用 probe rewrite 将 liveness 和 readiness 的请求直接重定向到工作负载。有关更多信息，请参阅 [Probe Rewrite](/zh/docs/ops/configuration/mesh/app-health-check/#probe-rewrite)。 diff --git a/content/zh/faq/security/mysql-with-mtls.md b/content/zh/faq/security/mysql-with-mtls.md index b872d51475..9d6b88a035 100644 --- a/content/zh/faq/security/mysql-with-mtls.md +++ b/content/zh/faq/security/mysql-with-mtls.md @@ -5,7 +5,7 @@ weight: 95 keywords: [mysql,mtls] --- -安装 Istio 后您可能会发现 MySQL 无法连接。这是因为 `istio-demo.yaml` 中默认使用的 `PERMISSIVE` 模式不适用于 MySQL。您可能会看到类似于 "ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0" 的错误。 +安装 Istio 后您可能会发现 MySQL 无法连接。这是因为 `istio-demo.yaml` 中默认使用的 `PERMISSIVE` 模式不适用于 MySQL。您可能会看到类似于 "ERROR 2013 (HY000) : Lost connection to MySQL server at 'reading initial communication packet', system error: 0" 的错误。 有两种方法可以解决此问题。 diff --git a/content/zh/faq/security/secret-encryption.md b/content/zh/faq/security/secret-encryption.md index 52d26c2440..847de34b87 100644 --- a/content/zh/faq/security/secret-encryption.md +++ b/content/zh/faq/security/secret-encryption.md @@ -3,6 +3,6 @@ title: 是否为工作负载中的密钥和证书进行了加密？ weight: 125 --- -默认情况下，它们是 base64 编码的，但未加密。但是，您可以按照 Kubernetes 中支持的[加密特性](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) 来进行操作。 +默认情况下，它们是 base64 编码的，但未加密。但是，您可以按照 Kubernetes 中支持的[加密特性](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)来进行操作。 -请注意，在 Google Container Engine (GKE) 中尚未启用此功能。 尽管可能不会在主节点上运行的 etcd 内部对数据进行加密，但主节点本身的内容将被加密，更多相关信息，请参照 [此处](https://cloud.google.com/security/encryption-at-rest/default-encryption/#encryption_of_data_at_rest) 。 \ No newline at end of file +请注意，在 Google Container Engine (GKE) 中尚未启用此功能。 尽管可能不会在主节点上运行的 etcd 内部对数据进行加密，但主节点本身的内容将被加密，更多相关信息，请参照[此处](https://cloud.google.com/security/encryption-at-rest/default-encryption/#encryption_of_data_at_rest) 。 diff --git a/content/zh/faq/security/use-k8s-secrets.md b/content/zh/faq/security/use-k8s-secrets.md index 2cf7a6d777..6e81554694 100644 --- a/content/zh/faq/security/use-k8s-secrets.md +++ b/content/zh/faq/security/use-k8s-secrets.md @@ -5,6 +5,6 @@ weight: 120 是的，Istio 认证的密钥和证书分发基于 [Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/) 实现。 -Secret [安全风险](https://kubernetes.io/docs/concepts/configuration/secret/#risks) 需知。 -Kubernetes 团队正在研究 [多种特性](https://docs.google.com/document/d/1T2y-9geg9EfHHtCDYTXptCa-F4kQ0RyiH-c_M1SyD0s)，以从 secret 加密到节点级访问控制，全面增强 Kubernetes secret 的安全性。 -从 1.6 版本开始，Kubernetes 引入了 [RBAC认证](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)，可以提供细粒度的 secret 管理。 +Secret [安全风险](https://kubernetes.io/docs/concepts/configuration/secret/#risks)需知。 +Kubernetes 团队正在研究[多种特性](https://docs.google.com/document/d/1T2y-9geg9EfHHtCDYTXptCa-F4kQ0RyiH-c_M1SyD0s)，以从 secret 加密到节点级访问控制，全面增强 Kubernetes secret 的安全性。 +从 1.6 版本开始，Kubernetes 引入了 [RBAC 认证](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)，可以提供细粒度的 secret 管理。 diff --git a/content/zh/news/releases/0.x/announcing-0.1/index.md b/content/zh/news/releases/0.x/announcing-0.1/index.md index 5e986ee0b6..7cb6be4d7b 100644 --- a/content/zh/news/releases/0.x/announcing-0.1/index.md +++ b/content/zh/news/releases/0.x/announcing-0.1/index.md @@ -30,7 +30,7 @@ Istio 为微服务添加了流量管理能力，同时为比如安全、监控 想象一下如果我们可以在服务和网络之间透明的注入一层基础设施来给予运维人员所需要的控制能力的同时又能让开发人员免除需要将解决分布式系统问题的代码糅合到业务代码的烦恼。这种一致的基础设施层与服务开发的搭配通常被称之为 **_服务网格_**。正如微服务帮助不同的功能团队之间互相解耦，服务网格可以帮助解除功能开发和发布流程之间的耦合。Istio 通过在不同的服务网络间注入代理来将不同的微服务集成进同一个服务网格。 -Google、IBM 和 Lyft 为了共同的愿景，基于为内部和企业客户构建和管理大规模微服务的经验合力创造了 Istio，以此来为微服务的开发和维护提供一个可靠的基础。Google 和 IBM 在他们自身的应用以及他们的企业客户的敏感的／受管制的环境中实施大规模微服务时积累了丰富的经验，同时 Lyft 开发了 Envoy 以解决他们内部面对的挑战。在成功的将其应用于生产环境，管理过能每秒处理两百万个请求的分布于上万个虚拟机 超过100个微服务一年后 [Lyft 开源 Envoy](https://eng.lyft.com/announcing-envoy-c-l7-proxy-and-communication-bus-92520b6c8191) 。 +Google、IBM 和 Lyft 为了共同的愿景，基于为内部和企业客户构建和管理大规模微服务的经验合力创造了 Istio，以此来为微服务的开发和维护提供一个可靠的基础。Google 和 IBM 在他们自身的应用以及他们的企业客户的敏感的／ 受管制的环境中实施大规模微服务时积累了丰富的经验，同时 Lyft 开发了 Envoy 以解决他们内部面对的挑战。在成功的将其应用于生产环境，管理过能每秒处理两百万个请求的分布于上万个虚拟机 超过 100 个微服务一年后 [Lyft 开源 Envoy](https://eng.lyft.com/announcing-envoy-c-l7-proxy-and-communication-bus-92520b6c8191) 。 ## Istio 的好处{#benefits-of-Istio} @@ -52,11 +52,11 @@ Google、IBM 和 Lyft 为了共同的愿景，基于为内部和企业客户构 ## 加入我们{#join-us-in-this-journey} -Istio 是一个完全开放的开发项目。今天我们发布了能工作于 Kubernetes 集群的 0.1 版本，我们计划每三个月发布一个大版本，包括支持更多的环境。我们的目标是赋能开发者和运维人员，使他们在所有环境中都能敏捷的发布和维护微服务，拥有底层网络的完全的可见性，且获得一致的控制和安全能力。我们期待与 Istio 社区和我们的合作伙伴一起沿着 [路线图](/zh/about/feature-stages/) 朝着这些目标前进。 +Istio 是一个完全开放的开发项目。今天我们发布了能工作于 Kubernetes 集群的 0.1 版本，我们计划每三个月发布一个大版本，包括支持更多的环境。我们的目标是赋能开发者和运维人员，使他们在所有环境中都能敏捷的发布和维护微服务，拥有底层网络的完全的可见性，且获得一致的控制和安全能力。我们期待与 Istio 社区和我们的合作伙伴一起沿着[路线图](/zh/about/feature-stages/)朝着这些目标前进。 -访问 [此处](https://github.com/istio/istio/releases) 获取最新发布的代码。 +访问[此处](https://github.com/istio/istio/releases)获取最新发布的代码。 -查看在 GlueCon 2017 公布 Istio 时的 [介绍](/talks/istio_talk_gluecon_2017.pdf)。 +查看在 GlueCon 2017 公布 Istio 时的[介绍](/talks/istio_talk_gluecon_2017.pdf)。 ## 社区{#community} diff --git a/content/zh/news/releases/0.x/announcing-0.2/index.md b/content/zh/news/releases/0.x/announcing-0.2/index.md index f5e437453f..c783e693ec 100644 --- a/content/zh/news/releases/0.x/announcing-0.2/index.md +++ b/content/zh/news/releases/0.x/announcing-0.2/index.md @@ -14,11 +14,11 @@ aliases: - /zh/news/announcing-0.2 --- -我在2017年5月24日发布了 Istio ，它是一个用于连接、管理、监控和保护微服务的开放平台。看着饱含浓厚兴趣的开发者、运营商、合作伙伴和不断发展的社区，我们感到十分的欣慰。我们 0.1 版本的重点是展示 Istio 在 Kubernetes 中的所有概念。 +我在 2017 年 5 月 24 日发布了 Istio ，它是一个用于连接、管理、监控和保护微服务的开放平台。看着饱含浓厚兴趣的开发者、运营商、合作伙伴和不断发展的社区，我们感到十分的欣慰。我们 0.1 版本的重点是展示 Istio 在 Kubernetes 中的所有概念。 今天我们十分高兴地宣布推出 0.2 版本，它提高了稳定性和性能、允许在 Kubernetes 集群中广泛部署并自动注入 sidecar 、为 TCP 服务添加策略和身份验证、同时保证扩展网格收录那些部署在虚拟机中的服务。此外，Istio 可以利用 Consul/Nomad 或 Eureka 在 Kubernetes 外部运行。 除了核心功能，Istio 的扩展已经准备由第三方公司和开发人员编写。 -## 0.2版本的亮点{#highlights-for-the-0.2-release} +## 0.2 版本的亮点{#highlights-for-the-0.2-release} ### 可用性改进{#usability-improvements} @@ -28,7 +28,7 @@ aliases: - _自动注入 sidecar_: 通过利用 Kubernetes 1.7 提供的 alpha [初始化程序](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ，当您的集群启用了该程序时，envoy sidecar 就可以自动注入到应用的 deployment 里。 这使得你可以使用 `kubectl` 命令部署微服务， 这与您通常在没有 Istio 的情况下部署微服务的命令完全相同。 -- _扩展 Istio_ : 改进的 Mixer 设计，可以允许供应商编写 Mixer 适配器以实现对其自身系统的支持，例如应用管理或策略实施。该 [Mixer 适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide) 可以轻松的帮你将 Istio 集成于你的解决方案。 +- _扩展 Istio_ : 改进的 Mixer 设计，可以允许供应商编写 Mixer 适配器以实现对其自身系统的支持，例如应用管理或策略实施。该 [Mixer 适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide)可以轻松的帮你将 Istio 集成于你的解决方案。 - _使用您自己的 CA 证书_: 允许用户提供自己的密钥和证书给 Istio CA 和永久 CA 密钥/证书存储，允许在持久化存储中提供签名密钥/证书，以便于 CA 重启。 @@ -36,7 +36,7 @@ aliases: ### 跨环境支持{#cross-environment-support} -- _网格扩展_: Istio 网格现在可以在 Kubernetes 之外跨服务 —— 就像那些运行在虚拟机中的服务一样，他们同时享受诸如自动双向 TLS认证、流量管理、遥测和跨网格策略实施带来的好处。 +- _网格扩展_: Istio 网格现在可以在 Kubernetes 之外跨服务 —— 就像那些运行在虚拟机中的服务一样，他们同时享受诸如自动双向 TLS 认证、流量管理、遥测和跨网格策略实施带来的好处。 - _运行在 Kubernetes 外部_: 我们知道许多客户使用其他的服务注册中心和 orchestration 解决方案（如 Consul/Nomad 和 Eureka）， Istio Pilot 可以在 Kubernetes 外部单独运行，同时从这些系统中获取信息，并在虚拟机或容器中管理 Envoy fleet 。 @@ -46,7 +46,7 @@ aliases: 想要了解如何参与并为 Istio 的未来做出贡献，请查看我们在 GitHub 的[社区](https://github.com/istio/community)项目，它将会向您介绍我们的工作组，邮件列表，各种社区会议，常规流程和指南。 -我们要感谢为我们测试新版本、提交错误报告、贡献代码、帮助其他成员以及通过参与无数次富有成效的讨论塑造 Istio 的出色社区，这让我们的项目自启动以来在GitHub上累积了3000颗星，并且在 Istio 邮件列表上有着数百名活跃的社区成员。 +我们要感谢为我们测试新版本、提交错误报告、贡献代码、帮助其他成员以及通过参与无数次富有成效的讨论塑造 Istio 的出色社区，这让我们的项目自启动以来在 GitHub 上累积了 3000 颗星，并且在 Istio 邮件列表上有着数百名活跃的社区成员。 谢谢 @@ -63,9 +63,9 @@ Istio 可以管理其他非系统名称空间中的服务。 - **Mesh 扩展**。 初步支持将非 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边车自动注入到Pod中。 +- **自动注入 Sidecar**。 使用 Kubernetes 中的 [Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署后将 Istio 边车自动注入到 Pod 中。 ### 性能及品质{#performance-and-quality} @@ -101,7 +101,7 @@ Istio 可以管理其他非系统名称空间中的服务。 - **新的 Mixer API**。Envoy 用于与 Mixer 进行交互的 API 已进行了完全重新设计，以提高健壮性，灵活性，并支持丰富的代理端缓存和批处理以提高性能。 - **新的 Mixer Adapter 模型**。新的适配器组合模型通过模板添加全新的适配器类，使扩展 Mixer 更容易。这种新模型将作为将来许多功能的基础构建块。 -请参阅 [适配器开发者指南](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide) 以了解如何编写适配器。 +请参阅[适配器开发者指南](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide)以了解如何编写适配器。 - **改进 Mixer 构建模型**。现在，构建包含自定义适配器的 Mixer 二进制文件变得更加容易。 @@ -117,15 +117,15 @@ Istio 可以管理其他非系统名称空间中的服务。 - **VM 和物理机的身份配置**。Auth 支持使用每节点代理进行身份配置的新机制。 该代理在每个节点（VM /物理机）上运行，并负责生成和发送 CSR（证书签名请求）以从 Istio CA 获取证书。 -- **使用自己的CA证书**。允许用户向 Istio CA 提供自己的密钥和证书。 +- **使用自己的 CA 证书**。允许用户向 Istio CA 提供自己的密钥和证书。 - **永久性 CA 密钥/证书存储**。Istio CA 现在将签名密钥/证书持久化存储，以方便 CA 重新启动。 ## 已知问题{#known-issues} -- **用户访问应用程序时可能会收到 404**：我们注意到，Envoy有时无法正确获取路由，因此将 404 返回给用户。 -我们正在对此 [问题](https://github.com/istio/istio/issues/1038) 进行积极的工作。 +- **用户访问应用程序时可能会收到 404**：我们注意到，Envoy 有时无法正确获取路由，因此将 404 返回给用户。 +我们正在对此[问题](https://github.com/istio/istio/issues/1038)进行积极的工作。 -- **在真正准备就绪之前，Istio Ingress 或 Egress 就报告了准备就绪**：您可以在 `istio-system` 名称空间中检查 `istio-ingress` 和 `istio-egress` pod 的状态，并在所有 Istio pod 报告就绪状态后等待几秒钟。我们正在对此 [问题](https://github.com/istio/istio/pull/1055) 进行积极的工作。 +- **在真正准备就绪之前，Istio Ingress 或 Egress 就报告了准备就绪**：您可以在 `istio-system` 名称空间中检查 `istio-ingress` 和 `istio-egress` pod 的状态，并在所有 Istio pod 报告就绪状态后等待几秒钟。我们正在对此[问题](https://github.com/istio/istio/pull/1055)进行积极的工作。 - **启用了 Istio Auth 的服务无法与一个非 Istio 服务通信**：此限制将在不久的将来消除。 diff --git a/content/zh/news/releases/0.x/announcing-0.4/index.md b/content/zh/news/releases/0.x/announcing-0.4/index.md index b3caf11c89..15681310ad 100644 --- a/content/zh/news/releases/0.x/announcing-0.4/index.md +++ b/content/zh/news/releases/0.x/announcing-0.4/index.md @@ -29,4 +29,4 @@ aliases: - **增强的属性表达式**。Mixer 的表达语言获得了一些新功能，使编写策略规则变得更加容易。[学到更多](/zh/docs/reference/config/policy-and-telemetry/expression-language/) -如果您想了解细节，可以在 [此处](https://github.com/istio/istio/wiki/v0.4.0) 查看我们更详细的低级发行说明。 +如果您想了解细节，可以在[此处](https://github.com/istio/istio/wiki/v0.4.0)查看我们更详细的低级发行说明。 diff --git a/content/zh/news/releases/0.x/announcing-0.5/index.md b/content/zh/news/releases/0.x/announcing-0.5/index.md index 02e82e198b..954d33b442 100644 --- a/content/zh/news/releases/0.x/announcing-0.5/index.md +++ b/content/zh/news/releases/0.x/announcing-0.5/index.md @@ -20,7 +20,7 @@ aliases: - **渐进式部署 Istio**。（预览）现在，通过仅安装所需的组件（例如，仅 Pilot + Ingress 作为最小化的 Istio 安装），您可以比以前更轻松地逐步采用 Istio。请参考 `istioctl` CLI 工具，以生成有关自定义 Istio 部署的信息。 -- **自动注入 Proxy**。我们利用 Kubernetes 1.9 的新 [muting webhook 特性](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.9.md#api-machinery) 提供 Pod 级的自动注入。自动注入需要 Kubernetes 1.9 或更高版本，因此不适用于旧版本。不再支持 alpha 初始化机制。[了解更多](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection) +- **自动注入 Proxy**。我们利用 Kubernetes 1.9 的新 [muting webhook 特性](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.9.md#api-machinery)提供 Pod 级的自动注入。自动注入需要 Kubernetes 1.9 或更高版本，因此不适用于旧版本。不再支持 alpha 初始化机制。[了解更多](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection) - **改进流量规则**。根据用户反馈，我们对 Istio 的流量管理（路由规则，目标规则等）进行了重大更改。在接下来的几周中，我们会不断完善您的反馈，希望我们能继续为您提供帮助。 diff --git a/content/zh/news/releases/1.0.x/announcing-1.0.1/index.md b/content/zh/news/releases/1.0.x/announcing-1.0.1/index.md index 8385acdf9c..c0ff975062 100644 --- a/content/zh/news/releases/1.0.x/announcing-1.0.1/index.md +++ b/content/zh/news/releases/1.0.x/announcing-1.0.1/index.md @@ -22,9 +22,9 @@ aliases: - 修复了添加端口时，虚拟服务 host 不匹配的 bug。 -- 增加了对[合并同一主机的多个虚拟服务或目标规则定义](/zh/docs/ops/best-practices/traffic-management/#split-virtual-services) 的有限支持。 +- 增加了对[合并同一主机的多个虚拟服务或目标规则定义](/zh/docs/ops/best-practices/traffic-management/#split-virtual-services)的有限支持。 -- 使用HTTP时，允许连续的[异常](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/cluster/outlier_detection.proto)网关故障。 +- 使用 HTTP 时，允许连续的[异常](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/cluster/outlier_detection.proto)网关故障。 ## 环境{#environment} diff --git a/content/zh/news/releases/1.0.x/announcing-1.0.3/index.md b/content/zh/news/releases/1.0.x/announcing-1.0.3/index.md index 537106018e..12dd5f5510 100644 --- a/content/zh/news/releases/1.0.x/announcing-1.0.3/index.md +++ b/content/zh/news/releases/1.0.x/announcing-1.0.3/index.md @@ -18,7 +18,7 @@ aliases: ## 行为变更{#behavior-changes} -- 现在强制使用 [验证 webhook](/zh/docs/ops/common-problems/validation)。禁用它可能导致 Pilot 崩溃。 +- 现在强制使用[验证 webhook](/zh/docs/ops/common-problems/validation)。禁用它可能导致 Pilot 崩溃。 - 现在，[Service entry](/zh/docs/reference/config/networking/service-entry/) 验证会在配置为 DNS 解析时拒绝通配主机名（`*`）。API 从未允许这样做，只是在以前的版本中，`ServiceEntry` 被错误地排除在验证之外。把通配符作为主机名的一部分，例如 `*.bar.com`，将保持不变。 @@ -30,7 +30,7 @@ aliases: - Pilot 性能和可扩展性已大大增强。Pilot 现在可以在不到 1 秒的时间内向 500 个 sidecar 提供 endpoint 更新。 -- [追踪采样](/zh/docs/tasks/observability/distributed-tracing/overview/#trace-sampling) 默认设置为 1%。 +- [追踪采样](/zh/docs/tasks/observability/distributed-tracing/overview/#trace-sampling)默认设置为 1%。 ## 策略和遥测{#policy-and-telemetry} diff --git a/content/zh/news/releases/1.0.x/announcing-1.0/index.md b/content/zh/news/releases/1.0.x/announcing-1.0/index.md index f484686811..40d0875f9b 100644 --- a/content/zh/news/releases/1.0.x/announcing-1.0/index.md +++ b/content/zh/news/releases/1.0.x/announcing-1.0/index.md @@ -32,17 +32,17 @@ aliases: 自 0.8 版以来，我们添加了一些重要的新功能，更重要的是将许多现有功能标记为 Beta，表明它们已可以投入生产。以下是一些要点： -- 现在可以将多个 Kubernetes 集群 [添加到单个网格](/zh/docs/setup/install/multicluster/) 中，并实现跨集群通信和一致的策略实施。多群集支持现在为 Beta。 +- 现在可以将多个 Kubernetes 集群[添加到单个网格](/zh/docs/setup/install/multicluster/)中，并实现跨集群通信和一致的策略实施。多群集支持现在为 Beta。 -- 现在，可以对通过网状网络的流量进行细粒度控制的网络 API 已成为 Beta。使用网关对进入和退出问题进行显式建模，使运维人员可以 [控制网络拓扑](/zh/blog/2018/v1alpha3-routing/) 并满足边缘的访问安全性要求。 +- 现在，可以对通过网状网络的流量进行细粒度控制的网络 API 已成为 Beta。使用网关对进入和退出问题进行显式建模，使运维人员可以[控制网络拓扑](/zh/blog/2018/v1alpha3-routing/)并满足边缘的访问安全性要求。 -- 双向 TLS 现在 [以增量方式推出]，无需更新服务的所有客户端。这是一项关键功能，现有生产部署可以无障碍的就地采用。 +- 双向 TLS 现在[以增量方式推出]，无需更新服务的所有客户端。这是一项关键功能，现有生产部署可以无障碍的就地采用。 -- Mixer 开始支持 [开发进程外适配器](https://github.com/istio/istio/wiki/Out-Of-Process-gRPC-Adapter-Dev-Guide)。这将成为在未来发行版中扩展 Mixer 的默认方法，并使构建适配器更加简单。 +- Mixer 开始支持[开发进程外适配器](https://github.com/istio/istio/wiki/Out-Of-Process-gRPC-Adapter-Dev-Guide)。这将成为在未来发行版中扩展 Mixer 的默认方法，并使构建适配器更加简单。 -- 现在，由 Envoy 完全控制本地控制访问服务的 [授权策略](/zh/docs/concepts/security/#authorization)，以提高其性能和可靠性。 +- 现在，由 Envoy 完全控制本地控制访问服务的[授权策略](/zh/docs/concepts/security/#authorization)，以提高其性能和可靠性。 -- 现在建议使用 [Helm chart 安装](/zh/docs/setup/install/helm/) 方法，该方法提供了丰富的自定义选项，可以按您的意愿采用 Istio。 +- 现在建议使用 [Helm chart 安装](/zh/docs/setup/install/helm/)方法，该方法提供了丰富的自定义选项，可以按您的意愿采用 Istio。 - 我们已经在性能上做出了很多努力，包括连续回归测试，大规模环境模拟和目标修复。我们对结果感到非常满意，并将在未来几周内详细分享更多信息。 @@ -53,8 +53,8 @@ aliases: ## 开始之前{#getting-started} 如果您是 Istio 的新手，并希望将其用于您的部署，我们很乐意听取您的意见。 -可以看看 [我们的文档](/zh/docs/) 或者移步我们的 [聊天室](https://discuss.istio.io)。 -如果您想更深入地 [为项目做贡献](/zh/about/community)，请参加一个我们的社区会议，并打个招呼。 +可以看看[我们的文档](/zh/docs/)或者移步我们的[聊天室](https://discuss.istio.io)。 +如果您想更深入地[为项目做贡献](/zh/about/community)，请参加一个我们的社区会议，并打个招呼。 ## 感谢{#thanks} @@ -74,13 +74,13 @@ Istio 团队非常感谢为该项目做出贡献的每个人。没有您的帮 ### 策略和遥测{#policy-and-telemetry} -- **更新的属性**。用于描述流量来源和目的地的一组 [属性](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/) 已被彻底修改，变得更加精确和全面。 +- **更新的属性**。用于描述流量来源和目的地的一组[属性](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)已被彻底修改，变得更加精确和全面。 -- **策略检查缓存**。Mixer 现在具有了用于策略检查的大型 2 级缓存，补充了 sidecar 代理中存在的1级缓存。这进一步减少了外部强制策略检查的平均延迟。 +- **策略检查缓存**。Mixer 现在具有了用于策略检查的大型 2 级缓存，补充了 sidecar 代理中存在的 1 级缓存。这进一步减少了外部强制策略检查的平均延迟。 - **遥测缓冲**。Mixer 现在可以在将调用报告分配给适配器之前先缓冲调用报告，这为适配器提供了机会以更大的块处理遥测数据，从而减少了 Mixer 及其适配器的总体计算开销。 -- **进程外适配器**。Mixer 现在包括对进程外适配器的初始支持。这将是与 Mixer 集成的推荐方法。[进程外适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide) 和[进程外适配器遍历](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Walkthrough) 提供了有关如何构建进程外适配器的初始文档。 +- **进程外适配器**。Mixer 现在包括对进程外适配器的初始支持。这将是与 Mixer 集成的推荐方法。[进程外适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide)和[进程外适配器遍历](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Walkthrough)提供了有关如何构建进程外适配器的初始文档。 - **客户端遥测**。现在，除了服务器端遥测之外，还可以从交互的客户端收集遥测。 @@ -92,11 +92,11 @@ Istio 团队非常感谢为该项目做出贡献的每个人。没有您的帮 ### 安全{#security} -- **授权**。我们已经重新实现了 [授权功能] 的 RPC 级授权策略，此功能现在的实现，不再需要使用 Mixer 和 Mixer 适配器。 +- **授权**。我们已经重新实现了[授权功能] 的 RPC 级授权策略，此功能现在的实现，不再需要使用 Mixer 和 Mixer 适配器。 -- **改进双向 TLS 身份认证控制**。现在，可以更轻松地控制服务之间的 [双向 TLS 身份认证](/zh/docs/concepts/security/#authentication)。我们提供 `PERMISSIVE` 模式，以便您可以为您的服务 [递增地启用双向TLS](/zh/docs/tasks/security/authentication/mtls-migration/)。我们移除了服务注释，采用 [独特的方法来启用双向 TLS](/zh/docs/tasks/security/authentication/authn-policy/)，并结合了客户端 [目标规则](/zh/docs/concepts/traffic-management/#destination-rules)。 +- **改进双向 TLS 身份认证控制**。现在，可以更轻松地控制服务之间的[双向 TLS 身份认证](/zh/docs/concepts/security/#authentication)。我们提供 `PERMISSIVE` 模式，以便您可以为您的服务[递增地启用双向 TLS](/zh/docs/tasks/security/authentication/mtls-migration/)。我们移除了服务注释，采用[独特的方法来启用双向 TLS](/zh/docs/tasks/security/authentication/authn-policy/)，并结合了客户端[目标规则](/zh/docs/concepts/traffic-management/#destination-rules)。 -- **JWT 授权**。现在支持 [JWT 身份验证](/zh/docs/concepts/security/#authentication)，可以使用 [身份验证策略](/zh/docs/concepts/security/#authentication-policies) 对其进行配置。 +- **JWT 授权**。现在支持 [JWT 身份验证](/zh/docs/concepts/security/#authentication)，可以使用[身份验证策略](/zh/docs/concepts/security/#authentication-policies)对其进行配置。 ### `istioctl` @@ -118,10 +118,10 @@ Istio 团队非常感谢为该项目做出贡献的每个人。没有您的帮 ### 1.0 已知问题{#known-issues-with-1-0} -- Amazon EKS 服务未实现 sidecar 自动注入。在 Amazon EKS 中使用 Istio 需要为 sidecar 使用 [手动注入](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection) 并通过 [Helm 参数](/zh/docs/setup/install/helm) `--set galley.enabled=false` 关闭 galley。 +- Amazon EKS 服务未实现 sidecar 自动注入。在 Amazon EKS 中使用 Istio 需要为 sidecar 使用[手动注入](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection)并通过 [Helm 参数](/zh/docs/setup/install/helm) `--set galley.enabled=false` 关闭 galley。 -- 在[多集群部署](/zh/docs/setup/install/multicluster) 中，mixer-telemetry 和 mixer-policy 组件不会连接到任何远程集群的 Kubernetes API 端点。由于与远程集群上的工作负载相关的某些元数据不完整，这会导致遥测保真度的损失。 +- 在[多集群部署](/zh/docs/setup/install/multicluster)中，mixer-telemetry 和 mixer-policy 组件不会连接到任何远程集群的 Kubernetes API 端点。由于与远程集群上的工作负载相关的某些元数据不完整，这会导致遥测保真度的损失。 - 有的 Kubernetes 清单，可用于独立使用 Citadel 或启用 Citadel 运行状况检查。Helm 没有实现这些模式。有关更多详细信息，请参见 [Issue 6922](https://github.com/istio/istio/issues/6922)。 -- 网格扩展功能，使您可以将原始 VM 添加到网格，此功能在 1.0 中已被破坏。我们预计将在几天内产生可解决此问题的补丁。 \ No newline at end of file +- 网格扩展功能，使您可以将原始 VM 添加到网格，此功能在 1.0 中已被破坏。我们预计将在几天内产生可解决此问题的补丁。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md index 1181475123..a10ba9e3ae 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md @@ -16,7 +16,7 @@ aliases: ## 安全更新{#security-update} -此版本包含了我们在[2019年10月8日](/zh/news/security/istio-security-2019-005)的新闻中所阐述的修复程序的安全漏洞。特别是： +此版本包含了我们在 [2019 年 10 月 8 日](/zh/news/security/istio-security-2019-005)的新闻中所阐述的修复程序的安全漏洞。特别是： __ISTIO-SECURITY-2019-005__: `Envoy` 社区发现了一个 `DoS` 漏洞。 * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: 经过调查，`Istio` 团队发现，如果攻击者使用大量非常小的 `header`，则可以利用此问题进行对 `Istio` 的 `DoS` 攻击。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.17/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.17/index.md index 961a0b0413..10f1855010 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.17/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.17/index.md @@ -16,4 +16,4 @@ aliases: ## Bug 修复{#bug-fixes} -- 修复了一个由 [10 月 8 日安全补丁](/zh/news/security/istio-security-2019-005)引入的bug，它错误地计算 HTTP 头和请求体大小（[Issue 17735](https://github.com/istio/istio/issues/17735)）。 +- 修复了一个由 [10 月 8 日安全补丁](/zh/news/security/istio-security-2019-005)引入的 bug，它错误地计算 HTTP 头和请求体大小（[Issue 17735](https://github.com/istio/istio/issues/17735)）。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md index 3616af2ed9..3a35563fa5 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md @@ -43,7 +43,7 @@ aliases: - 添加了缺少的验证，以防止网关名称包含点（.） ([Issue 13211](https://github.com/istio/istio/issues/13211))。 - 修复了 [`ConsistentHashLB.minimumRingSize`](/zh/docs/reference/config/networking/destination-rule#LoadBalancerSettings-ConsistentHashLB) -默认为0而不是记录的1024 ([Issue 13261](https://github.com/istio/istio/issues/13261))。 +默认为 0 而不是记录的 1024 ([Issue 13261](https://github.com/istio/istio/issues/13261))。 ## 小改进 {#small-enhancements} diff --git a/content/zh/news/releases/1.1.x/announcing-1.1/_index.md b/content/zh/news/releases/1.1.x/announcing-1.1/_index.md index d5122598d6..a1408e098c 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1/_index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1/_index.md @@ -21,9 +21,9 @@ aliases: 1.1 的主题是企业就绪。我们很高兴看到越来越多的公司在生产中使用 Istio，但是一些大型公司在尝试使用 Istio 的过程中，遇到了一些瓶颈。 -我们关注的主要领域之一是 [性能和可伸缩性](/zh/docs/ops/deployment/performance-and-scalability/)。随着人们进入生产环境，大型集群以更高的容量运行更多的服务，他们遇到了一些扩展和性能问题。[sidecar](/zh/docs/concepts/traffic-management/#sidecars) 占用了太多资源，并增加了太多延迟。控制平面（尤其是 [Pilot](/zh/docs/ops/deployment/architecture/#pilot)）过于浪费资源。 +我们关注的主要领域之一是[性能和可伸缩性](/zh/docs/ops/deployment/performance-and-scalability/)。随着人们进入生产环境，大型集群以更高的容量运行更多的服务，他们遇到了一些扩展和性能问题。[sidecar](/zh/docs/concepts/traffic-management/#sidecars) 占用了太多资源，并增加了太多延迟。控制平面（尤其是 [Pilot](/zh/docs/ops/deployment/architecture/#pilot)）过于浪费资源。 -我们已经做了很多工作，以提高数据平面和控制平面的使用效率。您可以在本次更新的 [性能和可扩展性概念](/zh/docs/ops/deployment/performance-and-scalability/) 中找到我们对 1.1 性能测试的详细信息和测试结果。 +我们已经做了很多工作，以提高数据平面和控制平面的使用效率。您可以在本次更新的[性能和可扩展性概念](/zh/docs/ops/deployment/performance-and-scalability/)中找到我们对 1.1 性能测试的详细信息和测试结果。 我们还完成了有关命名空间隔离的工作。这使您可以使用 Kubernetes 命名空间来强制控制边界，并确保您的团队和另一个团队之间不会相互干扰。 @@ -35,4 +35,4 @@ aliases: 我们感谢在过去几个月中为了 Istio 的发展而努力工作的每个人。他们修补了 1.0 版本，并为 1.1 版本增加了许多新功能，最近又对 1.1 版本进行了大量的测试。特别感谢在早期版本，与我们一起完成安装和升级方面的工作，并帮助我们在发布之前发现问题的那些公司和用户。 -现在：时机已到！就是 1.1，查看[更新文档](/zh/docs/)、[安装它](/zh/docs/setup/)，然后...happy meshing! \ No newline at end of file +现在：时机已到！就是 1.1，查看[更新文档](/zh/docs/)、[安装它](/zh/docs/setup/)，然后...happy meshing! 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 9ae4bb880b..c1454cbfd5 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 @@ -48,13 +48,13 @@ aliases: ### 安全{#security} -- **就绪和存活探针**。添加了对 Kubernetes HTTP [就绪和存活探针](/zh/faq/security/#k8s-health-checks) 的支持（启用双向 TLS 时）。 +- **就绪和存活探针**。添加了对 Kubernetes HTTP [就绪和存活探针](/zh/faq/security/#k8s-health-checks)的支持（启用双向 TLS 时）。 - **群集 RBAC 配置**。用 `ClusterRbacConfig` 资源替换了 `RbacConfig` 资源，以实现正确的集群范围。关于迁移说明，请参见[将 `RbacConfig` 迁移到 `ClusterRbacConfig`](https://archive.istio.io/v1.1/docs/setup/kubernetes/upgrade/steps/#migrating-from-rbacconfig-to-clusterrbacconfig)。 - **通过 SDS 进行身份认证**。添加了 SDS 支持，通过节点密钥生成以及动态证书轮换，来提供更强的安全性，并且无需重启 Envoy。有关更多信息，请参见[通过 SDS 进行身份认证](/zh/docs/tasks/security/citadel-config/auth-sds)。 -- **TCP 服务授权**。除了 HTTP 和 gRPC 服务之外，还增加了对 TCP 服务的授权支持。有关更多信息，请参见[TCP服务授权](/zh/docs/tasks/security/authorization/authz-tcp)。 +- **TCP 服务授权**。除了 HTTP 和 gRPC 服务之外，还增加了对 TCP 服务的授权支持。有关更多信息，请参见 [TCP 服务授权](/zh/docs/tasks/security/authorization/authz-tcp)。 - **终端用户组的授权**。添加了基于 `组` 声明或 JWT 中任何列表类型声明的授权。有关更多信息，请参见[组和列表声明的授权](/zh/docs/tasks/security/authorization/rbac-groups/)。 @@ -68,7 +68,7 @@ aliases: - **默认关闭策略检查**。默认情况下，修改后的策略检查是关闭的，以提高大多数客户方案的性能。[启用策略执行](/zh/docs/tasks/policy-enforcement/enabling-policy/)详细说明了如何根据需要开启 Istio 策略检查。 -- **Kiali**。用 [Kiali](https://www.kiali.io) 替换了 [Service Graph addon](https://github.com/istio/istio/issues/9066)，以提供更丰富的可视化体验。有关更多详细信息，请参见[Kiali 任务](/zh/docs/tasks/observability/kiali/)。 +- **Kiali**。用 [Kiali](https://www.kiali.io) 替换了 [Service Graph addon](https://github.com/istio/istio/issues/9066)，以提供更丰富的可视化体验。有关更多详细信息，请参见 [Kiali 任务](/zh/docs/tasks/observability/kiali/)。 - **减少开销**。添加了一些性能和规模改进，包括： @@ -102,7 +102,7 @@ aliases: ### 配置管理{#configuration-management} -- **Galley**。添加 [Galley](/zh/docs/ops/deployment/architecture/#galley) 作为 Istio 主要的配置收集和分发装置。它提供了一个健壮的模型来验证，转换配置状态并将其分配给 Istio 组件，从而将 Istio 组件与 Kubernetes 详细信息隔离开来。Galley 使用[网格配置协议](https://github.com/istio/api/tree/{{< source_branch_name >}}/mcp)与组件进行交互。 +- **Galley**。添加 [Galley](/zh/docs/ops/deployment/architecture/#galley) 作为 Istio 主要的配置收集和分发装置。它提供了一个健壮的模型来验证，转换配置状态并将其分配给 Istio 组件，从而将 Istio 组件与 Kubernetes 详细信息隔离开来。Galley 使用[网格配置协议](https://github.com/istio/api/tree/{{}}/mcp) 与组件进行交互。 - **监听端口**。将 Galley 的默认监听端口从 9093 修改为 15014。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1/helm-changes/index.md b/content/zh/news/releases/1.1.x/announcing-1.1/helm-changes/index.md index 5e00342bbf..7fd7869539 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1/helm-changes/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1/helm-changes/index.md @@ -39,7 +39,7 @@ keywords: [kubernetes, helm, install, options] | `global.proxy.accessLogFile` | `"/dev/stdout"` | `""` | | | | `global.proxy.enableCoreDump` | `false` | `false` | | `如果设置，新注入的 sidecars 将启用 core dumps。` | | `global.proxy.autoInject` | `enabled` | `enabled` | | `可以控制 sidecar 的注入策略。` | -| `global.proxy.envoyStatsd.enabled` | `true` | `false` | | `如果设置为 true，则还须提供主机地址和端口。Istio不再提供 statsd 收集器。` | +| `global.proxy.envoyStatsd.enabled` | `true` | `false` | | `如果设置为 true，则还须提供主机地址和端口。Istio 不再提供 statsd 收集器。` | | `global.proxy.envoyStatsd.host` | `istio-statsd-prom-bridge` | `` | | `例如: statsd-svc.istio-system` | | `global.proxy.envoyStatsd.port` | `9125` | `` | | `例如: 9125` | | `global.proxy_init.image` | `proxy_init` | `proxy_init` | | `proxy_init 容器的基本名称，用于配置 iptables。` | diff --git a/content/zh/news/releases/1.1.x/announcing-1.1/upgrade-notes/index.md b/content/zh/news/releases/1.1.x/announcing-1.1/upgrade-notes/index.md index 2fcd885aaf..6886871454 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1/upgrade-notes/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1/upgrade-notes/index.md @@ -17,7 +17,7 @@ weight: 20 - 许多安装选项已被添加、删除或者更改。请参阅[安装选项更改](/zh/news/releases/1.1.x/announcing-1.1/helm-changes/)来获得详细的更改概要。 -- 用于[多集群 VPN](/zh/docs/setup/install/multicluster/shared-vpn/)的 1.0 `istio-remote` 图表和[多集群共享网关](/zh/docs/setup/install/multicluster/shared-gateways/)的远程集群安装已经被合并到 Istio 图表中。为了生成等价的 `istio-remote` 图表，请使用 `--set global.istioRemote=true` 标志。 +- 用于[多集群 VPN](/zh/docs/setup/install/multicluster/shared-vpn/) 的 1.0 `istio-remote` 图表和[多集群共享网关](/zh/docs/setup/install/multicluster/shared-gateways/)的远程集群安装已经被合并到 Istio 图表中。为了生成等价的 `istio-remote` 图表，请使用 `--set global.istioRemote=true` 标志。 - 插件不再通过单独的负载均衡器暴露。现在可以通过选择 Ingress 网关暴露插件。当通过 Ingress 网关暴露插件时，请遵循[远程访问遥测插件](/zh/docs/tasks/observability/gateways/)指南进行操作。 @@ -45,4 +45,4 @@ weight: 20 ## 安全{#security} -- RBAC 配置已被修改来实现集群作用域。`RbacConfig` 资源已经被替换成 `ClusterRbacConfig` 资源。请参阅[将 `RbacConfig` 迁移到 `ClusterRbacConfig`](https://archive.istio.io/v1.1/docs/setup/kubernetes/upgrade/steps/#migrating-from-rbacconfig-to-clusterrbacconfig)的文档获得更多的迁移说明。 +- RBAC 配置已被修改来实现集群作用域。`RbacConfig` 资源已经被替换成 `ClusterRbacConfig` 资源。请参阅[将 `RbacConfig` 迁移到 `ClusterRbacConfig`](https://archive.istio.io/v1.1/docs/setup/kubernetes/upgrade/steps/#migrating-from-rbacconfig-to-clusterrbacconfig) 的文档获得更多的迁移说明。 diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md index ed0a8e27b1..fd3314ceaa 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md @@ -9,7 +9,7 @@ aliases: - /zh/news/announcing-1.2.10 --- -此版本包含了 [我们在 2019 年 12 月 10 日新闻](/zh/news/security/istio-security-2019-007) 中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.2.9 和 Istio 1.2.10 之间的区别。 +此版本包含了[我们在 2019 年 12 月 10 日新闻](/zh/news/security/istio-security-2019-007)中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.2.9 和 Istio 1.2.10 之间的区别。 {{< relnote >}} diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.3/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.3/index.md index 4f75fb2853..ab25f6467f 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.3/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.3/index.md @@ -24,7 +24,7 @@ aliases: - 修复虚拟服务基于正则表达式匹配 HTTP URI 区分大小写的问题（[Issue 14983](https://github.com/istio/istio/issues/14983)） - 修复 demo 配置文件的 HPA 和 CPU 设置（[Issue 15338](https://github.com/istio/istio/issues/15338)） - 放宽 Keep-Alive 实施策略，避免在轻负载下断开连接（[Issue 15088](https://github.com/istio/istio/issues/15088)） -- 当未使用 SDS 时，跳过Kubernetes JWT身份验证，以降低使用受损（不可信）JWT 的风险。 +- 当未使用 SDS 时，跳过 Kubernetes JWT 身份验证，以降低使用受损（不可信）JWT 的风险。 ## 测试升级{#tests-upgrade} diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md index 580ce0b841..9ab6bc20b3 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md @@ -16,7 +16,7 @@ aliases: ## 安全更新{#security-update} -此版本包含我们在[2019年10月8日](/zh/news/security/istio-security-2019-005)的新闻中所阐述的安全漏洞程序的修复。特别是： +此版本包含我们在 [2019 年 10 月 8 日](/zh/news/security/istio-security-2019-005)的新闻中所阐述的安全漏洞程序的修复。特别是： __ISTIO-SECURITY-2019-005__: `Envoy` 社区发现的一个 `DoS` 漏洞。 * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: 经过调查，`Istio` 团队发现，如果攻击者使用大量非常小的 `header`，则可以利用此问题在 `Istio` 中进行 `DoS` 攻击。 diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.8/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.8/index.md index 9bbc3578e4..f7d1e1f5e8 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.8/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.8/index.md @@ -16,7 +16,7 @@ aliases: ## Bug 修复{#bug-fixes} -- 修复了我们在[10 月 8 日发布的安全性错误](/zh/news/security/istio-security-2019-005)，错误地计算了 `HTTP header` 和 `body sizes` ([Issue 17735](https://github.com/istio/istio/issues/17735))。 +- 修复了我们在 [10 月 8 日发布的安全性错误](/zh/news/security/istio-security-2019-005)，错误地计算了 `HTTP header` 和 `body sizes` ([Issue 17735](https://github.com/istio/istio/issues/17735))。 - 修复了一个较小的错误，将部署减小到 0 个副本时，`endpoint` 仍保留在 `/clusters` 中 ([Issue 14336](https://github.com/istio/istio/issues/14336))。 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 50f5873abc..67c75501a9 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 @@ -22,7 +22,7 @@ aliases: ## 安全 {#security} -- **改进** 将自签名 Citadel 根证书的默认生存期延长到10年。 +- **改进** 将自签名 Citadel 根证书的默认生存期延长到 10 年。 - **增加** 通过[标注](/zh/docs/ops/configuration/mesh/app-health-check/#use-annotations-on-pod) `PodSpec` 中`sidecar.istio.io/rewriteAppHTTPProbers: "true"` 字段，Kubernetes 的健康检查探测器会重写每个 deployment。 - **增加** 支持给 Istio 双向 TLS 证书配置密钥路径。 更多信息请看[这里](https://github.com/istio/istio/issues/11984)。 - **增加** 通过启用 Citadel 上的 `pkcs8-keys` 来支持 workload 使用 [PKCS 8](https://en.wikipedia.org/wiki/PKCS_8) 私钥。 @@ -30,7 +30,7 @@ aliases: - **修复** workload 证书中的 [SAN](https://tools.ietf.org/html/rfc5280#section-4.2.1.6) 字段设置为 `critical`。这是修复了一些自定义证书验证服务无法验证 Istio 证书的问题。 - **修复** 重写了 HTTPS 的双向 TLS 探测。 - **毕业** [入口网关多证书支持的 SNI](/zh/docs/reference/config/networking/gateway/) 从 Alpha 版本发展到了稳定版。 -- **毕业** [入口网关证书管理](/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/) 从 Alpha 版本发展到了 Beta 版。 +- **毕业** [入口网关证书管理](/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/)从 Alpha 版本发展到了 Beta 版。 ## 遥测 {#telemetry} @@ -56,7 +56,7 @@ aliases: - **增加** `sidecarInjectorWebhook.neverInjectSelector` 和 `sidecarInjectorWebhook.alwaysInjectSelector` 配置，通过标签选择器让用户可以进一步控制 workload 是否应该自动注入 sidecar。 - **增加** `global.logging.level` 和 `global.proxy.logLevel` 配置，允许用户方便的给控制平面和数据平面组件全局的配置日志。 - **增加** 支持通过设置 [`global.tracer.datadog.address`](/zh/docs/reference/config/installation-options/#global-options) 来配置 Datadog 的地址。 -- **移除** 默认情况下禁止使用早期[被弃用]( https://discuss.istio.io/t/deprecation-notice-custom-mixer-adapter-crds/2055)的适配器和 CRD 模版。可以使用 `mixer.templates.useTemplateCRDs=true` 和 `mixer.adapters.useAdapterCRDs=true` 安装配置项来重新启用这两个功能。 +- **移除** 默认情况下禁止使用早期[被弃用](https://discuss.istio.io/t/deprecation-notice-custom-mixer-adapter-crds/2055) 的适配器和 CRD 模版。可以使用 `mixer.templates.useTemplateCRDs=true` 和 `mixer.adapters.useAdapterCRDs=true` 安装配置项来重新启用这两个功能。 要看全部的变动，请参阅[安装选项变动页面](/zh/news/releases/1.2.x/announcing-1.2/helm-changes/)。 @@ -72,10 +72,10 @@ aliases: ## 杂项 {#miscellaneous} -- **增加** [Istio CNI 支持](/zh/docs/setup/additional-setup/cni/) 以设置 sidecar 网络重定向，并移除需要 `NET_ADMIN` 功能的 `istio-init` 容器。 -- **增加** 新实验功能 ['a-la-carte' Istio 安装器](https://github.com/istio/installer/wiki) 可以让用户以所希望的独立和安全的方式安装和升级 Istio。 +- **增加** [Istio CNI 支持](/zh/docs/setup/additional-setup/cni/)以设置 sidecar 网络重定向，并移除需要 `NET_ADMIN` 功能的 `istio-init` 容器。 +- **增加** 新实验功能 ['a-la-carte' Istio 安装器](https://github.com/istio/installer/wiki)可以让用户以所希望的独立和安全的方式安装和升级 Istio。 - **增加** 除了命令行参数外，[支持以环境变量和配置文件](https://docs.google.com/document/d/1M-qqBMNbhbAxl3S_8qQfaeOLAiRqSBpSgfWebFBRuu8/edit)的方式来配置 Galley。 - **增加** [ControlZ](/zh/docs/ops/diagnostic-tools/controlz/) 支持在 Galley 中可视化 MCP 服务的状态。 -- **增加** 在 Galley 中通过 [`enableServiceDiscovery` 命令行参数](/zh/docs/reference/commands/galley/#galley-server) 来控制服务发现模块。 +- **增加** 在 Galley 中通过 [`enableServiceDiscovery` 命令行参数](/zh/docs/reference/commands/galley/#galley-server)来控制服务发现模块。 - **增加** Galley 和 Pilot 中的 `InitialWindowSize` 和 `InitialConnWindowSize` 参数允许微调 MCP (gRPC) 的链接设置。 - **毕业** Galley 的配置处理从 Alpha 版本发展到了 Beta 版。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3.2/index.md b/content/zh/news/releases/1.3.x/announcing-1.3.2/index.md index 267165a9dc..d53ace44bc 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3.2/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3.2/index.md @@ -21,4 +21,4 @@ aliases: __ISTIO-SECURITY-2019-005__: Envoy 社区发现了一个 DoS 漏洞。 * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: 经过调查，Istio 团队发现，如果攻击者使用大量非常小的标头，则可以利用此问题进行 Istio 的 DoS 攻击。 -除上述安全修复程序外，此版本中不包含其他任何内容。几天后将发布 Distroless 镜像。 \ No newline at end of file +除上述安全修复程序外，此版本中不包含其他任何内容。几天后将发布 Distroless 镜像。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md b/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md index 14f25ea178..71c699c1cf 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md @@ -9,7 +9,7 @@ aliases: - /zh/news/announcing-1.3.6 --- -此版本包含了 [我们在 2019 年 12 月 10 日新闻](/zh/news/security/istio-security-2019-007) 中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.3.5 和 Istio 1.3.6 之间的区别。 +此版本包含了[我们在 2019 年 12 月 10 日新闻](/zh/news/security/istio-security-2019-007)中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.3.5 和 Istio 1.3.6 之间的区别。 {{< relnote >}} diff --git a/content/zh/news/releases/1.3.x/announcing-1.3.8/index.md b/content/zh/news/releases/1.3.x/announcing-1.3.8/index.md index 6c6e408f1c..2feb4098d4 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3.8/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3.8/index.md @@ -9,7 +9,7 @@ aliases: - /zh/news/announcing-1.3.8 --- -此版本包含了 [我们在 2020 年 2 月 11 日的新闻](/zh/news/security/istio-security-2020-001) 中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.3.7 和 Istio 1.3.8 之间的区别。 +此版本包含了[我们在 2020 年 2 月 11 日的新闻](/zh/news/security/istio-security-2020-001)中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.3.7 和 Istio 1.3.8 之间的区别。 {{< relnote >}} diff --git a/content/zh/news/releases/1.3.x/announcing-1.3/_index.md b/content/zh/news/releases/1.3.x/announcing-1.3/_index.md index 9bf42ecb20..79c4444144 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3/_index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3/_index.md @@ -35,7 +35,7 @@ Istio 团队每发布几个版本，都会在可用性、API 和整体系统性 是的，你看的没错！我们直接在 Envoy 中实实现了大多数常见的安全策略，例如 RBAC。我们以前默认关闭 `istio-policy` 服务，现在可以将大多数 Mixer 遥测功 能迁移到 Envoy。在此版本中，我们增强了 Istio 代理，以直接向 Prometheus 发送 HTTP 指标，而无需该 `istio-telemetry` 服务来完善信息。如果您只关 -心 HTTP 服务的遥测，则此增强功能非常有用。请按照[无 Mixer 的 HTTP 遥测概述](https://github.com/istio/istio/wiki/Mixerless-HTTP-Telemetry) 进行操作，以试用此功能。在接下来的几个月里，我们将加强此功能，以便在您启用 Istio 双向 TLS 时增加对 TCP 服务的遥测支持。 +心 HTTP 服务的遥测，则此增强功能非常有用。请按照[无 Mixer 的 HTTP 遥测概述](https://github.com/istio/istio/wiki/Mixerless-HTTP-Telemetry)进行操作，以试用此功能。在接下来的几个月里，我们将加强此功能，以便在您启用 Istio 双向 TLS 时增加对 TCP 服务的遥测支持。 ## 不再需要容器端口{#container-ports-are-no-longer-required} @@ -83,4 +83,4 @@ Istio 团队每发布几个版本，都会在可用性、API 和整体系统性 Istio 的成长和成功归功于其 300 多家公司的 400 多个贡献者。 加入我们的 [Working Groups](https://github.com/istio/community/blob/master/WORKING-GROUPS.md)，帮助我们使 Istio 变得更好。 -要加入讨论，请使用您的 GitHub 账号登录 [discuss.istio.io](https://discuss.istio.io) 并加入我们！ \ No newline at end of file +要加入讨论，请使用您的 GitHub 账号登录 [discuss.istio.io](https://discuss.istio.io) 并加入我们！ diff --git a/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md b/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md index 4803a74095..ebd24f6112 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md @@ -35,7 +35,7 @@ aliases: - **改进**。改进了 ingress gateway，以实现使用 SDS 时[从另一个 secret 加载受信任的 CA 证书](/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/#configure-a-mutual-TLS-ingress-gateway)。 - **改进**。通过强制使用 [Kubernetes Trustworthy JWT](/zh/blog/2019/trustworthy-jwt-sds) 改进了 SDS 的安全性。 - **改进**。通过统一日志记录模式，改进了 Citadel Agent 日志记录。 -- **移除**。移除对 [Kubernetes 1.13 之前版本](/zh/blog/2019/trustworthy-jwt-sds) 的 Istio SDS 支持。 +- **移除**。移除对 [Kubernetes 1.13 之前版本](/zh/blog/2019/trustworthy-jwt-sds)的 Istio SDS 支持。 - **移除**。暂时移除与 Vault CA 的集成。SDS 的一些要求导致了本次临时移除，但我们将在之后的版本中重新引入 Vault CA 集成。 - **启用**。默认情况下启用 Envoy JWT 过滤器以提高安全性和可靠性。 @@ -67,9 +67,9 @@ aliases: ## `istioctl` -- **添加**。添加了 [`istioctl` 实验清单](/zh/docs/reference/commands/istioctl/#istioctl-manifest) 来管理新的实验安装清单。 -- **添加**。添加了 [`istioctl` 实验配置文件](/zh/docs/reference/commands/istioctl/#istioctl-profile) 来管理新的实验安装配置文件。 -- **添加**。添加了[`istioctl experimental metrics`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-metrics) +- **添加**。添加了 [`istioctl` 实验清单](/zh/docs/reference/commands/istioctl/#istioctl-manifest)来管理新的实验安装清单。 +- **添加**。添加了 [`istioctl` 实验配置文件](/zh/docs/reference/commands/istioctl/#istioctl-profile)来管理新的实验安装配置文件。 +- **添加**。添加了 [`istioctl experimental metrics`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-metrics) - **添加**。添加了 [`istioctl experimental describe pod`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-describe-pod)，其用于描述 Istio pod 的配置。 - **添加**。添加了 [`istioctl experimental add-to-mesh`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-add-to-mesh)，其用于将 Kubernetes 服务或虚拟机添加到现有 Istio 服务网格中。 - **添加**。添加了 [`istioctl experimental remove-from-mesh`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-remove-from-mesh)，其用于从已存在的 Istio 服务网格中移除 Kubernetes 服务或虚拟机。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3/helm-changes/index.md b/content/zh/news/releases/1.3.x/announcing-1.3/helm-changes/index.md index 55eef81767..2c25c7327f 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3/helm-changes/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3/helm-changes/index.md @@ -29,7 +29,7 @@ aliases: | 键 | 老的默认值 | 新的默认值 | 老的说明 | 新的说明 | | --- | --- | --- | --- | --- | -| `global.tag` | `1.2.0-rc.3` | `release-1.3-latest-daily` | `Istio 镜像默认tag。` | `Istio 镜像默认tag。` | +| `global.tag` | `1.2.0-rc.3` | `release-1.3-latest-daily` | `Istio 镜像默认 tag。` | `Istio 镜像默认 tag。` | ### 修改 `gateways` 键/值对{#modified-gateways-key-value-pairs} @@ -89,7 +89,7 @@ aliases: | `global.proxy.protocolDetectionTimeout` | `10ms` | `在服务端，自动协议检测使用一组启发式方法来确定连接是否正在使用 TLS，以及所使用的应用协议（例如，http vs tcp）。 这些试探法依赖于客户端发送第一次请求数。对于一些优先发现的协议，如 MySQL 协议，MongoDB 协议等等，Envoy 在完成协议检测超时情况下，默认为非 mTLS 的普通 TCP 流量。 设置此字段可调整 Envoy 等待客户端发送第一次请求数据时间。（必须 >= 1ms）` | | `global.proxy.enableCoreDumpImage` | `ubuntu:xenial` | `当 "enableCoreDump" 设置为 true 的时候，启动核心存储的镜像` | | `global.defaultTolerations` | `[]` | `节点的默认 tolerations 将应用于所有部署，以便可以将所有 Pod 调度到具有匹配 taints 的特定节点。每个组件都可以通过在下面的相关部分中添加其 tolerations block 并设置所需的值来覆盖这些默认值。如果希望将 Istio 控制平面的所有 Pod 都调度到具有指定 taints 的特定节点，请配置此字段。` | -| `global.meshID` | `""` | `MeshID表示 Mesh 标识符。在可能会彼此交互的 mesh 之间，它应该是唯一的，但是并不需要是全局唯一的。例如，如果满足以下任一条件，则两个 mesh 必须具有不同的 MeshID：- Mesh 将遥测聚集在同一个地方。- Mesh 将联合在一起。- 策略将被另一个 Mesh 引用。管理员希望这些条件中的任何一种将来可能成为现实，因此应确保为其 Mesh 分配了不同的 MeshID。在多集群 Mesh 中，每个集群必须（手动或自动）配置为具有相同的 MeshID 值。如果现有集群“加入”到多集群 Mesh 则需要将其迁移到新的 MeshID。迁移的详细信息待定，并且在安装后更改 MeshID 可能是一项破坏性操作。如果 Mesh 管理者未指定值，则 Istio 将使用 Mesh “信任域”的值。最佳实践是选择适当的“信任域”值。` | +| `global.meshID` | `""` | `MeshID 表示 Mesh 标识符。在可能会彼此交互的 mesh 之间，它应该是唯一的，但是并不需要是全局唯一的。例如，如果满足以下任一条件，则两个 mesh 必须具有不同的 MeshID：- Mesh 将遥测聚集在同一个地方。- Mesh 将联合在一起。- 策略将被另一个 Mesh 引用。管理员希望这些条件中的任何一种将来可能成为现实，因此应确保为其 Mesh 分配了不同的 MeshID。在多集群 Mesh 中，每个集群必须（手动或自动）配置为具有相同的 MeshID 值。如果现有集群“加入”到多集群 Mesh 则需要将其迁移到新的 MeshID。迁移的详细信息待定，并且在安装后更改 MeshID 可能是一项破坏性操作。如果 Mesh 管理者未指定值，则 Istio 将使用 Mesh “信任域”的值。最佳实践是选择适当的“信任域”值。` | | `global.localityLbSetting.enabled` | `true` | | ### 添加 `galley` 键/值对{#new-galley-key-value-pairs} diff --git a/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md b/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md index 452c7f5620..da29d259d6 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md @@ -35,6 +35,6 @@ Istio 现在默认情况下会捕获所有端口。如果您没有指定容器 在 Istio 1.3 中，我们正在利用 Kubernetes 的改进来更安全地为工作负载实例颁发证书。 Kubernetes 1.12 引入了 `值得信赖的` JWTs 来解决这些问题。 -[Kubernetes 1.13](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.13.md)引入了将 `aud` 字段的值更改为 API server 以外的值的功能。`aud` 字段代表了 Kubernetes 的 audience 。为了更好地保护网格，Istio 1.3 仅支持 `值得信赖的` JWT，并且当您启用 SDS 后，要求 audience ，也就是 `aud` 字段的值，为 `istio-ca`。 +[Kubernetes 1.13](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.13.md) 引入了将 `aud` 字段的值更改为 API server 以外的值的功能。`aud` 字段代表了 Kubernetes 的 audience 。为了更好地保护网格，Istio 1.3 仅支持 `值得信赖的` JWT，并且当您启用 SDS 后，要求 audience ，也就是 `aud` 字段的值，为 `istio-ca`。 在启用 SDS 的情况下升级到 Istio 1.3 之前，请参阅我们的博客文章[可信赖的 JWT 和 SDS](/zh/blog/2019/trustworthy-jwt-sds/)。 diff --git a/content/zh/news/releases/1.4.x/announcing-1.4.1/index.md b/content/zh/news/releases/1.4.x/announcing-1.4.1/index.md index 228268f56f..8731fef6d1 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4.1/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4.1/index.md @@ -20,5 +20,5 @@ aliases: - **修复** 当在 Kubernetes Ingress 中使用 cert-manager 的一个路由匹配顺序问题 ([Issue 19000](https://github.com/istio/istio/pull/19000)). - **修复** 当 pod 名称包含 `.` 时 Mixer 的 source namespace 属性配置错误的问题 ([Issue 19015](https://github.com/istio/istio/issues/19015)). - **修复** Galley 生成了过多的指标数据的问题 ([Issue 19165](https://github.com/istio/istio/issues/19165)). -- **修复** 使追踪服务的端口恢复为监听80 ([Issue 19227](https://github.com/istio/istio/issues/19227)). +- **修复** 使追踪服务的端口恢复为监听 80 ([Issue 19227](https://github.com/istio/istio/issues/19227)). - **修复** 缺失 `istioctl` 自动补齐文件的问题 ([Issue 19297](https://github.com/istio/istio/issues/19297)). diff --git a/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md b/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md index 52aad28e2e..fcbba26421 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md @@ -9,7 +9,7 @@ aliases: - /zh/news/announcing-1.4.2 --- -此版本包含了 [我们在 2019 年 12 月 10 日新闻](/zh/news/security/istio-security-2019-007) 中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.4.1 和 Istio 1.4.2 之间的区别。 +此版本包含了[我们在 2019 年 12 月 10 日新闻](/zh/news/security/istio-security-2019-007)中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.4.1 和 Istio 1.4.2 之间的区别。 {{< relnote >}} diff --git a/content/zh/news/releases/1.4.x/announcing-1.4.4/index.md b/content/zh/news/releases/1.4.x/announcing-1.4.4/index.md index 1240a1e29a..e4bfe38ac6 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4.4/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4.4/index.md @@ -9,7 +9,7 @@ aliases: - /zh/news/announcing-1.4.4 --- -此版本包含一些错误修复程序，以改善健壮性和用户体验，并修复了[我们在 2020 年 2 月 11 日新闻](/zh/news/security/istio-security-2020-001)中描述的安全漏洞。[我们在 2020 年 2 月 11 日新闻](/zh/news/security/istio-security-2020-001) 中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.4.3 和 Istio 1.3.4 之间的区别。 +此版本包含一些错误修复程序，以改善健壮性和用户体验，并修复了[我们在 2020 年 2 月 11 日新闻](/zh/news/security/istio-security-2020-001)中描述的安全漏洞。[我们在 2020 年 2 月 11 日新闻](/zh/news/security/istio-security-2020-001)中描述的安全漏洞的修复程序。此发行说明描述了 Istio 1.4.3 和 Istio 1.3.4 之间的区别。 {{< relnote >}} diff --git a/content/zh/news/releases/1.4.x/announcing-1.4/_index.md b/content/zh/news/releases/1.4.x/announcing-1.4/_index.md index cc0380ebdc..ead8c6bf1b 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4/_index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4/_index.md @@ -47,7 +47,7 @@ aliases: - 实验性的多群集设置已添加到 `istioctl` 命令中 - 我们通过删除 Docker 镜像中的 `proxy_init` 从而简化安装 -与往常一样，[社区会议](https://github.com/istio/community#community-meeting)上会发生很多相关事宜；所以请在太平洋时间的每个星期四上午的11点钟请加入我们。 +与往常一样，[社区会议](https://github.com/istio/community#community-meeting)上会发生很多相关事宜；所以请在太平洋时间的每个星期四上午的 11 点钟请加入我们。 我们很荣幸被评选为在 GitHub 上[增长最快](https://octoverse.github.com/#top-and-trending-projects)的五个开源项目之一。你想参与其中吗？加入我们的[工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md)之一 ，让我们一起把 Istio 变得更好。 diff --git a/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md b/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md index b65235ed4c..42438525ec 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md @@ -50,6 +50,6 @@ weight: 10 - **更新了** 子命令 [`istioctl authn tls-check`](/zh/docs/reference/commands/istioctl/#istioctl-authn-tls-check)，以显示正在使用的策略。 - **新增了** 实验性子命令 [`istioctl experimental wait`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-wait)，以使 `Istio` 等待，直到它已将配置推送到所有的 `Envoy sidecars`。 - **新增了** 实验性子命令 [`istioctl experimental multicluster`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-multicluster)，以帮助跨集群管理 `Istio`。 -- **新增了** 实验性子命令 [`istioctl experimental post-install webhook`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-post-install-webhook) 去 [安全配管 webhook](/zh/blog/2019/webhook/)。 +- **新增了** 实验性子命令 [`istioctl experimental post-install webhook`](/zh/docs/reference/commands/istioctl/#istioctl-experimental-post-install-webhook) 去[安全配管 webhook](/zh/blog/2019/webhook/)。 - **新增了** 实验性子命令 [`istioctl experimental upgrade`](/zh/docs/setup/upgrade/istioctl-upgrade/) 去执行 `Istio` 的升级。 - **改进了** 子命令 [`istioctl version`](/zh/docs/reference/commands/istioctl/#istioctl-version)，它现在显示的是 `Envoy proxy` 的版本。 diff --git a/content/zh/news/releases/1.4.x/announcing-1.4/upgrade-notes/index.md b/content/zh/news/releases/1.4.x/announcing-1.4/upgrade-notes/index.md index 2a2db9ee12..3c5e17b544 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4/upgrade-notes/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4/upgrade-notes/index.md @@ -9,7 +9,7 @@ weight: 20 ## 流量管理{#traffic-management} -### 443端口的 HTTP 服务{#http-services-on-port-four-four-three} +### 443 端口的 HTTP 服务{#http-services-on-port-four-four-three} `http`类型的服务将不再允许使用 443 端口，这个改动是为了保护协议不与外部的 HTTPS 服务所冲突。 @@ -23,7 +23,7 @@ weight: 20 ### 正则引擎变化{#regex-engine-changes} -为了防止过大的正则表达式消耗过多的资源，Envoy 选择了一个新的正则表达式引擎 [`re2`](https://github.com/google/re2) ，这之前用的是 `std::regex`。这两个引擎有着很明显的语法差异，尤其是，现在的正则字段被限制在100 bytes 以内。 +为了防止过大的正则表达式消耗过多的资源，Envoy 选择了一个新的正则表达式引擎 [`re2`](https://github.com/google/re2) ，这之前用的是 `std::regex`。这两个引擎有着很明显的语法差异，尤其是，现在的正则字段被限制在 100 bytes 以内。 如果你依赖了旧正则表达式引擎的某个特定的行为，你可以通过给 Pilot deployment 指定环境变量 `PILOT_ENABLE_UNSAFE_REGEX=true` 来避免这个变化。注意：这会在未来的发布中移除。 diff --git a/content/zh/news/security/incorrect-sidecar-image-1.2.4/index.md b/content/zh/news/security/incorrect-sidecar-image-1.2.4/index.md index 4be98ae71d..30c4ac1d54 100644 --- a/content/zh/news/security/incorrect-sidecar-image-1.2.4/index.md +++ b/content/zh/news/security/incorrect-sidecar-image-1.2.4/index.md @@ -26,6 +26,6 @@ aliases: 此 revert commit 发生在太平洋标准时间 2019 年 8 月 23 日下午 09:16。我们已经注意到该问题，并于太平洋标准时间 2019 年 9 月 6 日上午 09:26 回推了该镜像。 -对于由于此事件给您带来的不便，我们感到抱歉，并且我们 [正在努力建立更好的发布系统](https://github.com/istio/istio/issues/16887)，以及一种更有效的方式来处理漏洞报告。 +对于由于此事件给您带来的不便，我们感到抱歉，并且我们[正在努力建立更好的发布系统](https://github.com/istio/istio/issues/16887)，以及一种更有效的方式来处理漏洞报告。 - 1.2 的发布管理器 diff --git a/content/zh/news/security/istio-security-2019-002/index.md b/content/zh/news/security/istio-security-2019-002/index.md index 5678ae084b..7481c5fa5d 100644 --- a/content/zh/news/security/istio-security-2019-002/index.md +++ b/content/zh/news/security/istio-security-2019-002/index.md @@ -36,7 +36,7 @@ Epoch 0 terminated with an error: signal: segmentation fault (core dumped) 如果满足以下两个条件，则 Envoy 将很容易受到攻击： * 使用了 JWT 身份认证策略。 -* 使 JWT issuer(由 `jwksUri` 发行)使用 RSA 算法进行签名认证。 +* 使 JWT issuer(由 `jwksUri` 发行) 使用 RSA 算法进行签名认证。 {{< tip >}} 用于签名认证的 RSA 算法不包含任何已知的安全漏洞。 仅当使用此算法时才触发此 CVE，但与系统的安全性无关。 diff --git a/content/zh/news/security/istio-security-2019-003/index.md b/content/zh/news/security/istio-security-2019-003/index.md index b1eea972d1..a798a66fec 100644 --- a/content/zh/news/security/istio-security-2019-003/index.md +++ b/content/zh/news/security/istio-security-2019-003/index.md @@ -18,7 +18,7 @@ aliases: ## 内容{#context} -一位 Envoy 用户报告了一个 (c.f. [Envoy Issue 7728](https://github.com/envoyproxy/envoy/issues/7728)) 关于非常大的URI的正则表达式会导致 Envoy 崩溃的问题。通过调查，Istio 团队发现如果用户正在这些 Istio API（`JWT`, `VirtualService`, `HTTPAPISpecBinding`, `QuotaSpecBinding`）中使用正则表达式，那么这个问题可能在 Istio 中引发 Dos 攻击。 +一位 Envoy 用户报告了一个 (c.f. [Envoy Issue 7728](https://github.com/envoyproxy/envoy/issues/7728)) 关于非常大的 URI 的正则表达式会导致 Envoy 崩溃的问题。通过调查，Istio 团队发现如果用户正在这些 Istio API（`JWT`, `VirtualService`, `HTTPAPISpecBinding`, `QuotaSpecBinding`）中使用正则表达式，那么这个问题可能在 Istio 中引发 Dos 攻击。 ## 影响范围{#impact-and-detection} diff --git a/content/zh/news/security/istio-security-2019-004/index.md b/content/zh/news/security/istio-security-2019-004/index.md index becfdaa38f..65684ad640 100644 --- a/content/zh/news/security/istio-security-2019-004/index.md +++ b/content/zh/news/security/istio-security-2019-004/index.md @@ -20,11 +20,11 @@ Envoy 和 Istio 容易受到一系列基于 HTTP/2 的 DoS 攻击： * 利用 HTTP/2 的 PING 帧及 PING ACK 帧响应队列发起的洪水攻击，这会导致内存的无限制增长(可能导致内存不足的情况)。 * 利用 HTTP/2 的 PRIORITY 帧发起的洪水攻击，这会导致 CPU 使用率过高、不能及时响应其它正常的客户端。 -* 利用 HTTP/2 的 HEADERS 帧(带有无效 HTTP header)和 `RST_STREAM` 帧响应队列发起的洪水攻击，这会导致内存的无限制增长(可能导致内存不足的情况)。 +* 利用 HTTP/2 的 HEADERS 帧(带有无效 HTTP header) 和 `RST_STREAM` 帧响应队列发起的洪水攻击，这会导致内存的无限制增长(可能导致内存不足的情况)。 * 利用 HTTP/2 的 SETTINGS 帧及 SETTINGS ACK 帧响应队列发起的洪水攻击，这会导致内存的无限制增长(可能导致内存不足的情况)。 * 利用 HTTP/2 的 空荷载帧发起的洪水攻击，这会导致 CPU 使用率过高、不能及时响应其它正常的客户端。 -这些漏洞是从外部报告的，并影响多个代理的实现。更多信息请查看 [安全公告](https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md)。 +这些漏洞是从外部报告的，并影响多个代理的实现。更多信息请查看[安全公告](https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md)。 ## 影响范围{#impact-and-detection} @@ -32,7 +32,7 @@ Envoy 和 Istio 容易受到一系列基于 HTTP/2 的 DoS 攻击： ## 防范{#mitigation} -* 对于 Istio 1.1.x 部署：更新至[Istio 1.1.13](/zh/news/releases/1.1.x/announcing-1.1.13)或者更新的版本。 -* 对于 Istio 1.2.x 部署：更新至[Istio 1.2.4](/zh/news/releases/1.2.x/announcing-1.2.4)或者更新的版本。 +* 对于 Istio 1.1.x 部署：更新至 [Istio 1.1.13](/zh/news/releases/1.1.x/announcing-1.1.13) 或者更新的版本。 +* 对于 Istio 1.2.x 部署：更新至 [Istio 1.2.4](/zh/news/releases/1.2.x/announcing-1.2.4) 或者更新的版本。 {{< boilerplate "security-vulnerability" >}} diff --git a/content/zh/news/security/istio-security-2019-005/index.md b/content/zh/news/security/istio-security-2019-005/index.md index 233713834f..8de90a7079 100644 --- a/content/zh/news/security/istio-security-2019-005/index.md +++ b/content/zh/news/security/istio-security-2019-005/index.md @@ -25,8 +25,8 @@ Istio gateway 和 sidecar 都容易受到此问题的影响。如果您运行的 ## 防范{#mitigation} -* 对于 Istio 1.1.x 部署: 更新所有控制平面组件(Pilot、Mixer、Citadel、和 Galley)然后[更新数据平面](/zh/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade)的版本不低于[Istio 1.1.16](/zh/news/releases/1.1.x/announcing-1.1.16)。 -* 对于 Istio 1.2.x 部署: 更新所有控制平面组件(Pilot、Mixer、Citadel、和 Galley)然后[更新数据平面](/zh/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade)的版本不低于[Istio 1.2.7](/zh/news/releases/1.2.x/announcing-1.2.7)。 -* 对于 Istio 1.3.x 部署: 更新所有控制平面组件(Pilot、Mixer、Citadel、和 Galley)然后[更新数据平面](/zh/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade)的版本不低于[Istio 1.3.2](/zh/news/releases/1.3.x/announcing-1.3.2)。 +* 对于 Istio 1.1.x 部署: 更新所有控制平面组件(Pilot、Mixer、Citadel、和 Galley) 然后[更新数据平面](/zh/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade)的版本不低于 [Istio 1.1.16](/zh/news/releases/1.1.x/announcing-1.1.16)。 +* 对于 Istio 1.2.x 部署: 更新所有控制平面组件(Pilot、Mixer、Citadel、和 Galley) 然后[更新数据平面](/zh/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade)的版本不低于 [Istio 1.2.7](/zh/news/releases/1.2.x/announcing-1.2.7)。 +* 对于 Istio 1.3.x 部署: 更新所有控制平面组件(Pilot、Mixer、Citadel、和 Galley) 然后[更新数据平面](/zh/docs/setup/upgrade/cni-helm-upgrade/#sidecar-upgrade)的版本不低于 [Istio 1.3.2](/zh/news/releases/1.3.x/announcing-1.3.2)。 {{< boilerplate "security-vulnerability" >}} diff --git a/content/zh/news/security/istio-security-2019-006/index.md b/content/zh/news/security/istio-security-2019-006/index.md index 0372efd507..9eec1b242f 100644 --- a/content/zh/news/security/istio-security-2019-006/index.md +++ b/content/zh/news/security/istio-security-2019-006/index.md @@ -34,6 +34,6 @@ Istio gateway 和 sidecar 都容易受到此问题的影响。如果您运行的 --set pilot.env.PILOT_INBOUND_PROTOCOL_DETECTION_TIMEOUT=0s --set global.proxy.protocolDetectionTimeout=0s {{< /text >}} -* 对于 Istio 1.3.x 部署: 更新至[Istio 1.3.5](/zh/news/releases/1.3.x/announcing-1.3.5)或者更新的版本。 +* 对于 Istio 1.3.x 部署: 更新至 [Istio 1.3.5](/zh/news/releases/1.3.x/announcing-1.3.5) 或者更新的版本。 {{< boilerplate "security-vulnerability" >}} diff --git a/content/zh/news/security/istio-security-2020-002/index.md b/content/zh/news/security/istio-security-2020-002/index.md index fd0d6672aa..9f464cd6c0 100644 --- a/content/zh/news/security/istio-security-2020-002/index.md +++ b/content/zh/news/security/istio-security-2020-002/index.md @@ -16,7 +16,7 @@ skip_seealso: true Istio 1.3 到 1.3.6 包含了影响 Mixer 策略检查的漏洞。 注意：我们在 Istio 1.4.0 以及 Istio 1.3.7 中默认地修复了该漏洞。 -Istio 1.4.0 中的一个 [问题](https://github.com/istio/istio/issues/12063) 及其 [修复](https://github.com/istio/istio/pull/17692) 是一个非安全性问题。我们在 2019 年 12 月将该问题重新分类为漏洞。 +Istio 1.4.0 中的一个[问题](https://github.com/istio/istio/issues/12063)及其[修复](https://github.com/istio/istio/pull/17692)是一个非安全性问题。我们在 2019 年 12 月将该问题重新分类为漏洞。 __[CVE-2020-8843](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8843)__：在某些情况下，可以绕过特定配置的 Mixer 策略。Istio-proxy 在 ingress 处接受 `x-istio-attributes` header，当 Mixer 策略有选择地应用至 source 时，等价于应用至 ingress，其可能会影响策略决策。 为了避免这种情况，Istio 必须启用并以指定方式使用 Mixer 策略。在 Istio 1.3 和 1.4 中，默认情况下未启用此功能。 diff --git a/content/zh/news/support/announcing-1.0-eol-final/index.md b/content/zh/news/support/announcing-1.0-eol-final/index.md index 7a86812517..903a8bc6b1 100644 --- a/content/zh/news/support/announcing-1.0-eol-final/index.md +++ b/content/zh/news/support/announcing-1.0-eol-final/index.md @@ -8,6 +8,6 @@ aliases: - /zh/news/2019/announcing-1.0-eol-final --- -如 [先前宣布](/zh/news/support/announcing-1.0-eol/) 的一样，对 Istio 1.0 的支持现已正式终止。 +如[先前宣布](/zh/news/support/announcing-1.0-eol/)的一样，对 Istio 1.0 的支持现已正式终止。 我们将不再为 1.0 提供针对安全问题和关键错误的修复程序，因此，如果您尚未升级，我们建议您升级到最新版本的 Istio ({{}})。 diff --git a/content/zh/news/support/announcing-1.0-eol/index.md b/content/zh/news/support/announcing-1.0-eol/index.md index 76435a5425..1647a85a8c 100644 --- a/content/zh/news/support/announcing-1.0-eol/index.md +++ b/content/zh/news/support/announcing-1.0-eol/index.md @@ -8,8 +8,8 @@ aliases: - /zh/news/2019/announcing-1.0-eol --- -根据 Istio 的 [支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后，1.0 会继续得到三个月的支持。由于 [1.1已于3月19日发布](/zh/news/releases/1.1.x/announcing-1.1/)，因此对 1.0 的支持将于 2019 年 6 月 19 日终止。 +根据 Istio 的[支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后，1.0 会继续得到三个月的支持。由于 [1.1 已于 3 月 19 日发布](/zh/news/releases/1.1.x/announcing-1.1/)，因此对 1.0 的支持将于 2019 年 6 月 19 日终止。 届时，我们将停止为 1.0 提供针对安全问题和关键错误的修复程序，因此我们建议您升级到最新版本的 Istio ({{}})。如果您不升级，可能会使自己处于必须在短时间内完成重大升级才能获取关键修复程序的地步。 -我们关心您和您的集群，请对自己好点，升吧。 \ No newline at end of file +我们关心您和您的集群，请对自己好点，升吧。 diff --git a/content/zh/news/support/announcing-1.1-eol-final/index.md b/content/zh/news/support/announcing-1.1-eol-final/index.md index 2be29b9cee..1e6ec189ce 100644 --- a/content/zh/news/support/announcing-1.1-eol-final/index.md +++ b/content/zh/news/support/announcing-1.1-eol-final/index.md @@ -7,8 +7,8 @@ aliases: - /zh/news/2019/announcing-1.1-eol-final --- -正如 [之前宣布的](/zh/news/support/announcing-1.1-eol/)一样，对 Istio 1.1 的支持现已正式宣布终止。 +正如[之前宣布的](/zh/news/support/announcing-1.1-eol/)一样，对 Istio 1.1 的支持现已正式宣布终止。 -由于我们在[10月8日发布之后](/zh/news/security/istio-security-2019-005)了解到该版本存在安全漏洞，而该漏洞仍处于 1.1 版本支持的期限内，因此我们决定将 1.1 支持期限延长至原始公告之后并发布[1.1.16](/zh/news/releases/1.1.x/announcing-1.1.16)。然后，我们发现此版本引入了 [HTTP header 计算大小的错误](https://github.com/istio/istio/issues/17735) 因此我们决定最后发布一个补丁程序[1.1.17](/zh/news/releases/1.1.x/announcing-1.1.17) 发布之后，将会彻底关闭 1.1 系列版本。 +由于我们在 [10 月 8 日发布之后](/zh/news/security/istio-security-2019-005)了解到该版本存在安全漏洞，而该漏洞仍处于 1.1 版本支持的期限内，因此我们决定将 1.1 支持期限延长至原始公告之后并发布 [1.1.16](/zh/news/releases/1.1.x/announcing-1.1.16)。然后，我们发现此版本引入了 [HTTP header 计算大小的错误](https://github.com/istio/istio/issues/17735)因此我们决定最后发布一个补丁程序 [1.1.17](/zh/news/releases/1.1.x/announcing-1.1.17) 发布之后，将会彻底关闭 1.1 系列版本。 届时，我们将不会再针对安全和关键错误的修复等问题移植回 1.1，因此，我们衷心希望您将现有集群升级到最新版本的 Istio ({{}})。 diff --git a/content/zh/news/support/announcing-1.1-eol/index.md b/content/zh/news/support/announcing-1.1-eol/index.md index 0b7ff2e805..ba974dcd02 100644 --- a/content/zh/news/support/announcing-1.1-eol/index.md +++ b/content/zh/news/support/announcing-1.1-eol/index.md @@ -8,7 +8,7 @@ aliases: - /zh/news/2019/announcing-1.1-eol --- -根据 Istio 的[支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后的三个月内，将支持 1.1 LTS 版本。由于[1.2在6月18日发布](/zh/news/releases/1.2.x/announcing-1.2/)，对 1.1 的支持将于 2019 年 9 月 19 日终止。 +根据 Istio 的[支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后的三个月内，将支持 1.1 LTS 版本。由于 [1.2 在 6 月 18 日发布](/zh/news/releases/1.2.x/announcing-1.2/)，对 1.1 的支持将于 2019 年 9 月 19 日终止。 届时，我们将会把针对安全问题和关键性错误修复后的程序反向合并到 1.1，因此我们建议您升级到最新版本的 Istio（{{}}。如果您不这样做，可能会在短时间内为了修复关键性错误程序而进行频繁的重大升级。 diff --git a/content/zh/news/support/announcing-1.2-eol-final/index.md b/content/zh/news/support/announcing-1.2-eol-final/index.md index fee35adb8e..4af0d6df92 100644 --- a/content/zh/news/support/announcing-1.2-eol-final/index.md +++ b/content/zh/news/support/announcing-1.2-eol-final/index.md @@ -2,12 +2,12 @@ title: 对 Istio 1.2 的支持已终止 subtitle: 版本维护公告 description: Istio 1.2 生命周期终止公告。 -publishdate: 2019年12月13日 +publishdate: 2019 年 12 月 13 日 aliases: - /zh/news/2019/announcing-1.2-eol-final --- -如 [先前宣布](/zh/news/support/announcing-1.2-eol/) 的一样, 对 Istio 1.2 的支持现已正式终止。 +如[先前宣布](/zh/news/support/announcing-1.2-eol/)的一样, 对 Istio 1.2 的支持现已正式终止。 我们将不再为 1.2 提供针对安全问题和关键错误的修复程序，因此，如果您尚未升级， -我们建议您升级到最新版本的 Istio ({{}})。 \ No newline at end of file +我们建议您升级到最新版本的 Istio ({{}})。 diff --git a/content/zh/news/support/announcing-1.2-eol/index.md b/content/zh/news/support/announcing-1.2-eol/index.md index a4d8b3c98d..28464548a9 100644 --- a/content/zh/news/support/announcing-1.2-eol/index.md +++ b/content/zh/news/support/announcing-1.2-eol/index.md @@ -7,7 +7,7 @@ aliases: - /zh/news/2019/announcing-1.2-eol --- -根据 Istio 的[支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后，1.2 版本会继续得到三个月的支持。由于 [1.3 已经在 9 月12 日发布](/zh/news/releases/1.3.x/announcing-1.3/)，对 1.2 版本的支持将于 2019 年 12 月 13 日终止。 +根据 Istio 的[支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后，1.2 版本会继续得到三个月的支持。由于 [1.3 已经在 9 月 12 日发布](/zh/news/releases/1.3.x/announcing-1.3/)，对 1.2 版本的支持将于 2019 年 12 月 13 日终止。 届时，我们将停止为 1.2 提供针对安全问题和关键错误的修复程序，因此我们建议您升级到最新版本的 Istio ({{}})。如果您不这样做，可能会使自己处于必须在短时间内完成重大升级才能获取关键修复程序的地步。 diff --git a/content/zh/news/support/announcing-1.3-eol-final/index.md b/content/zh/news/support/announcing-1.3-eol-final/index.md index eb7772d0a2..9471aafd25 100644 --- a/content/zh/news/support/announcing-1.3-eol-final/index.md +++ b/content/zh/news/support/announcing-1.3-eol-final/index.md @@ -5,7 +5,7 @@ description: Istio 1.3 生命周期终止公告。 publishdate: 2020-02-14 --- -如 [先前宣布](/zh/news/support/announcing-1.3-eol/) 的一样, 对 Istio 1.3 的支持现已正式终止。 +如[先前宣布](/zh/news/support/announcing-1.3-eol/)的一样, 对 Istio 1.3 的支持现已正式终止。 我们将不再为 1.3 提供针对安全问题和关键错误的修复程序，因此，如果您尚未升级， 我们建议您升级到最新版本的 Istio ({{}})。 diff --git a/content/zh/news/support/announcing-1.3-eol/index.md b/content/zh/news/support/announcing-1.3-eol/index.md index 6eff766519..0d2559ef4b 100644 --- a/content/zh/news/support/announcing-1.3-eol/index.md +++ b/content/zh/news/support/announcing-1.3-eol/index.md @@ -7,7 +7,7 @@ aliases: - /zh/news/2020/announcing-1.3-eol --- -根据 Istio 的[支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后，1.3 版本会继续得到三个月的支持。由于 [1.4 版本已于 11 月 14 日发布](/zh/news/releases/1.4.x/announcing-1.4/)，因此对 1.3 版本的支持将于2020 年 2 月 14 日终止。 +根据 Istio 的[支持策略](/zh/about/release-cadence/)，在下一个 LTS 版本发布后，1.3 版本会继续得到三个月的支持。由于 [1.4 版本已于 11 月 14 日发布](/zh/news/releases/1.4.x/announcing-1.4/)，因此对 1.3 版本的支持将于 2020 年 2 月 14 日终止。 届时，我们将停止为 1.3 提供针对安全问题和关键错误的修复程序，因此我们建议您升级到最新版本的 Istio ({{}})。如果您不升级，可能会使自己处于必须在短时间内完成重大升级才能获取关键修复程序的地步。