Move pages out from the Concepts section (#5256)

* Move Deployment Models from Concepts to Setup

Signed-off-by: rcaballeromx <grca@google.com>

* Move Architecture from Concepts to Ops.

Signed-off-by: rcaballeromx <grca@google.com>

* Move Performance page from Concepts to Ops

Signed-off-by: rcaballeromx <grca@google.com>

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/concepts/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,9 @@ 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/concepts/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 for more details.]/docs/ops/architecture/)
 
-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/concepts/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/concepts/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/multicluster-version-routing/index.md

@@ -18,10 +18,10 @@ wondering if all these things will be just as simple in your real production env
 Fortunately, Istio provides several ways to configure a service mesh so that applications
 can, more-or-less transparently, be part of a mesh where the services are running
 in more than one cluster, i.e., in a
-[multicluster deployment](/docs/concepts/deployment-models/#multiple-clusters).
+[multicluster deployment]/docs/setup/deployment-models/#multiple-clusters).
 The simplest way to set up a multicluster mesh, because it has no special networking requirements,
 is using a replicated
-[control plane model](/docs/concepts/deployment-models/#control-plane-models).
+[control plane model]/docs/setup/deployment-models/#control-plane-models).
 In this configuration, each Kubernetes cluster contributing to the mesh has its own control plane,
 but each control plane is synchronized and running under a single administrative control.
 

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/concepts/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 repo](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark).
 {{< /tip >}}
 
-Also check out the [Istio Performance and Scalability guide](/docs/concepts/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 for current and future releases.
 
 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/concepts/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/concepts/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/concepts/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/concepts/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/examples/multicluster/_index.md

@@ -4,5 +4,5 @@ description: Multicluster service mesh examples for Istio that you can experimen
 weight: 100
 keywords: [multicluster]
 ---
-Refer to the [multicluster service mesh](/docs/concepts/deployment-models/) concept documentation
+Refer to the [multicluster service mesh]/docs/setup/deployment-models/) concept documentation
 for more information.

content/en/docs/examples/multicluster/gke/index.md

@@ -8,7 +8,7 @@ aliases:
 ---
 
 This example shows how to configure a multicluster mesh with a
-[single-network deployment](/docs/concepts/deployment-models/#single-network)
+[single-network deployment]/docs/setup/deployment-models/#single-network)
 over 2 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) clusters.
 
 ## Before you begin

content/en/docs/examples/multicluster/icp/index.md

@@ -10,7 +10,7 @@ aliases:
 This example demonstrates how to setup network connectivity between two
 [IBM Cloud Private](https://www.ibm.com/cloud/private) clusters
 and then compose them into a multicluster mesh using a
-[single-network deployment](/docs/concepts/deployment-models/#single-network).
+[single-network deployment]/docs/setup/deployment-models/#single-network).
 
 ## Create the IBM Cloud Private Clusters
 

content/en/docs/ops/architecture/index.md

@@ -1,7 +1,9 @@
 ---
 title: Architecture
 description: Describes Istio's high-level architecture and design goals.
-weight: 70
+weight: 20
+aliases:
+- /docs/concepts/architecture
 ---
 
 An Istio service mesh is logically split into a **data plane** and a **control

content/en/docs/ops/performance-and-scalability/index.md

@@ -1,16 +1,21 @@
 ---
 title: Performance and Scalability
 description: Introduces performance and scalability for Istio.
-weight: 50
+weight: 25
 aliases:
-    - /docs/performance-and-scalability/overview
-    - /docs/performance-and-scalability/microbenchmarks
-    - /docs/performance-and-scalability/performance-testing-automation
-    - /docs/performance-and-scalability/realistic-app-benchmark
-    - /docs/performance-and-scalability/scalability
-    - /docs/performance-and-scalability/scenarios
-    - /docs/performance-and-scalability/synthetic-benchmarks
-keywords: [performance,scalability,scale,benchmarks]
+- /docs/performance-and-scalability/overview
+- /docs/performance-and-scalability/microbenchmarks
+- /docs/performance-and-scalability/performance-testing-automation
+- /docs/performance-and-scalability/realistic-app-benchmark
+- /docs/performance-and-scalability/scalability
+- /docs/performance-and-scalability/scenarios
+- /docs/performance-and-scalability/synthetic-benchmarks
+- /docs/concepts/performance-and-scalability
+keywords:
+- performance
+- scalability
+- scale
+- benchmarks
 ---
 
 Istio makes it easy to create a network of deployed services with rich routing,

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/concepts/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/reference/glossary/mesh-federation.md

@@ -6,4 +6,4 @@ Mesh federation is the act of exposing services between meshes and enabling
 communication across mesh boundaries. Each mesh may expose a subset of its
 services to enable one or more other meshes to consume the exposed services. You
 can use mesh federation to enable communication between meshes in a
-[multi-mesh deployment](/docs/concepts/deployment-models/#multiple-meshes).
+[multi-mesh deployment]/docs/setup/deployment-models/#multiple-meshes).

content/en/docs/setup/additional-setup/config-profiles/index.md

@@ -56,13 +56,13 @@ To further customize Istio and install addons, you can add one or more `--set <k
 ## Multicluster profiles
 
 Istio provides two additional built-in configuration profiles that are used exclusively for configuring a
-[multicluster deployment](/docs/concepts/deployment-models/#multiple-clusters):
+[multicluster deployment]/docs/setup/deployment-models/#multiple-clusters):
 
 1. **remote**: used for configuring remote clusters of a
-    multicluster mesh with a shared [control plane](/docs/concepts/deployment-models/#control-plane-models).
+    multicluster mesh with a shared [control plane]/docs/setup/deployment-models/#control-plane-models).
 
 1. **multicluster-gateways**: used for configuring clusters of a
-    multicluster mesh with replicated [control planes](/docs/concepts/deployment-models/#control-plane-models).
+    multicluster mesh with replicated [control planes]/docs/setup/deployment-models/#control-plane-models).
 
 The **remote** profile is configured using the values file `values-istio-remote.yaml`. This profile installs only two
 Istio core components:

content/en/docs/setup/deployment-models/index.md

@@ -1,7 +1,7 @@
 ---
 title: Deployment Models
 description: Describes the system models that impact your overall Istio depolyment.
-weight: 60
+weight: 6
 keywords:
 - single-cluster
 - multiple-clusters
@@ -14,6 +14,7 @@ keywords:
 - multiple-meshes
 aliases:
 - /docs/concepts/multicluster-deployments/
+- /docs/concepts/deployment-models
 ---
 
 Important system models impact your overall Istio deployment model. This page

content/en/docs/setup/install/multicluster/_index.md

@@ -16,5 +16,5 @@ a combination of the approaches can be used. For example,
 two clusters might share a control plane while a third has its own.
 {{< /tip >}}
 
-Refer to the [multicluster deployment model](/docs/concepts/deployment-models/#multiple-clusters)
+Refer to the [multicluster deployment model]/docs/setup/deployment-models/#multiple-clusters)
 concept documentation for more information.

content/en/docs/setup/install/multicluster/gateways/index.md

@@ -11,8 +11,8 @@ keywords: [kubernetes,multicluster,gateway]
 ---
 
 Follow this guide to install an Istio
-[multicluster deployment](/docs/concepts/deployment-models/#multiple-clusters)
-with replicated [control plane](/docs/concepts/deployment-models/#control-plane-models) instances
+[multicluster deployment]/docs/setup/deployment-models/#multiple-clusters)
+with replicated [control plane]/docs/setup/deployment-models/#control-plane-models) instances
 in every cluster and using gateways to connect services across clusters.
 
 Instead of using a shared Istio control plane to manage the mesh,

content/en/docs/setup/install/multicluster/shared-gateways/index.md

@@ -10,7 +10,7 @@ aliases:
 ---
 
 Follow this guide to configure a multicluster mesh using a shared
-[control plane](/docs/concepts/deployment-models/#control-plane-models)
+[control plane]/docs/setup/deployment-models/#control-plane-models)
 with gateways to connect network-isolated clusters.
 Istio's location-aware service routing feature is used to route requests to different endpoints,
 depending on the location of the request source.

content/en/docs/setup/install/multicluster/shared-vpn/index.md

@@ -9,14 +9,14 @@ aliases:
     - /docs/setup/kubernetes/install/multicluster/shared-vpn/
 ---
 
-Follow this guide to install an Istio [multicluster service mesh](/docs/concepts/deployment-models/#multiple-clusters)
+Follow this guide to install an Istio [multicluster service mesh]/docs/setup/deployment-models/#multiple-clusters)
 where the Kubernetes cluster services and the applications in each cluster
 have the capability to expose their internal Kubernetes network to other
 clusters.
 
 In this configuration, multiple Kubernetes clusters running
 a remote configuration connect to a shared Istio
-[control plane](/docs/concepts/deployment-models/#control-plane-models).
+[control plane]/docs/setup/deployment-models/#control-plane-models).
 Once one or more remote Kubernetes clusters are connected to the
 Istio control plane, Envoy can then form a mesh network across multiple clusters.
 

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/concepts/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

@@ -24,31 +24,31 @@ 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/concepts/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/concepts/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/concepts/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
 teams cannot interfere with each other.
 
-We have also improved the [multicluster capabilities and usability](/docs/concepts/deployment-models/).
+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/concepts/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
 also supporting additional multicluster topologies including different
-[control plane models](/docs/concepts/deployment-models/#control-plane-models)
+[control plane models]/docs/setup/deployment-models/#control-plane-models)
 topologies without requiring a flat network.
 
 There is lots more -- see the [change notes](./change-notes) for complete

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/concepts/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,7 +183,7 @@ concise list of things you should know before upgrading your deployment to Istio
 
 ### Configuration management
 
-- **Galley**. Added [Galley](/docs/concepts/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

content/en/news/2019/announcing-1.3/_index.md

@@ -62,7 +62,7 @@ Leverage Istio to integrate with Kubernetes and handle large fleets of Envoys in
     - Added a new Grafana dashboard for Citadel
     - Improved the Pilot dashboard to expose additional key metrics
 
-- Added the new [Istio Deployment Models concept](/docs/concepts/deployment-models/) to help you decide what deployment model suits your needs.
+- Added the new [Istio Deployment Models concept]/docs/setup/deployment-models/) to help you decide what deployment model suits your needs.
 
 - Organized the content in of our [Operations Guide](/docs/ops/) and created a [section with all troubleshooting tasks](/docs/ops/common-problems) to help you find the information you seek faster.