From 01747f234941f36f719d1e65ecc1e290a6fc72b2 Mon Sep 17 00:00:00 2001 From: Martin Taillefer Date: Mon, 11 Nov 2019 07:43:43 -0800 Subject: [PATCH] Fix a bunch of busted links. (#5588) --- content/en/blog/2018/egress-https/index.md | 2 +- .../en/blog/2019/app-identity-and-access-adapter/index.md | 5 +++-- content/en/blog/2019/data-plane-setup/index.md | 2 +- content/en/blog/2019/performance-best-practices/index.md | 4 ++-- content/en/docs/concepts/observability/index.md | 2 +- content/en/docs/concepts/traffic-management/index.md | 2 +- .../docs/examples/mesh-expansion/multi-network/index.md | 2 +- .../docs/examples/mesh-expansion/single-network/index.md | 2 +- .../en/docs/ops/traffic-management/introduction/index.md | 2 +- .../egress/egress_sni_monitoring_and_policies/index.md | 2 +- content/en/news/2019/announcing-1.1/_index.md | 8 ++++---- content/en/news/2019/announcing-1.1/change-notes/index.md | 6 +++--- content/zh/blog/2018/egress-https/index.md | 2 +- .../zh/blog/2019/app-identity-and-access-adapter/index.md | 5 +++-- content/zh/blog/2019/data-plane-setup/index.md | 2 +- content/zh/blog/2019/performance-best-practices/index.md | 4 ++-- content/zh/docs/concepts/observability/index.md | 2 +- content/zh/docs/concepts/traffic-management/index.md | 2 +- .../docs/examples/mesh-expansion/multi-network/index.md | 2 +- .../docs/examples/mesh-expansion/single-network/index.md | 2 +- .../zh/docs/ops/traffic-management/introduction/index.md | 2 +- .../egress/egress_sni_monitoring_and_policies/index.md | 2 +- content/zh/news/2019/announcing-1.1/_index.md | 8 ++++---- content/zh/news/2019/announcing-1.1/change-notes/index.md | 6 +++--- 24 files changed, 40 insertions(+), 38 deletions(-) diff --git a/content/en/blog/2018/egress-https/index.md b/content/en/blog/2018/egress-https/index.md index 4c5c680b6f..8dc70e8c5e 100644 --- a/content/en/blog/2018/egress-https/index.md +++ b/content/en/blog/2018/egress-https/index.md @@ -190,7 +190,7 @@ in this case `www.googleapis.com`. To allow Istio to perform monitoring and policy enforcement of egress requests based on HTTP details, the microservices must issue HTTP requests. Istio then opens an HTTPS connection to the destination (performs TLS origination). The code of the microservices must be written differently or configured differently, according to whether the microservice runs -inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency]/docs/ops/architecture/#design-goals). Sometimes you need to compromise... +inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency](/docs/ops/architecture/#design-goals). Sometimes you need to compromise... The diagram below shows two options for sending HTTPS traffic to external services. On the top, a microservice sends regular HTTPS requests, encrypted end-to-end. On the bottom, the same microservice sends unencrypted HTTP requests diff --git a/content/en/blog/2019/app-identity-and-access-adapter/index.md b/content/en/blog/2019/app-identity-and-access-adapter/index.md index 916f9d6301..1bc9e375d0 100644 --- a/content/en/blog/2019/app-identity-and-access-adapter/index.md +++ b/content/en/blog/2019/app-identity-and-access-adapter/index.md @@ -16,9 +16,10 @@ With the [App Identity and Access Adapter](https://github.com/ibm-cloud-security ## Understanding Istio and the adapter -[Istio](/docs/concepts/what-is-istio/) is an open source service mesh that transparently layers onto distributed applications and seamlessly integrates with Kubernetes. To reduce the complexity of deployments Istio provides behavioral insights and operational control over the service mesh as a whole. [See Istio Architecture for more details.]/docs/ops/architecture/) +[Istio](/docs/concepts/what-is-istio/) is an open source service mesh that transparently layers onto distributed applications and seamlessly integrates with Kubernetes. To reduce the complexity of deployments Istio provides behavioral insights and operational control over the service mesh as a whole. +See [Istio Architecture](/docs/ops/architecture/) for more details. -Istio uses [Envoy proxy sidecars](/blog/2019/data-plane-setup/) to mediate inbound and outbound traffic for all pods in the service mesh. Istio extracts telemetry from the Envoy sidecars and sends it to [Mixer]/docs/ops/architecture/#mixer), the Istio component responsible for collecting telemetry and policy enforcement. +Istio uses [Envoy proxy sidecars](/blog/2019/data-plane-setup/) to mediate inbound and outbound traffic for all pods in the service mesh. Istio extracts telemetry from the Envoy sidecars and sends it to [Mixer](/docs/ops/architecture/#mixer), the Istio component responsible for collecting telemetry and policy enforcement. The App Identity and Access adapter extends the Mixer functionality by analyzing the telemetry (attributes) against various access control policies across the service mesh. The access control policies can be linked to a particular Kubernetes services and can be finely tuned to specific service endpoints. For more information about policies and telemetry, see the Istio documentation. diff --git a/content/en/blog/2019/data-plane-setup/index.md b/content/en/blog/2019/data-plane-setup/index.md index bfbd8cd784..c265d760d2 100644 --- a/content/en/blog/2019/data-plane-setup/index.md +++ b/content/en/blog/2019/data-plane-setup/index.md @@ -10,7 +10,7 @@ target_release: 1.0 --- A simple overview of an Istio service-mesh architecture always starts with describing the control-plane and data-plane. -[From Istio’s documentation:]/docs/ops/architecture/) +From [Istio’s documentation](/docs/ops/architecture/) {{< quote >}} An Istio service mesh is logically split into a data plane and a control plane. diff --git a/content/en/blog/2019/performance-best-practices/index.md b/content/en/blog/2019/performance-best-practices/index.md index 0d11eb1e43..9642604d68 100644 --- a/content/en/blog/2019/performance-best-practices/index.md +++ b/content/en/blog/2019/performance-best-practices/index.md @@ -12,7 +12,7 @@ Service meshes add a lot of functionality to application deployments, including Earlier this year, we published a [blog post](/blog/2019/istio1.1_perf/) on Istio's performance improvements in version 1.1. Following the release of [Istio 1.2](/news/2019/announcing-1.2), we want to provide guidance and tools to help you benchmark Istio's data plane performance in a production-ready Kubernetes environment. -Overall, we found that Istio's [sidecar proxy]/docs/ops/architecture/#envoy) latency scales with the number of concurrent connections. At 1000 requests per second (RPS), across 16 connections, Istio adds **3 milliseconds** per request in the 50th percentile, and **10 milliseconds** in the 99th percentile. +Overall, we found that Istio's [sidecar proxy](/docs/ops/architecture/#envoy) latency scales with the number of concurrent connections. At 1000 requests per second (RPS), across 16 connections, Istio adds **3 milliseconds** per request in the 50th percentile, and **10 milliseconds** in the 99th percentile. In the [Istio Tools repository](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark), you’ll find scripts and instructions for measuring Istio's data plane performance, with additional instructions on how to run the scripts with [Linkerd](https://linkerd.io), another service mesh implementation. [Follow along](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#setup) as we detail some best practices for each step of the performance test framework. @@ -108,6 +108,6 @@ For a mesh with 1000 RPS across 16 connections, Istio 1.2 adds just **3 millisec Istio's performance depends on your specific setup and traffic load. Because of this variance, make sure your test setup accurately reflects your production workloads. To try out the benchmarking scripts, head over [to the Istio Tools repository](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark). {{< /tip >}} -Also check out the [Istio Performance and Scalability guide]/docs/ops/performance-and-scalability) for the most up-to-date performance data for current and future releases. +Also check out the [Istio Performance and Scalability guide](/docs/ops/performance-and-scalability) for the most up-to-date performance data. Thank you for reading, and happy benchmarking! diff --git a/content/en/docs/concepts/observability/index.md b/content/en/docs/concepts/observability/index.md index fd9bce71c2..1f1a153b73 100644 --- a/content/en/docs/concepts/observability/index.md +++ b/content/en/docs/concepts/observability/index.md @@ -19,7 +19,7 @@ Istio, operators gain a thorough understanding of how monitored services are int Istio generates the following types of telemetry in order to provide overall service mesh observability: - [**Metrics**](#metrics). Istio generates a set of service metrics based on the four "golden signals" of monitoring (latency, traffic, errors, and - saturation). Istio also provides detailed metrics for the [mesh control plane]/docs/ops/architecture/). + saturation). Istio also provides detailed metrics for the [mesh control plane](/docs/ops/architecture/). A default set of mesh monitoring dashboards built on top of these metrics is also provided. - [**Distributed Traces**](#distributed-traces). Istio generates distributed trace spans for each service, providing operators with a detailed understanding of call flows and service dependencies within a mesh. diff --git a/content/en/docs/concepts/traffic-management/index.md b/content/en/docs/concepts/traffic-management/index.md index d83b523ec5..dd22f7b497 100644 --- a/content/en/docs/concepts/traffic-management/index.md +++ b/content/en/docs/concepts/traffic-management/index.md @@ -29,7 +29,7 @@ changes to your services. If you’re interested in the details of how the features described in this guide work, you can find out more about Istio’s traffic management implementation in the -[architecture overview]/docs/ops/architecture/). The rest of +[architecture overview](/docs/ops/architecture/). The rest of this guide introduces Istio’s traffic management features. ## Introducing Istio traffic management diff --git a/content/en/docs/examples/mesh-expansion/multi-network/index.md b/content/en/docs/examples/mesh-expansion/multi-network/index.md index 45f2826b66..449ed496a8 100644 --- a/content/en/docs/examples/mesh-expansion/multi-network/index.md +++ b/content/en/docs/examples/mesh-expansion/multi-network/index.md @@ -74,7 +74,7 @@ cluster for mesh expansion, run the following commands on a machine with cluster -o jsonpath='{.data.cert-chain\.pem}' | base64 --decode > cert-chain.pem {{< /text >}} -1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot]/docs/ops/architecture/#pilot) and workloads on cluster through this IP address. +1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/ops/architecture/#pilot) and workloads on cluster through this IP address. {{< text bash >}} $ export GWIP=$(kubectl get -n istio-system service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') diff --git a/content/en/docs/examples/mesh-expansion/single-network/index.md b/content/en/docs/examples/mesh-expansion/single-network/index.md index 85c87be5ef..caaa52ec1c 100644 --- a/content/en/docs/examples/mesh-expansion/single-network/index.md +++ b/content/en/docs/examples/mesh-expansion/single-network/index.md @@ -78,7 +78,7 @@ cluster for mesh expansion, run the following commands on a machine with cluster $ export SERVICE_NAMESPACE="default" {{< /text >}} -1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot]/docs/ops/architecture/#pilot) through this IP address. +1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/ops/architecture/#pilot) through this IP address. {{< text bash >}} $ export GWIP=$(kubectl get -n istio-system service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') diff --git a/content/en/docs/ops/traffic-management/introduction/index.md b/content/en/docs/ops/traffic-management/introduction/index.md index 3d4c3c8144..d345b7e2cc 100644 --- a/content/en/docs/ops/traffic-management/introduction/index.md +++ b/content/en/docs/ops/traffic-management/introduction/index.md @@ -19,7 +19,7 @@ other content. When attempting to understand, monitor or troubleshoot the networking within an Istio deployment it is critical to understand the fundamental Istio concepts starting with the service mesh. The service mesh is described -in [Architecture]/docs/ops/architecture/). As noted +in [Architecture](/docs/ops/architecture/). As noted in the architecture section Istio has a distinct control plane and a data plane and operationally it will be important to be able to monitor the network state of both. The service mesh is a fully interconnected set of diff --git a/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md b/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md index b96b3757e1..63e60be5a1 100644 --- a/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md +++ b/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md @@ -92,7 +92,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ ## Monitor the SNI and the source identity, and enforce access policies based on them -Since you enabled mutual TLS between the sidecar proxies and the egress gateway, you can monitor the [service identity]/docs/ops/architecture/#citadel) of the applications that access external services, and enforce policies +Since you enabled mutual TLS between the sidecar proxies and the egress gateway, you can monitor the [service identity](/docs/ops/architecture/#citadel) of the applications that access external services, and enforce policies based on the identities of the traffic source. In Istio on Kubernetes, the identities are based on [Service Accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/). In this diff --git a/content/en/news/2019/announcing-1.1/_index.md b/content/en/news/2019/announcing-1.1/_index.md index cfe828e20c..ec4ed702dc 100644 --- a/content/en/news/2019/announcing-1.1/_index.md +++ b/content/en/news/2019/announcing-1.1/_index.md @@ -23,17 +23,17 @@ The theme for 1.1 is Enterprise Ready. We’ve been very pleased to see more and more companies using Istio in production, but as some larger companies tried to adopt Istio they hit some limits. -One of our prime areas of focus has been [performance and scalability]/docs/ops/performance-and-scalability/). +One of our prime areas of focus has been [performance and scalability](/docs/ops/performance-and-scalability/). As people moved into production with larger clusters running more services at higher volume, they hit some scaling and performance issues. The [sidecars](/docs/concepts/traffic-management/#sidecars) took too many resources and added too much latency. The control plane (especially -[Pilot]/docs/ops/architecture/#pilot)) was overly +[Pilot](/docs/ops/architecture/#pilot)) was overly resource hungry. We’ve done a lot of work to make both the data plane and the control plane more efficient. You can find the details of our 1.1 performance testing and the -results in our updated [performance ans scalability concept]/docs/ops/performance-and-scalability/). +results in our updated [performance ans scalability concept](/docs/ops/performance-and-scalability/). We’ve done work around namespace isolation as well. This lets you use Kubernetes namespaces to enforce boundaries of control, and ensures that your @@ -42,7 +42,7 @@ teams cannot interfere with each other. We have also improved the [multicluster capabilities and usability](/docs/setup/deployment-models/). We listened to the community and improved defaults for traffic control and policy. We introduced a new component called -[Galley]/docs/ops/architecture/#galley). Galley validates that sweet, +[Galley](/docs/ops/architecture/#galley). Galley validates that sweet, sweet YAML, reducing the chance of configuration errors. Galley will also be instrumental in [multicluster setups](/docs/setup/install/multicluster/), gathering service discovery information from each Kubernetes cluster. We are diff --git a/content/en/news/2019/announcing-1.1/change-notes/index.md b/content/en/news/2019/announcing-1.1/change-notes/index.md index 407d912cb4..5f618beeff 100644 --- a/content/en/news/2019/announcing-1.1/change-notes/index.md +++ b/content/en/news/2019/announcing-1.1/change-notes/index.md @@ -85,7 +85,7 @@ concise list of things you should know before upgrading your deployment to Istio [gateways](/docs/concepts/traffic-management/#gateways). - **Performance and Scalability Improvements**. Tuned the performance and - scalability of Istio and Envoy. Read more about [Performance and Scalability]/docs/ops/performance-and-scalability/) + scalability of Istio and Envoy. Read more about [Performance and Scalability](/docs/ops/performance-and-scalability/) enhancements. - **Access Logging Off by Default**. Disabled the access logs for all Envoy @@ -183,11 +183,11 @@ concise list of things you should know before upgrading your deployment to Istio ### Configuration management -- **Galley**. Added [Galley]/docs/ops/architecture/#galley) as the +- **Galley**. Added [Galley](/docs/ops/architecture/#galley) as the primary configuration ingestion and distribution mechanism within Istio. It provides a robust model to validate, transform, and distribute configuration states to Istio components insulating the Istio components from Kubernetes - details. Galley uses the [Mesh Configuration Protocol (MCP)](https://github.com/istio/api/tree/{{< source_branch_name >}}/mcp) + details. Galley uses the [Mesh Configuration Protocol](https://github.com/istio/api/tree/{{< source_branch_name >}}/mcp) to interact with components. - **Monitoring Port**. Changed Galley's default monitoring port from 9093 to diff --git a/content/zh/blog/2018/egress-https/index.md b/content/zh/blog/2018/egress-https/index.md index 4c5c680b6f..8dc70e8c5e 100644 --- a/content/zh/blog/2018/egress-https/index.md +++ b/content/zh/blog/2018/egress-https/index.md @@ -190,7 +190,7 @@ in this case `www.googleapis.com`. To allow Istio to perform monitoring and policy enforcement of egress requests based on HTTP details, the microservices must issue HTTP requests. Istio then opens an HTTPS connection to the destination (performs TLS origination). The code of the microservices must be written differently or configured differently, according to whether the microservice runs -inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency]/docs/ops/architecture/#design-goals). Sometimes you need to compromise... +inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency](/docs/ops/architecture/#design-goals). Sometimes you need to compromise... The diagram below shows two options for sending HTTPS traffic to external services. On the top, a microservice sends regular HTTPS requests, encrypted end-to-end. On the bottom, the same microservice sends unencrypted HTTP requests 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 916f9d6301..1bc9e375d0 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 @@ -16,9 +16,10 @@ With the [App Identity and Access Adapter](https://github.com/ibm-cloud-security ## Understanding Istio and the adapter -[Istio](/docs/concepts/what-is-istio/) is an open source service mesh that transparently layers onto distributed applications and seamlessly integrates with Kubernetes. To reduce the complexity of deployments Istio provides behavioral insights and operational control over the service mesh as a whole. [See Istio Architecture for more details.]/docs/ops/architecture/) +[Istio](/docs/concepts/what-is-istio/) is an open source service mesh that transparently layers onto distributed applications and seamlessly integrates with Kubernetes. To reduce the complexity of deployments Istio provides behavioral insights and operational control over the service mesh as a whole. +See [Istio Architecture](/docs/ops/architecture/) for more details. -Istio uses [Envoy proxy sidecars](/blog/2019/data-plane-setup/) to mediate inbound and outbound traffic for all pods in the service mesh. Istio extracts telemetry from the Envoy sidecars and sends it to [Mixer]/docs/ops/architecture/#mixer), the Istio component responsible for collecting telemetry and policy enforcement. +Istio uses [Envoy proxy sidecars](/blog/2019/data-plane-setup/) to mediate inbound and outbound traffic for all pods in the service mesh. Istio extracts telemetry from the Envoy sidecars and sends it to [Mixer](/docs/ops/architecture/#mixer), the Istio component responsible for collecting telemetry and policy enforcement. The App Identity and Access adapter extends the Mixer functionality by analyzing the telemetry (attributes) against various access control policies across the service mesh. The access control policies can be linked to a particular Kubernetes services and can be finely tuned to specific service endpoints. For more information about policies and telemetry, see the Istio documentation. diff --git a/content/zh/blog/2019/data-plane-setup/index.md b/content/zh/blog/2019/data-plane-setup/index.md index bfbd8cd784..17f03f9e62 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 --- A simple overview of an Istio service-mesh architecture always starts with describing the control-plane and data-plane. -[From Istio’s documentation:]/docs/ops/architecture/) +From [Istio’s documentation](/docs/ops/architecture/): {{< quote >}} An Istio service mesh is logically split into a data plane and a control plane. diff --git a/content/zh/blog/2019/performance-best-practices/index.md b/content/zh/blog/2019/performance-best-practices/index.md index 0d11eb1e43..9642604d68 100644 --- a/content/zh/blog/2019/performance-best-practices/index.md +++ b/content/zh/blog/2019/performance-best-practices/index.md @@ -12,7 +12,7 @@ Service meshes add a lot of functionality to application deployments, including Earlier this year, we published a [blog post](/blog/2019/istio1.1_perf/) on Istio's performance improvements in version 1.1. Following the release of [Istio 1.2](/news/2019/announcing-1.2), we want to provide guidance and tools to help you benchmark Istio's data plane performance in a production-ready Kubernetes environment. -Overall, we found that Istio's [sidecar proxy]/docs/ops/architecture/#envoy) latency scales with the number of concurrent connections. At 1000 requests per second (RPS), across 16 connections, Istio adds **3 milliseconds** per request in the 50th percentile, and **10 milliseconds** in the 99th percentile. +Overall, we found that Istio's [sidecar proxy](/docs/ops/architecture/#envoy) latency scales with the number of concurrent connections. At 1000 requests per second (RPS), across 16 connections, Istio adds **3 milliseconds** per request in the 50th percentile, and **10 milliseconds** in the 99th percentile. In the [Istio Tools repository](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark), you’ll find scripts and instructions for measuring Istio's data plane performance, with additional instructions on how to run the scripts with [Linkerd](https://linkerd.io), another service mesh implementation. [Follow along](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#setup) as we detail some best practices for each step of the performance test framework. @@ -108,6 +108,6 @@ For a mesh with 1000 RPS across 16 connections, Istio 1.2 adds just **3 millisec Istio's performance depends on your specific setup and traffic load. Because of this variance, make sure your test setup accurately reflects your production workloads. To try out the benchmarking scripts, head over [to the Istio Tools repository](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark). {{< /tip >}} -Also check out the [Istio Performance and Scalability guide]/docs/ops/performance-and-scalability) for the most up-to-date performance data for current and future releases. +Also check out the [Istio Performance and Scalability guide](/docs/ops/performance-and-scalability) for the most up-to-date performance data. Thank you for reading, and happy benchmarking! diff --git a/content/zh/docs/concepts/observability/index.md b/content/zh/docs/concepts/observability/index.md index b7054e099e..d1d22d466b 100644 --- a/content/zh/docs/concepts/observability/index.md +++ b/content/zh/docs/concepts/observability/index.md @@ -19,7 +19,7 @@ Istio, operators gain a thorough understanding of how monitored services are int Istio generates the following types of telemetry in order to provide overall service mesh observability: - [**Metrics**](#metrics). Istio generates a set of service metrics based on the four "golden signals" of monitoring (latency, traffic, errors, and - saturation). Istio also provides detailed metrics for the [mesh control plane]/docs/ops/architecture/). + saturation). Istio also provides detailed metrics for the [mesh control plane](/docs/ops/architecture/). A default set of mesh monitoring dashboards built on top of these metrics is also provided. - [**Distributed Traces**](#distributed-traces). Istio generates distributed trace spans for each service, providing operators with a detailed understanding of call flows and service dependencies within a mesh. diff --git a/content/zh/docs/concepts/traffic-management/index.md b/content/zh/docs/concepts/traffic-management/index.md index 555941969d..74e9b54927 100644 --- a/content/zh/docs/concepts/traffic-management/index.md +++ b/content/zh/docs/concepts/traffic-management/index.md @@ -29,7 +29,7 @@ changes to your services. If you’re interested in the details of how the features described in this guide work, you can find out more about Istio’s traffic management implementation in the -[architecture overview]/docs/ops/architecture/). The rest of +[architecture overview](/docs/ops/architecture/). The rest of this guide introduces Istio’s traffic management features. ## Introducing Istio Traffic Management diff --git a/content/zh/docs/examples/mesh-expansion/multi-network/index.md b/content/zh/docs/examples/mesh-expansion/multi-network/index.md index 26e1e3562e..ac1a4dca09 100644 --- a/content/zh/docs/examples/mesh-expansion/multi-network/index.md +++ b/content/zh/docs/examples/mesh-expansion/multi-network/index.md @@ -74,7 +74,7 @@ cluster for mesh expansion, run the following commands on a machine with cluster -o jsonpath='{.data.cert-chain\.pem}' | base64 --decode > cert-chain.pem {{< /text >}} -1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot]/docs/ops/architecture/#pilot) and workloads on cluster through this IP address. +1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/ops/architecture/#pilot) and workloads on cluster through this IP address. {{< text bash >}} $ export GWIP=$(kubectl get -n istio-system service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') diff --git a/content/zh/docs/examples/mesh-expansion/single-network/index.md b/content/zh/docs/examples/mesh-expansion/single-network/index.md index 85c87be5ef..caaa52ec1c 100644 --- a/content/zh/docs/examples/mesh-expansion/single-network/index.md +++ b/content/zh/docs/examples/mesh-expansion/single-network/index.md @@ -78,7 +78,7 @@ cluster for mesh expansion, run the following commands on a machine with cluster $ export SERVICE_NAMESPACE="default" {{< /text >}} -1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot]/docs/ops/architecture/#pilot) through this IP address. +1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/ops/architecture/#pilot) through this IP address. {{< text bash >}} $ export GWIP=$(kubectl get -n istio-system service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') diff --git a/content/zh/docs/ops/traffic-management/introduction/index.md b/content/zh/docs/ops/traffic-management/introduction/index.md index bea4f811eb..0abd59d9a3 100644 --- a/content/zh/docs/ops/traffic-management/introduction/index.md +++ b/content/zh/docs/ops/traffic-management/introduction/index.md @@ -19,7 +19,7 @@ other content. When attempting to understand, monitor or troubleshoot the networking within an Istio deployment it is critical to understand the fundamental Istio concepts starting with the service mesh. The service mesh is described -in [Architecture]/docs/ops/architecture/). As noted +in [Architecture](/docs/ops/architecture/). As noted in the architecture section Istio has a distinct control plane and a data plane and operationally it will be important to be able to monitor the network state of both. The service mesh is a fully interconnected set of 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 2ade6661be..4121aa05a4 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 @@ -92,7 +92,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ ## Monitor the SNI and the source identity, and enforce access policies based on them -Since you enabled mutual TLS between the sidecar proxies and the egress gateway, you can monitor the [service identity]/docs/ops/architecture/#citadel) of the applications that access external services, and enforce policies +Since you enabled mutual TLS between the sidecar proxies and the egress gateway, you can monitor the [service identity](/docs/ops/architecture/#citadel) of the applications that access external services, and enforce policies based on the identities of the traffic source. In Istio on Kubernetes, the identities are based on [Service Accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/). In this diff --git a/content/zh/news/2019/announcing-1.1/_index.md b/content/zh/news/2019/announcing-1.1/_index.md index 2735e489b5..de33390e9a 100644 --- a/content/zh/news/2019/announcing-1.1/_index.md +++ b/content/zh/news/2019/announcing-1.1/_index.md @@ -24,17 +24,17 @@ The theme for 1.1 is Enterprise Ready. We’ve been very pleased to see more and more companies using Istio in production, but as some larger companies tried to adopt Istio they hit some limits. -One of our prime areas of focus has been [performance and scalability]/docs/ops/performance-and-scalability/). +One of our prime areas of focus has been [performance and scalability](/docs/ops/performance-and-scalability/). As people moved into production with larger clusters running more services at higher volume, they hit some scaling and performance issues. The [sidecars](/docs/concepts/traffic-management/#sidecars) took too many resources and added too much latency. The control plane (especially -[Pilot]/docs/ops/architecture/#pilot)) was overly +[Pilot](/docs/ops/architecture/#pilot)) was overly resource hungry. We’ve done a lot of work to make both the data plane and the control plane more efficient. You can find the details of our 1.1 performance testing and the -results in our updated [performance ans scalability concept]/docs/ops/performance-and-scalability/). +results in our updated [performance ans scalability concept](/docs/ops/performance-and-scalability/). We’ve done work around namespace isolation as well. This lets you use Kubernetes namespaces to enforce boundaries of control, and ensures that your @@ -43,7 +43,7 @@ teams cannot interfere with each other. We have also improved the [multicluster capabilities and usability](/docs/setup/deployment-models/). We listened to the community and improved defaults for traffic control and policy. We introduced a new component called -[Galley]/docs/ops/architecture/#galley). Galley validates that sweet, +[Galley](/docs/ops/architecture/#galley). Galley validates that sweet, sweet YAML, reducing the chance of configuration errors. Galley will also be instrumental in [multicluster setups](/docs/setup/install/multicluster/), gathering service discovery information from each Kubernetes cluster. We are diff --git a/content/zh/news/2019/announcing-1.1/change-notes/index.md b/content/zh/news/2019/announcing-1.1/change-notes/index.md index 407d912cb4..5f618beeff 100644 --- a/content/zh/news/2019/announcing-1.1/change-notes/index.md +++ b/content/zh/news/2019/announcing-1.1/change-notes/index.md @@ -85,7 +85,7 @@ concise list of things you should know before upgrading your deployment to Istio [gateways](/docs/concepts/traffic-management/#gateways). - **Performance and Scalability Improvements**. Tuned the performance and - scalability of Istio and Envoy. Read more about [Performance and Scalability]/docs/ops/performance-and-scalability/) + scalability of Istio and Envoy. Read more about [Performance and Scalability](/docs/ops/performance-and-scalability/) enhancements. - **Access Logging Off by Default**. Disabled the access logs for all Envoy @@ -183,11 +183,11 @@ concise list of things you should know before upgrading your deployment to Istio ### Configuration management -- **Galley**. Added [Galley]/docs/ops/architecture/#galley) as the +- **Galley**. Added [Galley](/docs/ops/architecture/#galley) as the primary configuration ingestion and distribution mechanism within Istio. It provides a robust model to validate, transform, and distribute configuration states to Istio components insulating the Istio components from Kubernetes - details. Galley uses the [Mesh Configuration Protocol (MCP)](https://github.com/istio/api/tree/{{< source_branch_name >}}/mcp) + details. Galley uses the [Mesh Configuration Protocol](https://github.com/istio/api/tree/{{< source_branch_name >}}/mcp) to interact with components. - **Monitoring Port**. Changed Galley's default monitoring port from 9093 to