diff --git a/.circleci/config.yml b/.circleci/config.yml deleted file mode 100644 index 1d20947e6b..0000000000 --- a/.circleci/config.yml +++ /dev/null @@ -1,64 +0,0 @@ -# Ruby CircleCI 2.0 configuration file -# -# Check https://circleci.com/docs/2.0/language-ruby/ for more details -# -version: 2 -jobs: - build: - docker: - # specify the version you desire here - - image: circleci/ruby:2.4.1-node-browsers - - working_directory: ~/repo - - steps: - - checkout - - # Download and cache dependencies - - restore_cache: - keys: - - v4-dependencies-{{ checksum "Gemfile.lock" }} - # fallback to using the latest cache if no exact match is found - - v4-dependencies- - - - run: - name: Installing proofer dependencies - command: | - gem install bundler - bundle install --jobs=4 --retry=3 --path .vendor/bundle - - - save_cache: - paths: - - ./.vendor/bundle - key: v4-dependencies-{{ checksum "Gemfile.lock" }} - - - restore_cache: - keys: - - htmlproofer-cache-v3 - - - run: - name: Proofing HTML - command: - bundle exec rake test - - # save the external URLs cache - - save_cache: - key: htmlproofer-cache-v3 - paths: - - tmp/.htmlproofer - - - run: - name: Installing speller dependencies - command: | - mkdir -p .vendor/node - npm install --prefix .vendor/node markdown-spellcheck - - - run: - name: Checking markdown spelling - command: - .vendor/node/node_modules/markdown-spellcheck/bin/mdspell --en-us --ignore-acronyms --ignore-numbers --no-suggestions --report *.md */*.md */*/*.md */*/*/*.md */*/*/*/*.md - - - run: - name: Checking markdown style - command: - mdl --ignore-front-matter --style mdl_style.rb . diff --git a/.gitignore b/.gitignore index ffc759f48f..75c2f92c30 100644 --- a/.gitignore +++ b/.gitignore @@ -1,15 +1,11 @@ -_site -_rakesite -_static_site -.bundle -config_override.yml -.jekyll-metadata # Eclipse artifacts .project .pydevproject *.iml .idea/ -.bundle/ tmp/ *.bak .DS_Store +.tools +.htmlproofer +public diff --git a/.spelling b/.spelling index 9471a63947..66b9f15f21 100644 --- a/.spelling +++ b/.spelling @@ -429,6 +429,7 @@ ratelimit-handler raw.githubusercontent.com raw.githubusercontent.com) reachability +rearchitect readinessProbe redis redis-master-2353460263-1ecey diff --git a/404.md b/404.md deleted file mode 100644 index 8eb11d0d4e..0000000000 --- a/404.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Page Not Found -description: Page redirection - -weight: 1 - -layout: notfound ---- -{% include home.html %} - -
Join the istio-users@ mailing list to participate in discussions @@ -29,14 +26,14 @@ There are quite a few ways to get plugged in with the Istio community: | ||
Follow us on Twitter to get the latest news. | ||
Stack Overflow is for practical questions and curated answers on deploying, configuring, and using Istio. @@ -44,21 +41,21 @@ There are quite a few ways to get plugged in with the Istio community: | ||
Chat with members of the Istio community on Rocket Chat. | ||
![]() |
+ ![]() |
GitHub is where development takes place on Istio code. |
![]() |
+ ![]() |
If you want to get into the nuts and bolts of Istio, check out our growing collection of design documents. To access these, simply join the @@ -69,7 +66,7 @@ There are quite a few ways to get plugged in with the Istio community: |
If you'd like to contribute to the Istio project, consider participating in our
working groups.
diff --git a/content/docs/_index.md b/content/docs/_index.md
index f6f469b611..4a594662fb 100644
--- a/content/docs/_index.md
+++ b/content/docs/_index.md
@@ -1,41 +1,38 @@
---
title: Welcome
description: Istio documentation home page.
-
weight: 1
-
-toc: false
+sidebar_multicard: true
---
-{% include home.html %}
From here you can learn all about Istio's architecture and how to deploy and use Istio.
-- [Concepts]({{home}}/docs/concepts/). Concepts explain some significant aspect of Istio. This
+- [Concepts](/docs/concepts/). Concepts explain some significant aspect of Istio. This
is where you can learn about what Istio does and how it does it.
-- [Setup]({{home}}/docs/setup/). Setup contains instructions for installing
+- [Setup](/docs/setup/). Setup contains instructions for installing
the Istio control plane in various environments, as well as instructions
for installing the sidecar in the application deployment. Quick start
instructions are available for
- [Kubernetes]({{home}}/docs/setup/kubernetes/quick-start.html) and
- [Docker Compose w/ Consul]({{home}}/docs/setup/consul/quick-start.html).
+ [Kubernetes](/docs/setup/kubernetes/quick-start/) and
+ [Docker Compose w/ Consul](/docs/setup/consul/quick-start/).
-- [Tasks]({{home}}/docs/tasks/). Tasks show you how to do a single directed activity with Istio.
+- [Tasks](/docs/tasks/). Tasks show you how to do a single directed activity with Istio.
-- [Guides]({{home}}/docs/guides/). Guides are fully working stand-alone examples
+- [Guides](/docs/guides/). Guides are fully working stand-alone examples
intended to highlight a particular set of Istio's features.
-- [Reference]({{home}}/docs/reference/). Detailed exhaustive lists of
+- [Reference](/docs/reference/). Detailed exhaustive lists of
command-line options, configuration options, API definitions, and procedures.
In addition, you might find these links interesting:
-- The latest Istio monthly release is {{site.data.istio.version}}: [download {{site.data.istio.version}}](https://github.com/istio/istio/releases),
-[release notes]({{home}}/about/notes/{{site.data.istio.version}}.html).
+- The latest Istio monthly release is {{< istio_version >}}: [download {{< istio_version >}}](https://github.com/istio/istio/releases),
+[release notes](/about/notes/{{< istio_version >}}/).
- Nostalgic for days gone by? We keep an [archive of the earlier releases' documentation](https://archive.istio.io/).
- We're always looking for help improving our documentation, so please don't hesitate to
[file an issue](https://github.com/istio/istio.github.io/issues/new) if you see some problem.
-Or better yet, submit your own [contributions]({{home}}/about/contribute/editing.html) to help
+Or better yet, submit your own [contributions](/about/contribute/editing/) to help
make our docs better.
diff --git a/content/docs/concepts/_index.md b/content/docs/concepts/_index.md
index 5134317c9a..a68c4eb7f5 100644
--- a/content/docs/concepts/_index.md
+++ b/content/docs/concepts/_index.md
@@ -1,10 +1,6 @@
---
title: Concepts
description: Concepts help you learn about the different parts of the Istio system and the abstractions it uses.
-
weight: 10
-
-toc: false
+type: section-index
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/concepts/policies-and-telemetry/_index.md b/content/docs/concepts/policies-and-telemetry/_index.md
index 6644e9be23..9583620a5a 100644
--- a/content/docs/concepts/policies-and-telemetry/_index.md
+++ b/content/docs/concepts/policies-and-telemetry/_index.md
@@ -1,12 +1,8 @@
---
title: Policies and Telemetry
description: Introduces the policy control snd telemetry collection mechanisms.
-
weight: 40
-
-toc: false
-redirect_from:
+type: section-index
+aliases:
- /docs/concepts/policy-and-control/index.html
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/concepts/policies-and-telemetry/config.md b/content/docs/concepts/policies-and-telemetry/config.md
index 12bdfea7fe..ab9af6c448 100644
--- a/content/docs/concepts/policies-and-telemetry/config.md
+++ b/content/docs/concepts/policies-and-telemetry/config.md
@@ -2,11 +2,10 @@
title: Configuration
description: An overview of the key concepts used to configure Istio's policy enforcement and telemetry collection features.
weight: 30
-redirect_from:
+aliases:
- /docs/concepts/policy-and-control/mixer-config.html
- /docs/concepts/policy-and-control/attributes.html
---
-{% include home.html %}
Istio's policy and telemetry features are configured through a common model designed to
put operators in control of every aspect of authorization policy and telemetry collection.
@@ -41,10 +40,10 @@ every request, giving Mixer a set of attributes that describe the request and th
around the request. Based on its configuration and the specific set of attributes it was
given, Mixer generates calls to a variety of infrastructure backends.
-{% include image.html width="60%" ratio="42.60%"
- link="./img/machine.svg"
+{{< image width="60%" ratio="42.60%"
+ link="../img/machine.svg"
caption="Attribute Machine"
- %}
+ >}}
### Attribute vocabulary
@@ -54,7 +53,7 @@ in the deployment. The primary attribute producer in Istio is Envoy, although
specialized Mixer adapters can also generate attributes.
The common baseline set of attributes available in most Istio deployments is defined
-[here]({{home}}/docs/reference/config/policy-and-telemetry/attribute-vocabulary.html).
+[here](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/).
## Configuration model
@@ -137,7 +136,7 @@ spec:
```
Each adapter defines its own particular format of configuration data. The exhaustive set of
-adapters and their specific configuration formats can be found [here]({{home}}/docs/reference/config/policy-and-telemetry/adapters/).
+adapters and their specific configuration formats can be found [here](/docs/reference/config/policy-and-telemetry/adapters/).
## Instances
@@ -160,7 +159,7 @@ spec:
```
Note that all the dimensions expected in the handler configuration are specified in the mapping.
Templates define the specific required content of individual instances. The exhaustive set of
-templates and their specific configuration formats can be found [here]({{home}}/docs/reference/config/policy-and-telemetry/templates/).
+templates and their specific configuration formats can be found [here](/docs/reference/config/policy-and-telemetry/templates/).
## Rules
@@ -208,14 +207,14 @@ destination_version: destination.labels["version"] | "unknown"
With the above, the `destination_version` label is assigned the value of `destination.labels["version"]`. However if that attribute
is not present, the literal `"unknown"` is used.
-Refer to the [attribute expression reference]({{home}}/docs/reference/config/policy-and-telemetry/expression-language.html) for details.
+Refer to the [attribute expression reference](/docs/reference/config/policy-and-telemetry/expression-language/) for details.
## What's next
-- Learn how to [configure telemetry collection]({{home}}/docs/tasks/telemetry).
+- Learn how to [configure telemetry collection](/docs/tasks/telemetry/).
-- Learn how to [configure policy enforcement]({{home}}/docs/tasks/policy-enforcement).
+- Learn how to [configure policy enforcement](/docs/tasks/policy-enforcement/).
-- Learn about the set of [supported adapters]({{home}}/docs/reference/config/policy-and-telemetry/adapters).
+- Learn about the set of [supported adapters](/docs/reference/config/policy-and-telemetry/adapters/).
-- See the blog post describing [Mixer's adapter model]({{home}}/blog/mixer-adapter-model.html).
+- See the blog post describing [Mixer's adapter model](/blog/2017/adapter-model/).
diff --git a/content/docs/concepts/policies-and-telemetry/overview.md b/content/docs/concepts/policies-and-telemetry/overview.md
index d2a9c76f9a..68525dcc25 100644
--- a/content/docs/concepts/policies-and-telemetry/overview.md
+++ b/content/docs/concepts/policies-and-telemetry/overview.md
@@ -2,12 +2,10 @@
title: Overview
description: Describes the design of the policy and telemetry mechanisms.
weight: 5
-redirect_from:
+aliases:
- /docs/concepts/policy-and-control/mixer.html
---
-{% include home.html %}
-
Istio provides a flexible model to enforce authorization policies and collect telemetry for the
services in a mesh.
@@ -26,10 +24,10 @@ control to operators.
Mixer is the Istio component responsible for providing policy controls and telemetry collection:
-{% include image.html width="75%" ratio="49.26%"
- link="./img/topology-without-cache.svg"
+{{< image width="75%" ratio="49.26%"
+ link="../img/topology-without-cache.svg"
caption="Mixer Topology"
- %}
+ >}}
The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry.
The sidecar has local caching such that a relatively large percentage of precondition checks can be performed from cache. Additionally, the
@@ -61,11 +59,11 @@ monitoring, quotas, ACL checking, and more. The exact set of
adapters used at runtime is determined through configuration and can easily be
extended to target new or custom infrastructure backends.
-{% include image.html width="35%" ratio="138%"
- link="./img/adapters.svg"
+{{< image width="35%" ratio="138%"
+ link="../img/adapters.svg"
alt="Showing Mixer with adapters."
caption="Mixer and its Adapters"
- %}
+ >}}
## Reliability and latency
@@ -82,10 +80,10 @@ The sidecar proxies that sit next to each service instance in the mesh must nece
caching and buffering. Mixer, however, lives independently and can use considerably larger caches and output buffers. Mixer thus acts as a highly-scaled and highly-available second-level
cache for the sidecars.
-{% include image.html width="75%" ratio="65.89%"
- link="./img/topology-with-cache.svg"
+{{< image width="75%" ratio="65.89%"
+ link="../img/topology-with-cache.svg"
caption="Mixer Topology"
- %}
+ >}}
Since Mixer’s expected availability is considerably higher than most infrastructure backends (those often have availability of perhaps 99.9%). Mixer's local
caches and buffers not only contribute to reduce latency, they also help mask infrastructure backend failures by being able to continue operating
@@ -96,4 +94,4 @@ sent to backends (through local aggregation). Both of these can reduce operation
## What's next
-* Read the [Mixer adapter model]({{home}}/blog/2017/adapter-model.html) blog post.
+* Read the [Mixer adapter model](/blog/2017/adapter-model/) blog post.
diff --git a/content/docs/concepts/security/_index.md b/content/docs/concepts/security/_index.md
index c1138c61d2..3fb140eb27 100644
--- a/content/docs/concepts/security/_index.md
+++ b/content/docs/concepts/security/_index.md
@@ -1,10 +1,6 @@
---
title: Security
description: Describes Istio's authorization and authentication functionality.
-
weight: 30
-
-toc: false
+type: section-index
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/concepts/security/authn-policy.md b/content/docs/concepts/security/authn-policy.md
index 9bef88cea8..811c04d182 100644
--- a/content/docs/concepts/security/authn-policy.md
+++ b/content/docs/concepts/security/authn-policy.md
@@ -1,15 +1,14 @@
---
-title: Istio Authentication Policy
-description: Describes Istio authentication policy
+title: Authentication Policy
+description: Describes Istio's authentication policy
weight: 10
-redirect_from:
+aliases:
- /docs/concepts/network-and-auth/auth.html
---
-{% include home.html %}
Istio authentication policy enables operators to specify authentication requirements for a service (or services). Istio authentication policy is composed of two parts:
-* Peer: verifies the party, the direct client, that makes the connection. The common authentication mechanism for this is [mutual TLS]({{home}}/docs/concepts/security/mutual-tls.html). Istio is responsible for managing both client and server sides to enforce the policy.
+* Peer: verifies the party, the direct client, that makes the connection. The common authentication mechanism for this is [mutual TLS](/docs/concepts/security/mutual-tls/). Istio is responsible for managing both client and server sides to enforce the policy.
* Origin: verifies the party, the original client, that makes the request (e.g end-users, devices etc). JWT is the only supported mechanism for origin authentication at the moment. Istio configures the server side to perform authentication, but doesn't enforce that the client side sends the required token.
@@ -19,10 +18,10 @@ Identities from both authentication parts, if applicable, are output to the next
Authentication policies are saved in Istio config store (in 0.7, the storage implementation uses Kubernetes CRD), and distributed by control plane. Depending on the size of the mesh, config propagation may take a few seconds to a few minutes. During the transition, you can expect traffic lost or inconsistent authentication results.
-{% include image.html width="80%" ratio="75%"
- link="./img/authn.svg"
+{{< image width="80%" ratio="75%"
+ link="../img/authn.svg"
caption="Authentication Policy Architecture"
- %}
+ >}}
Policy is scoped to namespaces, with (optional) target selector rules to narrow down the set of services (within the same namespace as the policy) on which the policy should be applied. This aligns with the ACL model based on Kubernetes RBAC. More specifically, only the admin of the namespace can set policies for services in that namespace.
@@ -40,7 +39,7 @@ Origin principal (principal from origin authentication) is not explicitly output
### Target selectors
-Defines rule to find service(s) on which policy should be applied. If no rule is provided, the policy is matched to all services in the namespace, so-called namespace-level policy (as opposed to service-level policies which have non-empty selector rules). Istio uses the service-level policy if available, otherwise it falls back to namespace-level policy. If neither is defined, it uses the default policy based on service mesh config and/or service annotation, which can only set mutual TLS setting (these are mechanisms before Istio 0.7 to config mutual TLS for Istio service mesh). See [testing Istio mutual TLS]({{home}}/docs/tasks/security/mutual-tls.html) and [per-service mutual TLS enablement]({{home}}/docs/tasks/security/per-service-mtls.html) for more details.
+Defines rule to find service(s) on which policy should be applied. If no rule is provided, the policy is matched to all services in the namespace, so-called namespace-level policy (as opposed to service-level policies which have non-empty selector rules). Istio uses the service-level policy if available, otherwise it falls back to namespace-level policy. If neither is defined, it uses the default policy based on service mesh config and/or service annotation, which can only set mutual TLS setting (these are mechanisms before Istio 0.7 to config mutual TLS for Istio service mesh). See [testing Istio mutual TLS](/docs/tasks/security/mutual-tls/) and [per-service mutual TLS enablement](/docs/tasks/security/per-service-mtls/) for more details.
Operators are responsible for avoiding conflicts, e.g create more than one service-level policy that matches to the same service(s) (or more than one namespace-level policy on the same namespace).
@@ -84,4 +83,4 @@ Defines what is the principal from the authentication. By default, this will be
## What's next
-Try out the [Basic Istio authentication policy]({{home}}/docs/tasks/security/authn-policy.html) tutorial.
+Try out the [Basic Istio authentication policy](/docs/tasks/security/authn-policy/) tutorial.
diff --git a/content/docs/concepts/security/mutual-tls.md b/content/docs/concepts/security/mutual-tls.md
index eb6713c46f..2f800ff8c9 100644
--- a/content/docs/concepts/security/mutual-tls.md
+++ b/content/docs/concepts/security/mutual-tls.md
@@ -2,14 +2,9 @@
title: Mutual TLS Authentication
description: Describes Istio's mutual TLS authentication architecture which provides a strong service identity and secure communication channels between services.
weight: 10
-
---
-{% include home.html %}
-
-## Overview
-
-Istio's aim is to enhance the security of microservices and their communication without requiring service code changes. It is responsible for:
+Istio aims to enhance the security of microservices and their communication without requiring service code changes. It is responsible for:
* Providing each service with a strong identity that represents its role to enable interoperability across clusters and clouds
@@ -24,11 +19,11 @@ security. This diagram describes how Istio is used to secure the service-to-serv
as the service account 'frontend-team' and service 'backend' running as the service account 'backend-team'. Istio supports services running
on both Kubernetes containers and VM/bare-metal machines.
-{% include image.html width="80%" ratio="56.25%"
- link="./img/mutual-tls/auth.svg"
+{{< image width="80%" ratio="56.25%"
+ link="../img/mutual-tls/auth.svg"
alt="Components making up the Istio auth model."
caption="Istio Security Architecture"
- %}
+ >}}
As illustrated in the diagram, Istio leverages secret volume mount to deliver keys/certs from Citadel to Kubernetes containers. For services running on
VM/bare-metal machines, we introduce a node agent, which is a process running on each VM/bare-metal machine. It generates the private key and CSR (certificate
@@ -99,7 +94,7 @@ pair for each of the existing and new service accounts, and sends them to the AP
1. When a pod is created, API Server mounts the key and certificate pair according to the service account using [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
-1. [Pilot]({{home}}/docs/concepts/traffic-management/pilot.html) generates the config with proper key and certificate and secure naming information,
+1. [Pilot](/docs/concepts/traffic-management/pilot/) generates the config with proper key and certificate and secure naming information,
which defines what service account(s) can run a certain service, and passes it to Envoy.
### Deployment phase (VM/bare-metal Machines Scenario)
@@ -140,7 +135,7 @@ Let's consider a 3-tier application with three services: photo-frontend, photo-b
In this scenario, a cluster admin creates 3 namespaces: istio-citadel-ns, photo-ns, and datastore-ns. Admin has access to all namespaces, and each team only has
access to its own namespace. The photo SRE team creates 2 service accounts to run photo-frontend and photo-backend respectively in namespace photo-ns. The
datastore SRE team creates 1 service account to run the datastore service in namespace datastore-ns. Moreover, we need to enforce the service access control
-in [Istio Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html) such that photo-frontend cannot access datastore.
+in [Istio Mixer](/docs/concepts/policies-and-telemetry/overview/) such that photo-frontend cannot access datastore.
In this setup, Citadel is able to provide keys and certificates management for all namespaces, and isolate
microservice deployments from each other.
diff --git a/content/docs/concepts/security/rbac.md b/content/docs/concepts/security/rbac.md
index 9c5f315162..2f114cf6d1 100644
--- a/content/docs/concepts/security/rbac.md
+++ b/content/docs/concepts/security/rbac.md
@@ -2,9 +2,7 @@
title: Istio Role-Based Access Control (RBAC)
description: Describes Istio RBAC which provides access control for services in Istio Mesh.
weight: 20
-
---
-{% include home.html %}
## Overview
@@ -22,11 +20,11 @@ It features:
The diagram below shows the Istio RBAC architecture. Operators specify Istio RBAC policies. The policies are saved in
the Istio config store.
-{% include image.html width="80%" ratio="56.25%"
- link="./img/IstioRBAC.svg"
+{{< image width="80%" ratio="56.25%"
+ link="../img/IstioRBAC.svg"
alt="Istio RBAC"
caption="Istio RBAC Architecture"
- %}
+ >}}
The Istio RBAC engine does two things:
* **Fetch RBAC policy.** Istio RBAC engine watches for changes on RBAC policy. It fetches the updated RBAC policy if it sees any changes.
@@ -35,7 +33,7 @@ request context against the RBAC policies, and returns the authorization result
### Request context
-In the current release, the Istio RBAC engine is implemented as a [Mixer adapter]({{home}}/docs/concepts/policies-and-telemetry/overview.html#adapters).
+In the current release, the Istio RBAC engine is implemented as a [Mixer adapter](/docs/concepts/policies-and-telemetry/overview/#adapters).
The request context is provided as an instance of the
[authorization template](https://github.com/istio/istio/blob/master/mixer/template/authorization/template.proto). The request context
contains all the information about the request and the environment that an authorization module needs to know. In particular, it has two parts:
@@ -248,4 +246,4 @@ spec:
## What's next
-Try out the [Istio RBAC with Bookinfo]({{home}}/docs/tasks/security/role-based-access-control.html) sample.
+Try out the [Istio RBAC with Bookinfo](/docs/tasks/security/role-based-access-control/) sample.
diff --git a/content/docs/concepts/traffic-management/_index.md b/content/docs/concepts/traffic-management/_index.md
index db6114be65..efb35d3cb0 100644
--- a/content/docs/concepts/traffic-management/_index.md
+++ b/content/docs/concepts/traffic-management/_index.md
@@ -1,10 +1,6 @@
---
title: Traffic Management
description: Describes the various Istio features focused on traffic routing and control.
-
weight: 20
-
-toc: false
+type: section-index
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/concepts/traffic-management/fault-injection.md b/content/docs/concepts/traffic-management/fault-injection.md
index b8b11b5b31..72b118c13f 100644
--- a/content/docs/concepts/traffic-management/fault-injection.md
+++ b/content/docs/concepts/traffic-management/fault-injection.md
@@ -1,14 +1,11 @@
---
title: Fault Injection
description: Introduces the idea of systematic fault injection that can be used to uncover conflicting failure recovery policies across services.
-
weight: 40
-
-toc: false
---
While Envoy sidecar/proxy provides a host of
-[failure recovery mechanisms](./handling-failures.html) to services running
+[failure recovery mechanisms](/docs/concepts/traffic-management/handling-failures/) to services running
on Istio, it is still
imperative to test the end-to-end failure recovery capability of the
application as a whole. Misconfigured failure recovery policies (e.g.,
@@ -31,4 +28,4 @@ increased network latency, or an overloaded upstream service. Aborts are
crash failures that mimic failures in upstream services. Aborts usually
manifest in the form of HTTP error codes, or TCP connection failures.
-Refer to [Istio's traffic management rules](./rules-configuration.html) for more details.
+Refer to [Istio's traffic management rules](/docs/concepts/traffic-management/rules-configuration/) for more details.
diff --git a/content/docs/concepts/traffic-management/handling-failures.md b/content/docs/concepts/traffic-management/handling-failures.md
index fb619e6b17..332ec4f276 100644
--- a/content/docs/concepts/traffic-management/handling-failures.md
+++ b/content/docs/concepts/traffic-management/handling-failures.md
@@ -1,11 +1,8 @@
---
title: Handling Failures
description: An overview of failure recovery capabilities in Envoy that can be leveraged by unmodified applications to improve robustness and prevent cascading failures.
-
weight: 30
-
---
-{% include home.html %}
Envoy provides a set of out-of-the-box _opt-in_ failure recovery features
that can be taken advantage of by the services in an application. Features
@@ -23,7 +20,7 @@ include:
instance in the load balancing pool
These features can be dynamically configured at runtime through
-[Istio's traffic management rules](./rules-configuration.html).
+[Istio's traffic management rules](/docs/concepts/traffic-management/rules-configuration/).
The jitter between retries minimizes the impact of retries on an overloaded
upstream service, while timeout budgets ensure that the calling service
@@ -44,9 +41,9 @@ and prevent localized failures from cascading instability to other nodes.
Istio's traffic management rules allow
operators to set global defaults for failure recovery per
service/version. However, consumers of a service can also override
-[timeout]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#HTTPTimeout)
+[timeout](/docs/reference/config/istio.routing.v1alpha1/#HTTPTimeout)
and
-[retry]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#HTTPRetry)
+[retry](/docs/reference/config/istio.routing.v1alpha1/#HTTPRetry)
defaults by providing request-level overrides through special HTTP headers.
With the Envoy proxy implementation, the headers are `x-envoy-upstream-rq-timeout-ms` and
`x-envoy-max-retries`, respectively.
diff --git a/content/docs/concepts/traffic-management/load-balancing.md b/content/docs/concepts/traffic-management/load-balancing.md
index ead3ffdb37..3e6caa7cd9 100644
--- a/content/docs/concepts/traffic-management/load-balancing.md
+++ b/content/docs/concepts/traffic-management/load-balancing.md
@@ -1,10 +1,7 @@
---
title: Discovery & Load Balancing
description: Describes how traffic is load balanced across instances of a service in the mesh.
-
weight: 25
-
-toc: false
---
This page describes how Istio load balances traffic across instances of a
@@ -23,10 +20,10 @@ registry and provides a platform-agnostic service discovery
interface. Envoy instances in the mesh perform service discovery and
dynamically update their load balancing pools accordingly.
-{% include image.html width="80%" ratio="74.79%"
- link="./img/pilot/LoadBalancing.svg"
+{{< image width="80%" ratio="74.79%"
+ link="../img/pilot/LoadBalancing.svg"
caption="Discovery and Load Balancing"
- %}
+ >}}
As illustrated in the figure above, services in the mesh access each other
using their DNS names. All HTTP traffic bound to a service is automatically
@@ -44,7 +41,7 @@ check failures for a given instance exceeds a pre-specified threshold, it
will be ejected from the load balancing pool. Similarly, when the number of
health checks that pass exceed a pre-specified threshold, the instance will
be added back into the load balancing pool. You can find out more about Envoy's
-failure-handling features in [Handling Failures](./handling-failures.html).
+failure-handling features in [Handling Failures](/docs/concepts/traffic-management/handling-failures/).
Services can actively shed load by responding with a HTTP 503 to a health
check. In such an event, the service instance will be immediately removed
diff --git a/content/docs/concepts/traffic-management/overview.md b/content/docs/concepts/traffic-management/overview.md
index 8497c2867f..83af01e8ec 100644
--- a/content/docs/concepts/traffic-management/overview.md
+++ b/content/docs/concepts/traffic-management/overview.md
@@ -1,16 +1,12 @@
---
title: Overview
description: Provides a conceptual overview of traffic management in Istio and the features it enables.
-
weight: 1
-
---
-{% include home.html %}
-
This page provides an overview of how traffic management works
in Istio, including the benefits of its traffic management
-principles. It assumes that you've already read [What Is Istio?]({{home}}/docs/concepts/what-is-istio/overview.html)
+principles. It assumes that you've already read [What Is Istio?](/docs/concepts/what-is-istio/overview/)
and are familiar with Istio's high-level architecture. You can
find out more about individual traffic management features in the other
guides in this section.
@@ -18,7 +14,7 @@ guides in this section.
## Pilot and Envoy
The core component used for traffic management in Istio is
-[Pilot](./pilot.html), which manages and configures all the Envoy
+[Pilot](/docs/concepts/traffic-management/pilot/), which manages and configures all the Envoy
proxy instances deployed in a particular Istio service mesh. It lets you
specify what rules you want to use to route traffic between Envoy proxies
and configure failure recovery features such as timeouts, retries, and
@@ -26,7 +22,7 @@ circuit breakers. It also maintains a canonical model of all the services
in the mesh and uses this to let Envoys know about the other instances in
the mesh via its discovery service.
-Each Envoy instance maintains [load balancing information](./load-balancing.html)
+Each Envoy instance maintains [load balancing information](/docs/concepts/traffic-management/load-balancing/)
based on the information it gets from Pilot and periodic health-checks
of other instances in its load-balancing pool, allowing it to intelligently
distribute traffic between destination instances while following its specified
@@ -43,17 +39,17 @@ of traffic for a particular service to go to a canary version irrespective
of the size of the canary deployment, or send traffic to a particular version
depending on the content of the request.
-{% include image.html width="85%" ratio="69.52%"
- link="./img/pilot/TrafficManagementOverview.svg"
+{{< image width="85%" ratio="69.52%"
+ link="../img/pilot/TrafficManagementOverview.svg"
caption="Traffic Management with Istio"
- %}
+ >}}
Decoupling traffic flow from infrastructure scaling like this allows Istio
to provide a variety of traffic management features that live outside the
-application code. As well as dynamic [request routing](request-routing.html)
+application code. As well as dynamic [request routing](/docs/concepts/traffic-management/request-routing/)
for A/B testing, gradual rollouts, and canary releases, it also handles
-[failure recovery](handling-failures.html) using timeouts, retries, and
-circuit breakers, and finally [fault injection](fault-injection.html) to
+[failure recovery](/docs/concepts/traffic-management/handling-failures/) using timeouts, retries, and
+circuit breakers, and finally [fault injection](/docs/concepts/traffic-management/fault-injection/) to
test the compatibility of failure recovery policies across services. These
capabilities are all realized through the Envoy sidecars/proxies deployed
across the service mesh.
diff --git a/content/docs/concepts/traffic-management/pilot.md b/content/docs/concepts/traffic-management/pilot.md
index 5bfc8ae9a7..fc6ca32a87 100644
--- a/content/docs/concepts/traffic-management/pilot.md
+++ b/content/docs/concepts/traffic-management/pilot.md
@@ -1,23 +1,19 @@
---
title: Pilot
description: Introduces Pilot, the component responsible for managing a distributed deployment of Envoy proxies in the service mesh.
-
weight: 10
-
toc: false
-redirect_from:
+aliases:
- /docs/concepts/traffic-management/manager.html
---
-{% include home.html %}
Pilot is responsible for the lifecycle of Envoy instances deployed
across the Istio service mesh.
-{% include image.html width="60%" ratio="72.17%"
- link="./img/pilot/PilotAdapters.svg"
- alt="Pilot's overall architecture."
+{{< image width='60%' ratio="72.17%"
+ link="../img/pilot/PilotAdapters.svg"
caption="Pilot Architecture"
- %}
+ >}}
As illustrated in the figure above, Pilot maintains a canonical
representation of services in the mesh that is independent of the underlying
@@ -36,5 +32,5 @@ These APIs decouple Envoy from platform-specific nuances, simplifying the
design and increasing portability across platforms.
Operators can specify high-level traffic management rules through
-[Pilot's Rules API]({{home}}/docs/reference/config/istio.routing.v1alpha1.html). These rules are translated into low-level
+[Pilot's Rules API](/docs/reference/config/istio.routing.v1alpha1/). These rules are translated into low-level
configurations and distributed to Envoy instances via the discovery API.
diff --git a/content/docs/concepts/traffic-management/request-routing.md b/content/docs/concepts/traffic-management/request-routing.md
index 25119a9328..048752ad55 100644
--- a/content/docs/concepts/traffic-management/request-routing.md
+++ b/content/docs/concepts/traffic-management/request-routing.md
@@ -1,17 +1,14 @@
---
title: Request Routing
description: Describes how requests are routed between services in an Istio service mesh.
-
weight: 20
-
---
-{% include home.html %}
This page describes how requests are routed between services in an Istio service mesh.
## Service model and service versions
-As described in [Pilot](./pilot.html), the canonical representation
+As described in [Pilot](/docs/concepts/traffic-management/pilot/), the canonical representation
of services in a particular mesh is maintained by Pilot. The Istio
model of a service is independent of how it is represented in the underlying
platform (Kubernetes, Mesos, Cloud Foundry,
@@ -25,16 +22,16 @@ way to subdivide service instances by versions (`v1`, `v2`) or environment
versions: they could be iterative changes to the same service, deployed in
different environments (prod, staging, dev, etc.). Common scenarios where
this is used include A/B testing or canary rollouts. Istio's [traffic
-routing rules](./rules-configuration.html) can refer to service versions to provide
+routing rules](/docs/concepts/traffic-management/rules-configuration/) can refer to service versions to provide
additional control over traffic between services.
## Communication between services
-{% include image.html width="60%" ratio="100.42%"
- link="./img/pilot/ServiceModel_Versions.svg"
+{{< image width='60%' ratio="100.42%"
+ link="../img/pilot/ServiceModel_Versions.svg"
alt="Showing how service versions are handled."
caption="Service Versions"
- %}
+ >}}
As illustrated in the figure above, clients of a service have no knowledge
of different versions of the service. They can continue to access the
@@ -46,14 +43,14 @@ Envoy determines its actual choice of service version dynamically
based on the routing rules specified by the operator using Pilot. This
model enables the application code to decouple itself from the evolution of its dependent
services, while providing other benefits as well (see
-[Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html)). Routing
+[Mixer](/docs/concepts/policies-and-telemetry/overview/)). Routing
rules allow Envoy to select a version based
on criteria such as headers, tags associated with
source/destination, and/or by weights assigned to each version.
Istio also provides load balancing for traffic to multiple instances of
the same service version. You can find out more about this in [Discovery
-and Load-Balancing](./load-balancing.html).
+and Load-Balancing](/docs/concepts/traffic-management/load-balancing/).
Istio does not provide a DNS. Applications can try to resolve the
FQDN using the DNS service present in the underlying platform (kube-dns,
@@ -70,9 +67,9 @@ via the sidecar Envoy, operators can add failure recovery features such as
timeouts, retries, circuit breakers, etc., and obtain detailed metrics on
the connections to these services.
-{% include image.html width="60%" ratio="28.88%"
- link="./img/pilot/ServiceModel_RequestFlow.svg"
+{{< image width="60%" ratio="28.88%"
+ link="../img/pilot/ServiceModel_RequestFlow.svg"
alt="Ingress and Egress through Envoy."
caption="Request Flow"
- %}
+ >}}
diff --git a/content/docs/concepts/traffic-management/rules-configuration.md b/content/docs/concepts/traffic-management/rules-configuration.md
index e8f3a9e8fe..9fc0d20f19 100644
--- a/content/docs/concepts/traffic-management/rules-configuration.md
+++ b/content/docs/concepts/traffic-management/rules-configuration.md
@@ -1,11 +1,8 @@
---
title: Rules Configuration
description: Provides a high-level overview of the configuration model used by Istio to configure traffic management rules in the service mesh.
-
weight: 50
-
---
-{% include home.html %}
Istio provides a simple configuration model to
control how API calls and layer-4 traffic flow across various
@@ -61,21 +58,21 @@ For example, in a Kubernetes deployment of Istio, "version: v1" indicates that
only pods containing the label "version: v1" will receive traffic.
Rules can be configured using the
-[istioctl CLI]({{home}}/docs/reference/commands/istioctl.html), or in a Kubernetes
+[istioctl CLI](/docs/reference/commands/istioctl/), or in a Kubernetes
deployment using the `kubectl` command instead, although only `istioctl` will
perform model validation and is recommended. See the
-[configuring request routing task]({{home}}/docs/tasks/traffic-management/request-routing.html)
+[configuring request routing task](/docs/tasks/traffic-management/request-routing/)
for examples.
There are four traffic management configuration resources in Istio:
**VirtualService**, **DestinationRule**, **ServiceEntry**, and **Gateway**.
A few important aspects of these resources are described below.
-See [networking reference]({{home}}/docs/reference/config/istio.networking.v1alpha3.html)
+See [networking reference](/docs/reference/config/istio.networking.v1alpha3/)
for detailed information.
## Virtual Services
-A [VirtualService]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#VirtualService)
+A [VirtualService](/docs/reference/config/istio.networking.v1alpha3/#VirtualService)
defines the rules that control how requests for a service are routed within an Istio service mesh.
For example, a virtual service could route requests to different versions of a service or, in fact,
to a completely different service than was requested.
@@ -298,9 +295,9 @@ spec:
```
Note that request timeouts and retries can also be
-[overridden on a per-request basis](./handling-failures.html#fine-tuning).
+[overridden on a per-request basis](/docs/concepts/traffic-management/handling-failures#fine-tuning).
-See the [request timeouts task]({{home}}/docs/tasks/traffic-management/request-timeouts.html) for a demonstration of timeout control.
+See the [request timeouts task](/docs/tasks/traffic-management/request-timeouts/) for a demonstration of timeout control.
### Injecting faults in the request path
@@ -383,7 +380,7 @@ spec:
subset: v1
```
-To see fault injection in action, see the [fault injection task]({{home}}/docs/tasks/traffic-management/fault-injection.html).
+To see fault injection in action, see the [fault injection task](/docs/tasks/traffic-management/fault-injection/).
### HTTP route rules have precedence
@@ -445,7 +442,7 @@ priorities of each rule when there is more than one.
## Destination Rules
-A [DestinationRule]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#DestinationRule)
+A [DestinationRule](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule)
configures the set of policies to be applied to a request after `VirtualService` routing has occurred. They are
intended to be authored by service owners, describing the circuit breakers, load balancer settings, TLS settings, etc..
@@ -506,7 +503,7 @@ spec:
maxConnections: 100
```
-See the [circuit-breaking task]({{home}}/docs/tasks/traffic-management/circuit-breaking.html) for a demonstration of circuit breaker control.
+See the [circuit-breaking task](/docs/tasks/traffic-management/circuit-breaking/) for a demonstration of circuit breaker control.
### DestinationRule evaluation
@@ -599,7 +596,7 @@ start, is generally considered a best practice in Istio.
## Service Entries
-A [ServiceEntry]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#ServiceEntry)
+A [ServiceEntry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry)
is used to add additional entries into the service registry that Istio maintains internally.
It is most commonly used to enable requests to services outside of an Istio service mesh.
For example, the following `ServiceEntry` can be used to allow external calls to services hosted
@@ -663,12 +660,12 @@ timeout and fault injection policies are all supported for external destinations
Weighted (version-based) routing is not possible, however, since there is no notion
of multiple versions of an external service.
-See the [egress task]({{home}}/docs/tasks/traffic-management/egress.html) for a more
+See the [egress task](/docs/tasks/traffic-management/egress/) for a more
about accessing external services.
## Gateways
-A [Gateway]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#Gateway)
+A [Gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
configure a load balancer for HTTP/TCP traffic, most commonly operating at the edge of the
mesh to enable ingress traffic for an application.
@@ -721,11 +718,11 @@ spec:
...
```
-See the [ingress task]({{home}}/docs/tasks/traffic-management/ingress.html) for a
+See the [ingress task](/docs/tasks/traffic-management/ingress/) for a
complete ingress gateway example.
Although primarily used to manage ingress traffic, a `Gateway` can also be used to model
a purely internal or egress proxy. Irrespective of the location, all gateways
can be configured and controlled in the same way. Refer to the
-[gateway reference]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#Gateway)
+[gateway reference](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
for details.
diff --git a/content/docs/concepts/what-is-istio/_index.md b/content/docs/concepts/what-is-istio/_index.md
index 300b912a04..f4789e7e4e 100644
--- a/content/docs/concepts/what-is-istio/_index.md
+++ b/content/docs/concepts/what-is-istio/_index.md
@@ -1,10 +1,6 @@
---
title: What is Istio?
description: A broad overview of the Istio system.
-
weight: 10
-
-toc: false
+type: section-index
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/concepts/what-is-istio/goals.md b/content/docs/concepts/what-is-istio/goals.md
index 8d055ce6f2..631020f0b1 100644
--- a/content/docs/concepts/what-is-istio/goals.md
+++ b/content/docs/concepts/what-is-istio/goals.md
@@ -1,9 +1,7 @@
---
title: Design Goals
description: Describes the core principles that Istio's design adheres to.
-
weight: 20
-
---
This page outlines the core principles that guide Istio's design.
diff --git a/content/docs/concepts/what-is-istio/overview.md b/content/docs/concepts/what-is-istio/overview.md
index e6eacce744..430945d0a8 100644
--- a/content/docs/concepts/what-is-istio/overview.md
+++ b/content/docs/concepts/what-is-istio/overview.md
@@ -1,17 +1,14 @@
---
title: Overview
description: Provides a conceptual introduction to Istio, including the problems it solves and its high-level architecture.
-
weight: 15
-
---
-{% include home.html %}
This document introduces Istio: an open platform to connect, manage, and secure microservices. Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured and managed using Istio's control plane functionality.
Istio currently supports service deployment on Kubernetes, as well as services registered with Consul or Eureka and services running on individual VMs.
-For detailed conceptual information about Istio components see our other [Concepts]({{home}}/docs/concepts/) guides.
+For detailed conceptual information about Istio components see our other [Concepts](/docs/concepts/) guides.
## Why use Istio?
@@ -60,11 +57,11 @@ configuring proxies to route traffic, and configuring Mixers to enforce policies
The following diagram shows the different components that make up each plane:
-{% include image.html width="80%" ratio="56.25%"
- link="./img/overview/arch.svg"
+{{< image width="80%" ratio="56.25%"
+ link="../img/overview/arch.svg"
alt="The overall architecture of an Istio-based application."
caption="Istio Architecture"
- %}
+ >}}
### Envoy
@@ -72,17 +69,17 @@ Istio uses an extended version of the [Envoy](https://envoyproxy.github.io/envoy
Istio leverages Envoy’s many built-in features such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers,
health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics.
-Envoy is deployed as a **sidecar** to the relevant service in the same Kubernetes pod. This allows Istio to extract a wealth of signals about traffic behavior as [attributes]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes), which in turn it can use in [Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html) to enforce policy decisions, and be sent to monitoring systems to provide information about the behavior of the entire mesh. The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code. You can read more about why we chose this approach in our [Design Goals]({{home}}/docs/concepts/what-is-istio/goals.html).
+Envoy is deployed as a **sidecar** to the relevant service in the same Kubernetes pod. This allows Istio to extract a wealth of signals about traffic behavior as [attributes](/docs/concepts/policies-and-telemetry/config/#attributes), which in turn it can use in [Mixer](/docs/concepts/policies-and-telemetry/overview/) to enforce policy decisions, and be sent to monitoring systems to provide information about the behavior of the entire mesh. The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code. You can read more about why we chose this approach in our [Design Goals](/docs/concepts/what-is-istio/goals/).
### Mixer
-[Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html) is a platform-independent component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other
-services. The proxy extracts request level [attributes]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes), which are sent to Mixer for evaluation. More information on this attribute extraction and policy
-evaluation can be found in [Mixer Configuration]({{home}}/docs/concepts/policies-and-telemetry/config.html). Mixer includes a flexible plugin model enabling it to interface with a variety of host environments and infrastructure backends, abstracting the Envoy proxy and Istio-managed services from these details.
+[Mixer](/docs/concepts/policies-and-telemetry/overview/) is a platform-independent component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other
+services. The proxy extracts request level [attributes](/docs/concepts/policies-and-telemetry/config/#attributes), which are sent to Mixer for evaluation. More information on this attribute extraction and policy
+evaluation can be found in [Mixer Configuration](/docs/concepts/policies-and-telemetry/config/). Mixer includes a flexible plugin model enabling it to interface with a variety of host environments and infrastructure backends, abstracting the Envoy proxy and Istio-managed services from these details.
### Pilot
-[Pilot]({{home}}/docs/concepts/traffic-management/pilot.html) provides
+[Pilot](/docs/concepts/traffic-management/pilot/) provides
service discovery for the Envoy sidecars, traffic management capabilities
for intelligent routing (e.g., A/B tests, canary deployments, etc.),
and resiliency (timeouts, retries, circuit breakers, etc.). It converts
@@ -97,17 +94,17 @@ interface for traffic management.
### Citadel
-[Citadel]({{home}}/docs/concepts/security/) provides strong service-to-service and end-user authentication, with built-in identity and
+[Citadel](/docs/concepts/security/) provides strong service-to-service and end-user authentication, with built-in identity and
credential management. It can be used to upgrade unencrypted traffic in the service mesh, and provides operators the ability to enforce
policy based on service identity rather than network controls. Starting from release 0.5, Istio supports
-[role-based access control]({{home}}/docs/concepts/security/rbac.html) to control who can access your services.
+[role-based access control](/docs/concepts/security/rbac/) to control who can access your services.
## What's next
-- Learn about Istio's [design goals]({{home}}/docs/concepts/what-is-istio/goals.html).
+- Learn about Istio's [design goals](/docs/concepts/what-is-istio/goals/).
-- Explore our [Guides]({{home}}/docs/guides/).
+- Explore our [Guides](/docs/guides/).
-- Read about Istio components in detail in our other [Concepts]({{home}}/docs/concepts/) guides.
+- Read about Istio components in detail in our other [Concepts](/docs/concepts/) guides.
-- Learn how to deploy Istio with your own services using our [Tasks]({{home}}/docs/tasks/) guides.
+- Learn how to deploy Istio with your own services using our [Tasks](/docs/tasks/) guides.
diff --git a/content/docs/guides/_index.md b/content/docs/guides/_index.md
index 338bed3fcb..16f326763f 100644
--- a/content/docs/guides/_index.md
+++ b/content/docs/guides/_index.md
@@ -2,9 +2,7 @@
title: Guides
description: Guides include a variety of fully working example uses for Istio that you can experiment with.
weight: 30
-toc: false
-redirect_from:
+type: section-index
+aliases:
/docs/samples/index.html
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/guides/bookinfo.md b/content/docs/guides/bookinfo.md
index c88209d237..f93f84b00b 100644
--- a/content/docs/guides/bookinfo.md
+++ b/content/docs/guides/bookinfo.md
@@ -2,12 +2,11 @@
title: Bookinfo Sample Application
description: This guide deploys a sample application composed of four separate microservices which will be used to demonstrate various features of the Istio service mesh.
weight: 10
-redirect_from:
+aliases:
- /docs/samples/bookinfo.html
---
-{% include home.html %}
-> Note: This guide assumes you will be using the new [v1alpha3 traffic management API]({{home}}/blog/2018/v1alpha3-routing.html).
+> Note: This guide assumes you will be using the new [v1alpha3 traffic management API](/blog/2018/v1alpha3-routing/).
The old API has been deprecated and will be removed in the next Istio release.
If you need to use the old version, you can follow the old instructions [here](https://archive.istio.io/v0.6/docs/guides/bookinfo.html),
but note that on Kubernetes you will need to run an additional command (`kubectl apply -f samples/bookinfo/kube/bookinfo-gateway.yaml`)
@@ -38,10 +37,10 @@ There are 3 versions of the reviews microservice:
The end-to-end architecture of the application is shown below.
-{% include image.html width="80%" ratio="68.52%"
- link="./img/bookinfo/noistio.svg"
+{{< image width="80%" ratio="68.52%"
+ link="../img/bookinfo/noistio.svg"
caption="Bookinfo Application without Istio"
- %}
+ >}}
This application is polyglot, i.e., the microservices are written in different languages.
It’s worth noting that these services have no dependencies on Istio, but make an interesting
@@ -51,7 +50,7 @@ for the reviews service.
## Before you begin
If you haven't already done so, setup Istio by following the instructions
-corresponding to your platform [installation guide]({{home}}/docs/setup/).
+corresponding to your platform [installation guide](/docs/setup/).
## Deploying the application
@@ -61,10 +60,10 @@ Istio-enabled environment, with Envoy sidecars injected along side each service.
The needed commands and configuration vary depending on the runtime environment
although in all cases the resulting deployment will look like this:
-{% include image.html width="80%" ratio="59.08%"
- link="./img/bookinfo/withistio.svg"
+{{< image width="80%" ratio="59.08%"
+ link="../img/bookinfo/withistio.svg"
caption="Bookinfo Application"
- %}
+ >}}
All of the microservices will be packaged with an Envoy sidecar that intercepts incoming
and outgoing calls for the services, providing the hooks needed to externally control,
@@ -81,7 +80,7 @@ To start the application, follow the instructions below corresponding to your Is
1. Bring up the application containers:
- * If you are using [manual sidecar injection]({{home}}/docs/setup/kubernetes/sidecar-injection.html#manual-sidecar-injection),
+ * If you are using [manual sidecar injection](/docs/setup/kubernetes/sidecar-injection/#manual-sidecar-injection),
use the following command
```command
@@ -89,10 +88,10 @@ To start the application, follow the instructions below corresponding to your Is
```
The `istioctl kube-inject` command is used to manually modify the `bookinfo.yaml`
- file before creating the deployments as documented [here]({{home}}/docs/reference/commands/istioctl.html#istioctl kube-inject).
+ file before creating the deployments as documented [here](/docs/reference/commands/istioctl/#istioctl kube-inject).
* If you are using a cluster with
- [automatic sidecar injection]({{home}}/docs/setup/kubernetes/sidecar-injection.html#automatic-sidecar-injection)
+ [automatic sidecar injection](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection)
enabled, simply deploy the services using `kubectl`
```command
@@ -138,7 +137,7 @@ To start the application, follow the instructions below corresponding to your Is
#### Determining the ingress IP and port
-Follow [the instructions]({{home}}/docs/tasks/traffic-management/ingress.html#determining-the-ingress-ip-and-ports) to set the `INGRESS_HOST` and `INGRESS_PORT` variables. Set `GATEWAY_URL`:
+Follow [the instructions](/docs/tasks/traffic-management/ingress/#determining-the-ingress-ip-and-ports) to set the `INGRESS_HOST` and `INGRESS_PORT` variables. Set `GATEWAY_URL`:
```command
$ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
@@ -195,8 +194,8 @@ version routing.
You can now use this sample to experiment with Istio's features for
traffic routing, fault injection, rate limiting, etc..
-To proceed, refer to one or more of the [Istio Guides]({{home}}/docs/guides),
-depending on your interest. [Intelligent Routing]({{home}}/docs/guides/intelligent-routing.html)
+To proceed, refer to one or more of the [Istio Guides](/docs/guides),
+depending on your interest. [Intelligent Routing](/docs/guides/intelligent-routing/)
is a good place to start for beginners.
## Cleanup
diff --git a/content/docs/guides/endpoints.md b/content/docs/guides/endpoints.md
index 4bb525b25f..c68cfdc399 100644
--- a/content/docs/guides/endpoints.md
+++ b/content/docs/guides/endpoints.md
@@ -1,10 +1,8 @@
---
title: Install Istio for Google Cloud Endpoints Services
description: Explains how to manually integrate Google Cloud Endpoints services with Istio.
-
weight: 42
---
-{% include home.html %}
This document shows how to manually integrate Istio with existing
Google Cloud Endpoints services.
@@ -21,12 +19,12 @@ You may test the service using the following command:
$ curl --request POST --header "content-type:application/json" --data '{"message":"hello world"}' "http://${EXTERNAL_IP}:80/echo?key=${ENDPOINTS_KEY}"
```
-You need to install Istio with [instructions]({{home}}/docs/setup/kubernetes/quick-start.html#google-kubernetes-engine).
+You need to install Istio with [instructions](/docs/setup/kubernetes/quick-start/#google-kubernetes-engine).
## HTTP Endpoints service
1. Inject the service into the mesh using `--includeIPRanges` by following the
-[instructions]({{home}}/docs/tasks/traffic-management/egress.html#calling-external-services-directly)
+[instructions](/docs/tasks/traffic-management/egress/#calling-external-services-directly)
so that Egress is allowed to call external services directly.
Otherwise, ESP won't be able to access Google cloud service control.
@@ -53,7 +51,7 @@ Otherwise, ESP won't be able to access Google cloud service control.
EOF
```
-1. Get the Ingress IP through [instructions]({{home}}/docs/tasks/traffic-management/ingress.html#verifying-the-gateway-for-http).
+1. Get the Ingress IP through [instructions](/docs/tasks/traffic-management/ingress/#verifying-the-gateway-for-http).
You can verify accessing the Endpoints service through Ingress:
```command
@@ -89,7 +87,7 @@ Adding `"--http_port=8081"` in the ESP deployment arguments and expose the HTTP
1. After this, you will find access to `EXTERNAL_IP` no longer works because istio proxy only accept secure mesh connections.
Accessing through Ingress works because Ingress does HTTP terminations.
-1. To secure the access at Ingress, following the [instructions]({{home}}/docs/tasks/traffic-management/ingress.html#add-a-secure-port-https-to-our-gateway).
+1. To secure the access at Ingress, following the [instructions](/docs/tasks/traffic-management/ingress/#add-a-secure-port-https-to-our-gateway).
1. You can verify accessing the Endpoints service through secure Ingress:
@@ -111,7 +109,7 @@ This solution uses Istio proxy for TCP bypassing. The traffic is secured through
```
1. Update the mesh service deployment. See further readings on port naming rules
-[here]({{home}}/docs/setup/kubernetes/sidecar-injection.html#pod-spec-requirements).
+[here](/docs/setup/kubernetes/sidecar-injection/#pod-spec-requirements).
1. You can verify access to the Endpoints service through secure Ingress:
diff --git a/content/docs/guides/integrating-vms.md b/content/docs/guides/integrating-vms.md
index 5aabcfa639..fd789017de 100644
--- a/content/docs/guides/integrating-vms.md
+++ b/content/docs/guides/integrating-vms.md
@@ -1,10 +1,8 @@
---
title: Integrating Virtual Machines
description: This sample deploys the Bookinfo services across Kubernetes and a set of virtual machines, and illustrates how to use the Istio service mesh to control this infrastructure as a single mesh.
-
weight: 60
---
-{% include home.html %}
This sample deploys the Bookinfo services across Kubernetes and a set of
Virtual Machines, and illustrates how to use Istio service mesh to control
@@ -16,21 +14,21 @@ VMs cannot initiate any direct communication to Kubernetes Pods even when using
## Overview
-{% include image.html width="80%" ratio="56.78%"
- link="./img/mesh-expansion.svg"
+{{< image width="80%" ratio="56.78%"
+ link="../img/mesh-expansion.svg"
caption="Bookinfo Application with Istio Mesh Expansion"
- %}
+ >}}
## Before you begin
* Setup Istio by following the instructions in the
- [Installation guide]({{home}}/docs/setup/kubernetes/quick-start.html).
+ [Installation guide](/docs/setup/kubernetes/quick-start/).
-* Deploy the [Bookinfo]({{home}}/docs/guides/bookinfo.html) sample application (in the `bookinfo` namespace).
+* Deploy the [Bookinfo](/docs/guides/bookinfo/) sample application (in the `bookinfo` namespace).
-* Create a VM named 'vm-1' in the same project as Istio cluster, and [Join the Mesh]({{home}}/docs/setup/kubernetes/mesh-expansion.html).
+* Create a VM named 'vm-1' in the same project as Istio cluster, and [Join the Mesh](/docs/setup/kubernetes/mesh-expansion/).
## Running MySQL on the VM
diff --git a/content/docs/guides/intelligent-routing.md b/content/docs/guides/intelligent-routing.md
index 5c6f391bc7..4f704d1d39 100644
--- a/content/docs/guides/intelligent-routing.md
+++ b/content/docs/guides/intelligent-routing.md
@@ -1,10 +1,8 @@
---
title: Intelligent Routing
description: This guide demonstrates how to use various traffic management capabilities of an Istio service mesh.
-
weight: 20
---
-{% include home.html %}
This guide demonstrates how to use various traffic management capabilities
of an Istio service mesh.
@@ -16,32 +14,32 @@ to externally control service monitoring and tracing, request (version) routing,
security and policy enforcement, etc., in a consistent way across the services,
for the application as a whole.
-In this guide, we will use the [Bookinfo sample application]({{home}}/docs/guides/bookinfo.html)
+In this guide, we will use the [Bookinfo sample application](/docs/guides/bookinfo/)
to show how operators can dynamically configure request routing and fault injection
for a running application.
## Before you begin
* Install the Istio control plane by following the instructions
- corresponding to your platform [installation guide]({{home}}/docs/setup/).
+ corresponding to your platform [installation guide](/docs/setup/).
* Run the Bookinfo sample application by following the applicable
- [application deployment instructions]({{home}}/docs/guides/bookinfo.html#deploying-the-application).
+ [application deployment instructions](/docs/guides/bookinfo/#deploying-the-application).
## Tasks
-1. [Request routing]({{home}}/docs/tasks/traffic-management/request-routing.html) This task will first
+1. [Request routing](/docs/tasks/traffic-management/request-routing/) This task will first
direct all incoming traffic for the Bookinfo application to the v1 version of the
`reviews` service. It will then send traffic only from a specific test user to version v2,
leaving all other users unaffected.
-1. [Fault injection]({{home}}/docs/tasks/traffic-management/fault-injection.html) We will now use Istio to
+1. [Fault injection](/docs/tasks/traffic-management/fault-injection/) We will now use Istio to
test the resiliency of the Bookinfo application by injecting an artificial delay in
requests between the `reviews:v2` and `ratings` services. Observing the resulting behavior
as the test user, we will notice that the v2 version of the `reviews` service has a bug.
Note that all other users are unaware of this testing against the live system.
-1. [Traffic Shifting]({{home}}/docs/tasks/traffic-management/traffic-shifting.html) Finally, we will
+1. [Traffic Shifting](/docs/tasks/traffic-management/traffic-shifting/) Finally, we will
use Istio to gradually migrate traffic for all users from to a v3 version of
the `reviews` service, one which includes the fix for the bug discovered in v2.
@@ -49,5 +47,5 @@ for a running application.
When you're finished experimenting with the Bookinfo sample, you can
uninstall it by following the
-[Bookinfo cleanup instructions]({{home}}/docs/guides/bookinfo.html#cleanup)
+[Bookinfo cleanup instructions](/docs/guides/bookinfo/#cleanup)
corresponding to your environment.
diff --git a/content/docs/guides/policy-enforcement.md b/content/docs/guides/policy-enforcement.md
deleted file mode 100644
index 68d30b2e66..0000000000
--- a/content/docs/guides/policy-enforcement.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Policy Enforcement
-description: This sample uses the Bookinfo application to demonstrate policy enforcement using Istio Mixer.
-
-weight: 40
-draft: true
----
-{% include home.html %}
-
-This sample uses the Bookinfo application to demonstrate policy enforcement using Istio Mixer.
-
-## Overview
-
-Provide a high level overview of what users can expect to learn, why these
-features are important, and so on. This is not a task, but a feature of
-Istio.
-
-## Before you begin
-
-* Describe installation options.
-
-* Install Istio control plane in a Kubernetes cluster by following the quick start instructions in the
-[Installation guide]({{home}}/docs/setup/kubernetes/quick-start.html).
-
-## Application Setup
-
-1. Steps
-
-## Tasks
-
-1. some tasks that will complete the goal of this sample.
diff --git a/content/docs/guides/security.md b/content/docs/guides/security.md
deleted file mode 100644
index 2af8822707..0000000000
--- a/content/docs/guides/security.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Security
-description: This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
-
-weight: 30
-draft: true
----
-{% include home.html %}
-
-This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
-
-## Overview
-
-Placeholder.
-
-## Before you begin
-
-* Describe installation options.
-
-* Install Istio control plane in a Kubernetes cluster by following the quick start instructions in the
-[Installation guide]({{home}}/docs/setup/kubernetes/quick-start.html).
-
-## Application Setup
-
-1. Steps
-
-## Tasks
-
-1. some tasks that will complete the goal of this sample.
diff --git a/content/docs/guides/telemetry.md b/content/docs/guides/telemetry.md
index 7076c39a32..0a45e34d27 100644
--- a/content/docs/guides/telemetry.md
+++ b/content/docs/guides/telemetry.md
@@ -1,10 +1,8 @@
---
title: In-Depth Telemetry
description: This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
-
weight: 30
---
-{% include home.html %}
This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
@@ -15,7 +13,7 @@ to externally control service monitoring and tracing, request (version) routing,
security and policy enforcement, etc., in a consistent way across the services,
for the application as a whole.
-In this guide, we will use the [Bookinfo sample application]({{home}}/docs/guides/bookinfo.html)
+In this guide, we will use the [Bookinfo sample application](/docs/guides/bookinfo/)
to show how operators can obtain uniform metrics and traces from running
applications involving diverse language frameworks without relying on
developers to manually instrument their applications.
@@ -23,22 +21,22 @@ developers to manually instrument their applications.
## Before you begin
* Install the Istio control plane by following the instructions
- corresponding to your platform [installation guide]({{home}}/docs/setup/).
+ corresponding to your platform [installation guide](/docs/setup/).
* Run the Bookinfo sample application by following the applicable
- [application deployment instructions]({{home}}/docs/guides/bookinfo.html#deploying-the-application).
+ [application deployment instructions](/docs/guides/bookinfo/#deploying-the-application).
## Tasks
-1. [Collecting metrics]({{home}}/docs/tasks/telemetry/metrics-logs.html)
+1. [Collecting metrics](/docs/tasks/telemetry/metrics-logs/)
This task will configure Mixer to collect a uniform set of metrics
across all services in the Bookinfo application.
-1. [Querying metrics]({{home}}/docs/tasks/telemetry/querying-metrics.html)
+1. [Querying metrics](/docs/tasks/telemetry/querying-metrics/)
This task installs the Prometheus add-on for metrics collection and
demonstrates querying a configured Prometheus server for Istio metrics.
-1. [Distributed tracing]({{home}}/docs/tasks/telemetry/distributed-tracing.html)
+1. [Distributed tracing](/docs/tasks/telemetry/distributed-tracing/)
We will now use Istio to trace how requests are flowing across services
in the application. Distributed tracing speeds up troubleshooting by
allowing developers to quickly understand how different services
@@ -46,7 +44,7 @@ developers to manually instrument their applications.
can be a valuable tool to diagnosis and troubleshooting in distributed
applications.
-1. [Using the Istio Dashboard]({{home}}/docs/tasks/telemetry/using-istio-dashboard.html)
+1. [Using the Istio Dashboard](/docs/tasks/telemetry/using-istio-dashboard/)
This task installs the Grafana add-on with a preconfigured dashboard
for monitoring mesh traffic.
@@ -54,5 +52,5 @@ developers to manually instrument their applications.
When you're finished experimenting with the Bookinfo sample, you can
uninstall it by following the
-[Bookinfo cleanup instructions]({{home}}/docs/guides/bookinfo.html#cleanup)
+[Bookinfo cleanup instructions](/docs/guides/bookinfo/#cleanup)
corresponding to your environment.
diff --git a/content/docs/guides/using-external-services.md b/content/docs/guides/using-external-services.md
deleted file mode 100644
index cd3f9692d7..0000000000
--- a/content/docs/guides/using-external-services.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Integrating with External Services
-description: This sample integrates third party services with Bookinfo and demonstrates how to use Istio service mesh to provide metrics, and routing functions for these services.
-
-weight: 50
-draft: true
----
-{% include home.html %}
-
-This sample integrates third party services with Bookinfo and demonstrates how to use Istio service mesh to provide metrics, and routing functions for these services.
-
-## Overview
-
-Placeholder.
-
-## Application Setup
-
-1. Steps
-
-## Tasks
-
-1. some tasks that will complete the goal of this sample.
diff --git a/content/docs/reference/_index.md b/content/docs/reference/_index.md
index 24ffc2e4d7..a27e5ceb4b 100644
--- a/content/docs/reference/_index.md
+++ b/content/docs/reference/_index.md
@@ -1,11 +1,6 @@
---
title: Reference
description: The Reference section contains detailed authoritative reference material such as command-line options, configuration options, and API calling parameters.
-index: true
-
weight: 60
-
-toc: false
+type: section-index
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/reference/commands/_index.md b/content/docs/reference/commands/_index.md
index 291b1d442c..ead44a3359 100644
--- a/content/docs/reference/commands/_index.md
+++ b/content/docs/reference/commands/_index.md
@@ -1,11 +1,6 @@
---
title: Commands
description: Describes usage and options of the Istio commands and utilities.
-
weight: 30
-
-toc: false
+type: section-index
---
-
-{% include section-index.html docs=site.docs %}
-
diff --git a/content/docs/reference/config/_index.md b/content/docs/reference/config/_index.md
index 41e416737f..b5ace758f5 100644
--- a/content/docs/reference/config/_index.md
+++ b/content/docs/reference/config/_index.md
@@ -1,10 +1,6 @@
---
title: Configuration
description: Detailed information on configuration options.
-
weight: 20
-
-toc: false
+type: section-index
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/reference/config/policy-and-telemetry/_index.md b/content/docs/reference/config/policy-and-telemetry/_index.md
index 357231f9c2..98e2b018a9 100644
--- a/content/docs/reference/config/policy-and-telemetry/_index.md
+++ b/content/docs/reference/config/policy-and-telemetry/_index.md
@@ -2,8 +2,7 @@
title: Policies and Telemetry
description: Describes how to configure Istio's policy and telemetry features.
weight: 30
-redirect_from:
+type: section-index
+aliases:
- /docs/reference/config/mixer/index.html
---
-
-{% include section-index.html docs=site.docs %}
diff --git a/content/docs/reference/config/policy-and-telemetry/adapters/_index.md b/content/docs/reference/config/policy-and-telemetry/adapters/_index.md
index f4aa5a2d2f..1720f5ff40 100644
--- a/content/docs/reference/config/policy-and-telemetry/adapters/_index.md
+++ b/content/docs/reference/config/policy-and-telemetry/adapters/_index.md
@@ -1,13 +1,9 @@
---
title: Adapters
description: Mixer adapters allow Istio to interface to a variety of infrastructure backends for such things as metrics and logs.
-
weight: 40
-
-toc: false
+type: section-index
---
-{% include section-index.html docs=site.docs %}
-
To implement a new adapter for Mixer, please refer to the
[Adapter Developer's Guide](https://github.com/istio/istio/wiki/Mixer-Adapter-Dev-Guide).
diff --git a/content/docs/reference/config/policy-and-telemetry/adapters/circonus.html b/content/docs/reference/config/policy-and-telemetry/adapters/circonus.html
index 08dc2507a1..a5f3acd63d 100644
--- a/content/docs/reference/config/policy-and-telemetry/adapters/circonus.html
+++ b/content/docs/reference/config/policy-and-telemetry/adapters/circonus.html
@@ -10,7 +10,7 @@ number_of_entries: 3
The This adapter supports the metric template. +This adapter supports the metric template. ParamsTo activate the CloudWatch adapter, operators need to provide configuration for the -cloudwatch adapter. +cloudwatch adapter.The handler configuration must contain the same metrics as the instance configuration. The metrics specified in both instance and handler configurations will be sent to CloudWatch. -This adapter supports the metric template. +This adapter supports the metric template. ParamsThe This adapter supports the metric template. +This adapter supports the metric template. ParamsThe This adapter supports the checknothing template, -the listentry template, -and the quota template. +This adapter supports the checknothing template, +the listentry template, +and the quota template. ParamsThe This adapter supports the logentry template. +This adapter supports the logentry template. ParamsThe This adapter supports the kubernetesenv template. +This adapter supports the kubernetesenv template. ParamsThis adapter supports the listentry template. +This adapter supports the listentry template. ParamsThis adapter supports the quota template. +This adapter supports the quota template. ParamsThe This adapter supports the authorization template. +This adapter supports the authorization template. ParamsThe This adapter supports the authorization template. +This adapter supports the authorization template. ParamsThe This adapter supports the quota template. +This adapter supports the quota template. ParamsThe This adapter supports the servicecontrolreport template, -the quota template, -and the apikey template. +This adapter supports the servicecontrolreport template, +the quota template, +and the apikey template. GcpServiceSettingThis adapter supports the metric template -and the logentry template. +This adapter supports the metric template +and the logentry template. ParamsThe This adapter supports the metric template, -and the logentry template. +This adapter supports the metric template, +and the logentry template. ParamsThe This adapter supports the metric template. +This adapter supports the metric template. ParamsThis adapter supports the logentry template. -and the metric template. +This adapter supports the logentry template. +and the metric template. ParamsThe Example config: @@ -27,8 +27,8 @@ spec: within a list.When writing the configuration, the value for the fields associated with this template can either be a -literal or an expression. Please note that if the datatype of a field is not istio.mixer.adapter.model.v1beta1.Value, -then the expression’s inferred type must match the datatype of the field. +literal or an expression. Please note that if the datatype of a field is not istio.mixer.adapter.model.v1beta1.Value, +then the expression’s inferred type must match the datatype of the field. |