Fix a bunch of busted links. (#5588)

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

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.
 

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.

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!

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.

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

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}')

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}')

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

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

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

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

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

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.
 

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.

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!

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.

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

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}')

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}')

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

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

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

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