-
+
\ No newline at end of file
diff --git a/content/en/about/community/_index.md b/content/en/about/community/_index.md
index c58255bf2c45..1f48d810900a 100644
--- a/content/en/about/community/_index.md
+++ b/content/en/about/community/_index.md
@@ -2,7 +2,7 @@
title: Our Community
linktitle: Our Community
description: Learn about our community, our customers, and our partners.
-weight: 15
+weight: 5
aliases:
- /community
icon: community
diff --git a/content/en/about/community/customers/coohom.svg b/content/en/about/community/customers/coohom.svg
index 37b2506c2383..056911426eef 100644
--- a/content/en/about/community/customers/coohom.svg
+++ b/content/en/about/community/customers/coohom.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/customers/daocloud.svg b/content/en/about/community/customers/daocloud.svg
new file mode 100644
index 000000000000..4966a045f4cb
--- /dev/null
+++ b/content/en/about/community/customers/daocloud.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/about/community/customers/flexe.svg b/content/en/about/community/customers/flexe.svg
index 1b87ae857213..406d4ab155ce 100644
--- a/content/en/about/community/customers/flexe.svg
+++ b/content/en/about/community/customers/flexe.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/customers/index.md b/content/en/about/community/customers/index.md
index b0b43d24f147..55962355c455 100644
--- a/content/en/about/community/customers/index.md
+++ b/content/en/about/community/customers/index.md
@@ -14,6 +14,7 @@ Tons of people are using Istio. Maybe you should too?
{{< company_logo link="https://www.autotrader.co.uk" logo="./autotrader.uk.svg" alt="AutoTrader UK" >}}
{{< company_logo link="https://www.continental-corporation.com" logo="./continental.svg" alt="Continental" >}}
{{< company_logo link="https://www.coohom.com" logo="./coohom.svg" alt="COOHOM" >}}
+ {{< company_logo link="https://www.daocloud.io" logo="./daocloud.svg" alt="DaoCloud" >}}
{{< company_logo link="https://www.descarteslabs.com" logo="./descarteslabs.png" alt="Descartes Labs" >}}
{{< company_logo link="https://www.ebay.com" logo="./ebay.png" alt="eBay" >}}
{{< company_logo link="https://www.flexe.com/" logo="/about/community/customers/flexe.svg" alt="FLEXE" >}}
diff --git a/content/en/about/community/customers/namely.svg b/content/en/about/community/customers/namely.svg
index 89ba4b916eaf..b9206c06cf06 100644
--- a/content/en/about/community/customers/namely.svg
+++ b/content/en/about/community/customers/namely.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/customers/plangrid.svg b/content/en/about/community/customers/plangrid.svg
index b4e6e3a20c6b..7a91f4e09069 100644
--- a/content/en/about/community/customers/plangrid.svg
+++ b/content/en/about/community/customers/plangrid.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/customers/pubnub.svg b/content/en/about/community/customers/pubnub.svg
index 0bf2bd2d9f0a..f787c8ce9fe1 100644
--- a/content/en/about/community/customers/pubnub.svg
+++ b/content/en/about/community/customers/pubnub.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/join/discourse.svg b/content/en/about/community/join/discourse.svg
index f03d5a1e7886..46db9c8d1d1f 100644
--- a/content/en/about/community/join/discourse.svg
+++ b/content/en/about/community/join/discourse.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/join/gcal.svg b/content/en/about/community/join/gcal.svg
index c6b834896567..b98906e530f5 100644
--- a/content/en/about/community/join/gcal.svg
+++ b/content/en/about/community/join/gcal.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/join/group.svg b/content/en/about/community/join/group.svg
index e2746a1b58ec..41e862b8e703 100644
--- a/content/en/about/community/join/group.svg
+++ b/content/en/about/community/join/group.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/join/slack.svg b/content/en/about/community/join/slack.svg
index 8a5d24fae7f9..308c174127d7 100644
--- a/content/en/about/community/join/slack.svg
+++ b/content/en/about/community/join/slack.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/join/twitter.svg b/content/en/about/community/join/twitter.svg
index dba00e4b9c3b..a0492f18b0a0 100644
--- a/content/en/about/community/join/twitter.svg
+++ b/content/en/about/community/join/twitter.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/ambassador.svg b/content/en/about/community/partners/ambassador.svg
index 1650e104637b..2823cdd62e7e 100644
--- a/content/en/about/community/partners/ambassador.svg
+++ b/content/en/about/community/partners/ambassador.svg
@@ -1,14 +1 @@
-
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/apigee.svg b/content/en/about/community/partners/apigee.svg
index 8e4378c2ae11..885fa477dd26 100644
--- a/content/en/about/community/partners/apigee.svg
+++ b/content/en/about/community/partners/apigee.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/aporeto.svg b/content/en/about/community/partners/aporeto.svg
index 29609dc6599a..22be6d8afd97 100644
--- a/content/en/about/community/partners/aporeto.svg
+++ b/content/en/about/community/partners/aporeto.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/aspenmesh.svg b/content/en/about/community/partners/aspenmesh.svg
index 2daca7c5c6e2..f24e05061172 100644
--- a/content/en/about/community/partners/aspenmesh.svg
+++ b/content/en/about/community/partners/aspenmesh.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/cisco.svg b/content/en/about/community/partners/cisco.svg
index 66248feda5e9..e9ba4ae5a714 100644
--- a/content/en/about/community/partners/cisco.svg
+++ b/content/en/about/community/partners/cisco.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/envoy.svg b/content/en/about/community/partners/envoy.svg
index 300e3019093a..7b922d2bbfbd 100644
--- a/content/en/about/community/partners/envoy.svg
+++ b/content/en/about/community/partners/envoy.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/gcp.svg b/content/en/about/community/partners/gcp.svg
index 4445af9814a9..08c7a6a25012 100644
--- a/content/en/about/community/partners/gcp.svg
+++ b/content/en/about/community/partners/gcp.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/ibm-cloud.svg b/content/en/about/community/partners/ibm-cloud.svg
index 5df0216dd1db..6ccc82da9adc 100644
--- a/content/en/about/community/partners/ibm-cloud.svg
+++ b/content/en/about/community/partners/ibm-cloud.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/pivotal.svg b/content/en/about/community/partners/pivotal.svg
index 847461a2e4d3..4667162f6c2d 100644
--- a/content/en/about/community/partners/pivotal.svg
+++ b/content/en/about/community/partners/pivotal.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/redhat.svg b/content/en/about/community/partners/redhat.svg
index 40f4775b1e2b..735c74f2b777 100644
--- a/content/en/about/community/partners/redhat.svg
+++ b/content/en/about/community/partners/redhat.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/scytale.svg b/content/en/about/community/partners/scytale.svg
index 958ddbbc96f0..f05dc3e3ab13 100644
--- a/content/en/about/community/partners/scytale.svg
+++ b/content/en/about/community/partners/scytale.svg
@@ -1,20 +1 @@
-
-
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/styra.svg b/content/en/about/community/partners/styra.svg
index 82045e83eb6f..ed72599de780 100644
--- a/content/en/about/community/partners/styra.svg
+++ b/content/en/about/community/partners/styra.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/community/partners/vmware.svg b/content/en/about/community/partners/vmware.svg
index acff14c3b5a5..62776c7ba0ea 100644
--- a/content/en/about/community/partners/vmware.svg
+++ b/content/en/about/community/partners/vmware.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/contribute/creating-and-editing-pages/index.md b/content/en/about/contribute/creating-and-editing-pages/index.md
index c4332770ad58..e02250dc063e 100644
--- a/content/en/about/contribute/creating-and-editing-pages/index.md
+++ b/content/en/about/contribute/creating-and-editing-pages/index.md
@@ -62,16 +62,22 @@ is the best fit for your content:
Blog Post
- A blog post is a timely article on Istio or products and technologies related to it. Typically, posts fall in one of the following four categories:
+ A blog post is an article on Istio or products and technologies related to it. Typically, posts fall in one of the following three categories:
Posts detailing the author’s experience using and configuring Istio, especially those that articulate a novel experience or perspective.
-
Posts highlighting or announcing Istio features.
-
Posts announcing an Istio-related event.
+
Posts highlighting Istio features.
Posts detailing how to accomplish a task or fulfill a specific use case using Istio. Unlike Tasks and Examples, the technical accuracy of blog posts is not maintained and tested after publication.
+
+
News Entry
+
+ A news entry post is a timely article on Istio and events related to it. News entries typically announce new releases or upcoming events.
+
+
+
FAQ
diff --git a/content/en/about/contribute/diagrams/diagram-guidelines.svg b/content/en/about/contribute/diagrams/diagram-guidelines.svg
index bbee8c8aff09..1111f52f42e5 100644
--- a/content/en/about/contribute/diagrams/diagram-guidelines.svg
+++ b/content/en/about/contribute/diagrams/diagram-guidelines.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/about/feature-stages/OWNERS b/content/en/about/feature-stages/OWNERS
deleted file mode 100644
index 6942d217ab8d..000000000000
--- a/content/en/about/feature-stages/OWNERS
+++ /dev/null
@@ -1,2 +0,0 @@
-approvers:
- - jasmine-jaksic
diff --git a/content/en/about/notes/1.0.1/index.md b/content/en/about/notes/1.0.1/index.md
deleted file mode 100644
index 8f41c649d6a4..000000000000
--- a/content/en/about/notes/1.0.1/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.0.1
-publishdate: 2018-08-29
-icon: notes
-release: 1.0.1
----
-
-This release addresses some critical issues found by the community when using Istio 1.0. This release note describes what's different between Istio 1.0 and Istio 1.0.1.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.2/index.md b/content/en/about/notes/1.0.2/index.md
deleted file mode 100644
index e3c9f0e8cb42..000000000000
--- a/content/en/about/notes/1.0.2/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Istio 1.0.2
-publishdate: 2018-09-06
-icon: notes
-release: 1.0.2
----
-
-This release addresses some critical issues found by the community when using Istio 1.0.1. This release note describes what's different between Istio 1.0.1 and
-Istio 1.0.2.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.3/index.md b/content/en/about/notes/1.0.3/index.md
deleted file mode 100644
index 7f84a1c5ded0..000000000000
--- a/content/en/about/notes/1.0.3/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Istio 1.0.3
-publishdate: 2018-10-30
-icon: notes
-release: 1.0.3
----
-
-This release addresses some critical issues found by the community when using Istio 1.0.2.
-This release note describes what's different between Istio 1.0.2 and Istio 1.0.3.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.4/index.md b/content/en/about/notes/1.0.4/index.md
deleted file mode 100644
index 17a844b4392b..000000000000
--- a/content/en/about/notes/1.0.4/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Istio 1.0.4
-publishdate: 2018-11-21
-icon: notes
-release: 1.0.4
----
-
-This release addresses some critical issues found by the community when using Istio 1.0.3.
-This release note describes what's different between Istio 1.0.3 and Istio 1.0.4.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.5/index.md b/content/en/about/notes/1.0.5/index.md
deleted file mode 100644
index c403160f8f61..000000000000
--- a/content/en/about/notes/1.0.5/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Istio 1.0.5
-publishdate: 2018-12-20
-icon: notes
-release: 1.0.5
----
-
-This release addresses some critical issues found by the community in prior releases.
-This release note describes what's different between Istio 1.0.4 and Istio 1.0.5.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.6/index.md b/content/en/about/notes/1.0.6/index.md
deleted file mode 100644
index 7cdadb1f11e8..000000000000
--- a/content/en/about/notes/1.0.6/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Istio 1.0.6
-publishdate: 2019-02-12
-icon: notes
-release: 1.0.6
----
-
-This release includes security vulnerability fixes and improvements to robustness.
-This release note describes what's different between Istio 1.0.5 and Istio 1.0.6.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.7/index.md b/content/en/about/notes/1.0.7/index.md
deleted file mode 100644
index b1d84005d6cc..000000000000
--- a/content/en/about/notes/1.0.7/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.0.7
-publishdate: 2019-04-05
-icon: notes
-release: 1.0.7
----
-
-This release includes an important security update. All customers using prior versions of Istio are advised to upgrade immediately.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.8/index.md b/content/en/about/notes/1.0.8/index.md
deleted file mode 100644
index 18ac4e989b92..000000000000
--- a/content/en/about/notes/1.0.8/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.0.8
-publishdate: 2019-06-07
-icon: notes
-release: 1.0.8
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.0.7 and Istio 1.0.8.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0.9/index.md b/content/en/about/notes/1.0.9/index.md
deleted file mode 100644
index 914a7bd0237f..000000000000
--- a/content/en/about/notes/1.0.9/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.0.9
-publishdate: 2019-06-28
-icon: notes
-release: 1.0.9
----
-
-This release includes bug fixes to improve robustness. This release note describes what's different between Istio 1.0.8 and Istio 1.0.9.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.0/index.md b/content/en/about/notes/1.0/index.md
deleted file mode 100644
index d89d3c80ca86..000000000000
--- a/content/en/about/notes/1.0/index.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Istio 1.0
-publishdate: 2018-07-31
-icon: notes
-release: 1.0.0
----
-
-We're proud to release Istio 1.0! Istio has been in development for nearly two years, and the 1.0 release represents a substantial
-milestone for us. All of our [core features](/about/feature-stages/) are now ready for production use.
-
-These release notes describe what's different between Istio 0.8 and Istio 1.0. Istio 1.0 only has a few new features
-relative to 0.8 as most of the effort for this release went into fixing bugs and improving performance.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.1/index.md b/content/en/about/notes/1.1.1/index.md
deleted file mode 100644
index 1a04b609326a..000000000000
--- a/content/en/about/notes/1.1.1/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.1
-publishdate: 2019-03-25
-icon: notes
-release: 1.1.1
----
-
-This release includes security vulnerability fixes and improvements to robustness. This release note describes what's different between Istio 1.1 and Istio 1.1.1.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.10/index.md b/content/en/about/notes/1.1.10/index.md
deleted file mode 100644
index ac93ee30bf8e..000000000000
--- a/content/en/about/notes/1.1.10/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.10
-publishdate: 2019-06-28
-icon: notes
-release: 1.1.10
----
-
-This release includes bug fixes to improve robustness. This release note describes what's different between Istio 1.1.9 and Istio 1.1.10.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.11/index.md b/content/en/about/notes/1.1.11/index.md
deleted file mode 100644
index a4846643de27..000000000000
--- a/content/en/about/notes/1.1.11/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.11
-publishdate: 2019-07-03
-icon: notes
-release: 1.1.11
----
-
-This release includes bug fixes to improve robustness. This release note describes what's different between Istio 1.1.10 and Istio 1.1.11.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.12/index.md b/content/en/about/notes/1.1.12/index.md
deleted file mode 100644
index 01e1e207e064..000000000000
--- a/content/en/about/notes/1.1.12/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.12
-publishdate: 2019-08-02
-icon: notes
-release: 1.1.12
----
-
-This release includes bug fixes to improve robustness. This release note describes what's different between Istio 1.1.11 and Istio 1.1.12.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.13/index.md b/content/en/about/notes/1.1.13/index.md
deleted file mode 100644
index 9d740ee671d2..000000000000
--- a/content/en/about/notes/1.1.13/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.13
-publishdate: 2019-08-13
-icon: notes
-release: 1.1.13
----
-
-This release includes an important security update. This release note describes what's different between Istio 1.1.12 and Istio 1.1.13.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.14/index.md b/content/en/about/notes/1.1.14/index.md
deleted file mode 100644
index 29e41974f85c..000000000000
--- a/content/en/about/notes/1.1.14/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.14
-publishdate: 2019-08-26
-icon: notes
-release: 1.1.14
----
-
-This release includes an important security update. This release note describes what's different between Istio 1.1.13 and Istio 1.1.14.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.2/index.md b/content/en/about/notes/1.1.2/index.md
deleted file mode 100644
index cee5d7659de9..000000000000
--- a/content/en/about/notes/1.1.2/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.2
-publishdate: 2019-04-05
-icon: notes
-release: 1.1.2
----
-
-This release includes an important security update. All customers using prior versions of Istio are advised to upgrade immediately.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.3/index.md b/content/en/about/notes/1.1.3/index.md
deleted file mode 100644
index 303a73768768..000000000000
--- a/content/en/about/notes/1.1.3/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.3
-publishdate: 2019-04-15
-icon: notes
-release: 1.1.3
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.1.2 and Istio 1.1.3.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.4/index.md b/content/en/about/notes/1.1.4/index.md
deleted file mode 100644
index b978c43b29d5..000000000000
--- a/content/en/about/notes/1.1.4/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.4
-publishdate: 2019-04-24
-icon: notes
-release: 1.1.4
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.1.3 and Istio 1.1.4.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.5/index.md b/content/en/about/notes/1.1.5/index.md
deleted file mode 100644
index 4f760e41ccb9..000000000000
--- a/content/en/about/notes/1.1.5/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.5
-publishdate: 2019-05-03
-icon: notes
-release: 1.1.5
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.1.4 and Istio 1.1.5.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.6/index.md b/content/en/about/notes/1.1.6/index.md
deleted file mode 100644
index 66bd081d2d54..000000000000
--- a/content/en/about/notes/1.1.6/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.6
-publishdate: 2019-05-11
-icon: notes
-release: 1.1.6
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.1.5 and Istio 1.1.6.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.7/index.md b/content/en/about/notes/1.1.7/index.md
deleted file mode 100644
index 09bba8ab914f..000000000000
--- a/content/en/about/notes/1.1.7/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.7
-publishdate: 2019-05-17
-icon: notes
-release: 1.1.7
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.1.6 and Istio 1.1.7.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.8/index.md b/content/en/about/notes/1.1.8/index.md
deleted file mode 100644
index 7c6eeb6705dd..000000000000
--- a/content/en/about/notes/1.1.8/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.8
-publishdate: 2019-06-06
-icon: notes
-release: 1.1.8
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.1.7 and Istio 1.1.8.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1.9/index.md b/content/en/about/notes/1.1.9/index.md
deleted file mode 100644
index 95d7a977eeb1..000000000000
--- a/content/en/about/notes/1.1.9/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.1.9
-publishdate: 2019-06-17
-icon: notes
-release: 1.1.9
----
-
-This release includes several bug fixes and improvements to robustness. This release note describes what's different between Istio 1.1.8 and Istio 1.1.9.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.1/index.md b/content/en/about/notes/1.1/index.md
deleted file mode 100644
index ac94e046b8cb..000000000000
--- a/content/en/about/notes/1.1/index.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Istio 1.1
-publishdate: 2019-03-19
-icon: notes
-release: 1.1.0
----
-
-We're proud to release Istio 1.1!
-
-We've spent the last 8 months making some significant improvements to the
-overall product, with fixes and features from Google, IBM, VMware, Huawei,
-RedHat, Cisco, SAP, Salesforce, Pivotal, SUSE, Datadog and LightStep, to name a
-few. Special thanks to all of our end-users for providing feedback, feature
-requests, and testing the release candidates at various scales.
-
-These release notes describe what's different between Istio 1.0.6 and Istio 1.1.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.2.1/index.md b/content/en/about/notes/1.2.1/index.md
deleted file mode 100644
index 0e1eedd9c07d..000000000000
--- a/content/en/about/notes/1.2.1/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.2.1
-publishdate: 2019-06-27
-icon: notes
-release: 1.2.1
----
-
-This release includes several bug fixes and improvements. This release note describes what's different between Istio 1.2 and Istio 1.2.1.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.2.2/index.md b/content/en/about/notes/1.2.2/index.md
deleted file mode 100644
index 209e9e3ea623..000000000000
--- a/content/en/about/notes/1.2.2/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.2.2
-publishdate: 2019-06-28
-icon: notes
-release: 1.2.2
----
-
-This release includes bug fixes. This release note describes what's different between Istio 1.2.1 and Istio 1.2.2.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.2.3/index.md b/content/en/about/notes/1.2.3/index.md
deleted file mode 100644
index 093e73788135..000000000000
--- a/content/en/about/notes/1.2.3/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.2.3
-publishdate: 2019-08-02
-icon: notes
-release: 1.2.3
----
-
-This release includes bug fixes. This release note describes what's different between Istio 1.2.2 and Istio 1.2.3.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.2.4/index.md b/content/en/about/notes/1.2.4/index.md
deleted file mode 100644
index fe019473a631..000000000000
--- a/content/en/about/notes/1.2.4/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.2.4
-publishdate: 2019-08-13
-icon: notes
-release: 1.2.4
----
-
-This release includes an important security update. This release note describes what's different between Istio 1.2.3 and Istio 1.2.4.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.2.5/index.md b/content/en/about/notes/1.2.5/index.md
deleted file mode 100644
index c5f596349c9b..000000000000
--- a/content/en/about/notes/1.2.5/index.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Istio 1.2.5
-publishdate: 2019-08-26
-icon: notes
-release: 1.2.5
----
-
-This release includes an important security update. This release note describes what's different between Istio 1.2.4 and Istio 1.2.5.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.2/index.md b/content/en/about/notes/1.2/index.md
deleted file mode 100644
index 476ab0a22a65..000000000000
--- a/content/en/about/notes/1.2/index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Istio 1.2
-publishdate: 2019-06-18
-icon: notes
-release: 1.2.0
----
-
-We’re proud to release Istio 1.2! We are excited that we are back with a 3 month release cadence!
-
-We’ve spent the last 3 months making some significant improvements to the overall product,
-with fixes and features from the Istio community. Special thanks to all of our end-users for
-providing feedback, feature requests, and testing the release candidates at various scales.
-
-This release note describes what’s different between Istio 1.1.9 and Istio 1.2.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/1.3/index.md b/content/en/about/notes/1.3/index.md
deleted file mode 100644
index 847fc2920ab6..000000000000
--- a/content/en/about/notes/1.3/index.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Istio 1.3
-publishdate: 2019-09-12
-icon: notes
-release: 1.3.0
----
-
-We’re proud to release Istio 1.3!
-
-We’ve spent the last 3 months making some significant improvements to the overall product,
-with fixes and features from the Istio community. Special thanks to all of our end-users for
-providing feedback, feature requests, and testing the release candidates at various scales.
-
-This release note describes what’s different between Istio 1.2.5 and Istio 1.3.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/_index.md b/content/en/about/notes/_index.md
deleted file mode 100644
index 3e3a6e9cb50b..000000000000
--- a/content/en/about/notes/_index.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: Release Notes
-description: Description of features and improvements for every Istio release.
-weight: 5
-aliases:
- - /docs/reference/release-notes.html
- - /release-notes
- - /docs/welcome/notes/index.html
- - /docs/references/notes
-icon: notes
-simple_list: true
----
-
-Check out our [release page](https://github.com/istio/istio/releases) to download Istio binaries.
diff --git a/content/en/about/notes/older/0.1/index.md b/content/en/about/notes/older/0.1/index.md
deleted file mode 100644
index 4fef2c329821..000000000000
--- a/content/en/about/notes/older/0.1/index.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Istio 0.1
-publishdate: 2017-05-24
-aliases:
- - /docs/welcome/notes/0.1.html
- - /about/notes/0.1/index.html
-icon: notes
-release: 0.1.0
----
-
-Istio 0.1 is the initial [release](https://github.com/istio/istio/releases) of Istio. It works in a single Kubernetes cluster and supports the following features:
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/0.2/index.md b/content/en/about/notes/older/0.2/index.md
deleted file mode 100644
index e0a181cc6f89..000000000000
--- a/content/en/about/notes/older/0.2/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Istio 0.2
-publishdate: 2017-10-10
-aliases:
- - /docs/welcome/notes/0.2.html
- - /about/notes/0.2/index.html
-icon: notes
-release: 0.2.0
----
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/0.3/index.md b/content/en/about/notes/older/0.3/index.md
deleted file mode 100644
index c6791eca87d2..000000000000
--- a/content/en/about/notes/older/0.3/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Istio 0.3
-publishdate: 2017-11-29
-aliases:
- - /docs/welcome/notes/0.3.html
- - /about/notes/0.3/index.html
-icon: notes
-release: 0.3.0
----
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/0.4/index.md b/content/en/about/notes/older/0.4/index.md
deleted file mode 100644
index 94a9d178f83e..000000000000
--- a/content/en/about/notes/older/0.4/index.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Istio 0.4
-publishdate: 2017-12-18
-aliases:
- - /docs/welcome/notes/0.4.html
- - /about/notes/0.4/index.html
-icon: notes
-release: 0.4.0
----
-
-This release has only got a few weeks' worth of changes, as we stabilize our monthly release process.
-In addition to the usual pile of bug fixes and performance improvements, this release includes the items
-below.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/0.5/index.md b/content/en/about/notes/older/0.5/index.md
deleted file mode 100644
index c05242211ca4..000000000000
--- a/content/en/about/notes/older/0.5/index.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Istio 0.5
-publishdate: 2018-02-02
-icon: notes
-aliases:
- - /about/notes/0.5/index.html
-release: 0.5.0
----
-
-In addition to the usual pile of bug fixes and performance improvements, this release includes the new or
-updated features detailed below.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/0.6/index.md b/content/en/about/notes/older/0.6/index.md
deleted file mode 100644
index e5df931f7d2a..000000000000
--- a/content/en/about/notes/older/0.6/index.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Istio 0.6
-publishdate: 2018-03-08
-icon: notes
-aliases:
- - /about/notes/0.6/index.html
-release: 0.6.0
----
-
-In addition to the usual pile of bug fixes and performance improvements, this release includes the new or
-updated features detailed below.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/0.7/index.md b/content/en/about/notes/older/0.7/index.md
deleted file mode 100644
index df1908b39eb5..000000000000
--- a/content/en/about/notes/older/0.7/index.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-title: Istio 0.7
-publishdate: 2018-03-28
-icon: notes
-aliases:
- - /about/notes/0.7/index.html
-release: 0.7.0
----
-
-For this release, we focused on improving our build and test infrastructures and increasing the
-quality of our tests. As a result, there are no new features for this month.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/0.8/index.md b/content/en/about/notes/older/0.8/index.md
deleted file mode 100644
index e1b80a464d7b..000000000000
--- a/content/en/about/notes/older/0.8/index.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Istio 0.8
-publishdate: 2018-06-01
-icon: notes
-aliases:
- - /about/notes/0.8/index.html
-release: 0.8.0
----
-
-This is a major release for Istio on the road to 1.0. There are a great many new features and architectural improvements in addition to the usual pile of bug fixes and performance improvements.
-
-{{< relnote >}}
diff --git a/content/en/about/notes/older/_index.md b/content/en/about/notes/older/_index.md
deleted file mode 100644
index 20e27e88c8bc..000000000000
--- a/content/en/about/notes/older/_index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Older Notes
-description: Notes from older releases of Istio.
-icon: notes
-simple_list: true
-publishdate: 2017-05-24
-skip_byline: true
----
-
-If you're on the lookout for info on ancient Istio releases, head straight for
-our [archive of the earlier releases' documentation](https://archive.istio.io/).
diff --git a/content/en/about/release-cadence/index.md b/content/en/about/release-cadence/index.md
index 0f48b37c9507..d3c514ddcb8a 100644
--- a/content/en/about/release-cadence/index.md
+++ b/content/en/about/release-cadence/index.md
@@ -1,7 +1,7 @@
---
title: Build & Release Cadence
description: How we manage, number, and support Istio releases.
-weight: 6
+weight: 15
icon: cadence
---
@@ -24,7 +24,7 @@ offer technical assistance. Separately, 3rd parties and partners may offer longe
You can find available releases on the [releases page](https://github.com/istio/istio/releases),
and if you're the adventurous type, you can learn about our daily builds on the [daily builds wiki](https://github.com/istio/istio/wiki/Daily-builds).
-You can find high-level releases notes for each LTS release [here](/about/notes).
+You can find high-level releases notes for each LTS release [here](/news).
## Naming Scheme
diff --git a/content/en/blog/2017/0.1-auth/istio_auth_overview.svg b/content/en/blog/2017/0.1-auth/istio_auth_overview.svg
index 46576cf0b55e..882fb596ddd7 100644
--- a/content/en/blog/2017/0.1-auth/istio_auth_overview.svg
+++ b/content/en/blog/2017/0.1-auth/istio_auth_overview.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2017/0.1-auth/istio_auth_workflow.svg b/content/en/blog/2017/0.1-auth/istio_auth_workflow.svg
index b8a4fe11f7da..ff45e4f9ecb1 100644
--- a/content/en/blog/2017/0.1-auth/istio_auth_workflow.svg
+++ b/content/en/blog/2017/0.1-auth/istio_auth_workflow.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2017/0.2-announcement/index.md b/content/en/blog/2017/0.2-announcement/index.md
deleted file mode 100644
index a5261d99c4b3..000000000000
--- a/content/en/blog/2017/0.2-announcement/index.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Announcing Istio 0.2
-description: Istio 0.2 announcement.
-publishdate: 2017-10-10
-subtitle: Improved mesh and support for multiple environments
-attribution: The Istio Team
-aliases:
- - /blog/istio-0.2-announcement.html
----
-
-We launched Istio; an open platform to connect, manage, monitor, and secure microservices, on May 24, 2017. We have been humbled by the incredible interest, and
-rapid community growth of developers, operators, and partners. Our 0.1 release was focused on showing all the concepts of Istio in Kubernetes.
-
-Today we are happy to announce the 0.2 release which improves stability and performance, allows for cluster wide deployment and automated injection of sidecars in Kubernetes, adds policy and authentication for TCP services, and enables expansion of the mesh to include services deployed in virtual machines. In addition, Istio can now run outside Kubernetes, leveraging Consul/Nomad or Eureka. Beyond core features, Istio is now ready for extensions to be written by third party companies and developers.
-
-## Highlights for the 0.2 release
-
-### Usability improvements
-
-* _Multiple namespace support_: Istio now works cluster-wide, across multiple namespaces and this was one of the top requests from community from 0.1 release.
-
-* _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/reference/access-authn-authz/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
-[Mixer Adapter Developer's Guide](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide) can help
-you easily integrate your solution with Istio.
-
-* _Bring your own CA certificates_: Allows users to provide their own key and certificate for Istio CA and persistent CA key/certificate Storage. Enables storing signing key/certificates in persistent storage to facilitate CA restarts.
-
-* _Improved routing & metrics_: Support for WebSocket, MongoDB and Redis protocols. You can apply resilience features like circuit breakers on traffic to third party services. In addition to Mixer’s metrics, hundreds of metrics from Envoy are now visible inside Prometheus for all traffic entering, leaving and within Istio mesh.
-
-### Cross environment support
-
-* _Mesh expansion_: Istio mesh can now span services running outside of Kubernetes - like those running in virtual machines while enjoying benefits such as automatic mutual TLS authentication, traffic management, telemetry, and policy enforcement across the mesh.
-
-* _Running outside Kubernetes_: We know many customers use other service registry and orchestration solutions like Consul/Nomad and Eureka. Istio Pilot can now run standalone outside Kubernetes, consuming information from these systems, and manage the Envoy fleet in VMs or containers.
-
-## Get involved in shaping the future of Istio
-
-We have a growing [roadmap](/about/feature-stages/) ahead of us, full of great features to implement. Our focus next release is going to be on stability, reliability, integration with third party tools and multicluster use cases.
-
-To learn how to get involved and contribute to Istio's future, check out our [community](https://github.com/istio/community) GitHub repository which
-will introduce you to our working groups, our mailing lists, our various community meetings, our general procedures and our guidelines.
-
-We want to thank our fantastic community for field testing new versions, filing bug reports, contributing code, helping out other community members, and shaping Istio by participating in countless productive discussions. This has enabled the project to accrue 3000 stars on GitHub since launch and hundreds of active community members on Istio mailing lists.
-
-Thank you
diff --git a/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg b/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg
index c9ff48da01be..e91f64d2156f 100644
--- a/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg
+++ b/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg b/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg
index 4a9b4b1f0ac0..c3940616e8d5 100644
--- a/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg
+++ b/content/en/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2018/announcing-1.0.1/index.md b/content/en/blog/2018/announcing-1.0.1/index.md
deleted file mode 100644
index 141a0c1fb4e8..000000000000
--- a/content/en/blog/2018/announcing-1.0.1/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.0.1
-description: Istio 1.0.1 patch release.
-publishdate: 2018-08-29
-attribution: The Istio Team
-release: 1.0.1
----
-
-We're pleased to announce the availability of Istio 1.0.1. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2018/announcing-1.0.2/index.md b/content/en/blog/2018/announcing-1.0.2/index.md
deleted file mode 100644
index 1558f29c4db7..000000000000
--- a/content/en/blog/2018/announcing-1.0.2/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.0.2
-description: Istio 1.0.2 patch release.
-publishdate: 2018-09-06
-attribution: The Istio Team
-release: 1.0.2
----
-
-We're pleased to announce the availability of Istio 1.0.2. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2018/announcing-1.0.3/index.md b/content/en/blog/2018/announcing-1.0.3/index.md
deleted file mode 100644
index 3a47ed397929..000000000000
--- a/content/en/blog/2018/announcing-1.0.3/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.0.3
-description: Istio 1.0.3 patch release.
-publishdate: 2018-10-30
-attribution: The Istio Team
-release: 1.0.3
----
-
-We're pleased to announce the availability of Istio 1.0.3. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2018/announcing-1.0.4/index.md b/content/en/blog/2018/announcing-1.0.4/index.md
deleted file mode 100644
index 93aa3b169019..000000000000
--- a/content/en/blog/2018/announcing-1.0.4/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.0.4
-description: Istio 1.0.4 patch release.
-publishdate: 2018-11-21
-attribution: The Istio Team
-release: 1.0.4
----
-
-We're pleased to announce the availability of Istio 1.0.4. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2018/announcing-1.0.5/index.md b/content/en/blog/2018/announcing-1.0.5/index.md
deleted file mode 100644
index 6e88352c416f..000000000000
--- a/content/en/blog/2018/announcing-1.0.5/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.0.5
-description: Istio 1.0.5 patch release.
-publishdate: 2018-12-20
-attribution: The Istio Team
-release: 1.0.5
----
-
-We're pleased to announce the availability of Istio 1.0.5. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2018/announcing-1.0/index.md b/content/en/blog/2018/announcing-1.0/index.md
deleted file mode 100644
index bed7ab5cce4a..000000000000
--- a/content/en/blog/2018/announcing-1.0/index.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Announcing Istio 1.0
-subtitle: The production ready service mesh
-description: Istio is ready for production use with its 1.0 release.
-publishdate: 2018-07-31
-attribution: The Istio Team
-release: 1.0.0
----
-
-Today, we’re excited to announce [Istio 1.0](/about/notes/1.0). It’s been a little over a year since our initial 0.1 release. Since then, Istio has evolved significantly with the help of a thriving and growing community of contributors and users. We’ve now reached the point where many companies have successfully adopted Istio in production and have gotten real value from the insight and control it provides over their deployments. We’ve helped large enterprises and fast-moving startups like [eBay](https://www.ebay.com/), [Auto Trader UK](https://www.autotrader.co.uk/), [Descartes Labs](http://www.descarteslabs.com/), [HP FitStation](https://www.fitstation.com/), [JUSPAY](https://juspay.in), [Namely](https://www.namely.com/), [PubNub](https://www.pubnub.com/) and [Trulia](https://www.trulia.com/) use Istio to connect, manage and secure their services from the ground up. Shipping this release as 1.0 is recognition that we’ve built a core set of functionality that our users can rely on for production use.
-
-{{< relnote linktonote="true" >}}
-
-## Ecosystem
-
-We’ve seen substantial growth in Istio's ecosystem in the last year. [Envoy](https://www.envoyproxy.io/) continues its impressive growth and added numerous
-features that are crucial for a production quality service mesh. Observability providers like [Datadog](https://www.datadoghq.com/),
-[SolarWinds](https://www.solarwinds.com/), [Sysdig](https://sysdig.com/blog/monitor-istio/), [Google Stackdriver](https://cloud.google.com/stackdriver/) and
-[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) have written plugins to integrate Istio with their products.
-[Tigera](https://www.tigera.io/resources/using-network-policy-concert-istio-2/), [Aporeto](https://www.aporeto.com/), [Cilium](https://cilium.io/)
-and [Styra](https://styra.com/) built extensions to our policy enforcement and networking capabilities. [Red Hat](https://www.redhat.com/en) built [Kiali](https://www.kiali.io) to wrap a nice user-experience around mesh management and observability. [Cloud Foundry](https://www.cloudfoundry.org/) is building on Istio for it’s next generation traffic routing stack, the recently announced [Knative](https://github.com/knative/docs) serverless project is doing the same and [Apigee](https://apigee.com/) announced that they plan to use it in their API management solution. These are just some of the integrations the community has added in the last year.
-
-## Features
-
-Since the 0.8 release we’ve added some important new features and more importantly marked many of our existing features as Beta signaling that they’re ready for production use. This is captured in more detail in the [release notes](/about/notes/1.0/) but it’s worth calling out some highlights
-
-* Multiple Kubernetes clusters can now be [added to a single mesh](/docs/setup/install/multicluster/) and enabling cross-cluster communication and consistent policy enforcement. Multi-cluster support is now Beta.
-
-* Networking APIs that enable fine grained control over the flow of traffic through a mesh are now Beta. Explicitly modeling ingress and egress concerns using Gateways allows operators to [control the network topology](/blog/2018/v1alpha3-routing/) and meet access security requirements at the edge.
-
-* Mutual TLS can now be [rolled out incrementally](/docs/tasks/security/mtls-migration) without requiring all clients of a service to be updated. This is a critical feature that unblocks adoption in-place by existing production deployments.
-
-* Mixer now has support for [developing out-of-process adapters](https://github.com/istio/istio/wiki/Out-Of-Process-gRPC-Adapter-Dev-Guide). This will become the default way to extend Mixer over the coming releases and makes building adapters much simpler.
-
-* [Authorization policies](/docs/concepts/security/#authorization) which control access to services are now entirely evaluated locally in Envoy increasing
-their performance and reliability.
-
-* [Helm chart installation](/docs/setup/install/helm/) is now the recommended install method offering rich customization options to adopt Istio on your terms.
-
-* We’ve put a lot of effort into performance including continuous regression testing, large scale environment simulation and targeted fixes. We’re very happy with the results and will share more on this in detail in the coming weeks.
-
-## What’s next?
-
-While this is a significant milestone for the project there’s lots more to do. In working with adopters we’ve gotten a lot of great feedback about what to focus next. We’ve heard consistent themes around support for hybrid-cloud, install modularity, richer networking features and scalability for massive deployments. We’ve already taken some of this feedback into account in the 1.0 release and we’ll continue to aggressively tackle this work in the coming months.
-
-## Getting Started
-
-If you’re new to Istio and looking to use it for your deployment we’d love to hear from you. Take a look at [our docs](/docs/) or stop by our
-[chat forum](https://discuss.istio.io). If you’d like
-to go deeper and [contribute to the project](/about/community) come to one of our community meetings and say hello.
-
-## Finally
-
-The Istio team would like to give huge thanks to everyone who has made a contribution to the project. It wouldn’t be where it is today without your help. The last year has been pretty amazing and we look forward to the next one with excitement about what we can achieve together as a community.
diff --git a/content/en/blog/2018/egress-https/bookinfo-details-v2.svg b/content/en/blog/2018/egress-https/bookinfo-details-v2.svg
index 1bb7358186eb..d53a479b9883 100644
--- a/content/en/blog/2018/egress-https/bookinfo-details-v2.svg
+++ b/content/en/blog/2018/egress-https/bookinfo-details-v2.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2018/egress-mongo/bookinfo-ratings-v2-mongodb-external.svg b/content/en/blog/2018/egress-mongo/bookinfo-ratings-v2-mongodb-external.svg
index 387034b66a57..ca6cc662c2dc 100644
--- a/content/en/blog/2018/egress-mongo/bookinfo-ratings-v2-mongodb-external.svg
+++ b/content/en/blog/2018/egress-mongo/bookinfo-ratings-v2-mongodb-external.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2018/egress-monitoring-access-control/http-to-gateway.svg b/content/en/blog/2018/egress-monitoring-access-control/http-to-gateway.svg
index 8b32f2dc93af..d4b0bd376d3c 100644
--- a/content/en/blog/2018/egress-monitoring-access-control/http-to-gateway.svg
+++ b/content/en/blog/2018/egress-monitoring-access-control/http-to-gateway.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2018/egress-monitoring-access-control/https-to-gateway.svg b/content/en/blog/2018/egress-monitoring-access-control/https-to-gateway.svg
index ac1534c28302..6f739c11e943 100644
--- a/content/en/blog/2018/egress-monitoring-access-control/https-to-gateway.svg
+++ b/content/en/blog/2018/egress-monitoring-access-control/https-to-gateway.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2018/egress-tcp/bookinfo-ratings-v2-mysql-external.svg b/content/en/blog/2018/egress-tcp/bookinfo-ratings-v2-mysql-external.svg
index e212fbc026ca..002519267725 100644
--- a/content/en/blog/2018/egress-tcp/bookinfo-ratings-v2-mysql-external.svg
+++ b/content/en/blog/2018/egress-tcp/bookinfo-ratings-v2-mysql-external.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2018/traffic-mirroring/index.md b/content/en/blog/2018/traffic-mirroring/index.md
index b3c4d7296485..6d53f520bbd3 100644
--- a/content/en/blog/2018/traffic-mirroring/index.md
+++ b/content/en/blog/2018/traffic-mirroring/index.md
@@ -9,7 +9,7 @@ keywords: [traffic-management,mirroring]
Trying to enumerate all the possible combinations of test cases for testing services in non-production/test environments can be daunting. In some cases, you'll find that all of the effort that goes into cataloging these use cases doesn't match up to real production use cases. Ideally, we could use live production use cases and traffic to help illuminate all of the feature areas of the service under test that we might miss in more contrived testing environments.
-Istio can help here. With the release of [Istio 0.5.0](/about/notes/older/0.5/), Istio can mirror traffic to help test your services. You can write route rules similar to the following to enable traffic mirroring:
+Istio can help here. With the release of [Istio 0.5.0](/news/2018/announcing-0.5), Istio can mirror traffic to help test your services. You can write route rules similar to the following to enable traffic mirroring:
{{< text yaml >}}
apiVersion: config.istio.io/v1alpha2
diff --git a/content/en/blog/2018/v1alpha3-routing/gateways.svg b/content/en/blog/2018/v1alpha3-routing/gateways.svg
index 1e09e346c2c0..f5bc243fc816 100644
--- a/content/en/blog/2018/v1alpha3-routing/gateways.svg
+++ b/content/en/blog/2018/v1alpha3-routing/gateways.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2018/v1alpha3-routing/virtualservices-destrules.svg b/content/en/blog/2018/v1alpha3-routing/virtualservices-destrules.svg
index 15dfc7b38706..c7b4afd4bc54 100644
--- a/content/en/blog/2018/v1alpha3-routing/virtualservices-destrules.svg
+++ b/content/en/blog/2018/v1alpha3-routing/virtualservices-destrules.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2019/announcing-1.0.6/index.md b/content/en/blog/2019/announcing-1.0.6/index.md
deleted file mode 100644
index 8859a3b29bbb..000000000000
--- a/content/en/blog/2019/announcing-1.0.6/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.0.6
-description: Istio 1.0.6 patch release.
-publishdate: 2019-02-12
-attribution: The Istio Team
-release: 1.0.6
----
-
-We're pleased to announce the availability of Istio 1.0.6. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.0.7/index.md b/content/en/blog/2019/announcing-1.0.7/index.md
deleted file mode 100644
index 20cd9b78639e..000000000000
--- a/content/en/blog/2019/announcing-1.0.7/index.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Announcing Istio 1.0.7 with Important Security Update
-subtitle: Important Security Update
-description: Istio 1.0.7 patch releases.
-publishdate: 2019-04-05
-attribution: The Istio Team
-release: 1.0.7
----
-
-We're announcing immediate availability of Istio 1.0.7 which contains some important security updates. Please see below for details.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.0.8/index.md b/content/en/blog/2019/announcing-1.0.8/index.md
deleted file mode 100644
index 533a73938205..000000000000
--- a/content/en/blog/2019/announcing-1.0.8/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.0.8
-description: Istio 1.0.8 patch release.
-publishdate: 2019-06-07
-attribution: The Istio Team
-release: 1.0.8
----
-
-We're pleased to announce the availability of Istio 1.0.8. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.1/index.md b/content/en/blog/2019/announcing-1.1.1/index.md
deleted file mode 100644
index c841b6c2d93a..000000000000
--- a/content/en/blog/2019/announcing-1.1.1/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.1
-description: Istio 1.1.1 patch release.
-publishdate: 2019-03-25
-attribution: The Istio Team
-release: 1.1.1
----
-
-We're pleased to announce the availability of Istio 1.1.1. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.10/index.md b/content/en/blog/2019/announcing-1.1.10/index.md
deleted file mode 100644
index ad06eca82e31..000000000000
--- a/content/en/blog/2019/announcing-1.1.10/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.10
-description: Istio 1.1.10 patch release.
-publishdate: 2019-06-28
-attribution: The Istio Team
-release: 1.1.10
----
-
-We're pleased to announce the availability of Istio 1.1.10. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.12/index.md b/content/en/blog/2019/announcing-1.1.12/index.md
deleted file mode 100644
index a97149b29b67..000000000000
--- a/content/en/blog/2019/announcing-1.1.12/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.12
-description: Istio 1.1.12 patch release.
-publishdate: 2019-08-02
-attribution: The Istio Team
-release: 1.1.12
----
-
-We're pleased to announce the availability of Istio 1.1.12. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.13/index.md b/content/en/blog/2019/announcing-1.1.13/index.md
deleted file mode 100644
index 2e9205a2d742..000000000000
--- a/content/en/blog/2019/announcing-1.1.13/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.13
-description: Istio 1.1.13 patch release.
-publishdate: 2019-08-13
-attribution: The Istio Team
-release: 1.1.13
----
-
-We're pleased to announce the availability of Istio 1.1.13. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.14/index.md b/content/en/blog/2019/announcing-1.1.14/index.md
deleted file mode 100644
index a3063dd0cc11..000000000000
--- a/content/en/blog/2019/announcing-1.1.14/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.14
-description: Istio 1.1.14 patch release.
-publishdate: 2019-08-26
-attribution: The Istio Team
-release: 1.1.14
----
-
-We're pleased to announce the availability of Istio 1.1.14. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.2/index.md b/content/en/blog/2019/announcing-1.1.2/index.md
deleted file mode 100644
index 39206a64dc81..000000000000
--- a/content/en/blog/2019/announcing-1.1.2/index.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: Announcing Istio 1.1.2 with Important Security Update
-subtitle: Important Security Update
-description: Istio 1.1.2 patch release.
-publishdate: 2019-04-05
-attribution: The Istio Team
-release: 1.1.2
----
-
-We're announcing immediate availability of Istio 1.1.2 which contains some important security updates. Please see below for details.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.3/index.md b/content/en/blog/2019/announcing-1.1.3/index.md
deleted file mode 100644
index 637931d3e372..000000000000
--- a/content/en/blog/2019/announcing-1.1.3/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.3
-description: Istio 1.1.3 patch release.
-publishdate: 2019-04-15
-attribution: The Istio Team
-release: 1.1.3
----
-
-We're pleased to announce the availability of Istio 1.1.3. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.4/index.md b/content/en/blog/2019/announcing-1.1.4/index.md
deleted file mode 100644
index 613929fe072c..000000000000
--- a/content/en/blog/2019/announcing-1.1.4/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.4
-description: Istio 1.1.4 patch release.
-publishdate: 2019-04-24
-attribution: The Istio Team
-release: 1.1.4
----
-
-We're pleased to announce the availability of Istio 1.1.4. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.5/index.md b/content/en/blog/2019/announcing-1.1.5/index.md
deleted file mode 100644
index fa60ea7ce30f..000000000000
--- a/content/en/blog/2019/announcing-1.1.5/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.5
-description: Istio 1.1.5 patch release.
-publishdate: 2019-05-03
-attribution: The Istio Team
-release: 1.1.5
----
-
-We're pleased to announce the availability of Istio 1.1.5. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.6/index.md b/content/en/blog/2019/announcing-1.1.6/index.md
deleted file mode 100644
index 592183ca0ac0..000000000000
--- a/content/en/blog/2019/announcing-1.1.6/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.6
-description: Istio 1.1.6 patch release.
-publishdate: 2019-05-11
-attribution: The Istio Team
-release: 1.1.6
----
-
-We're pleased to announce the availability of Istio 1.1.6. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.7/index.md b/content/en/blog/2019/announcing-1.1.7/index.md
deleted file mode 100644
index 268a1d28d896..000000000000
--- a/content/en/blog/2019/announcing-1.1.7/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.7
-description: Istio 1.1.7 patch release.
-publishdate: 2019-05-17
-attribution: The Istio Team
-release: 1.1.7
----
-
-We're pleased to announce the availability of Istio 1.1.7. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.8/index.md b/content/en/blog/2019/announcing-1.1.8/index.md
deleted file mode 100644
index f895698f014a..000000000000
--- a/content/en/blog/2019/announcing-1.1.8/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.8
-description: Istio 1.1.8 patch release.
-publishdate: 2019-06-06
-attribution: The Istio Team
-release: 1.1.8
----
-
-We're pleased to announce the availability of Istio 1.1.8. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1.9/index.md b/content/en/blog/2019/announcing-1.1.9/index.md
deleted file mode 100644
index 089a429c0a41..000000000000
--- a/content/en/blog/2019/announcing-1.1.9/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.1.9
-description: Istio 1.1.9 patch release.
-publishdate: 2019-06-17
-attribution: The Istio Team
-release: 1.1.9
----
-
-We're pleased to announce the availability of Istio 1.1.9. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.1/index.md b/content/en/blog/2019/announcing-1.1/index.md
deleted file mode 100644
index a7ba8d932f2c..000000000000
--- a/content/en/blog/2019/announcing-1.1/index.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Announcing Istio 1.1
-subtitle: Major Update
-description: Istio 1.1 release announcement.
-publishdate: 2019-03-19
-attribution: The Istio Team
-release: 1.1.0
----
-
-We are pleased to announce the release of Istio 1.1!
-
-{{< relnote linktonote="true" >}}
-
-Since we released 1.0 back in July, we’ve done a lot of work to help people get
-into production. Not surprisingly, we had to do some [patch releases](/about/notes)
-(6 so far!), but we’ve also been hard at work adding new features to the
-product.
-
-The theme for 1.1 is Enterprise Ready. We’ve been very pleased to see more and
-more companies using Istio in production, but as some larger companies tried to
-adopt Istio they hit some limits.
-
-One of our prime areas of focus has been [performance and scalability](/docs/concepts/performance-and-scalability/).
-As people moved into production with larger clusters running more services at
-higher volume, they hit some scaling and performance issues. The
-[sidecars](/docs/concepts/traffic-management/#sidecars) took too many resources
-and added too much latency. The control plane (especially
-[Pilot](/docs/concepts/traffic-management/#pilot)) was overly
-resource hungry.
-
-We’ve done a lot of work to make both the data plane and the control plane more
-efficient. You can find the details of our 1.1 performance testing and the
-results in our updated [performance ans scalability concept](/docs/concepts/performance-and-scalability/).
-
-We’ve done work around namespace isolation as well. This lets you use
-Kubernetes namespaces to enforce boundaries of control, and ensures that your
-teams cannot interfere with each other.
-
-We have also improved the [multicluster capabilities and usability](/docs/concepts/deployment-models/).
-We listened to the community and improved defaults for traffic control and
-policy. We introduced a new component called
-[Galley](/docs/concepts/what-is-istio/#galley). Galley validates that sweet,
-sweet YAML, reducing the chance of configuration errors. Galley will also be
-instrumental in [multicluster setups](/docs/setup/install/multicluster/),
-gathering service discovery information from each Kubernetes cluster. We are
-also supporting additional multicluster topologies including different
-[control plane models](/docs/concepts/deployment-models/#control-plane-models)
-topologies without requiring a flat network.
-
-There is lots more -- see the [release notes](/about/notes/1.1/) for complete
-details.
-
-There is more going on in the project as well. We know that Istio has a lot of
-moving parts and can be a lot to take on. To help address that, we recently
-formed a [Usability Working Group](https://github.com/istio/community/blob/master/WORKING-GROUPS.md#working-group-meetings)
-(feel free to join). There is also a lot happening in the [Community
-Meeting](https://github.com/istio/community#community-meeting) (Thursdays at
-`11 a.m.`) and in the [Working
-Groups](https://github.com/istio/community/blob/master/WORKING-GROUPS.md). And
-if you haven’t yet joined the conversation at
-[discuss.istio.io](https://discuss.istio.io), head over, log in with your
-GitHub credentials and join us!
-
-We are grateful to everyone who has worked hard on Istio over the last few
-months -- patching 1.0, adding features to 1.1, and, lately, doing tons of
-testing on 1.1. Thanks especially to those companies and users who worked with
-us installing and upgrading to the early builds and helping us catch problems
-before the release.
-
-So: now’s the time! Grab 1.1, check out [the updated documentation](/docs/),
-[install it](/docs/setup/) and...happy meshing!
diff --git a/content/en/blog/2019/announcing-1.2.1/index.md b/content/en/blog/2019/announcing-1.2.1/index.md
deleted file mode 100644
index ff1ff26b782b..000000000000
--- a/content/en/blog/2019/announcing-1.2.1/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.2.1
-description: Istio 1.2.1 patch release.
-publishdate: 2019-06-27
-attribution: The Istio Team
-release: 1.2.1
----
-
-We're pleased to announce the availability of Istio 1.2.1. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.2.2/index.md b/content/en/blog/2019/announcing-1.2.2/index.md
deleted file mode 100644
index d1c67cb46448..000000000000
--- a/content/en/blog/2019/announcing-1.2.2/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.2.2
-description: Istio 1.2.2 patch release.
-publishdate: 2019-06-28
-attribution: The Istio Team
-release: 1.2.2
----
-
-We're pleased to announce the availability of Istio 1.2.2. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.2.3/index.md b/content/en/blog/2019/announcing-1.2.3/index.md
deleted file mode 100644
index 4b276eec9317..000000000000
--- a/content/en/blog/2019/announcing-1.2.3/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.2.3
-description: Istio 1.2.3 patch release.
-publishdate: 2019-08-02
-attribution: The Istio Team
-release: 1.2.3
----
-
-We're pleased to announce the availability of Istio 1.2.3. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.2.4/index.md b/content/en/blog/2019/announcing-1.2.4/index.md
deleted file mode 100644
index 330a1882673b..000000000000
--- a/content/en/blog/2019/announcing-1.2.4/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.2.4
-description: Istio 1.2.4 patch release.
-publishdate: 2019-08-13
-attribution: The Istio Team
-release: 1.2.4
----
-
-We're pleased to announce the availability of Istio 1.2.4. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.2.5/index.md b/content/en/blog/2019/announcing-1.2.5/index.md
deleted file mode 100644
index 3767ca24deac..000000000000
--- a/content/en/blog/2019/announcing-1.2.5/index.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Announcing Istio 1.2.5
-description: Istio 1.2.5 patch release.
-publishdate: 2019-08-26
-attribution: The Istio Team
-release: 1.2.5
----
-
-We're pleased to announce the availability of Istio 1.2.5. Please see below for what's changed.
-
-{{< relnote >}}
diff --git a/content/en/blog/2019/announcing-1.2/index.md b/content/en/blog/2019/announcing-1.2/index.md
deleted file mode 100644
index c7fc4dd04034..000000000000
--- a/content/en/blog/2019/announcing-1.2/index.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Announcing Istio 1.2
-subtitle: Major Update
-description: Istio 1.2 release announcement.
-publishdate: 2019-06-18
-attribution: The Istio Team
-release: 1.2.0
----
-
-We are pleased to announce the release of Istio 1.2!
-
-{{< relnote linktonote="true" >}}
-
-The theme of 1.2 is Predictable Releases - predictable in quality (we want
-every release to be a good release) as well as in time (we want to be able
-to ship on well known schedules).
-
-As nearly anyone using Istio 1.0 noticed, it took us a long time to get 1.1
-out. Far too long. One of the reasons was that we needed to do some work on
-our testing and infrastructure -- it was simply far too manual a process to
-build, test and release. Because of that, 1.2 focuses on improving the
-stability of these new features, and improving general product health.
-
-In order to make release quality and timing predictable, we declared a
-"Code Mauve", meaning that we would spend the next iteration focusing on
-project infrastructure. As a result, we’ve been investing a ton of effort
-in our build, test and release machinery.
-
-We formed 3 new teams (GitHub Workflow, Source Organization, Testing
-Methodology, and Build & Release Automation). Each had a set of issues to
-take on and a set of exit criteria. Code Mauve isn’t over yet, in fact we
-expect it to go
-on for some time. We’re putting in place the infrastructure to measure the
-metrics each team decided on (paraphrasing Peter Drucker: if you can’t
-measure it, you can’t manage it).
-
-You might have noticed that the [patch releases](/about/notes) for 1.1 have
-been coming fast and furious.
-
-In order to get features in the hands of our customers and users as soon as
-possible, most of the new features from the last three months have been
-delivered in 1.1.x releases. With 1.2, those features are now officially
-part of the release. See a complete
-list of changes in the [release notes](/about/notes/1.2).
-
-We're seeing early results from the usability group. In the release notes,
-you'll find that you can now set log levels for the control plane and the
-data plane globally. You can use [`istioctl`](/docs/reference/commands/istioctl) to validate that your Kubernetes
-installation meets Istio's requirements. And the new
-`traffic.sidecar.istio.io/includeInboundPorts` annotation to eliminate the
-need for service owner to declare `containerPort` in the deployment yaml.
-
-Some of the features have matured as well. The following features have
-progressed from Beta status
-to Stable: SNI at ingress, distributed tracing, and service tracing. The
-following features have reached beta status: cert management on ingress,
-configuration resource validation, and configuration processing with Galley.
-We know there are lots of feature requests outstanding, and we have an
-exciting roadmap (watch for a forthcoming post from the TOC on that). The
-work we have done in this release has taken care of some technical debt which
-will help us get those features out reliably in future.
-
-As always, there is also a lot happening in the [Community
-Meeting](https://github.com/istio/community#community-meeting) (Thursdays at
-`11 a.m. Pactific`) and in the [Working
-Groups](https://github.com/istio/community/blob/master/WORKING-GROUPS.md). And
-if you haven’t yet joined the conversation at
-[discuss.istio.io](https://discuss.istio.io), head over, log in with your
-GitHub credentials and join us!
diff --git a/content/en/blog/2019/announcing-1.3/index.md b/content/en/blog/2019/announcing-1.3/index.md
deleted file mode 100644
index a55d3db3af8f..000000000000
--- a/content/en/blog/2019/announcing-1.3/index.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Announcing Istio 1.3
-subtitle: Major Update
-description: Istio 1.3 release announcement.
-publishdate: 2019-09-12
-attribution: The Istio Team
-release: 1.3.0
----
-
-We are pleased to announce the release of Istio 1.3!
-
-{{< relnote linktonote="true" >}}
-
-The theme of Istio 1.3 is User Experience:
-
-- Improve the experience of new users adopting Istio
-- Improve the experience of users debugging problems
-- Support more applications without any additional configuration
-
-Every few releases, the Istio team delivers dramatic improvements to usability, APIs, and the overall system performance. Istio 1.3 is one such release, and the team is very excited to roll out some key updates.
-
-## Intelligent protocol detection (experimental)
-
-To take advantage of Istio's routing features, service ports must use a special port naming format to explicitly declare the protocol. This requirement can cause problems for users that do not name their ports when they add their applications to the mesh. Starting with 1.3, the protocol for outbound traffic is automatically detected as HTTP or TCP when the ports are not named according to Istio's conventions. We will be polishing this feature in the upcoming releases with support for protocol sniffing on inbound traffic as well as identifying protocols other than HTTP.
-
-## Mixer-less telemetry (experimental)
-
-Yes, you read that right! We implemented most of the common security policies, such as RBAC, directly into Envoy. We previously turned off the `istio-policy` service by default and are now on track to migrate most of Mixer's telemetry functionality into Envoy as well. In this release, we have enhanced the Istio proxy to emit HTTP metrics directly to Prometheus, without requiring the `istio-telemetry` service to enrich the information. This enhancement is great if all you care about is telemetry for HTTP services. Follow the [Mixer-less HTTP telemetry instructions](https://github.com/istio/istio/wiki/Mixerless-HTTP-Telemetry) to experiment with this feature. We are polishing this feature in the coming months to add telemetry support for TCP services when you enable Istio mutual TLS.
-
-## Container ports are no longer required
-
-Previous releases required that pods explicitly declare the Kubernetes `containerPort` for each container as a security measure against trampolining traffic. Istio 1.3 has a secure and simpler way of handling all inbound traffic on any port into a {{< gloss >}}workload instance{{< /gloss >}} without requiring the `containerPort` declarations. We have also completely eliminated the infinite loops caused in the IP tables rules when workload instances send traffic to themselves.
-
-## Fully customize generated Envoy configuration
-
-While Istio 1.3 focuses on usability, expert users can use advanced features in Envoy that are not part of the Istio Networking APIs. We enhanced the `EnvoyFilter` API to allow users to fully customize:
-
-- The HTTP/TCP listeners and their filter chains returned by LDS
-- The Envoy HTTP route configuration returned by the RDS
-- The set of clusters returned by CDS
-
-You get the best of both worlds:
-
-Leverage Istio to integrate with Kubernetes and handle large fleets of Envoys in an efficient manner, while you still can customize the generated Envoy configuration to meet specific requirements within your infrastructure.
-
-## Other enhancements
-
-- `istioctl` gained many debugging features to help you highlight various issues in your mesh installation. Checkout the `istioctl` [reference page](/docs/reference/commands/istioctl/) for the set of all supported features.
-
-- Locality aware load balancing graduated from experimental to default in this release too. Istio now takes advantage of existing locality information to prioritize load balancing pools and favor sending requests to the closest backends.
-
-- Better support for headless services with Istio mutual TLS
-
-- We enhanced control plane monitoring in the following ways:
-
- - Added new metrics to monitor configuration state
- - Added metrics for sidecar injector
- - Added a new Grafana dashboard for Citadel
- - Improved the Pilot dashboard to expose additional key metrics
-
-- Added the new [Istio Deployment Models concept](/docs/concepts/deployment-models/) to help you decide what deployment model suits your needs.
-
-- Organized the content in of our [Operations Guide](/docs/ops/) and created a [section with all troubleshooting tasks](/docs/ops/troubleshooting) to help you find the information you seek faster.
-
-See the [release notes](/about/notes/1.3) for the complete list of changes.
-
-As always, there is a lot happening in the [Community Meeting](https://github.com/istio/community#community-meeting); join us every other Thursday at 11 AM Pacific.
-
-The growth and success of Istio is due to its 400+ contributors from over 300 companies. Join one of our [Working Groups](https://github.com/istio/community/blob/master/WORKING-GROUPS.md) and help us make Istio even better.
-
-To join the conversation, go to [discuss.istio.io](https://discuss.istio.io), log in with your GitHub credentials and join us!
diff --git a/content/en/blog/2019/app-identity-and-access-adapter/index.md b/content/en/blog/2019/app-identity-and-access-adapter/index.md
new file mode 100644
index 000000000000..0289d23c2d3f
--- /dev/null
+++ b/content/en/blog/2019/app-identity-and-access-adapter/index.md
@@ -0,0 +1,167 @@
+---
+title: App Identity and Access Adapter
+subtitle: Using Istio to secure multi-cloud Kubernetes applications with zero code changes
+description: Using Istio to secure multi-cloud Kubernetes applications with zero code changes.
+publishdate: 2019-09-18
+attribution: Anton Aleksandrov (IBM)
+keywords: [security,oidc,jwt,policies]
+---
+
+If you are running your containerized applications on Kubernetes, you can benefit from using the App Identity and Access Adapter for an abstracted level of security with zero code changes or redeploys.
+
+Whether your computing environment is based on a single cloud provider, a combination of multiple cloud providers, or following a hybrid cloud approach, having a centralized identity management can help you to preserve existing infrastructure and avoid vendor lock-in.
+
+With the [App Identity and Access Adapter](https://github.com/ibm-cloud-security/app-identity-and-access-adapter), you can use any OAuth2/OIDC provider: IBM Cloud App ID, Auth0, Okta, Ping Identity, AWS Cognito, Azure AD B2C and more. Authentication and authorization policies can be applied in a streamlined way in all environments — including frontend and backend applications — all without code changes or redeploys.
+
+## Understanding Istio and the adapter
+
+[Istio](/docs/concepts/what-is-istio/) is an open source service mesh that transparently layers onto distributed applications and seamlessly integrates with Kubernetes. To reduce the complexity of deployments Istio provides behavioral insights and operational control over the service mesh as a whole. [See Istio Architecture for more details.](/docs/concepts/what-is-istio/#architecture)
+
+Istio uses [Envoy proxy sidecars](/blog/2019/data-plane-setup/) to mediate inbound and outbound traffic for all pods in the service mesh. Istio extracts telemetry from the Envoy sidecars and sends it to [Mixer](/docs/concepts/what-is-istio/#mixer), the Istio component responsible for collecting telemetry and policy enforcement.
+
+The App Identity and Access adapter extends the Mixer functionality by analyzing the telemetry (attributes) against various access control policies across the service mesh. The access control policies can be linked to a particular Kubernetes services and can be finely tuned to specific service endpoints. For more information about policies and telemetry, see the Istio documentation.
+
+When [App Identity and Access Adapter](https://github.com/ibm-cloud-security/app-identity-and-access-adapter) is combined with Istio, it provides a scalable, integrated identity and access solution for multicloud architectures that does not require any custom application code changes.
+
+## Installation
+
+App Identity and Access adapter can be installed using Helm directly from the `github.com` repository
+
+{{< text bash >}}
+$ helm repo add appidentityandaccessadapter https://raw.githubusercontent.com/ibm-cloud-security/app-identity-and-access-adapter/master/helm/appidentityandaccessadapter
+$ helm install --name appidentityandaccessadapter appidentityandaccessadapter/appidentityandaccessadapter
+{{< /text >}}
+
+Alternatively, you can clone the repo and install the Helm chart locally
+
+{{< text bash >}}
+$ git clone git@github.com:ibm-cloud-security/app-identity-and-access-adapter.git
+$ helm install ./helm/appidentityandaccessadapter --name appidentityandaccessadapter.
+{{< /text >}}
+
+## Protecting web applications
+
+Web applications are most commonly protected by the OpenID Connect (OIDC) workflow called `authorization_code`. When an unauthenticated/unauthorized user is detected, they are automatically redirected to the identity service of your choice and presented with the authentication page. When authentication completes, the browser is redirected back to an implicit `/oidc/callback` endpoint intercepted by the adapter. At this point, the adapter obtains access and identity tokens from the identity service and then redirects users back to their originally requested URL in the web app.
+
+Authentication state and tokens are maintained by the adapter. Each request processed by the adapter will include the Authorization header bearing both access and identity tokens in the following format `Authorization: Bearer `
+
+Developers can read leverage the tokens for application experience adjustments, e.g. displaying user name, adjusting UI based on user role etc.
+
+In order to terminate the authenticated session and wipe tokens, aka user logout, simply redirect browser to the `/oidc/logout` endpoint under the protected service, e.g. if you're serving your app from `https://example.com/myapp`, redirect users to `https://example.com/myapp/oidc/logout`
+
+Whenever access token expires, a refresh token is used to automatically acquire new access and identity tokens without your user's needing to re-authenticate. If the configured identity provider returns a refresh token, it is persisted by the adapter and used to retrieve new access and identity tokens when the old ones expire.
+
+### Applying web application protection
+
+Protecting web applications requires creating two types of resources - use `OidcConfig` resources to define various OIDC providers, and `Policy` resources to define the web app protection policies.
+
+{{< text yaml >}}
+apiVersion: "security.cloud.ibm.com/v1"
+kind: OidcConfig
+metadata:
+ name: my-oidc-provider-config
+ namespace: sample-namespace
+spec:
+ discoveryUrl:
+ clientId:
+ clientSecretRef:
+ name:
+ key:
+{{< /text >}}
+
+{{< text yaml >}}
+apiVersion: "security.cloud.ibm.com/v1"
+kind: Policy
+metadata:
+ name: my-sample-web-policy
+ namespace: sample-namespace
+spec:
+ targets:
+ - serviceName:
+ paths:
+ - prefix: /webapp
+ method: ALL
+ policies:
+ - policyType: oidc
+ config: my-oidc-provider-config
+ rules: // optional
+ - claim: iss
+ match: ALL
+ source: access_token
+ values:
+ -
+ - claim: scope
+ match: ALL
+ source: access_token
+ values:
+ - openid
+{{< /text >}}
+
+[Read more about protecting web applications](https://github.com/ibm-cloud-security/app-identity-and-access-adapter)
+
+## Protecting backend application and APIs
+
+Backend applications and APIs are protected using the Bearer Token flow, where an incoming token is validated against a particular policy. The Bearer Token authorization flow expects a request to contain the `Authorization` header with a valid access token in JWT format. The expected header structure is `Authorization: Bearer {access_token}`. In case token is successfully validated request will be forwarded to the requested service. In case token validation fails the HTTP 401 will be returned back to the client with a list of scopes that are required to access the API.
+
+### Applying backend application and APIs protection
+
+Protecting backend applications and APIs requires creating two types of resources - use `JwtConfig` resources to define various JWT providers, and `Policy` resources to define the backend app protection policies.
+
+{{< text yaml >}}
+apiVersion: "security.cloud.ibm.com/v1"
+kind: JwtConfig
+metadata:
+ name: my-jwt-config
+ namespace: sample-namespace
+spec:
+ jwksUrl:
+{{< /text >}}
+
+{{< text yaml >}}
+apiVersion: "security.cloud.ibm.com/v1"
+kind: Policy
+metadata:
+ name: my-sample-backend-policy
+ namespace: sample-namespace
+spec:
+ targets:
+ - serviceName:
+ paths:
+ - prefix: /api/files
+ method: ALL
+ policies:
+ - policyType: jwt
+ config: my-oidc-provider-config
+ rules: // optional
+ - claim: iss
+ match: ALL
+ source: access_token
+ values:
+ -
+ - claim: scope
+ match: ALL
+ source: access_token
+ values:
+ - files.read
+ - files.write
+{{< /text >}}
+
+[Read more about protecting backend applications](https://github.com/ibm-cloud-security/app-identity-and-access-adapter)
+
+## Known limitations
+
+At the time of writing this blog there are two known limitations of the App Identity and Access adapter:
+
+- If you use the App Identity and Access adapter for Web Applications you should not create more than a single replica of the adapter. Due to the way Envoy Proxy was handling HTTP headers it was impossible to return multiple `Set-Cookie` headers from Mixer back to Envoy. Therefore we couldn't set all the cookies required for handling Web Application scenarios. The issue was recently addressed in Envoy and Mixer and we're planning to address this in future versions of our adapter. **Note that this only affects Web Applications, and doesn't affect Backend Apps and APIs in any way**.
+
+- As a general best practice you should always consider using mutual-tls for any in-cluster communications. At the moment the communications channel between Mixer and App Identity and Access adapter currently does not use mutual-tls. In future we plan to address this by implementing an approach described in the [Mixer Adapter developer guide](https://github.com/istio/istio/wiki/Mixer-Out-of-Process-Adapter-Walkthrough#step-7-encrypt-connection-between-mixer-and-grpc-adapter).
+
+## Summary
+
+When a multicloud strategy is in place, security can become complicated as the environment grows and diversifies. While cloud providers supply protocols and tools to ensure their offerings are safe, the development teams are still responsible for the application-level security, such as API access control with OAuth2, defending against man-in-the-middle attacks with traffic encryption, and providing mutual TLS for service access control. However, this becomes complex in a multicloud environment since you might need to define those security details for each service separately. With proper security protocols in place, those external and internal threats can be mitigated.
+
+Development teams have spent time making their services portable to different cloud providers, and in the same regard, the security in place should be flexible and not infrastructure-dependent.
+
+Istio and App Identity and Access Adapter allow you to secure your Kubernetes apps with absolutely zero code changes or redeployments regardless of which programming language and which frameworks you use. Following this approach ensures maximum portability of your apps, and ability to easily enforce same security policies across multiple environments.
+
+You can read more about the App Identity and Access Adapter in the [release blog](https://www.ibm.com/cloud/blog/using-istio-to-secure-your-multicloud-kubernetes-applications-with-zero-code-change).
diff --git a/content/en/blog/2019/data-plane-setup/arch-2.svg b/content/en/blog/2019/data-plane-setup/arch-2.svg
index 9cc2425b7ebe..a572bb34d5c2 100644
--- a/content/en/blog/2019/data-plane-setup/arch-2.svg
+++ b/content/en/blog/2019/data-plane-setup/arch-2.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2019/egress-traffic-control-in-istio-part-2/SecurityArchitectureWithL3Firewalls.svg b/content/en/blog/2019/egress-traffic-control-in-istio-part-2/SecurityArchitectureWithL3Firewalls.svg
index 694e34f74a18..256c6c89e610 100644
--- a/content/en/blog/2019/egress-traffic-control-in-istio-part-2/SecurityArchitectureWithL3Firewalls.svg
+++ b/content/en/blog/2019/egress-traffic-control-in-istio-part-2/SecurityArchitectureWithL3Firewalls.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/blog/2019/evolving-istios-apis/index.md b/content/en/blog/2019/evolving-istios-apis/index.md
index 07c542bb3024..3714a607f734 100644
--- a/content/en/blog/2019/evolving-istios-apis/index.md
+++ b/content/en/blog/2019/evolving-istios-apis/index.md
@@ -6,7 +6,7 @@ attribution: Louis Ryan (Google), Sandeep Parikh (Google)
keywords: [apis,composability,evolution]
---
-One of Istio’s main goals has always been, and continues to be, enabling teams to develop abstractions that work best for their specific organization and workloads. Istio provides robust and powerful building blocks for service-to-service networking. Since [version 0.1](/blog/2017/0.1-announcement/), the Istio team has been learning from production users about how they map their own architectures, workloads, and constraints to Istio’s capabilities, and we’ve been evolving Istio’s APIs to make them work better for you.
+One of Istio’s main goals has always been, and continues to be, enabling teams to develop abstractions that work best for their specific organization and workloads. Istio provides robust and powerful building blocks for service-to-service networking. Since [Istio 0.1](/news/2017/announcing-0.1), the Istio team has been learning from production users about how they map their own architectures, workloads, and constraints to Istio’s capabilities, and we’ve been evolving Istio’s APIs to make them work better for you.
## Evolving Istio’s APIs
@@ -34,7 +34,13 @@ It sounds complicated, but not everyone needs to interact with those concepts. S
Another example of composability in the networking space can be found in the [Google Cloud HTTP(S) Load Balancer](https://cloud.google.com/load-balancing/docs/https/) (GCLB). To correctly use an instance of the GCLB, six different infrastructure objects need to be created and configured. This design is the result of our 20 years of experience in operating distributed systems and [there is a reason why each one is separate from the others](https://www.youtube.com/watch?v=J5HJ1y6PeyE). But the steps are simplified when you’re creating an instance via the Google Cloud console. We provide the more common end-user/role-specific configurations, and you can configure less common settings later. Ultimately, the goals of infrastructure APIs are to offer the most flexibility without sacrificing functionality.
-[Knative](http://knative.dev) is a platform for building, running, and operating serverless workloads that provides a great real-world example of role-centric, higher-level APIs. [Knative Serving](https://knative.dev/docs/serving/), a component of Knative that builds on Kubernetes and Istio to support deploying and serving serverless applications and functions, provides an opinionated workflow for application developers to manage routes and revisions of their services. Thanks to that opinionated approach, Knative Serving exposes a subset of Istio’s networking APIs that are most relevant to application developers via a simplified [Routes](https://github.com/knative/serving/blob/master/docs/spec/spec.md#route) object that supports revisions and traffic routing, abstracting Istio’s [virtual service](/docs/reference/config/networking/v1alpha3/virtual-service/)s and [destination rule](/docs/reference/config/networking/v1alpha3/destination-rule/)s resources.
+[Knative](http://knative.dev) is a platform for building, running, and operating serverless workloads that provides a great real-world example of role-centric,
+higher-level APIs. [Knative Serving](https://knative.dev/docs/serving/), a component of Knative that builds on Kubernetes and Istio to support deploying and
+serving serverless applications and functions, provides an opinionated workflow for application developers to manage routes and revisions of their services.
+Thanks to that opinionated approach, Knative Serving exposes a subset of Istio’s networking APIs that are most relevant to application developers via a simplified
+[Routes](https://github.com/knative/docs/blob/master/docs/serving/spec/knative-api-specification-1.0.md#route) object that supports revisions and traffic routing,
+abstracting Istio’s [`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/) and [`DestinationRule`](/docs/reference/config/networking/v1alpha3/destination-rule/)
+resources.
As Istio has matured, we’ve also seen production users develop workload- and organization-specific abstractions on top of Istio’s infrastructure APIs.
diff --git a/content/en/blog/2019/knative-activator-adapter/index.md b/content/en/blog/2019/knative-activator-adapter/index.md
new file mode 100644
index 000000000000..1d33abf7f5f4
--- /dev/null
+++ b/content/en/blog/2019/knative-activator-adapter/index.md
@@ -0,0 +1,80 @@
+---
+title: Mixer out-of-process adapter for Knative
+subtitle: Demonstrates a Mixer out-of-process adapter which implements the Knative scale-from-zero logic
+description: Demonstrates a Mixer out-of-process adapter which implements the Knative scale-from-zero logic.
+publishdate: 2019-09-18
+attribution: Idan Zach (IBM)
+keywords: [mixer,adapter,knative,scale-from-zero]
+---
+
+This post demonstrates how you can use [Mixer](/faq/mixer/) to push application logic
+into Istio. It describes a Mixer adapter which implements the [Knative](https://knative.dev/) scale-from-zero logic
+with simple code and similar performance to the original implementation.
+
+## Knative serving
+
+[Knative Serving](https://knative.dev/docs/serving/) builds on [Kubernetes](https://kubernetes.io/) to support deploying
+and serving of serverless applications. A core capability of serverless platforms is scale-to-zero
+functionality which reduces resource usage and cost of inactive workloads.
+A new mechanism is required to scale from zero when an idle application receives a new request.
+
+The following diagram represents the current Knative architecture for scale-from-zero.
+
+{{< image width="60%" link="knative-activator.png" caption="Knative scale-from-zero" >}}
+
+The traffic for an idle application is redirected to **Activator** component by programming Istio with `VirtualServices`
+and `DestinationRules`. When **Activator** receives a new request, it:
+
+1. buffers incoming requests
+1. triggers the **Autoscaler**
+1. redirects requests to the application after it has been scaled up, including retries and load-balancing (if needed)
+
+Once the application is up and running again, Knative restores the routing from **Activator** to the running application.
+
+## Mixer adapter
+
+[Mixer](/faq/mixer/) provides a rich intermediation layer between the Istio components and infrastructure backends.
+It is designed as a stand-alone component, separate from [Envoy](https://www.envoyproxy.io/), and has a simple extensibility model
+to enable Istio to interoperate with a wide breadth of backends. Mixer is inherently easier to extend
+than Envoy is.
+
+Mixer is an attribute processing engine that uses operator-supplied configuration to map request attributes from the Istio proxy into calls
+to the infrastructure backends systems via a pluggable set of adapters. Adapters enable **Mixer** to expose a single consistent API, independent of the
+infrastructure backends in use. The exact set of adapters used at runtime is determined through operator configuration and can easily
+be extended to target new or custom infrastructure backends.
+
+In order to achieve Knative scale-from-zero, we use a Mixer [out-of-process adapter](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide)
+to call the Autoscaler. Out-of-process adapters for Mixer allow developers to use any
+programming language and to build and maintain your extension as a stand-alone program
+without the need to build the Istio proxy.
+
+The following diagram represents the Knative design using the **Mixer** adapter.
+
+{{< image width="60%" link="knative-mixer-adapter.png" caption="Knative scale-from-zero" >}}
+
+In this design, there is no need to change the routing from/to **Activator** for an idle application as in the original Knative setup.
+When the Istio proxy represented by the ingress gateway component receives a new request for an idle application, it informs **Mixer**, including all the
+relevant metadata information.
+**Mixer** then calls your adapter which triggers the Knative **Autoscaler** using the original Knative protocol.
+
+{{< idea >}}
+By using this design you do not need to deal with buffering, retries and load-balancing because it is already handled by the Istio proxy.
+{{< /idea >}}
+
+Istio's use of Mixer adapters makes it possible to replace otherwise complex networking-based application logic with a more
+straightforward implementation, as demonstrated in the [Knative adapter](https://github.com/zachidan/istio-kactivator).
+
+When the adapter receives a message from **Mixer**, it sends a `StatMessage` directly to **Autoscaler**
+component using the Knative protocol.
+The metadata information (`namespace` and `service name`) required by **Autoscaler** are transferred by Istio proxy to
+**Mixer** and from there to the adapter.
+
+## Summary
+
+I compared the cold-start time of the original Knative reference architecture to the new Istio Mixer adapter reference architecture.
+The results show similar cold-start times.
+The implementation using the Mixer adapter has greater simplicity. It is not necessary to handle low-level network-based mechanisms as these are handled by Envoy.
+
+The next step is converting this Mixer adapter into an Envoy-specific filter running inside an ingress gateway.
+This will allow to further improve the latency overhead (no more calls to **Mixer** and the adapter) and
+to remove the dependency on the Istio Mixer.
diff --git a/content/en/blog/2019/knative-activator-adapter/knative-activator.png b/content/en/blog/2019/knative-activator-adapter/knative-activator.png
new file mode 100644
index 000000000000..c98b7fbe675a
Binary files /dev/null and b/content/en/blog/2019/knative-activator-adapter/knative-activator.png differ
diff --git a/content/en/blog/2019/knative-activator-adapter/knative-mixer-adapter.png b/content/en/blog/2019/knative-activator-adapter/knative-mixer-adapter.png
new file mode 100644
index 000000000000..f1b6e0cc2004
Binary files /dev/null and b/content/en/blog/2019/knative-activator-adapter/knative-mixer-adapter.png differ
diff --git a/content/en/blog/2019/monitoring-external-service-traffic/index.md b/content/en/blog/2019/monitoring-external-service-traffic/index.md
new file mode 100644
index 000000000000..4407edc03a1f
--- /dev/null
+++ b/content/en/blog/2019/monitoring-external-service-traffic/index.md
@@ -0,0 +1,371 @@
+---
+title: "Monitoring blocked and passthrough external service traffic"
+description: "How can you use Istio to monitor blocked and passthrough external traffic."
+publishdate: 2019-09-28
+attribution: Neeraj Poddar (Aspen Mesh)
+keywords: [monitoring,blackhole,passthrough]
+---
+
+Understanding, controlling and securing your external service access is one
+of the key benefits that you get from a service mesh like Istio. From a security
+and operations point of view, it is critical to monitor what external service traffic
+is getting blocked as they might surface possible misconfigurations or a
+security vulnerability if an application is attempting to communicate with a
+service that it should not be allowed to. Similarly, if you currently have a
+policy of allowing any external service access, it is beneficial to monitor
+the traffic so you can incrementally add explicit Istio configuration to allow
+access and better security your cluster. In either case, having visibility into this
+traffic via telemetry is quite helpful as it enables you to create alerts and
+dashboards, and better reason about your security posture. This was a highly
+requested feature by production users of Istio and we are excited that the
+support for this was added in release 1.3.
+
+To implement this, the Istio [default
+metrics](/docs/reference/config/policy-and-telemetry/metrics) are augmented with
+explicit labels to capture blocked and passthrough external service traffic.
+This blog will cover how you can use these augmented metrics to monitor all
+external service traffic.
+
+The Istio control plane configures the sidecar proxy with
+predefined clusters called BlackHoleCluster and Passthrough which block or
+allow all traffic respectively. To understand these clusters, let's start with
+what external and internal services mean in the context of Istio service mesh.
+
+## External and internal services
+
+Internal services are defined as services which are part of your platform
+and are considered to be in the mesh. For internal services, Istio control
+plane provides all the required configuration to the sidecars by default.
+For example, in Kubernetes clusters, Istio configures the sidecars for all
+Kubernetes services to preserve the default Kubernetes behavior of all
+services being able to communicate with other.
+
+External services are services which are not part of your platform i.e. services
+which are outside of the mesh. For external services, Istio provides two
+options, first to block all external service access (enabled by setting
+`global.outboundTrafficPolicy.mode` to `REGISTRY_ONLY`) and
+second to allow all access to external service (enabled by setting
+`global.outboundTrafficPolicy.mode` to `ALLOW_ANY`). The default option for this
+setting (as of Istio 1.3) is to allow all external service access. This
+option can be configured via [mesh configuration](/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-Mode).
+
+This is where the BlackHole and Passthrough clusters are used.
+
+## What are BlackHole and Passthrough clusters?
+
+* **BlackHoleCluster** - The BlackHoleCluster is a virtual cluster created
+ in the Envoy configuration when `global.outboundTrafficPolicy.mode` is set to
+ `REGISTRY_ONLY`. In this mode, all traffic to external service is blocked unless
+ [service entries](/docs/reference/config/networking/v1alpha3/service-entry)
+ are explicitly added for each service. To implement this, the default virtual
+ outbound listener at `0.0.0.0:15001` which uses
+ [original destination](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#original-destination)
+ is setup as a TCP Proxy with the BlackHoleCluster as the static cluster.
+ The configuration for the BlackHoleCluster looks like this:
+
+ {{< text json >}}
+ {
+ "name": "BlackHoleCluster",
+ "type": "STATIC",
+ "connectTimeout": "10s"
+ }
+ {{< /text >}}
+
+ As you can see, this cluster is static with no endpoints so all the traffic
+ will be dropped. Additionally, Istio creates unique listeners for every
+ port/protocol combination of platform services which gets hit instead of the
+ virtual listener if the request is made to an external service on the same port.
+ In that case, the route configuration of every virtual route in Envoy is augmented to
+ add the BlackHoleCluster like this:
+
+ {{< text json >}}
+ {
+ "name": "block_all",
+ "domains": [
+ "*"
+ ],
+ "routes": [
+ {
+ "match": {
+ "prefix": "/"
+ },
+ "directResponse": {
+ "status": 502
+ }
+ }
+ ]
+ }
+ {{< /text >}}
+
+ The route is setup as [direct response](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route.proto#envoy-api-msg-route-directresponseaction)
+ with `502` response code which means if no other routes match the Envoy proxy
+ will directly return a `502` HTTP status code.
+
+* **PassthroughCluster** - The PassthroughCluster is a virtual cluster created
+ in the Envoy configuration when `global.outboundTrafficPolicy.mode` is set to
+ `ALLOW_ANY`. In this mode, all traffic to any external service external is allowed.
+ To implement this, the default virtual outbound listener at `0.0.0.0:15001`
+ which uses `SO_ORIGINAL_DST`, is setup as a TCP Proxy with the PassthroughCluster
+ as the static cluster.
+ The configuration for the PassthroughCluster looks like this:
+
+ {{< text json >}}
+ {
+ "name": "PassthroughCluster",
+ "type": "ORIGINAL_DST",
+ "connectTimeout": "10s",
+ "lbPolicy": "ORIGINAL_DST_LB",
+ "circuitBreakers": {
+ "thresholds": [
+ {
+ "maxConnections": 102400,
+ "maxRetries": 1024
+ }
+ ]
+ }
+ }
+ {{< /text >}}
+
+ This cluster uses the [original destination load balancing](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/service_discovery#original-destination)
+ policy which configures Envoy to send the traffic to the
+ original destination i.e. passthrough.
+
+ Similar to the BlackHoleCluster, for every port/protocol based listener the
+ virtual route configuration is augmented to add the PassthroughCluster as the
+ default route:
+
+ {{< text json >}}
+ {
+ "name": "allow_any",
+ "domains": [
+ "*"
+ ],
+ "routes": [
+ {
+ "match": {
+ "prefix": "/"
+ },
+ "route": {
+ "cluster": "PassthroughCluster"
+ }
+ }
+ ]
+ }
+ {{< /text >}}
+
+Prior to Istio 1.3, there were no metrics reported or if metrics were reported
+there were no explicit labels set when traffic hit these clusters, resulting in
+lack of visibility in traffic flowing through the mesh.
+
+The next section covers how to take advantage of this enhancement as the metrics
+and labels emitted are conditional on whether the virtual outbound or explicit port/protocol
+listener is being hit.
+
+## Using the augmented metrics
+
+To capture all external service traffic in either of the cases (BlackHole or
+Passthrough), you will need to monitor `istio_requests_total` and
+`istio_tcp_connections_closed_total` metrics. Depending upon the Envoy listener
+type i.e. TCP proxy or HTTP proxy that gets invoked, one of these metrics
+will be incremented.
+
+Additionally, in case of a TCP proxy listener in order to see the IP address of
+the external service that is blocked or allowed via BlackHole or Passthrough
+cluster, you will need to add the `destination_ip` label to the
+`istio_tcp_connections_closed_total` metric. In this scenario, the host name of
+the external service is not captured. This label is not added by default and can
+be easily added by augmenting the Istio configuration for attribute generation
+and Prometheus handler. You should be careful about cardinality explosion in
+time series if you have many services with non-stable IP addresses.
+
+### PassthroughCluster metrics
+
+This section explains the metrics and the labels emitted based on the listener
+type invoked in Envoy.
+
+* HTTP proxy listener: This happens when the port of the external service is
+ same as one of the service ports defined in the cluster. In this scenario,
+ when the PassthroughCluster is hit, `istio_requests_total` will get increased
+ like this:
+
+ {{< text json >}}
+ {
+ "metric": {
+ "__name__": "istio_requests_total",
+ "connection_security_policy": "unknown",
+ "destination_app": "unknown",
+ "destination_principal": "unknown",
+ "destination_service": "httpbin.org",
+ "destination_service_name": "PassthroughCluster",
+ "destination_service_namespace": "unknown",
+ "destination_version": "unknown",
+ "destination_workload": "unknown",
+ "destination_workload_namespace": "unknown",
+ "instance": "100.96.2.183:42422",
+ "job": "istio-mesh",
+ "permissive_response_code": "none",
+ "permissive_response_policyid": "none",
+ "reporter": "source",
+ "request_protocol": "http",
+ "response_code": "200",
+ "response_flags": "-",
+ "source_app": "sleep",
+ "source_principal": "unknown",
+ "source_version": "unknown",
+ "source_workload": "sleep",
+ "source_workload_namespace": "default"
+ },
+ "value": [
+ 1567033080.282,
+ "1"
+ ]
+ }
+ {{< /text >}}
+
+ Note that the `destination_service_name` label is set to PassthroughCluster to
+ indicate that this cluster was hit and the `destination_service` is set to the
+ host of the external service.
+
+* TCP proxy virtual listener - If the external service port doesn't map to any
+ HTTP based service ports within the cluster, this listener is invoked and
+ `istio_tcp_connections_closed_total` is the metric that will be increased:
+
+ {{< text json >}}
+ {
+ "status": "success",
+ "data": {
+ "resultType": "vector",
+ "result": [
+ {
+ "metric": {
+ "__name__": "istio_tcp_connections_closed_total",
+ "connection_security_policy": "unknown",
+ "destination_app": "unknown",
+ "destination_ip": "52.22.188.80",
+ "destination_principal": "unknown",
+ "destination_service": "unknown",
+ "destination_service_name": "PassthroughCluster",
+ "destination_service_namespace": "unknown",
+ "destination_version": "unknown",
+ "destination_workload": "unknown",
+ "destination_workload_namespace": "unknown",
+ "instance": "100.96.2.183:42422",
+ "job": "istio-mesh",
+ "reporter": "source",
+ "response_flags": "-",
+ "source_app": "sleep",
+ "source_principal": "unknown",
+ "source_version": "unknown",
+ "source_workload": "sleep",
+ "source_workload_namespace": "default"
+ },
+ "value": [
+ 1567033761.879,
+ "1"
+ ]
+ }
+ ]
+ }
+ }
+ {{< /text >}}
+
+ In this case, `destination_service_name` is set to PassthroughCluster and
+ the `destination_ip` is set to the IP address of the external service.
+ The `destination_ip` label can be used to do a reverse DNS lookup and
+ get the host name of the external service. As this cluster is passthrough,
+ other TCP related metrics like `istio_tcp_connections_opened_total`,
+ `istio_tcp_received_bytes_total` and `istio_tcp_sent_bytes_total` are also
+ updated.
+
+### BlackHoleCluster metrics
+
+Similar to the PassthroughCluster, this section explains the metrics and the
+labels emitted based on the listener type invoked in Envoy.
+
+* HTTP proxy listener: This happens when the port of the external service is same
+ as one of the service ports defined in the cluster.
+ In this scenario, when the BlackHoleCluster is hit,
+ `istio_requests_total` will get increased like this:
+
+ {{< text json >}}
+ {
+ "metric": {
+ "__name__": "istio_requests_total",
+ "connection_security_policy": "unknown",
+ "destination_app": "unknown",
+ "destination_principal": "unknown",
+ "destination_service": "httpbin.org",
+ "destination_service_name": "BlackHoleCluster",
+ "destination_service_namespace": "unknown",
+ "destination_version": "unknown",
+ "destination_workload": "unknown",
+ "destination_workload_namespace": "unknown",
+ "instance": "100.96.2.183:42422",
+ "job": "istio-mesh",
+ "permissive_response_code": "none",
+ "permissive_response_policyid": "none",
+ "reporter": "source",
+ "request_protocol": "http",
+ "response_code": "502",
+ "response_flags": "-",
+ "source_app": "sleep",
+ "source_principal": "unknown",
+ "source_version": "unknown",
+ "source_workload": "sleep",
+ "source_workload_namespace": "default"
+ },
+ "value": [
+ 1567034251.717,
+ "1"
+ ]
+ }
+ {{< /text >}}
+
+ Note the `destination_service_name` label is set to BlackHoleCluster and the
+ `destination_service` to the host name of the external service. The response
+ code should always be `502` in this case.
+
+* TCP proxy virtual listener - If the external service port doesn't map to any
+ HTTP based service ports within the cluster, this listener is invoked and
+ `istio_tcp_connections_closed_total` is the metric that will be increased:
+
+ {{< text json >}}
+ {
+ "metric": {
+ "__name__": "istio_tcp_connections_closed_total",
+ "connection_security_policy": "unknown",
+ "destination_app": "unknown",
+ "destination_ip": "52.22.188.80",
+ "destination_principal": "unknown",
+ "destination_service": "unknown",
+ "destination_service_name": "BlackHoleCluster",
+ "destination_service_namespace": "unknown",
+ "destination_version": "unknown",
+ "destination_workload": "unknown",
+ "destination_workload_namespace": "unknown",
+ "instance": "100.96.2.183:42422",
+ "job": "istio-mesh",
+ "reporter": "source",
+ "response_flags": "-",
+ "source_app": "sleep",
+ "source_principal": "unknown",
+ "source_version": "unknown",
+ "source_workload": "sleep",
+ "source_workload_namespace": "default"
+ },
+ "value": [
+ 1567034481.03,
+ "1"
+ ]
+ }
+ {{< /text >}}
+
+ Note the `destination_ip` label represents the IP address of the external
+ service and the `destination_service_name` is set to BlackHoleCluster
+ to indicate that this traffic was blocked by the mesh. Is is interesting to
+ note that for the BlackHole cluster case, other TCP related metrics like
+ `istio_tcp_connections_opened_total` are not increased as there's no
+ connection that is ever established.
+
+Monitoring these metrics can help operators easily understand all the external
+services consumed by the applications in their cluster.
diff --git a/content/en/blog/2019/multicluster-version-routing/index.md b/content/en/blog/2019/multicluster-version-routing/index.md
index 11b6e0555dcf..c63dfe2e4dd4 100644
--- a/content/en/blog/2019/multicluster-version-routing/index.md
+++ b/content/en/blog/2019/multicluster-version-routing/index.md
@@ -19,7 +19,7 @@ can, more-or-less transparently, be part of a mesh where the services are runnin
in more than one cluster, i.e., in a
[multi-cluster deployment](/docs/concepts/deployment-models/#multiple-clusters).
The simplest way to setup a multi-cluster mesh, because it has no special networking requirements,
-is using a simple
+is using a replicated
[control plane model](/docs/concepts/deployment-models/#control-plane-models).
In this configuration, each Kubernetes cluster contributing to the mesh has its own control plane,
but each control plane is synchronized and running under a single administrative control.
@@ -36,7 +36,7 @@ running in one cluster, versions `v2` and `v3` running in a second cluster.
To start, you'll need two Kubernetes clusters, both running a slightly customized configuration of Istio.
* Set up a multicluster environment with two Istio clusters by following the
- [dedicated control planes](/docs/setup/install/multicluster/gateways/) instructions.
+ [replicated control planes](/docs/setup/install/multicluster/gateways/) instructions.
* The `kubectl` command is used to access both clusters with the `--context` flag.
Use the following command to list your contexts:
@@ -299,7 +299,7 @@ spec:
protocol: http
resolution: DNS
addresses:
- - 127.255.0.3
+ - 240.0.0.3
endpoints:
- address: ${CLUSTER2_GW_ADDR}
labels:
@@ -326,8 +326,8 @@ spec:
EOF
{{< /text >}}
-The address `127.255.0.3` of the service entry can be any arbitrary unallocated IP.
-Using an IP from the loopback range 127.0.0.0/8 is a good choice.
+The address `240.0.0.3` of the service entry can be any arbitrary unallocated IP.
+Using an IP from the class E addresses range 240.0.0.0/4 is a good choice.
Check out the
[gateway-connected multicluster example](/docs/setup/install/multicluster/gateways/#configure-the-example-services)
for more details.
@@ -453,8 +453,7 @@ only see reviews without ratings (`v1`).
## Summary
In this article, we've seen how to use Istio route rules to distribute the versions of a service
-across clusters in a multicluster service mesh with a suitable
-[control plane model](/docs/concepts/deployment-models/#control-plane-models).
+across clusters in a multicluster service mesh with a replicated control plane model.
In this example, we manually configured the `.global` service entry and destination rules needed to provide
connectivity to one remote service, `reviews`. In general, however, if we wanted to enable any service
to run either locally or remotely, we would need to create `.global` resources for every service.
diff --git a/content/en/blog/2019/performance-best-practices/index.md b/content/en/blog/2019/performance-best-practices/index.md
index 882662f00811..49715ee990af 100644
--- a/content/en/blog/2019/performance-best-practices/index.md
+++ b/content/en/blog/2019/performance-best-practices/index.md
@@ -10,7 +10,7 @@ keywords: [performance,scalability,scale,benchmarks]
Service meshes add a lot of functionality to application deployments, including [traffic policies](/docs/concepts/what-is-istio/#traffic-management), [observability](/docs/concepts/what-is-istio/#observability), and [secure communication](/docs/concepts/what-is-istio/#security). But adding a service mesh to your environment comes at a cost, whether that's time (added latency) or resources (CPU cycles). To make an informed decision on whether a service mesh is right for your use case, it's important to evaluate how your application performs when deployed with a service mesh.
-Earlier this year, we published a [blog post](/blog/2019/istio1.1_perf/) on Istio's performance improvements in version 1.1. Following the release of [Istio 1.2](/about/notes/1.2/), we want to provide guidance and tools to help you benchmark Istio's data plane performance in a production-ready Kubernetes environment.
+Earlier this year, we published a [blog post](/blog/2019/istio1.1_perf/) on Istio's performance improvements in version 1.1. Following the release of [Istio 1.2](/news/2019/announcing-1.2), we want to provide guidance and tools to help you benchmark Istio's data plane performance in a production-ready Kubernetes environment.
Overall, we found that Istio's [sidecar proxy](/docs/concepts/what-is-istio/#envoy) latency scales with the number of concurrent connections. At 1000 requests per second (RPS), across 16 connections, Istio adds **3 milliseconds** per request in the 50th percentile, and **10 milliseconds** in the 99th percentile.
diff --git a/content/en/blog/2019/sail-the-blog/index.md b/content/en/blog/2019/sail-the-blog/index.md
index 200a1e215a79..fb969351d8e3 100644
--- a/content/en/blog/2019/sail-the-blog/index.md
+++ b/content/en/blog/2019/sail-the-blog/index.md
@@ -2,6 +2,7 @@
title: Sail the Blog!
description: Announces the new Istio blog policy.
publishdate: 2019-02-05
+last_update: 2019-09-27
attribution: Rigs Caballero, Google
keywords: [community,blog,contribution,guide,guideline,event]
---
@@ -13,7 +14,7 @@ To make it easier to publish your content on our website, we
The goal of the updated guide is to make sharing and finding content easier.
-We want to make sharing timely information on Istio easy and the Istio blog is
+We want to make sharing timely information on Istio easy and the [Istio blog](/blog) is
a good place to start.
We welcome your posts to the blog if you think your content falls in one of the
@@ -21,8 +22,7 @@ following four categories:
- Your post details your experience using and configuring Istio. Ideally, your
post shares a novel experience or perspective.
-- Your post highlights or announces Istio features.
-- Your post announces or recaps an Istio-related event.
+- Your post highlights Istio features.
- Your post details how to accomplish a task or fulfill a specific use case
using Istio.
diff --git a/content/en/boilerplates/notes/0.1.md b/content/en/boilerplates/notes/0.1.md
deleted file mode 100644
index b749d0c0a5d1..000000000000
--- a/content/en/boilerplates/notes/0.1.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## General
-
-- Installation of Istio into a Kubernetes namespace with a single command.
-- Semi-automated injection of Envoy proxies into Kubernetes pods.
-- Automatic traffic capture for Kubernetes pods using iptables.
-- In-cluster load balancing for HTTP, gRPC, and TCP traffic.
-- Support for timeouts, retries with budgets, and circuit breakers.
-- Istio-integrated Kubernetes Ingress support (Istio acts as an Ingress Controller).
-- Fine-grained traffic routing controls, including A/B testing, canarying, red/black deployments.
-- Flexible in-memory rate limiting.
-- L7 telemetry and logging for HTTP and gRPC using Prometheus.
-- Grafana dashboards showing per-service L7 metrics.
-- Request tracing through Envoy with Zipkin.
-- Service-to-service authentication using mutual TLS.
-- Simple service-to-service authorization using deny expressions.
diff --git a/content/en/boilerplates/notes/1.0.6.md b/content/en/boilerplates/notes/1.0.6.md
deleted file mode 100644
index 8ccf8d071f78..000000000000
--- a/content/en/boilerplates/notes/1.0.6.md
+++ /dev/null
@@ -1,12 +0,0 @@
-## Security vulnerability fixes
-
-- Updated Go `requests` and `urllib3` libraries in Bookinfo sample code per [`CVE-2018-18074`](https://nvd.nist.gov/vuln/detail/CVE-2018-18074) and [`CVE-2018-20060`](https://nvd.nist.gov/vuln/detail/CVE-2018-20060).
-- Fixed username and password being exposed in `Grafana` and `Kiali` ([Issue 7446](https://github.com/istio/istio/issues/7476), [Issue 7447](https://github.com/istio/istio/issues/7447)). If you have trouble to start the `Grafana` pod after upgrade to 1.0.6, please follow [the steps]({{< github_tree >}}/install/kubernetes/helm/istio#installing-the-chart) to create the secrete first.
-- Removed in-memory service registry in Pilot. This allowed adding endpoints to proxy configurations from within the cluster through a Pilot debug API.
-
-## Robustness improvements
-
-- Fixed Pilot failing to push configuration under load ([Issue 10360](https://github.com/istio/istio/issues/10360)).
-- Fixed a race condition that would lead Pilot to crash and restart ([Issue 10868](https://github.com/istio/istio/issues/10868)).
-- Fixed a memory leak in Pilot ([Issue 10822](https://github.com/istio/istio/issues/10822)).
-- Fixed a memory leak in Mixer ([Issue 10393](https://github.com/istio/istio/issues/10393)).
diff --git a/content/en/boilerplates/notes/1.0.9.md b/content/en/boilerplates/notes/1.0.9.md
deleted file mode 100644
index 83772af4f9bb..000000000000
--- a/content/en/boilerplates/notes/1.0.9.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Bug fixes
-
-- Fix crash in Istio's JWT Envoy filter caused by malformed JWT ([Issue 15084](https://github.com/istio/istio/issues/15084)).
diff --git a/content/en/boilerplates/notes/1.0.md b/content/en/boilerplates/notes/1.0.md
deleted file mode 100644
index c9599be92bbc..000000000000
--- a/content/en/boilerplates/notes/1.0.md
+++ /dev/null
@@ -1,93 +0,0 @@
-## Networking
-
-- **SNI Routing using Virtual Services**. Newly introduced `TLS` sections in
-[`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/) can be used to route TLS traffic
-based on SNI values. Service ports named as TLS/HTTPS can be used in conjunction with
-virtual service TLS routes. TLS/HTTPS ports without an accompanying virtual service will be treated as opaque TCP.
-
-- **Streaming gRPC Restored**. Istio 0.8 caused periodic termination of long running streaming gRPC connections. This has been fixed in 1.0.
-
-- **Old (v1alpha1) Networking APIs Removed**. Support for the old `v1alpha1` traffic management model
-has been removed.
-
-- **Istio Ingress Deprecated**. The old Istio ingress is deprecated and disabled by default. We encourage users to use [gateways](/docs/concepts/traffic-management/#gateways) instead.
-
-## Policy and Telemetry
-
-- **Updated Attributes**. The set of [attributes](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/) used to describe the source and
-destination of traffic have been completely revamped in order to be more
-precise and comprehensive.
-
-- **Policy Check Cache**. Mixer now features a large level 2 cache for policy checks, complementing the level 1 cache
-present in the sidecar proxy. This further reduces the average latency of externally-enforced
-policy checks.
-
-- **Telemetry Buffering**. Mixer now buffers report calls before dispatching to adapters, which gives an opportunity for
-adapters to process telemetry data in bigger chunks, reducing overall computational overhead
-in Mixer and its adapters.
-
-- **Out of Process Adapters**. Mixer now includes initial support for out-of-process adapters. This will
-be the recommended approach moving forward for integrating with Mixer. Initial documentation on
-how to build an out-of-process adapter is provided by the
-[Out Of Process Adapter Dev Guide](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide)
-and the [Out Of Process Adapter Walk-through](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Walkthrough).
-
-- **Client-Side Telemetry**. It's now possible to collect telemetry from the client of an interaction,
-in addition to the server-side telemetry.
-
-### Adapters
-
-- **SignalFX**. There is a new [`signalfx`](/docs/reference/config/policy-and-telemetry/adapters/signalfx/) adapter.
-
-- **Stackdriver**. The [`stackdriver`](/docs/reference/config/policy-and-telemetry/adapters/stackdriver/) adapter has been substantially enhanced in this
-release to add new features and improve performance.
-
-## Security
-
-- **Authorization**. We've reimplemented our [authorization functionality](/docs/concepts/security/#authorization).
-RPC-level authorization policies can now be implemented without the need for Mixer and Mixer adapters.
-
-- **Improved Mutual TLS Authentication Control**. It's now easier to [control mutual TLS authentication](/docs/concepts/security/#authentication) between services. We provide 'PERMISSIVE' mode so that you can
-[incrementally turn on mutual TLS](/docs/tasks/security/mtls-migration/) for your services.
-We removed service annotations and have a [unique approach to turn on mutual TLS](/docs/tasks/security/authn-policy/),
-coupled with client-side [destination rules](/docs/concepts/traffic-management/#destination-rules).
-
-- **JWT Authentication**. We now support [JWT authentication](/docs/concepts/security/#authentication) which can
-be configured using [authentication policies](/docs/concepts/security/#authentication-policies).
-
-## `istioctl`
-
-- Added the [`istioctl authn tls-check`](/docs/reference/commands/istioctl/#istioctl-authn-tls-check) command.
-
-- Added the [`istioctl proxy-status`](/docs/reference/commands/istioctl/#istioctl-proxy-status) command.
-
-- Added the `istioctl experimental convert-ingress` command.
-
-- Removed the `istioctl experimental convert-networking-config` command.
-
-- Enhancements and bug fixes:
-
- - Align `kubeconfig` handling with `kubectl`
-
- - `istioctl get all` returns all types of networking and authentication configuration.
-
- - Added the `--all-namespaces` flag to `istioctl get` to retrieve resources across all namespaces.
-
-## Known issues with 1.0
-
-- Amazon's EKS service does not implement automatic sidecar injection. Istio can be used in Amazon's
- EKS by using [manual injection](/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection) for
- sidecars and turning off galley using the [Helm parameter](/docs/setup/install/helm)
- `--set galley.enabled=false`.
-
-- In a [multicluster deployment](/docs/setup/install/multicluster) the mixer-telemetry
- and mixer-policy components do not connect to the Kubernetes API endpoints of any of the remote
- clusters. This results in a loss of telemetry fidelity as some of the metadata associated
- with workloads on remote clusters is incomplete.
-
-- There are Kubernetes manifests available for using Citadel standalone or with Citadel health checking enabled.
- There is not a Helm implementation of these modes. See [Issue 6922](https://github.com/istio/istio/issues/6922)
- for more details.
-
-- Mesh expansion functionality, which lets you add raw VMs to a mesh is broken in 1.0. We're expecting to produce a
-patch that fixes this problem within a few days.
diff --git a/content/en/boilerplates/notes/1.1.11.md b/content/en/boilerplates/notes/1.1.11.md
deleted file mode 100644
index 871f0c0f0e4d..000000000000
--- a/content/en/boilerplates/notes/1.1.11.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Small enhancements
-
-- Add ability to enable `HTTP/1.0` support in ingress gateway ([Issue 13085](https://github.com/istio/istio/issues/13085)).
diff --git a/content/en/boilerplates/notes/1.1.12.md b/content/en/boilerplates/notes/1.1.12.md
deleted file mode 100644
index 9ac3cb72807b..000000000000
--- a/content/en/boilerplates/notes/1.1.12.md
+++ /dev/null
@@ -1,3 +0,0 @@
-## Bug fixes
-
-- Fix a bug where the sidecar could infinitely forward requests to itself when a `Pod` resource defines a port that isn't defined for a service ([Issue 14443](https://github.com/istio/istio/issues/14443)) and ([Issue 14242](https://github.com/istio/istio/issues/14242))
diff --git a/content/en/boilerplates/notes/1.2.2.md b/content/en/boilerplates/notes/1.2.2.md
deleted file mode 100644
index 811b8811adf9..000000000000
--- a/content/en/boilerplates/notes/1.2.2.md
+++ /dev/null
@@ -1,4 +0,0 @@
-## Bug fixes
-
-- Fix crash in Istio's JWT Envoy filter caused by malformed JWT ([Issue 15084](https://github.com/istio/istio/issues/15084))
-- Fix incorrect overwrite of x-forwarded-proto header ([Issue 15124](https://github.com/istio/istio/issues/15124))
diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md
index 094a960e48ac..0c16900f13f4 100644
--- a/content/en/docs/_index.md
+++ b/content/en/docs/_index.md
@@ -11,7 +11,6 @@ In addition to the documentation, we provide the following resources:
- [FAQ](/faq) section
- [Glossary](/docs/reference/glossary).
-- [Release notes](/about/notes) for info on individual Istio releases.
Are you looking for past versions of the documentation? We keep an
[archive of the documentation for prior releases](https://archive.istio.io/).
diff --git a/content/en/docs/concepts/deployment-models/cluster-iso.svg b/content/en/docs/concepts/deployment-models/cluster-iso.svg
index 39ef424a9ca9..8aff13f1c506 100644
--- a/content/en/docs/concepts/deployment-models/cluster-iso.svg
+++ b/content/en/docs/concepts/deployment-models/cluster-iso.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/cluster-ns.svg b/content/en/docs/concepts/deployment-models/cluster-ns.svg
index 9b0f1be7ca35..586784576435 100644
--- a/content/en/docs/concepts/deployment-models/cluster-ns.svg
+++ b/content/en/docs/concepts/deployment-models/cluster-ns.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/exp-ns.svg b/content/en/docs/concepts/deployment-models/exp-ns.svg
index d103173b96d2..21021f0e756a 100644
--- a/content/en/docs/concepts/deployment-models/exp-ns.svg
+++ b/content/en/docs/concepts/deployment-models/exp-ns.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/failover.svg b/content/en/docs/concepts/deployment-models/failover.svg
index 5c97856e4737..242ebe69310b 100644
--- a/content/en/docs/concepts/deployment-models/failover.svg
+++ b/content/en/docs/concepts/deployment-models/failover.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/iso-ns.svg b/content/en/docs/concepts/deployment-models/iso-ns.svg
index 75492fc8e1f4..b404bd320153 100644
--- a/content/en/docs/concepts/deployment-models/iso-ns.svg
+++ b/content/en/docs/concepts/deployment-models/iso-ns.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/multi-cluster.svg b/content/en/docs/concepts/deployment-models/multi-cluster.svg
index c00ee241e21a..2b7763a6a5ba 100644
--- a/content/en/docs/concepts/deployment-models/multi-cluster.svg
+++ b/content/en/docs/concepts/deployment-models/multi-cluster.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/multi-control.svg b/content/en/docs/concepts/deployment-models/multi-control.svg
index 587238bdf1e2..6a6158d9e7d5 100644
--- a/content/en/docs/concepts/deployment-models/multi-control.svg
+++ b/content/en/docs/concepts/deployment-models/multi-control.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/multi-mesh.svg b/content/en/docs/concepts/deployment-models/multi-mesh.svg
index 394532b17eea..e14698b9122a 100644
--- a/content/en/docs/concepts/deployment-models/multi-mesh.svg
+++ b/content/en/docs/concepts/deployment-models/multi-mesh.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/multi-net.svg b/content/en/docs/concepts/deployment-models/multi-net.svg
index 7e2dc78989cb..5ac474fa830a 100644
--- a/content/en/docs/concepts/deployment-models/multi-net.svg
+++ b/content/en/docs/concepts/deployment-models/multi-net.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/multi-trust.svg b/content/en/docs/concepts/deployment-models/multi-trust.svg
index 8b3a5a7e39ae..6abfaaa4dd05 100644
--- a/content/en/docs/concepts/deployment-models/multi-trust.svg
+++ b/content/en/docs/concepts/deployment-models/multi-trust.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/shared-control.svg b/content/en/docs/concepts/deployment-models/shared-control.svg
index 44e7f4bea2c2..fbabd61cb202 100644
--- a/content/en/docs/concepts/deployment-models/shared-control.svg
+++ b/content/en/docs/concepts/deployment-models/shared-control.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/single-cluster.svg b/content/en/docs/concepts/deployment-models/single-cluster.svg
index 9295577a9e59..f5c4ed62d478 100644
--- a/content/en/docs/concepts/deployment-models/single-cluster.svg
+++ b/content/en/docs/concepts/deployment-models/single-cluster.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/single-net.svg b/content/en/docs/concepts/deployment-models/single-net.svg
index 47814f554255..81fea299c4c1 100644
--- a/content/en/docs/concepts/deployment-models/single-net.svg
+++ b/content/en/docs/concepts/deployment-models/single-net.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/deployment-models/single-trust.svg b/content/en/docs/concepts/deployment-models/single-trust.svg
index f3ef49f9374d..04b3cd8de0ab 100644
--- a/content/en/docs/concepts/deployment-models/single-trust.svg
+++ b/content/en/docs/concepts/deployment-models/single-trust.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/performance-and-scalability/latency_p90.svg b/content/en/docs/concepts/performance-and-scalability/latency_p90.svg
index f5768c838109..daaf6fa30f4d 100644
--- a/content/en/docs/concepts/performance-and-scalability/latency_p90.svg
+++ b/content/en/docs/concepts/performance-and-scalability/latency_p90.svg
@@ -1,1624 +1 @@
-
-
-
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/security/auth.svg b/content/en/docs/concepts/security/auth.svg
index 78dd5081ce32..8ce914a9333c 100644
--- a/content/en/docs/concepts/security/auth.svg
+++ b/content/en/docs/concepts/security/auth.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/security/authn.svg b/content/en/docs/concepts/security/authn.svg
index 79302e3703b1..328caa8a2468 100644
--- a/content/en/docs/concepts/security/authn.svg
+++ b/content/en/docs/concepts/security/authn.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/security/authz.svg b/content/en/docs/concepts/security/authz.svg
index 168f0deec0d5..44331851f9b3 100644
--- a/content/en/docs/concepts/security/authz.svg
+++ b/content/en/docs/concepts/security/authz.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/security/node_agent.svg b/content/en/docs/concepts/security/node_agent.svg
index 292b102357da..f1442db390b6 100644
--- a/content/en/docs/concepts/security/node_agent.svg
+++ b/content/en/docs/concepts/security/node_agent.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/discovery.svg b/content/en/docs/concepts/traffic-management/discovery.svg
index 2c540a62c916..70f92f139c6f 100644
--- a/content/en/docs/concepts/traffic-management/discovery.svg
+++ b/content/en/docs/concepts/traffic-management/discovery.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/gateways-1.svg b/content/en/docs/concepts/traffic-management/gateways-1.svg
index 8b9df6e259ea..c6290d54bbcd 100644
--- a/content/en/docs/concepts/traffic-management/gateways-1.svg
+++ b/content/en/docs/concepts/traffic-management/gateways-1.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/gateways-2.svg b/content/en/docs/concepts/traffic-management/gateways-2.svg
index 06c16163e823..6689f04b3dba 100644
--- a/content/en/docs/concepts/traffic-management/gateways-2.svg
+++ b/content/en/docs/concepts/traffic-management/gateways-2.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/index.md b/content/en/docs/concepts/traffic-management/index.md
index cf07beb16b19..c2f655c3e2e0 100644
--- a/content/en/docs/concepts/traffic-management/index.md
+++ b/content/en/docs/concepts/traffic-management/index.md
@@ -13,237 +13,142 @@ aliases:
- /docs/concepts/traffic-management/pilot.html
---
-- [Overview and terminology](/docs/concepts/traffic-management/#overview-and-terminology):
- Learn about Pilot, Istio's core traffic management component and Envoy
- proxies and how they enable service discovery and traffic control for services in the mesh.
-
-- [Traffic routing and configuration](/docs/concepts/traffic-management/#traffic-routing-and-configuration):
- Learn about the Istio features and resources needed to configure routing and
- control the ingress and egress of traffic for the mesh.
-
-- [Network resilience and testing](/docs/concepts/traffic-management/#network-resilience-and-testing):
- Learn about Istio's dynamic failure recovery features that you can configure
- to test and build tolerance for failing nodes, and to prevent cascading failures to
- other nodes.
-
-## Overview and terminology
-
-With Istio, you can manage service discovery, traffic routing, and load balancing
-for your service mesh without having to update your services. Istio simplifies
-configuration of service-level properties like timeouts and retries, and makes
-it straightforward to set up tasks like staged rollouts with percentage-based
-traffic splits.
-
-Istio's traffic management model relies on the following two components:
-
-- {{< gloss >}}Pilot{{}}, the core traffic management component.
-- {{< gloss >}}Envoy{{}} proxies, which enforce configurations and policies set through Pilot.
-
-These components enable the following Istio traffic management features:
-
-- Service discovery
-- Load balancing
-- Traffic routing and control
-
-### Pilot: Core traffic management {#pilot}
-
-The following diagram shows the Pilot architecture:
-
-{{< image width="40%"
- link="./pilot-arch.svg"
- caption="Pilot architecture"
- >}}
-
-As the diagram illustrates, Pilot maintains an **abstract model** of all the
-services in the mesh. **Platform-specific adapters** in Pilot translate the
-abstract model appropriately for your platform.
-For example, the Kubernetes adapter implements controllers to watch the
-Kubernetes API server for changes to pod registration information and service
-resources. The Kubernetes adapter translates this
-data for the abstract model.
-
-Pilot uses the abstract model to generate appropriate Envoy-specific configurations
-to let Envoy proxies know about one another in the mesh through the **Envoy API.**
-
-You can use Istio's **Traffic Management API** to instruct Pilot to refine
-the Envoy configuration to exercise more granular control
-over the traffic in your service mesh.
-
-### Envoy proxies
-
-Traffic in Istio is categorized as data plane traffic and control plane
-traffic. Data plane traffic refers to the data that the business logic of the
-workloads manipulate. Control plane traffic refers to configuration and control
-data sent between Istio components to program the behavior of the mesh. Traffic
-management in Istio refers exclusively to data plane traffic.
-
-Envoy proxies are the only Istio components that interact with data plane
-traffic. Envoy proxies route the data plane traffic across the mesh and enforce
-the configurations and traffic rules without the services having to be aware of
-them. Envoy proxies mediate all inbound and outbound traffic for all services
-in the mesh. Envoy proxies are deployed as sidecars to services, logically
-augmenting the services with traffic management features:
-
-- [service discovery and load balancing](/docs/concepts/traffic-management/#discovery)
-- [traffic routing and configuration](/docs/concepts/traffic-management/#traffic-routing-and-configuration)
-- [network resilience and testing](/docs/concepts/traffic-management/#network-resilience-and-testing)
-
-Some of the features and tasks enabled by Envoy proxies include:
-
-- Traffic control features: enforce fine-grained traffic control with rich
- routing rules for HTTP, gRPC, WebSocket, and TCP traffic.
-
-- Network resiliency features: setup retries, failovers, circuit breakers, and
- fault injection.
-
-- Security and authentication features: enforce security policies and enforce
- access control and rate limiting defined through the configuration API.
-
-#### Service discovery and load balancing {#discovery}
-
-Istio service discovery leverages the service discovery features provided by
-platforms like Kubernetes for container-based applications.
-Service discovery works in a similar way regardless of what platform you're
-using:
-
-1. The platform starts a new instance of a service which notifies its platform
- adapter.
-
-1. The platform adapter registers the instance with the Pilot abstract model.
-
-1. **Pilot** distributes traffic rules and configurations to the Envoy proxies
- to account for the change.
-
-The following diagram shows how the platform adapters and Envoy proxies
-interact.
-
-{{< image width="40%"
- link="./discovery.svg"
- caption="Service discovery"
- >}}
-
-Because the service discovery feature is platform-independent,
-a service mesh can include services across multiple platforms.
-
-Using the abstract model, Pilot configures the Envoy proxies to perform
-load balancing for service requests, replacing any underlying
-platform-specific load balancing feature.
-In the absence of more specific routing rules, Envoy will distribute the traffic
-across the instances in the calling service's load balancing pool, according to
-the Pilot abstract model and load balancer configuration.
-
-Istio supports the following load balancing methods:
-
-- Round robin: Requests are forwarded to instances in the pool in turn, and
- the algorithm instructs the load balancer to go back to the top of the pool
- and repeat.
-
-- Random: Requests are forwarded at random to instances in the pool.
-
-- Weighted: Requests are forwarded to instances in the pool according to a
- specific percentage.
-
-- Least requests: Requests are forwarded to instances with the least number of
- requests. See the [Envoy load balancing documentation](https://www.envoyproxy.io/docs/envoy/v1.5.0/intro/arch_overview/load_balancing)
- for more information.
-
-You can also choose to prioritize your load balancing pools based on geographic
-location. Visit the [operations guide](/docs/ops/traffic-management/locality-load-balancing/)
-for more information on the locality load balancing feature.
-
-In addition to basic service discovery and load balancing, Istio provides a rich
-set of traffic routing and control features, which are described in the following sections.
-
-## Traffic routing and configuration
-
-The Istio traffic routing and configuration model relies on the following
-Istio [traffic management API](/docs/reference/config/networking/) resources:
-
-- **Virtual services**
-
- Use a [virtual service](/docs/concepts/traffic-management/#virtual-services)
- to configure an ordered list of routing rules to control how Envoy proxies
- route requests for a service within an Istio service mesh.
-
-- **Destination rules**
-
- Use [destination rules](/docs/concepts/traffic-management/#destination-rules)
- to configure the policies you want Istio to apply to a request after
- enforcing the routing rules in your virtual service.
-
-- **Gateways**
-
- Use [gateways](/docs/concepts/traffic-management/#gateways)
- to configure how the Envoy proxies load balance HTTP, TCP, or gRPC traffic.
-
-- **Service entries**
-
- Use a [service entry](/docs/concepts/traffic-management/#service-entries)
- to add an entry to Istio's **abstract model** that configures
- external dependencies of the mesh.
-
-- **Sidecars**
-
- Use a [sidecar](/docs/concepts/traffic-management/#sidecars)
- to configure the scope of the Envoy proxies to enable certain features,
- like namespace isolation.
-
-You can use these resources to configure
-fine-grained traffic control for a range of use cases:
-
-- Configure ingress traffic, enforce traffic policing, perform a traffic
- rewrite.
-
-- Set up load balancers and define [service subsets](/docs/concepts/traffic-management/#service-subsets)
- as destinations in the mesh.
-
-- Set up canary rollouts, circuit breakers, timeouts, and retries to test
- network resilience.
-
-- Configure TLS settings and outlier detection.
-
-The next section walks through some common use cases and describes how Istio
-supports them. Following sections describe each of the traffic management API resources in
-more detail.
-
-### Traffic routing use cases
-
-You might use all or only some of the Istio traffic management API resources,
-depending on your use case. Istio handles basic traffic routing by default,
-but configurations for advanced use cases might require the full range of Istio
-traffic routing features.
-
-#### Routing traffic to multiple versions of a service {#routing-versions}
-
-Typically, requests sent to services use a service's hostname or IP address,
-and clients sending requests don't distinguish between different versions of
-the service.
-
-With Istio, because the Envoy proxy intercepts and forwards all requests and
-responses between the clients and the services, you can use routing rules with
-[service subsets](/docs/concepts/traffic-management/#service-subsets)
-in a virtual service to configure the [routing rules](/docs/concepts/traffic-management/#routing-rules)
-for multiple versions of a service.
-
-Service subsets are used to label all instances that correspond to a specific
-version of a service.
-Before you configure routing rules, the Envoy proxies use round-robin load
-balancing across all service instances, regardless of their subset. After you
-configure routing rules for traffic to reach specific subsets, the Envoy
-proxies route traffic to the subset according to the rule but again use
-round-robin to route traffic across the instances of each subset.
-
-This configuration method provides the following advantages:
-
-- Decouples the application code from the evolution of the application's dependent services.
-- Provides monitoring benefits.
-For details, see [Mixer policies and telemetry](/docs/reference/config/policy-and-telemetry/).
-
-For example, in A/B testing we often want to configure traffic routes based on
-percentages. With Istio, you can use a virtual service to specify a routing
-rule that sends 25% of requests to instances in the `v2` subset, and sends the
-remaining 75% of requests to instances in the `v1` subset. The following
-configuration accomplishes our example for the `reviews` service.
+Istio’s traffic routing rules let you easily control the flow
+of traffic and API calls between services. Istio simplifies configuration of
+service-level properties like circuit breakers, timeouts, and retries, and makes
+it easy to set up important tasks like A/B testing, canary rollouts, and staged
+rollouts with percentage-based traffic splits. It also provides out-of-box
+failure recovery features that help make your application
+more robust against failures of dependent services or the network.
+
+Istio’s traffic management model relies on the {{< gloss >}}Envoy{{}}
+proxies that are deployed along with your services. All traffic that your mesh
+services send and receive ({{< gloss >}}data plane{{}} traffic) is proxied through Envoy, making
+it easy to direct and control traffic around your mesh without making any
+changes to your services.
+
+If you’re interested in the details of how the features described in this guide
+work, you can find out more about Istio’s traffic management architecture in the
+[Architecture](#architecture) section at the end of this document. The rest of
+this guide introduces Istio’s traffic management features.
+
+## Introducing Istio Traffic Management
+
+In order to direct traffic within your mesh, Istio needs to know where all your
+endpoints are, and which services they belong to. To populate its own
+{{< gloss >}}service registry{{}}, Istio connects to a service
+discovery system. For example, if you've installed Istio on a Kubernetes cluster,
+then Istio automatically detects the services and endpoints in that cluster.
+
+Using this service registry, the Envoy proxies can then direct traffic to the
+relevant services. Most microservice-based applications have multiple instances
+of each service workload to handle service traffic, sometimes referred to as a
+load balancing pool. By default, the Envoy proxies distribute traffic across
+each service’s load balancing pool using a round-robin model, where requests are
+sent to each pool member in turn, returning to the top of the pool once each
+service instance has received a request.
+
+While Istio's basic service discovery and load balancing gives you a working
+service mesh, it’s far from all that Istio can do. In many cases you might want
+more fine-grained control over what happens to your mesh traffic.
+You might want to direct a particular percentage of traffic to a new version of
+a service as part of A/B testing, or apply a different load balancing policy to
+traffic for a particular subset of service instances. You might also want to
+apply special rules to traffic coming into or out of your mesh, or add an
+external dependency of your mesh to the service registry. You can do all this
+and more by adding your own traffic configuration to Istio using Istio’s traffic
+management API.
+
+Like other Istio configuration, the API is specified using Kubernetes custom
+resource definitions ({{< gloss >}}CRDs{{}}), which you can configure
+using YAML, as you’ll see in the examples.
+
+The rest of this guide examines each of the traffic management API resources
+and what you can do with them. These resources are:
+
+- [Virtual services](#virtual-services)
+- [Destination rules](#destination-rules)
+- [Gateways](#gateways)
+- [Service entries](#service-entries)
+- [Sidecars](#sidecars)
+
+This guide also gives an overview of some of the
+[network resilience and testing features](#network-resilience-and-testing) that
+are built in to the API resources.
+
+## Virtual services {#virtual-services}
+
+[Virtual services](/docs/reference/config/networking/v1alpha3/virtual-service/#VirtualService),
+along with [destination rules](#destination-rules), are the key building blocks of Istio’s traffic
+routing functionality. A virtual service lets you configure how requests are
+routed to a service within an Istio service mesh, building on the basic
+connectivity and discovery provided by Istio and your platform. Each virtual
+service consists of a set of routing rules that are evaluated in order, letting
+Istio match each given request to the virtual service to a specific real
+destination within the mesh. Your mesh can require multiple virtual services or
+none depending on your use case.
+
+### Why use virtual services? {#why-use-virtual-services}
+
+Virtual services play a key role in making Istio’s traffic management flexible
+and powerful. They do this by strongly decoupling where clients send their
+requests from the destination workloads that actually implement them. Virtual
+services also provide a rich way of specifying different traffic routing rules
+for sending traffic to those workloads.
+
+Why is this so useful? Without virtual services, Envoy distributes
+traffic using round-robin load balancing between all service instances, as
+described in the introduction. You can improve this behavior with what you know
+about the workloads. For example, some might represent a different version. This
+can be useful in A/B testing, where you might want to configure traffic routes
+based on percentages across different service versions, or to direct
+traffic from your internal users to a particular set of instances.
+
+With a virtual service, you can specify traffic behavior for one or more hostnames.
+You use routing rules in the virtual service that tell Envoy how to send the
+virtual service’s traffic to appropriate destinations. Route destinations can
+be versions of the same service or entirely different services.
+
+A typical use case is to send traffic to different versions of a service,
+specified as service subsets. Clients send requests to the virtual service host as if
+it was a single entity, and Envoy then routes the traffic to the different
+versions depending on the virtual service rules: for example, "20% of calls go to
+the new version" or "calls from these users go to version 2". This allows you to,
+for instance, create a canary rollout where you gradually increase the
+percentage of traffic that’s sent to a new service version. The traffic routing
+is completely separate from the instance deployment, meaning that the number of
+instances implementing the new service version can scale up and down based on
+traffic load without referring to traffic routing at all. By contrast, container
+orchestration platforms like Kubernetes only support traffic distribution based
+on instance scaling, which quickly becomes complex. You can read more about how
+virtual services help with canary deployments in [Canary Deployments using Istio](/blog/2017/0.1-canary/).
+
+Virtual services also let you:
+
+- Address multiple application services through a single virtual service. If
+ your mesh uses Kubernetes, for example, you can configure a virtual service
+ to handle all services in a specific namespace. Mapping a single
+ virtual service to multiple "real" services is particularly useful in
+ facilitating turning a monolithic application into a composite service built
+ out of distinct microservices without requiring the consumers of the service
+ to adapt to the transition. Your routing rules can specify "calls to these URIs of
+ `monolith.com` go to `microservice A`", and so on. You can see how this works
+ in [one of our examples below](#more-about-routing-rules).
+- Configure traffic rules in combination with
+ [gateways](/docs/concepts/traffic-management/#gateways) to control ingress
+ and egress traffic.
+
+In some cases you also need to configure destination rules to use these
+features, as these are where you specify your service subsets. Specifying
+service subsets and other destination-specific policies in a separate object
+lets you reuse these cleanly between virtual services. You can find out more
+about destination rules in the next section.
+
+### Virtual service example {#virtual-service-example}
+
+The following virtual service routes
+requests to different versions of a service depending on whether the request
+comes from a particular user.
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -254,502 +159,242 @@ spec:
hosts:
- reviews
http:
- - route:
- - destination:
- host: reviews
- subset: v1
- weight: 75
+ - match:
+ - headers:
+ end-user:
+ exact: jason
+ route:
- destination:
host: reviews
subset: v2
- weight: 25
-{{< /text >}}
-
-#### Canary rollouts with autoscaling {#canary}
-
-Canary rollouts allow you to test a new version of a service by sending a small
-amount of traffic to the new version. If the test is successful, you can
-gradually increase the percentage of traffic sent to the new version until all
-the traffic is moved. If anything goes wrong along the way, you can abort the
-rollout and return the traffic to the old version.
-
-Container orchestration platforms like Docker or Kubernetes support canary
-rollouts, but they use instance scaling to manage traffic distribution, which
-quickly becomes complex, especially in a production environment that requires
-autoscaling.
-
-With Istio, you can configure traffic routing and instance deployment as
-independent functions. The number of instances implementing the services can
-scale up and down based on traffic load without referring to version traffic
-routing at all. This makes managing a canary version that includes autoscaling
-a much simpler problem. For details, see the [Canary Deployments](/blog/2017/0.1-canary/)
-blog post.
-
-## Virtual services
-
-A [virtual service](/docs/reference/config/networking/v1alpha3/virtual-service/)
-is a resource you can use to configure how Envoy proxies route requests
-to a service within an Istio service mesh. Virtual services let you finely
-configure traffic behavior. For example, you can use virtual services to direct
-HTTP traffic to use a different version of the service for a specific user.
-
-Istio and your platform provide basic connectivity and discovery for your
-services. With virtual services, you can add a configuration layer to set up
-complex traffic routing. You can map user-addressable destinations to real
-workloads in the mesh, for example. Or, you can configure more advanced traffic
-routes to specific services or subsets in the mesh.
-
-Your mesh can require multiple virtual services or none depending on your use
-case. You can add [gateways](/docs/concepts/traffic-management/#gateways)
-to route traffic in or out of your mesh, or combine virtual services with
-[destination rules](/docs/concepts/traffic-management/#destination-rules)
-to configure the behavior of the traffic. You can use a [service entry](/docs/concepts/traffic-management/#service-entries)
-to add external dependencies to the mesh and combine them with virtual services
-to configure the traffic to these dependencies. The following diagrams
-show some example virtual service configurations:
-
-- 1:1 relationship: Virtual service A configures routing rules for traffic to
- reach service X.
-
- {{< image width="40%"
- link="./virtual-services-1.svg"
- caption="1 : 1 relationship"
- >}}
-
-- 1:many relationship:
-
- - Virtual service B configures routing rules for traffic to reach services
- Y and Z.
-
- {{< image width="40%"
- link="./virtual-services-2.svg"
- caption="1 : multiple services"
- >}}
-
- - Virtual service C configures routing rules for traffic to reach different
- versions of service W.
-
- {{< image width="40%"
- link="./virtual-services-3.svg"
- caption="1 : multiple versions"
- >}}
-
-You can use virtual services to perform the following types of tasks:
-
-- Configure each application service version as a
- [subset](/docs/concepts/traffic-management/#service-subsets) and add
- a corresponding [destination
- rule](/docs/concepts/traffic-management/#destination-rules) to
- determine the set of pods or VMs belonging to these subsets.
-
-- Configure traffic rules in combination with
- [gateways](/docs/concepts/traffic-management/#gateways)
- to control ingress and egress traffic
-
-- Add [multiple match conditions](/docs/concepts/traffic-management/#multi-match)
- to a virtual service configuration to eliminate redundant rules.
-
-- Configure [traffic routes](/docs/concepts/traffic-management/#routing-subset)
- to your application services using DNS names. These DNS names support
- wildcard prefixes or CIDR prefixes to create a single rule for all matching
- services.
-
-- Address one or more application services through a single virtual service.
- If your mesh uses Kubernetes, for example, you can configure a virtual
- service to handle all services in a specific
- [namespace](/docs/concepts/traffic-management/#routing-namespace).
-
-### Route requests to a subset {#routing-subset}
-
-The following example configures the `my-vtl-svc` virtual service to route
-requests to the `v1` subset of the `my-svc` service:
-
-{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: my-vtl-svc
-spec:
- hosts:
- - "*.my-co.org"
- http:
- route:
- destination:
- host: my-svc
- subset: v1
+ host: reviews
+ subset: v3
{{< /text >}}
-In the example, under `spec`,
-`hosts` lists the virtual service's hosts. In this case, the
-hosts are `*.my-co.org`, where `*` is a wildcard prefix indicating that this
-virtual service handles routing for any DNS name ending with `.my-co.org`.
-
-You can specify user-addressable hosts by using any DNS name or an internal
-mesh service name as long as the name resolves, implicitly or explicitly, to
-one or more fully qualified domain names (FQDN). To specify multiple hosts, you
-can use wildcards.
+#### The hosts field {#the-hosts-field}
-Also, note that under `route`, which specifies the routing rule's
-configuration, and `destination`, which specifies the routing rule's
-destination, `host: my-svc` specifies the destination's host. If you are
-running on Kubernetes, then `my-svc` is the name of a Kubernetes service.
-
-You use the destination's host to specify where you want the traffic to be
-sent. The destination's host must exist in the service registry. To use
-external services as destinations, use [service entries](/docs/concepts/traffic-management/#service-entries)
-to add those services to the registry.
-
-{{< warning >}}
-Istio **doesn't** provide [DNS](https://hosting.review/web-hosting-glossary/#9)
-resolution. Applications can try to resolve the FQDN by using the DNS service
-present in their platform of choice, for example `kube-dns`.
-{{< /warning >}}
-
-The following diagram shows the configured rule:
-
-{{< image width="40%"
- link="./virtual-services-4.svg"
- caption="Configurable traffic route to send traffic to a specific subset"
- >}}
-
-### Route requests to services in a Kubernetes namespace {#routing-namespace}
-
-When you specify the `host` field for the destination of a route in a virtual service
-using a short name like `svc-1`, Istio expands the short name into a fully qualified domain name.
-To perform the expansion, Istio adds a domain suffix based on the namespace of the virtual service that
-contains the routing rule. For example, if the virtual service is defined in the `my-namespace` namespace,
-Istio adds the `my-namespace.svc.cluster.local` suffix to the abbreviated destination resulting in
-the actual destination: `svc-1.my-namespace.svc.cluster.local`.
-
-While this approach is very convenient and commonly used to simplify examples, it can
-easily lead to misconfigurations. Therefore we do
-[not recommend it for production deployments](/docs/reference/config/networking/v1alpha3/virtual-service/#Destination).
-
-The following example shows a virtual service configuration with fully qualified traffic routes
-for two services in the `my-namespace` Kubernetes namespace.
-The configuration relies on the URI prefixes of the two services to distinguish
-them.
+The `hosts` field lists the virtual service’s hosts - in other words, the user-addressable
+destination or destinations that these routing rules apply to. This is the
+address or addresses the client uses when sending requests to the service.
{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: my-namespace
-spec:
- hosts:
- - my-namespace.com
- http:
- - match:
- - uri:
- prefix: /svc-1
- route:
- - destination:
- host: svc-1.my-namespace.svc.cluster.local
- - match:
- - uri:
- prefix: /svc-2
- route:
- - destination:
- host: svc-2.my-namespace.svc.cluster.local
+hosts:
+- reviews
{{< /text >}}
-Using fully qualified hosts in the routing rules also provides more flexibility.
-If you use short names, the destinations must be in the same namespace as the virtual service.
-If you use fully qualified domain names, the destinations can be in any namespace.
-
-### Routing rules
-
-A virtual service consists of an ordered list of routing rules to define the
-paths that requests follow within the mesh. You use virtual services to
-configure the routing rules. A routing rule consists of a destination and zero
-or more conditions, depending on your use case. You can also use routing rules
-to perform some actions on the traffic, for example:
-
-- Append or remove headers.
-
-- Rewrite the URL.
-
-- Set a retry policy.
-
-To learn more about the actions available, see the [virtual service reference documentation](/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPRoute).
-
-#### Routing rule for HTTP traffic
-
-The following example shows a virtual service that specifies
-two HTTP traffic routing rules. The first rule includes a `match`
-condition with a regular expression to check if the username "jason" is in the
-request's cookie. If the request matches this condition, the rule sends
-traffic to the `v2` subset of the `my-svc` service. Otherwise, the second rule
-sends traffic to the `v1` subset of the `my-svc` service.
+The virtual service hostname can be an IP address, a DNS name, or, depending on
+the platform, a short name (such as a Kubernetes service short name) that resolves,
+implicitly or explicitly, to a fully qualified domain name (FQDN). You can also
+use wildcard ("\*") prefixes, letting you create a single set of routing rules for
+all matching services. Virtual service hosts don't actually have to be part of the
+Istio service registry, they are simply virtual destinations. This lets you model
+traffic for virtual hosts that don't have routable entries inside the mesh.
+
+#### Routing rules {#routing-rules}
+
+The `http` section contains the virtual service’s routing rules, describing
+match conditions and actions for routing HTTP/1.1, HTTP2, and gRPC traffic sent
+to the destination(s) specified in the hosts field (you can also use `tcp` and
+`tls` sections to configure routing rules for
+[TCP](/docs/reference/config/networking/v1alpha3/virtual-service/#TCPRoute) and
+unterminated
+[TLS](/docs/reference/config/networking/v1alpha3/virtual-service/#TLSRoute)
+traffic). A routing rule consists of the destination where you want the traffic
+to go and zero or more match conditions, depending on your use case.
+
+##### Match condition {#match-condition}
+
+The first routing rule in the example has a condition and so begins with the
+`match` field. In this case you want this routing to apply to all requests from
+the user "jason", so you use the `headers`, `end-user`, and `exact` fields to select
+the appropriate requests.
{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: my-vtl-svc
-spec:
- hosts:
- - "*"
- http:
- - match:
- - headers:
- cookie:
- regex: "^(.*?;)?(user=jason)(;.*)?$"
- route:
- - destination:
- host: my-svc
- subset: v2
- - route:
- - destination:
- host: my-svc
- subset: v1
+- match:
+ - headers:
+ end-user:
+ exact: jason
{{< /text >}}
-In the preceding example, there are two routing rules in the `http` section,
-indicated by a leading `-` in front of the first field of each rule.
-
-The first routing rule begins with the `match` field:
-
-- `match` Lists the routing rule's matching conditions.
-
-- `headers` Specifies to look for a match in the header of the request.
-
-- `cookie` Specifies to look for a match in the header's cookie.
-
-- `regex` Specifies the regular expression used to determine a match.
-
-- `route` Specifies where to route the traffic
- matching the condition. In this case, that traffic is HTTP traffic with the
- username `jason` in the cookie of the request's header.
-
-- `destination` Specifies the route destination for the traffic matching the rule conditions.
-
-- `host` Specifies the destination's host, `my-svc`.
-
-- `subset` Specifies the destination’s subset for the traffic matching the conditions, `v2` in this case.
-
-The configuration of the second routing rule in the example begins with the
-`route` field with a leading `-`. This rule applies to all traffic that doesn't match the
-conditions specified in the first routing rule.
-
-- `route` Specifies where to route all traffic except for HTTP traffic matching the condition of the previous rule.
-
-- `destination` Specifies the routing rule's destination.
+##### Destination {#destination}
-- `host` Specifies the destination's host, `my-svc`.
+The route section’s `destination` field specifies the actual destination for
+traffic that matches this condition. Unlike the virtual service’s host(s), the
+destination’s host must be a real destination that exists in Istio’s service
+registry or Envoy won’t know where to send traffic to it. This can be a mesh
+service with proxies or a non-mesh service added using a service entry. In this
+case we’re running on Kubernetes and the host name is a Kubernetes service name:
-- `subset` Specifies the destination’s subset, `v1` in this case.
+{{< text yaml >}}
+route:
+- destination:
+ host: reviews
+ subset: v2
+{{< /text >}}
-The following diagram shows the configured traffic routes for the matched traffic and for all other traffic:
+Note in this and the other examples on this page, we use a Kubernetes short name for the
+destination hosts for simplicity. When this rule is evaluated, Istio adds a domain suffix based
+on the namespace of the virtual service that contains the routing rule to get
+the fully qualified name for the host. Using short names in our examples
+also means that you can copy and try them in any namespace you like.
-{{< image width="40%"
- link="./virtual-services-6.svg"
- caption="Configurable traffic route based on the namespace of two application services"
- >}}
+{{< warning >}}
+Using short names like this only works if the
+destination hosts and the virtual service are actually in the same Kubernetes
+namespace. Because using the Kubernetes short name can result in
+misconfigurations, we recommend that you specify fully qualified host names in
+production environments.
+{{< /warning >}}
-Routing rules are evaluated in a specific order. For details, refer to
-[Precedence](/docs/concepts/traffic-management/#precedence).
+The destination section also specifies which subset of this Kubernetes service
+you want requests that match this rule’s conditions to go to, in this case the
+subset named v2. You’ll see how you define a service subset in the section on
+[destination rules](#destination-rules) below.
-#### Match a condition
+#### Routing rule precedence {#routing-rule-precedence}
-You can set routing rules that only apply to requests matching a specific
-condition. For example, the following configuration sets up a rule that only
-applies to an incoming request that includes a custom `end-user` header
-containing the exact value `jason`:
+Routing rules are **evaluated in sequential order from top to bottom**, with the
+first rule in the virtual service definition being given highest priority. In
+this case you want anything that doesn't match the first routing rule to go to a
+default destination, specified in the second rule. Because of this, the second
+rule has no match conditions and just directs traffic to the v3 subset.
{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: reviews
-spec:
- hosts:
- - reviews
- http:
- - match:
- - headers:
- end-user:
- exact: jason
- route:
- ...
+- route:
+ - destination:
+ host: reviews
+ subset: v3
{{< /text >}}
-You can specify more than one header in a rule. All corresponding headers must
-match.
+We recommend providing a default "no condition" or weight-based rule (described
+below) like this as the last rule in each virtual service to ensure that traffic
+to the virtual service always has at least one matching route.
-#### Match request URI
+### More about routing rules {#more-about-routing-rules}
-The following routing rule is based on the request's URI: it only applies to a
-request if the URI path starts with `/api/v1`:
+As you saw above, routing rules are a powerful tool for routing particular
+subsets of traffic to particular destinations. You can set match conditions on
+traffic ports, header fields, URIs, and more. For example, this virtual service
+lets users send traffic to two separate services, ratings and reviews, as if
+they were part of a bigger virtual service at `http://bookinfo.com/.` The
+virtual service rules match traffic based on request URIs and direct requests to
+the appropriate service.
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
- name: productpage
+ name: bookinfo
spec:
hosts:
- - productpage
+ - bookinfo.com
http:
- match:
- uri:
- prefix: /api/v1
+ prefix: /reviews
route:
- ...
-{{< /text >}}
-
-#### Multiple match conditions {#multi-match}
-
-Conditions can have multiple matches simultaneously. In such cases, you use the
-nesting of the conditions in the routing rule to specify whether AND or OR
-semantics apply. To specify AND semantics, you nest multiple conditions in a
-single section of `match.`
-
-For example, the following rule applies only to requests for a
-URL that begins with `/api/v1` **and** that include the custom
-`end-user` header that contains the exact value `jason`:
-
-{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: productpage
-spec:
- hosts:
- - productpage
- http:
+ - destination:
+ host: reviews
- match:
- uri:
- prefix: /api/v1
- headers:
- end-user:
- exact: jason
+ prefix: /ratings
route:
- ...
-{{< /text >}}
-
-To specify OR conditions, you place multiple conditions in separate sections of
-`match.` Only one of the conditions applies. For example, the following rule
-applies to requests for a URL that begins with `/api/v1` **or** to requests with the
-custom `end-user` header containing the exact value `jason`:
+ - destination:
+ host: ratings
+...
-{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: productpage
-spec:
- hosts:
- - productpage
http:
- match:
- - uri:
- prefix: /api/v1
- - headers:
- end-user:
- exact: jason
+ sourceLabels:
+ app: reviews
route:
- ...
+...
{{< /text >}}
-{{< warning >}}
-In the two examples, above, the only difference between AND behavior and OR behavior is
-an extra `-` character in front of the `headers` field. The `-` in the YAML representation,
-indicates two separate matches as opposed to one match with multiple conditions.
-{{< /warning >}}
-
-### Routing rule precedence {#precedence}
-
-Multiple rules for a given destination in a configuration file are evaluated in
-the order they appear. The first rule on the list has the highest priority.
-
-Rules with no match condition that direct all or weighted percentages of
-traffic to destination services are called **weight-based** rules to
-distinguish them from other match-based rules. When routing for a particular
-service is purely weight-based, you can specify it in a single rule.
-
-When you use other conditions to route traffic, such as requests from a
-specific user, you must use more than one rule to specify the routing.
+For some match conditions, you can also choose to select them using the exact
+value, a prefix, or a regex.
-It's important to ensure that your routing rules are evaluated in the right
-order.
+You can add multiple match conditions to the same `match` block to AND your
+conditions, or add multiple match blocks to the same rule to OR your conditions.
+You can also have multiple routing rules for any given virtual service. This
+lets you make your routing conditions as complex or simple as you like within a
+single virtual service. A full list of match condition fields and their possible
+values can be found in the
+[`HTTPMatchRequest` reference](/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPMatchRequest).
-A best practice pattern to specify routing rules is as follows:
-
-1. Provide one or more higher priority rules that match various conditions.
-
-1. Provide a single weight-based rule with no match condition last. This rule
- provides the weighted distribution of traffic for all other cases.
-
-#### Precedence example with 2 rules
-
-The following virtual service configuration file includes two rules. The first
-rule sends all requests for the `reviews` service that include the Foo header
-with the bar value to the `v2` subset. The second rule sends all remaining
-requests to the `v1` subset:
+In addition to using match conditions, you can distribute traffic
+by percentage "weight". This is useful for A/B testing and canary rollouts:
{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: reviews
spec:
hosts:
- reviews
http:
- - match:
- - headers:
- Foo:
- exact: bar
- route:
- - destination:
- host: reviews
- subset: v2
- route:
- destination:
host: reviews
subset: v1
+ weight: 75
+ - destination:
+ host: reviews
+ subset: v2
+ weight: 25
{{< /text >}}
-In this example, the header-based rule has the higher priority because it comes
-first in the configuration file. If the match-based rule came second, these
-rules wouldn't work as expected. Istio would evaluate the weight-based rule
-first and route all traffic to the instances in the `v1` subset, even requests
-including the matching `Foo` header.
+You can also use routing rules to perform some actions on the traffic, for
+example:
+
+- Append or remove headers.
+- Rewrite the URL.
+- Set a [retry policy](#retries) for calls to this destination.
-## Destination rules
+To learn more about the actions available, see the
+[`HTTPRoute` reference](/docs/reference/config/networking/v1alpha3/virtual-service/#HTTPRoute).
-You specify the path for traffic with routing rules, and then you use
-[destination rules](/docs/reference/config/networking/v1alpha3/destination-rule/)
-to configure the set of policies that Envoy proxies apply to a request at a
-specific destination.
+## Destination rules {#destination-rules}
-Destination rules are applied after the routing rules are evaluated.
-Therefore, destination rules are matched against the destination in the routing rules,
-not the host of the virtual service itself.
-You can use wildcard prefixes in a
-destination rule to specify a single rule for multiple services.
+Along with [virtual services](#virtual-services),
+[destination rules](/docs/reference/config/networking/v1alpha3/destination-rule/#DestinationRule)
+are a key part of Istio’s traffic routing functionality. You can think of
+virtual services as how you route your traffic **to** a given destination, and
+then you use destination rules to configure what happens to traffic **for** that
+destination. Destination rules are applied after virtual service routing rules
+are evaluated, so they apply to the traffic’s "real" destination.
-You can use destination rules to specify service subsets, that is, to group all
-the instances of your service with a particular version together. You then
-configure [routing rules](/docs/concepts/traffic-management/#routing-rules)
-that route traffic to your subsets to send certain traffic to particular
-service versions.
+In particular, you use destination rules to specify named service subsets, such
+as grouping all a given service’s instances by version. You can then use these
+service subsets in the routing rules of virtual services to control the
+traffic to different instances of your services.
-You specify explicit routing rules to service subsets. This model allows you
-to:
+Destination rules also let you customize Envoy’s traffic policies when calling
+the entire destination service or a particular service subset, such as your
+preferred load balancing model, TLS security mode, or circuit breaker settings.
+You can see a complete list of destination rule options in the
+[Destination Rule reference](/docs/reference/config/networking/v1alpha3/destination-rule/).
-- Cleanly refer to a specific service version across different
- [virtual services](/docs/concepts/traffic-management/#virtual-services).
+### Load balancing options
-- Simplify the stats that the Istio proxies emit.
+By default, Istio uses a round-robin load balancing policy, where each service
+instance in the instance pool gets a request in turn. Istio also supports the
+following models, which you can specify in destination rules for requests to a
+particular service or service subset.
-- Encode subsets in Server Name Indication (SNI) headers.
+- Random: Requests are forwarded at random to instances in the pool.
+- Weighted: Requests are forwarded to instances in the pool according to a
+ specific percentage.
+- Least requests: Requests are forwarded to instances with the least number of
+ requests.
-### Load balancing 3 subsets
+See the
+[Envoy load balancing documentation](https://www.envoyproxy.io/docs/envoy/v1.5.0/intro/arch_overview/load_balancing)
+for more information about each option.
-The following example destination rule configures three different subsets with
-different load balancing policies for the `my-svc` destination service:
+### Destination rule example {#destination-rule-example}
+
+The following example destination rule configures three different subsets for
+the `my-svc` destination service, with different load balancing policies:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -776,89 +421,53 @@ spec:
version: v3
{{< /text >}}
-As shown above, you can specify multiple policies in a single destination rule.
-In this example, the default policy, defined above the subsets field,
-sets a simple random load balancer for the `v1` and `v3` subsets. A `v2`
-specific policy, a round robin load balancer, is defined in the corresponding subset's field.
-
-See our [destination rules reference documentation](/docs/reference/config/networking/v1alpha3/destination-rule/)
-to review all the enabled keys and values.
-
-### Service subsets
-
-Service subsets subdivide and label the instances of a service. To define the
-divisions and labels, use the `subsets` section in [destination rules](/docs/reference/config/networking/v1alpha3/destination-rule/).
-For example, you can use subsets to configure the following traffic routing
-scenarios:
-
-- Use subsets to route traffic to different versions of a service.
-
-- Use subsets to route traffic to the same service in different environments.
-
-You use service subsets in the routing rules of [virtual services](/docs/concepts/traffic-management/#virtual-services)
-to control the traffic to your services.
-You can also use subsets to customize Envoy's traffic policies when calling particular versions of a service.
-
-Understanding service subsets in Istio allows you to configure the
-communication to services with multiple versions within your mesh and configure
-the following common use cases:
-
-- [Splitting traffic between versions for A/B testing](/docs/concepts/traffic-management/#routing-subset)
-
-- [Canary rollout](/docs/concepts/traffic-management/#canary)
-
-To learn how you can use service subsets to configure failure handling use
-cases, visit our [Network resilience and testing concept](/docs/concepts/traffic-management/#network-resilience-and-testing).
-
-## Gateways
-
-You use a [gateway](/docs/reference/config/networking/v1alpha3/gateway/) to
-manage inbound and outbound traffic for your mesh. You can manage
-[multiple types of traffic](/docs/reference/config/networking/v1alpha3/gateway/#Port)
-with a gateway.
-
-Gateway configurations apply to Envoy proxies that are running at the edge
-of the mesh, which means that the Envoy proxies are not running as service sidecars.
-To configure a gateway means configuring an Envoy
-proxy to allow or block certain traffic from entering or leaving the mesh.
-
-Your mesh can have any number of gateway configurations, and multiple gateway
-workload implementations can co-exist within your mesh. You might use multiple
-gateways to have one gateway for private traffic and another for public
-traffic, so you can keep all private traffic inside a firewall, for example.
-
-You can use a gateway to configure workload labels for your existing network
-tasks, including:
-
-- Firewall functions
-- Caching
-- Authentication
-- Network address translation
-- IP address management
-
-Gateways are primarily used to manage ingress traffic, but you can also use a
-gateway to configure an egress gateway. You can use egress gateways to
-configure a dedicated exit node for the traffic leaving the mesh and configure
-each egress gateway to use its own policies and telemetry.
-
-You can use egress gateways to limit which services can or should access
-external networks, or to enable [secure control of egress
-traffic](/blog/2019/egress-traffic-control-in-istio-part-1/) to add security to
-your mesh, for example. The following diagram shows the basic model of a
-request flowing through a service mesh with an ingress gateway and an egress
-gateway.
-
-{{< image width="70%"
- link="./gateways-1.svg"
- caption="Request flow"
- >}}
-
-All traffic enters the mesh through an ingress gateway workload. To configure
-the traffic, use an Istio gateway and a virtual service. You bind the virtual
-service to the gateway to use standard Istio [routing rules](/docs/concepts/traffic-management/#routing-rules)
-to control HTTP requests and TCP traffic entering the mesh.
-
-### Configure a gateway for external HTTPS traffic
+Each subset is defined based on one or more `labels`, which in Kubernetes are
+key/value pairs that are attached to objects such as Pods. These labels are
+applied in the Kubernetes service’s deployment as `metadata` to identify
+different versions.
+
+As well as defining subsets, this destination rule has both a default traffic
+policy for all subsets in this destination and a subset-specific policy that
+overrides it for just that subset. The default policy, defined above the `subsets`
+field, sets a simple random load balancer for the `v1` and `v3` subsets. In the
+`v2` policy, a round-robin load balancer is specified in the corresponding
+subset’s field.
+
+## Gateways {#gateways}
+
+You use a [gateway](/docs/reference/config/networking/v1alpha3/gateway/#Gateway) to
+manage inbound and outbound traffic for your mesh, letting you specify which
+traffic you want to enter or leave the mesh. Gateway configurations are applied
+to standalone Envoy proxies that are running at the edge of the mesh, rather
+than sidecar Envoy proxies running alongside your service workloads.
+
+Unlike other mechanisms for controlling traffic entering your systems, such as
+the Kubernetes Ingress APIs, Istio gateways let you use the full power and
+flexibility of Istio’s traffic routing. You can do this because Istio’s Gateway
+resource just lets you configure layer 4-6 load balancing properties such as
+ports to expose, TLS settings, and so on. Then instead of adding
+application-layer traffic routing (L7) to the same API resource, you bind a
+regular Istio [virtual service](#virtual-services) to the gateway. This lets you
+basically manage gateway traffic like any other data plane traffic in an Istio
+mesh.
+
+Gateways are primarily used to manage ingress traffic, but you can also
+configure egress gateways. An egress gateway lets you configure a dedicated exit
+node for the traffic leaving the mesh, letting you limit which services can or
+should access external networks, or to enable
+[secure control of egress traffic](/blog/2019/egress-traffic-control-in-istio-part-1/)
+to add security to your mesh, for example. You can also use a gateway to
+configure a purely internal proxy.
+
+Istio provides some preconfigured gateway proxy deployments
+(`istio-ingressgateway` and `istio-egressgateway`) that you can use - both are
+deployed if you use our [demo installation](/docs/setup/install/kubernetes/),
+while just the ingress gateway is deployed with our
+[default or sds profiles.](/docs/setup/additional-setup/config-profiles/) You
+can apply your own gateway configurations to these deployments or deploy and
+configure your own gateway proxies.
+
+### Gateway example {#gateway-example}
The following example shows a possible gateway configuration for external HTTPS
ingress traffic:
@@ -877,20 +486,18 @@ spec:
name: https
protocol: HTTPS
hosts:
- - ext-host
+ - ext-host.example.com
tls:
mode: SIMPLE
serverCertificate: /tmp/tls.crt
privateKey: /tmp/tls.key
{{< /text >}}
-This gateway configuration lets HTTPS traffic from `ext-host` into the mesh on
-port 443, but doesn't specify any routing for the traffic.
-
-#### Bind a gateway to a virtual service
+This gateway configuration lets HTTPS traffic from `ext-host.example.com` into the mesh on
+port 443, but doesn’t specify any routing for the traffic.
To specify routing and for the gateway to work as intended, you must also bind
-the gateway to a virtual service. You do this using the virtual service's
+the gateway to a virtual service. You do this using the virtual service’s
`gateways` field, as shown in the following example:
{{< text yaml >}}
@@ -900,7 +507,7 @@ metadata:
name: virtual-svc
spec:
hosts:
- - ext-svc
+ - ext-host.example.com
gateways:
- ext-host-gwy
{{< /text >}}
@@ -908,60 +515,34 @@ spec:
You can then configure the virtual service with routing rules for the external
traffic.
-For more information:
-
-- Refer to the [gateways reference documentation](/docs/reference/config/networking/v1alpha3/gateway/)
- to review all the enabled keys and values.
-
-- Refer to the [Ingress task topic](/docs/tasks/traffic-management/ingress/) for instructions on how to configure
- an Istio gateway for ingress traffic.
-
-- Refer to the [Egress gateway task](/docs/tasks/traffic-management/egress/egress-gateway/) to learn how to configure egress traffic
- using a gateway resource.
-
-## Service entries
-
-A [service entry](/docs/reference/config/networking/v1alpha3/service-entry)
-is used to add an entry to Istio's abstract model, or
-service registry, that Istio maintains internally. After you add the service
-entry, the Envoy proxies can send traffic to the service as if it was
-a service in your mesh.
-Configuring service entries allows you to manage traffic for services running
-outside of the mesh:
-
-- Redirect and forward traffic for external destinations, such as APIs
- consumed from the web, or traffic to services in legacy infrastructure.
-
-- Define
- [retry](/docs/concepts/traffic-management/#timeouts-and-retries),
- [timeout](/docs/concepts/traffic-management/#timeouts-and-retries),
- and [fault injection](/docs/concepts/traffic-management/#fault-injection)
- policies for external destinations.
-
-- Add a service running in a Virtual Machine (VM) to the mesh to [expand your mesh](/docs/examples/mesh-expansion/).
-
-- Logically add services from a different cluster to the mesh to configure a
- [multicluster Istio mesh](/docs/setup/install/multicluster/gateways/#configure-the-example-services)
- on Kubernetes.
+## Service entries {#service-entries}
-You don’t need to add a service entry for every external service that you
-want your mesh services to use. By default, Istio configures the Envoy proxies
-to passthrough requests to unknown services, although you can't use Istio features
-to control the traffic to destinations that are not registered in the mesh.
+You use a
+[service entry](/docs/reference/config/networking/v1alpha3/service-entry/#ServiceEntry) to add
+an entry to the service registry that Istio maintains internally. After you add
+the service entry, the Envoy proxies can send traffic to the service as if it
+was a service in your mesh. Configuring service entries allows you to manage
+traffic for services running outside of the mesh, including the following tasks:
-You can use service entries to perform the following configurations:
+- Redirect and forward traffic for external destinations, such as APIs
+ consumed from the web, or traffic to services in legacy infrastructure.
+- Define [retry](#retries), [timeout](#timeouts), and
+ [fault injection](#fault-injection) policies for external destinations.
+- Add a service running in a Virtual Machine (VM) to the mesh to
+ [expand your mesh](/docs/examples/mesh-expansion/single-network/#running-services-on-a-mesh-expansion-machine).
+- Logically add services from a different cluster to the mesh to configure a
+ [multicluster Istio mesh](/docs/setup/install/multicluster/gateways/#configure-the-example-services)
+ on Kubernetes.
-- Access secure external services over plain text ports,
- to configure Envoy to perform {{< gloss >}}TLS Origination{{}}.
-- Ensure, together with an egress gateway, that all external services are
- accessed through a single exit point.
+You don’t need to add a service entry for every external service that you want
+your mesh services to use. By default, Istio configures the Envoy proxies to
+passthrough requests to unknown services. However, you can’t use Istio features
+to control the traffic to destinations that aren't registered in the mesh.
-Refer to the [Egress task topic](/docs/tasks/traffic-management/egress/) for details.
-
-## Add an external dependency securely
+### Service entry example {#service-entry-example}
The following example mesh-external service entry adds the `ext-resource`
-external dependency to Istio's service registry:
+external dependency to Istio’s service registry:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -970,7 +551,7 @@ metadata:
name: svc-entry
spec:
hosts:
- - ext-resource.com
+ - ext-svc.example.com
ports:
- number: 443
name: https
@@ -979,20 +560,14 @@ spec:
resolution: DNS
{{< /text >}}
-You must specify the external resource using the `hosts` key. You can qualify
-it fully or use a wildcard domain name. The value represents the set of one or
-more services outside the mesh that services in the mesh can access.
-
-Configuring a service entry can be enough to call an external service, but
-typically you configure either, or both, a virtual service or destination rule
-to control traffic in a more granular way. You can configure traffic for a
-service entry in the same way you configure traffic for a service in the mesh.
-
-### Secure the connection with mutual TLS
+You specify the external resource using the `hosts` field. You can qualify it
+fully or use a wildcard prefixed domain name.
-The following destination rule configures the traffic route to use mutual TLS
-to secure the connection to the `ext-resource` external service we
-configured using the service entry:
+You can configure virtual services and destination rules to control traffic to a
+service entry in a more granular way, in the same way you configure traffic for
+any other service in the mesh. For example, the following destination rule
+configures the traffic route to use mutual TLS to secure the connection to the
+`ext-svc.example.com` external service that we configured using the service entry:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -1000,7 +575,7 @@ kind: DestinationRule
metadata:
name: ext-res-dr
spec:
- host: ext-resource.com
+ host: ext-svc.example.com
trafficPolicy:
tls:
mode: MUTUAL
@@ -1009,36 +584,29 @@ spec:
caCertificates: /etc/certs/rootcacerts.pem
{{< /text >}}
-Together, the `svc-entry` service entry and the `ext-res-dr` destination rule
-configure a connection for traffic to the `ext-resource` external
-dependency using port 443 and mutual TLS.
+See the
+[Service Entry reference](/docs/reference/config/networking/v1alpha3/service-entry)
+for more possible configuration options.
-See the [service entries reference documentation](/docs/reference/config/networking/v1alpha3/service-entry)
-to review all the enabled keys and values.
-
-## Sidecars
+## Sidecars {#sidecars}
By default, Istio configures every Envoy proxy to accept traffic on all the
ports of its associated workload, and to reach every workload in the mesh when
-forwarding traffic. You can use a sidecar configuration to do the following:
-
-- Fine-tune the set of ports and protocols that an Envoy proxy accepts.
-
-- Limit the set of services that the Envoy proxy can reach.
+forwarding traffic. You can use a [sidecar](/docs/reference/config/networking/v1alpha3/sidecar/#Sidecar) configuration to do the following:
-Limiting sidecar reachability reduces memory usage, which can become a problem
-for large applications in which every sidecar is configured to reach every
-other service in the mesh.
+- Fine-tune the set of ports and protocols that an Envoy proxy accepts.
+- Limit the set of services that the Envoy proxy can reach.
-A [Sidecar](/docs/reference/config/networking/v1alpha3/sidecar/) resource can be used to configure one or more sidecar proxies
-selected using workload labels, or to configure all sidecars in a particular
-namespace.
+You might want to limit sidecar reachability like this in larger applications,
+where having every proxy configured to reach every other service in the mesh can
+potentially affect mesh performance due to high memory usage.
-### Enable namespace isolation
-
-For example, the following `Sidecar` configures all services in the `bookinfo`
-namespace to only reach services running in the same namespace thanks to the
-`./*` value of the `hosts:` field:
+You can specify that you want a sidecar configuration to apply to all workloads
+in a particular namespace, or choose specific workloads using a
+`workloadSelector`. For example, the following sidecar configuration configures
+all services in the `bookinfo` namespace to only reach services running in the
+same namespace and the Istio control plane (currently needed to use Istio’s
+policy and telemetry features):
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -1050,62 +618,37 @@ spec:
egress:
- hosts:
- "./*"
+ - "istio-system/*"
{{< /text >}}
-Sidecars have many uses. Refer to the [sidecar reference](/docs/reference/config/networking/v1alpha3/sidecar/)
-for details.
-
-## Network resilience and testing
-
-Istio provides opt-in failure recovery features that you can configure
-dynamically at runtime through the [Istio traffic management rules](/docs/concepts/traffic-management/#routing-rules).
-With these features, the service mesh can tolerate failing nodes and Istio can
-prevent localized failures from cascading to other nodes:
-
-- **Timeouts and retries**
-
- A timeout is the amount of time that Istio waits for a response to a
- request. A retry is an attempt to complete an operation multiple times if
- it fails. You can set defaults and specify request-level overrides for both
- timeouts and retries or for one or the other.
+See the [Sidecar reference](/docs/reference/config/networking/v1alpha3/sidecar/)
+for more details.
-- **Circuit breakers**
+## Network resilience and testing {#network-resilience-and-testing}
- Circuit breakers prevent your application from stalling as it waits for an
- upstream service to respond. You can configure a circuit breaker based on a
- number of conditions, such as connection and request limits.
+As well as helping you direct traffic around your mesh, Istio provides opt-in
+failure recovery and fault injection features that you can configure dynamically
+at runtime. Using these features helps your applications operate reliably,
+ensuring that the service mesh can tolerate failing nodes and preventing
+localized failures from cascading to other nodes.
-- **Fault injection**
+### Timeouts {#timeouts}
- Fault injection is a testing method that introduces errors into a system to
- ensure that it can withstand and recover from error conditions. You can
- inject faults at the application layer, rather than the network layer, to
- get more relevant results.
+A timeout is the amount of time that an Envoy proxy should wait for replies from
+a given service, ensuring that services don’t hang around waiting for replies
+indefinitely and that calls succeed or fail within a predictable timeframe. The
+default timeout for HTTP requests is 15 seconds, which means that if the service
+doesn’t respond within 15 seconds, the call fails.
-- **Fault tolerance**
-
- You can use Istio failure recovery features to complement application-level
- fault tolerance libraries in situations where their behaviors don’t
- conflict.
-
-{{< warning >}}
-While Istio failure recovery features improve the reliability and availability
-of services in the mesh, applications must handle the failure or errors and
-take appropriate fallback actions. For example, when all instances in a load
-balancing pool have failed, Envoy returns an `HTTP 503` code. The application
-must implement any fallback logic needed to handle the `HTTP 503` error code
-from an upstream service.
-{{< /warning >}}
-
-## Timeouts and retries
-
-You can use Istio's traffic management resources to set defaults for timeouts
-and retries per service and subset that apply to all callers.
-
-### Override default timeout setting
-
-The default timeout for HTTP requests is 15 seconds. You can configure a
-virtual service with a routing rule to override the default, for example:
+For some applications and services, Istio’s default timeout might not be
+appropriate. For example, a timeout that is too long could result in excessive
+latency from waiting for replies from failing services, while a timeout that is
+too short could result in calls failing unnecessarily while waiting for an
+operation involving multiple services to return. To find and use your optimal timeout
+settings, Istio lets you easily adjust timeouts dynamically on a per-service
+basis using [virtual services](#virtual-services) without having to edit your
+service code. Here’s a virtual service that specifies a 10 second timeout for
+calls to the v1 subset of the ratings service:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -1123,18 +666,26 @@ spec:
timeout: 10s
{{< /text >}}
-### Set number and timeouts for retries
-
-You can specify the maximum number of retries for an HTTP request in a virtual
-service, and you can provide specific timeouts for the retries to ensure that
-the calling service gets a response, either success or failure, within a
-predictable time frame.
-
-Envoy proxies automatically add variable jitter between your retries to
-minimize the potential impact of retries on an overloaded upstream service.
-
-The following virtual service configures three attempts with a 2-second
-timeout:
+### Retries {#retries}
+
+A retry setting specifies the maximum number of times an Envoy proxy attempts to
+connect to a service if the initial call fails. Retries can enhance service
+availability and application performance by making sure that calls don’t fail
+permanently because of transient problems such as a temporarily overloaded
+service or network. The interval between retries (25ms+) is variable and
+determined automatically by Istio, preventing the called service from being
+overwhelmed with requests. By default, the Envoy proxy doesn’t attempt to
+reconnect to services after a first failure.
+
+Like timeouts, Istio’s default retry behavior might not suit your application
+needs in terms of latency (too many retries to a failed service can slow things
+down) or availability. Also like timeouts, you can adjust your retry settings on
+a per-service basis in [virtual services](#virtual-services) without having to
+touch your service code. You can also further refine your retry behavior by
+adding per-retry timeouts, specifying the amount of time you want to wait for
+each retry attempt to successfully connect to the service. The following example
+configures a maximum of 3 retries to connect to this service subset after an
+initial call failure, each with a 2 second timeout.
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -1154,29 +705,22 @@ spec:
perTryTimeout: 2s
{{< /text >}}
-Consumers of a service can also override timeout and retry defaults with
-request-level overrides through special HTTP headers. The Envoy proxy
-implementation makes the following headers available:
-
-- Timeouts: `x-envoy-upstream-rq-timeout-ms`
+### Circuit breakers {#circuit-breakers}
-- Retries: `X-envoy-max-retries`
+Circuit breakers are another useful mechanism Istio provides for creating
+resilient microservice-based applications. In a circuit breaker, you set limits
+for calls to individual hosts within a service, such as the number of concurrent
+connections or how many times calls to this host have failed. Once that limit
+has been reached the circuit breaker "trips" and stops further connections to
+that host. Using a circuit breaker pattern enables fast failure rather than
+clients trying to connect to an overloaded or failing host.
-## Circuit breakers
-
-As with timeouts and retries, you can configure a circuit breaker pattern
-without changing your services. While retries let your application recover from
-transient errors, a circuit breaker pattern prevents your application from
-stalling as it waits for an upstream service to respond. By configuring a
-circuit breaker pattern, you allow your application to fail fast and handle the
-error appropriately, for example, by triggering an alert. You can configure a
-simple circuit breaker pattern based on a number of conditions such as
-connection and request limits.
-
-### Limit connections to 100
-
-The following destination rule sets a limit of 100 connections for the
-`reviews` service workloads of the v1 subset:
+As circuit breaking applies to "real" mesh destinations in a load balancing
+pool, you configure circuit breaker thresholds in
+[destination rules](#destination-rules), with the settings applying to each
+individual host in the service. The following example limits the number of
+concurrent connections for the `reviews` service workloads of the v1 subset to
+100:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -1195,42 +739,35 @@ spec:
maxConnections: 100
{{< /text >}}
-See the [circuit-breaking task](/docs/tasks/traffic-management/circuit-breaking/)
-for detailed instructions on how to configure a circuit breaker pattern.
-
-## Fault injection
-
-You can use fault injection to test the end-to-end failure recovery capability
-of the application as a whole. An incorrect configuration of the failure
-recovery policies could result in unavailability of critical services. Examples
-of incorrect configurations include incompatible or restrictive timeouts across
-service calls.
-
-With Istio, you can use application-layer fault injection instead of killing
-pods, delaying packets, or corrupting packets at the TCP layer. You can inject
-more relevant failures at the application layer, such as HTTP error codes, to
-test the resilience of an application.
+You can find out more about creating circuit breakers in
+[Circuit Breaking](/docs/tasks/traffic-management/circuit-breaking/).
-You can inject faults into requests that match specific conditions, and you can
-restrict the percentage of requests Istio subjects to faults.
+### Fault injection {#fault-injection}
-You can inject two types of faults:
+After you’ve configured your network, including failure recovery policies, you
+can use Istio’s fault injection mechanisms to test the failure recovery capacity
+of your application as a whole. Fault injection is a testing method that
+introduces errors into a system to ensure that it can withstand and recover from
+error conditions. Using fault injection can be particularly useful to ensure
+that your failure recovery policies aren’t incompatible or too restrictive,
+potentially resulting in critical services being unavailable.
-- **Delays:** Delays are timing failures. They mimic increased network latency
- or an overloaded upstream service.
+Unlike other mechanisms for introducing errors such as delaying packets or
+killing pods at the network layer, Istio’ lets you inject faults at the
+application layer. This lets you inject more relevant failures, such as HTTP
+error codes, to get more relevant results.
-- **Aborts:** Aborts are crash failures. They mimic failures in upstream
- services. Aborts usually manifest in the form of HTTP error codes or TCP
- connection failures.
+You can inject two types of faults, both configured using a
+[virtual service](#virtual-services):
-You can configure a virtual service to inject one or more faults while
-forwarding HTTP requests to the rule's corresponding request destination. The
-faults can be either delays or aborts.
+- Delays: Delays are timing failures. They mimic increased network latency or
+ an overloaded upstream service.
+- Aborts: Aborts are crash failures. They mimic failures in upstream services.
+ Aborts usually manifest in the form of HTTP error codes or TCP connection
+ failures.
-### Introduce a 5 second delay in 10% of requests
-
-You can configure a virtual service to introduce a 5 second delay for 10% of
-the requests to the `ratings` service.
+For example, this virtual service introduces a 5 second delay for 1 out of every 1000
+requests to the `ratings` service.
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@@ -1252,75 +789,121 @@ spec:
subset: v1
{{< /text >}}
-### Return an HTTP 400 error code for 10% of requests
+For detailed instructions on how to configure delays and aborts, see
+[Fault Injection](/docs/tasks/traffic-management/fault-injection/).
-You can configure an abort instead to terminate a request and simulate a
-failure.
+### Working with your applications {#working-with-your-applications}
-{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: ratings
-spec:
- hosts:
- - ratings
- http:
- - fault:
- abort:
- percentage:
- value: 0.1
- httpStatus: 400
- route:
- - destination:
- host: ratings
- subset: v1
-{{< /text >}}
+Istio failure recovery features are completely transparent to the
+application. Applications don’t know if an Envoy sidecar proxy is handling
+failures for a called service before returning a response. This means that
+if you are also setting failure recovery policies in your application code
+you need to keep in mind that both work independently, and therefore might
+conflict. For example, suppose you can have two timeouts, one configured in
+a virtual service and another in the application. The application sets a 2
+second timeout for an API call to a service. However, you configured a 3
+second timeout with 1 retry in your virtual service. In this case, the
+application’s timeout kicks in first, so your Envoy timeout and retry
+attempt has no effect.
-### Combine delay and abort faults
+While Istio failure recovery features improve the reliability and
+availability of services in the mesh, applications must handle the failure
+or errors and take appropriate fallback actions. For example, when all
+instances in a load balancing pool have failed, Envoy returns an `HTTP 503`
+code. The application must implement any fallback logic needed to handle the
+`HTTP 503` error code..
-You can use delay and abort faults together. The following configuration
-introduces a delay of 5 seconds for all requests to the `v1` subset of the
-`ratings` service and an abort for 10% of them:
+## Architecture {#architecture}
-{{< text yaml >}}
-apiVersion: networking.istio.io/v1alpha3
-kind: VirtualService
-metadata:
- name: ratings
-spec:
- hosts:
- - ratings
- http:
- - fault:
- delay:
- fixedDelay: 5s
- abort:
- percentage:
- value: 0.1
- httpStatus: 400
- route:
- - destination:
- host: ratings
- subset: v1
-{{< /text >}}
+Istio's traffic management model relies on the following two components:
+
+- {{< gloss >}}Pilot{{}}, the core traffic management component.
+- {{< gloss >}}Envoy{{}} proxies, which enforce configurations and
+ policies set through Pilot.
+
+These components enable the following Istio traffic management features:
+
+- Service discovery
+- Load balancing
+- Traffic routing and control
+
+### Pilot: Core traffic management {#pilot}
+
+The following diagram shows the Pilot architecture:
+
+{{< image width="40%" link="./pilot-arch.svg" caption="Pilot architecture" >}}
+
+As the diagram illustrates, Pilot maintains an **abstract model** of all the
+services in the mesh. **Platform-specific adapters** in Pilot translate the
+abstract model appropriately for your platform. For example, the Kubernetes
+adapter implements controllers to watch the Kubernetes API server for changes to
+pod registration information and service resources. The Kubernetes adapter
+translates this data for the abstract model.
+
+Pilot uses the abstract model to generate appropriate Envoy-specific
+configurations to let Envoy proxies know about one another in the mesh through
+the [Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api).
+
+You can use Istio's [Traffic Management API](#introducing-istio-traffic-management) to instruct Pilot to refine the
+Envoy configuration to exercise more granular control over the traffic in your
+service mesh.
-For detailed instructions on how to configure delays and aborts, visit our
-[fault injection task](/docs/tasks/traffic-management/fault-injection/).
+### Envoy proxies
+
+Traffic in Istio is categorized as data plane traffic and control plane traffic.
+Data plane traffic refers to the messages that the business logic of the workloads
+send and receive. Control plane traffic refers to configuration and control messages sent
+between Istio components to program the behavior of the mesh. Traffic management
+in Istio refers exclusively to data plane traffic.
+
+Envoy proxies are the only Istio components that interact with data plane
+traffic. Envoy proxies route the data plane traffic across the mesh and enforce
+the configurations and traffic rules without the services having to be aware of
+them. Envoy proxies mediate all inbound and outbound traffic for all services in
+the mesh. Envoy proxies are deployed as sidecars to services, logically
+augmenting the services with traffic management features:
+
+- service discovery and load balancing
+- traffic routing and configuration
+- network resilience and testing
+
+Some of the features and tasks enabled by Envoy proxies include:
+
+- Traffic control features: enforce fine-grained traffic control with rich
+ routing rules for HTTP, gRPC, WebSocket, and TCP traffic.
+
+- Network resiliency features: setup retries, failovers, circuit breakers, and
+ fault injection.
+
+- Security and authentication features: enforce security policies and enforce
+ access control and rate limiting defined through the configuration API.
+
+#### Service discovery and load balancing {#discovery}
+
+Istio service discovery leverages the service discovery features provided by
+platforms like Kubernetes for container-based applications. Service discovery
+works in a similar way regardless of what platform you're using:
+
+1. The platform starts a new instance of a service which notifies its platform
+ adapter.
+
+1. The platform adapter registers the instance with the Pilot abstract model.
+
+1. **Pilot** distributes traffic rules and configurations to the Envoy proxies
+ to account for the change.
+
+The following diagram shows how the platform adapters and Envoy proxies
+interact.
-## Compatibility with application-level fault handling
+{{< image width="40%" link="./discovery.svg" caption="Service discovery" >}}
-Istio failure recovery features are completely transparent to the application.
-Applications don't know if an Envoy sidecar proxy is handling
-failures for a called upstream service, before returning a response.
+Because the service discovery feature is platform-independent, a service mesh
+can include services across multiple platforms.
-When you use application-level fault tolerance libraries and Envoy proxy
-failure recovery policies at the same time, you need to keep in mind that
-both work independently, and therefore might conflict.
+Using the abstract model, Pilot configures the Envoy proxies to perform load
+balancing for service requests, replacing any underlying platform-specific load
+balancing feature. In the absence of more specific routing rules, Envoy will
+distribute the traffic across the instances in the calling service's load
+balancing pool, according to the Pilot abstract model and load balancer
+configuration.
-For example: Suppose you can have two timeouts, one configured in a virtual
-service and another in the application. The application sets a
-2 second timeout for an API call to a service. However, you configured a
-3 second timeout with 1 retry in your virtual service. In this case,
-the application's timeout kicks in first, so your Envoy timeout and retry
-attempt has no affect.
diff --git a/content/en/docs/concepts/traffic-management/pilot-arch.svg b/content/en/docs/concepts/traffic-management/pilot-arch.svg
index 41de07febf5d..4a3d17c3442e 100644
--- a/content/en/docs/concepts/traffic-management/pilot-arch.svg
+++ b/content/en/docs/concepts/traffic-management/pilot-arch.svg
@@ -1,513 +1 @@
-
-
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/routing-overview.svg b/content/en/docs/concepts/traffic-management/routing-overview.svg
index 30f7a74d7265..0cb1e18eb3bf 100644
--- a/content/en/docs/concepts/traffic-management/routing-overview.svg
+++ b/content/en/docs/concepts/traffic-management/routing-overview.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/service-entries-1.svg b/content/en/docs/concepts/traffic-management/service-entries-1.svg
index 82ce477bd146..8bd9fa35cad0 100644
--- a/content/en/docs/concepts/traffic-management/service-entries-1.svg
+++ b/content/en/docs/concepts/traffic-management/service-entries-1.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/virtual-services-1.svg b/content/en/docs/concepts/traffic-management/virtual-services-1.svg
index 2361c9720a30..34d0fc402eb3 100644
--- a/content/en/docs/concepts/traffic-management/virtual-services-1.svg
+++ b/content/en/docs/concepts/traffic-management/virtual-services-1.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/virtual-services-2.svg b/content/en/docs/concepts/traffic-management/virtual-services-2.svg
index bdb4c7c3e186..01c57b6ffe2d 100644
--- a/content/en/docs/concepts/traffic-management/virtual-services-2.svg
+++ b/content/en/docs/concepts/traffic-management/virtual-services-2.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/virtual-services-3.svg b/content/en/docs/concepts/traffic-management/virtual-services-3.svg
index 4c4565e991bb..895e714bc564 100644
--- a/content/en/docs/concepts/traffic-management/virtual-services-3.svg
+++ b/content/en/docs/concepts/traffic-management/virtual-services-3.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/virtual-services-4.svg b/content/en/docs/concepts/traffic-management/virtual-services-4.svg
index 9bdc8bc7abc4..5a556e2cfa2e 100644
--- a/content/en/docs/concepts/traffic-management/virtual-services-4.svg
+++ b/content/en/docs/concepts/traffic-management/virtual-services-4.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/virtual-services-5.svg b/content/en/docs/concepts/traffic-management/virtual-services-5.svg
index 04ae0116c9d4..6f4c3b14e515 100644
--- a/content/en/docs/concepts/traffic-management/virtual-services-5.svg
+++ b/content/en/docs/concepts/traffic-management/virtual-services-5.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/traffic-management/virtual-services-6.svg b/content/en/docs/concepts/traffic-management/virtual-services-6.svg
index 5e097affc3f6..1f6e09234d36 100644
--- a/content/en/docs/concepts/traffic-management/virtual-services-6.svg
+++ b/content/en/docs/concepts/traffic-management/virtual-services-6.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/concepts/what-is-istio/arch.svg b/content/en/docs/concepts/what-is-istio/arch.svg
index 097b7118cad3..731f288f07b8 100644
--- a/content/en/docs/concepts/what-is-istio/arch.svg
+++ b/content/en/docs/concepts/what-is-istio/arch.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/examples/bookinfo/noistio.svg b/content/en/docs/examples/bookinfo/noistio.svg
index 92fcfbd07de6..7e1da78815f4 100644
--- a/content/en/docs/examples/bookinfo/noistio.svg
+++ b/content/en/docs/examples/bookinfo/noistio.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/examples/bookinfo/withistio.svg b/content/en/docs/examples/bookinfo/withistio.svg
index dc531dfea4b5..f48ea99cd6e8 100644
--- a/content/en/docs/examples/bookinfo/withistio.svg
+++ b/content/en/docs/examples/bookinfo/withistio.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/examples/mesh-expansion/bookinfo-expanded/mesh-expansion.svg b/content/en/docs/examples/mesh-expansion/bookinfo-expanded/mesh-expansion.svg
index 530313d61157..30d3ba172e6b 100644
--- a/content/en/docs/examples/mesh-expansion/bookinfo-expanded/mesh-expansion.svg
+++ b/content/en/docs/examples/mesh-expansion/bookinfo-expanded/mesh-expansion.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/examples/mesh-expansion/multi-network/index.md b/content/en/docs/examples/mesh-expansion/multi-network/index.md
index 68f95e42397d..5ccbbfd72028 100644
--- a/content/en/docs/examples/mesh-expansion/multi-network/index.md
+++ b/content/en/docs/examples/mesh-expansion/multi-network/index.md
@@ -186,7 +186,7 @@ Next, run the following commands on each machine that you want to add to the mes
$ sudo dpkg -i istio-sidecar.deb
{{< /text >}}
-1. Add the IP address of the Istio gateway to `/etc/hosts`. Revisit the [Customized installation of Istio on the Cluster](#Customized-installation-of-Istio-on-the-Cluster) section to learn how to obtain the IP address.
+1. Add the IP address of the Istio gateway to `/etc/hosts`. Revisit the [Customized installation of Istio on the Cluster](#customized-installation-of-istio-on-the-cluster) section to learn how to obtain the IP address.
The following example updates the `/etc/hosts` file with the Istio gateway address:
{{< text bash >}}
@@ -323,7 +323,7 @@ in the cluster.
The gateway for port 15443 is a special SNI-aware Envoy
preconfigured and installed as part of the meshexpansion with gateway Istio installation step
- in the [Customized installation of Istio on the Cluster](#Customized-installation-of-Istio-on-the-Cluster) section. Traffic entering port 15443 will be
+ in the [Customized installation of Istio on the Cluster](#customized-installation-of-istio-on-the-cluster) section. Traffic entering port 15443 will be
load balanced among pods of the appropriate internal service of the target
cluster (in this case, `httpbin.bar` in the cluster).
diff --git a/content/en/docs/ops/app-health-check/index.md b/content/en/docs/ops/app-health-check/index.md
index 68e1c2847e1b..66dc269f7fb4 100644
--- a/content/en/docs/ops/app-health-check/index.md
+++ b/content/en/docs/ops/app-health-check/index.md
@@ -106,7 +106,7 @@ You have two ways to enable Istio to rewrite the liveness HTTP probes.
**Alternatively**, update the configuration map of Istio sidecar injection:
{{< text bash >}}
-$ kubectl get cm istio-sidecar-injector -n istio-system -o yaml | sed -e "s/ rewriteAppHTTPProbe: false/ rewriteAppHTTPProbe: true/" | kubectl apply -f -
+$ kubectl get cm istio-sidecar-injector -n istio-system -o yaml | sed -e 's/"rewriteAppHTTPProbe":false/"rewriteAppHTTPProbe":true/' | kubectl apply -f -
{{< /text >}}
The above installation option and configuration map, each instruct the sidecar injection process to automatically
diff --git a/content/en/docs/ops/security/root-transition/index.md b/content/en/docs/ops/security/root-transition/index.md
index ee6c2d9d3984..df6286757198 100644
--- a/content/en/docs/ops/security/root-transition/index.md
+++ b/content/en/docs/ops/security/root-transition/index.md
@@ -130,7 +130,7 @@ please follow the procedure and check whether you will be affected.
The following command shows an example to check the Envoy’s certificate for pod _foo_ running in namespace _bar_.
{{< text bash>}}
- $ kubectl exec -it foo -c istio-proxy -n bar -- curl http://localhost:15000/certs | head -c 1000
+ $ kubectl exec -foo -c istio-proxy -n bar -- pilot-agent request GET certs | head -c 1000
{
"certificates": [
{
diff --git a/content/en/docs/ops/telemetry/envoy-stats/index.md b/content/en/docs/ops/telemetry/envoy-stats/index.md
index cc46436b7d18..dc313cb11b46 100644
--- a/content/en/docs/ops/telemetry/envoy-stats/index.md
+++ b/content/en/docs/ops/telemetry/envoy-stats/index.md
@@ -15,7 +15,7 @@ statistics the Envoy proxies record can provide more information about specific
To see the statistics for a pod:
{{< text bash >}}
-$ kubectl exec -it $POD -c istio-proxy -- sh -c 'curl localhost:15000/stats'
+$ kubectl exec $POD -c istio-proxy -- pilot-agent request GET stats
{{< /text >}}
See [the Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/configuration/upstream/cluster_manager/cluster_stats)
diff --git a/content/en/docs/ops/troubleshooting/istioctl-describe/index.md b/content/en/docs/ops/troubleshooting/istioctl-describe/index.md
new file mode 100644
index 000000000000..a7d0e4818bd7
--- /dev/null
+++ b/content/en/docs/ops/troubleshooting/istioctl-describe/index.md
@@ -0,0 +1,304 @@
+---
+title: Understand your Mesh with istioctl describe
+description: Shows you how to use istioctl describe to verify the configurations of a pod in your mesh.
+weight: 90
+keywords: [traffic-management, istioctl, debugging, kubernetes]
+---
+
+{{< boilerplate experimental-feature-warning >}}
+
+In Istio 1.3, we included the [`istioctl experimental describe`](/docs/reference/commands/istioctl/#istioctl-experimental-describe-pod)
+command. This CLI command provides you with the information needed to understand
+the configuration impacting a {{< gloss >}}pod{{< /gloss >}}. This guide shows
+you how to use this experimental sub-command to see if a pod is in the mesh and
+verify its configuration.
+
+The basic usage of the command is as follows:
+
+{{< text bash >}}
+$ istioctl experimental describe [.]
+{{< /text >}}
+
+Appending a namespace to the pod name has the same affect as using the `-n` option
+of `istioctl` to specify a non-default namespace.
+
+{{< tip >}}
+Just like all other `istioctl` commands, you can replace `experimental`
+with `x` for convenience.
+{{< /tip >}}
+
+This guide assumes you have deployed the [Bookinfo](/docs/examples/bookinfo/)
+sample in your mesh. If you haven't already done so,
+[start the application's services](/docs/examples/bookinfo/#start-the-application-services)
+and [determine the IP and port of the ingress](/docs/examples/bookinfo/#determine-the-ingress-ip-and-port)
+before continuing.
+
+## Verify a pod is in the mesh
+
+The `istioctl describe` command returns a warning if the {{< gloss >}}Envoy{{< /gloss >}}
+proxy is not present in a pod or if the proxy has not started. Additionally, the command warns
+if some of the [Istio requirements for pods](/docs/setup/additional-setup/requirements/)
+are not met.
+
+For example, the following command produces a warning indicating a `kubernetes-dashboard`
+pod is not part of the service mesh because it has no sidecar:
+
+{{< text bash >}}
+$ export DASHBOARD_POD=$(kubectl -n kube-system get pod -l k8s-app=kubernetes-dashboard -o jsonpath='{.items[0].metadata.name}')
+$ istioctl x describe pod -n kube-system $DASHBOARD_POD
+WARNING: kubernetes-dashboard-7996b848f4-nbns2.kube-system is not part of mesh; no Istio sidecar
+{{< /text >}}
+
+The command will not produce such a warning for a pod that is part of the mesh,
+the Bookinfo `ratings` service for example, but instead will output the Istio configuration applied to the pod:
+
+{{< text bash >}}
+$ export RATINGS_POD=$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')
+$ istioctl experimental describe pod $RATINGS_POD
+Pod: ratings-v1-f745cf57b-qrxl2
+Pod Ports: 9080 (ratings), 15090 (istio-proxy)
+--------------------
+Service: ratings
+ Port: http 9080/HTTP
+Pilot reports that pod enforces HTTP/mTLS and clients speak HTTP
+{{< /text >}}
+
+The output shows the following information:
+
+- The ports of the service container in the pod, `9080` for the `ratings` container in this example.
+- The ports of the `istio-proxy` container in the pod, `15090` in this example.
+- The protocol used by the service in the pod, `HTTP` over port `9080` in this example.
+- The mutual TLS settings for the pod.
+
+## Verify destination rule configurations
+
+You can use `istioctl describe` to see what
+[destination rules](/docs/concepts/traffic-management/#destination-rules) apply to requests
+to a pod. For example, apply the Bookinfo
+[mutual TLS destination rules]({{< github_file >}}/samples/bookinfo/networking/destination-rule-all-mtls.yaml):
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
+{{< /text >}}
+
+Now describe the `ratings` pod again:
+
+{{< text bash >}}
+$ istioctl x describe pod $RATINGS_POD
+Pod: ratings-v1-f745cf57b-qrxl2
+ Pod Ports: 9080 (ratings), 15090 (istio-proxy)
+--------------------
+Service: ratings
+ Port: http 9080/HTTP
+DestinationRule: ratings for "ratings"
+ Matching subsets: v1
+ (Non-matching subsets v2,v2-mysql,v2-mysql-vm)
+ Traffic Policy TLS Mode: ISTIO_MUTUAL
+Pilot reports that pod enforces HTTP/mTLS and clients speak mTLS
+{{< /text >}}
+
+The command now shows additional output:
+
+- The `ratings` destination rule applies to request to the `ratings` service.
+- The subset of the `ratings` destination rule that matches the pod, `v1` in this example.
+- The other subsets defined by the destination rule.
+- The pod accepts either HTTP or mutual TLS requests but clients use mutual TLS.
+
+## Verify virtual service configurations
+
+When [virtual services](/docs/concepts/traffic-management/#virtual-services) configure
+routes to a pod, `istioctl describe` will also include the routes in its output.
+For example, apply the
+[Bookinfo virtual services]({{< github_file>}}/samples/bookinfo/networking/virtual-service-all-v1.yaml)
+that route all requests to `v1` pods:
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
+{{< /text >}}
+
+Then, describe a pod implementing `v1` of the `reviews` service:
+
+{{< text bash >}}
+$ export REVIEWS_V1_POD=$(kubectl get pod -l app=reviews,version=v1 -o jsonpath='{.items[0].metadata.name}')
+$ istioctl x describe pod $REVIEWS_V1_POD
+...
+VirtualService: reviews
+ 1 HTTP route(s)
+{{< /text >}}
+
+The output contains similar information to that shown previously for the `ratings` pod,
+but it also includes the virtual service's routes to the pod.
+
+The `istioctl describe` command doesn't just show the virtual services impacting the pod.
+If a virtual service configures the service host of a pod but no traffic will reach it,
+the command's output includes a warning. This case can occur if the virtual service
+actually blocks traffic by never routing traffic to the pod's subset. For
+example:
+
+{{< text bash >}}
+$ export REVIEWS_V2_POD=$(kubectl get pod -l app=reviews,version=v2 -o jsonpath='{.items[0].metadata.name}')
+$ istioctl x describe pod $REVIEWS_V2_POD
+...
+VirtualService: reviews
+ WARNING: No destinations match pod subsets (checked 1 HTTP routes)
+ Route to non-matching subset v1 for (everything)
+{{< /text >}}
+
+The warning includes the cause of the problem, how many routes were checked, and
+even gives you information about the other routes in place. In this example,
+no traffic arrives at the `v2` pod because the route in the virtual service directs all
+traffic to the `v1` subset.
+
+If you now delete the Bookinfo destination rules:
+
+{{< text bash >}}
+$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
+{{< /text >}}
+
+You can see another useful feature of `istioctl describe`:
+
+{{< text bash >}}
+$ istioctl x describe pod $REVIEWS_V1_POD
+...
+VirtualService: reviews
+ WARNING: No destinations match pod subsets (checked 1 HTTP routes)
+ Warning: Route to subset v1 but NO DESTINATION RULE defining subsets!
+{{< /text >}}
+
+The output shows you that you deleted the destination rule but not the virtual
+service that depends on it. The virtual service routes traffic to the `v1`
+subset, but there is no destination rule defining the `v1` subset.
+Thus, traffic destined for version `v1` can't flow to the pod.
+
+If you refresh the browser to send a new request to Bookinfo at this
+point, you would see the following message: `Error fetching product reviews`.
+To fix the problem, reapply the destination rule:
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
+{{< /text >}}
+
+Reloading the browser shows the app working again and
+running `istioctl experimental describe pod $REVIEWS_V1_POD` no longer produces
+warnings.
+
+## Verifying traffic routes
+
+The `istioctl describe` command shows split traffic weights too.
+For example, run the following command to route 90% of traffic to the `v1` subset
+and 10% to the `v2` subset of the the `reviews` service:
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-90-10.yaml@
+{{< /text >}}
+
+Now describe the `reviews` `v1` pod:
+
+{{< text bash >}}
+$ istioctl x describe pod $REVIEWS_V1_POD
+...
+VirtualService: reviews
+ Weight 90%
+{{< /text >}}
+
+The output shows that the `reviews` virtual service has a weight of 90% for the
+`v1` subset.
+
+This function is also helpful for other types of routing. For example, you can deploy
+header-specific routing:
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@
+{{< /text >}}
+
+Then, describe the pod again:
+
+{{< text bash >}}
+$ istioctl x describe pod $REVIEWS_V1_POD
+...
+VirtualService: reviews
+ WARNING: No destinations match pod subsets (checked 2 HTTP routes)
+ Route to non-matching subset v2 for (when headers are end-user=jason)
+ Route to non-matching subset v3 for (everything)
+{{< /text >}}
+
+The output produces a warning since you are describing a pod in the `v1` subset.
+However, the virtual service configuration you applied routes traffic to the `v2`
+subset if the header contains `end-user=jason` and to the `v3` subset in all
+other cases.
+
+## Verifying strict mutual TLS
+
+Following the [mutual TLS migration](/docs/tasks/security/mtls-migration/)
+instructions, you can enable strict mutual TLS for the `ratings` service:
+
+{{< text bash >}}
+$ kubectl apply -f - <}}
+
+Run the following command to describe the `ratings` pod:
+
+{{< text bash >}}
+$ istioctl x describe pod $RATINGS_POD
+Pilot reports that pod enforces mTLS and clients speak mTLS
+{{< /text >}}
+
+The output reports that requests to the the `ratings` pod are now locked down and secure.
+
+Sometimes, however, a deployment breaks when switching mutual TLS to `STRICT`.
+The likely cause is that the destination rule didn't match the new configuration.
+For example, if you configure the Bookinfo clients to not use mutual TLS using the
+[plain HTTP destination rules]({{< github_file >}}/samples/bookinfo/networking/destination-rule-all.yaml):
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
+{{< /text >}}
+
+If you open Bookinfo in your browser, you see `Ratings service is currently unavailable`.
+To learn why, run the following command:
+
+{{< text bash >}}
+$ istioctl x describe pod $RATINGS_POD
+...
+WARNING Pilot predicts TLS Conflict on ratings-v1-f745cf57b-qrxl2 port 9080 (pod enforces mTLS, clients speak HTTP)
+ Check DestinationRule ratings/default and AuthenticationPolicy ratings-strict/default
+{{< /text >}}
+
+The output includes a warning describing the conflict
+between the destination rule and the authentication policy.
+
+You can restore correct behavior by applying a destination rule that uses
+mutual TLS:
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
+{{< /text >}}
+
+## Conclusion and cleanup
+
+Our goal with the `istioctl x describe` command is to help you understand the
+traffic and security configurations in your Istio mesh.
+
+We would love to hear your ideas for improvements!
+Please join us at [https://discuss.istio.io](https://discuss.istio.io).
+
+To remove the Bookinfo pods and configurations used in this guide, run the
+following commands:
+
+{{< text bash >}}
+$ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo.yaml@
+$ kubectl delete -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
+$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
+$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
+{{< /text >}}
diff --git a/content/en/docs/ops/troubleshooting/proxy-cmd/index.md b/content/en/docs/ops/troubleshooting/proxy-cmd/index.md
index abc63dd88635..a68cfacfcd7f 100644
--- a/content/en/docs/ops/troubleshooting/proxy-cmd/index.md
+++ b/content/en/docs/ops/troubleshooting/proxy-cmd/index.md
@@ -351,14 +351,8 @@ You should receive a response listing the "service-key" and "hosts" for each ser
To find out the Envoy version used in deployment, you can `exec` into the container and query the `server_info` endpoint:
{{< text bash >}}
-$ kubectl exec -it PODNAME -c istio-proxy -n NAMESPACE /bin/bash
-root@5c7e9d3a4b67:/# curl localhost:15000/server_info
-envoy 0/1.9.0-dev//RELEASE live 57964 57964 0
-{{< /text >}}
-
-In addition, the `Envoy` and `istio-api` repository versions are stored as labels on the image:
-
-{{< text bash >}}
-$ docker inspect -f '{{json .Config.Labels }}' ISTIO-PROXY-IMAGE
-{"envoy-vcs-ref":"b3be5713f2100ab5c40316e73ce34581245bd26a","istio-api-vcs-ref":"825044c7e15f6723d558b7b878855670663c2e1e"}
+$ kubectl exec -it PODNAME -c istio-proxy -n NAMESPACE pilot-agent request GET server_info
+{
+ "version": "48bc83d8f0582fc060ef76d5aa3d75400e739d9e/1.12.0-dev/Clean/RELEASE/BoringSSL"
+}
{{< /text >}}
diff --git a/content/en/docs/ops/troubleshooting/security-issues/index.md b/content/en/docs/ops/troubleshooting/security-issues/index.md
index 0ab10be612f0..542254bc05ef 100644
--- a/content/en/docs/ops/troubleshooting/security-issues/index.md
+++ b/content/en/docs/ops/troubleshooting/security-issues/index.md
@@ -195,7 +195,7 @@ otherwise you should replace `"-l app=productpage"` with your actual pod.
1. Run the following command to get the proxy configuration dump for the `productpage` service:
{{< text bash >}}
- $ kubectl exec $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl localhost:15000/config_dump -s
+ $ kubectl exec $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- pilot-agent request GET config_dump
{{< /text >}}
1. Check the log and verify:
@@ -268,7 +268,7 @@ otherwise you should replace `"-l app=productpage"` with your actual pod.
1. Turn on the authorization debug logging in proxy with the following command:
{{< text bash >}}
- $ kubectl exec $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl -X POST localhost:15000/logging?rbac=debug -s
+ $ kubectl exec $(kubectl get pods -l app=productpage -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
{{< /text >}}
1. Verify you see the following output:
diff --git a/content/en/docs/reference/commands/galley/index.html b/content/en/docs/reference/commands/galley/index.html
index 6d1114f5280f..61efbac3f9bb 100644
--- a/content/en/docs/reference/commands/galley/index.html
+++ b/content/en/docs/reference/commands/galley/index.html
@@ -29,12 +29,12 @@
--log_caller <string>
-
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
+
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--log_rotate <string>
@@ -59,7 +59,7 @@
--log_stacktrace_level <string>
-
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
+
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
--log_target <stringArray>
@@ -99,12 +99,12 @@
galley probe
--log_caller <string>
-
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
+
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--log_rotate <string>
@@ -129,7 +129,7 @@
galley probe
--log_stacktrace_level <string>
-
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
+
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
--log_target <stringArray>
@@ -264,12 +264,12 @@
galley server
--log_caller <string>
-
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
+
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--log_rotate <string>
@@ -294,7 +294,7 @@
galley server
--log_stacktrace_level <string>
-
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
+
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
--log_target <stringArray>
@@ -451,12 +451,12 @@
galley version
--log_caller <string>
-
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
+
Comma-separated list of scopes for which to include caller information, scopes can be any of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] (default ``)
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--log_rotate <string>
@@ -481,7 +481,7 @@
galley version
--log_stacktrace_level <string>
-
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
+
Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [all, analysis, attributes, conversions, default, grpcAdapter, kube, kube-converter, mcp, meshconfig, model, processing, rbac, resource, runtime, server, source, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)
Istio configuration command line utility for service operators to
debug and diagnose their Istio mesh.
@@ -36,7 +36,7 @@
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -76,7 +76,7 @@
istioctl auth
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -117,7 +117,7 @@
istioctl authn
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -164,7 +164,7 @@
istioctl authn tls-check
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -219,7 +219,7 @@
istioctl convert-ingress
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -271,7 +271,7 @@
istioctl dashboard
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -316,7 +316,7 @@
istioctl dashboard controlz
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -359,7 +359,7 @@
istioctl dashboard envoy
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -402,7 +402,7 @@
istioctl dashboard grafana
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -445,7 +445,7 @@
istioctl dashboard jaeger
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -488,7 +488,7 @@
istioctl dashboard kiali
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -531,7 +531,7 @@
istioctl dashboard prometheus
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -574,7 +574,7 @@
istioctl dashboard zipkin
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -617,7 +617,7 @@
istioctl deregister
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -659,7 +659,7 @@
istioctl experimental
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -702,7 +702,7 @@
istioctl experimental add-to-mesh
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -756,7 +756,7 @@
istioctl experimenta
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -820,7 +820,7 @@
istioctl experimental add-to-
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--meshConfigFile <string>
@@ -846,6 +846,63 @@
istioctl experimental add-to-
Examples
istioctl experimental add-to-mesh service productpage
+
+
istioctl experimental analyze
+
Analyze Istio configuration and print validation messages
+
istioctl experimental analyze <file>... [flags]
+
+
+
+
+
Flags
+
Shorthand
+
Description
+
+
+
+
+
--context <string>
+
+
The name of the kubeconfig context to use (default ``)
+
+
+
--istioNamespace <string>
+
-i
+
Istio system namespace (default `istio-system`)
+
+
+
--kubeconfig <string>
+
-c
+
Kubernetes configuration file (default ``)
+
+
+
--log_output_level <string>
+
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
+
+
--namespace <string>
+
-n
+
Config namespace (default ``)
+
+
+
--use-kube
+
-k
+
Use live kubernetes cluster for analysis
+
+
+
+
Examples
+
+# Analyze yaml files
+istioctl experimental analyze a.yaml b.yaml
+
+# Analyze the current live cluster
+istioctl experimental analyze -k
+
+# Analyze the current live cluster, simulating the effect of applying additional yaml files
+istioctl experimental analyze -k a.yaml b.yaml
+
istioctl experimental auth
Commands to inspect and interact with the authentication (TLS, JWT) and authorization (RBAC) policies in the mesh
@@ -879,7 +936,7 @@
istioctl experimental auth
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -945,7 +1002,7 @@
istioctl experimental auth check
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1001,7 +1058,7 @@
istioctl experimental auth validate
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1044,7 +1101,7 @@
istioctl experimental convert-ing
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1084,7 +1141,7 @@
istioctl experimental dashboard
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1127,7 +1184,7 @@
istioctl experimental describe
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1175,7 +1232,7 @@
istioctl experimental describe pod
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1226,7 +1283,7 @@
istioctl experimental kube-uninject
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1253,7 +1310,7 @@
Examples
istioctl experimental manifest
-
The manifest subcommand is used to generate, apply, diff or migrate Istio manifests.
+
The manifest subcommand generates, applies, diffs or migrates Istio manifests.
@@ -1286,7 +1343,7 @@
istioctl experimental manifest
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1306,7 +1363,7 @@
istioctl experimental manifest
istioctl experimental manifest apply
-
The apply subcommand is used to generate an Istio install manifest and apply it to a cluster.
+
The apply subcommand generates an Istio install manifest and applies it to a cluster.
istioctl experimental manifest apply [flags]
@@ -1331,7 +1388,7 @@
istioctl experimental manifest app
--filename <string>
-f
-
Path to file containing IstioControlPlane CustomResource. (default ``)
+
Path to file containing IstioControlPlane CustomResource (default ``)
--istioNamespace <string>
@@ -1346,7 +1403,7 @@
istioctl experimental manifest app
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1361,14 +1418,14 @@
istioctl experimental manifest app
--readiness-timeout <duration>
-
Maximum time to wait for all Istio resources to be ready.--wait must be set for this flag to apply. (default `5m0s`)
+
Maximum seconds to wait for all Istio resources to be ready. The --wait flag must be set for this flag to apply (default `5m0s`)
--set <stringSlice>
-s
Set a value in IstioControlPlane CustomResource. e.g. --set policy.enabled=true.
Overrides the corresponding path value in the selected profile or passed through IstioControlPlane CR
-customization file. (default `[]`)
+customization file (default `[]`)
--verbose
@@ -1378,13 +1435,18 @@
istioctl experimental manifest app
--wait
-w
-
Wait, if set will wait until all Pods, Services, and minimum number of Pods of a Deployment are in a ready state before the command exits. It will wait for a maximum duration of --readiness-timeout seconds.
+
Wait, if set will wait until all Pods, Services, and minimum number of Pods of a Deployment are in a ready state before the command exits. It will wait for a maximum duration of --readiness-timeout seconds
+
+
+
--yes
+
-y
+
Do not ask for confirmation
istioctl experimental manifest diff
-
The diff-manifest subcommand is used to compare manifest from two files or directories.
-
istioctl experimental manifest diff [flags]
+
The diff subcommand compares manifests from two files or directories.
ignoreResources ignores all listed items during comparison. It uses the same list format as selectResources. (default ``)
+
ignoreResources ignores all listed items during comparison. It uses the same list format as selectResources (default ``)
--istioNamespace <string>
@@ -1428,7 +1490,7 @@
istioctl experimental manifest diff
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1447,7 +1509,7 @@
istioctl experimental manifest diff
The format of each list item is "::" and the items are comma separated. The "*" character represents wildcard selection.
e.g.
Deployment:istio-system:* - compare all deployments in istio-system namespace
- Service:*:istio-pilot - compare Services called "istio-pilot" in all namespaces. (default `::`)
+ Service:*:istio-pilot - compare Services called "istio-pilot" in all namespaces (default `::`)
--verbose
@@ -1457,7 +1519,7 @@
istioctl experimental manifest diff
istioctl experimental manifest generate
-
The generate subcommand is used to generate an Istio install manifest.
+
The generate subcommand generates an Istio install manifest and outputs to the console by default.
istioctl experimental manifest generate [flags]
@@ -1482,7 +1544,7 @@
istioctl experimental manifest
--filename <string>
-f
-
Path to file containing IstioControlPlane CustomResource. (default ``)
+
Path to file containing IstioControlPlane CustomResource (default ``)
--istioNamespace <string>
@@ -1497,7 +1559,7 @@
istioctl experimental manifest
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1512,14 +1574,14 @@
istioctl experimental manifest
--output <string>
-o
-
Manifest output directory path. (default ``)
+
Manifest output directory path (default ``)
--set <stringSlice>
-s
Set a value in IstioControlPlane CustomResource. e.g. --set policy.enabled=true.
Overrides the corresponding path value in the selected profile or passed through IstioControlPlane CR
-customization file. (default `[]`)
+customization file (default `[]`)
--verbose
@@ -1529,8 +1591,8 @@
istioctl experimental manifest
istioctl experimental manifest migrate
-
The migrate subcommand is used to migrate a configuration in Helm values format to IstioControlPlane format.
-
istioctl experimental manifest migrate [flags]
+
The migrate subcommand migrates a configuration from Helm values format to IstioControlPlane format.
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1584,7 +1646,7 @@
istioctl experimental manifest m
istioctl experimental manifest versions
-
List the version of Istio recommended for and supported by this version of the operator binary.
+
List the versions of Istio recommended for and supported by this version of the operator binary.
istioctl experimental manifest versions [flags]
@@ -1619,7 +1681,7 @@
istioctl experimental manifest
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1639,7 +1701,7 @@
istioctl experimental manifest
--versionsURI <string>
-u
-
URI for operator versions to Istio versions map. (default `https://raw.githubusercontent.com/istio/operator/master/version/versions.yaml`)
+
URI for operator versions to Istio versions map (default `https://raw.githubusercontent.com/istio/operator/master/version/versions.yaml`)
@@ -1688,7 +1750,7 @@
istioctl experimental metrics
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -1707,7 +1769,7 @@
Examples
istioctl experimental profile
-
The profile subcommand is list, dump or diff Istio configuration profiles.
+
The profile subcommand lists, dumps or diffs Istio configuration profiles.
@@ -1740,7 +1802,7 @@
istioctl experimental profile
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1760,8 +1822,8 @@
istioctl experimental profile
istioctl experimental profile diff
-
The diff subcommand is used to display the difference between two Istio configuration profiles.
-
istioctl experimental profile diff [flags]
+
The diff subcommand displays the differences between two Istio configuration profiles.
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1815,8 +1877,8 @@
istioctl experimental profile diff
istioctl experimental profile dump
-
The dump subcommand is used to dump the values in an Istio configuration profile.
-
istioctl experimental profile dump [flags]
+
The dump subcommand dumps the values in an Istio configuration profile.
The path the root of the configuration subtree to dump e.g. trafficManagement.components.pilot. By default, dump whole tree. (default ``)
+
The path the root of the configuration subtree to dump e.g. trafficManagement.components.pilot. By default, dump whole tree (default ``)
--context <string>
@@ -1845,12 +1907,12 @@
istioctl experimental profile dump
--filename <string>
-f
-
Path to file containing IstioControlPlane CustomResource. (default ``)
+
Path to file containing IstioControlPlane CustomResource (default ``)
--helm-values
-
If set, dumps the Helm values that IstioControlPlaceSpec is translated to before manifests are rendered.
+
If set, dumps the Helm values that IstioControlPlaceSpec is translated to before manifests are rendered
--istioNamespace <string>
@@ -1865,7 +1927,7 @@
istioctl experimental profile dump
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1885,7 +1947,7 @@
istioctl experimental profile dump
istioctl experimental profile list
-
The list subcommand is used to list available Istio configuration profiles.
+
The list subcommand lists the available Istio configuration profiles.
istioctl experimental profile list [flags]
@@ -1920,7 +1982,7 @@
istioctl experimental profile list
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--logtostderr
@@ -1973,7 +2035,7 @@
istioctl experimental remove-fro
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2017,7 +2079,7 @@
istioctl experi
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2062,7 +2124,7 @@
istioctl experimental re
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2133,7 +2195,7 @@
istioctl kube-inject
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--meshConfigFile <string>
@@ -2214,7 +2276,7 @@
istioctl proxy-config
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2266,7 +2328,7 @@
istioctl proxy-config bootstrap
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2330,7 +2392,7 @@
istioctl proxy-config cluster
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2410,7 +2472,7 @@
istioctl proxy-config endpoint
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2490,7 +2552,7 @@
istioctl proxy-config listener
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2560,7 +2622,7 @@
istioctl proxy-config route
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--name <string>
@@ -2626,7 +2688,7 @@
istioctl proxy-status
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2684,7 +2746,7 @@
istioctl register
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2734,7 +2796,7 @@
istioctl validate
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2808,7 +2870,7 @@
istioctl verify-install
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
--namespace <string>
@@ -2865,7 +2927,7 @@
istioctl version
--log_output_level <string>
-
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, rbac, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
+
Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, attributes, authn, default, grpcAdapter, kube-converter, mcp, meshconfig, model, name, patch, processing, rbac, resource, runtime, source, tpath, translator, util, validation] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)
Number of errors (timeouts) initiating push context.
+
pilot_xds_push_time
Distribution
Total time in second Pilot takes to push lds, rds, cds and eds.
pilot_xds_pushes
Sum
Pilot build and send errors for lds, rds, cds and eds.
pilot_xds_rds_reject
LastValue
Pilot rejected RDS.
pilot_xds_write_timeout
Sum
Pilot XDS response write timeouts.
diff --git a/content/en/docs/reference/config/installation-options/index.md b/content/en/docs/reference/config/installation-options/index.md
index 79c83b27b965..9cc5804edd3e 100644
--- a/content/en/docs/reference/config/installation-options/index.md
+++ b/content/en/docs/reference/config/installation-options/index.md
@@ -172,8 +172,8 @@ To customize Istio install using Helm, use the `--set =` option in H
| Key | Default Value | Description |
| --- | --- | --- |
-| `global.hub` | `gcr.io/istio-release` | `Default hub for Istio images. Releases are published to docker hub under 'istio' project. Daily builds from prow are on gcr.io` |
-| `global.tag` | `release-1.3-latest-daily` | `Default tag for Istio images.` |
+| `global.hub` | `` | `Default hub for Istio images. Releases are published to docker hub under 'istio' project. Daily builds from prow are on gcr.io` |
+| `global.tag` | `` | `Default tag for Istio images.` |
| `global.logging.level` | `"default:info"` | |
| `global.monitoringPort` | `15014` | `monitoring port used by mixer, pilot, galley and sidecar injector` |
| `global.k8sIngress.enabled` | `false` | |
diff --git a/content/en/docs/reference/config/istio.operator.v1alpha12.pb/index.html b/content/en/docs/reference/config/istio.operator.v1alpha12.pb/index.html
new file mode 100644
index 000000000000..1072a74d2669
--- /dev/null
+++ b/content/en/docs/reference/config/istio.operator.v1alpha12.pb/index.html
@@ -0,0 +1,2285 @@
+---
+WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE 'https://github.com/istio/operator' REPO
+source_repo: https://github.com/istio/operator
+title: Operator Installation
+description: Configuration for Istio control plane installation through the Operator.
+location: https://istio.io/docs/reference/config/istio.operator.v1alpha12.pb.html
+layout: protoc-gen-docs
+generator: protoc-gen-docs
+number_of_entries: 52
+---
+
IstioControlPlane is a schema for both defining and customizing Istio control plane installations.
+Running the operator with an empty user defined InstallSpec results in an control plane with default values, using the
+default charts.
+
+
The simplest install specialization is to point the user InstallSpec profile to a different values file, for
+example an Istio minimal control plane, which will use the values associated with the minimal control plane profile for
+Istio.
+
+
Deeper customization is possible at three levels:
+
+
+
New APIs defined in this file
+
+
Feature API: this API groups an Istio install by features and allows enabling/disabling the features, selecting base
+control plane profiles, as well as some additional high level settings that are feature specific. Each feature contains
+one or more components, which correspond to Istio components (Pods) in the cluster.
+
+
k8s API: this API is a pass through to k8s resource settings for Istio k8s resources. It allows customizing Istio k8s
+resources like Affinity, Resource requests/limits, PodDisruptionBudgetSpec, Selectors etc. in a more consistent and
+k8s specific way compared to values.yaml. See KubernetesResourcesSpec in this file for details.
+
+
values.yaml
+
+
The entirety of values.yaml settings is accessible through InstallSpec (see CommonComponentSpec/Values).
+This API will gradually be deprecated and values there will be moved either into CRDs that are used to directly
+configure components or, in the case of k8s settings, will be replaced by the new API above.
+
+
k8s resource overlays
+
+
Once a manifest is rendered from InstallSpec, a further customization can be applied by specifying k8s resource
+overlays. The concept is similar to kustomize, where JSON patches are applied for object paths. This allows
+customization at the lowest level and eliminates the need to create ad-hoc template parameters, or edit templates.
Status reports the status of the Istio control plane.
+
+
+
+
+
+
+
IstioControlPlaneSpec
+
+
IstioControlPlaneSpec defines the desired state of IstioControlPlane.
+The spec is a used to define a customization of the default profile values that are supplied with each Istio release.
+It is grouped at the top level by feature, where behavior of Istio functional areas is specified.
+Each feature contains components, where k8s resource level defaults can be overridden.
+Because the spec is a customization API, specifying an empty InstallSpec results in a default Istio control plane.
+
+
+
+
+
Field
+
Type
+
Description
+
+
+
+
+
defaultNamespace
+
string
+
+
Default namespace if feature or component namespaces are not set.
Unvalidated overrides for default global values.yaml.
+
+
+
+
+
profile
+
string
+
+
Path or name for the profile e.g.
+ - minimal (looks in profiles dir for a file called minimal.yaml)
+ - /tmp/istio/install/values/custom/custom-install.yaml (local file path)
+default profile is used if this field is unset.
+
+
+
+
+
installPackagePath
+
string
+
+
Path for the install package. e.g.
+ - /tmp/istio-installer/nightly (local file path)
+
+
+
+
+
hub
+
string
+
+
Root for docker image paths e.g. docker.io/istio-release.
+Releases are published to docker hub under ‘istio’ project.
+Daily builds from prow are on gcr.io, and nightly builds from circle on docker.io/istionightly
+
+
+
+
+
tag
+
string
+
+
Version tag for docker images e.g. 1.0.6
+
+
+
+
+
+
+
KubernetesResourcesSpec
+
+
KubernetesResourcesConfig is a common set of k8s resource configs for components.
k8s pod annotations.
+https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
+
+
+
+
+
priorityClassName
+
string
+
+
k8s priorityclassname. Default for all resources unless overridden.
+https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass
scaleTargetRef points to the target resource to scale, and is used to the pods for which metrics
+should be collected, as well as to actually change the replica count.
+
+
+
+
+
minReplicas
+
int32
+
+
minReplicas is the lower limit for the number of replicas to which the autoscaler
+can scale down. It defaults to 1 pod. minReplicas is allowed to be 0 if the
+alpha feature gate HPAScaleToZero is enabled and at least one Object or External
+metric is configured. Scaling is active as long as at least one metric value is
+available.
++optional
+
+
+
+
+
maxReplicas
+
int32
+
+
maxReplicas is the upper limit for the number of replicas to which the autoscaler can scale up.
+It cannot be less that minReplicas.
metrics contains the specifications for which to use to calculate the
+desired replica count (the maximum replica count across all metrics will
+be used). The desired replica count is calculated multiplying the
+ratio between the target value and the current value by the current
+number of pods. Ergo, metrics used must decrease as the pod count is
+increased, and vice-versa. See the individual metric source types for
+more information about how each type of metric must respond.
++optional
Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod in the same node, zone, etc. as some other pod(s)).
++optional
+
+
+
+
+
+
+
k8s.io.api.core.v1.EnvVar
+
+
EnvVar represents an environment variable present in a Container.
+
+
+
+
+
Field
+
Type
+
Description
+
+
+
+
+
name
+
string
+
+
Name of the environment variable. Must be a C_IDENTIFIER.
+
+
+
+
+
value
+
string
+
+
Variable references $(VARNAME) are expanded
+using the previous defined environment variables in the container and
+any service environment variables. If a variable cannot be resolved,
+the reference in the input string will be unchanged. The $(VARNAME)
+syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped
+references will never be expanded, regardless of whether the variable
+exists or not.
+Defaults to “”.
++optional
The list of ports that are exposed by this service.
+More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
++patchMergeKey=port
++patchStrategy=merge
++listType=map
++listMapKey=port
++listMapKey=protocol
+
+
+
+
+
selector
+
map<string, string>
+
+
Route service traffic to pods with label keys and values matching this
+selector. If empty or not present, the service is assumed to have an
+external process managing its endpoints, which Kubernetes will not
+modify. Only applies to types ClusterIP, NodePort, and LoadBalancer.
+Ignored if type is ExternalName.
+More info: https://kubernetes.io/docs/concepts/services-networking/service/
++optional
+
+
+
+
+
clusterIP
+
string
+
+
clusterIP is the IP address of the service and is usually assigned
+randomly by the master. If an address is specified manually and is not in
+use by others, it will be allocated to the service; otherwise, creation
+of the service will fail. This field can not be changed through updates.
+Valid values are “None”, empty string (“”), or a valid IP address. “None”
+can be specified for headless services when proxying is not required.
+Only applies to types ClusterIP, NodePort, and LoadBalancer. Ignored if
+type is ExternalName.
+More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
++optional
+
+
+
+
+
type
+
string
+
+
type determines how the Service is exposed. Defaults to ClusterIP. Valid
+options are ExternalName, ClusterIP, NodePort, and LoadBalancer.
+“ExternalName” maps to the specified externalName.
+“ClusterIP” allocates a cluster-internal IP address for load-balancing to
+endpoints. Endpoints are determined by the selector or if that is not
+specified, by manual construction of an Endpoints object. If clusterIP is
+“None”, no virtual IP is allocated and the endpoints are published as a
+set of endpoints rather than a stable IP.
+“NodePort” builds on ClusterIP and allocates a port on every node which
+routes to the clusterIP.
+“LoadBalancer” builds on NodePort and creates an
+external load-balancer (if supported in the current cloud) which routes
+to the clusterIP.
+More info: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
++optional
+
+
+
+
+
externalIPs
+
string[]
+
+
externalIPs is a list of IP addresses for which nodes in the cluster
+will also accept traffic for this service. These IPs are not managed by
+Kubernetes. The user is responsible for ensuring that traffic arrives
+at a node with this IP. A common example is external load-balancers
+that are not part of the Kubernetes system.
++optional
+
+
+
+
+
sessionAffinity
+
string
+
+
Supports “ClientIP” and “None”. Used to maintain session affinity.
+Enable client IP based session affinity.
+Must be ClientIP or None.
+Defaults to None.
+More info: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
++optional
+
+
+
+
+
loadBalancerIP
+
string
+
+
Only applies to Service Type: LoadBalancer
+LoadBalancer will get created with the IP specified in this field.
+This feature depends on whether the underlying cloud-provider supports specifying
+the loadBalancerIP when a load balancer is created.
+This field will be ignored if the cloud-provider does not support the feature.
++optional
+
+
+
+
+
loadBalancerSourceRanges
+
string[]
+
+
If specified and supported by the platform, this will restrict traffic through the cloud-provider
+load-balancer will be restricted to the specified client IPs. This field will be ignored if the
+cloud-provider does not support the feature.”
+More info: https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/
++optional
+
+
+
+
+
externalName
+
string
+
+
externalName is the external reference that kubedns or equivalent will
+return as a CNAME record for this service. No proxying will be involved.
+Must be a valid RFC-1123 hostname (https://tools.ietf.org/html/rfc1123)
+and requires Type to be ExternalName.
++optional
+
+
+
+
+
externalTrafficPolicy
+
string
+
+
externalTrafficPolicy denotes if this Service desires to route external
+traffic to node-local or cluster-wide endpoints. “Local” preserves the
+client source IP and avoids a second hop for LoadBalancer and Nodeport
+type services, but risks potentially imbalanced traffic spreading.
+“Cluster” obscures the client source IP and may cause a second hop to
+another node, but should have good overall load-spreading.
++optional
+
+
+
+
+
healthCheckNodePort
+
int32
+
+
healthCheckNodePort specifies the healthcheck nodePort for the service.
+If not specified, HealthCheckNodePort is created by the service api
+backend with the allocated nodePort. Will use user-specified nodePort value
+if specified by the client. Only effects when Type is set to LoadBalancer
+and ExternalTrafficPolicy is set to Local.
++optional
+
+
+
+
+
publishNotReadyAddresses
+
bool
+
+
publishNotReadyAddresses, when set to true, indicates that DNS implementations
+must publish the notReadyAddresses of subsets for the Endpoints associated with
+the Service. The default value is false.
+The primary use case for setting this field is to use a StatefulSet’s Headless Service
+to propagate SRV records for its Pods without respect to their readiness for purpose
+of peer discovery.
++optional
sessionAffinityConfig contains the configurations of session affinity.
++optional
+
+
+
+
+
ipFamily
+
string
+
+
ipFamily specifies whether this Service has a preference for a particular IP family (e.g. IPv4 vs.
+IPv6). If a specific IP family is requested, the clusterIP field will be allocated from that family, if it is
+available in the cluster. If no IP family is requested, the cluster’s primary IP family will be used.
+Other IP fields (loadBalancerIP, loadBalancerSourceRanges, externalIPs) and controllers which
+allocate external load-balancers should use the same IP family. Endpoints for this Service will be of
+this family. This field is immutable after creation. Assigning a ServiceIPFamily not available in the
+cluster (e.g. IPv6 in IPv4 only cluster) is an error condition and will fail during clusterIP assignment.
++optional
+
+
+
+
+
+
+
k8s.io.api.core.v1.Toleration
+
+
The pod this Toleration is attached to tolerates any taint that matches
+the triple <key,value,effect> using the matching operator <operator>.
+
+
+
+
+
Field
+
Type
+
Description
+
+
+
+
+
key
+
string
+
+
Key is the taint key that the toleration applies to. Empty means match all taint keys.
+If the key is empty, operator must be Exists; this combination means to match all values and all keys.
++optional
+
+
+
+
+
operator
+
string
+
+
Operator represents a key’s relationship to the value.
+Valid operators are Exists and Equal. Defaults to Equal.
+Exists is equivalent to wildcard for value, so that a pod can
+tolerate all taints of a particular category.
++optional
+
+
+
+
+
value
+
string
+
+
Value is the taint value the toleration matches to.
+If the operator is Exists, the value should be empty, otherwise just a regular string.
++optional
+
+
+
+
+
effect
+
string
+
+
Effect indicates the taint effect to match. Empty means match all taint effects.
+When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute.
++optional
+
+
+
+
+
tolerationSeconds
+
int64
+
+
TolerationSeconds represents the period of time the toleration (which must be
+of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default,
+it is not set, which means tolerate the taint forever (do not evict). Zero and
+negative values will be treated as 0 (evict immediately) by the system.
++optional
A label selector is a label query over a set of resources. The result of matchLabels and
+matchExpressions are ANDed. An empty label selector matches all objects. A null
+label selector matches no objects.
+
+
+
+
+
Field
+
Type
+
Description
+
+
+
+
+
matchLabels
+
map<string, string>
+
+
matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels
+map is equivalent to an element of matchExpressions, whose key field is “key”, the
+operator is “In”, and the values array contains only “value”. The requirements are ANDed.
++optional
Path of the form a.b:c.e.:f
+Where b:c is a list element selector of the form key:value and :f is a list selector of the form :value.
+All path intermediate nodes must exist.
Value to add, delete or replace.
+For add, the path should be a new leaf.
+For delete, value should be unset.
+For replace, path should reference an existing node.
+All values are strings but are converted into appropriate type based on schema.
Specifies the conditions under which retry takes place.
One or more policies can be specified using a ‘,’ delimited list.
-See the supported policies
-and here for more details.
The log level (one of error, warn, info, debug, or none). Ex: info
+
diff --git a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/adapters.svg b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/adapters.svg
index 17e3d06a6784..52a2a1a4b1c7 100644
--- a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/adapters.svg
+++ b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/adapters.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg
index c9c695ece261..aa0dce96d1fc 100644
--- a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg
+++ b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-with-cache.svg b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-with-cache.svg
index e03b14a49a31..12b94bde9553 100644
--- a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-with-cache.svg
+++ b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-with-cache.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-without-cache.svg b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-without-cache.svg
index 9d616120e4c0..081f317e962a 100644
--- a/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-without-cache.svg
+++ b/content/en/docs/reference/config/policy-and-telemetry/mixer-overview/topology-without-cache.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/reference/glossary/crds.md b/content/en/docs/reference/glossary/crds.md
new file mode 100644
index 000000000000..26978a3257c4
--- /dev/null
+++ b/content/en/docs/reference/glossary/crds.md
@@ -0,0 +1,7 @@
+---
+title: CRDs
+---
+
+[Custom resource definitions (CRDs)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+are extensions of the default Kubernetes API. Istio uses the Kubernetes CRD API for
+configuration, even for non-Kubernetes Istio deployments.
diff --git a/content/en/docs/reference/glossary/data-plane.md b/content/en/docs/reference/glossary/data-plane.md
new file mode 100644
index 000000000000..92b3cbc83862
--- /dev/null
+++ b/content/en/docs/reference/glossary/data-plane.md
@@ -0,0 +1,7 @@
+---
+title: Data Plane
+---
+
+The data plane is the part of the mesh that directly controls communication between workload instances.
+Istio's data plane uses intelligent [Envoy](#envoy) proxies deployed as sidecars to mediate and control all
+traffic that your mesh services send and receive.
diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md
index b938dfda00ac..ae2e2af2e4ef 100644
--- a/content/en/docs/reference/glossary/pod.md
+++ b/content/en/docs/reference/glossary/pod.md
@@ -1,4 +1,7 @@
---
title: Pod
---
-A Pod is a group of one or more containers (such as [Docker](https://www.docker.com/) containers), with shared storage/network, and a specification for how to run the containers. A pod is the smallest deployable unit of computing in [Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/).
+A Pod is a group of one or more containers (such as [Docker](https://www.docker.com/) containers),
+with shared storage and network, and a specification for how to run the containers.
+Pods are the [workload instances](#workload-instance) in a
+[Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) deployment of Istio.
diff --git a/content/en/docs/reference/glossary/routing-rules.md b/content/en/docs/reference/glossary/routing-rules.md
index ea1927799414..97b0e79bad69 100644
--- a/content/en/docs/reference/glossary/routing-rules.md
+++ b/content/en/docs/reference/glossary/routing-rules.md
@@ -5,5 +5,5 @@ Routing rules, which you configure in a virtual service, define the paths that
requests follow within the service mesh. With routing rules, you can define
conditions to route traffic addressed to the virtual service's host to specific
destination workloads. Routing rules let you set up complex
-[traffic routing](/docs/concepts/traffic-management/#traffic-routing-and-configuration)
+[traffic routing](/docs/concepts/traffic-management/#virtual-services)
scenarios.
diff --git a/content/en/docs/reference/glossary/service-version.md b/content/en/docs/reference/glossary/service-version.md
index 236535d7e840..a72ac5b16ba3 100644
--- a/content/en/docs/reference/glossary/service-version.md
+++ b/content/en/docs/reference/glossary/service-version.md
@@ -2,5 +2,4 @@
title: Service Version
---
Distinct variants of a [service](#service), typically backed by different versions of a [workload](#workload) binary.
-Common scenarios where multiple [service versions](#service-version) may be used include A/B testing, canary rollouts, etc.
-Each service has a default version.
+Common scenarios where multiple service versions may be used include A/B testing, canary rollouts, etc.
diff --git a/content/en/docs/reference/glossary/virtual-service.md b/content/en/docs/reference/glossary/virtual-service.md
index 6a6b1fb79e6f..f61709246a6b 100644
--- a/content/en/docs/reference/glossary/virtual-service.md
+++ b/content/en/docs/reference/glossary/virtual-service.md
@@ -4,5 +4,5 @@ title: Virtual Service
A virtual service is a resource you can use to configure how Envoy proxies route
requests to a service within an Istio service mesh. The routing rules that you
define in a virtual service let you set up complex
-[traffic routing](/docs/concepts/traffic-management/#traffic-routing-and-configuration)
+[traffic routing](/docs/concepts/traffic-management/#virtual-services)
scenarios.
diff --git a/content/en/docs/reference/glossary/workload-instance.md b/content/en/docs/reference/glossary/workload-instance.md
index b8e207607108..48c1acda6f70 100644
--- a/content/en/docs/reference/glossary/workload-instance.md
+++ b/content/en/docs/reference/glossary/workload-instance.md
@@ -1,7 +1,7 @@
---
title: Workload Instance
---
-A single instantiation of a workload's binary.
+A single instantiation of a [workload's](#workload) binary.
A workload instance can expose zero or more [service endpoints](#service-endpoint),
and can consume zero or more [services](#service).
diff --git a/content/en/docs/reference/glossary/workload.md b/content/en/docs/reference/glossary/workload.md
index 463bb4944a8d..9b69a15b280a 100644
--- a/content/en/docs/reference/glossary/workload.md
+++ b/content/en/docs/reference/glossary/workload.md
@@ -7,5 +7,6 @@ using the following [attributes](#attribute):
* `source.workload.name`, `source.workload.namespace`, `source.workload.uid`
* `destination.workload.name`, `destination.workload.namespace`, `destination.workload.uid`
-In Kubernetes, a workload typically corresponds to a Kubernetes deployment, while a workload instance corresponds to an individual pod managed
+In Kubernetes, a workload typically corresponds to a Kubernetes deployment,
+while a [workload instance](#workload-instance) corresponds to an individual pod managed
by the deployment.
diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md
index 2ade3dbc1d3b..29ed88f4d12d 100644
--- a/content/en/docs/setup/_index.md
+++ b/content/en/docs/setup/_index.md
@@ -32,8 +32,7 @@ At a high level, the basic flow is the same regardless of platform:
## Downloading the release
-Istio is installed in its own `istio-system` namespace and can manage
-services from all other namespaces.
+Download the Istio release which includes installation files, samples and a command line utility.
1. Go to the [Istio release]({{< istio_release_url >}}) page to
download the installation file corresponding to your OS. On a macOS or
@@ -55,7 +54,7 @@ services from all other namespaces.
- Installation YAML files for Kubernetes in `install/kubernetes`
- Sample applications in `samples/`
- - The [`istioctl`]((/docs/reference/commands/istioctl) client binary in the `bin/` directory. `istioctl` is
+ - The [`istioctl`](/docs/reference/commands/istioctl) client binary in the `bin/` directory. `istioctl` is
used when manually injecting Envoy as a sidecar proxy.
1. Add the `istioctl` client to your path, on a macOS or
@@ -69,7 +68,8 @@ services from all other namespaces.
## Installing Istio
-Choose one of the following installation options, depending on your intended use:
+Istio is installed in its own `istio-system` namespace and can manage
+services from all other namespaces. Choose one of the following installation options, depending on your intended use:
- [Demo installation](/docs/setup/install/kubernetes/):
This option is ideal if you're new to Istio and just want to try it out.
diff --git a/content/en/docs/setup/additional-setup/config-profiles/index.md b/content/en/docs/setup/additional-setup/config-profiles/index.md
index a75b4b57cec8..bc98089b31f8 100644
--- a/content/en/docs/setup/additional-setup/config-profiles/index.md
+++ b/content/en/docs/setup/additional-setup/config-profiles/index.md
@@ -73,10 +73,10 @@ Istio provides two additional built-in configuration profiles that are used excl
[multi-cluster deployment](/docs/concepts/deployment-models/#multiple-clusters):
1. **remote**: used for configuring remote clusters of a
- multicluster mesh with a suitable [control plane model](/docs/concepts/deployment-models/#control-plane-models).
+ multicluster mesh with a shared [control plane](/docs/concepts/deployment-models/#control-plane-models).
-1. **multicluster-gateways**: used for configuring all of the clusters of a
- multicluster mesh with a suitable [control plane model](/docs/concepts/deployment-models/#control-plane-models).
+1. **multicluster-gateways**: used for configuring clusters of a
+ multicluster mesh with replicated [control planes](/docs/concepts/deployment-models/#control-plane-models).
The **remote** profile is configured using the values file `values-istio-remote.yaml`. This profile installs only two
Istio core components:
diff --git a/content/en/docs/setup/additional-setup/requirements/index.md b/content/en/docs/setup/additional-setup/requirements/index.md
index 65ac872c421d..813578075bb1 100644
--- a/content/en/docs/setup/additional-setup/requirements/index.md
+++ b/content/en/docs/setup/additional-setup/requirements/index.md
@@ -13,6 +13,28 @@ keywords: [kubernetes,sidecar,sidecar-injection]
To be a part of an Istio service mesh, pods and services in a Kubernetes
cluster must satisfy the following requirements:
+- **Named service ports**: Service ports must be named. The port name key/value
+ pairs must have the following syntax: `name: [-]`. To take
+ advantage of Istio's routing features, replace `` with one of the
+ following values:
+
+ - `grpc`
+ - `http`
+ - `http2`
+ - `https`
+ - `mongo`
+ - `mysql`
+ - `redis`
+ - `tcp`
+ - `tls`
+ - `udp`
+
+ For example, `name: http2-foo` or `name: http` are valid port names, but
+ `name: http2foo` is not. If the port name does not begin with a recognized
+ prefix or if the port is unnamed, outbound HTTP or TCP traffic will be automatically detected. Inbound traffic on the port is treated as
+ plain TCP traffic unless the port [explicitly](https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service)
+ uses `Protocol: UDP` to signify a UDP port.
+
- **Service association**: A pod must belong to at least one Kubernetes
service even if the pod does NOT expose any port.
If a pod belongs to multiple [Kubernetes services](https://kubernetes.io/docs/concepts/services-networking/service/),
diff --git a/content/en/docs/setup/install/helm/index.md b/content/en/docs/setup/install/helm/index.md
index 712ad5948708..3e31ab24a95f 100644
--- a/content/en/docs/setup/install/helm/index.md
+++ b/content/en/docs/setup/install/helm/index.md
@@ -358,6 +358,7 @@ $ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=k
$ helm delete --purge istio
$ helm delete --purge istio-init
$ helm delete --purge istio-cni
+ $ kubectl delete namespace istio-system
{{< /text >}}
## Deleting CRDs and Istio Configuration
diff --git a/content/en/docs/setup/install/kubernetes/index.md b/content/en/docs/setup/install/kubernetes/index.md
index b1f8d37bcf12..b3480ddaa251 100644
--- a/content/en/docs/setup/install/kubernetes/index.md
+++ b/content/en/docs/setup/install/kubernetes/index.md
@@ -29,13 +29,6 @@ requirements.
1. [Download the Istio release](/docs/setup/#downloading-the-release).
- {{< warning >}}
- These quick-start instructions will not work with a downloaded [istio repository](https://github.com/istio/istio)
- because the pregenerated yaml files, `istio-demo.yaml` and `istio-demo-auth.yaml`, are only available in
- [release images](https://github.com/istio/istio/releases). If you want to work with the latest Istio codebase,
- refer to the [developer wiki](https://github.com/istio/istio/wiki) for instructions.
- {{< /warning >}}
-
1. Perform any necessary [platform-specific setup](/docs/setup/platform-setup/).
1. Check the [Requirements for Pods and Services](/docs/setup/additional-setup/requirements/).
diff --git a/content/en/docs/setup/install/multicluster/gateways/index.md b/content/en/docs/setup/install/multicluster/gateways/index.md
index ef016f1b6183..5ca7e0ba5a89 100644
--- a/content/en/docs/setup/install/multicluster/gateways/index.md
+++ b/content/en/docs/setup/install/multicluster/gateways/index.md
@@ -264,13 +264,15 @@ running in a second cluster. Before you begin:
{{< /tip >}}
If the global services have actual VIPs, you can use those, but otherwise we suggest
- using IPs from the loopback range `127.0.0.0/8` that are not already allocated.
- These IPs are non-routable outside of a pod.
- In this example we'll use IPs in `127.255.0.0/16` which avoids conflicting with
- well known IPs such as `127.0.0.1` (`localhost`).
+ using IPs from the class E addresses range `240.0.0.0/4`.
Application traffic for these IPs will be captured by the sidecar and routed to the
appropriate remote service.
+ {{< warning >}}
+ Multicast addresses (224.0.0.0 ~ 239.255.255.255) should not be used because there is no route to them by default.
+ Loopback addresses (127.0.0.0/8) should also not be used because traffic sent to them may be redirected to the sidecar inbound listener.
+ {{< /warning >}}
+
{{< text bash >}}
$ kubectl apply --context=$CTX_CLUSTER1 -n foo -f - <
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/setup/install/multicluster/shared-gateways/diagram.svg b/content/en/docs/setup/install/multicluster/shared-gateways/diagram.svg
index bc62d8051b07..8c61645949b5 100644
--- a/content/en/docs/setup/install/multicluster/shared-gateways/diagram.svg
+++ b/content/en/docs/setup/install/multicluster/shared-gateways/diagram.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/setup/install/multicluster/shared-gateways/index.md b/content/en/docs/setup/install/multicluster/shared-gateways/index.md
index 295bc0e9c70a..c5c1440227af 100644
--- a/content/en/docs/setup/install/multicluster/shared-gateways/index.md
+++ b/content/en/docs/setup/install/multicluster/shared-gateways/index.md
@@ -1,6 +1,6 @@
---
title: Shared control plane (multi-network)
-description: Install an Istio mesh across multiple Kubernetes clusters using a shared control plane for diconnected cluster networks.
+description: Install an Istio mesh across multiple Kubernetes clusters using a shared control plane for disconnected cluster networks.
weight: 85
keywords: [kubernetes,multi-cluster]
aliases:
diff --git a/content/en/docs/setup/install/multicluster/shared-vpn/multicluster-with-vpn.svg b/content/en/docs/setup/install/multicluster/shared-vpn/multicluster-with-vpn.svg
index 8be9b4a44841..2b50b6f0227d 100644
--- a/content/en/docs/setup/install/multicluster/shared-vpn/multicluster-with-vpn.svg
+++ b/content/en/docs/setup/install/multicluster/shared-vpn/multicluster-with-vpn.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/setup/install/operator/index.md b/content/en/docs/setup/install/operator/index.md
index afe0a605b981..198cd7be2ec0 100644
--- a/content/en/docs/setup/install/operator/index.md
+++ b/content/en/docs/setup/install/operator/index.md
@@ -305,6 +305,14 @@ and displays the results:
$ istioctl verify-install -f $HOME/generated-manifest.yaml
{{< /text >}}
+## Uninstall Istio
+
+To uninstall Istio, run the following command:
+
+{{< text bash >}}
+$ istioctl experimental manifest generate | kubectl delete -f -
+{{< /text >}}
+
## Additional documentation
The Istio Operator CLI is experimental. See the upstream repository [README](https://github.com/istio/operator/blob/master/README.md)
diff --git a/content/en/docs/setup/platform-setup/MicroK8s/index.md b/content/en/docs/setup/platform-setup/MicroK8s/index.md
index 2767f664ce39..3c0b57bc0c54 100644
--- a/content/en/docs/setup/platform-setup/MicroK8s/index.md
+++ b/content/en/docs/setup/platform-setup/MicroK8s/index.md
@@ -15,7 +15,7 @@ Follow these instructions to prepare MicroK8s for using Istio.
Administrative privileges are required to run MicroK8s.
{{< /warning >}}
-1. Install the latest version of [MicroK8s](https://microK8s.io) using the command
+1. Install the latest version of [MicroK8s](https://microk8s.io) using the command
{{< text bash >}}
$ sudo snap install microk8s --classic
diff --git a/content/en/docs/setup/platform-setup/gardener/index.md b/content/en/docs/setup/platform-setup/gardener/index.md
index a0fe148370d6..91e01d86c43d 100644
--- a/content/en/docs/setup/platform-setup/gardener/index.md
+++ b/content/en/docs/setup/platform-setup/gardener/index.md
@@ -43,7 +43,7 @@ project. To learn more about this open source project, read the
You can create your cluster using `kubectl` cli by providing a cluster
specification yaml file. You can find an example for GCP
-[here](https://github.com/gardener/gardener/blob/master/example/90-shoot-gcp.yaml).
+[here](https://github.com/gardener/gardener/blob/master/example/90-shoot.yaml).
Make sure the namespace matches that of your project. Then just apply the
prepared so-called "shoot" cluster CRD with `kubectl`:
diff --git a/content/en/docs/setup/upgrade/notice/index.md b/content/en/docs/setup/upgrade/notice/index.md
index af03e196ff2a..06537b440cc5 100644
--- a/content/en/docs/setup/upgrade/notice/index.md
+++ b/content/en/docs/setup/upgrade/notice/index.md
@@ -12,8 +12,8 @@ compatibility. We also mention cases where backwards compatibility was
preserved but new behavior was introduced that would be surprising to someone
familiar with the use and operation of Istio 1.2.
-For an overview of new features introduced with Istio 1.2, please refer
-to the [1.3 release notes](/about/notes/1.3/).
+For an overview of new features introduced with Istio 1.3, please refer
+to the [1.3 release notes](/news/2019/announcing-1.3/).
## Installation and upgrade
@@ -31,11 +31,6 @@ Istio now captures all ports by default. If you don't specify container ports
to intentionally bypass Envoy, you must opt out of port capturing with the
`traffic.sidecar.istio.io/excludeInboundPorts` option.
-{{< warning >}}
-This change exposes any applications listening on `127.0.0.1` since Envoy
-connects over `localhost`. Opt out to avoid exposing such applications.
-{{< /warning >}}
-
Protocol sniffing is now enabled by default. Disable protocol sniffing with the
`--set pilot.enableProtocolSniffing=false` option when you upgrade to get the
previous behavior. To learn more see our [protocol selection page](/docs/ops/traffic-management/protocol-selection/).
diff --git a/content/en/docs/tasks/security/auth-sds/index.md b/content/en/docs/tasks/security/auth-sds/index.md
index 31297f5b67ab..feb043af2060 100644
--- a/content/en/docs/tasks/security/auth-sds/index.md
+++ b/content/en/docs/tasks/security/auth-sds/index.md
@@ -86,16 +86,16 @@ $ kubectl exec -it $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..me
As you can see there is no secret file mounted at `/etc/certs` folder.
-## Increasing security with pod security policies
+## Securing SDS with pod security policies
The Istio Secret Discovery Service (SDS) uses the Citadel agent to distribute the certificate to the
Envoy sidecar via a Unix domain socket. All pods running in the same Kubernetes node share the Citadel
agent and Unix domain socket.
-To prevent malicious modifications to the Unix domain socket, enable the [pod security policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
-to restrict the pod's permission on the Unix domain socket. Otherwise, a malicious pod could hijack the
-Unix domain socket to break the SDS service or steal the identity credentials from other pods running
-on the same Kubernetes node.
+To prevent unexpected modifications to the Unix domain socket, enable the [pod security policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
+to restrict the pod's permission on the Unix domain socket. Otherwise, a malicious user who has the
+permission to modify the deployment could hijack the Unix domain socket to break the SDS service or
+steal the identity credentials from other pods running on the same Kubernetes node.
To enable the pod security policy, perform the following steps:
diff --git a/content/en/docs/tasks/security/mutual-tls/index.md b/content/en/docs/tasks/security/mutual-tls/index.md
index b2fcfe22f696..aadeb127169b 100644
--- a/content/en/docs/tasks/security/mutual-tls/index.md
+++ b/content/en/docs/tasks/security/mutual-tls/index.md
@@ -69,7 +69,7 @@ Please check [Istio identity](/docs/concepts/security/#istio-identity) for more
## Verify mutual TLS configuration
-Use [`istioctl auhtn tls-check`](/docs/reference/commands/istioctl/#istioctl-authn-tls-check) to check if the mutual TLS settings are in effect. The `istioctl` command needs the client's pod because the destination rule depends on the client's namespace.
+Use [`istioctl authn tls-check`](/docs/reference/commands/istioctl/#istioctl-authn-tls-check) to check if the mutual TLS settings are in effect. The `istioctl` command needs the client's pod because the destination rule depends on the client's namespace.
You can also provide the destination service to filter the status to that service only.
{{< tip >}}
diff --git a/content/en/docs/tasks/telemetry/metrics/tcp-metrics/istio-tcp-attribute-flow.svg b/content/en/docs/tasks/telemetry/metrics/tcp-metrics/istio-tcp-attribute-flow.svg
index 2620a3c97021..1a82b3026585 100644
--- a/content/en/docs/tasks/telemetry/metrics/tcp-metrics/istio-tcp-attribute-flow.svg
+++ b/content/en/docs/tasks/telemetry/metrics/tcp-metrics/istio-tcp-attribute-flow.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/tasks/traffic-management/circuit-breaking/index.md b/content/en/docs/tasks/traffic-management/circuit-breaking/index.md
index 2eb017c6ed34..553bec341263 100644
--- a/content/en/docs/tasks/traffic-management/circuit-breaking/index.md
+++ b/content/en/docs/tasks/traffic-management/circuit-breaking/index.md
@@ -230,7 +230,7 @@ one connection and request concurrently, you should see some failures when the
1. Query the `istio-proxy` stats to see more:
{{< text bash >}}
- $ kubectl exec -it $FORTIO_POD -c istio-proxy -- sh -c 'curl localhost:15000/stats' | grep httpbin | grep pending
+ $ kubectl exec $FORTIO_POD -c istio-proxy -- pilot-agent request GET stats | grep httpbin | grep pending
cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_failure_eject: 0
cluster.outbound|80||httpbin.springistio.svc.cluster.local.upstream_rq_pending_overflow: 12
diff --git a/content/en/docs/tasks/traffic-management/egress/egress-control/index.md b/content/en/docs/tasks/traffic-management/egress/egress-control/index.md
index 4d7efb06fd64..6671eb87bba1 100644
--- a/content/en/docs/tasks/traffic-management/egress/egress-control/index.md
+++ b/content/en/docs/tasks/traffic-management/egress/egress-control/index.md
@@ -254,7 +254,7 @@ any other unintentional accesses.
### Manage traffic to external services
Similar to inter-cluster requests, Istio
-[routing rules](/docs/concepts/traffic-management/#routing-rules)
+[routing rules](/docs/concepts/traffic-management/)
can also be set for external services that are accessed using `ServiceEntry` configurations.
In this example, you set a timeout rule on calls to the `httpbin.org` service.
@@ -319,7 +319,7 @@ $ kubectl delete virtualservice httpbin-ext --ignore-not-found=true
If you want to completely bypass Istio for a specific IP range,
you can configure the Envoy sidecars to prevent them from
-[intercepting](/docs/concepts/traffic-management/#traffic-routing-and-configuration)
+[intercepting](/docs/concepts/traffic-management/)
external requests. To set up the bypass, change either the `global.proxy.includeIPRanges`
or the `global.proxy.excludeIPRanges` [configuration option](/docs/reference/config/installation-options/) and
update the `istio-sidecar-injector` configuration map using the `kubectl apply` command.
diff --git a/content/en/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md b/content/en/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md
index 8a89f0c0275e..f87c036c285d 100644
--- a/content/en/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md
+++ b/content/en/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md
@@ -45,6 +45,8 @@ traffic to external services.
* [Deploy Istio egress gateway](/docs/tasks/traffic-management/egress/egress-gateway/#deploy-istio-egress-gateway).
+* [Enable Envoy’s access logging](/docs/tasks/telemetry/logs/access-log/#enable-envoy-s-access-logging)
+
## Perform TLS origination with an egress gateway
This section describes how to perform the same TLS origination as in the
diff --git a/content/en/docs/tasks/traffic-management/egress/egress-gateway/index.md b/content/en/docs/tasks/traffic-management/egress/egress-gateway/index.md
index c4b0f98aac69..b19be9818a4a 100644
--- a/content/en/docs/tasks/traffic-management/egress/egress-gateway/index.md
+++ b/content/en/docs/tasks/traffic-management/egress/egress-gateway/index.md
@@ -37,6 +37,8 @@ controlled way.
{{< boilerplate before-you-begin-egress >}}
+* [Enable Envoy’s access logging](/docs/tasks/telemetry/logs/access-log/#enable-envoy-s-access-logging)
+
## Deploy Istio egress gateway
1. Check if the Istio egress gateway is deployed:
@@ -310,7 +312,7 @@ You need to specify port 443 with protocol `TLS` in a corresponding `ServiceEntr
EOF
{{< /text >}}
-1. Verify that your `ServiceEntry` was applied correctly by sending an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
+1. Verify that your `ServiceEntry` was applied correctly by sending an HTTPS request to [https://edition.cnn.com/politics](https://edition.cnn.com/politics).
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics
@@ -482,7 +484,7 @@ You need to specify port 443 with protocol `TLS` in a corresponding `ServiceEntr
{{< /tabset >}}
-1. Send an HTTPS request to [http://edition.cnn.com/politics](https://edition.cnn.com/politics).
+1. Send an HTTPS request to [https://edition.cnn.com/politics](https://edition.cnn.com/politics).
The output should be the same as before.
{{< text bash >}}
@@ -725,7 +727,7 @@ external service.
counter is:
{{< text bash >}}
- $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- curl -s localhost:15000/stats | grep edition.cnn.com.upstream_cx_total
+ $ kubectl exec $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET stats | grep edition.cnn.com.upstream_cx_total
cluster.outbound|443||edition.cnn.com.upstream_cx_total: 2
{{< /text >}}
@@ -781,7 +783,7 @@ external service.
If you get the certificate as in the output above, your traffic is routed correctly. Check the statistics of the egress gateway's proxy and see a counter that corresponds to your requests (sent by _openssl_ and _curl_) to _edition.cnn.com_.
{{< text bash >}}
- $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- curl -s localhost:15000/stats | grep edition.cnn.com.upstream_cx_total
+ $ kubectl exec $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET stats | grep edition.cnn.com.upstream_cx_total
cluster.outbound|443||edition.cnn.com.upstream_cx_total: 2
{{< /text >}}
diff --git a/content/en/docs/tasks/traffic-management/egress/egress-tls-origination/index.md b/content/en/docs/tasks/traffic-management/egress/egress-tls-origination/index.md
index cb49839b9923..4773a7cb933e 100644
--- a/content/en/docs/tasks/traffic-management/egress/egress-tls-origination/index.md
+++ b/content/en/docs/tasks/traffic-management/egress/egress-tls-origination/index.md
@@ -151,8 +151,8 @@ Both of these issues can be resolved by configuring Istio to perform TLS origina
name: http-port
protocol: HTTP
- number: 443
- name: http-port-for-tls-origination
- protocol: HTTP
+ name: https-port-for-tls-origination
+ protocol: HTTPS
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
diff --git a/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md b/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md
index 039ee258c55e..8f891252d726 100644
--- a/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md
+++ b/content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md
@@ -15,6 +15,8 @@ example extends that example to show how to configure SNI monitoring and apply p
* [Deploy Istio egress gateway](/docs/tasks/traffic-management/egress/egress-gateway/#deploy-istio-egress-gateway).
+* [Enable Envoy’s access logging](/docs/tasks/telemetry/logs/access-log/#enable-envoy-s-access-logging)
+
* Configure traffic to `*.wikipedia.org` by following
[the steps](/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#wildcard-configuration-for-arbitrary-domains) in
[Configure Egress Traffic using Wildcard Hosts](/docs/tasks/traffic-management/egress/wildcard-egress-hosts/) example,
diff --git a/content/en/docs/tasks/traffic-management/egress/http-proxy/index.md b/content/en/docs/tasks/traffic-management/egress/http-proxy/index.md
index ec8cc3b81c77..2e5b4d56b0ef 100644
--- a/content/en/docs/tasks/traffic-management/egress/http-proxy/index.md
+++ b/content/en/docs/tasks/traffic-management/egress/http-proxy/index.md
@@ -18,6 +18,8 @@ services.
{{< boilerplate before-you-begin-egress >}}
+* [Enable Envoy’s access logging](/docs/tasks/telemetry/logs/access-log/#enable-envoy-s-access-logging)
+
## Deploy an HTTPS proxy
To simulate a legacy proxy and only for this example, you deploy an HTTPS proxy inside your cluster.
diff --git a/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/EgressGatewayWithSNIProxy.svg b/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/EgressGatewayWithSNIProxy.svg
index 6b15b5d7b15d..9099c6a40095 100644
--- a/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/EgressGatewayWithSNIProxy.svg
+++ b/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/EgressGatewayWithSNIProxy.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md b/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md
index 50f18cc12d57..077c6340c4b4 100644
--- a/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md
+++ b/content/en/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md
@@ -25,6 +25,8 @@ without the need to specify every language's site separately.
* [Deploy Istio egress gateway](/docs/tasks/traffic-management/egress/egress-gateway/#deploy-istio-egress-gateway).
+* [Enable Envoy’s access logging](/docs/tasks/telemetry/logs/access-log/#enable-envoy-s-access-logging)
+
## Configure direct traffic to a wildcard host
The first, and simplest, way to access a set of hosts within a common domain is by configuring
@@ -208,7 +210,7 @@ the set of domains.
counter is:
{{< text bash >}}
- $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- curl -s localhost:15000/clusters | grep '^outbound|443||www.wikipedia.org.*cx_total:'
+ $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET clusters | grep '^outbound|443||www.wikipedia.org.*cx_total:'
outbound|443||www.wikipedia.org::208.80.154.224:443::cx_total::2
{{< /text >}}
diff --git a/content/en/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md b/content/en/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md
index ea5d05353b38..402b5f25b0b9 100644
--- a/content/en/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md
+++ b/content/en/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md
@@ -31,6 +31,15 @@ $ helm template $HOME/istio-fetch/istio \
By default `istio-ingressgateway` will be exposed as a `LoadBalancer` service type. You may want to change that by setting the `gateways.istio-ingressgateway.type` installation option to `NodePort` if this is more applicable to your Kubernetes environment.
{{< /tip >}}
+{{< tip >}}
+If you're editing the `values.yml` file, don't enable
+{{}}
+sds:
+ enabled: false
+{{}}
+This will enable mutual TLS between pods which will cause pods to become unhealthy if you don't have mutual TLS configured.
+{{< /tip >}}
+
## Configuring DNS name and gateway
Take a note of the external IP address of the `istio-ingressgateway` service:
diff --git a/content/en/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md b/content/en/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md
index b4a5ab78d2b8..a7340702009a 100644
--- a/content/en/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md
+++ b/content/en/docs/tasks/traffic-management/ingress/secure-ingress-mount/index.md
@@ -521,7 +521,7 @@ only this time for host `bookinfo.com` instead of `httpbin.example.com`.
* Verify that the proxy of the ingress gateway is aware of the certificates:
{{< text bash >}}
- $ kubectl exec -ti $(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -n istio-system -- curl 127.0.0.1:15000/certs
+ $ kubectl exec -ti $(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -n istio-system -- pilot-agent request GET certs
{
"ca_cert": "",
"cert_chain": "Certificate Path: /etc/istio/ingressgateway-certs/tls.crt, Serial Number: 100212, Days until Expiration: 370"
diff --git a/content/en/faq/general/roadmap.md b/content/en/faq/general/roadmap.md
index d4cee708d505..562557a2dd32 100644
--- a/content/en/faq/general/roadmap.md
+++ b/content/en/faq/general/roadmap.md
@@ -4,4 +4,4 @@ weight: 140
---
See our [feature stages page](/about/feature-stages/)
-and [release notes](/about/notes) for more details.
+and [news](/news) for latest happenings.
diff --git a/content/en/news/2017/_index.md b/content/en/news/2017/_index.md
new file mode 100644
index 000000000000..43d5f0d7e976
--- /dev/null
+++ b/content/en/news/2017/_index.md
@@ -0,0 +1,6 @@
+---
+title: 2017 News
+description: News items for 2017.
+weight: 20
+icon: newspaper
+---
diff --git a/content/en/blog/2017/0.1-announcement/index.md b/content/en/news/2017/announcing-0.1/index.md
similarity index 87%
rename from content/en/blog/2017/0.1-announcement/index.md
rename to content/en/news/2017/announcing-0.1/index.md
index 3bb41388a9e6..65e83f368103 100644
--- a/content/en/blog/2017/0.1-announcement/index.md
+++ b/content/en/news/2017/announcing-0.1/index.md
@@ -7,6 +7,10 @@ attribution: The Istio Team
aliases:
- /blog/istio-service-mesh-for-microservices.html
- /blog/0.1-announcement.html
+ - /about/notes/older/0.1
+ - /blog/2017/0.1-announcement
+ - /docs/welcome/notes/0.1.html
+ - /about/notes/0.1/index.html
---
Google, IBM, and Lyft are proud to announce the first public release of [Istio](/): an open source project that provides a uniform way to connect, secure, manage and monitor microservices. Our current release is targeted at the [Kubernetes](https://kubernetes.io/) environment; we intend to add support for other environments such as virtual machines and Cloud Foundry in the coming months.
@@ -68,14 +72,30 @@ this journey.
To get involved, connect with us via any of these channels:
-* [istio.io]() for documentation and examples.
+- [istio.io]() for documentation and examples.
-* The [Istio discussion board](https://discuss.istio.io) general discussions,
+- The [Istio discussion board](https://discuss.istio.io) general discussions,
-* [Stack Overflow](https://stackoverflow.com/questions/tagged/istio) for curated questions and answers
+- [Stack Overflow](https://stackoverflow.com/questions/tagged/istio) for curated questions and answers
-* [GitHub](https://github.com/istio/istio/issues) for filing issues
+- [GitHub](https://github.com/istio/istio/issues) for filing issues
-* [@IstioMesh](https://twitter.com/IstioMesh) on Twitter
+- [@IstioMesh](https://twitter.com/IstioMesh) on Twitter
From everyone working on Istio, welcome aboard!
+
+## Release notes
+
+- Installation of Istio into a Kubernetes namespace with a single command.
+- Semi-automated injection of Envoy proxies into Kubernetes pods.
+- Automatic traffic capture for Kubernetes pods using iptables.
+- In-cluster load balancing for HTTP, gRPC, and TCP traffic.
+- Support for timeouts, retries with budgets, and circuit breakers.
+- Istio-integrated Kubernetes Ingress support (Istio acts as an Ingress Controller).
+- Fine-grained traffic routing controls, including A/B testing, canarying, red/black deployments.
+- Flexible in-memory rate limiting.
+- L7 telemetry and logging for HTTP and gRPC using Prometheus.
+- Grafana dashboards showing per-service L7 metrics.
+- Request tracing through Envoy with Zipkin.
+- Service-to-service authentication using mutual TLS.
+- Simple service-to-service authorization using deny expressions.
diff --git a/content/en/blog/2017/0.1-announcement/istio_grafana_dashboard-new.png b/content/en/news/2017/announcing-0.1/istio_grafana_dashboard-new.png
similarity index 100%
rename from content/en/blog/2017/0.1-announcement/istio_grafana_dashboard-new.png
rename to content/en/news/2017/announcing-0.1/istio_grafana_dashboard-new.png
diff --git a/content/en/blog/2017/0.1-announcement/istio_zipkin_dashboard.png b/content/en/news/2017/announcing-0.1/istio_zipkin_dashboard.png
similarity index 100%
rename from content/en/blog/2017/0.1-announcement/istio_zipkin_dashboard.png
rename to content/en/news/2017/announcing-0.1/istio_zipkin_dashboard.png
diff --git a/content/en/boilerplates/notes/0.2.md b/content/en/news/2017/announcing-0.2/index.md
similarity index 53%
rename from content/en/boilerplates/notes/0.2.md
rename to content/en/news/2017/announcing-0.2/index.md
index 53dc794a96b0..0a8de96dd015 100644
--- a/content/en/boilerplates/notes/0.2.md
+++ b/content/en/news/2017/announcing-0.2/index.md
@@ -1,4 +1,62 @@
-## General
+---
+title: Announcing Istio 0.2
+description: Istio 0.2 announcement.
+publishdate: 2017-10-10
+subtitle: Improved mesh and support for multiple environments
+attribution: The Istio Team
+aliases:
+ - /blog/istio-0.2-announcement.html
+ - /about/notes/older/0.2
+ - /blog/2017/0.2-announcement
+ - /docs/welcome/notes/0.2.html
+ - /about/notes/0.2/index.html
+---
+
+We launched Istio; an open platform to connect, manage, monitor, and secure microservices, on May 24, 2017. We have been humbled by the incredible interest, and
+rapid community growth of developers, operators, and partners. Our 0.1 release was focused on showing all the concepts of Istio in Kubernetes.
+
+Today we are happy to announce the 0.2 release which improves stability and performance, allows for cluster wide deployment and automated injection of sidecars in Kubernetes, adds policy and authentication for TCP services, and enables expansion of the mesh to include services deployed in virtual machines. In addition, Istio can now run outside Kubernetes, leveraging Consul/Nomad or Eureka. Beyond core features, Istio is now ready for extensions to be written by third party companies and developers.
+
+## Highlights for the 0.2 release
+
+### Usability improvements
+
+- _Multiple namespace support_: Istio now works cluster-wide, across multiple namespaces and this was one of the top requests from community from 0.1 release.
+
+- _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/reference/access-authn-authz/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
+[Mixer Adapter Developer's Guide](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide) can help
+you easily integrate your solution with Istio.
+
+- _Bring your own CA certificates_: Allows users to provide their own key and certificate for Istio CA and persistent CA key/certificate Storage. Enables storing signing key/certificates in persistent storage to facilitate CA restarts.
+
+- _Improved routing & metrics_: Support for WebSocket, MongoDB and Redis protocols. You can apply resilience features like circuit breakers on traffic to third party services. In addition to Mixer’s metrics, hundreds of metrics from Envoy are now visible inside Prometheus for all traffic entering, leaving and within Istio mesh.
+
+### Cross environment support
+
+- _Mesh expansion_: Istio mesh can now span services running outside of Kubernetes - like those running in virtual machines while enjoying benefits such as automatic mutual TLS authentication, traffic management, telemetry, and policy enforcement across the mesh.
+
+- _Running outside Kubernetes_: We know many customers use other service registry and orchestration solutions like Consul/Nomad and Eureka. Istio Pilot can now run standalone outside Kubernetes, consuming information from these systems, and manage the Envoy fleet in VMs or containers.
+
+## Get involved in shaping the future of Istio
+
+We have a growing [roadmap](/about/feature-stages/) ahead of us, full of great features to implement. Our focus next release is going to be on stability, reliability, integration with third party tools and multicluster use cases.
+
+To learn how to get involved and contribute to Istio's future, check out our [community](https://github.com/istio/community) GitHub repository which
+will introduce you to our working groups, our mailing lists, our various community meetings, our general procedures and our guidelines.
+
+We want to thank our fantastic community for field testing new versions, filing bug reports, contributing code, helping out other community members, and shaping Istio by participating in countless productive discussions. This has enabled the project to accrue 3000 stars on GitHub since launch and hundreds of active community members on Istio mailing lists.
+
+Thank you
+
+## Release notes
+
+### General
- **Updated Configuration Model**. Istio now uses the Kubernetes [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
model to describe and store its configuration. When running in Kubernetes, configuration can now be optionally managed using the `kubectl`
@@ -16,7 +74,7 @@ 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/reference/access-authn-authz/extensible-admission-controllers/) alpha feature in Kubernetes.
-## Performance and quality
+### Performance and quality
There have been many performance and reliability improvements throughout the system. We don’t consider Istio 0.2 ready for production yet, but
we’ve made excellent progress in that direction. Here are a few items of note:
@@ -33,7 +91,7 @@ request-time for initial requests and thus delivers a smoother average latency.
- **Reduced Latency for Egress Traffic**. We now forward traffic to external services directly from the sidecar.
-## Traffic management
+### Traffic management
- **Egress Rules**. It’s now possible to specify routing rules for egress traffic.
@@ -43,7 +101,7 @@ and Kubernetes [headless services](https://kubernetes.io/docs/concepts/services-
- **Other Improvements**. Ingress properly supports gRPC services, better support for health checks, and
Jaeger tracing.
-## Policy enforcement & telemetry
+### Policy enforcement & telemetry
- **Ingress Policies**. In addition to east-west traffic supported in 0.1. policies can now be applied to north-south traffic.
@@ -65,7 +123,7 @@ release. The experimental `redisquota` adapter has been removed in the 0.2 relea
- **Mixer Call Tracing**. Calls between Envoy and Mixer can now be traced and analyzed in the Zipkin dashboard.
-## Security
+### Security
- **Mutual TLS for TCP Traffic**. In addition to HTTP traffic, mutual TLS is now supported for TCP traffic as well.
diff --git a/content/en/boilerplates/notes/0.3.md b/content/en/news/2017/announcing-0.3/index.md
similarity index 82%
rename from content/en/boilerplates/notes/0.3.md
rename to content/en/news/2017/announcing-0.3/index.md
index 302f84715525..196db39da65c 100644
--- a/content/en/boilerplates/notes/0.3.md
+++ b/content/en/news/2017/announcing-0.3/index.md
@@ -1,3 +1,19 @@
+---
+title: Announcing Istio 0.3
+description: Istio 0.3 announcement.
+publishdate: 2017-11-29
+attribution: The Istio Team
+release: 0.3
+aliases:
+ - /about/notes/older/0.3
+ - /docs/welcome/notes/0.3.html
+ - /about/notes/0.3/index.html
+---
+
+We're pleased to announce the availability of Istio 0.3. Please see below for what's changed.
+
+{{< relnote >}}
+
## General
Starting with 0.3, Istio is switching to a monthly release cadence. We hope this will help accelerate our ability
diff --git a/content/en/boilerplates/notes/0.4.md b/content/en/news/2017/announcing-0.4/index.md
similarity index 63%
rename from content/en/boilerplates/notes/0.4.md
rename to content/en/news/2017/announcing-0.4/index.md
index 647e897bff91..e9d69341fa01 100644
--- a/content/en/boilerplates/notes/0.4.md
+++ b/content/en/news/2017/announcing-0.4/index.md
@@ -1,3 +1,21 @@
+---
+title: Announcing Istio 0.4
+description: Istio 0.4 announcement.
+publishdate: 2017-12-18
+attribution: The Istio Team
+release: 0.3
+aliases:
+ - /about/notes/older/0.4
+ - /docs/welcome/notes/0.4.html
+ - /about/notes/0.4/index.html
+---
+
+This release has only got a few weeks' worth of changes, as we stabilize our monthly release process.
+In addition to the usual pile of bug fixes and performance improvements, this release includes the items
+below.
+
+{{< relnote >}}
+
## General
- **Cloud Foundry**. Added minimum Pilot support for the [Cloud Foundry](https://www.cloudfoundry.org) platform, making it
diff --git a/content/en/news/2018/_index.md b/content/en/news/2018/_index.md
new file mode 100644
index 000000000000..e6cb2eb4dd21
--- /dev/null
+++ b/content/en/news/2018/_index.md
@@ -0,0 +1,6 @@
+---
+title: 2018 News
+description: News items for 2018.
+weight: 10
+icon: newspaper
+---
diff --git a/content/en/boilerplates/notes/0.5.md b/content/en/news/2018/announcing-0.5/index.md
similarity index 88%
rename from content/en/boilerplates/notes/0.5.md
rename to content/en/news/2018/announcing-0.5/index.md
index 4f4d14ab34b7..3e1e6d47b3e1 100644
--- a/content/en/boilerplates/notes/0.5.md
+++ b/content/en/news/2018/announcing-0.5/index.md
@@ -1,3 +1,19 @@
+---
+title: Announcing Istio 0.5
+description: Istio 0.5 announcement.
+publishdate: 2018-02-02
+attribution: The Istio Team
+release: 0.5
+aliases:
+ - /about/notes/older/0.5
+ - /about/notes/0.5/index.html
+---
+
+In addition to the usual pile of bug fixes and performance improvements, this release includes the new or
+updated features detailed below.
+
+{{< relnote >}}
+
## Networking
- **Incremental Istio Deployment**. (Preview) You can now adopt Istio incrementally, more easily than before, by installing only
diff --git a/content/en/boilerplates/notes/0.6.md b/content/en/news/2018/announcing-0.6/index.md
similarity index 80%
rename from content/en/boilerplates/notes/0.6.md
rename to content/en/news/2018/announcing-0.6/index.md
index 3a1bea2f9cde..66179e96f416 100644
--- a/content/en/boilerplates/notes/0.6.md
+++ b/content/en/news/2018/announcing-0.6/index.md
@@ -1,3 +1,19 @@
+---
+title: Announcing Istio 0.6
+description: Istio 0.6 announcement.
+publishdate: 2018-03-08
+attribution: The Istio Team
+release: 0.6
+aliases:
+ - /about/notes/older/0.6
+ - /about/notes/0.6/index.html
+---
+
+In addition to the usual pile of bug fixes and performance improvements, this release includes the new or
+updated features detailed below.
+
+{{< relnote >}}
+
## Networking
- **Custom Envoy Configuration**. Pilot now supports ferrying custom Envoy configuration to the
diff --git a/content/en/boilerplates/notes/0.7.md b/content/en/news/2018/announcing-0.7/index.md
similarity index 56%
rename from content/en/boilerplates/notes/0.7.md
rename to content/en/news/2018/announcing-0.7/index.md
index 7a34dd859076..d59c1d3d78f1 100644
--- a/content/en/boilerplates/notes/0.7.md
+++ b/content/en/news/2018/announcing-0.7/index.md
@@ -1,4 +1,18 @@
-This release include a large number of bug fixes and performance improvements.
+---
+title: Announcing Istio 0.7
+description: Istio 0.7 announcement.
+publishdate: 2018-03-28
+attribution: The Istio Team
+release: 0.7
+aliases:
+ - /about/notes/0.7
+ - /about/notes/0.7/index.html
+---
+
+For this release, we focused on improving our build and test infrastructures and increasing the
+quality of our tests. As a result, there are no new features for this month.
+
+{{< relnote >}}
Please note that this release includes preliminary support for the new v1alpha3 traffic management
functionality. This functionality is still in a great deal of flux and there may be some breaking
diff --git a/content/en/boilerplates/notes/0.8.md b/content/en/news/2018/announcing-0.8/index.md
similarity index 89%
rename from content/en/boilerplates/notes/0.8.md
rename to content/en/news/2018/announcing-0.8/index.md
index 4824500fbf56..b9309e919d76 100644
--- a/content/en/boilerplates/notes/0.8.md
+++ b/content/en/news/2018/announcing-0.8/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 0.8
+description: Istio 0.8 announcement.
+publishdate: 2018-06-01
+attribution: The Istio Team
+release: 0.8
+aliases:
+ - /about/notes/0.8
+ - /about/notes/0.8/index.html
+---
+
+This is a major release for Istio on the road to 1.0. There are a great many new features and architectural improvements in addition to the usual pile of bug fixes and performance improvements.
+
+{{< relnote >}}
+
## Networking
- **Revamped Traffic Management Model**. We're finally ready to take the wraps off our
diff --git a/content/en/boilerplates/notes/1.0.1.md b/content/en/news/2018/announcing-1.0.1/index.md
similarity index 80%
rename from content/en/boilerplates/notes/1.0.1.md
rename to content/en/news/2018/announcing-1.0.1/index.md
index 626dd5703f18..3ebf5aa25d3f 100644
--- a/content/en/boilerplates/notes/1.0.1.md
+++ b/content/en/news/2018/announcing-1.0.1/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.0.1
+description: Istio 1.0.1 patch release.
+publishdate: 2018-08-29
+attribution: The Istio Team
+release: 1.0.1
+aliases:
+ - /about/notes/1.0.1
+ - /blog/2018/announcing-1.0.1
+---
+
+We're pleased to announce the availability of Istio 1.0.1. Please see below for what's changed.
+
+{{< relnote >}}
+
## Networking
- Improved Pilot scalability and Envoy startup time.
diff --git a/content/en/boilerplates/notes/1.0.2.md b/content/en/news/2018/announcing-1.0.2/index.md
similarity index 57%
rename from content/en/boilerplates/notes/1.0.2.md
rename to content/en/news/2018/announcing-1.0.2/index.md
index 011e30f1664d..01ace3afecea 100644
--- a/content/en/boilerplates/notes/1.0.2.md
+++ b/content/en/news/2018/announcing-1.0.2/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.0.2
+description: Istio 1.0.2 patch release.
+publishdate: 2018-09-06
+attribution: The Istio Team
+release: 1.0.2
+aliases:
+ - /about/notes/1.0.1
+ - /blog/2018/announcing-1.0.2
+---
+
+We're pleased to announce the availability of Istio 1.0.2. Please see below for what's changed.
+
+{{< relnote >}}
+
## General
- Fixed bug in Envoy where the sidecar would crash if receiving normal traffic on the mutual TLS port.
diff --git a/content/en/boilerplates/notes/1.0.3.md b/content/en/news/2018/announcing-1.0.3/index.md
similarity index 80%
rename from content/en/boilerplates/notes/1.0.3.md
rename to content/en/news/2018/announcing-1.0.3/index.md
index e2cfe6ede84b..bfea3639e48f 100644
--- a/content/en/boilerplates/notes/1.0.3.md
+++ b/content/en/news/2018/announcing-1.0.3/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.0.3
+description: Istio 1.0.3 patch release.
+publishdate: 2018-10-30
+attribution: The Istio Team
+release: 1.0.3
+aliases:
+ - /about/notes/1.0.3
+ - /blog/2018/announcing-1.0.3
+---
+
+We're pleased to announce the availability of Istio 1.0.3. Please see below for what's changed.
+
+{{< relnote >}}
+
## Behavior changes
- [Validating webhook](/docs/ops/troubleshooting/validation) is now mandatory. Disabling it may result in Pilot crashes.
diff --git a/content/en/boilerplates/notes/1.0.4.md b/content/en/news/2018/announcing-1.0.4/index.md
similarity index 67%
rename from content/en/boilerplates/notes/1.0.4.md
rename to content/en/news/2018/announcing-1.0.4/index.md
index e0fe7e0ffdeb..f40d1875323c 100644
--- a/content/en/boilerplates/notes/1.0.4.md
+++ b/content/en/news/2018/announcing-1.0.4/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.0.4
+description: Istio 1.0.4 patch release.
+publishdate: 2018-11-21
+attribution: The Istio Team
+release: 1.0.4
+aliases:
+ - /about/notes/1.0.4
+ - /blog/2018/announcing-1.0.4
+---
+
+We're pleased to announce the availability of Istio 1.0.4. Please see below for what's changed.
+
+{{< relnote >}}
+
## Known issues
- Pilot may deadlock when using [`istioctl proxy-status`](/docs/reference/commands/istioctl/#istioctl-proxy-status) to get proxy synchronization status.
diff --git a/content/en/boilerplates/notes/1.0.5.md b/content/en/news/2018/announcing-1.0.5/index.md
similarity index 50%
rename from content/en/boilerplates/notes/1.0.5.md
rename to content/en/news/2018/announcing-1.0.5/index.md
index 5737cadcf566..2bb26e5470ab 100644
--- a/content/en/boilerplates/notes/1.0.5.md
+++ b/content/en/news/2018/announcing-1.0.5/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.0.5
+description: Istio 1.0.5 patch release.
+publishdate: 2018-12-20
+attribution: The Istio Team
+release: 1.0.5
+aliases:
+ - /about/notes/1.0.5
+ - /blog/2018/announcing-1.0.5
+---
+
+We're pleased to announce the availability of Istio 1.0.5. Please see below for what's changed.
+
+{{< relnote >}}
+
## General
- Disabled the precondition cache in the `istio-policy` service as it lead to invalid results. The
diff --git a/content/en/news/2018/announcing-1.0/index.md b/content/en/news/2018/announcing-1.0/index.md
new file mode 100644
index 000000000000..9b6964b1c27d
--- /dev/null
+++ b/content/en/news/2018/announcing-1.0/index.md
@@ -0,0 +1,154 @@
+---
+title: Announcing Istio 1.0
+subtitle: The production ready service mesh
+description: Istio is ready for production use with its 1.0 release.
+publishdate: 2018-07-31
+attribution: The Istio Team
+release: 1.0.0
+aliases:
+ - /about/notes/1.0
+ - /blog/2018/announcing-1.0
+---
+
+Today, we’re excited to announce Istio 1.0! It’s been a little over a year since our initial 0.1 release. Since then, Istio has evolved significantly with the help of a thriving and growing community of contributors and users. We’ve now reached the point where many companies have successfully adopted Istio in production and have gotten real value from the insight and control it provides over their deployments. We’ve helped large enterprises and fast-moving startups like [eBay](https://www.ebay.com/), [Auto Trader UK](https://www.autotrader.co.uk/), [Descartes Labs](http://www.descarteslabs.com/), [HP FitStation](https://www.fitstation.com/), [JUSPAY](https://juspay.in), [Namely](https://www.namely.com/), [PubNub](https://www.pubnub.com/) and [Trulia](https://www.trulia.com/) use Istio to connect, manage and secure their services from the ground up. Shipping this release as 1.0 is recognition that we’ve built a core set of functionality that our users can rely on for production use.
+
+{{< relnote >}}
+
+## Ecosystem
+
+We’ve seen substantial growth in Istio's ecosystem in the last year. [Envoy](https://www.envoyproxy.io/) continues its impressive growth and added numerous
+features that are crucial for a production quality service mesh. Observability providers like [Datadog](https://www.datadoghq.com/),
+[SolarWinds](https://www.solarwinds.com/), [Sysdig](https://sysdig.com/blog/monitor-istio/), [Google Stackdriver](https://cloud.google.com/stackdriver/) and
+[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) have written plugins to integrate Istio with their products.
+[Tigera](https://www.tigera.io/resources/using-network-policy-concert-istio-2/), [Aporeto](https://www.aporeto.com/), [Cilium](https://cilium.io/)
+and [Styra](https://styra.com/) built extensions to our policy enforcement and networking capabilities. [Red Hat](https://www.redhat.com/en) built [Kiali](https://www.kiali.io) to wrap a nice user-experience around mesh management and observability. [Cloud Foundry](https://www.cloudfoundry.org/) is building on Istio for it’s next generation traffic routing stack, the recently announced [Knative](https://github.com/knative/docs) serverless project is doing the same and [Apigee](https://apigee.com/) announced that they plan to use it in their API management solution. These are just some of the integrations the community has added in the last year.
+
+## Features
+
+Since the 0.8 release we’ve added some important new features and more importantly marked many of our existing features as Beta signaling that they’re ready for production use.
+Here are some highlights:
+
+- Multiple Kubernetes clusters can now be [added to a single mesh](/docs/setup/install/multicluster/) and enabling cross-cluster communication and consistent policy enforcement. Multi-cluster support is now Beta.
+
+- Networking APIs that enable fine grained control over the flow of traffic through a mesh are now Beta. Explicitly modeling ingress and egress concerns using Gateways allows operators to [control the network topology](/blog/2018/v1alpha3-routing/) and meet access security requirements at the edge.
+
+- Mutual TLS can now be [rolled out incrementally](/docs/tasks/security/mtls-migration) without requiring all clients of a service to be updated. This is a critical feature that unblocks adoption in-place by existing production deployments.
+
+- Mixer now has support for [developing out-of-process adapters](https://github.com/istio/istio/wiki/Out-Of-Process-gRPC-Adapter-Dev-Guide). This will become the default way to extend Mixer over the coming releases and makes building adapters much simpler.
+
+- [Authorization policies](/docs/concepts/security/#authorization) which control access to services are now entirely evaluated locally in Envoy increasing
+their performance and reliability.
+
+- [Helm chart installation](/docs/setup/install/helm/) is now the recommended install method offering rich customization options to adopt Istio on your terms.
+
+- We’ve put a lot of effort into performance including continuous regression testing, large scale environment simulation and targeted fixes. We’re very happy with the results and will share more on this in detail in the coming weeks.
+
+## What’s next?
+
+While this is a significant milestone for the project there’s lots more to do. In working with adopters we’ve gotten a lot of great feedback about what to focus next. We’ve heard consistent themes around support for hybrid-cloud, install modularity, richer networking features and scalability for massive deployments. We’ve already taken some of this feedback into account in the 1.0 release and we’ll continue to aggressively tackle this work in the coming months.
+
+## Getting Started
+
+If you’re new to Istio and looking to use it for your deployment we’d love to hear from you. Take a look at [our docs](/docs/) or stop by our
+[chat forum](https://discuss.istio.io). If you’d like
+to go deeper and [contribute to the project](/about/community) come to one of our community meetings and say hello.
+
+## Thanks
+
+The Istio team would like to give huge thanks to everyone who has made a contribution to the project. It wouldn’t be where it is today without your help. The last year has been pretty amazing and we look forward to the next one with excitement about what we can achieve together as a community.
+
+## Release notes
+
+### Networking
+
+- **SNI Routing using Virtual Services**. Newly introduced `TLS` sections in
+[`VirtualService`](/docs/reference/config/networking/v1alpha3/virtual-service/) can be used to route TLS traffic
+based on SNI values. Service ports named as TLS/HTTPS can be used in conjunction with
+virtual service TLS routes. TLS/HTTPS ports without an accompanying virtual service will be treated as opaque TCP.
+
+- **Streaming gRPC Restored**. Istio 0.8 caused periodic termination of long running streaming gRPC connections. This has been fixed in 1.0.
+
+- **Old (v1alpha1) Networking APIs Removed**. Support for the old `v1alpha1` traffic management model
+has been removed.
+
+- **Istio Ingress Deprecated**. The old Istio ingress is deprecated and disabled by default. We encourage users to use [gateways](/docs/concepts/traffic-management/#gateways) instead.
+
+### Policy and Telemetry
+
+- **Updated Attributes**. The set of [attributes](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/) used to describe the source and
+destination of traffic have been completely revamped in order to be more
+precise and comprehensive.
+
+- **Policy Check Cache**. Mixer now features a large level 2 cache for policy checks, complementing the level 1 cache
+present in the sidecar proxy. This further reduces the average latency of externally-enforced
+policy checks.
+
+- **Telemetry Buffering**. Mixer now buffers report calls before dispatching to adapters, which gives an opportunity for
+adapters to process telemetry data in bigger chunks, reducing overall computational overhead
+in Mixer and its adapters.
+
+- **Out of Process Adapters**. Mixer now includes initial support for out-of-process adapters. This will
+be the recommended approach moving forward for integrating with Mixer. Initial documentation on
+how to build an out-of-process adapter is provided by the
+[Out Of Process Adapter Dev Guide](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide)
+and the [Out Of Process Adapter Walk-through](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Walkthrough).
+
+- **Client-Side Telemetry**. It's now possible to collect telemetry from the client of an interaction,
+in addition to the server-side telemetry.
+
+#### Adapters
+
+- **SignalFX**. There is a new [`signalfx`](/docs/reference/config/policy-and-telemetry/adapters/signalfx/) adapter.
+
+- **Stackdriver**. The [`stackdriver`](/docs/reference/config/policy-and-telemetry/adapters/stackdriver/) adapter has been substantially enhanced in this
+release to add new features and improve performance.
+
+### Security
+
+- **Authorization**. We've reimplemented our [authorization functionality](/docs/concepts/security/#authorization).
+RPC-level authorization policies can now be implemented without the need for Mixer and Mixer adapters.
+
+- **Improved Mutual TLS Authentication Control**. It's now easier to [control mutual TLS authentication](/docs/concepts/security/#authentication) between services. We provide 'PERMISSIVE' mode so that you can
+[incrementally turn on mutual TLS](/docs/tasks/security/mtls-migration/) for your services.
+We removed service annotations and have a [unique approach to turn on mutual TLS](/docs/tasks/security/authn-policy/),
+coupled with client-side [destination rules](/docs/concepts/traffic-management/#destination-rules).
+
+- **JWT Authentication**. We now support [JWT authentication](/docs/concepts/security/#authentication) which can
+be configured using [authentication policies](/docs/concepts/security/#authentication-policies).
+
+### `istioctl`
+
+- Added the [`istioctl authn tls-check`](/docs/reference/commands/istioctl/#istioctl-authn-tls-check) command.
+
+- Added the [`istioctl proxy-status`](/docs/reference/commands/istioctl/#istioctl-proxy-status) command.
+
+- Added the `istioctl experimental convert-ingress` command.
+
+- Removed the `istioctl experimental convert-networking-config` command.
+
+- Enhancements and bug fixes:
+
+ - Align `kubeconfig` handling with `kubectl`
+
+ - `istioctl get all` returns all types of networking and authentication configuration.
+
+ - Added the `--all-namespaces` flag to `istioctl get` to retrieve resources across all namespaces.
+
+### Known issues with 1.0
+
+- Amazon's EKS service does not implement automatic sidecar injection. Istio can be used in Amazon's
+ EKS by using [manual injection](/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection) for
+ sidecars and turning off galley using the [Helm parameter](/docs/setup/install/helm)
+ `--set galley.enabled=false`.
+
+- In a [multicluster deployment](/docs/setup/install/multicluster) the mixer-telemetry
+ and mixer-policy components do not connect to the Kubernetes API endpoints of any of the remote
+ clusters. This results in a loss of telemetry fidelity as some of the metadata associated
+ with workloads on remote clusters is incomplete.
+
+- There are Kubernetes manifests available for using Citadel standalone or with Citadel health checking enabled.
+ There is not a Helm implementation of these modes. See [Issue 6922](https://github.com/istio/istio/issues/6922)
+ for more details.
+
+- Mesh expansion functionality, which lets you add raw VMs to a mesh is broken in 1.0. We're expecting to produce a
+patch that fixes this problem within a few days.
diff --git a/content/en/news/2019/_index.md b/content/en/news/2019/_index.md
new file mode 100644
index 000000000000..a693dc302df4
--- /dev/null
+++ b/content/en/news/2019/_index.md
@@ -0,0 +1,6 @@
+---
+title: 2019 News
+description: News items for 2019.
+weight: 9
+icon: newspaper
+---
diff --git a/content/en/blog/2019/announcing-1.0-eol-final/index.md b/content/en/news/2019/announcing-1.0-eol-final/index.md
similarity index 77%
rename from content/en/blog/2019/announcing-1.0-eol-final/index.md
rename to content/en/news/2019/announcing-1.0-eol-final/index.md
index ea1595cfbd35..b942bf4b823b 100644
--- a/content/en/blog/2019/announcing-1.0-eol-final/index.md
+++ b/content/en/news/2019/announcing-1.0-eol-final/index.md
@@ -3,8 +3,10 @@ title: Support for Istio 1.0 has ended
description: Istio 1.0 end of life announcement.
publishdate: 2019-06-19
attribution: The Istio Team
+aliases:
+ - /blog/2019/announcing-1.0-eol-final
---
-As [previously announced](/blog/2019/announcing-1.0-eol/), support for Istio 1.0 has now officially ended.
+As [previously announced](/news/2019/announcing-1.0-eol/), support for Istio 1.0 has now officially ended.
We will no longer back-port fixes for security issues and critical bugs to 1.0, so we encourage you to upgrade to the latest version of Istio ({{}}) if you haven't already.
diff --git a/content/en/blog/2019/announcing-1.0-eol/index.md b/content/en/news/2019/announcing-1.0-eol/index.md
similarity index 79%
rename from content/en/blog/2019/announcing-1.0-eol/index.md
rename to content/en/news/2019/announcing-1.0-eol/index.md
index 199d19c2939d..699d4df01574 100644
--- a/content/en/blog/2019/announcing-1.0-eol/index.md
+++ b/content/en/news/2019/announcing-1.0-eol/index.md
@@ -3,10 +3,11 @@ title: Support for Istio 1.0 ends on June 19th, 2019
description: Upcoming Istio 1.0 end of life announcement.
publishdate: 2019-05-23
attribution: The Istio Team
-release: 1.0
+aliases:
+ - /blog/2019/announcing-1.0-eol
---
-According to Istio's [support policy](/about/release-cadence/), LTS releases like 1.0 are supported for three months after the next LTS release. Since [1.1 was released on March 19th](/about/notes/1.1/), support for 1.0 will end on June 19th, 2019.
+According to Istio's [support policy](/about/release-cadence/), LTS releases like 1.0 are supported for three months after the next LTS release. Since [1.1 was released on March 19th](/news/2019/announcing-1.1/), support for 1.0 will end on June 19th, 2019.
At that point we will stop back-porting fixes for security issues and critical bugs to 1.0, so we encourage you to upgrade to the latest version of Istio ({{}}). If you don't do this you may put yourself in the position of having to do a major upgrade on a short timeframe to pick up a critical fix.
diff --git a/content/en/boilerplates/notes/1.1.6.md b/content/en/news/2019/announcing-1.0.6/index.md
similarity index 77%
rename from content/en/boilerplates/notes/1.1.6.md
rename to content/en/news/2019/announcing-1.0.6/index.md
index 89432dc45b73..317e03d59594 100644
--- a/content/en/boilerplates/notes/1.1.6.md
+++ b/content/en/news/2019/announcing-1.0.6/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.0.6
+description: Istio 1.0.6 patch release.
+publishdate: 2019-02-12
+attribution: The Istio Team
+release: 1.0.6
+aliases:
+ - /about/notes/1.0.6
+ - /blog/2019/announcing-1.0.6
+---
+
+We're pleased to announce the availability of Istio 1.0.6. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Fix Galley Helm charts so that the `validatingwebhookconfiguration` object can now deployed to a namespace other than `istio-system` ([Issue 13625](https://github.com/istio/istio/issues/13625)).
diff --git a/content/en/boilerplates/notes/1.1.2.md b/content/en/news/2019/announcing-1.0.7/index.md
similarity index 89%
rename from content/en/boilerplates/notes/1.1.2.md
rename to content/en/news/2019/announcing-1.0.7/index.md
index c12a24390805..f447a47b1356 100644
--- a/content/en/boilerplates/notes/1.1.2.md
+++ b/content/en/news/2019/announcing-1.0.7/index.md
@@ -1,3 +1,19 @@
+---
+title: Announcing Istio 1.0.7 with Important Security Update
+subtitle: Important Security Update
+description: Istio 1.0.7 patch releases.
+publishdate: 2019-04-05
+attribution: The Istio Team
+release: 1.0.7
+aliases:
+ - /about/notes/1.0.7
+ - /blog/2019/announcing-1.0.7
+---
+
+We're announcing immediate availability of Istio 1.0.7 which contains some important security updates. Please see below for details.
+
+{{< relnote >}}
+
## Security update
Two security vulnerabilities have recently been identified in the Envoy proxy
@@ -40,9 +56,9 @@ policies or the routing rules, an attacker could exploit these vulnerabilities t
Eliminating the vulnerabilities requires updating to a corrected version of Envoy. We’ve incorporated the necessary updates in the latest Istio patch releases.
-For Istio 1.1.x deployments: update to a minimum of [Istio 1.1.2](/about/notes/1.1.2)
+For Istio 1.1.x deployments: update to a minimum of [Istio 1.1.2](/news/2019/announcing-1.1.2)
-For Istio 1.0.x deployments: update to a minimum of [Istio 1.0.7](/about/notes/1.0.7)
+For Istio 1.0.x deployments: update to a minimum of [Istio 1.0.7](/news/2019/announcing-1.0.7)
While Envoy 1.9.1 requires opting in to path normalization to address CVE 2019-9901, the version of Envoy embedded in Istio 1.1.2 and 1.0.7 enables path
normalization by default.
diff --git a/content/en/boilerplates/notes/1.0.8.md b/content/en/news/2019/announcing-1.0.8/index.md
similarity index 50%
rename from content/en/boilerplates/notes/1.0.8.md
rename to content/en/news/2019/announcing-1.0.8/index.md
index 705b45eb52ee..c3e644a0d470 100644
--- a/content/en/boilerplates/notes/1.0.8.md
+++ b/content/en/news/2019/announcing-1.0.8/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.0.8
+description: Istio 1.0.8 patch release.
+publishdate: 2019-06-07
+attribution: The Istio Team
+release: 1.0.8
+aliases:
+ - /about/notes/1.0.8
+ - /blog/2019/announcing-1.0.8
+---
+
+We're pleased to announce the availability of Istio 1.0.8. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Fix issue where Citadel could generate a new root CA if it cannot contact the Kubernetes API server, causing mutual TLS verification to incorrectly fail ([Issue 14512](https://github.com/istio/istio/issues/14512)).
diff --git a/content/en/blog/2019/announcing-1.0.9/index.md b/content/en/news/2019/announcing-1.0.9/index.md
similarity index 55%
rename from content/en/blog/2019/announcing-1.0.9/index.md
rename to content/en/news/2019/announcing-1.0.9/index.md
index c839c50d7c92..372700b7783a 100644
--- a/content/en/blog/2019/announcing-1.0.9/index.md
+++ b/content/en/news/2019/announcing-1.0.9/index.md
@@ -4,8 +4,15 @@ description: Istio 1.0.9 patch release.
publishdate: 2019-06-28
attribution: The Istio Team
release: 1.0.9
+aliases:
+ - /about/notes/1.0.9
+ - /blog/2019/announcing-1.0.9
---
We're pleased to announce the availability of Istio 1.0.9. Please see below for what's changed.
{{< relnote >}}
+
+## Bug fixes
+
+- Fix crash in Istio's JWT Envoy filter caused by malformed JWT ([Issue 15084](https://github.com/istio/istio/issues/15084)).
diff --git a/content/en/blog/2019/announcing-1.1-eol/index.md b/content/en/news/2019/announcing-1.1-eol/index.md
similarity index 79%
rename from content/en/blog/2019/announcing-1.1-eol/index.md
rename to content/en/news/2019/announcing-1.1-eol/index.md
index 337d0214b076..ffbb1c646ea8 100644
--- a/content/en/blog/2019/announcing-1.1-eol/index.md
+++ b/content/en/news/2019/announcing-1.1-eol/index.md
@@ -3,9 +3,11 @@ title: Support for Istio 1.1 ends on September 19th, 2019
description: Upcoming Istio 1.1 end of life announcement.
publishdate: 2019-08-15
attribution: The Istio Team
+aliases:
+ - /blog/2019/announcing-1.1-eol
---
-According to Istio's [support policy](/about/release-cadence/), LTS releases like 1.1 are supported for three months after the next LTS release. Since [1.2 was released on June 18th](/about/notes/1.2/), support for 1.1 will end on September 19th, 2019.
+According to Istio's [support policy](/about/release-cadence/), LTS releases like 1.1 are supported for three months after the next LTS release. Since [1.2 was released on June 18th](/news/2019/announcing-1.2/), support for 1.1 will end on September 19th, 2019.
At that point we will stop back-porting fixes for security issues and critical bugs to 1.1, so we encourage you to upgrade to the latest version of Istio ({{}}). If you don't do this you may put yourself in the position of having to do a major upgrade on a short timeframe to pick up a critical fix.
diff --git a/content/en/boilerplates/notes/1.1.1.md b/content/en/news/2019/announcing-1.1.1/index.md
similarity index 86%
rename from content/en/boilerplates/notes/1.1.1.md
rename to content/en/news/2019/announcing-1.1.1/index.md
index ddc1d8cfc55f..2984e3db770a 100644
--- a/content/en/boilerplates/notes/1.1.1.md
+++ b/content/en/news/2019/announcing-1.1.1/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.1.1
+description: Istio 1.1.1 patch release.
+publishdate: 2019-03-25
+attribution: The Istio Team
+release: 1.1.1
+aliases:
+ - /about/notes/1.1.1
+ - /blog/2019/announcing-1.1.1
+---
+
+We're pleased to announce the availability of Istio 1.1.1. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes and minor enhancements
- Configure Prometheus to monitor Citadel ([Issue 12175](https://github.com/istio/istio/pull/12175))
@@ -16,4 +31,3 @@
- Fix bug in locality load balancing normalization ([Issue 12579](https://github.com/istio/istio/pull/12579))
- Propagate Envoy Metrics Service configuration ([Issue 12569](https://github.com/istio/istio/issues/12569))
- Do not apply `VirtualService` rule to the wrong gateway ([Issue 10313](https://github.com/istio/istio/issues/10313))
-
diff --git a/content/en/boilerplates/notes/1.1.10.md b/content/en/news/2019/announcing-1.1.10/index.md
similarity index 57%
rename from content/en/boilerplates/notes/1.1.10.md
rename to content/en/news/2019/announcing-1.1.10/index.md
index e07535340bc7..b342131b35f3 100644
--- a/content/en/boilerplates/notes/1.1.10.md
+++ b/content/en/news/2019/announcing-1.1.10/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.1.10
+description: Istio 1.1.10 patch release.
+publishdate: 2019-06-28
+attribution: The Istio Team
+release: 1.1.10
+aliases:
+ - /about/notes/1.1.10
+ - /blog/2019/announcing-1.1.10
+---
+
+We're pleased to announce the availability of Istio 1.1.10. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Eliminate 503 errors caused by Envoy not being able to talk to the SDS Node Agent after a restart ([Issue 14853](https://github.com/istio/istio/issues/14853)).
diff --git a/content/en/blog/2019/announcing-1.1.11/index.md b/content/en/news/2019/announcing-1.1.11/index.md
similarity index 54%
rename from content/en/blog/2019/announcing-1.1.11/index.md
rename to content/en/news/2019/announcing-1.1.11/index.md
index 7dfc0bbd6394..f994485aa866 100644
--- a/content/en/blog/2019/announcing-1.1.11/index.md
+++ b/content/en/news/2019/announcing-1.1.11/index.md
@@ -4,8 +4,15 @@ description: Istio 1.1.11 patch release.
publishdate: 2019-07-03
attribution: The Istio Team
release: 1.1.11
+aliases:
+ - /about/notes/1.1.11
+ - /blog/2019/announcing-1.1.11
---
We're pleased to announce the availability of Istio 1.1.11. Please see below for what's changed.
{{< relnote >}}
+
+## Small enhancements
+
+- Add ability to enable `HTTP/1.0` support in ingress gateway ([Issue 13085](https://github.com/istio/istio/issues/13085)).
diff --git a/content/en/news/2019/announcing-1.1.12/index.md b/content/en/news/2019/announcing-1.1.12/index.md
new file mode 100644
index 000000000000..aad3d000911a
--- /dev/null
+++ b/content/en/news/2019/announcing-1.1.12/index.md
@@ -0,0 +1,18 @@
+---
+title: Announcing Istio 1.1.12
+description: Istio 1.1.12 patch release.
+publishdate: 2019-08-02
+attribution: The Istio Team
+release: 1.1.12
+aliases:
+ - /about/notes/1.1.12
+ - /blog/2019/announcing-1.1.12
+---
+
+We're pleased to announce the availability of Istio 1.1.12. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Bug fixes
+
+- Fix a bug where the sidecar could infinitely forward requests to itself when a `Pod` resource defines a port that isn't defined for a service ([Issue 14443](https://github.com/istio/istio/issues/14443)) and ([Issue 14242](https://github.com/istio/istio/issues/14242))
diff --git a/content/en/boilerplates/notes/1.2.4.md b/content/en/news/2019/announcing-1.1.13/index.md
similarity index 84%
rename from content/en/boilerplates/notes/1.2.4.md
rename to content/en/news/2019/announcing-1.1.13/index.md
index a280ff76783f..508f7e08bd15 100644
--- a/content/en/boilerplates/notes/1.2.4.md
+++ b/content/en/news/2019/announcing-1.1.13/index.md
@@ -1,6 +1,21 @@
+---
+title: Announcing Istio 1.1.13
+description: Istio 1.1.13 patch release.
+publishdate: 2019-08-13
+attribution: The Istio Team
+release: 1.1.13
+aliases:
+ - /about/notes/1.1.13
+ - /blog/2019/announcing-1.1.13
+---
+
+We're pleased to announce the availability of Istio 1.1.13. Please see below for what's changed.
+
+{{< relnote >}}
+
## Security update
-This release contains fixes for the security vulnerabilities described in [our August 13th, 2019 blog post](/blog/2019/istio-security-003-004/). Specifically:
+This release contains fixes for the security vulnerabilities described in [our August 13th, 2019 news post](/news/2019/istio-security-003-004/). Specifically:
__ISTIO-SECURITY-2019-003__: An Envoy user reported publicly an issue (c.f. [Envoy Issue 7728](https://github.com/envoyproxy/envoy/issues/7728)) about regular expressions matching that crashes Envoy with very large URIs.
* __[CVE-2019-14993](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14993)__: After investigation, the Istio team has found that this issue could be leveraged for a DoS attack in Istio, if users are employing regular expressions in some of the Istio APIs: `JWT`, `VirtualService`, `HTTPAPISpecBinding`, `QuotaSpecBinding`.
diff --git a/content/en/boilerplates/notes/1.1.14.md b/content/en/news/2019/announcing-1.1.14/index.md
similarity index 65%
rename from content/en/boilerplates/notes/1.1.14.md
rename to content/en/news/2019/announcing-1.1.14/index.md
index 56c282b32d02..f2e6655a900e 100644
--- a/content/en/boilerplates/notes/1.1.14.md
+++ b/content/en/news/2019/announcing-1.1.14/index.md
@@ -1,6 +1,21 @@
+---
+title: Announcing Istio 1.1.14
+description: Istio 1.1.14 patch release.
+publishdate: 2019-08-26
+attribution: The Istio Team
+release: 1.1.14
+aliases:
+ - /about/notes/1.1.14
+ - /blog/2019/announcing-1.1.14
+---
+
+We're pleased to announce the availability of Istio 1.1.14. Please see below for what's changed.
+
+{{< relnote >}}
+
## Security update
-Following the previous fixes for the security vulnerabilities described in [our August 13th, 2019 blog post](/blog/2019/istio-security-003-004/), we are now addressing the internal control plane communication surface. These security fixes were not available at the time of our previous security release, and we considered the control plane gRPC surface to be harder to exploit.
+Following the previous fixes for the security vulnerabilities described in [our August 13th, 2019 blog post](/news/2019/istio-security-003-004/), we are now addressing the internal control plane communication surface. These security fixes were not available at the time of our previous security release, and we considered the control plane gRPC surface to be harder to exploit.
You can find the gRPC vulnerability fix description on their mailing list (c.f.
[HTTP/2 Security Vulnerabilities](https://groups.google.com/forum/#!topic/grpc-io/w5jPamxdda4)).
diff --git a/content/en/news/2019/announcing-1.1.15/index.md b/content/en/news/2019/announcing-1.1.15/index.md
new file mode 100644
index 000000000000..0ebd519765ab
--- /dev/null
+++ b/content/en/news/2019/announcing-1.1.15/index.md
@@ -0,0 +1,22 @@
+---
+title: Announcing Istio 1.1.15
+description: Istio 1.1.15 patch release.
+publishdate: 2019-09-16
+attribution: The Istio Team
+release: 1.1.15
+aliases:
+ - /about/notes/1.1.15
+ - /blog/2019/announcing-1.1.15
+---
+
+We're pleased to announce the availability of Istio 1.1.15. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Bug fixes
+
+- Fix an Envoy crash introduced in Istio 1.1.14 ([Issue 16357](https://github.com/istio/istio/issues/16357)).
+
+## Small enhancements
+
+- Expose `HTTP/2` window size settings as Pilot environment variables ([Issue 17117](https://github.com/istio/istio/issues/17117)).
diff --git a/content/en/news/2019/announcing-1.1.16/index.md b/content/en/news/2019/announcing-1.1.16/index.md
new file mode 100644
index 000000000000..7bab63a820e3
--- /dev/null
+++ b/content/en/news/2019/announcing-1.1.16/index.md
@@ -0,0 +1,20 @@
+---
+title: Announcing Istio 1.1.16
+description: Istio 1.1.16 patch release.
+publishdate: 2019-10-08
+attribution: The Istio Team
+release: 1.1.16
+---
+
+We're pleased to announce the availability of Istio 1.1.16. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Security update
+
+This release contains fixes for the security vulnerability described in [our October 8th, 2019 news post](/news/2019/istio-security-2019-005). Specifically:
+
+__ISTIO-SECURITY-2019-005__: A DoS vulnerability has been discovered by the Envoy community.
+ * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: After investigation, the Istio team has found that this issue could be leveraged for a DoS attack in Istio if an attacker uses a high quantity of very small headers.
+
+Nothing else is included in this release except for the above security fix.
diff --git a/content/en/boilerplates/notes/1.0.7.md b/content/en/news/2019/announcing-1.1.2/index.md
similarity index 89%
rename from content/en/boilerplates/notes/1.0.7.md
rename to content/en/news/2019/announcing-1.1.2/index.md
index c12a24390805..97c1ec73b999 100644
--- a/content/en/boilerplates/notes/1.0.7.md
+++ b/content/en/news/2019/announcing-1.1.2/index.md
@@ -1,3 +1,19 @@
+---
+title: Announcing Istio 1.1.2 with Important Security Update
+subtitle: Important Security Update
+description: Istio 1.1.2 patch release.
+publishdate: 2019-04-05
+attribution: The Istio Team
+release: 1.1.2
+aliases:
+ - /about/notes/1.1.2
+ - /blog/2019/announcing-1.1.2
+---
+
+We're announcing immediate availability of Istio 1.1.2 which contains some important security updates. Please see below for details.
+
+{{< relnote >}}
+
## Security update
Two security vulnerabilities have recently been identified in the Envoy proxy
@@ -40,9 +56,9 @@ policies or the routing rules, an attacker could exploit these vulnerabilities t
Eliminating the vulnerabilities requires updating to a corrected version of Envoy. We’ve incorporated the necessary updates in the latest Istio patch releases.
-For Istio 1.1.x deployments: update to a minimum of [Istio 1.1.2](/about/notes/1.1.2)
+For Istio 1.1.x deployments: update to a minimum of [Istio 1.1.2](/news/2019/announcing-1.1.2)
-For Istio 1.0.x deployments: update to a minimum of [Istio 1.0.7](/about/notes/1.0.7)
+For Istio 1.0.x deployments: update to a minimum of [Istio 1.0.7](/news/2019/announcing-1.0.7)
While Envoy 1.9.1 requires opting in to path normalization to address CVE 2019-9901, the version of Envoy embedded in Istio 1.1.2 and 1.0.7 enables path
normalization by default.
diff --git a/content/en/boilerplates/notes/1.1.3.md b/content/en/news/2019/announcing-1.1.3/index.md
similarity index 94%
rename from content/en/boilerplates/notes/1.1.3.md
rename to content/en/news/2019/announcing-1.1.3/index.md
index 202b51886611..abd04da82bf3 100644
--- a/content/en/boilerplates/notes/1.1.3.md
+++ b/content/en/news/2019/announcing-1.1.3/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.1.3
+description: Istio 1.1.3 patch release.
+publishdate: 2019-04-15
+attribution: The Istio Team
+release: 1.1.3
+aliases:
+ - /about/notes/1.1.3
+ - /blog/2019/announcing-1.1.3
+---
+
+We're pleased to announce the availability of Istio 1.1.3. Please see below for what's changed.
+
+{{< relnote >}}
+
## Known issues with 1.1.3
- A [panic in the Node Agent](https://github.com/istio/istio/issues/13325) was discovered late in the 1.1.3 qualification process. The panic only occurs in clusters with the alpha-quality SDS certificate rotation feature enabled. Since this is the first time we have included SDS certificate rotation in our long-running release tests, we don't know whether this is a latent bug or a new regression. Considering SDS certificate rotation is in alpha, we have decided to release 1.1.3 with this issue and target a fix for the 1.1.4 release.
diff --git a/content/en/boilerplates/notes/1.1.4.md b/content/en/news/2019/announcing-1.1.4/index.md
similarity index 87%
rename from content/en/boilerplates/notes/1.1.4.md
rename to content/en/news/2019/announcing-1.1.4/index.md
index abc90aa20cd7..f2c9c22a7b61 100644
--- a/content/en/boilerplates/notes/1.1.4.md
+++ b/content/en/news/2019/announcing-1.1.4/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.1.4
+description: Istio 1.1.4 patch release.
+publishdate: 2019-04-24
+attribution: The Istio Team
+release: 1.1.4
+aliases:
+ - /about/notes/1.1.4
+ - /blog/2019/announcing-1.1.4
+---
+
+We're pleased to announce the availability of Istio 1.1.4. Please see below for what's changed.
+
+{{< relnote >}}
+
## Behavior change
- Changed the default behavior for Pilot to allow traffic to outside the mesh, even if it is on the same port as an internal service.
diff --git a/content/en/boilerplates/notes/1.1.5.md b/content/en/news/2019/announcing-1.1.5/index.md
similarity index 69%
rename from content/en/boilerplates/notes/1.1.5.md
rename to content/en/news/2019/announcing-1.1.5/index.md
index 6cbb9a2e61bc..18a257738f14 100644
--- a/content/en/boilerplates/notes/1.1.5.md
+++ b/content/en/news/2019/announcing-1.1.5/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.1.5
+description: Istio 1.1.5 patch release.
+publishdate: 2019-05-03
+attribution: The Istio Team
+release: 1.1.5
+aliases:
+ - /about/notes/1.1.5
+ - /blog/2019/announcing-1.1.5
+---
+
+We're pleased to announce the availability of Istio 1.1.5. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Add additional validation to Pilot to reject gateway configuration with overlapping hosts matches ([Issue 13717](https://github.com/istio/istio/issues/13717)).
@@ -8,4 +23,3 @@
- Add additional logging to help diagnose hostname resolution failures ([Issue 13581](https://github.com/istio/istio/issues/13581)).
- Improve ease of installing `prometheus` by removing unnecessary use of `busybox` image ([Issue 13501](https://github.com/istio/istio/issues/13501)).
- Make Pilot Agent's certificate paths configurable ([Issue 11984](https://github.com/istio/istio/issues/11984)).
-
diff --git a/content/en/news/2019/announcing-1.1.6/index.md b/content/en/news/2019/announcing-1.1.6/index.md
new file mode 100644
index 000000000000..4da9a2533319
--- /dev/null
+++ b/content/en/news/2019/announcing-1.1.6/index.md
@@ -0,0 +1,26 @@
+---
+title: Announcing Istio 1.1.6
+description: Istio 1.1.6 patch release.
+publishdate: 2019-05-11
+attribution: The Istio Team
+release: 1.1.6
+aliases:
+ - /about/notes/1.1.6
+ - /blog/2019/announcing-1.1.6
+---
+
+We're pleased to announce the availability of Istio 1.1.6. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Bug fixes
+
+- Fix Galley Helm charts so that the `validatingwebhookconfiguration` object can now deployed to a namespace other than `istio-system` ([Issue 13625](https://github.com/istio/istio/issues/13625)).
+- Additional Helm chart fixes for anti-affinity support: fix `gatewaypodAntiAffinityRequiredDuringScheduling` and `podAntiAffinityLabelSelector` match expressions and fix the default value for `podAntiAffinityLabelSelector` ([Issue 13892](https://github.com/istio/istio/issues/13892)).
+- Make Pilot handle a condition where Envoy continues to request routes for a deleted gateway while listeners are still draining ([Issue 13739](https://github.com/istio/istio/issues/13739)).
+
+## Small enhancements
+
+- If access logs are enabled, `passthrough` listener requests will be logged.
+- Make Pilot tolerate unknown JSON fields to make it easier to rollback to older versions during upgrade.
+- Add support for fallback secrets to `SDS` which Envoy can use instead of waiting indefinitely for late or non-existent secrets during startup ([Issue 13853](https://github.com/istio/istio/issues/13853)).
diff --git a/content/en/boilerplates/notes/1.1.7.md b/content/en/news/2019/announcing-1.1.7/index.md
similarity index 79%
rename from content/en/boilerplates/notes/1.1.7.md
rename to content/en/news/2019/announcing-1.1.7/index.md
index 9884e5131093..79a7baac9f5f 100644
--- a/content/en/boilerplates/notes/1.1.7.md
+++ b/content/en/news/2019/announcing-1.1.7/index.md
@@ -1,6 +1,21 @@
+---
+title: Announcing Istio 1.1.7
+description: Istio 1.1.7 patch release.
+publishdate: 2019-05-17
+attribution: The Istio Team
+release: 1.1.7
+aliases:
+ - /about/notes/1.1.7
+ - /blog/2019/announcing-1.1.7
+---
+
+We're pleased to announce the availability of Istio 1.1.7. Please see below for what's changed.
+
+{{< relnote >}}
+
## Security update
-This release fixes [CVE 2019-12243](/blog/2019/cve-2019-12243).
+This release fixes [CVE 2019-12243](/news/2019/cve-2019-12243).
## Bug fixes
diff --git a/content/en/boilerplates/notes/1.1.8.md b/content/en/news/2019/announcing-1.1.8/index.md
similarity index 86%
rename from content/en/boilerplates/notes/1.1.8.md
rename to content/en/news/2019/announcing-1.1.8/index.md
index ba90a0c9890e..4cb0510e63b5 100644
--- a/content/en/boilerplates/notes/1.1.8.md
+++ b/content/en/news/2019/announcing-1.1.8/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.1.8
+description: Istio 1.1.8 patch release.
+publishdate: 2019-06-06
+attribution: The Istio Team
+release: 1.1.8
+aliases:
+ - /about/notes/1.1.8
+ - /blog/2019/announcing-1.1.8
+---
+
+We're pleased to announce the availability of Istio 1.1.8. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Fix `PASSTHROUGH` `DestinationRules` for CDS clusters ([Issue 13744](https://github.com/istio/istio/issues/13744)).
@@ -17,4 +32,3 @@
- Reduce Pilot log spam by logging the `the endpoints within network ... will be ignored for no network configured` message at `DEBUG`.
- Make it easier to rollback by making pilot-agent ignore unknown flags.
- Update Citadel's default root CA certificate TTL from 1 year to 10 years.
-
diff --git a/content/en/boilerplates/notes/1.1.9.md b/content/en/news/2019/announcing-1.1.9/index.md
similarity index 66%
rename from content/en/boilerplates/notes/1.1.9.md
rename to content/en/news/2019/announcing-1.1.9/index.md
index 64036105fc14..833b0e545ca1 100644
--- a/content/en/boilerplates/notes/1.1.9.md
+++ b/content/en/news/2019/announcing-1.1.9/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.1.9
+description: Istio 1.1.9 patch release.
+publishdate: 2019-06-17
+attribution: The Istio Team
+release: 1.1.9
+aliases:
+ - /about/notes/1.1.9
+ - /blog/2019/announcing-1.1.9
+---
+
+We're pleased to announce the availability of Istio 1.1.9. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Prevent overly large strings from being sent to Prometheus ([Issue 14642](https://github.com/istio/istio/issues/14642)).
diff --git a/content/en/boilerplates/notes/1.1.md b/content/en/news/2019/announcing-1.1/index.md
similarity index 73%
rename from content/en/boilerplates/notes/1.1.md
rename to content/en/news/2019/announcing-1.1/index.md
index b905d9935995..26c258417f4d 100644
--- a/content/en/boilerplates/notes/1.1.md
+++ b/content/en/news/2019/announcing-1.1/index.md
@@ -1,10 +1,87 @@
-## Incompatible changes from 1.0
+---
+title: Announcing Istio 1.1
+subtitle: Major Update
+description: Istio 1.1 release announcement.
+publishdate: 2019-03-19
+attribution: The Istio Team
+release: 1.1.0
+aliases:
+ - /about/notes/1.1
+ - /blog/2019/announcing-1.1
+---
+
+We are pleased to announce the release of Istio 1.1!
+
+{{< relnote >}}
+
+Since we released 1.0 back in July, we’ve done a lot of work to help people get
+into production. Not surprisingly, we had to do some [patch releases](/news)
+(6 so far!), but we’ve also been hard at work adding new features to the
+product.
+
+The theme for 1.1 is Enterprise Ready. We’ve been very pleased to see more and
+more companies using Istio in production, but as some larger companies tried to
+adopt Istio they hit some limits.
+
+One of our prime areas of focus has been [performance and scalability](/docs/concepts/performance-and-scalability/).
+As people moved into production with larger clusters running more services at
+higher volume, they hit some scaling and performance issues. The
+[sidecars](/docs/concepts/traffic-management/#sidecars) took too many resources
+and added too much latency. The control plane (especially
+[Pilot](/docs/concepts/traffic-management/#pilot)) was overly
+resource hungry.
+
+We’ve done a lot of work to make both the data plane and the control plane more
+efficient. You can find the details of our 1.1 performance testing and the
+results in our updated [performance ans scalability concept](/docs/concepts/performance-and-scalability/).
+
+We’ve done work around namespace isolation as well. This lets you use
+Kubernetes namespaces to enforce boundaries of control, and ensures that your
+teams cannot interfere with each other.
+
+We have also improved the [multicluster capabilities and usability](/docs/concepts/deployment-models/).
+We listened to the community and improved defaults for traffic control and
+policy. We introduced a new component called
+[Galley](/docs/concepts/what-is-istio/#galley). Galley validates that sweet,
+sweet YAML, reducing the chance of configuration errors. Galley will also be
+instrumental in [multicluster setups](/docs/setup/install/multicluster/),
+gathering service discovery information from each Kubernetes cluster. We are
+also supporting additional multicluster topologies including different
+[control plane models](/docs/concepts/deployment-models/#control-plane-models)
+topologies without requiring a flat network.
+
+There is lots more -- see the [release notes](/news/2019/announcing-1.1/) for complete
+details.
+
+There is more going on in the project as well. We know that Istio has a lot of
+moving parts and can be a lot to take on. To help address that, we recently
+formed a [Usability Working Group](https://github.com/istio/community/blob/master/WORKING-GROUPS.md#working-group-meetings)
+(feel free to join). There is also a lot happening in the [Community
+Meeting](https://github.com/istio/community#community-meeting) (Thursdays at
+`11 a.m.`) and in the [Working
+Groups](https://github.com/istio/community/blob/master/WORKING-GROUPS.md). And
+if you haven’t yet joined the conversation at
+[discuss.istio.io](https://discuss.istio.io), head over, log in with your
+GitHub credentials and join us!
+
+We are grateful to everyone who has worked hard on Istio over the last few
+months -- patching 1.0, adding features to 1.1, and, lately, doing tons of
+testing on 1.1. Thanks especially to those companies and users who worked with
+us installing and upgrading to the early builds and helping us catch problems
+before the release.
+
+So: now’s the time! Grab 1.1, check out [the updated documentation](/docs/),
+[install it](/docs/setup/) and...happy meshing!
+
+## Release notes
+
+### Incompatible changes from 1.0
In addition to the new features and improvements listed below, Istio 1.1 has introduced
a number of significant changes from 1.0 that can alter the behavior of applications.
A concise list of these changes can be found in the [upgrade notice](/docs/setup/upgrade/notice).
-## Upgrades
+### Upgrades
We recommend a manual upgrade of the control plane and data plane to 1.1. See
the [upgrades documents](/docs/setup/upgrade/) for more information.
@@ -14,7 +91,7 @@ Be sure to check out the [upgrade notice](/docs/setup/upgrade/notice) for a
concise list of things you should know before upgrading your deployment to Istio 1.1.
{{< /warning >}}
-## Installation
+### Installation
- **CRD Install Separated from Istio Install**. Placed Istio’s Custom Resource
Definitions (CRDs) into the `istio-init` Helm chart. Placing the CRDs in
@@ -33,7 +110,7 @@ concise list of things you should know before upgrading your deployment to Istio
[multicluster split horizon](/docs/setup/install/multicluster/shared-gateways/) remote cluster installation
into the Istio Helm chart simplifying the operational experience.
-## Traffic management
+### Traffic management
- **New `Sidecar` Resource**. The new [sidecar](/docs/concepts/traffic-management/#sidecars) resource
enables more fine-grained control over the behavior of the sidecar proxies attached to workloads within a namespace.
@@ -83,7 +160,7 @@ concise list of things you should know before upgrading your deployment to Istio
- **Access Logging Off by Default**. Disabled the access logs for all Envoy
sidecars by default to improve performance.
-## Security
+### Security
- **Readiness and Liveness Probes**. Added support for Kubernetes' HTTP
[readiness and liveness probes](/faq/security/#k8s-health-checks) when
@@ -116,7 +193,7 @@ concise list of things you should know before upgrading your deployment to Istio
- **Customized (non `cluster.local`) Trust Domains**. Added support for
organization- or cluster-specific trust domains in the identities.
-## Policies and telemetry
+### Policies and telemetry
- **Policy Checks Off By Default**. Changed policy checks to be turned off by
default to improve performance for most customer scenarios. [Enabling Policy Enforcement](/docs/tasks/policy-enforcement/enabling-policy/)
@@ -173,7 +250,7 @@ concise list of things you should know before upgrading your deployment to Istio
collector. Istio now supports bring your own `statsd` for
improved flexibility with existing Kubernetes deployments.
-## Configuration management
+### Configuration management
- **Galley**. Added [Galley](/docs/concepts/what-is-istio/#galley) as the
primary configuration ingestion and distribution mechanism within Istio. It
@@ -185,7 +262,7 @@ concise list of things you should know before upgrading your deployment to Istio
- **Monitoring Port**. Changed Galley's default monitoring port from 9093 to
15014.
-## `istioctl` and `kubectl`
+### `istioctl` and `kubectl`
- **Validate Command**. Added the [`istioctl validate`](/docs/reference/commands/istioctl/#istioctl-validate)
command for offline validation of Istio Kubernetes resources.
diff --git a/content/en/boilerplates/notes/1.2.1.md b/content/en/news/2019/announcing-1.2.1/index.md
similarity index 77%
rename from content/en/boilerplates/notes/1.2.1.md
rename to content/en/news/2019/announcing-1.2.1/index.md
index 831a64ef52fd..cf2e96c14fd6 100644
--- a/content/en/boilerplates/notes/1.2.1.md
+++ b/content/en/news/2019/announcing-1.2.1/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.2.1
+description: Istio 1.2.1 patch release.
+publishdate: 2019-06-27
+attribution: The Istio Team
+release: 1.2.1
+aliases:
+ - /about/notes/1.2.1
+ - /blog/2019/announcing-1.2.1
+---
+
+We're pleased to announce the availability of Istio 1.2.1. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Fix duplicate CRD being generated in the install ([Issue 14976](https://github.com/istio/istio/issues/14976))
diff --git a/content/en/news/2019/announcing-1.2.2/index.md b/content/en/news/2019/announcing-1.2.2/index.md
new file mode 100644
index 000000000000..9b5df5a9ccb5
--- /dev/null
+++ b/content/en/news/2019/announcing-1.2.2/index.md
@@ -0,0 +1,19 @@
+---
+title: Announcing Istio 1.2.2
+description: Istio 1.2.2 patch release.
+publishdate: 2019-06-28
+attribution: The Istio Team
+release: 1.2.2
+aliases:
+ - /about/notes/1.2.2
+ - /blog/2019/announcing-1.2.2
+---
+
+We're pleased to announce the availability of Istio 1.2.2. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Bug fixes
+
+- Fix crash in Istio's JWT Envoy filter caused by malformed JWT ([Issue 15084](https://github.com/istio/istio/issues/15084))
+- Fix incorrect overwrite of x-forwarded-proto header ([Issue 15124](https://github.com/istio/istio/issues/15124))
diff --git a/content/en/boilerplates/notes/1.2.3.md b/content/en/news/2019/announcing-1.2.3/index.md
similarity index 77%
rename from content/en/boilerplates/notes/1.2.3.md
rename to content/en/news/2019/announcing-1.2.3/index.md
index a008f21cfc6e..3ec5416a9e5e 100644
--- a/content/en/boilerplates/notes/1.2.3.md
+++ b/content/en/news/2019/announcing-1.2.3/index.md
@@ -1,3 +1,18 @@
+---
+title: Announcing Istio 1.2.3
+description: Istio 1.2.3 patch release.
+publishdate: 2019-08-02
+attribution: The Istio Team
+release: 1.2.3
+aliases:
+ - /about/notes/1.2.3
+ - /blog/2019/announcing-1.2.3
+---
+
+We're pleased to announce the availability of Istio 1.2.3. Please see below for what's changed.
+
+{{< relnote >}}
+
## Bug fixes
- Fix a bug where the sidecar could infinitely forward requests to itself when pod defines a port undefined for service ([Issue 14443](https://github.com/istio/istio/issues/14443)) and ([Issue 14242](https://github.com/istio/istio/issues/14242))
diff --git a/content/en/boilerplates/notes/1.1.13.md b/content/en/news/2019/announcing-1.2.4/index.md
similarity index 84%
rename from content/en/boilerplates/notes/1.1.13.md
rename to content/en/news/2019/announcing-1.2.4/index.md
index a280ff76783f..125de33a85c0 100644
--- a/content/en/boilerplates/notes/1.1.13.md
+++ b/content/en/news/2019/announcing-1.2.4/index.md
@@ -1,6 +1,21 @@
+---
+title: Announcing Istio 1.2.4
+description: Istio 1.2.4 patch release.
+publishdate: 2019-08-13
+attribution: The Istio Team
+release: 1.2.4
+aliases:
+ - /about/notes/1.2.4
+ - /blog/2019/announcing-1.2.4
+---
+
+We're pleased to announce the availability of Istio 1.2.4. Please see below for what's changed.
+
+{{< relnote >}}
+
## Security update
-This release contains fixes for the security vulnerabilities described in [our August 13th, 2019 blog post](/blog/2019/istio-security-003-004/). Specifically:
+This release contains fixes for the security vulnerabilities described in [our August 13th, 2019 news post](/news/2019/istio-security-003-004/). Specifically:
__ISTIO-SECURITY-2019-003__: An Envoy user reported publicly an issue (c.f. [Envoy Issue 7728](https://github.com/envoyproxy/envoy/issues/7728)) about regular expressions matching that crashes Envoy with very large URIs.
* __[CVE-2019-14993](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14993)__: After investigation, the Istio team has found that this issue could be leveraged for a DoS attack in Istio, if users are employing regular expressions in some of the Istio APIs: `JWT`, `VirtualService`, `HTTPAPISpecBinding`, `QuotaSpecBinding`.
diff --git a/content/en/boilerplates/notes/1.2.5.md b/content/en/news/2019/announcing-1.2.5/index.md
similarity index 68%
rename from content/en/boilerplates/notes/1.2.5.md
rename to content/en/news/2019/announcing-1.2.5/index.md
index c7c3b533512b..60a8774fad06 100644
--- a/content/en/boilerplates/notes/1.2.5.md
+++ b/content/en/news/2019/announcing-1.2.5/index.md
@@ -1,6 +1,21 @@
+---
+title: Announcing Istio 1.2.5
+description: Istio 1.2.5 patch release.
+publishdate: 2019-08-26
+attribution: The Istio Team
+release: 1.2.5
+aliases:
+ - /about/notes/1.2.5
+ - /blog/2019/announcing-1.2.5
+---
+
+We're pleased to announce the availability of Istio 1.2.5. Please see below for what's changed.
+
+{{< relnote >}}
+
## Security update
-Following the previous fixes for the security vulnerabilities described in [our August 13th, 2019 blog post](/blog/2019/istio-security-003-004/), we are now addressing the internal control plane communication surface. These security fixes were not available at the time of our previous security release, and we considered the control plane gRPC surface to be harder to exploit.
+Following the previous fixes for the security vulnerabilities described in [our August 13th, 2019 news post](/news/2019/istio-security-003-004/), we are now addressing the internal control plane communication surface. These security fixes were not available at the time of our previous security release, and we considered the control plane gRPC surface to be harder to exploit.
You can find the gRPC vulnerability fix description on their mailing list (c.f.
[HTTP/2 Security Vulnerabilities](https://groups.google.com/forum/#!topic/grpc-io/w5jPamxdda4)).
diff --git a/content/en/news/2019/announcing-1.2.6/index.md b/content/en/news/2019/announcing-1.2.6/index.md
new file mode 100644
index 000000000000..78571637a119
--- /dev/null
+++ b/content/en/news/2019/announcing-1.2.6/index.md
@@ -0,0 +1,28 @@
+---
+title: Announcing Istio 1.2.6
+description: Istio 1.2.6 patch release.
+publishdate: 2019-09-17
+attribution: The Istio Team
+release: 1.2.6
+aliases:
+ - /about/notes/1.2.6
+ - /blog/2019/announcing-1.2.6
+---
+
+We're pleased to announce the availability of Istio 1.2.6. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Bug fixes
+
+- Fix `redisquota` inconsistency in regards to `memquota` counting ([Issue 15543](https://github.com/istio/istio/issues/15543)).
+- Fix an Envoy crash introduced in Istio 1.2.5 ([Issue 16357](https://github.com/istio/istio/issues/16357)).
+- Fix Citadel health check broken in the context of plugin certs (with intermediate certs) ([Issue 16593](https://github.com/istio/istio/issues/16593)).
+- Fix Stackdriver Mixer Adapter error log verbosity ([Issue 16782](https://github.com/istio/istio/issues/16782)).
+- Fix a bug where the service account map would be erased for service hostnames with more than one port.
+- Fix incorrect `filterChainMatch` wildcard hosts duplication produced by Pilot ([Issue 16573](https://github.com/istio/istio/issues/16573)).
+
+## Small enhancements
+
+- Expose `sidecarToTelemetrySessionAffinity` (required for Mixer V1) when it talks to services like Stackdriver. ([Issue 16862](https://github.com/istio/istio/issues/16862)).
+- Expose `HTTP/2` window size settings as Pilot environment variables ([Issue 17117](https://github.com/istio/istio/issues/17117)).
diff --git a/content/en/news/2019/announcing-1.2.7/index.md b/content/en/news/2019/announcing-1.2.7/index.md
new file mode 100644
index 000000000000..a7da62d529b7
--- /dev/null
+++ b/content/en/news/2019/announcing-1.2.7/index.md
@@ -0,0 +1,23 @@
+---
+title: Announcing Istio 1.2.7
+description: Istio 1.2.7 patch release.
+publishdate: 2019-10-08
+attribution: The Istio Team
+release: 1.2.7
+---
+
+We're pleased to announce the availability of Istio 1.2.7. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Security update
+
+This release contains fixes for the security vulnerability described in [our October 8th, 2019 news post](/news/2019/istio-security-2019-005). Specifically:
+
+__ISTIO-SECURITY-2019-005__: A DoS vulnerability has been discovered by the Envoy community.
+ * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: After investigation, the Istio team has found that this issue could be leveraged for a DoS attack in Istio if an attacker uses a high quantity of very small headers.
+
+## Bug fix
+
+- Fix a bug where `nodeagent` was failing to start when using citadel ([Issue 15876](https://github.com/istio/istio/issues/17108))
+
diff --git a/content/en/boilerplates/notes/1.2.md b/content/en/news/2019/announcing-1.2/index.md
similarity index 64%
rename from content/en/boilerplates/notes/1.2.md
rename to content/en/news/2019/announcing-1.2/index.md
index 53cda4c994b2..417dcee556de 100644
--- a/content/en/boilerplates/notes/1.2.md
+++ b/content/en/news/2019/announcing-1.2/index.md
@@ -1,10 +1,83 @@
-
-## General
+---
+title: Announcing Istio 1.2
+subtitle: Major Update
+description: Istio 1.2 release announcement.
+publishdate: 2019-06-18
+attribution: The Istio Team
+release: 1.2.0
+aliases:
+ - /about/notes/1.2
+ - /blog/2019/announcing-1.2
+---
+
+We are pleased to announce the release of Istio 1.2!
+
+{{< relnote >}}
+
+The theme of 1.2 is Predictable Releases - predictable in quality (we want
+every release to be a good release) as well as in time (we want to be able
+to ship on well known schedules).
+
+As nearly anyone using Istio 1.0 noticed, it took us a long time to get 1.1
+out. Far too long. One of the reasons was that we needed to do some work on
+our testing and infrastructure -- it was simply far too manual a process to
+build, test and release. Because of that, 1.2 focuses on improving the
+stability of these new features, and improving general product health.
+
+In order to make release quality and timing predictable, we declared a
+"Code Mauve", meaning that we would spend the next iteration focusing on
+project infrastructure. As a result, we’ve been investing a ton of effort
+in our build, test and release machinery.
+
+We formed 3 new teams (GitHub Workflow, Source Organization, Testing
+Methodology, and Build & Release Automation). Each had a set of issues to
+take on and a set of exit criteria. Code Mauve isn’t over yet, in fact we
+expect it to go
+on for some time. We’re putting in place the infrastructure to measure the
+metrics each team decided on (paraphrasing Peter Drucker: if you can’t
+measure it, you can’t manage it).
+
+You might have noticed that the [patch releases](/news/) for 1.1 have
+been coming fast and furious.
+
+In order to get features in the hands of our customers and users as soon as
+possible, most of the new features from the last three months have been
+delivered in 1.1.x releases. With 1.2, those features are now officially
+part of the release.
+
+We're seeing early results from the usability group. In the release notes,
+you'll find that you can now set log levels for the control plane and the
+data plane globally. You can use [`istioctl`](/docs/reference/commands/istioctl) to validate that your Kubernetes
+installation meets Istio's requirements. And the new
+`traffic.sidecar.istio.io/includeInboundPorts` annotation to eliminate the
+need for service owner to declare `containerPort` in the deployment yaml.
+
+Some of the features have matured as well. The following features have
+progressed from Beta status
+to Stable: SNI at ingress, distributed tracing, and service tracing. The
+following features have reached beta status: cert management on ingress,
+configuration resource validation, and configuration processing with Galley.
+We know there are lots of feature requests outstanding, and we have an
+exciting roadmap (watch for a forthcoming post from the TOC on that). The
+work we have done in this release has taken care of some technical debt which
+will help us get those features out reliably in future.
+
+As always, there is also a lot happening in the [Community
+Meeting](https://github.com/istio/community#community-meeting) (Thursdays at
+`11 a.m. Pactific`) and in the [Working
+Groups](https://github.com/istio/community/blob/master/WORKING-GROUPS.md). And
+if you haven’t yet joined the conversation at
+[discuss.istio.io](https://discuss.istio.io), head over, log in with your
+GitHub credentials and join us!
+
+## Release notes
+
+### General
- **Added** `traffic.sidecar.istio.io/includeInboundPorts` annotation to eliminate the need for service owner to declare `containerPort` in the deployment yaml file. This will become the default in a future release.
- **Added** IPv6 experimental support for Kubernetes clusters.
-## Traffic Management
+### Traffic management
- **Improved** [locality based routing](/docs/ops/traffic-management/locality-load-balancing/) in multicluster environments.
- **Improved** outbound traffic policy in [`ALLOW_ANY` mode](/docs/reference/config/installation-options/#global-options). Traffic for unknown HTTP/HTTPS hosts on an existing port will be [forwarded as is](/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services). Unknown traffic will be logged in Envoy access logs.
@@ -13,7 +86,7 @@
- **Added** ability to configure the [DNS refresh rate](/docs/reference/config/installation-options/#global-options) for sidecar Envoys, to reduce the load on the DNS servers.
- **Graduated** [Sidecar API](/docs/reference/config/networking/v1alpha3/sidecar/) from Alpha to Alpha API and Beta runtime.
-## Security
+### Security
- **Improved** extend the default lifetime of self-signed Citadel root certificates to 10 years.
- **Added** Kubernetes health check prober rewrite per deployment via `sidecar.istio.io/rewriteAppHTTPProbers: "true"` in the `PodSpec` [annotation](/docs/ops/app-health-check/#use-annotations-on-pod).
@@ -25,24 +98,24 @@
- **Graduated** [SNI with multiple certificates support at ingress gateway](/docs/reference/config/networking/v1alpha3/gateway/) from Alpha to Stable.
- **Graduated** [certification management on Ingress Gateway](/docs/tasks/traffic-management/ingress/secure-ingress-sds/) from Alpha to Beta.
-## Telemetry
+### Telemetry
- **Added** Full support for control over Envoy stats generation, based on stats prefixes, suffixes, and regular expressions through the use of annotations.
- **Changed** Prometheus generated traffic is excluded from metrics.
- **Added** support for sending traces to Datadog.
- **Graduated** [distributed tracing](/docs/tasks/telemetry/distributed-tracing/) from Beta to Stable.
-## Policy
+### Policy
- **Fixed** [Mixer based](https://github.com/istio/istio/issues/13868)TCP Policy enforcement.
- **Graduated** [Authorization (RBAC)](/docs/reference/config/authorization/istio.rbac.v1alpha1/) from Alpha to Alpha API and Beta runtime.
-## Configuration Management
+### Configuration management
- **Improved** validation of Policy & Telemetry CRDs.
- **Graduated** basic configuration resource validation from Alpha to Beta.
-## Installation and Upgrade
+### Installation and upgrade
- **Updated** default proxy memory limit size(`global.proxy.resources.limits.memory`) from `128Mi` to `1024Mi` to ensure proxy has sufficient memory.
- **Added** pod [anti-affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) and [toleration](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) support to all of our control plane components.
@@ -53,7 +126,7 @@
Refer to the [installation option change page](/docs/reference/config/installation-options-changes/) to view the complete list of changes.
-## `istioctl` and `kubectl`
+### `istioctl` and `kubectl`
- **Graduated** `istioctl verify-install` out of experimental.
- **Improved** `istioctl verify-install` to validate if a given Kubernetes environment meets Istio's prerequisites.
@@ -63,7 +136,7 @@ Refer to the [installation option change page](/docs/reference/config/installati
- **Improved** `istioctl version` to report both Istio control plane and `istioctl` version info by default.
- **Improved** `istioctl validate` to validate Mixer configuration and supports deep validation with referential integrity.
-## Others
+### Others
- **Added** [Istio CNI support](/docs/setup/additional-setup/cni/) to setup sidecar network redirection and remove the use of `istio-init` containers requiring `NET_ADMIN` capability.
- **Added** a new experimental ['a-la-carte' Istio installer](https://github.com/istio/installer/wiki) to enable users to install and upgrade Istio with desired isolation and security.
diff --git a/content/en/news/2019/announcing-1.3.1/index.md b/content/en/news/2019/announcing-1.3.1/index.md
new file mode 100644
index 000000000000..fc3e5399358a
--- /dev/null
+++ b/content/en/news/2019/announcing-1.3.1/index.md
@@ -0,0 +1,32 @@
+---
+title: Announcing Istio 1.3.1
+description: Istio 1.3.1 release announcement.
+publishdate: 2019-09-27
+attribution: The Istio Team
+subtitle: Minor Update
+release: 1.3.1
+---
+
+This release includes bug fixes to improve robustness. This release note describes what’s different between Istio 1.3.0 and Istio 1.3.1.
+
+{{< relnote >}}
+
+## Bug fixes
+
+- **Fixed** an issue which caused the secret cleanup job to erroneously run during upgrades ([Issue 16873](https://github.com/istio/istio/issues/16873)).
+- **Fixed** an issue where the default configuration disabled Kubernetes Ingress support ([Issue 17148](https://github.com/istio/istio/issues/17148))
+- **Fixed** an issue with handling invalid `UTF-8` characters in the Stackdriver logging adapter ([Issue 16966](https://github.com/istio/istio/issues/16966)).
+- **Fixed** an issue which caused the `destination_service` label in HTTP metrics not to be set for `BlackHoleCluster` and `PassThroughCluster` ([Issue 16629](https://github.com/istio/istio/issues/16629)).
+- **Fixed** an issue with the `destination_service` label in the `istio_tcp_connections_closed_total` and `istio_tcp_connections_opened_total` metrics which caused them to not be set correctly ([Issue 17234](https://github.com/istio/istio/issues/17234)).
+- **Fixed** an Envoy crash introduced in Istio 1.2.4 ([Issue 16357](https://github.com/istio/istio/issues/16357)).
+- **Fixed** Istio CNI sidecar initialization when IPv6 is disabled on the node ([Issue 15895](https://github.com/istio/istio/issues/15895)).
+- **Fixed** a regression affecting support of RS384 and RS512 algorithms in JWTs ([Issue 15380](https://github.com/istio/istio/issues/15380)).
+
+## Minor enhancements
+
+- **Added** support for `.Values.global.priorityClassName` to the telemetry deployment.
+- **Added** annotations for Datadog tracing that controls extra features in sidecars.
+- **Added** the `pilot_xds_push_time` metric to report Pilot xDS push time.
+- **Added** `istioctl experimental analyze` to support multi-resource analysis and validation.
+- **Added** support for running metadata exchange and stats extensions in a WebAssembly sandbox. Follow [these](/docs/ops/telemetry/in-proxy-service-telemetry/) instructions to try it out.
+- **Removed** time diff info in the proxy-status command.
diff --git a/content/en/news/2019/announcing-1.3.2/index.md b/content/en/news/2019/announcing-1.3.2/index.md
new file mode 100644
index 000000000000..7caa8979ca9d
--- /dev/null
+++ b/content/en/news/2019/announcing-1.3.2/index.md
@@ -0,0 +1,20 @@
+---
+title: Announcing Istio 1.3.2
+description: Istio 1.3.2 patch release.
+publishdate: 2019-10-08
+attribution: The Istio Team
+release: 1.3.2
+---
+
+We're pleased to announce the availability of Istio 1.3.2. Please see below for what's changed.
+
+{{< relnote >}}
+
+## Security update
+
+This release contains fixes for the security vulnerability described in [our October 8th, 2019 news post](/news/2019/istio-security-2019-005). Specifically:
+
+__ISTIO-SECURITY-2019-005__: A DoS vulnerability has been discovered by the Envoy community.
+ * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: After investigation, the Istio team has found that this issue could be leveraged for a DoS attack in Istio if an attacker uses a high quantity of very small headers.
+
+Nothing else is included in this release except for the above security fix.
diff --git a/content/en/news/2019/announcing-1.3.3/index.md b/content/en/news/2019/announcing-1.3.3/index.md
new file mode 100644
index 000000000000..a6b45d282deb
--- /dev/null
+++ b/content/en/news/2019/announcing-1.3.3/index.md
@@ -0,0 +1,21 @@
+---
+title: Announcing Istio 1.3.3
+description: Istio 1.3.3 release announcement.
+publishdate: 2019-10-14
+attribution: The Istio Team
+subtitle: Minor Update
+release: 1.3.3
+---
+
+This release includes bug fixes to improve robustness. This release note describes what's different between Istio 1.3.2 and Istio 1.3.3.
+
+{{< relnote >}}
+
+## Bug fixes
+
+- **Fixed** an issue which caused Prometheus to install improperly when using `istioctl x manifest apply`. ([Issue 16970](https://github.com/istio/istio/issues/16970))
+- **Fixed** a bug where locality load balancing can not read locality information from the node. ([Issue 17337](https://github.com/istio/istio/issues/17337))
+- **Fixed** a bug where long-lived connections were getting dropped by the Envoy proxy as the listeners were getting reconfigured without any user configuration changes. ([Issue 17383](https://github.com/istio/istio/issues/17383), [Issue 17139](https://github.com/istio/istio/issues/17139))
+- **Fixed** a crash in `istioctl x analyze` command. ([Issue 17449](https://github.com/istio/istio/issues/17449))
+- **Fixed** `istioctl x manifest diff` to diff text blocks in ConfigMaps. ([Issue 16828](https://github.com/istio/istio/issues/16828))
+- **Fixed** a segmentation fault crash in the Envoy proxy. ([Issue 17699](https://github.com/istio/istio/issues/17699))
diff --git a/content/en/boilerplates/notes/1.3.md b/content/en/news/2019/announcing-1.3/index.md
similarity index 53%
rename from content/en/boilerplates/notes/1.3.md
rename to content/en/news/2019/announcing-1.3/index.md
index ccd988092f23..d620cfbd24a8 100644
--- a/content/en/boilerplates/notes/1.3.md
+++ b/content/en/news/2019/announcing-1.3/index.md
@@ -1,10 +1,85 @@
-## Installation
+---
+title: Announcing Istio 1.3
+subtitle: Major Update
+description: Istio 1.3 release announcement.
+publishdate: 2019-09-12
+attribution: The Istio Team
+release: 1.3.0
+aliases:
+ - /about/notes/1.3
+ - /blog/2019/announcing-1.3
+---
+
+We are pleased to announce the release of Istio 1.3!
+
+{{< relnote >}}
+
+The theme of Istio 1.3 is User Experience:
+
+- Improve the experience of new users adopting Istio
+- Improve the experience of users debugging problems
+- Support more applications without any additional configuration
+
+Every few releases, the Istio team delivers dramatic improvements to usability, APIs, and the overall system performance. Istio 1.3 is one such release, and the team is very excited to roll out some key updates.
+
+## Intelligent protocol detection (experimental)
+
+To take advantage of Istio's routing features, service ports must use a special port naming format to explicitly declare the protocol. This requirement can cause problems for users that do not name their ports when they add their applications to the mesh. Starting with 1.3, the protocol for outbound traffic is automatically detected as HTTP or TCP when the ports are not named according to Istio's conventions. We will be polishing this feature in the upcoming releases with support for protocol sniffing on inbound traffic as well as identifying protocols other than HTTP.
+
+## Mixer-less telemetry (experimental)
+
+Yes, you read that right! We implemented most of the common security policies, such as RBAC, directly into Envoy. We previously turned off the `istio-policy` service by default and are now on track to migrate most of Mixer's telemetry functionality into Envoy as well. In this release, we have enhanced the Istio proxy to emit HTTP metrics directly to Prometheus, without requiring the `istio-telemetry` service to enrich the information. This enhancement is great if all you care about is telemetry for HTTP services. Follow the [Mixer-less HTTP telemetry instructions](https://github.com/istio/istio/wiki/Mixerless-HTTP-Telemetry) to experiment with this feature. We are polishing this feature in the coming months to add telemetry support for TCP services when you enable Istio mutual TLS.
+
+## Container ports are no longer required
+
+Previous releases required that pods explicitly declare the Kubernetes `containerPort` for each container as a security measure against trampolining traffic. Istio 1.3 has a secure and simpler way of handling all inbound traffic on any port into a {{< gloss >}}workload instance{{< /gloss >}} without requiring the `containerPort` declarations. We have also completely eliminated the infinite loops caused in the IP tables rules when workload instances send traffic to themselves.
+
+## Fully customize generated Envoy configuration
+
+While Istio 1.3 focuses on usability, expert users can use advanced features in Envoy that are not part of the Istio Networking APIs. We enhanced the `EnvoyFilter` API to allow users to fully customize:
+
+- The HTTP/TCP listeners and their filter chains returned by LDS
+- The Envoy HTTP route configuration returned by the RDS
+- The set of clusters returned by CDS
+
+You get the best of both worlds:
+
+Leverage Istio to integrate with Kubernetes and handle large fleets of Envoys in an efficient manner, while you still can customize the generated Envoy configuration to meet specific requirements within your infrastructure.
+
+## Other enhancements
+
+- `istioctl` gained many debugging features to help you highlight various issues in your mesh installation. Checkout the `istioctl` [reference page](/docs/reference/commands/istioctl/) for the set of all supported features.
+
+- Locality aware load balancing graduated from experimental to default in this release too. Istio now takes advantage of existing locality information to prioritize load balancing pools and favor sending requests to the closest backends.
+
+- Better support for headless services with Istio mutual TLS
+
+- We enhanced control plane monitoring in the following ways:
+
+ - Added new metrics to monitor configuration state
+ - Added metrics for sidecar injector
+ - Added a new Grafana dashboard for Citadel
+ - Improved the Pilot dashboard to expose additional key metrics
+
+- Added the new [Istio Deployment Models concept](/docs/concepts/deployment-models/) to help you decide what deployment model suits your needs.
+
+- Organized the content in of our [Operations Guide](/docs/ops/) and created a [section with all troubleshooting tasks](/docs/ops/troubleshooting) to help you find the information you seek faster.
+
+As always, there is a lot happening in the [Community Meeting](https://github.com/istio/community#community-meeting); join us every other Thursday at 11 AM Pacific.
+
+The growth and success of Istio is due to its 400+ contributors from over 300 companies. Join one of our [Working Groups](https://github.com/istio/community/blob/master/WORKING-GROUPS.md) and help us make Istio even better.
+
+To join the conversation, go to [discuss.istio.io](https://discuss.istio.io), log in with your GitHub credentials and join us!
+
+## Release notes
+
+### Installation
- **Added** experimental [manifest and profile commands](/docs/setup/install/operator/) to install and manage the Istio control plane for evaluation.
-## Traffic management
+### Traffic management
-- **Added** [automatic determination](/docs/ops/traffic-management/protocol-selection/) of protocol types. You no longer need to explicitly prefix service ports with their protocol type.
+- **Added** [automatic determination](/docs/ops/traffic-management/protocol-selection/) of HTTP or TCP for outbound traffic when ports are not named according to Istio’s [conventions](/docs/setup/additional-setup/requirements/).
- **Added** a mode to the Gateway API for mutual TLS operation.
- **Fixed** issues present when a service communicates over the network first in permissive mutual TLS mode for protocols like MySQL and MongoDB.
- **Improved** Envoy proxy readiness checks. They now check Envoy's readiness status.
@@ -16,7 +91,7 @@
- **Improved** the `ServiceEntry` API to allow for the same hostname in different namespaces.
- **Improved** the [Sidecar API](/docs/reference/config/networking/v1alpha3/sidecar/#OutboundTrafficPolicy) to customize the `OutboundTrafficPolicy` policy.
-## Security
+### Security
- **Added** trust domain validation for services using mutual TLS. By default, the server only authenticates the requests from the same trust domain.
- **Added** [labels](/docs/concepts/security/#how-citadel-determines-whether-to-create-service-account-secrets) to control service account secret generation by namespace.
@@ -31,7 +106,7 @@
- **Removed** integration with Vault CA temporarily. SDS requirements caused the temporary removal but we will reintroduce Vault CA integration in a future release.
- **Enabled** the Envoy JWT filter by default to improve security and reliability.
-## Telemetry
+### Telemetry
- **Added** Access Log Service [ALS](https://www.envoyproxy.io/docs/envoy/latest/api-v2/service/accesslog/v2/als.proto#grpc-access-log-service-als) support for Envoy gRPC.
- **Added** a Grafana dashboard for Citadel monitoring.
@@ -46,19 +121,18 @@
- **Improved** the mesh dashboard to provide monitoring of Istio's configuration state.
- **Improved** the Pilot dashboard to expose additional key metrics to more clearly identify errors.
- **Removed** deprecated `Adapter` and `Template` custom resource definitions (CRDs).
-- **Deprecated** Mixer adapters. Please begin the transition of all extensions to the new extension model. Legacy Mixer integration support continues only for Istio 1.3 and 1.4.
- **Deprecated** the HTTP API spec used to produce API attributes. We will remove support for producing API attributes in Istio 1.4.
-## Policy
+### Policy
- **Improved** rate limit enforcement to allow communication when the quota backend is unavailable.
-## Configuration management
+### Configuration management
- **Fixed** Galley to stop too many gRPC pings from closing connections.
- **Improved** Galley to avoid control plane upgrade failures.
-## `istioctl`
+### `istioctl`
- **Added** [`istioctl experimental manifest`](/docs/reference/commands/istioctl/#istioctl-experimental-manifest) to manage the new experimental install manifests.
- **Added** [`istioctl experimental profile`](/docs/reference/commands/istioctl/#istioctl-experimental-profile) to manage the new experimental install profiles.
@@ -69,7 +143,7 @@
- **Promoted** the [`istioctl experimental convert-ingress`](/docs/reference/commands/istioctl/#istioctl-convert-ingress) command to `istioctl convert-ingress`.
- **Promoted** the [`istioctl experimental dashboard`](/docs/reference/commands/istioctl/#istioctl-dashboard) command to `istioctl dashboard`.
-## Other
+### Other
- **Added** new images based on [distroless](/docs/ops/security/harden-docker-images/) base images.
- **Improved** the Istio CNI Helm chart to have consistent versions with Istio.
diff --git a/content/en/blog/2019/announcing-discuss.istio.io/index.md b/content/en/news/2019/announcing-discuss.istio.io/index.md
similarity index 96%
rename from content/en/blog/2019/announcing-discuss.istio.io/index.md
rename to content/en/news/2019/announcing-discuss.istio.io/index.md
index 072ef8e25570..e74accbcb579 100644
--- a/content/en/blog/2019/announcing-discuss.istio.io/index.md
+++ b/content/en/news/2019/announcing-discuss.istio.io/index.md
@@ -4,6 +4,8 @@ subtitle: Istio's discussion board
description: Istio has a new discussion board.
publishdate: 2019-01-10
attribution: The Istio Team
+aliases:
+ - /blog/2019/announcing-discuss.istio.io
---
We in the Istio community have been working to find the right medium for users to engage with other members of the community -- to ask questions,
diff --git a/content/en/blog/2019/cve-2019-12243/index.md b/content/en/news/2019/cve-2019-12243/index.md
similarity index 91%
rename from content/en/blog/2019/cve-2019-12243/index.md
rename to content/en/news/2019/cve-2019-12243/index.md
index 7d608c7274b6..4face043bb4f 100644
--- a/content/en/blog/2019/cve-2019-12243/index.md
+++ b/content/en/news/2019/cve-2019-12243/index.md
@@ -3,9 +3,11 @@ title: Security Update - CVE-2019-12243
description: Security vulnerability disclosure for CVE-2019-12243.
publishdate: 2019-05-28
attribution: The Istio Team
+aliases:
+ - /blog/2019/cve-2019-12243
---
-During review of the [Istio 1.1.7](/about/notes/1.1.7) release notes, we realized that [issue 13868](https://github.com/istio/istio/issues/13868),
+During review of the [Istio 1.1.7](/news/2019/announcing-1.1.7) release notes, we realized that [issue 13868](https://github.com/istio/istio/issues/13868),
which is fixed in the release, actually represents a security vulnerability.
Initially we thought the bug was impacting the [TCP Authorization](/about/feature-stages/#security-and-policy-enforcement) feature advertised
@@ -52,7 +54,7 @@ You are impacted by the vulnerability issue if the following conditions are all
## Mitigation
* Users of Istio 1.0.x are not affected
-* For Istio 1.1.x deployments: update to a minimum version of [Istio 1.1.7](/about/notes/1.1.7)
+* For Istio 1.1.x deployments: update to a minimum version of [Istio 1.1.7](/news/2019/announcing-1.1.7)
## Credit
diff --git a/content/en/blog/2019/cve-2019-12995/index.md b/content/en/news/2019/cve-2019-12995/index.md
similarity index 99%
rename from content/en/blog/2019/cve-2019-12995/index.md
rename to content/en/news/2019/cve-2019-12995/index.md
index ccd898bb2562..f3fab626acf9 100644
--- a/content/en/blog/2019/cve-2019-12995/index.md
+++ b/content/en/news/2019/cve-2019-12995/index.md
@@ -4,6 +4,8 @@ description: Security vulnerability disclosure for CVE-2019-12995.
publishdate: 2019-06-28
attribution: The Istio Team
keywords: [CVE]
+aliases:
+ - /blog/2019/cve-2019-12995
---
A bug in Istio’s JWT validation filter causes Envoy to crash in certain cases when the request contains a malformed JWT token. The bug was discovered and reported by a user [on GitHub](https://github.com/istio/istio/issues/15084) on June 23, 2019.
diff --git a/content/en/blog/2019/incorrect-sidecar-image-1.2.4/index.md b/content/en/news/2019/incorrect-sidecar-image-1.2.4/index.md
similarity index 91%
rename from content/en/blog/2019/incorrect-sidecar-image-1.2.4/index.md
rename to content/en/news/2019/incorrect-sidecar-image-1.2.4/index.md
index c4dc836a8724..f628efe87777 100644
--- a/content/en/blog/2019/incorrect-sidecar-image-1.2.4/index.md
+++ b/content/en/news/2019/incorrect-sidecar-image-1.2.4/index.md
@@ -1,13 +1,15 @@
---
title: Istio 1.2.4 sidecar image vulnerability
-description: An erroneus 1.2.4 sidecar image was available due to a faulty release operation.
+description: An erroneous 1.2.4 sidecar image was available due to a faulty release operation.
publishdate: 2019-09-10
attribution: The Istio Team
keywords: [community,blog,security]
+aliases:
+ - /blog/2019/incorrect-sidecar-image-1.2.4
---
To the Istio’s user community,
-For the period between Aug 23rd 2019 09:16PM PST and Sep 6th 2019 09:26AM PST a Docker image shipped as Istio `proxyv2` 1.2.4 (c.f. [https://hub.docker.com/r/istio/proxyv2](https://hub.docker.com/r/istio/proxyv2) ) contained a faulty version of the proxy against the security bugs [ISTIO-SECURITY-2019-003 and ISTIO-SECURITY-2019-004](/blog/2019/istio-security-003-004/).
+For the period between Aug 23rd 2019 09:16PM PST and Sep 6th 2019 09:26AM PST a Docker image shipped as Istio `proxyv2` 1.2.4 (c.f. [https://hub.docker.com/r/istio/proxyv2](https://hub.docker.com/r/istio/proxyv2) ) contained a faulty version of the proxy against the security bugs [ISTIO-SECURITY-2019-003 and ISTIO-SECURITY-2019-004](/news/2019/istio-security-003-004/).
If you have installed Istio 1.2.4 during that time, please consider upgrading to Istio 1.2.5 that also contains additional security fixes.
diff --git a/content/en/blog/2019/istio-security-003-004/index.md b/content/en/news/2019/istio-security-003-004/index.md
similarity index 94%
rename from content/en/blog/2019/istio-security-003-004/index.md
rename to content/en/news/2019/istio-security-003-004/index.md
index d9c259629947..2f4ac120bc6d 100644
--- a/content/en/blog/2019/istio-security-003-004/index.md
+++ b/content/en/news/2019/istio-security-003-004/index.md
@@ -1,12 +1,14 @@
---
-title: Security Update - ISTIO-SECURITY-003 and ISTIO-SECURITY-004
+title: Security Update - ISTIO-SECURITY-2019-003 and ISTIO-SECURITY-2019-004
description: Security vulnerability disclosure for multiple CVEs.
publishdate: 2019-08-13
attribution: The Istio Team
keywords: [CVE]
+aliases:
+ - /blog/2019/istio-security-003-004
---
-Today we are releasing two new versions of Istio. Istio [1.1.13](/about/notes/1.1.13/) and [1.2.4](/about/notes/1.2.4/) address vulnerabilities that can be used to mount a Denial of Service (DoS) attack against services using Istio.
+Today we are releasing two new versions of Istio. Istio [1.1.13](/news/2019/announcing-1.1.13/) and [1.2.4](/news/2019/announcing-1.2.4/) address vulnerabilities that can be used to mount a Denial of Service (DoS) attack against services using Istio.
__ISTIO-SECURITY-2019-003__: An Envoy user reported publicly an issue (c.f. [Envoy Issue 7728](https://github.com/envoyproxy/envoy/issues/7728)) about regular expressions (or regex) matching that crashes Envoy with very large URIs.
* __[CVE-2019-14993](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14993)__: After investigation, the Istio team has found that this issue could be leveraged for a DoS attack in Istio, if users are employing regular expressions in some of the Istio APIs: `JWT`, `VirtualService`, `HTTPAPISpecBinding`, `QuotaSpecBinding`.
diff --git a/content/en/news/2019/istio-security-2019-005/index.md b/content/en/news/2019/istio-security-2019-005/index.md
new file mode 100644
index 000000000000..4ac381826833
--- /dev/null
+++ b/content/en/news/2019/istio-security-2019-005/index.md
@@ -0,0 +1,37 @@
+---
+title: Security Update - ISTIO-SECURITY-2019-005
+description: Security vulnerability disclosure for CVE-2019-15226.
+publishdate: 2019-10-08
+attribution: The Istio Team
+---
+
+Today we are releasing three new Istio versions: 1.1.16, 1.2.7, and 1.3.2. These new Istio versions address vulnerabilities that can be used to mount Denial of Service (DoS) attacks against services using Istio.
+
+__ISTIO-SECURITY-2019-005__: Envoy, and subsequently Istio, are vulnerable to the following DoS attack:
+* __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: Upon receiving each incoming request, Envoy will iterate over the request headers to verify that the total size of the headers stays below a maximum limit. A remote attacker may craft a request that stays below the maximum request header size but consists of many thousands of small headers to consume CPU and result in a denial-of-service attack.
+
+## Affected Istio Releases
+
+The following Istio releases are vulnerable:
+
+* 1.1, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 1.1.9, 1.1.10, 1.1.11, 1.1.12, 1.1.13, 1.1.14, 1.1.15
+* 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6
+* 1.3, 1.3.1
+
+## Impact Score
+
+Overall CVSS score: 7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
+
+## Vulnerability impact and Detection
+
+Both Istio gateways and sidecars are vulnerable to this issue. If you are running one of the versions listed above, your cluster is vulnerable.
+
+## Mitigation
+
+* For Istio 1.1.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](/docs/setup/upgrade/steps/#sidecar-upgrade) to a minimum version of [Istio 1.1.16](/news/2019/announcing-1.1.16).
+* For Istio 1.2.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](/docs/setup/upgrade/steps/#sidecar-upgrade) to a minimum version of [Istio 1.2.7](/news/2019/announcing-1.2.7).
+* For Istio 1.3.x deployments: update all control plane components (Pilot, Mixer, Citadel, and Galley) and then [upgrade the data plane](/docs/setup/upgrade/steps/#sidecar-upgrade) to a minimum version of [Istio 1.3.2](/news/2019/announcing-1.3.2).
+
+We'd like to remind our community to follow the [vulnerability reporting process](/about/security-vulnerabilities/) to report any bug that can result in a security vulnerability.
+
+
diff --git a/content/en/news/_index.md b/content/en/news/_index.md
new file mode 100644
index 000000000000..1345fbe91659
--- /dev/null
+++ b/content/en/news/_index.md
@@ -0,0 +1,7 @@
+---
+title: Istio News
+description: Timely news about the Istio project.
+linktitle: News
+sidebar_multicard: true
+icon: newspaper
+---
diff --git a/content/en/search/_index.md b/content/en/search/_index.md
index f94d796713e7..e2bc403e8f9b 100644
--- a/content/en/search/_index.md
+++ b/content/en/search/_index.md
@@ -1,6 +1,5 @@
---
title: Search Results
-url: /search.html
sidebar_none: true
skip_toc: true
---
diff --git a/content/zh/about/community/customers/index.md b/content/zh/about/community/customers/index.md
index fabb12a5e7f8..6e40fbe61e3f 100644
--- a/content/zh/about/community/customers/index.md
+++ b/content/zh/about/community/customers/index.md
@@ -24,6 +24,7 @@ skip_seealso: true
{{< company_logo link="http://www.theweathercompany.com" logo="/about/community/customers/theweatherco.jpg" alt="The Weather Company" >}}
{{< company_logo link="https://www.trulia.com" logo="/about/community/customers/trulia.svg" alt="Trulia" >}}
{{< company_logo link="https://www.ibm.com/watson" logo="/about/community/customers/watson.png" alt="IBM Watson" >}}
+ {{< company_logo link="https://www.daocloud.io" logo="/about/community/customers/daocloud.svg" alt="DaoCloud" >}}
想要您的 logo 也出现在这里吗？只需要提交一个 [pull request](https://github.com/istio/istio.io/pulls)。
diff --git a/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg b/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg
index aada9fc509e2..00e9d9a13659 100644
--- a/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg
+++ b/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-1.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg b/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg
index d07cdaf890e6..d0e3c7bbb462 100644
--- a/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg
+++ b/content/zh/blog/2017/mixer-spof-myth/mixer-spof-myth-2.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg b/content/zh/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg
index 7a1d3ef94dd2..df8600eea116 100644
--- a/content/zh/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg
+++ b/content/zh/docs/concepts/multicluster-deployments/multicluster-split-horizon-eds.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg b/content/zh/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg
index 42f1f390f6e2..a10febdb47ab 100644
--- a/content/zh/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg
+++ b/content/zh/docs/concepts/multicluster-deployments/multicluster-with-gateways.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg b/content/zh/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg
index 8be9b4a44841..dd98630eacd1 100644
--- a/content/zh/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg
+++ b/content/zh/docs/concepts/multicluster-deployments/multicluster-with-vpn.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/traffic-management/LoadBalancing.svg b/content/zh/docs/concepts/traffic-management/LoadBalancing.svg
index 3ae06b20e06e..cbf8c0134fe9 100644
--- a/content/zh/docs/concepts/traffic-management/LoadBalancing.svg
+++ b/content/zh/docs/concepts/traffic-management/LoadBalancing.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/traffic-management/PilotAdapters.svg b/content/zh/docs/concepts/traffic-management/PilotAdapters.svg
index 66a8b8632cbf..5b25352241b7 100644
--- a/content/zh/docs/concepts/traffic-management/PilotAdapters.svg
+++ b/content/zh/docs/concepts/traffic-management/PilotAdapters.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/traffic-management/ServiceModel_RequestFlow.svg b/content/zh/docs/concepts/traffic-management/ServiceModel_RequestFlow.svg
index 11b44c352c7b..8b4e88daa325 100644
--- a/content/zh/docs/concepts/traffic-management/ServiceModel_RequestFlow.svg
+++ b/content/zh/docs/concepts/traffic-management/ServiceModel_RequestFlow.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/traffic-management/ServiceModel_Versions.svg b/content/zh/docs/concepts/traffic-management/ServiceModel_Versions.svg
index b97604e49602..6bcf81ac3aac 100644
--- a/content/zh/docs/concepts/traffic-management/ServiceModel_Versions.svg
+++ b/content/zh/docs/concepts/traffic-management/ServiceModel_Versions.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/concepts/traffic-management/TrafficManagementOverview.svg b/content/zh/docs/concepts/traffic-management/TrafficManagementOverview.svg
index cfd1da83e680..88cbb2d34a35 100644
--- a/content/zh/docs/concepts/traffic-management/TrafficManagementOverview.svg
+++ b/content/zh/docs/concepts/traffic-management/TrafficManagementOverview.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/content/zh/docs/reference/config/policy-and-telemetry/adapters/cloudmonitor/index.md b/content/zh/docs/reference/config/policy-and-telemetry/adapters/cloudmonitor/index.md
index 0540e8275aa0..12c3c7139d9d 100644
--- a/content/zh/docs/reference/config/policy-and-telemetry/adapters/cloudmonitor/index.md
+++ b/content/zh/docs/reference/config/policy-and-telemetry/adapters/cloudmonitor/index.md
@@ -4,7 +4,7 @@ description: CloudMonitor 适配器使 Istio 可以向 AliCloud CloudMonitor 提
weight: 70
---
-`cloudmonitor` 适配器让 Istio 可以向 [AliCloud CloudMonitor](https://cloudmonitor.console.aliyun.com/) 提供指标数据。
+`cloudmonitor` 适配器让 Istio 可以向 [AliCloud CloudMonitor](https://www.alibabacloud.com/product/cloud-monitor) 提供指标数据。
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 CloudMonitor.
diff --git a/content/zh/docs/tasks/traffic-management/edge-traffic/egress-tls-origination/index.md b/content/zh/docs/tasks/traffic-management/edge-traffic/egress-tls-origination/index.md
index 998e623f6239..99c0556bdf11 100644
--- a/content/zh/docs/tasks/traffic-management/edge-traffic/egress-tls-origination/index.md
+++ b/content/zh/docs/tasks/traffic-management/edge-traffic/egress-tls-origination/index.md
@@ -120,8 +120,8 @@ $ kubectl delete serviceentry cnn
name: http-port
protocol: HTTP
- number: 443
- name: http-port-for-tls-origination
- protocol: HTTP
+ name: https-port-for-tls-origination
+ protocol: HTTPS
resolution: DNS
---
apiVersion: networking.istio.io/v1alpha3
diff --git a/content/zh/search/_index.md b/content/zh/search/_index.md
index 8028cf3bcfc2..9b82490152d0 100644
--- a/content/zh/search/_index.md
+++ b/content/zh/search/_index.md
@@ -1,6 +1,5 @@
---
title: 搜索结果
-url: /zh/search.html
sidebar_none: true
skip_toc: true
---
diff --git a/data/args.yml b/data/args.yml
index 0964667d3bbc..d646776430bc 100644
--- a/data/args.yml
+++ b/data/args.yml
@@ -2,7 +2,7 @@
version: "1.3"
# The full Istio version identifier the docs describe
-full_version: "1.3.0"
+full_version: "1.3.3"
# The previous Istio version identifier the docs describe, used for upgrade documentation
previous_version: "1.2"
@@ -16,7 +16,7 @@ copyright_year: 2019
# When preliminary=true, we're building for preliminary.istio.io
# when archive=true, we're building for archive.istio.io
# when archive_landing=true, we're building the landing page for archive.istio.io
-preliminary: true
+preliminary: false
archive: false
archive_landing: false
@@ -26,7 +26,7 @@ archive_search_refinement: "V1.1"
# GitHub branch names used when the docs have links to GitHub
source_branch_name: release-1.3
-doc_branch_name: master
+doc_branch_name: release-1.3
# The list of supported versions described by the docs
supported_kubernetes_versions: ["1.13", "1.14", "1.15"]
diff --git a/layouts/_default/baseof.html b/layouts/_default/baseof.html
index c460b994c2d5..91bc1a86205c 100644
--- a/layouts/_default/baseof.html
+++ b/layouts/_default/baseof.html
@@ -83,7 +83,9 @@
-
+
+
+
diff --git a/layouts/blog/rss.xml b/layouts/blog/rss.xml
new file mode 100644
index 000000000000..47019208ce3b
--- /dev/null
+++ b/layouts/blog/rss.xml
@@ -0,0 +1,36 @@
+{{ $home := .Site.BaseURL }}
+
+
+
+ Istio Blog
+ Connect, secure, control, and observe services.
+ {{ if not .Date.IsZero }}
+ {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
+ {{ end }}
+ {{ $home }}
+
+ {{ $home }}/favicons/android-192x192.png
+ {{ $home }}
+
+ Service mesh
+
+ {{ $pages := (where .Site.Pages "Section" "blog").ByPublishDate.Reverse }}
+
+ {{ range $post := $pages }}
+ {{ if and (not $post.Draft) $post.IsPage }}
+
+ {{ $post.Title }}
+ {{ $post.Content | html }}
+ {{ $post.PublishDate.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
+ {{ $post.Permalink }}
+ {{ $post.Params.attribution }}
+ {{ $post.Permalink }}
+
+ {{ range $kw := $post.Keywords }}
+ {{ $kw }}
+ {{ end }}
+
+ {{ end }}
+ {{ end }}
+
+
diff --git a/layouts/index.redir b/layouts/index.redir
index 3f136b844fa9..ec8df19a002f 100644
--- a/layouts/index.redir
+++ b/layouts/index.redir
@@ -12,6 +12,8 @@
/test-infra/* go-get=1 /golang/test-infra.html 200
/tools/* go-get=1 /golang/tools.html 200
/operator/* go-get=1 /golang/operator.html 200
+/client-go/* go-get=1 /golang/client-go.html 200
+/release-builder/* go-get=1 /golang/release-builder.html 200
# Redirect default Netlify subdomain to primary domain
https://istio.netlify.com/* https://istio.io/:splat 301!
diff --git a/layouts/news/rss.xml b/layouts/news/rss.xml
new file mode 100644
index 000000000000..b1bea3f755cb
--- /dev/null
+++ b/layouts/news/rss.xml
@@ -0,0 +1,36 @@
+{{ $home := .Site.BaseURL }}
+
+
+
+ Istio News
+ Connect, secure, control, and observe services.
+ {{ if not .Date.IsZero }}
+ {{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
+ {{ end }}
+ {{ $home }}
+
+ {{ $home }}/favicons/android-192x192.png
+ {{ $home }}
+
+ Service mesh
+
+ {{ $pages := (where .Site.Pages "Section" "news").ByPublishDate.Reverse }}
+
+ {{ range $post := $pages }}
+ {{ if and (not $post.Draft) $post.IsPage }}
+
+ {{ $post.Title }}
+ {{ $post.Content | html }}
+ {{ $post.PublishDate.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}
+ {{ $post.Permalink }}
+ {{ $post.Params.attribution }}
+ {{ $post.Permalink }}
+
+ {{ range $kw := $post.Keywords }}
+ {{ $kw }}
+ {{ end }}
+
+ {{ end }}
+ {{ end }}
+
+
diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html
index 2ce589f55f11..f7eb06e43626 100644
--- a/layouts/partials/footer.html
+++ b/layouts/partials/footer.html
@@ -8,7 +8,7 @@
{{- end -}}
{{- if not .Site.Data.args.archive_landing -}}
-
+ download
{{ partial "icon.html" "download" }}
diff --git a/layouts/partials/header.html b/layouts/partials/header.html
index 54986a5cfa55..f0226de2f475 100644
--- a/layouts/partials/header.html
+++ b/layouts/partials/header.html
@@ -4,6 +4,10 @@
{{ $latest_post := index $posts 0 }}
{{ $blog_home := .Site.GetPage "section" "blog" }}
+{{ $news := (where .Site.Pages "Section" "news").ByPublishDate.Reverse }}
+{{ $latest_news := index $news 0 }}
+{{ $news_home := .Site.GetPage "section" "news" }}
+