First pass at refactoring file locations.

This also reenables html proofing, which I accidentally left
off in an earlier commit.

content/about/notes/0.2/index.md

@@ -21,7 +21,7 @@ this feature and has some limitations (such as requiring a flat network across c
 including Consul and Eureka.
 
 - **Automatic injection of sidecars**. Istio sidecar can automatically be injected into a Pod upon deployment using the
-[Initializers](https://kubernetes.io/docs/admin/extensible-admission-controllers/#what-are-initializers) alpha feature in Kubernetes.
+[Initializers](https://kubernetes.io/docs/admin/extensible-admission-controllers/) alpha feature in Kubernetes.
 
 ## Performance and quality
 

content/blog/2017/0.1-announcement/index.md

@@ -33,12 +33,12 @@ Google, IBM and Lyft joined forces to create Istio from a desire to provide a re
 **Fleet-wide Visibility**: Failures happen, and operators need tools to stay on top of the health of clusters and their graphs of microservices. Istio produces detailed monitoring data about application and network behaviors that is rendered using [Prometheus](https://prometheus.io/) & [Grafana](https://github.com/grafana/grafana), and can be easily extended to send metrics and logs to any collection, aggregation and querying system. Istio enables analysis of performance hotspots and diagnosis of distributed failure modes with [Zipkin](https://github.com/openzipkin/zipkin) tracing.
 
 {{< image width="100%" ratio="55.42%"
-    link="../img/istio_grafana_dashboard-new.png"
+    link="./istio_grafana_dashboard-new.png"
     caption="Grafana Dashboard with Response Size"
     >}}
 
 {{< image width="100%" ratio="29.91%"
-    link="../img/istio_zipkin_dashboard.png"
+    link="./istio_zipkin_dashboard.png"
     caption="Zipkin Dashboard"
     >}}
 

content/blog/2017/0.1-auth/index.md

@@ -42,7 +42,7 @@ Istio Auth is based on industry standards like mutual TLS and X.509. Furthermore
 The diagram below provides an overview of the Istio Auth service authentication architecture on Kubernetes.
 
 {{< image width="100%" ratio="56.25%"
-    link="../img/istio_auth_overview.svg"
+    link="./istio_auth_overview.svg"
     caption="Istio Auth Overview"
     >}}
 
@@ -77,7 +77,7 @@ Istio Auth provides a per-cluster CA (Certificate Authority) and automated key &
 The following diagram explains the end to end Istio Auth authentication workflow on Kubernetes:
 
 {{< image width="100%" ratio="56.25%"
-    link="../img/istio_auth_workflow.svg"
+    link="./istio_auth_workflow.svg"
     caption="Istio Auth Workflow"
     >}}
 

content/blog/2017/0.2-announcement/index.md

@@ -23,7 +23,7 @@ Today we are happy to announce the 0.2 release which improves stability and perf
 * _Policy and security for TCP services_: In addition to HTTP, we have added transparent mutual TLS authentication and policy enforcement for TCP services as well. This will allow you to secure more of your
 Kubernetes deployment, and get Istio features like telemetry, policy and security.
 
-* _Automated sidecar injection_: By leveraging the alpha [initializer](https://kubernetes.io/docs/admin/extensible-admission-controllers/#what-are-initializers) feature provided by Kubernetes 1.7, envoy sidecars can now be automatically injected into application deployments when your cluster has the initializer enabled.  This enables you to deploy microservices using `kubectl`, the exact same command that you normally use for deploying the microservices without Istio.
+* _Automated sidecar injection_: By leveraging the alpha [initializer](https://kubernetes.io/docs/admin/extensible-admission-controllers/) feature provided by Kubernetes 1.7, envoy sidecars can now be automatically injected into application deployments when your cluster has the initializer enabled.  This enables you to deploy microservices using `kubectl`, the exact same command that you normally use for deploying the microservices without Istio.
 
 * _Extending Istio_: An improved Mixer design that lets vendors write Mixer adapters to implement support for their own systems, such as application
 management or policy enforcement. The

content/blog/2017/adapter-model/index.md

@@ -30,7 +30,7 @@ Adapters are Go packages that are directly linked into the Mixer binary. It’s
 Mixer is essentially an attribute processing and routing machine. The proxy sends it [attributes](/docs/concepts/policies-and-telemetry/config/#attributes) as part of doing precondition checks and telemetry reports, which it turns into a series of calls into adapters. The operator supplies configuration which describes how to map incoming attributes to inputs for the adapters.
 
 {{< image width="60%" ratio="42.60%"
-    link="/docs/concepts/policies-and-telemetry/img/machine.svg"
+    link="/docs/concepts/policies-and-telemetry/config/machine.svg"
     caption="Attribute Machine"
     >}}
 

content/blog/2017/mixer-spof-myth/index.md

@@ -35,7 +35,7 @@ In 2014, we started an initiative to create a replacement architecture that woul
 The older system was built around a centralized fleet of fairly heavy proxies into which all incoming traffic would flow, before being forwarded to the services where the real work was done. The newer architecture jettisons the shared proxy design and instead consists of a very lean and efficient distributed sidecar proxy sitting next to service instances, along with a shared fleet of sharded control plane intermediaries:
 
 {{< image width="75%" ratio="74.79%"
-    link="../img/mixer-spof-myth-1.svg"
+    link="./mixer-spof-myth-1.svg"
     title="Google System Topology"
     caption="Google's API & Service Management System"
     >}}
@@ -47,7 +47,7 @@ Look familiar? Of course: it’s just like Istio! Istio was conceived as a secon
 As shown in the diagram below, Mixer sits between the mesh and the infrastructure backends that support it:
 
 {{< image width="75%" ratio="65.89%"
-    link="../img/mixer-spof-myth-2.svg"
+    link="./mixer-spof-myth-2.svg"
     caption="Istio Topology"
     >}}
 

content/blog/2018/aws-nlb/index.md

@@ -25,14 +25,14 @@ You need to apply policy on the master role in order to be able to provision net
 1. In AWS `iam` console click on policies and click on create a new one:
 
     {{< image width="80%" ratio="60%"
-    link="../img/createpolicystart.png"
+    link="./createpolicystart.png"
     caption="Create a new policy"
     >}}
 
 1. Select `json`:
 
     {{< image width="80%" ratio="60%"
-    link="../img/createpolicyjson.png"
+    link="./createpolicyjson.png"
     caption="Select json"
     >}}
 
@@ -80,14 +80,14 @@ You need to apply policy on the master role in order to be able to provision net
 1. Click review policy, fill all fields and click create policy:
 
     {{< image width="80%" ratio="60%"
-        link="../img/create_policy.png"
+        link="./create_policy.png"
         caption="Validate policy"
         >}}
 
 1. Click on roles, select you master role nodes, and click attach policy:
 
     {{< image width="100%" ratio="35%"
-    link="../img/roles_summary.png"
+    link="./roles_summary.png"
     caption="Attach policy"
     >}}
 

content/blog/2018/egress-https/index.md

@@ -41,7 +41,7 @@ $ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-det
 The updated architecture of the application now looks as follows:
 
 {{< image width="80%" ratio="65.16%"
-    link="../img/bookinfo-details-v2.svg"
+    link="./bookinfo-details-v2.svg"
     caption="The Bookinfo Application with details V2"
     >}}
 
@@ -70,7 +70,7 @@ Let's access the web page of the application, after [determining the ingress IP
 Oops... Instead of the book details we have the _Error fetching product details_ message displayed:
 
 {{< image width="80%" ratio="36.01%"
-    link="../img/errorFetchingBookDetails.png"
+    link="./errorFetchingBookDetails.png"
     caption="The Error Fetching Product Details Message"
     >}}
 
@@ -101,7 +101,7 @@ EOF
 Now accessing the web page of the application displays the book details without error:
 
 {{< image width="80%" ratio="34.82%"
-    link="../img/externalBookDetails.png"
+    link="./externalBookDetails.png"
     caption="Book Details Displayed Correctly"
     >}}
 
@@ -137,7 +137,7 @@ The diagram below shows how the HTTPS traffic to external services is performed.
 sends regular HTTPS requests, encrypted end-to-end. On the bottom, the same microservice inside an Istio service mesh must send unencrypted HTTP requests inside a pod, which are intercepted by the sidecar Envoy proxy. The sidecar proxy performs TLS origination, so the traffic between the pod and the external service is encrypted.
 
 {{< image width="80%" ratio="65.16%"
-    link="../img/https_from_the_app.svg"
+    link="./https_from_the_app.svg"
     caption="HTTPS traffic to external services, from outside vs. from inside an Istio service mesh"
     >}}
 

content/blog/2018/egress-tcp/index.md

@@ -167,7 +167,7 @@ service. In addition, I route all the traffic destined to the _ratings_ service
 The updated architecture appears below. Note that the blue arrows inside the mesh mark the traffic configured according to the route rules we added. According to the route rules, the traffic is sent to _reviews v3_ and _ratings v2-mysql_.
 
 {{< image width="80%" ratio="59.31%"
-    link="../img/bookinfo-ratings-v2-mysql-external.svg"
+    link="./bookinfo-ratings-v2-mysql-external.svg"
     caption="The Bookinfo application with ratings v2-mysql and an external MySQL database"
     >}}
 
@@ -180,7 +180,7 @@ Let's access the webpage of the application, after [determining the ingress IP a
 We have a problem... Instead of the rating stars, the message _"Ratings service is currently unavailable"_ is currently displayed below each review:
 
 {{< image width="80%" ratio="36.19%"
-    link="../img/errorFetchingBookRating.png"
+    link="./errorFetchingBookRating.png"
     caption="The Ratings service error messages"
     >}}
 
@@ -217,7 +217,7 @@ Note that for a TCP egress rule, we specify `tcp` as the protocol of a port of t
 It worked! Accessing the web page of the application displays the ratings without error:
 
 {{< image width="80%" ratio="36.69%"
-    link="../img/externalMySQLRatings.png"
+    link="./externalMySQLRatings.png"
     caption="Book Ratings Displayed Correctly"
     >}}
 

content/blog/2018/export-logs-through-stackdriver/index.md

@@ -29,7 +29,7 @@ contains information like source service, destination service, auth
 metrics (coming..) among others. Following is a diagram of the pipeline:
 
 {{< image width="75%" ratio="75%"
-link="../img/istio-analytics-using-stackdriver.png"
+link="./istio-analytics-using-stackdriver.png"
 caption="Diagram of exporting logs from Istio to StackDriver for analysis" >}}
 
 Istio supports exporting logs to Stackdriver which can be configured to export

content/blog/2018/v1alpha3-routing/index.md

@@ -51,7 +51,7 @@ exiting the mesh may be forced through dedicated egress gateways. The following
 this mental model.
 
 {{< image width="80%" ratio="35.20%"
-    link="../img/gateways.svg"
+    link="./gateways.svg"
     alt="Role of gateways in the mesh"
     caption="Gateways in an Istio service mesh"
     >}}
@@ -73,7 +73,7 @@ The figure below depicts the flow of control across configuration
 resources.
 
 {{< image width="80%" ratio="41.16%"
-    link="../img/virtualservices-destrules.svg"
+    link="./virtualservices-destrules.svg"
     caption="Relationship between different v1alpha3 elements"
     >}}
 

content/docs/concepts/policies-and-telemetry/config/index.md

@@ -42,7 +42,7 @@ around the request. Based on its configuration and the specific set of attribute
 given, Mixer generates calls to a variety of infrastructure backends.
 
 {{< image width="60%" ratio="42.60%"
-    link="../img/machine.svg"
+    link="./machine.svg"
     caption="Attribute Machine"
     >}}
 

content/docs/concepts/policies-and-telemetry/overview/index.md

@@ -26,7 +26,7 @@ control to operators.
 Mixer is the Istio component responsible for providing policy controls and telemetry collection:
 
 {{< image width="75%" ratio="49.26%"
-    link="../img/topology-without-cache.svg"
+    link="./topology-without-cache.svg"
     caption="Mixer Topology"
     >}}
 
@@ -61,7 +61,7 @@ adapters used at runtime is determined through configuration and can easily be
 extended to target new or custom infrastructure backends.
 
 {{< image width="35%" ratio="138%"
-    link="../img/adapters.svg"
+    link="./adapters.svg"
     alt="Showing Mixer with adapters."
     caption="Mixer and its Adapters"
     >}}
@@ -82,7 +82,7 @@ caching and buffering. Mixer, however, lives independently and can use considera
 cache for the sidecars.
 
 {{< image width="75%" ratio="65.89%"
-    link="../img/topology-with-cache.svg"
+    link="./topology-with-cache.svg"
     caption="Mixer Topology"
     >}}
 

content/docs/concepts/security/authn-policy/index.md

@@ -22,7 +22,7 @@ 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.
 
 {{< image width="80%" ratio="75%"
-    link="../img/authn.svg"
+    link="./authn.svg"
     caption="Authentication Policy Architecture"
     >}}
 

content/docs/concepts/security/mutual-tls/index.md

@@ -21,7 +21,7 @@ as the service account 'frontend-team' and service 'backend' running as the serv
 on both Kubernetes containers and VM/bare-metal machines.
 
 {{< image width="80%" ratio="56.25%"
-    link="../img/mutual-tls/auth.svg"
+    link="./auth.svg"
     alt="Components making up the Istio auth model."
     caption="Istio Security Architecture"
     >}}

content/docs/concepts/security/rbac/index.md

@@ -22,7 +22,7 @@ The diagram below shows the Istio RBAC architecture. Operators specify Istio RBA
 the Istio config store.
 
 {{< image width="80%" ratio="56.25%"
-    link="../img/IstioRBAC.svg"
+    link="./IstioRBAC.svg"
     alt="Istio RBAC"
     caption="Istio RBAC Architecture"
     >}}

content/docs/concepts/traffic-management/load-balancing/index.md

@@ -22,7 +22,7 @@ interface. Envoy instances in the mesh perform service discovery and
 dynamically update their load balancing pools accordingly.
 
 {{< image width="80%" ratio="74.79%"
-    link="../img/pilot/LoadBalancing.svg"
+    link="./LoadBalancing.svg"
     caption="Discovery and Load Balancing"
     >}}
 

content/docs/concepts/traffic-management/overview/index.md

@@ -41,7 +41,7 @@ of the size of the canary deployment, or send traffic to a particular version
 depending on the content of the request.
 
 {{< image width="85%" ratio="69.52%"
-    link="../img/pilot/TrafficManagementOverview.svg"
+    link="./TrafficManagementOverview.svg"
     caption="Traffic Management with Istio"
     >}}
 

content/docs/concepts/traffic-management/pilot/index.md

@@ -11,7 +11,7 @@ Pilot is responsible for the lifecycle of Envoy instances deployed
 across the Istio service mesh.
 
 {{< image width="60%" ratio="72.17%"
-    link="../img/pilot/PilotAdapters.svg"
+    link="./PilotAdapters.svg"
     caption="Pilot Architecture"
     >}}
 

content/docs/concepts/traffic-management/request-routing/index.md

@@ -29,7 +29,7 @@ additional control over traffic between services.
 ## Communication between services
 
 {{< image width="60%" ratio="100.42%"
-    link="../img/pilot/ServiceModel_Versions.svg"
+    link="./ServiceModel_Versions.svg"
     alt="Showing how service versions are handled."
     caption="Service Versions"
     >}}
@@ -69,7 +69,7 @@ timeouts, retries, circuit breakers, etc., and obtain detailed metrics on
 the connections to these services.
 
 {{< image width="60%" ratio="28.88%"
-    link="../img/pilot/ServiceModel_RequestFlow.svg"
+    link="./ServiceModel_RequestFlow.svg"
     alt="Ingress and Egress through Envoy."
     caption="Request Flow"
     >}}

content/docs/concepts/what-is-istio/overview/index.md

@@ -58,7 +58,7 @@ configuring proxies to route traffic, and configuring Mixers to enforce policies
 The following diagram shows the different components that make up each plane:
 
 {{< image width="80%" ratio="56.25%"
-    link="../img/overview/arch.svg"
+    link="./arch.svg"
     alt="The overall architecture of an Istio-based application."
     caption="Istio Architecture"
     >}}

content/docs/reference/config/policy-and-telemetry/metrics.md

@@ -14,29 +14,29 @@ We will describe metrics first and then the labels for each metric.
 ## Metrics
 
 *   **Request Count**: This is a `COUNTER`
-    [metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L786:9)
+    `[metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L786:9)`
     incremented for every request handled by an Istio proxy.
 
 *   **Request Duration**: This is a `DISTRIBUTION`
-    [metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L802:9)
+    `[metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L802:9)`
     which measures the duration of the request (as observed by the server-side
     proxy).
 
 *   **Request Size**: This is a `DISTRIBUTION`
-    [metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L818:9)
+    `[metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L818:9)`
     which measures the size of the HTTP request’s body size.
 
 *   **Response Size**: This is a `DISTRIBUTION`
-    [metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L834:9)
+    `[metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L834:9)`
     which measures the size of the HTTP response body size.
 
 *   **Tcp Byte Sent**: This is a `COUNTER`
-    [metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L850:9)
+    `[metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L850:9)`
     which measures the size of total bytes sent during response in case of a TCP
     connection as measured by the server-side proxy.
 
 *   **Tcp Byte Received**: This is a `COUNTER`
-    [metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L867:9)
+    `[metric](https://github.com/istio/istio/blob/{{<branch_name>}}/install/kubernetes/templates/istio-mixer.yaml.tmpl#L867:9)`
     which measures the size of total bytes received during request in case of a
     TCP connection as measured by the server-side proxy.
 

content/help/faq/setup/k8s-checking-cluster-alpha-features.md

@@ -1,17 +0,0 @@
----
-title: Kubernetes - How do I check if my cluster has enabled the alpha features required for automatic sidecar injection?
-weight: 10
----
-
-Automatic sidecar injection requires the
-[initializer alpha feature](https://kubernetes.io/docs/admin/extensible-admission-controllers/#enable-initializers-alpha-feature).
-Run the following command to check if the initializer has been enabled
-(empty output indicates that initializers are not enabled):
-
-```command
-$ kubectl api-versions | grep admissionregistration
-```
-
-In addition, the Kubernetes API server must be started with the Initializer plugin [enabled](https://kubernetes.io/docs/admin/extensible-admission-controllers/#enable-initializers-alpha-feature). Failure to enable the `Initializer` plugin will result in the following error when trying to create the initializer deployment.
-
-> The Deployment "istio-initializer" is invalid: metadata.initializers.pending: Invalid value: "null": must be non-empty when result is not set

content_zh/docs/concepts/traffic-management/overview.md

@@ -17,9 +17,9 @@ Istio 流量管理的核心组件是 [Pilot](/docs/concepts/traffic-management/p
 
 使用 Istio 的流量管理模型，本质上是将流量与基础设施扩容解耦，让运维人员可以通过 Pilot 指定流量遵循什么规则，而不是执行哪些 pod/VM 应该接收流量——Pilot 和智能 Envoy 代理会帮我们搞定。因此，例如，您可以通过 Pilot 指定特定服务的 5％ 流量可以转到金丝雀版本，而不必考虑金丝雀部署的大小，或根据请求的内容将流量发送到特定版本。
 
-{{< image width="85%" ratio="69.52%"
+{{</* image width="85%" ratio="69.52%"
     link="../img/pilot/TrafficManagementOverview.svg"
     caption="Istio 中的流量管理"
-    >}}
+    */>}}
 
 将流量从基础设施扩展中解耦，这样就可以让 Istio 提供各种流量管理功能，这些功能在应用程序代码之外。除了 A/B 测试的动态[请求路由](/docs/concepts/traffic-management/request-routing/)，逐步推出和金丝雀发布之外，它还使用超时、重试和熔断器处理[故障恢复](/docs/concepts/traffic-management/handling-failures/)，最后还可以通过[故障注入](/docs/concepts/traffic-management/fault-injection/)来测试服务之间故障恢复策略的兼容性。这些功能都是通过在服务网格中部署的 Envoy sidecar/代理来实现的。

content_zh/docs/concepts/traffic-management/pilot.md

@@ -9,10 +9,10 @@ aliases:
 
 Pilot 负责部署在 Istio 服务网格中的 Envoy 实例的生命周期管理。
 
-{{< image width="60%" ratio="72.17%"
+{{</* image width="60%" ratio="72.17%"
     link="../img/pilot/PilotAdapters.svg"
     caption="Pilot 架构"
-    >}}
+    */>}}
 
 如上图所示，Pilot 维护了网格中的服务的规范表示，这个表示是独立于底层平台的。Pilot 中的平台特定适配器负责适当填充此规范模型。例如，Pilot 中的 Kubernetes 适配器实现必要的控制器来 watch Kubernetes API server 中 pod 注册信息、ingress 资源以及用于存储流量管理规则的第三方资源的更改。该数据被翻译成规范表示。Envoy 特定配置是基于规范表示生成的。
 

content_zh/docs/concepts/what-is-istio/overview.md

@@ -37,11 +37,11 @@ Istio服务网格逻辑上分为**数据面板**和**控制面板**。
 
 下图显示了构成每个面板的不同组件：
 
-{{< image width="80%" ratio="56.25%"
+{{</* image width="80%" ratio="56.25%"
     link="../img/overview/arch.svg"
     alt="基于 Istio 的应用程序架构概览"
     caption="Istio 架构"
-    >}}
+    */>}}
 
 ### Envoy
 

scripts/lint_site.sh

@@ -23,7 +23,7 @@ then
     FAILED=1
 fi
 
-#htmlproofer ./public --check-html --assume-extension --timeframe 2d --storage-dir .htmlproofer --url-ignore "/localhost/,/github.com/istio/istio.github.io/edit/master/,/github.com/istio/istio/issues/new/choose/"
+htmlproofer ./public --check-html --assume-extension --timeframe 2d --storage-dir .htmlproofer --url-ignore "/localhost/,/github.com/istio/istio.github.io/edit/master/,/github.com/istio/istio/issues/new/choose/"
 if [ "$?" != "0" ]
 then
     FAILED=1