istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Switch from Jekyll to Hugo.

This commit is contained in:
mtail 2018-05-24 06:57:19 -07:00
parent 401989fba6
commit 951a8ed9f4
268 changed files with 2146 additions and 1812 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
.circleci/config.yml
View File

@ -1,64 +0,0 @@
# Ruby CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-ruby/ for more details
#
version: 2
jobs:
build:
docker:
# specify the version you desire here
- image: circleci/ruby:2.4.1-node-browsers
working_directory: ~/repo
steps:
- checkout
# Download and cache dependencies
- restore_cache:
keys:
- v4-dependencies-{{ checksum "Gemfile.lock" }}
# fallback to using the latest cache if no exact match is found
- v4-dependencies-
- run:
name: Installing proofer dependencies
command: |
gem install bundler
bundle install --jobs=4 --retry=3 --path .vendor/bundle
- save_cache:
paths:
- ./.vendor/bundle
key: v4-dependencies-{{ checksum "Gemfile.lock" }}
- restore_cache:
keys:
- htmlproofer-cache-v3
- run:
name: Proofing HTML
command:
bundle exec rake test
# save the external URLs cache
- save_cache:
key: htmlproofer-cache-v3
paths:
- tmp/.htmlproofer
- run:
name: Installing speller dependencies
command: |
mkdir -p .vendor/node
npm install --prefix .vendor/node markdown-spellcheck
- run:
name: Checking markdown spelling
command:
.vendor/node/node_modules/markdown-spellcheck/bin/mdspell --en-us --ignore-acronyms --ignore-numbers --no-suggestions --report *.md */*.md */*/*.md */*/*/*.md */*/*/*/*.md
- run:
name: Checking markdown style
command:
mdl --ignore-front-matter --style mdl_style.rb .

10
.gitignore vendored
View File

@ -1,15 +1,11 @@
_site
_rakesite
_static_site
.bundle
config_override.yml
.jekyll-metadata
# Eclipse artifacts
.project
.pydevproject
*.iml
.idea/
.bundle/
tmp/
*.bak
.DS_Store
.tools
.htmlproofer
public

1
.spelling
View File

@ -429,6 +429,7 @@ ratelimit-handler
raw.githubusercontent.com
raw.githubusercontent.com)
reachability
rearchitect
readinessProbe
redis
redis-master-2353460263-1ecey

21
404.md
View File

@ -1,21 +0,0 @@
---
title: Page Not Found
description: Page redirection
weight: 1
layout: notfound
---
{% include home.html %}
<div class="icon">
<img alt="Warning" title="Uh-oh" src="{{home}}/img/exclamation-mark.svg" />
</div>
<div class="error">
We're sorry, the page you requested cannot be found
</div>
<div class="explanation">
The URL may be misspelled or the page you're looking for is no longer available
</div>

51
Makefile Normal file
View File

@ -0,0 +1,51 @@
all: prep build generate lint
prep: prep_build prep_lint prep_generate
##########
prep_generate:
npm install --prefix .tools/node html-minifier
generate:
hugo --baseURL $(DEPLOY_URL)
.tools/node/node_modules/html-minifier/cli.js --input-dir public --output-dir public --file-ext html --collapse-whitespace --minify-js --minify-css --sort-attributes --sort-class-name --remove-attribute-quotes --remove-comments
##########
prep_build:
npm install --prefix .tools/node sass
npm install --prefix .tools/node uglify-js
build:
.tools/node/node_modules/sass/sass.js src/sass/light_theme_archive.scss static/css/light_theme_archive.css -s compressed
.tools/node/node_modules/sass/sass.js src/sass/light_theme_normal.scss static/css/light_theme_normal.css -s compressed
.tools/node/node_modules/sass/sass.js src/sass/light_theme_preliminary.scss static/css/light_theme_preliminary.css -s compressed
.tools/node/node_modules/sass/sass.js src/sass/dark_theme_archive.scss static/css/dark_theme_archive.css -s compressed
.tools/node/node_modules/sass/sass.js src/sass/dark_theme_normal.scss static/css/dark_theme_normal.css -s compressed
.tools/node/node_modules/sass/sass.js src/sass/dark_theme_preliminary.scss static/css/dark_theme_preliminary.css -s compressed
.tools/node/node_modules/uglify-js/bin/uglifyjs src/js/misc.js src/js/prism.js --mangle --compress -o static/js/all.min.js
.tools/node/node_modules/uglify-js/bin/uglifyjs src/js/styleSwitcher.js --mangle --compress -o static/js/styleSwitcher.min.js
##########
prep_lint:
npm install --prefix .tools/node markdown-spellcheck
gem install mdl
gem install html-proofer
lint:
.tools/node/node_modules/markdown-spellcheck/bin/mdspell --en-us --ignore-acronyms --ignore-numbers --no-suggestions --report */*.md */*/*.md */*/*/*.md */*/*/*/*.md */*/*/*/*/*.md */*/*/*/*/*/*.md */*/*/*/*/*/*/*.md
mdl --ignore-front-matter --style mdl_style.rb .
htmlproofer ./public --check-html --assume-extension --timeframe 2d --storage-dir .htmlproofer --url-ignore "/localhost/,/github.com/istio/istio.github.io/edit/master/"
prep_lint_local:
npm install --prefix .tools/node markdown-spellcheck
gem install mdl --install-dir .tools
gem install html-proofer --install-dir .tools
lint_local:
.tools/node/node_modules/markdown-spellcheck/bin/mdspell --en-us --ignore-acronyms --ignore-numbers --no-suggestions --report */*.md */*/*.md */*/*/*.md */*/*/*/*.md */*/*/*/*/*.md */*/*/*/*/*/*.md */*/*/*/*/*/*/*.md
.tools/bin/mdl --ignore-front-matter --style mdl_style.rb .
.tools/bin/htmlproofer ./public --check-html --assume-extension --timeframe 2d --storage-dir .htmlproofer --url-ignore "/localhost/,/github.com/istio/istio.github.io/edit/master/"

98
README.md
View File

@ -8,75 +8,91 @@ file to learn about the overall Istio project and how to get in touch with us. T
contribute to any of the Istio components, please
see the Istio [contribution guidelines](https://github.com/istio/community/blob/master/CONTRIBUTING.md).
* [Working with the site](#working-with-the-site)
* [Editing and testing content](#editing-and-testing-content)
* [Linting](#linting)
* [Site infrastructure](#site-infrastructure)
* [Versions and releases](#versions-and-releases)
* [How versioning works](#how-versioning-works)
* [Publishing content immediately](#publishing-content-immediately)
* [Creating a version](#creating-a-version)
## Working with the site
## Editing and testing content
We use [Jekyll](https://jekyllrb.com/) to generate our sites.
To run the site locally with Docker, use the following command from the top level directory for this git repo
(e.g. pwd must be `~/github/istio.github.io` if you were in `~/github` when you issued
`git clone https://github.com/istio/istio.github.io.git`)
We use [Hugo](https://gohugo.io/) to generate our sites. To build and test the site locally,
install Hugo, go to the root of the repo and do:
```bash
# First time: (slow)
docker run --name istio-jekyll --volume=$(pwd):/srv/jekyll -w /srv/jekyll -it -p 4000:4000 jekyll/jekyll:3.7.3 sh -c "bundle install && rake test && bundle exec jekyll serve --incremental --host 0.0.0.0"
# Then open browser with url 127.0.0.1:4000 to see the change.
# Subsequent, each time you want to see a new change and you stopped the previous run by ctrl+c: (much faster)
docker start istio-jekyll -a -i
# Clean up, only needed if you won't be previewing website changes for a long time or you want to start over:
docker rm istio-jekyll
$ hugo serve
```
The `rake test` part is to make sure you are not introducing HTML errors or bad links, you should see
This will build the site and start a web server hosting the site. You can then connect to the web server
at `http://localhost:1313`.
All normal content for the site is located in the `content` directory. To
create a new content file, go to the root of the repo and do:
```bash
HTML-Proofer finished successfully.
$ hugo new <path to new file>
```
in the output.
Alternatively, if you just want to develop locally w/o Docker/Kubernetes/Minikube, you can try installing Jekyll locally.
You may need to install other prerequisites manually (which is where using the docker image shines). Here's an example of doing
so for Mac OS X:
This will create a fresh content file, ready for editing. The path you specify is relative to the `content` directory. For
example:
```bash
xcode-select --install
sudo xcodebuild -license
brew install ruby
gem update --system
gem install mdspell
gem install bundler
gem install jekyll
cd istio.github.io
bundle install
bundle exec rake test
bundle exec jekyll serve
$ hugo new docs/tasks/traffic-management/foo.md
```
Will create the file `content/docs/tasks/traffic-management/foo.md` which you can then add your markdown to.
## Linting
You should run `scripts/linters.sh` prior to checking in your changes.
This will run 3 tests:
We use linters to ensure some base quality to the site's content. We currently
run 3 linters as a precommit requirement:
* HTML proofing, which ensures all your links are valid along with other checks.
* Spell checking.
* Style checking, which makes sure your markdown file complies with some common style rules.
* Style checking, which makes sure your markdown files comply with our common style rules.
If you get a spelling error, you have three choices to address it:
You can run these linters locally using:
```bash
$ make prep_lint
$ make lint
```
The `prep_lint` step installs a bunch of Ruby and Node.js tools in a local directory. You only need to do
this once. Afterwards, just use the `lint` target to run the linters.
If you get spelling errors, you have three choices to address it:
* It's a real typo, so fix your markdown.
* It's a command/field/symbol name, so stick some `backticks` around it.
* It's really valid, so go add the word to the .spelling file at the root of the repo.
* It's really valid, so go add the word to the `.spelling` file at the root of the repo.
## Site infrastructure
Here's how things work:
* Primary site content is in the `content` directory. This is mostly
markdown files which Hugo processes into HTML.
* Additional site content is in the `static` directory. These are files that
Hugo directly copies to the site without any processing.
* The `src` directory contains the source material for certain files from the
`static` directory. You use
```bash
$ make prep_build
$ make build
```
to build the material from the `src` directory and refresh what's in the `static`
directory.
## Versions and releases
@ -126,24 +142,24 @@ version of Istio is 0.6 and you wish to introduce 0.7 which has been under devel
1. Create a new release branch off of master, named as release-*major*.*minor*, which in this case would be
release-0.7. There is one such branch for every release.
1. In the **master** branch, edit the file `_data/istio.yml` and update the `version` field to have the version
1. In the **master** branch, edit the file `data/args.yml` and update the `version` field to have the version
of the next release of Istio. In this case, you would set the field to 0.8.
1. In the **master** branch, edit the file `_data/releases.yml` and add a new entry at the top of the file
1. In the **master** branch, edit the file `data/releases.yml` and add a new entry at the top of the file
for version 0.8. You'll need to make sure the URLs are updated for the first few entries. The top
entry (0.8) should point to preliminary.istio.io. The second entry (0.7) should point to istio.io. The third
and subsequent entries should point to archive.istio.io.
1. Commit the previous two edits to GitHub.
1. In the **release** branch you created, edit the file `_data/istio.yml`. Set the `preliminary` field to `false`.
1. In the **release** branch you created, edit the file `data/args.yml`. Set the `preliminary` field to `false`.
1. Commit the previous edit to GitHub.
1. Go to the Google Search Console and create a new search engine that searches the archive.istio.io/V&lt;major&gt;.&lt;minor&gt;
directory. This search engine will be used to perform version-specific searches on archive.istio.io.
1. In the **previous release's** branch (in this case release-0.6), edit the file `_data/istio.yml`. Set the
1. In the **previous release's** branch (in this case release-0.6), edit the file `data/args.yml`. Set the
`archive` field to true, the `archive_date` field to the current date, and the `search_engine_id` field
to the ID of the search engine you created in the prior step.

11
archetypes/blog.md Normal file
View File

@ -0,0 +1,11 @@
---
title: My Title
subtitle: My optional on-line subtitle
description: My one-line description for the page
publishdate: 2017-05-24
attribution: My Name
weight: 0
---
## What's next

11
archetypes/default.md Normal file
View File

@ -0,0 +1,11 @@
---
title: My Title
description: My one-line description for the page
weight: 0
---
## Before you begin
## Cleaning up
## What's next

25
config.toml Normal file
View File

@ -0,0 +1,25 @@
defaultContentLanguage = "en"
languageCode = "en-us"
metaDataFormat = "yaml"
title = "Istio"
uglyURLs = false
enableRobotsTXT = true
googleAnalytics = "UA-98480406-1"
pluralizeListTitles = false
canonifyURLs = false
disableKinds = ["taxonomy", "taxonomyTerm"]
anchor = "smart"
# MARKDOWN
## Configuration for BlackFriday markdown parser: https://github.com/russross/blackfriday
[blackfriday]
plainIDAnchors = true
# See https://github.com/gohugoio/hugo/issues/2424
hrefTargetBlank = false
angledQuotes = false
latexDashes = true
extensions = [""]
[outputs]
home = ["HTML"]
section = ["HTML"]

3
content/_index.md Normal file
View File

@ -0,0 +1,3 @@
---
title: Istio
---

9
content/about/_index.md
View File

@ -6,15 +6,14 @@ weight: 15
toc: false
---
{% include home.html %}
Get a bit more in-depth info about the Istio project.
- [What is Istio?]({{home}}/about/intro.html). Get some context about what problems Istio is designed to solve.
- [What is Istio?](/about/intro/). Get some context about what problems Istio is designed to solve.
- [Release Notes]({{home}}/about/notes/). Learn about the latest features, improvements, and bug fixes.
- [Release Notes](/about/notes/). Learn about the latest features, improvements, and bug fixes.
- [Feature Status]({{home}}/about/feature-stages.html). Get a detailed list of Istio's individual features and their relative
- [Feature Status](/about/feature-stages/). Get a detailed list of Istio's individual features and their relative
maturity and support level.
- [Contributing to the Docs]({{home}}/about/contribute/). Learn how you can help contribute to improve Istio's documentation.
- [Contributing to the Docs](/about/contribute/). Learn how you can help contribute to improve Istio's documentation.

6
content/about/contribute/_index.md
View File

@ -2,9 +2,7 @@
title: Contributing to the Docs
description: Learn how to contribute to improve and expand the Istio documentation.
weight: 100
toc: false
redirect_from:
type: section-index
aliases:
- /docs/welcome/contribute/index.html
---
{% include section-index.html docs=site.about %}

8
content/about/contribute/creating-a-pull-request.md
View File

@ -2,7 +2,7 @@
title: Creating a Pull Request
description: Shows you how to create a GitHub pull request in order to submit your docs for approval.
weight: 20
redirect_from:
aliases:
- /docs/welcome/contribute/creating-a-pull-request.html
---
@ -35,8 +35,8 @@ documentation repository in your GitHub account. The copy is called a *fork*.
a new branch to use for your contribution.
1. In your new branch, make your changes and commit them. If you want to
[write a new topic](./writing-a-new-topic.html),
choose the [page-type](./writing-a-new-topic.html#choosing-a-page-type)
[write a new topic](/about/contribute/writing-a-new-topic/),
choose the [page-type](/about/contribute/writing-a-new-topic/#choosing-a-page-type)
that is the best fit for your content.
## Submitting a pull request
@ -56,4 +56,4 @@ If needed, revise your pull request by committing changes to your
new branch in your fork.
> Once your changes have been committed, they will show up immediately on [preliminary.istio.io](https://preliminary.istio.io), but
will only show up on [istio.io](http://istio.io) the next time we produce a new release, which happens around once a month.
will only show up on [istio.io](https://istio.io) the next time we produce a new release, which happens around once a month.

4
content/about/contribute/editing.md
View File

@ -2,7 +2,7 @@
title: Editing Docs
description: Lets you start editing this site's documentation.
weight: 10
redirect_from:
aliases:
- /docs/welcome/contribute/editing.html
---
@ -14,4 +14,4 @@ are ready to send those changes to us, go to the index page for your fork and cl
<a class="btn btn-istio" href="https://github.com/istio/istio.github.io/">Browse this site's source code</a>
> Once your changes have been committed, they will show up immediately on [preliminary.istio.io](https://preliminary.istio.io), but
will only show up on [istio.io](http://istio.io) the next time we produce a new release, which happens around once a month.
will only show up on [istio.io](https://istio.io) the next time we produce a new release, which happens around once a month.

4
content/about/contribute/reviewing-doc-issues.md
View File

@ -1,10 +1,8 @@
---
title: Doc Issues
description: Explains the process involved in accepting documentation updates.
weight: 60
redirect_from:
aliases:
- /docs/welcome/contribute/reviewing-doc-issues.html
---

27
content/about/contribute/staging-your-changes.md
View File

@ -1,10 +1,8 @@
---
title: Staging Your Changes
description: Explains how to test your changes locally before submitting them.
weight: 40
redirect_from:
aliases:
- /docs/welcome/contribute/staging-your-changes.html
---
@ -14,30 +12,17 @@ to the Istio documentation.
## Before you begin
Create a fork of the Istio documentation repository as described in
[Creating a Doc Pull Request](./creating-a-pull-request.html).
[Creating a Doc Pull Request](/about/contribute/creating-a-pull-request/).
## Staging locally
See [Detailed instructions and options on GitHub](https://github.com/istio/istio.github.io/blob/master/README.md)
Once Jekyll is running, you can open a web browser and go to `http://localhost:4000` to see your
Once Hugo is running, you can open a web browser and go to `http://localhost:1313` to see your
changes. You can make further changes to the content in your repo and just refresh your browser page to see
the results, no need to restart Jekyll all the time.
the results, no need to restart Hugo all the time.
## Staging from your GitHub account
> Hey, you know, you're much better off staging locally using the above procedure. Just sayin'...
GitHub provides staging of content in your master branch. Note that you
might not want to merge your changes into your master branch. If that is
the case, choose another option for staging your content.
1. In your GitHub account, in your fork, merge your changes into
the master branch.
1. Change the name of your repository to `<your-username>.github.io`, where
`<your-username>` is the username of your GitHub account.
1. Delete the `CNAME` file.
1. View your staged content at this URL: `https://<your-username>.github.io`
Once you push a PR from your fork to the istio.github.io's master branch, your PR page on GitHub will show a link to a staging site
built automatically for your PR. This is useful for folks trying to review your changes.

6
content/about/contribute/style-guide.md
View File

@ -1,10 +1,8 @@
---
title: Style Guide
description: Explains the dos and donts of writing Istio docs.
weight: 70
redirect_from:
aliases:
- /docs/welcome/contribute/style-guide.html
- /docs/reference/contribute/style-guide.html
---
@ -17,7 +15,7 @@ propose changes to this document in a pull request.
For additional information on creating new content for the Istio
docs, follow the instructions on
[Creating a Doc Pull Request](./creating-a-pull-request.html).
[Creating a Doc Pull Request](/about/contribute/creating-a-pull-request/).
## Formatting standards

55
content/about/contribute/writing-a-new-topic.md
View File

@ -2,17 +2,16 @@
title: Writing a New Topic
description: Explains the mechanics of creating new documentation pages.
weight: 30
redirect_from:
aliases:
- /docs/welcome/contribute/writing-a-new-topic.html
---
{% include home.html %}
This page shows how to create a new Istio documentation topic.
## Before you begin
You first need to create a fork of the Istio documentation repository as described in
[Creating a Doc Pull Request](./creating-a-pull-request.html).
[Creating a Doc Pull Request](/about/contribute/creating-a-pull-request/).
## Choosing a page type
@ -76,8 +75,8 @@ all in lower case.
## Updating the front matter
Every documentation file needs to start with Jekyll
[front matter](https://jekyllrb.com/docs/frontmatter/).
Every documentation file needs to start with
[front matter](https://gohugo.io/content-management/front-matter/).
The front matter is a block of YAML that is between the
triple-dashed lines at the top of each file. Here's the
chunk of front matter you should start with:
@ -99,9 +98,8 @@ matter fields are:
|`title` | The short title of the page
|`description` | A one-line description of what the topic is about
|`weight` | An integer used to determine the sort order of this page relative to other pages in the same directory.
|`layout` | Indicates which of the Jekyll layouts this page uses
|`draft` | When true, prevents the page from showing up in any navigation area
|`publishdate` | For blog posts, indicates the date of publication of the post
|`publishdate` | For blog posts, indicates the date of publication of the post
|`subtitle` | For blog posts, supplies an optional subtitle to be displayed below the main title
|`attribution` | For blog posts, supplies an optional author's name
|`toc` | Set this to false to prevent the page from having a table of contents generated for it
@ -135,14 +133,12 @@ if needed.
Within markdown, use the following sequence to add the image:
```html
{% raw %}
{% include image.html width="75%" ratio="69.52%"
{{</* image width="75%" ratio="69.52%"
link="./img/myfile.svg"
alt="Alternate text to display when the image is not available"
title="A tooltip displayed when hovering over the image"
caption="A caption displayed under the image"
%}
{% endraw %}
*/>}}
```
The `width`, `ratio`, `link` and `caption` values are required. If the `title` value isn't
@ -157,14 +153,14 @@ relative to the surrounding text. `ratio` (image height / image width) * 100.
There are three types of links that can be included in documentation. Each uses a different
way to indicate the link target:
- **Internet Link**. You use classic URL syntax, preferably with the HTTPS protocol, to reference
1. **Internet Link**. You use classic URL syntax, preferably with the HTTPS protocol, to reference
files on the Internet:
```markdown
[see here](https://mysite/myfile.html)
```
- **Relative Link**. You use relative links that start with a period to
1. **Relative Link**. You use relative links that start with a period to
reference any content that is at the same level as the current file, or below within
the hierarchy of the site:
@ -172,25 +168,13 @@ the hierarchy of the site:
[see here](./adir/anotherfile.html)
```
- **Absolute Link**. You use absolute links with the special \{\{home\}\} notation to reference content outside of the
1. **Absolute Link**. You use absolute links that start with a `/` to reference content outside of the
current hierarchy:
```markdown
{% raw %}[see here]({{home}}/docs/adir/afile.html){% endraw %}
[see here](/docs/adir/afile/)
```
In order to use \{\{home\}\} in a file,
you need to make sure that the file contains the following
line of boilerplate right after the block of front matter:
```markdown
...
---
{% raw %}{% include home.html %}{% endraw %}
```
Adding this include statement is what defines the `home` variable that is used in the link target.
## Embedding preformatted blocks
You can embed blocks of preformatted content using the normal markdown technique:
@ -282,15 +266,14 @@ instead of merely `command` in order to apply syntax coloring to the command's o
## Displaying file content
You can pull in an external file and display its content as a preformatted block. This is handy to display a
config file or a test file. To do so, you use a Jekyll include statement such as:
config file or a test file. To do so, you use a statement such as:
```html
{% raw %}{% include file-content.html url='https://raw.githubusercontent.com/istio/istio/master/Makefile' %}{% endraw %}
```markdown
{{</* file_content url="https://raw.githubusercontent.com/istio/istio/master/Makefile" */>}}
```
which produces the following result:
{% include file-content.html url='https://raw.githubusercontent.com/istio/istio/master/Makefile' %}
{{< file_content url="https://raw.githubusercontent.com/istio/istio/master/Makefile" >}}
If the file is from a different origin site, CORS should be enabled on that site. Note that the
GitHub raw content site (raw.githubusercontent.com) is CORS
@ -308,7 +291,7 @@ In the page that is the target of the redirect (where you'd like users to land),
following to the front-matter:
```plain
redirect_from:
aliases:
- <url>
```
@ -319,14 +302,14 @@ For example
title: Frequently Asked Questions
description: Questions Asked Frequently
weight: 12
redirect_from:
aliases:
- /faq
---
```
With the above in a page saved as _help/faq.md, the user will be able to access the page by going
to istio.io/help/faq as normal, as well as istio.io/faq.
to `istio.io/help/faq/` as normal, as well as `istio.io/faq/`.
You can also add many redirects like so:
@ -335,7 +318,7 @@ You can also add many redirects like so:
title: Frequently Asked Questions
description: Questions Asked Frequently
weight: 12
redirect_from:
aliases:
- /faq
- /faq2
- /faq3

89
content/about/feature-stages.md
View File

@ -2,12 +2,11 @@
title: Feature Status
description: List of features and their release stages.
weight: 10
redirect_from:
- /docs/reference/release-roadmap.html
- /docs/reference/feature-stages.html
- /docs/welcome/feature-stages.html
aliases:
- /docs/reference/release-roadmap.html
- /docs/reference/feature-stages.html
- /docs/welcome/feature-stages.html
---
{% include home.html %}
This page lists the relative maturity and support
level of every Istio feature. Please note that the phases (Alpha, Beta, and Stable) are applied to individual features
@ -36,68 +35,68 @@ Below is our list of existing features and their current phases. This informatio
| [Protocols: TCP](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/tcp_proxy) | Alpha
| [Protocols: WebSocket](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/websocket) | Alpha
| [Protocols: MongoDB](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/mongo) | Alpha
| [Routing Rules: Retry]({{home}}/docs/tasks/traffic-management/request-routing.html) | Alpha
| [Routing Rules: Timeout]({{home}}/docs/tasks/traffic-management/request-routing.html) | Alpha
| [Routing Rules: Circuit Break]({{home}}/docs/tasks/traffic-management/request-routing.html) | Alpha
| [Routing Rules: Header Rewrite]({{home}}/docs/tasks/traffic-management/request-routing.html) | Alpha
| [Routing Rules: Traffic Splitting]({{home}}/docs/tasks/traffic-management/request-routing.html) | Alpha
| [Improved Routing Rules: Composite Service]({{home}}/docs/reference/config/istio.networking.v1alpha3.html) | Alpha
| [Quota / Redis Rate Limiting (Adapter and Server)]({{home}}/docs/tasks/policy-enforcement/rate-limiting.html) | Alpha
| [Memquota Implementation and Integration]({{home}}/docs/tasks/telemetry/metrics-logs.html) | Stable
| [Ingress TLS]({{home}}/docs/tasks/traffic-management/ingress.html) | Alpha
| [Routing Rules: Retry](/docs/tasks/traffic-management/request-routing/) | Alpha
| [Routing Rules: Timeout](/docs/tasks/traffic-management/request-routing/) | Alpha
| [Routing Rules: Circuit Break](/docs/tasks/traffic-management/request-routing/) | Alpha
| [Routing Rules: Header Rewrite](/docs/tasks/traffic-management/request-routing/) | Alpha
| [Routing Rules: Traffic Splitting](/docs/tasks/traffic-management/request-routing/) | Alpha
| [Improved Routing Rules: Composite Service](/docs/reference/config/istio.networking.v1alpha3/) | Alpha
| [Quota / Redis Rate Limiting (Adapter and Server)](/docs/tasks/policy-enforcement/rate-limiting/) | Alpha
| [Memquota Implementation and Integration](/docs/tasks/telemetry/metrics-logs/) | Stable
| [Ingress TLS](/docs/tasks/traffic-management/ingress/) | Alpha
| Egress Policy and Telemetry | Alpha
### Observability
| Feature | Phase
|-------------------|-------------------
| [Prometheus Integration]({{home}}/docs/guides/telemetry.html) | Beta
| [Local Logging (STDIO)]({{home}}/docs/guides/telemetry.html) | Stable
| [Statsd Integration]({{home}}/docs/reference/config/policy-and-telemetry/adapters/statsd.html) | Stable
| [Service Dashboard in Grafana]({{home}}/docs/tasks/telemetry/using-istio-dashboard.html) | Beta
| [Stackdriver Integration]({{home}}/docs/reference/config/policy-and-telemetry/adapters/stackdriver.html) | Alpha
| [Service Graph]({{home}}/docs/tasks/telemetry/servicegraph.html) | Alpha
| [Distributed Tracing to Zipkin / Jaeger]({{home}}/docs/tasks/telemetry/distributed-tracing.html) | Alpha
| [Istio Component Dashboard in Grafana]({{home}}/docs/tasks/telemetry/using-istio-dashboard.html) | Beta
| [Service Tracing]({{home}}/docs/tasks/telemetry/distributed-tracing.html) | Alpha
| [Prometheus Integration](/docs/guides/telemetry/) | Beta
| [Local Logging (STDIO)](/docs/guides/telemetry/) | Stable
| [Statsd Integration](/docs/reference/config/policy-and-telemetry/adapters/statsd/) | Stable
| [Service Dashboard in Grafana](/docs/tasks/telemetry/using-istio-dashboard/) | Beta
| [Stackdriver Integration](/docs/reference/config/policy-and-telemetry/adapters/stackdriver/) | Alpha
| [Service Graph](/docs/tasks/telemetry/servicegraph/) | Alpha
| [Distributed Tracing to Zipkin / Jaeger](/docs/tasks/telemetry/distributed-tracing/) | Alpha
| [Istio Component Dashboard in Grafana](/docs/tasks/telemetry/using-istio-dashboard/) | Beta
| [Service Tracing](/docs/tasks/telemetry/distributed-tracing/) | Alpha
### Security
| Feature | Phase
|-------------------|-------------------
| [Deny Checker]({{home}}/docs/reference/config/policy-and-telemetry/adapters/denier.html) | Stable
| [List Checker]({{home}}/docs/reference/config/policy-and-telemetry/adapters/list.html) | Stable
| [Kubernetes: Service Credential Distribution]({{home}}/docs/concepts/security/mutual-tls.html) | Stable
| [Pluggable Key/Cert Support for Istio CA]({{home}}/docs/tasks/security/plugin-ca-cert.html) | Stable
| [Service-to-service mutual TLS]({{home}}/docs/concepts/security/mutual-tls.html) | Stable
| [Incremental Enablement of service-to-service mutual TLS]({{home}}/docs/tasks/security/per-service-mtls.html) | Alpha
| [VM: Service Credential Distribution]({{home}}/docs/concepts/security/mutual-tls.html) | Alpha
| [Deny Checker](/docs/reference/config/policy-and-telemetry/adapters/denier/) | Stable
| [List Checker](/docs/reference/config/policy-and-telemetry/adapters/list/) | Stable
| [Kubernetes: Service Credential Distribution](/docs/concepts/security/mutual-tls/) | Stable
| [Pluggable Key/Cert Support for Istio CA](/docs/tasks/security/plugin-ca-cert/) | Stable
| [Service-to-service mutual TLS](/docs/concepts/security/mutual-tls/) | Stable
| [Incremental Enablement of service-to-service mutual TLS](/docs/tasks/security/per-service-mtls/) | Alpha
| [VM: Service Credential Distribution](/docs/concepts/security/mutual-tls/) | Alpha
| [OPA Checker](https://github.com/istio/istio/blob/41a8aa4f75f31bf0c1911d844a18da4cff8ac584/mixer/adapter/opa/README.md) | Alpha
| RBAC Mixer Adapter | Alpha
| [API Keys]({{home}}/docs/reference/config/policy-and-telemetry/templates/apikey.html) | Alpha
| [API Keys](/docs/reference/config/policy-and-telemetry/templates/apikey/) | Alpha
### Core
| Feature | Phase
|-------------------|-------------------
| [Kubernetes: Envoy Installation and Traffic Interception]({{home}}/docs/setup/kubernetes/) | Beta
| [Kubernetes: Istio Control Plane Installation]({{home}}/docs/setup/kubernetes/) | Beta
| [Pilot Integration into Kubernetes Service Discovery]({{home}}/docs/setup/kubernetes/) | Stable
| [Attribute Expression Language]({{home}}/docs/reference/config/policy-and-telemetry/expression-language.html) | Stable
| [Mixer Adapter Authoring Model]({{home}}/blog/2017/adapter-model.html) | Stable
| [VM: Envoy Installation, Traffic Interception and Service Registration]({{home}}/docs/guides/integrating-vms.html) | Alpha
| [Kubernetes: Envoy Installation and Traffic Interception](/docs/setup/kubernetes/) | Beta
| [Kubernetes: Istio Control Plane Installation](/docs/setup/kubernetes/) | Beta
| [Pilot Integration into Kubernetes Service Discovery](/docs/setup/kubernetes/) | Stable
| [Attribute Expression Language](/docs/reference/config/policy-and-telemetry/expression-language/) | Stable
| [Mixer Adapter Authoring Model](/blog/2017/adapter-model/) | Stable
| [VM: Envoy Installation, Traffic Interception and Service Registration](/docs/guides/integrating-vms/) | Alpha
| [VM: Istio Control Plane Installation and Upgrade (Galley, Mixer, Pilot, CA)](https://github.com/istio/istio/issues/2083) | Alpha
| VM: Ansible Envoy Installation, Interception and Registration | Alpha
| [Kubernetes: Istio Control Plane Upgrade]({{home}}/docs/setup/kubernetes/) | Beta
| [Pilot Integration into Consul]({{home}}/docs/setup/consul/quick-start.html) | Alpha
| [Pilot Integration into Eureka]({{home}}/docs/setup/consul/quick-start.html) | Alpha
| [Pilot Integration into Cloud Foundry Service Discovery]({{home}}/docs/setup/consul/quick-start.html) | Alpha
| [Kubernetes: Istio Control Plane Upgrade](/docs/setup/kubernetes/) | Beta
| [Pilot Integration into Consul](/docs/setup/consul/quick-start/) | Alpha
| [Pilot Integration into Eureka](/docs/setup/consul/quick-start/) | Alpha
| [Pilot Integration into Cloud Foundry Service Discovery](/docs/setup/consul/quick-start/) | Alpha
| [Basic Config Resource Validation](https://github.com/istio/istio/issues/1894) | Alpha
| Mixer Telemetry Collection (Tracing, Logging, Monitoring) | Alpha
| [Custom Mixer Build Model](https://github.com/istio/istio/wiki/Mixer-Adapter-Dev-Guide) | Alpha
| Enable API attributes using an IDL | Alpha
| [Helm]({{home}}/docs/setup/kubernetes/helm-install.html) | Alpha
| [Multicluster Mesh]({{home}}/docs/setup/kubernetes/multicluster-install.html) | Alpha
| [Helm](/docs/setup/kubernetes/helm-install/) | Alpha
| [Multicluster Mesh](/docs/setup/kubernetes/multicluster-install/) | Alpha
> <img src="{{home}}/img/bulb.svg" alt="Bulb" title="Help" style="width: 32px; display:inline" />
Please get in touch by joining our [community]({{home}}/community.html) if there are features you'd like to see in our future releases!
> <img src="/img/bulb.svg" alt="Bulb" title="Help" style="width: 32px; display:inline" />
Please get in touch by joining our [community](/community/) if there are features you'd like to see in our future releases!

3
content/about/intro.md
View File

@ -1,10 +1,7 @@
---
title: What is Istio?
description: Context about what problems Istio is designed to solve.
weight: 1
toc: false
---
Istio is an open platform that provides a uniform way to connect, manage,

4
content/about/notes/0.1.md
View File

@ -1,10 +1,8 @@
---
title: Istio 0.1
weight: 100
toc: false
redirect_from:
aliases:
- /docs/welcome/notes/0.1.html
---

4
content/about/notes/0.2.md
View File

@ -1,9 +1,7 @@
---
title: Istio 0.2
weight: 99
redirect_from:
aliases:
- /docs/welcome/notes/0.2.html
---

10
content/about/notes/0.3.md
View File

@ -1,18 +1,14 @@
---
title: Istio 0.3
weight: 98
redirect_from:
aliases:
- /docs/welcome/notes/0.3.html
---
{% include home.html %}
## General
Starting with 0.3, Istio is switching to a monthly release cadence. We hope this will help accelerate our ability
to deliver timely improvements. See [here]({{home}}/about/feature-stages.html) for information on the state of individual features
to deliver timely improvements. See [here](/about/feature-stages/) for information on the state of individual features
for this release.
This is a fairly modest release in terms of new features as the team put emphasis on internal
@ -36,7 +32,7 @@ which helps with incremental migration to Istio.
significant drop in average latency for authorization checks.
- **Improved list Adapter**. The Mixer 'list' adapter now supports regular expression matching. See the adapter's
[configuration options]({{home}}/docs/reference/config/policy-and-telemetry/adapters/list.html) for details.
[configuration options](/docs/reference/config/policy-and-telemetry/adapters/list/) for details.
- **Config Validation**. Mixer does more extensive validation of configuration state in order to catch problems earlier.
We expect to invest more in this area in coming releases.

7
content/about/notes/0.4.md
View File

@ -1,13 +1,10 @@
---
title: Istio 0.4
weight: 97
toc: false
redirect_from:
aliases:
- /docs/welcome/notes/0.4.html
---
{% include home.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:
@ -22,7 +19,7 @@ possible for Pilot to discover CF services and service instances.
- **Helm Charts**. We now provide helm charts to install Istio.
- **Enhanced Attribute Expressions**. Mixer's expression language gained a few new functions
to make it easier to write policy rules. [Learn more]({{home}}/docs/reference/config/policy-and-telemetry/expression-language.html)
to make it easier to write policy rules. [Learn more](/docs/reference/config/policy-and-telemetry/expression-language/)
If you're into the nitty-gritty details, you can see our more detailed low-level
release notes [here](https://github.com/istio/istio/wiki/v0.4.0).

13
content/about/notes/0.5.md
View File

@ -1,10 +1,7 @@
---
title: Istio 0.5
weight: 96
---
{% include home.html %}
In addition to the usual pile of bug fixes and performance improvements, this release includes the new or
updated features detailed below.
@ -19,7 +16,7 @@ information on customized Istio deployments.
[mutating webhook feature](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9.md#api-machinery) to provide automatic
pod-level proxy injection. Automatic injection requires Kubernetes 1.9 or beyond and
therefore doesn't work on older versions. The alpha initializer mechanism is no longer supported.
[Learn more]({{home}}/docs/setup/kubernetes/sidecar-injection.html#automatic-sidecar-injection)
[Learn more](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection)
- **Revised Traffic Rules**. Based on user feedback, we have made significant changes to Istio's traffic management
(routing rules, destination rules, etc.). We would love your continuing feedback while we polish this in the coming weeks.
@ -30,10 +27,10 @@ therefore doesn't work on older versions. The alpha initializer mechanism is no
providing a flexible fine-grained access control mechanism. [Learn more](https://docs.google.com/document/d/1U2XFmah7tYdmC5lWkk3D43VMAAQ0xkBatKmohf90ICA/edit#heading=h.fmlgl8m03gfy)
- **Istio RBAC**. Mixer now has a role-based access control adapter.
[Learn more]({{home}}/docs/concepts/security/rbac.html)
[Learn more](/docs/concepts/security/rbac/)
- **Fluentd**. Mixer now has an adapter for log collection through [fluentd](https://www.fluentd.org).
[Learn more]({{home}}/docs/tasks/telemetry/fluentd.html)
[Learn more](/docs/tasks/telemetry/fluentd/)
- **Stdio**. The stdio adapter now lets you log to files with support for log rotation & backup, along with a host
of controls.
@ -41,12 +38,12 @@ of controls.
## Security
- **Bring Your Own CA**. There have been many enhancements to the 'bring your own CA' feature.
[Learn more]({{home}}/docs/tasks/security/plugin-ca-cert.html)
[Learn more](/docs/tasks/security/plugin-ca-cert/)
- **PKCS8**. Add support for PKCS8 keys to Istio PKI.
- **Istio RBAC** Istio RBAC provides access control for services in Istio mesh.
[Learn more]({{home}}/docs/concepts/security/rbac.html).
[Learn more](/docs/concepts/security/rbac/).
## Other

13
content/about/notes/0.6.md
View File

@ -1,10 +1,7 @@
---
title: Istio 0.6
weight: 95
---
{% include home.html %}
In addition to the usual pile of bug fixes and performance improvements, this release includes the new or
updated features detailed below.
@ -17,13 +14,13 @@ proxy. [Learn more](https://github.com/mandarjog/istioluawebhook)
## Mixer adapters
- **SolarWinds**. Mixer can now interface to AppOptics and Papertrail.
[Learn more]({{home}}/docs/reference/config/policy-and-telemetry/adapters/solarwinds.html)
[Learn more](/docs/reference/config/policy-and-telemetry/adapters/solarwinds/)
- **Redisquota**. Mixer now supports a Redis-based adapter for rate limit tracking.
[Learn more]({{home}}/docs/reference/config/policy-and-telemetry/adapters/redisquota.html)
[Learn more](/docs/reference/config/policy-and-telemetry/adapters/redisquota/)
- **Datadog**. Mixer now provides an adapter to deliver metric data to a Datadog agent.
[Learn more]({{home}}/docs/reference/config/policy-and-telemetry/adapters/datadog.html)
[Learn more](/docs/reference/config/policy-and-telemetry/adapters/datadog/)
## Other
@ -33,10 +30,10 @@ functionality. This may be useful in large deployments for better scaling of Mix
- **Monitoring Dashboards**. There are now preliminary Mixer & Pilot monitoring dashboard in Grafana.
- **Servicegraph Visualization**. Servicegraph has a new visualization. [Learn more]({{home}}/docs/tasks/telemetry/servicegraph.html).
- **Servicegraph Visualization**. Servicegraph has a new visualization. [Learn more](/docs/tasks/telemetry/servicegraph/).
- **Liveness and Readiness Probes**. Istio components now provide canonical liveness and readiness
probe support to help ensure mesh infrastructure health. [Learn more]({{home}}/docs/tasks/security/health-check.html)
probe support to help ensure mesh infrastructure health. [Learn more](/docs/tasks/security/health-check/)
- **Egress Policy and Telemetry**. Istio can monitor traffic to external services defined by EgressRule or External Service. Istio can also apply
Mixer policies on this traffic.

5
content/about/notes/0.7.md
View File

@ -1,10 +1,7 @@
---
title: Istio 0.7
weight: 94
---
{% include home.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.
@ -18,5 +15,5 @@ change in 0.8 and beyond.
Known Issues:
Our [helm chart](https://istio.io/docs/setup/kubernetes/helm.html)
Our [helm chart](/docs/setup/kubernetes/helm-install/)
currently requires some workaround to apply the chart correctly, see [4701](https://github.com/istio/istio/issues/4701) for details.

16
content/about/notes/0.8.md
View File

@ -1,9 +1,7 @@
---
title: Istio 0.8
weight: 93
---
{% include home.html %}
In addition to the usual pile of bug fixes and performance improvements, this release includes the new or
updated features detailed below.
@ -11,17 +9,17 @@ updated features detailed below.
## Networking
- **Revamped Traffic Management Model**. We're finally ready to take the wraps off our
[new traffic management configuration model]({{home}}/blog/2018/v1alpha3-routing.html).
[new traffic management configuration model](/blog/2018/v1alpha3-routing/).
This model adds many new features and addresses usability issues
with the prior model. There is a conversion tool built into `istioctl` to help migrate your config from
the old model. [Try out the new traffic management model]({{home}}/docs/tasks/traffic-management).
the old model. [Try out the new traffic management model](/docs/tasks/traffic-management).
- **Envoy V2**. Users can choose to inject Envoy V2 as the sidecar. In this mode, Pilot uses Envoy's new API to push configuration to the data plane. This new approach
increases effective scalability and should eliminate spurious 404 errors. [TBD: docs on how to control this?]
- **Gateway for Ingress/Egress**. We no longer support combining Kubernetes Ingress specs with Istio route rules,
as it has led to several bugs and reliability issues. Istio now supports a platform independent ingress/egress
[Gateway]({{home}}/docs/concepts/traffic-management/rules-configuration.html#gateways) that works across
[Gateway](/docs/concepts/traffic-management/rules-configuration/#gateways) that works across
Kubernetes and Cloud Foundry and works seamlessly with the routing rules.
- **Constrained Inbound Ports**. We now restrict the inbound ports in a pod to the ones declared by the apps running inside that pod.
@ -36,7 +34,7 @@ and workloads can authenticate each other across the mesh.
- **Authentication Policy**. We've introduced authentication policy that can be used to configure service-to-service
authentication (mutual TLS) and end user authentication. This is the recommended way for enabling mutual TLS
(over the existing config flag and service annotations). [Learn more]({{home}}/docs/tasks/security/authn-policy.html).
(over the existing config flag and service annotations). [Learn more](/docs/tasks/security/authn-policy/).
## Telemetry
@ -48,13 +46,13 @@ Istio telemetry pipeline, just like services in the mesh.
- **A la Carte Istio**. Istio has a rich set of features, however you don't need to install or consume them all together. By using
Helm or `istioctl gen-deploy`, users can install only the features they want. For example, users can install Pilot only and enjoy traffic
management functionality without dealing with Mixer or Citadel.
Learn more about [customization through Helm](https://istio.io/docs/setup/kubernetes/helm-install.html#customization-with-helm)
and about [`istioctl gen-deploy`](https://istio.io/docs/reference/commands/istioctl.html#istioctl%20gen-deploy).
Learn more about [customization through Helm](/docs/setup/kubernetes/helm-install/#customization-with-helm)
and about [`istioctl gen-deploy`](/docs/reference/commands/istioctl/#istioctl%20gen-deploy).
## Mixer adapters
- **CloudWatch**. Mixer can now report metrics to AWS CloudWatch.
[Learn more]({{home}}/docs/reference/config/policy-and-telemetry/adapters/cloudwatch.html)
[Learn more](/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/)
## Known issues with 0.8

8
content/about/notes/_index.md
View File

@ -2,17 +2,17 @@
title: Release Notes
description: Description of features and improvements for every Istio release.
weight: 5
redirect_from:
type: section-index
aliases:
- /docs/reference/release-notes.html
- /release-notes
- /docs/welcome/notes/index.html
- /docs/references/notes
toc: false
---
{% include section-index.html docs=site.about %}
The latest Istio monthly release is {{site.data.istio.version}} ([release notes]({{site.data.istio.version}}.html)). You can
[download {{site.data.istio.version}}](https://github.com/istio/istio/releases) with:
The latest Istio snapshot release is {{< istio_version >}} ([release notes](/about/notes/{{< istio_version >}}/)). You can
[download {{< istio_version >}}](https://github.com/istio/istio/releases) with:
```command
$ curl -L https://git.io/getLatestIstio | sh -

3
content/about/release-cadence.md
View File

@ -3,7 +3,6 @@ title: Build & Release Cadence
description: How we manage, number, and support Istio releases.
weight: 5
---
{% include home.html %}
We produce new builds of Istio on a daily basis. Around once a month or so, we take one of these daily
builds and run it through a number of additional qualification tests and tag the build as a Snapshot release.
@ -24,7 +23,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]({{home}}/about/notes).
You can find high-level releases notes for each LTS release [here](/about/notes).
## Naming Scheme

29
content/blog/2017/0.1-announcement.md
View File

@ -1,17 +1,16 @@
---
title: Introducing Istio
description: Istio 0.1 announcement
publishdate: 2018-05-24
publishdate: 2017-05-24
subtitle: A robust service mesh for microservices
attribution: The Istio Team
weight: 100
redirect_from:
- /blog/istio-service-mesh-for-microservices.html
- /blog/0.1-announcement.html
aliases:
- /blog/istio-service-mesh-for-microservices.html
- /blog/0.1-announcement.html
---
{% include home.html %}
Google, IBM, and Lyft are proud to announce the first public release of [Istio]({{home}}/): 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.
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.
Istio adds traffic management to microservices and creates a basis for value-add capabilities like security, monitoring, routing, connectivity management and policy. The software is built using the battle-tested [Envoy](https://envoyproxy.github.io/envoy/) proxy from Lyft, and gives visibility and control over traffic *without requiring any changes to application code*. Istio gives CIOs a powerful tool to enforce security, policy and compliance requirements across the enterprise.
## Background
@ -33,15 +32,15 @@ Google, IBM and Lyft joined forces to create Istio from a desire to provide a re
**Fleet-wide Visibility**: Failures happen, and operators need tools to stay on top of the health of clusters and their graphs of microservices. Istio produces detailed monitoring data about application and network behaviors that is rendered using [Prometheus](https://prometheus.io/) & [Grafana](https://github.com/grafana/grafana), and can be easily extended to send metrics and logs to any collection, aggregation and querying system. Istio enables analysis of performance hotspots and diagnosis of distributed failure modes with [Zipkin](https://github.com/openzipkin/zipkin) tracing.
{% include image.html width="100%" ratio="55.42%"
link="./img/istio_grafana_dashboard-new.png"
{{< image width="100%" ratio="55.42%"
link="../img/istio_grafana_dashboard-new.png"
caption="Grafana Dashboard with Response Size"
%}
>}}
{% include image.html width="100%" ratio="29.91%"
link="./img/istio_zipkin_dashboard.png"
{{< image width="100%" ratio="29.91%"
link="../img/istio_zipkin_dashboard.png"
caption="Zipkin Dashboard"
%}
>}}
**Resiliency and efficiency**: When developing microservices, operators need to assume that the network will be unreliable. Operators can use retries, load balancing, flow-control (HTTP/2), and circuit-breaking to compensate for some of the common failure modes due to an unreliable network. Istio provides a uniform approach to configuring these features, making it easier to operate a highly resilient service mesh.
@ -58,11 +57,11 @@ Google, IBM and Lyft joined forces to create Istio from a desire to provide a re
Istio is a completely open development project. Today we are releasing version 0.1, which works in a Kubernetes cluster, and we plan to have major new
releases every 3 months, including support for additional environments. Our goal is to enable developers and operators to rollout and operate microservices
with agility, complete visibility of the underlying network, and uniform control and security in all environments. We look forward to working with the Istio
community and our partners towards these goals, following our [roadmap]({{home}}/docs/reference/release-roadmap.html).
community and our partners towards these goals, following our [roadmap](/about/feature-stages/).
Visit [here](https://github.com/istio/istio/releases) to get the latest released bits.
View the [presentation]({{home}}/talks/istio_talk_gluecon_2017.pdf) from GlueCon 2017, where Istio was unveiled.
View the [presentation](/talks/istio_talk_gluecon_2017.pdf) from GlueCon 2017, where Istio was unveiled.
## Community
@ -76,7 +75,7 @@ this journey.
To get involved, connect with us via any of these channels:
* [istio.io]({{home}}) for documentation and examples.
* [istio.io]() for documentation and examples.
* The [istio-users@googlegroups.com](https://groups.google.com/forum/#!forum/istio-users) mailing list for general discussions,
or [istio-announce@googlegroups.com](https://groups.google.com/forum/#!forum/istio-announce) for key announcements regarding the project.

21
content/blog/2017/0.1-auth.md
View File

@ -5,15 +5,14 @@ publishdate: 2017-05-25
subtitle: Secure by default service to service communications
attribution: The Istio Team
weight: 99
redirect_from:
- /blog/0.1-auth.html
- /blog/istio-auth-for-microservices.html
aliases:
- /blog/0.1-auth.html
- /blog/istio-auth-for-microservices.html
---
{% include home.html %}
Conventional network security approaches fail to address security threats to distributed applications deployed in dynamic production environments. Today, we describe how Istio Auth enables enterprises to transform their security posture from just protecting the edge to consistently securing all inter-service communications deep within their applications. With Istio Auth, developers and operators can protect services with sensitive data against unauthorized insider access and they can achieve this without any changes to the application code!
Istio Auth is the security component of the broader [Istio platform]({{home}}/). It incorporates the learnings of securing millions of microservice
Istio Auth is the security component of the broader [Istio platform](/). It incorporates the learnings of securing millions of microservice
endpoints in Google’s production environment.
## Background
@ -42,10 +41,10 @@ Istio Auth is based on industry standards like mutual TLS and X.509. Furthermore
The diagram below provides an overview of the Istio Auth service authentication architecture on Kubernetes.
{% include image.html width="100%" ratio="56.25%"
link="./img/istio_auth_overview.svg"
{{< image width="100%" ratio="56.25%"
link="../img/istio_auth_overview.svg"
caption="Istio Auth Overview"
%}
>}}
The above diagram illustrates three key security features:
@ -77,10 +76,10 @@ Istio Auth provides a per-cluster CA (Certificate Authority) and automated key &
The following diagram explains the end to end Istio Auth authentication workflow on Kubernetes:
{% include image.html width="100%" ratio="56.25%"
link="./img/istio_auth_workflow.svg"
{{< image width="100%" ratio="56.25%"
link="../img/istio_auth_workflow.svg"
caption="Istio Auth Workflow"
%}
>}}
Istio Auth is part of the broader security story for containers. Red Hat, a partner on the development of Kubernetes, has identified [10 Layers](https://www.redhat.com/en/resources/container-security-openshift-cloud-devops-whitepaper) of container security. Istio and Istio Auth addresses two of these layers: "Network Isolation" and "API and Service Endpoint Management". As cluster federation evolves on Kubernetes and other platforms, our intent is for Istio to secure communications across services spanning multiple federated clusters.

19
content/blog/2017/0.1-canary.md
View File

@ -2,20 +2,13 @@
title: Canary Deployments using Istio
description: Using Istio to create autoscaled canary deployments
publishdate: 2017-06-14
subtitle:
attribution: Frank Budinsky
weight: 98
redirect_from:
aliases:
- /blog/canary-deployments-using-istio.html
---
{% include home.html %}
> This post was updated on May 16, 2018 to use the latest version of the traffic management model.
One of the benefits of the [Istio]({{home}}) project is that it provides the control needed to deploy canary services. The idea behind canary deployment (or rollout) is to introduce a new version of a service by first testing it using a small percentage of user traffic, and then if all goes well, increase, possibly gradually in increments, the percentage while simultaneously phasing out the old version. If anything goes wrong along the way, we abort and rollback to the previous version. In its simplest form, the traffic sent to the canary version is a randomly selected percentage of requests, but in more sophisticated schemes it can be based on the region, user, or other properties of the request.
> This post was updated on May 16, 2018 to use the latest version of the traffic management model. One of the benefits of the [Istio]() project is that it provides the control needed to deploy canary services. The idea behind canary deployment (or rollout) is to introduce a new version of a service by first testing it using a small percentage of user traffic, and then if all goes well, increase, possibly gradually in increments, the percentage while simultaneously phasing out the old version. If anything goes wrong along the way, we abort and rollback to the previous version. In its simplest form, the traffic sent to the canary version is a randomly selected percentage of requests, but in more sophisticated schemes it can be based on the region, user, or other properties of the request.
Depending on your level of expertise in this area, you may wonder why Istio's support for canary deployment is even needed, given that platforms like Kubernetes already provide a way to do [version rollout](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) and [canary deployment](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments). Problem solved, right? Well, not exactly. Although doing a rollout this way works in simple cases, it’s very limited, especially in large scale cloud environments receiving lots of (and especially varying amounts of) traffic, where autoscaling is needed.
@ -31,7 +24,7 @@ Whether we use one deployment or two, canary management using deployment feature
With Istio, traffic routing and replica deployment are two completely independent functions. The number of pods implementing services are free to scale up and down based on traffic load, completely orthogonal to the control of version traffic routing. This makes managing a canary version in the presence of autoscaling a much simpler problem. Autoscalers may, in fact, respond to load variations resulting from traffic routing changes, but they are nevertheless functioning independently and no differently than when loads change for other reasons.
Istio’s [routing rules]({{home}}/docs/concepts/traffic-management/rules-configuration.html) also provide other important advantages; you can easily control
Istio’s [routing rules](/docs/concepts/traffic-management/rules-configuration/) also provide other important advantages; you can easily control
fine grain traffic percentages (e.g., route 1% of traffic without requiring 100 pods) and you can control traffic using other criteria (e.g., route traffic for specific users to the canary version). To illustrate, let’s look at deploying the **helloworld** service and see how simple the problem becomes.
We begin by defining the **helloworld** Service, just like any other Kubernetes service, something like this:
@ -86,9 +79,9 @@ spec:
Note that this is exactly the same way we would do a [canary deployment](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) using plain Kubernetes, but in that case we would need to adjust the number of replicas of each Deployment to control the distribution of traffic. For example, to send 10% of the traffic to the canary version (**v2**), the replicas for **v1** and **v2** could be set to 9 and 1, respectively.
However, since we are going to deploy the service in an [Istio enabled]({{home}}/docs/setup/) cluster, all we need to do is set a routing
However, since we are going to deploy the service in an [Istio enabled](/docs/setup/) cluster, all we need to do is set a routing
rule to control the traffic distribution. For example if we want to send 10% of the traffic to the canary, we could use the
[istioctl]({{home}}/docs/reference/commands/istioctl.html) command to set a routing rule something like this:
[istioctl](/docs/reference/commands/istioctl/) command to set a routing rule something like this:
```bash
cat <<EOF | istioctl create -f -
@ -215,5 +208,5 @@ As before, the autoscalers bound to the 2 version Deployments will automatically
In this article we’ve shown how Istio supports general scalable canary deployments, and how this differs from the basic deployment support in Kubernetes. Istio’s service mesh provides the control necessary to manage traffic distribution with complete independence from deployment scaling. This allows for a simpler, yet significantly more functional, way to do canary test and rollout.
Intelligent routing in support of canary deployment is just one of the many features of Istio that will make the production deployment of large-scale microservices-based applications much simpler. Check out [istio.io]({{home}}) for more information and to try it out.
Intelligent routing in support of canary deployment is just one of the many features of Istio that will make the production deployment of large-scale microservices-based applications much simpler. Check out [istio.io]() for more information and to try it out.
The sample code used in this article can be found [here](https://github.com/istio/istio/tree/master/samples/helloworld).

12
content/blog/2017/0.1-using-network-policy.md
View File

@ -4,13 +4,10 @@ description: How Kubernetes Network Policy relates to Istio policy
publishdate: 2017-08-10
subtitle:
attribution: Spike Curtis
weight: 97
redirect_from:
aliases:
- /blog/using-network-policy-in-concert-with-istio.html
---
{% include home.html %}
The use of Network Policy to secure applications running on Kubernetes is a now a widely accepted industry best practice. Given that Istio also supports policy, we want to spend some time explaining how Istio policy and Kubernetes Network Policy interact and support each other to deliver your application securely.
@ -106,11 +103,10 @@ spec:
Here is the service graph for the Bookinfo application.
{% assign url = home | append: "/docs/guides/img/bookinfo/withistio.svg" %}
{% include image.html width="80%" ratio="59.08%"
link=url
{{< image width="80%" ratio="59.08%"
link="/docs/guides/img/bookinfo/withistio.svg"
caption="Bookinfo Service Graph"
%}
>}}
This graph shows every connection that a correctly functioning application should be allowed to make. All other connections, say from the Istio Ingress directly to the Rating service, are not part of the application. Let’s lock out those extraneous connections so they cannot be used by an attacker. Imagine, for example, that the Ingress pod is compromised by an exploit that allows an attacker to run arbitrary code. If we only allow connections to the Product Page pods using Network Policy, the attacker has gained no more access to my application backends _even though they have compromised a member of the service mesh_.

9
content/blog/2017/0.2-announcement.md
View File

@ -4,14 +4,11 @@ description: Istio 0.2 announcement
publishdate: 2017-10-10
subtitle: Improved mesh and support for multiple environments
attribution: The Istio Team
weight: 96
toc: false
redirect_from:
aliases:
- /blog/istio-0.2-announcement.html
---
{% include home.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.
@ -42,11 +39,11 @@ you easily integrate your solution with Istio.
* _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]({{home}}/docs/setup/consul/quick-start.html) and [Eureka]({{home}}/docs/setup/eureka/quick-start.html). Istio Pilot can now run standalone outside Kubernetes, consuming information from these systems, and manage the Envoy fleet in VMs or containers.
* _Running outside Kubernetes_: We know many customers use other service registry and orchestration solutions like [Consul/Nomad](/docs/setup/consul/quick-start/) and [Eureka](/docs/setup/eureka/quick-start/). 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]({{home}}/docs/reference/release-roadmap.html) 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.
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.

6
content/blog/2017/_index.md
View File

@ -1,10 +1,6 @@
---
title: 2017 Posts
description: Blog posts for 2017
weight: 20
toc: false
type: section-index
---
{% include section-index.html docs=site.blog %}

32
content/blog/2017/adapter-model.md
View File

@ -4,13 +4,10 @@ description: Provides an overview of the Mixer plug-in architecture
publishdate: 2017-11-03
subtitle: Extending Istio to integrate with a world of infrastructure backends
attribution: Martin Taillefer
weight: 95
redirect_from:
aliases:
- /blog/mixer-adapter-model.html
---
{% include home.html %}
Istio 0.2 introduced a new Mixer adapter model which is intended to increase Mixer’s flexibility to address a varied set of infrastructure backends. This post intends to put the adapter model in context and explain how it works.
@ -29,13 +26,12 @@ Adapters are Go packages that are directly linked into the Mixer binary. It’s
## Philosophy
Mixer is essentially an attribute processing and routing machine. The proxy sends it [attributes]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes) as part of doing precondition checks and telemetry reports, which it turns into a series of calls into adapters. The operator supplies configuration which describes how to map incoming attributes to inputs for the adapters.
Mixer is essentially an attribute processing and routing machine. The proxy sends it [attributes](/docs/concepts/policies-and-telemetry/config/#attributes) as part of doing precondition checks and telemetry reports, which it turns into a series of calls into adapters. The operator supplies configuration which describes how to map incoming attributes to inputs for the adapters.
{% assign url = home | append: "/docs/concepts/policies-and-telemetry/img/machine.svg" %}
{% include image.html width="60%" ratio="42.60%"
link=url
{{< image width="60%" ratio="42.60%"
link="/docs/concepts/policies-and-telemetry/img/machine.svg"
caption="Attribute Machine"
%}
>}}
Configuration is a complex task. In fact, evidence shows that the overwhelming majority of service outages are caused by configuration errors. To help combat this, Mixer’s configuration model enforces a number of constraints designed to avoid errors. For example, the configuration model uses strong typing to ensure that only meaningful attributes or attribute expressions are used in any given context.
@ -43,26 +39,26 @@ Configuration is a complex task. In fact, evidence shows that the overwhelming m
Each adapter that Mixer uses requires some configuration to operate. Typically, adapters need things like the URL to their backend, credentials, caching options, and so forth. Each adapter defines the exact configuration data it needs via a [protobuf](https://developers.google.com/protocol-buffers/) message.
You configure each adapter by creating [*handlers*]({{home}}/docs/concepts/policies-and-telemetry/config.html#handlers) for them. A handler is a
You configure each adapter by creating [*handlers*](/docs/concepts/policies-and-telemetry/config/#handlers) for them. A handler is a
configuration resource which represents a fully configured adapter ready for use. There can be any number of handlers for a single adapter, making it possible to reuse an adapter in different scenarios.
## Templates: adapter input schema
Mixer is typically invoked twice for every incoming request to a mesh service, once for precondition checks and once for telemetry reporting. For every such call, Mixer invokes one or more adapters. Different adapters need different pieces of data as input in order to do their work. A logging adapter needs a log entry, a metric adapter needs a metric, an authorization adapter needs credentials, etc.
Mixer [*templates*]({{home}}/docs/reference/config/policy-and-telemetry/templates/) are used to describe the exact data that an adapter consumes at request time.
Mixer [*templates*](/docs/reference/config/policy-and-telemetry/templates/) are used to describe the exact data that an adapter consumes at request time.
Each template is specified as a [protobuf](https://developers.google.com/protocol-buffers/) message. A single template describes a bundle of data that is delivered to one or more adapters at runtime. Any given adapter can be designed to support any number of templates, the specific templates the adapter supports is determined by the adapter developer.
[metric]({{home}}/docs/reference/config/policy-and-telemetry/templates/metric.html) and [logentry]({{home}}/docs/reference/config/policy-and-telemetry/templates/logentry.html) are two of the most essential templates used within Istio. They represent respectively the payload to report a single metric and a single log entry to appropriate backends.
[`metric`](/docs/reference/config/policy-and-telemetry/templates/metric/) and [`logentry`](/docs/reference/config/policy-and-telemetry/templates/logentry/) are two of the most essential templates used within Istio. They represent respectively the payload to report a single metric and a single log entry to appropriate backends.
## Instances: attribute mapping
You control which data is delivered to individual adapters by creating
[*instances*]({{home}}/docs/concepts/policies-and-telemetry/config.html#instances).
Instances control how Mixer uses the [attributes]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes) delivered
[*instances*](/docs/concepts/policies-and-telemetry/config/#instances).
Instances control how Mixer uses the [attributes](/docs/concepts/policies-and-telemetry/config/#attributes) delivered
by the proxy into individual bundles of data that can be routed to different adapters.
Creating instances generally requires using [attribute expressions]({{home}}/docs/concepts/policies-and-telemetry/config.html#attribute-expressions). The point of these expressions is to use any attribute or literal value in order to produce a result that can be assigned to an instance’s field.
Creating instances generally requires using [attribute expressions](/docs/concepts/policies-and-telemetry/config/#attribute-expressions). The point of these expressions is to use any attribute or literal value in order to produce a result that can be assigned to an instance’s field.
Every instance field has a type, as defined in the template, every attribute has a
[type](https://github.com/istio/api/blob/master/policy/v1beta1/value_type.proto), and every attribute expression has a type.
@ -72,7 +68,7 @@ to a string field. This kind of strong typing is designed to minimize the risk
## Rules: delivering data to adapters
The last piece to the puzzle is telling Mixer which instances to send to which handler and when. This is done by
creating [*rules*]({{home}}/docs/concepts/policies-and-telemetry/config.html#rules). Each rule identifies a specific handler and the set of
creating [*rules*](/docs/concepts/policies-and-telemetry/config/#rules). Each rule identifies a specific handler and the set of
instances to send to that handler. Whenever Mixer processes an incoming call, it invokes the indicated handler and gives it the specific set of instances for processing.
Rules contain matching predicates. A predicate is an attribute expression which returns a true/false value. A rule only takes effect if its predicate expression returns true. Otherwise, it’s like the rule didn’t exist and the indicated handler isn’t invoked.
@ -89,6 +85,6 @@ The refreshed Mixer adapter model is designed to provide a flexible framework to
Handlers provide configuration data for individual adapters, templates determine exactly what kind of data different adapters want to consume at runtime, instances let operators prepare this data, rules direct the data to one or more handlers.
You can learn more about Mixer's overall architecture [here]({{home}}/docs/concepts/policies-and-telemetry/), and learn the specifics of templates, handlers,
and rules [here]({{home}}/docs/reference/config/policy-and-telemetry). You can find many examples of Mixer configuration resources in the Bookinfo sample
You can learn more about Mixer's overall architecture [here](/docs/concepts/policies-and-telemetry/), and learn the specifics of templates, handlers,
and rules [here](/docs/reference/config/policy-and-telemetry). You can find many examples of Mixer configuration resources in the Bookinfo sample
[here](https://github.com/istio/istio/tree/master/samples/bookinfo/kube).

21
content/blog/2017/mixer-spof-myth.md
View File

@ -4,16 +4,13 @@ description: Improving availability and reducing latency
publishdate: 2017-12-07
subtitle: Improving availability and reducing latency
attribution: Martin Taillefer
weight: 94
redirect_from:
aliases:
- /blog/posts/2017/mixer-spof-myth.html
- /blog/mixer-spof-myth.html
---
{% include home.html %}
As [Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html) is in the request path, it is natural to question how it impacts
As [Mixer](/docs/concepts/policies-and-telemetry/overview/) is in the request path, it is natural to question how it impacts
overall system availability and latency. A common refrain we hear when people first glance at Istio architecture diagrams is
"Isn't this just introducing a single point of failure?"
@ -36,11 +33,11 @@ In 2014, we started an initiative to create a replacement architecture that woul
The older system was built around a centralized fleet of fairly heavy proxies into which all incoming traffic would flow, before being forwarded to the services where the real work was done. The newer architecture jettisons the shared proxy design and instead consists of a very lean and efficient distributed sidecar proxy sitting next to service instances, along with a shared fleet of sharded control plane intermediaries:
{% include image.html width="75%" ratio="74.79%"
link="./img/mixer-spof-myth-1.svg"
{{< image width="75%" ratio="74.79%"
link="../img/mixer-spof-myth-1.svg"
title="Google System Topology"
caption="Google's API & Service Management System"
%}
>}}
Look familiar? Of course: it’s just like Istio! Istio was conceived as a second generation of this distributed proxy architecture. We took the core lessons from this internal system, generalized many of the concepts by working with our partners, and created Istio.
@ -48,10 +45,10 @@ Look familiar? Of course: it’s just like Istio! Istio was conceived as a secon
As shown in the diagram below, Mixer sits between the mesh and the infrastructure backends that support it:
{% include image.html width="75%" ratio="65.89%"
link="./img/mixer-spof-myth-2.svg"
{{< image width="75%" ratio="65.89%"
link="../img/mixer-spof-myth-2.svg"
caption="Istio Topology"
%}
>}}
The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry.
The sidecar has local caching such that a relatively large percentage of precondition checks can be performed from cache. Additionally, the
@ -123,5 +120,5 @@ cache, we spend more time in Mixer to respond to requests than we should. We’r
that Mixer imparts in the synchronous precondition check case.
We hope this post makes you appreciate the inherent benefits that Mixer brings to Istio.
Don’t hesitate to post comments or questions to [istio-integrations@](https://groups.google.com/forum/#!forum/istio-integrations).
Don’t hesitate to post comments or questions to [istio-policies-and-telemetry@](https://groups.google.com/forum/#!forum/istio-policies-and-telemetry).

6
content/blog/2018/_index.md
View File

@ -1,10 +1,6 @@
---
title: 2018 Posts
description: Blog posts for 2018
weight: 10
toc: false
type: section-index
---
{% include section-index.html docs=site.blog %}

119
content/blog/2018/aws-nlb.md
View File

@ -6,9 +6,8 @@ subtitle: Ingress AWS Network Load Balancer
attribution: Julien SENON
weight: 89
---
{% include home.html %}
This blog entry will provide instructions to use and configure ingress Istio with [AWS Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html).
This post provides instructions to use and configure ingress Istio with [AWS Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html).
Network load balancer (NLB) could be used instead of classical load balancer. You can find [comparison](https://aws.amazon.com/elasticloadbalancing/details/#compare) between different AWS `loadbalancer` for more explanation.
@ -16,71 +15,81 @@ Network load balancer (NLB) could be used instead of classical load balancer. Yo
The following instructions require a Kubernetes **1.9.0 or newer** cluster.
<img src="{{home}}/img/exclamation-mark.svg" alt="Warning" title="Warning" style="width: 32px; display:inline" /> Usage of AWS `nlb` on kubernetes is an alpha feature and not recommended for production clusters.
<img src="/img/exclamation-mark.svg" alt="Warning" title="Warning" style="width: 32px; display:inline" /> Usage of AWS `nlb` on kubernetes is an alpha feature and not recommended for production clusters.
## IAM Policy
You need to apply policy on the master role in order to be able to provision network load balancer.
1. In AWS `iam` console click on policies and click on create a new one:
{% include image.html width="80%" ratio="60%"
link="./img/createpolicystart.png"
{{< image width="80%" ratio="60%"
link="../img/createpolicystart.png"
caption="Create a new policy"
%}
>}}
1. Select `json`:
{% include image.html width="80%" ratio="60%"
link="./img/createpolicyjson.png"
{{< image width="80%" ratio="60%"
link="../img/createpolicyjson.png"
caption="Select json"
%}
1. Copy/paste text bellow:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "kopsK8sNLBMasterPermsRestrictive",
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"ec2:DescribeRegions"
],
"Resource": "*"
}
]
}
```
>}}
1. Copy/paste text below:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "kopsK8sNLBMasterPermsRestrictive",
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"elasticloadbalancing:AddTags",
"elasticloadbalancing:CreateListener",
"elasticloadbalancing:CreateTargetGroup",
"elasticloadbalancing:DeleteListener",
"elasticloadbalancing:DeleteTargetGroup",
"elasticloadbalancing:DescribeListeners",
"elasticloadbalancing:DescribeLoadBalancerPolicies",
"elasticloadbalancing:DescribeTargetGroups",
"elasticloadbalancing:DescribeTargetHealth",
"elasticloadbalancing:ModifyListener",
"elasticloadbalancing:ModifyTargetGroup",
"elasticloadbalancing:RegisterTargets",
"elasticloadbalancing:SetLoadBalancerPoliciesOfListener"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeVpcs",
"ec2:DescribeRegions"
],
"Resource": "*"
}
]
}
```
1. Click review policy, fill all fields and click create policy:
{% include image.html width="80%" ratio="60%"
link="./img/create_policy.png"
caption="Validate policy"
%}
{{< image width="80%" ratio="60%"
link="../img/create_policy.png"
caption="Validate policy"
>}}
1. Click on roles, select you master role nodes, and click attach policy:
{% include image.html width="100%" ratio="35%"
link="./img/roles_summary.png"
{{< image width="100%" ratio="35%"
link="../img/roles_summary.png"
caption="Attach policy"
%}
>}}
1. Your policy is now attach to your master node.
## Rewrite Istio Ingress Service

50
content/blog/2018/egress-https.md
View File

@ -6,30 +6,28 @@ subtitle: Egress Rules for HTTPS traffic
attribution: Vadim Eisenberg
weight: 93
---
{% include home.html %}
In many cases, not all the parts of a microservices-based application reside in a _service mesh_. Sometimes, the microservices-based applications use functionality provided by legacy systems that reside outside the mesh. We may want to migrate these systems to the service mesh gradually. Until these systems are migrated, they must be accessed by the applications inside the mesh. In other cases, the applications use web services provided by external organizations, often over the World Wide Web.
In this blog post, I modify the [Istio Bookinfo Sample Application]({{home}}/docs/guides/bookinfo.html) to fetch book details from an external web service ([Google Books APIs](https://developers.google.com/books/docs/v1/getting_started)). I show how to enable external HTTPS traffic in Istio by using an _egress rule_. Finally, I explain the current issues related to the egress traffic control in Istio.
In this blog post, I modify the [Istio Bookinfo Sample Application](/docs/guides/bookinfo/) to fetch book details from an external web service ([Google Books APIs](https://developers.google.com/books/docs/v1/getting_started)). I show how to enable external HTTPS traffic in Istio by using an _egress rule_. Finally, I explain the current issues related to the egress traffic control in Istio.
## Bookinfo sample application with external details web service
### Initial setting
To demonstrate the scenario of consuming an external web service, I start with a Kubernetes cluster with [Istio installed]({{home}}/docs/setup/kubernetes/quick-start.html#installation-steps). Then I deploy [Istio Bookinfo Sample Application]({{home}}/docs/guides/bookinfo.html). This application uses the _details_ microservice to fetch book details, such as the number of pages and the publisher. The original _details_ microservice provides the book details without consulting any external service.
To demonstrate the scenario of consuming an external web service, I start with a Kubernetes cluster with [Istio installed](/docs/setup/kubernetes/quick-start/#installation-steps). Then I deploy [Istio Bookinfo Sample Application](/docs/guides/bookinfo/). This application uses the _details_ microservice to fetch book details, such as the number of pages and the publisher. The original _details_ microservice provides the book details without consulting any external service.
The example commands in this blog post work with Istio 0.2+, with or without [Mutual TLS]({{home}}/docs/concepts/security/mutual-tls.html) enabled.
The example commands in this blog post work with Istio 0.2+, with or without [Mutual TLS](/docs/concepts/security/mutual-tls/) enabled.
The Bookinfo configuration files required for the scenario of this post appear starting from [Istio release version 0.5](https://github.com/istio/istio/releases/tag/0.5.0).
The Bookinfo configuration files reside in the `samples/bookinfo/kube` directory of the Istio release archive.
Here is a copy of the end-to-end architecture of the application from the original [Bookinfo Guide]({{home}}/docs/guides/bookinfo.html).
Here is a copy of the end-to-end architecture of the application from the original [Bookinfo Guide](/docs/guides/bookinfo/).
{% assign url = home | append: "/docs/guides/img/bookinfo/withistio.svg" %}
{% include image.html width="80%" ratio="59.08%"
link=url
{{< image width="80%" ratio="59.08%"
link="/docs/guides/img/bookinfo/withistio.svg"
caption="The Original Bookinfo Application"
%}
>}}
### Bookinfo with details version 2
@ -41,10 +39,10 @@ $ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-deta
The updated architecture of the application now looks as follows:
{% include image.html width="80%" ratio="65.16%"
link="./img/bookinfo-details-v2.svg"
{{< image width="80%" ratio="65.16%"
link="../img/bookinfo-details-v2.svg"
caption="The Bookinfo Application with details V2"
%}
>}}
Note that the Google Books web service is outside the Istio service mesh, the boundary of which is marked by a dashed line.
@ -66,18 +64,18 @@ spec:
EOF
```
Let's access the web page of the application, after [determining the ingress IP and port]({{home}}/docs/guides/bookinfo.html#determining-the-ingress-ip-and-port).
Let's access the web page of the application, after [determining the ingress IP and port](/docs/guides/bookinfo/#determining-the-ingress-ip-and-port).
Oops... Instead of the book details we have the _Error fetching product details_ message displayed:
{% include image.html width="80%" ratio="36.01%"
link="./img/errorFetchingBookDetails.png"
{{< image width="80%" ratio="36.01%"
link="../img/errorFetchingBookDetails.png"
caption="The Error Fetching Product Details Message"
%}
>}}
The good news is that our application did not crash. With a good microservice design, we do not have **failure propagation**. In our case, the failing _details_ microservice does not cause the _productpage_ microservice to fail. Most of the functionality of the application is still provided, despite the failure in the _details_ microservice. We have **graceful service degradation**: as you can see, the reviews and the ratings are displayed correctly, and the application is still useful.
So what might have gone wrong? Ah... The answer is that I forgot to enable traffic from inside the mesh to an external service, in this case to the Google Books web service. By default, the Istio sidecar proxies ([Envoy proxies](https://www.envoyproxy.io)) **block all the traffic to destinations outside the cluster**. To enable such traffic, we must define an [egress rule]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#EgressRule).
So what might have gone wrong? Ah... The answer is that I forgot to enable traffic from inside the mesh to an external service, in this case to the Google Books web service. By default, the Istio sidecar proxies ([Envoy proxies](https://www.envoyproxy.io)) **block all the traffic to destinations outside the cluster**. To enable such traffic, we must define an [egress rule](/docs/reference/config/istio.routing.v1alpha1/#EgressRule).
### Egress rule for Google Books web service
@ -101,10 +99,10 @@ EOF
Now accessing the web page of the application displays the book details without error:
{% include image.html width="80%" ratio="34.82%"
link="./img/externalBookDetails.png"
{{< image width="80%" ratio="34.82%"
link="../img/externalBookDetails.png"
caption="Book Details Displayed Correctly"
%}
>}}
Note that our egress rule allows traffic to any domain matching _*.googleapis.com_, on port 443, using the HTTPS protocol. Let's assume for the sake of the example that the applications in our Istio service mesh must access multiple subdomains of _googleapis.com_, for example _www.googleapis.com_ and also _fcm.googleapis.com_. Our rule allows traffic to both _www.googleapis.com_ and _fcm.googleapis.com_, since they both match _*.googleapis.com_. This **wildcard** feature allows us to enable traffic to multiple domains using a single egress rule.
@ -132,15 +130,15 @@ Accessing the web page after deleting the egress rule produces the same error th
There is a caveat to this story. In HTTPS, all the HTTP details (hostname, path, headers etc.) are encrypted, so Istio cannot know the destination domain of the encrypted requests. Well, Istio could know the destination domain by the [SNI](https://tools.ietf.org/html/rfc3546#section-3.1) (_Server Name Indication_) field. This feature, however, is not yet implemented in Istio. Therefore, currently Istio cannot perform filtering of HTTPS requests based on the destination domains.
To allow Istio to perform filtering of egress requests based on domains, the microservices must issue HTTP requests. Istio then opens an HTTPS connection to the destination (performs TLS origination). The code of the microservices must be written differently or configured differently, according to whether the microservice runs inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency]({{home}}/docs/concepts/what-is-istio/goals.html). Sometimes we need to compromise...
To allow Istio to perform filtering of egress requests based on domains, the microservices must issue HTTP requests. Istio then opens an HTTPS connection to the destination (performs TLS origination). The code of the microservices must be written differently or configured differently, according to whether the microservice runs inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency](/docs/concepts/what-is-istio/goals/). Sometimes we need to compromise...
The diagram below shows how the HTTPS traffic to external services is performed. On the top, a microservice outside an Istio service mesh
sends regular HTTPS requests, encrypted end-to-end. On the bottom, the same microservice inside an Istio service mesh must send unencrypted HTTP requests inside a pod, which are intercepted by the sidecar Envoy proxy. The sidecar proxy performs TLS origination, so the traffic between the pod and the external service is encrypted.
{% include image.html width="80%" ratio="65.16%"
link="./img/https_from_the_app.svg"
{{< image width="80%" ratio="65.16%"
link="../img/https_from_the_app.svg"
caption="HTTPS traffic to external services, from outside vs. from inside an Istio service mesh"
%}
>}}
Here is how we code this behavior in the [the Bookinfo details microservice code](https://github.com/istio/istio/blob/master/samples/bookinfo/src/details/details.rb), using the Ruby [net/http module](https://docs.ruby-lang.org/en/2.0.0/Net/HTTP.html):
@ -169,7 +167,7 @@ env:
#### Relation to Istio mutual TLS
Note that the TLS origination in this case is unrelated to [the mutual TLS]({{home}}/docs/concepts/security/mutual-tls.html) applied by Istio. The TLS origination for the external services will work, whether the Istio mutual TLS is enabled or not. The **mutual** TLS secures service-to-service communication **inside** the service mesh and provides each service with a strong identity. In the case of the **external services**, we have **one-way** TLS, the same mechanism used to secure communication between a web browser and a web server. TLS is applied to the communication with external services to verify the identity of the external server and to encrypt the traffic.
Note that the TLS origination in this case is unrelated to [the mutual TLS](/docs/concepts/security/mutual-tls/) applied by Istio. The TLS origination for the external services will work, whether the Istio mutual TLS is enabled or not. The **mutual** TLS secures service-to-service communication **inside** the service mesh and provides each service with a strong identity. In the case of the **external services**, we have **one-way** TLS, the same mechanism used to secure communication between a web browser and a web server. TLS is applied to the communication with external services to verify the identity of the external server and to encrypt the traffic.
### Malicious microservices threat
@ -191,4 +189,4 @@ In Istio, we are working on making Istio egress traffic more secure, and in part
In this blog post I demonstrated how the microservices in an Istio service mesh can consume external web services via HTTPS. By default, Istio blocks all the traffic to the hosts outside the cluster. To enable such traffic, egress rules must be created for the service mesh. It is possible to access the external sites by HTTPS, however the microservices must issue HTTP requests while Istio will perform TLS origination. Currently, no tracing, telemetry and Mixer checks are enabled for the egress traffic. Egress rules are currently not a security feature, so additional mechanisms are required for securing egress traffic. We're working to enable logging/telemetry and security policies for the egress traffic in future releases.
To read more about Istio egress traffic control, see [Control Egress Traffic Task]({{home}}/docs/tasks/traffic-management/egress.html).
To read more about Istio egress traffic control, see [Control Egress Traffic Task](/docs/tasks/traffic-management/egress/).

58
content/blog/2018/egress-tcp.md
View File

@ -6,13 +6,12 @@ subtitle: Egress rules for TCP traffic
attribution: Vadim Eisenberg
weight: 92
---
{% include home.html %}
In my previous blog post, [Consuming External Web Services]({{home}}/blog/2018/egress-https.html), I described how external services can be consumed by in-mesh Istio applications via HTTPS. In this post, I demonstrate consuming external services over TCP. I use the [Istio Bookinfo sample application]({{home}}/docs/guides/bookinfo.html), the version in which the book ratings data is persisted in a MySQL database. I deploy this database outside the cluster and configure the _ratings_ microservice to use it. I define an [egress rule]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#EgressRule) to allow the in-mesh applications to access the external database.
In my previous blog post, [Consuming External Web Services](/blog/2018/egress-https/), I described how external services can be consumed by in-mesh Istio applications via HTTPS. In this post, I demonstrate consuming external services over TCP. I use the [Istio Bookinfo sample application](/docs/guides/bookinfo/), the version in which the book ratings data is persisted in a MySQL database. I deploy this database outside the cluster and configure the _ratings_ microservice to use it. I define an [egress rule](/docs/reference/config/istio.routing.v1alpha1/#EgressRule) to allow the in-mesh applications to access the external database.
## Bookinfo sample application with external ratings database
First, I set up a MySQL database instance to hold book ratings data, outside my Kubernetes cluster. Then I modify the [Bookinfo sample application]({{home}}/docs/guides/bookinfo.html) to use my database.
First, I set up a MySQL database instance to hold book ratings data, outside my Kubernetes cluster. Then I modify the [Bookinfo sample application](/docs/guides/bookinfo/) to use my database.
### Setting up the database for ratings data
@ -118,17 +117,16 @@ Now I am ready to deploy a version of the Bookinfo application that will use my
### Initial setting of Bookinfo application
To demonstrate the scenario of using an external database, I start with a Kubernetes cluster with [Istio installed]({{home}}/docs/setup/kubernetes/quick-start.html#installation-steps). Then I deploy the [Istio Bookinfo sample application]({{home}}/docs/guides/bookinfo.html). This application uses the _ratings_ microservice to fetch book ratings, a number between 1 and 5. The ratings are displayed as stars for each review. There are several versions of the _ratings_ microservice. Some use [MongoDB](https://www.mongodb.com), others use [MySQL](https://www.mysql.com) as their database.
To demonstrate the scenario of using an external database, I start with a Kubernetes cluster with [Istio installed](/docs/setup/kubernetes/quick-start/#installation-steps). Then I deploy the [Istio Bookinfo sample application](/docs/guides/bookinfo/). This application uses the _ratings_ microservice to fetch book ratings, a number between 1 and 5. The ratings are displayed as stars for each review. There are several versions of the _ratings_ microservice. Some use [MongoDB](https://www.mongodb.com), others use [MySQL](https://www.mysql.com) as their database.
The example commands in this blog post work with Istio 0.3+, with or without [Mutual TLS]({{home}}/docs/concepts/security/mutual-tls.html) enabled.
The example commands in this blog post work with Istio 0.3+, with or without [Mutual TLS](/docs/concepts/security/mutual-tls/) enabled.
As a reminder, here is the end-to-end architecture of the application from the [Bookinfo Guide]({{home}}/docs/guides/bookinfo.html).
As a reminder, here is the end-to-end architecture of the application from the [Bookinfo Guide](/docs/guides/bookinfo/).
{% assign url = home | append: "/docs/guides/img/bookinfo/withistio.svg" %}
{% include image.html width="80%" ratio="59.08%"
link=url
{{< image width="80%" ratio="59.08%"
link="/docs/guides/img/bookinfo/withistio.svg"
caption="The original Bookinfo application"
%}
>}}
### Use the database for ratings data in Bookinfo application
@ -155,7 +153,7 @@ As a reminder, here is the end-to-end architecture of the application from the [
```
1. I route all the traffic destined to the _reviews_ service to its _v3_ version. I do this to ensure that the _reviews_ service always calls the _ratings_
service. In addition, I route all the traffic destined to the _ratings_ service to _ratings v2-mysql_ that uses my database. I add routing for both services above by adding two [route rules]({{home}}/docs/reference/config/istio.routing.v1alpha1.html). These rules are specified in `samples/bookinfo/kube/route-rule-ratings-mysql.yaml` of an Istio release archive.
service. In addition, I route all the traffic destined to the _ratings_ service to _ratings v2-mysql_ that uses my database. I add routing for both services above by adding two [route rules](/docs/reference/config/istio.routing.v1alpha1/). These rules are specified in `samples/bookinfo/kube/route-rule-ratings-mysql.yaml` of an Istio release archive.
```command
$ istioctl create -f samples/bookinfo/kube/route-rule-ratings-mysql.yaml
@ -165,27 +163,27 @@ service. In addition, I route all the traffic destined to the _ratings_ service
The updated architecture appears below. Note that the blue arrows inside the mesh mark the traffic configured according to the route rules we added. According to the route rules, the traffic is sent to _reviews v3_ and _ratings v2-mysql_.
{% include image.html width="80%" ratio="59.31%"
link="./img/bookinfo-ratings-v2-mysql-external.svg"
{{< image width="80%" ratio="59.31%"
link="../img/bookinfo-ratings-v2-mysql-external.svg"
caption="The Bookinfo application with ratings v2-mysql and an external MySQL database"
%}
>}}
Note that the MySQL database is outside the Istio service mesh, or more precisely outside the Kubernetes cluster. The boundary of the service mesh is marked by a dashed line.
### Access the webpage
Let's access the webpage of the application, after [determining the ingress IP and port]({{home}}/docs/guides/bookinfo.html#determining-the-ingress-ip-and-port).
Let's access the webpage of the application, after [determining the ingress IP and port](/docs/guides/bookinfo/#determining-the-ingress-ip-and-port).
We have a problem... Instead of the rating stars, the message _"Ratings service is currently unavailable"_ is currently displayed below each review:
{% include image.html width="80%" ratio="36.19%"
link="./img/errorFetchingBookRating.png"
{{< image width="80%" ratio="36.19%"
link="../img/errorFetchingBookRating.png"
caption="The Ratings service error messages"
%}
>}}
As in [Consuming External Web Services]({{home}}/blog/2018/egress-https.html), we experience **graceful service degradation**, which is good. The application did not crash due to the error in the _ratings_ microservice. The webpage of the application correctly displayed the book information, the details, and the reviews, just without the rating stars.
As in [Consuming External Web Services](/blog/2018/egress-https/), we experience **graceful service degradation**, which is good. The application did not crash due to the error in the _ratings_ microservice. The webpage of the application correctly displayed the book information, the details, and the reviews, just without the rating stars.
We have the same problem as in [Consuming External Web Services]({{home}}/blog/2018/egress-https.html), namely all the traffic outside the Kubernetes cluster, both TCP and HTTP, is blocked by default by the sidecar proxies. To enable such traffic for TCP, an egress rule for TCP must be defined.
We have the same problem as in [Consuming External Web Services](/blog/2018/egress-https/), namely all the traffic outside the Kubernetes cluster, both TCP and HTTP, is blocked by default by the sidecar proxies. To enable such traffic for TCP, an egress rule for TCP must be defined.
### Egress rule for an external MySQL instance
@ -215,10 +213,10 @@ Note that for a TCP egress rule, we specify `tcp` as the protocol of a port of t
It worked! Accessing the web page of the application displays the ratings without error:
{% include image.html width="80%" ratio="36.69%"
link="./img/externalMySQLRatings.png"
{{< image width="80%" ratio="36.69%"
link="../img/externalMySQLRatings.png"
caption="Book Ratings Displayed Correctly"
%}
>}}
Note that we see a one-star rating for both displayed reviews, as expected. I changed the ratings to be one star to provide us with a visual clue that our external database is indeed being used.
@ -228,7 +226,7 @@ As with egress rules for HTTP/HTTPS, we can delete and create egress rules for T
Some in-mesh Istio applications must access external services, for example legacy systems. In many cases, the access is not performed over HTTP or HTTPS protocols. Other TCP protocols are used, such as database-specific protocols like [MongoDB Wire Protocol](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/) and [MySQL Client/Server Protocol](https://dev.mysql.com/doc/internals/en/client-server-protocol.html) to communicate with external databases.
Note that in case of access to external HTTPS services, as described in the [Control Egress TCP Traffic]({{home}}/docs/tasks/traffic-management/egress.html) task, an application must issue HTTP requests to the external service. The Envoy sidecar proxy attached to the pod or the VM, will intercept the requests and open an HTTPS connection to the external service. The traffic will be unencrypted inside the pod or the VM, but it will leave the pod or the VM encrypted.
Note that in case of access to external HTTPS services, as described in the [Control Egress TCP Traffic](/docs/tasks/traffic-management/egress/) task, an application must issue HTTP requests to the external service. The Envoy sidecar proxy attached to the pod or the VM, will intercept the requests and open an HTTPS connection to the external service. The traffic will be unencrypted inside the pod or the VM, but it will leave the pod or the VM encrypted.
However, sometimes this approach cannot work due to the following reasons:
@ -252,17 +250,17 @@ To enable TCP traffic to an external service by its hostname, all the IPs of the
Note that all the IPs of an external service are not always known. To enable TCP traffic by IPs, as opposed to the traffic by a hostname, only the IPs that are used by the applications must be specified.
Also note that the IPs of an external service are not always static, for example in the case of [CDNs](https://en.wikipedia.org/wiki/Content_delivery_network). Sometimes the IPs are static most of the time, but can be changed from time to time, for example due to infrastructure changes. In these cases, if the range of the possible IPs is known, you should specify the range by CIDR blocks (even by multiple egress rules if needed). As an example, see the approach we used in the case of `wikipedia.org`, described in [Control Egress TCP Traffic Task]({{home}}/docs/tasks/traffic-management/egress-tcp.html). If the range of the possible IPs is not known, egress rules for TCP cannot be used and [the external services must be called directly]({{home}}/docs/tasks/traffic-management/egress.html#calling-external-services-directly), circumventing the sidecar proxies.
Also note that the IPs of an external service are not always static, for example in the case of [CDNs](https://en.wikipedia.org/wiki/Content_delivery_network). Sometimes the IPs are static most of the time, but can be changed from time to time, for example due to infrastructure changes. In these cases, if the range of the possible IPs is known, you should specify the range by CIDR blocks (even by multiple egress rules if needed). As an example, see the approach we used in the case of `wikipedia.org`, described in [Control Egress TCP Traffic Task](/docs/tasks/traffic-management/egress-tcp/). If the range of the possible IPs is not known, egress rules for TCP cannot be used and [the external services must be called directly](/docs/tasks/traffic-management/egress/#calling-external-services-directly), circumventing the sidecar proxies.
## Relation to mesh expansion
Note that the scenario described in this post is different from the mesh expansion scenario, described in the
[Integrating Virtual Machines]({{home}}/docs/guides/integrating-vms.html) guide. In that scenario, a MySQL instance runs on an external
[Integrating Virtual Machines](/docs/guides/integrating-vms/) guide. In that scenario, a MySQL instance runs on an external
(outside the cluster) machine (a bare metal or a VM), integrated with the Istio service mesh. The MySQL service becomes a first-class citizen of the mesh with all the beneficial features of Istio applicable. Among other things, the service becomes addressable by a local cluster domain name, for example by `mysqldb.vm.svc.cluster.local`, and the communication to it can be secured by
[mutual TLS authentication]({{home}}/docs/concepts/security/mutual-tls.html). There is no need to create an egress rule to access this service; however, the
[mutual TLS authentication](/docs/concepts/security/mutual-tls/). There is no need to create an egress rule to access this service; however, the
service must be registered with Istio. To enable such integration, Istio components (_Envoy proxy_, _node-agent_, _istio-agent_) must be
installed on the machine and the Istio control plane (_Pilot_, _Mixer_, _CA_) must be accessible from it. See the
[Istio Mesh Expansion]({{home}}/docs/setup/kubernetes/mesh-expansion.html) instructions for more details.
[Istio Mesh Expansion](/docs/setup/kubernetes/mesh-expansion/) instructions for more details.
In our case, the MySQL instance can run on any machine or can be provisioned as a service by a cloud provider. There is no requirement to integrate the machine
with Istio. The Istio control plane does not have to be accessible from the machine. In the case of MySQL as a service, the machine which MySQL runs on may be not accessible and installing on it the required components may be impossible. In our case, the MySQL instance is addressable by its global domain name, which could be beneficial if the consuming applications expect to use that domain name. This is especially relevant when that expected domain name cannot be changed in the deployment configuration of the consuming applications.
@ -318,6 +316,6 @@ In this blog post, I demonstrated how the microservices in an Istio service mesh
To read more about Istio egress traffic control:
* for TCP, see [Control Egress TCP Traffic Task]({{home}}/docs/tasks/traffic-management/egress-tcp.html)
* for TCP, see [Control Egress TCP Traffic Task](/docs/tasks/traffic-management/egress-tcp/)
* for HTTP/HTTPS, see [Control Egress Traffic Task]({{home}}/docs/tasks/traffic-management/egress.html)
* for HTTP/HTTPS, see [Control Egress Traffic Task](/docs/tasks/traffic-management/egress/)

20
content/blog/2018/soft-multitenancy.md
View File

@ -6,7 +6,7 @@ subtitle: Using multiple Istio control planes and RBAC to create multi-tenancy
attribution: John Joyce and Rich Curran
weight: 90
---
{% include home.html %}
Multi-tenancy is commonly used in many environments across many different applications,
but the implementation details and functionality provided on a per tenant basis does not
follow one model in all environments. The [Kubernetes multi-tenancy working group](
@ -31,7 +31,7 @@ Potential future Istio multi-tenant deployment models are described at the botto
blog.
>Note: This blog is a high-level description of how to deploy Istio in a
limited multi-tenancy environment. The [docs]({{home}}/docs/) section will be updated
limited multi-tenancy environment. The [docs](/docs/) section will be updated
when official multi-tenancy support is provided.
## Deployment
@ -71,8 +71,8 @@ istio-system1 istio-ingress-68d65fc5c6-2vldg 1/1 Running 0
istio-system1 istio-mixer-7d4f7b9968-66z44 3/3 Running 0 15d
istio-system1 istio-pilot-5bb6b7669c-779vb 2/2 Running 0 15d
```
The Istio [sidecar]({{home}}/docs/setup/kubernetes/sidecar-injection.html) and
[addons]({{home}}/docs/tasks/telemetry/), if required, manifests must also
The Istio [sidecar](/docs/setup/kubernetes/sidecar-injection/) and
[addons](/docs/tasks/telemetry/), if required, manifests must also
be deployed to match the configured `namespace` in use by the tenant's Istio control plane.
The execution of these two yaml files is the responsibility of the cluster
@ -192,8 +192,8 @@ the tenant administrator.
### Using `istioctl` in a multi-tenant environment
When defining [route rules]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#RouteRule)
or [destination policies]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#DestinationPolicy),
When defining [route rules](/docs/reference/config/istio.routing.v1alpha1/#RouteRule)
or [destination policies](/docs/reference/config/istio.routing.v1alpha1/#DestinationPolicy),
it is necessary to ensure that the `istioctl` command is scoped to
the namespace the Istio control plane is running in to ensure the resource is created
in the proper namespace. Additionally, the rule itself must be scoped to the tenant's namespace
@ -218,7 +218,7 @@ ratings-default RouteRule.v1alpha2.config.istio.io ns-1
reviews-default RouteRule.v1alpha2.config.istio.io ns-1
```
See the [Multiple Istio control planes]({{home}}/blog/2018/soft-multitenancy.html#multiple-istio-control-planes) section of this document for more details on `namespace` requirements in a
See the [Multiple Istio control planes](/blog/2018/soft-multitenancy/#multiple-istio-control-planes) section of this document for more details on `namespace` requirements in a
multi-tenant environment.
### Test results
@ -256,7 +256,7 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p
```
The tenant administrator can deploy applications in the application namespace configured for
that tenant. As an example, updating the [Bookinfo]({{home}}/docs/guides/bookinfo.html)
that tenant. As an example, updating the [Bookinfo](/docs/guides/bookinfo/)
manifests and then deploying under the tenant's application namespace of *ns-0*, listing the
pods in use by this tenant's namespace is permitted:
@ -278,8 +278,8 @@ $ kubectl get pods -n ns-1
Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list pods in the namespace "ns-1"
```
If the [addon tools]({{home}}/docs/tasks/telemetry/), example
[prometheus]({{home}}/docs/tasks/telemetry//querying-metrics.html), are deployed
If the [addon tools](/docs/tasks/telemetry/), example
[prometheus](/docs/tasks/telemetry//querying-metrics/), are deployed
(also limited by an Istio `namespace`) the statistical results returned would represent only
that traffic seen from that tenant's application namespace.

5
content/blog/2018/traffic-mirroring.md
View File

@ -6,11 +6,10 @@ subtitle: Routing rules for HTTP traffic
attribution: Christian Posta
weight: 91
---
{% include home.html %}
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]({{home}}/about/notes/0.5.html), 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](/about/notes/0.5/), Istio can mirror traffic to help test your services. You can write route rules similar to the following to enable traffic mirroring:
```yaml
apiVersion: config.istio.io/v1alpha2
@ -40,5 +39,5 @@ A few things to note here:
* Responses to any mirrored traffic is ignored; traffic is mirrored as "fire-and-forget"
* You'll need to have the 0-weighted route to hint to Istio to create the proper Envoy cluster under the covers; [this should be ironed out in future releases](https://github.com/istio/istio/issues/3270).
Learn more about mirroring by visiting the [Mirroring Task]({{home}}/docs/tasks/traffic-management/mirroring.html) and see a more
Learn more about mirroring by visiting the [Mirroring Task](/docs/tasks/traffic-management/mirroring/) and see a more
[comprehensive treatment of this scenario on my blog](https://blog.christianposta.com/microservices/traffic-shadowing-with-istio-reduce-the-risk-of-code-release/).

26
content/blog/2018/v1alpha3-routing.md
View File

@ -7,8 +7,6 @@ attribution: Frank Budinsky (IBM) and Shriram Rajagopalan (VMware)
weight: 88
---
{% include home.html %}
Up until now, Istio has provided a simple API for traffic management using four configuration resources:
`RouteRule`, `DestinationPolicy`, `EgressRule`, and (Kubernetes) `Ingress`.
With this API, users have been able to easily manage the flow of traffic in an Istio service mesh.
@ -23,7 +21,7 @@ traffic has proven to be woefully insufficient for our needs.
To address these, and other concerns, a new traffic management API, a.k.a. `v1alpha3`, is being introduced, which will
completely replace the previous API going forward. Although the `v1alpha3` model is fundamentally the same, it is not
backward compatible and will require manual conversion from the old API. A
[conversion tool]({{home}}/docs/reference/commands/istioctl.html#istioctl%20experimental%20convert-networking-config)
[conversion tool](/docs/reference/commands/istioctl/#istioctl%20experimental%20convert-networking-config)
is included in the next few releases of Istio to help with the transition.
To justify this disruption, the `v1alpha3` API has gone through a long and painstaking community
@ -51,11 +49,11 @@ services (e.g., Google Maps API). These may be called directly or, in certain de
exiting the mesh may be forced through dedicated egress gateways. The following diagram depicts
this mental model.
{% include image.html width="80%" ratio="35.20%"
link="./img/gateways.svg"
{{< image width="80%" ratio="35.20%"
link="../img/gateways.svg"
alt="Role of gateways in the mesh"
caption="Gateways in an Istio service mesh"
%}
>}}
With the above setup in mind, `v1alpha3` introduces the following new
configuration resources to control traffic routing into, within, and out of the mesh.
@ -73,14 +71,14 @@ dedicated middleboxes.
The figure below depicts the flow of control across configuration
resources.
{% include image.html width="80%" ratio="41.16%"
link="./img/virtualservices-destrules.svg"
{{< image width="80%" ratio="41.16%"
link="../img/virtualservices-destrules.svg"
caption="Relationship between different v1alpha3 elements"
%}
>}}
### Gateway
A [Gateway]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#Gateway)
A [Gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
configures a load balancer for HTTP/TCP traffic, regardless of
where it will be running. Any number of gateways can exist within the mesh
and multiple different gateway implementations can co-exist. In fact, a
@ -160,9 +158,9 @@ scalability issues with the previous model.
In effect, what has changed is that instead of configuring routing using a set of individual configuration resources
(rules) for a particular destination service, each containing a precedence field to control the order of evaluation, we
now configure the (virtual) destination itself, with all of its rules in an ordered list within a corresponding
[VirtualService]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#VirtualService) resource.
[VirtualService](/docs/reference/config/istio.networking.v1alpha3/#VirtualService) resource.
For example, where previously we had two `RouteRule` resources for the
[Bookinfo]({{home}}/docs/guides/bookinfo.html) application’s `reviews` service, like this:
[Bookinfo](/docs/guides/bookinfo/) application’s `reviews` service, like this:
```yaml
apiVersion: config.istio.io/v1alpha2
@ -278,7 +276,7 @@ In addition to this fundamental restructuring, `VirtualService` includes several
### DestinationRule
A [DestinationRule]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#DestinationRule)
A [DestinationRule](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule)
configures the set of policies to be applied while forwarding traffic to a service. They are
intended to be authored by service owners, describing the circuit breakers, load balancer settings, TLS settings, etc..
`DestinationRule` is more or less the same as its predecessor, `DestinationPolicy`, with the following exceptions:
@ -322,7 +320,7 @@ Notice that, unlike `DestinationPolicy`, multiple policies (e.g., default and v2
### ServiceEntry
[ServiceEntry]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#ServiceEntry)
[ServiceEntry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry)
is used to add additional entries into the service registry that Istio maintains internally.
It is most commonly used to allow one to model traffic to external dependencies of the mesh
such as APIs consumed from the web or traffic to services in legacy infrastructure.

5
content/blog/_index.md Normal file
View File

@ -0,0 +1,5 @@
---
title: Istio Blog Posts
type: section-index
sidebar_multicard: true
---

17
content/blog/index.html
View File

@ -1,17 +0,0 @@
---
title: Istio Blog
description: The Istio blog
layout: compress
---
{% include latest_blog_post.html %}
<!DOCTYPE html>
<html lang="en-US">
<meta charset="utf-8">
<title>Redirecting…</title>
<link rel="canonical" href="{{latest_blog_post}}">
<meta http-equiv="refresh" content="0; url={{latest_blog_post}}">
<h1>Redirecting…</h1>
<a href="{{latest_blog_post}}">Click here if you are not redirected.</a>
<script>location="{{latest_blog_post}}"</script>
</html>

21
content/community/_index.md
View File

@ -2,21 +2,18 @@
title: Community
description: Information on the various ways to participate and interact with the Istio community.
layout: community
redirect_from:
- /community/index.html
sidebar_none: true
---
{% include home.html %}
Istio is an open source project with an active community that supports its use and on-going development. We'd love for you
to join us and get involved!
There are quite a few ways to get plugged in with the Istio community:
<table>
<table class="community">
<tbody>
<tr>
<td class="logo"><img src="{{home}}/img/mailing-list.svg" alt="Mailing Lists"/></td>
<td class="logo"><img src="/img/mailing-list.svg" alt="Mailing Lists"/></td>
<td class="desc">
Join the <a href="https://groups.google.com/forum/#!forum/istio-users">istio-users@</a> mailing list to participate in
discussions
@ -29,14 +26,14 @@ There are quite a few ways to get plugged in with the Istio community:
</tr>
<tr>
<td class="logo"><img src="{{home}}/img/twitter.svg" alt="Twitter"/></td>
<td class="logo"><img src="/img/twitter.svg" alt="Twitter"/></td>
<td class="desc">
Follow us on <a href="https://twitter.com/IstioMesh">Twitter</a> to get the latest news.
</td>
</tr>
<tr>
<td class="logo"><img src="{{home}}/img/stackoverflow.svg" alt="Stack Overflow"/></td>
<td class="logo"><img src="/img/stackoverflow.svg" alt="Stack Overflow"/></td>
<td class="desc">
<a href="https://stackoverflow.com/questions/tagged/istio">Stack Overflow</a> is for practical questions and curated answers
on deploying, configuring, and using Istio.
@ -44,21 +41,21 @@ There are quite a few ways to get plugged in with the Istio community:
</tr>
<tr>
<td class="logo"><img src="{{home}}/img/rocket-chat.svg" alt="Rocket Chat"/></td>
<td class="logo"><img src="/img/rocket-chat.svg" alt="Rocket Chat"/></td>
<td class="desc">
Chat with members of the Istio community on <a href="https://istio.rocket.chat">Rocket Chat</a>.
</td>
</tr>
<tr>
<td class="logo"><img src="{{home}}/img/github.png" alt="GitHub"/></td>
<td class="logo"><img src="/img/github.png" alt="GitHub"/></td>
<td class="desc">
<a href="https://github.com/istio/community">GitHub</a> is where development takes place on Istio code.
</td>
</tr>
<tr>
<td class="logo"><img src="{{home}}/img/drive.png" alt="Team Drive"/></td>
<td class="logo"><img src="/img/drive.png" alt="Team Drive"/></td>
<td class="desc">
If you want to get into the nuts and bolts of Istio, check out our growing collection
of design documents. To access these, simply join the
@ -69,7 +66,7 @@ There are quite a few ways to get plugged in with the Istio community:
</tr>
<tr>
<td class="logo"><img src="{{home}}/img/group.svg" alt="Working Groups"/></td>
<td class="logo"><img src="/img/group.svg" alt="Working Groups"/></td>
<td class="desc">
If you'd like to contribute to the Istio project, consider participating in our
<a href="https://github.com/istio/community/blob/master/WORKING-GROUPS.md">working groups</a>.

25
content/docs/_index.md
View File

@ -1,41 +1,38 @@
---
title: Welcome
description: Istio documentation home page.
weight: 1
toc: false
sidebar_multicard: true
---
{% include home.html %}
From here you can learn all about Istio's architecture and how to deploy and use Istio.
- [Concepts]({{home}}/docs/concepts/). Concepts explain some significant aspect of Istio. This
- [Concepts](/docs/concepts/). Concepts explain some significant aspect of Istio. This
is where you can learn about what Istio does and how it does it.
- [Setup]({{home}}/docs/setup/). Setup contains instructions for installing
- [Setup](/docs/setup/). Setup contains instructions for installing
the Istio control plane in various environments, as well as instructions
for installing the sidecar in the application deployment. Quick start
instructions are available for
[Kubernetes]({{home}}/docs/setup/kubernetes/quick-start.html) and
[Docker Compose w/ Consul]({{home}}/docs/setup/consul/quick-start.html).
[Kubernetes](/docs/setup/kubernetes/quick-start/) and
[Docker Compose w/ Consul](/docs/setup/consul/quick-start/).
- [Tasks]({{home}}/docs/tasks/). Tasks show you how to do a single directed activity with Istio.
- [Tasks](/docs/tasks/). Tasks show you how to do a single directed activity with Istio.
- [Guides]({{home}}/docs/guides/). Guides are fully working stand-alone examples
- [Guides](/docs/guides/). Guides are fully working stand-alone examples
intended to highlight a particular set of Istio's features.
- [Reference]({{home}}/docs/reference/). Detailed exhaustive lists of
- [Reference](/docs/reference/). Detailed exhaustive lists of
command-line options, configuration options, API definitions, and procedures.
In addition, you might find these links interesting:
- The latest Istio monthly release is {{site.data.istio.version}}: [download {{site.data.istio.version}}](https://github.com/istio/istio/releases),
[release notes]({{home}}/about/notes/{{site.data.istio.version}}.html).
- The latest Istio monthly release is {{< istio_version >}}: [download {{< istio_version >}}](https://github.com/istio/istio/releases),
[release notes](/about/notes/{{< istio_version >}}/).
- Nostalgic for days gone by? We keep an [archive of the earlier releases' documentation](https://archive.istio.io/).
- We're always looking for help improving our documentation, so please don't hesitate to
[file an issue](https://github.com/istio/istio.github.io/issues/new) if you see some problem.
Or better yet, submit your own [contributions]({{home}}/about/contribute/editing.html) to help
Or better yet, submit your own [contributions](/about/contribute/editing/) to help
make our docs better.

6
content/docs/concepts/_index.md
View File

@ -1,10 +1,6 @@
---
title: Concepts
description: Concepts help you learn about the different parts of the Istio system and the abstractions it uses.
weight: 10
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}

8
content/docs/concepts/policies-and-telemetry/_index.md
View File

@ -1,12 +1,8 @@
---
title: Policies and Telemetry
description: Introduces the policy control snd telemetry collection mechanisms.
weight: 40
toc: false
redirect_from:
type: section-index
aliases:
- /docs/concepts/policy-and-control/index.html
---
{% include section-index.html docs=site.docs %}

25
content/docs/concepts/policies-and-telemetry/config.md
View File

@ -2,11 +2,10 @@
title: Configuration
description: An overview of the key concepts used to configure Istio's policy enforcement and telemetry collection features.
weight: 30
redirect_from:
aliases:
- /docs/concepts/policy-and-control/mixer-config.html
- /docs/concepts/policy-and-control/attributes.html
---
{% include home.html %}
Istio's policy and telemetry features are configured through a common model designed to
put operators in control of every aspect of authorization policy and telemetry collection.
@ -41,10 +40,10 @@ every request, giving Mixer a set of attributes that describe the request and th
around the request. Based on its configuration and the specific set of attributes it was
given, Mixer generates calls to a variety of infrastructure backends.
{% include image.html width="60%" ratio="42.60%"
link="./img/machine.svg"
{{< image width="60%" ratio="42.60%"
link="../img/machine.svg"
caption="Attribute Machine"
%}
>}}
### Attribute vocabulary
@ -54,7 +53,7 @@ in the deployment. The primary attribute producer in Istio is Envoy, although
specialized Mixer adapters can also generate attributes.
The common baseline set of attributes available in most Istio deployments is defined
[here]({{home}}/docs/reference/config/policy-and-telemetry/attribute-vocabulary.html).
[here](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/).
## Configuration model
@ -137,7 +136,7 @@ spec:
```
Each adapter defines its own particular format of configuration data. The exhaustive set of
adapters and their specific configuration formats can be found [here]({{home}}/docs/reference/config/policy-and-telemetry/adapters/).
adapters and their specific configuration formats can be found [here](/docs/reference/config/policy-and-telemetry/adapters/).
## Instances
@ -160,7 +159,7 @@ spec:
```
Note that all the dimensions expected in the handler configuration are specified in the mapping.
Templates define the specific required content of individual instances. The exhaustive set of
templates and their specific configuration formats can be found [here]({{home}}/docs/reference/config/policy-and-telemetry/templates/).
templates and their specific configuration formats can be found [here](/docs/reference/config/policy-and-telemetry/templates/).
## Rules
@ -208,14 +207,14 @@ destination_version: destination.labels["version"] | "unknown"
With the above, the `destination_version` label is assigned the value of `destination.labels["version"]`. However if that attribute
is not present, the literal `"unknown"` is used.
Refer to the [attribute expression reference]({{home}}/docs/reference/config/policy-and-telemetry/expression-language.html) for details.
Refer to the [attribute expression reference](/docs/reference/config/policy-and-telemetry/expression-language/) for details.
## What's next
- Learn how to [configure telemetry collection]({{home}}/docs/tasks/telemetry).
- Learn how to [configure telemetry collection](/docs/tasks/telemetry/).
- Learn how to [configure policy enforcement]({{home}}/docs/tasks/policy-enforcement).
- Learn how to [configure policy enforcement](/docs/tasks/policy-enforcement/).
- Learn about the set of [supported adapters]({{home}}/docs/reference/config/policy-and-telemetry/adapters).
- Learn about the set of [supported adapters](/docs/reference/config/policy-and-telemetry/adapters/).
- See the blog post describing [Mixer's adapter model]({{home}}/blog/mixer-adapter-model.html).
- See the blog post describing [Mixer's adapter model](/blog/2017/adapter-model/).

24
content/docs/concepts/policies-and-telemetry/overview.md
View File

@ -2,12 +2,10 @@
title: Overview
description: Describes the design of the policy and telemetry mechanisms.
weight: 5
redirect_from:
aliases:
- /docs/concepts/policy-and-control/mixer.html
---
{% include home.html %}
Istio provides a flexible model to enforce authorization policies and collect telemetry for the
services in a mesh.
@ -26,10 +24,10 @@ control to operators.
Mixer is the Istio component responsible for providing policy controls and telemetry collection:
{% include image.html width="75%" ratio="49.26%"
link="./img/topology-without-cache.svg"
{{< image width="75%" ratio="49.26%"
link="../img/topology-without-cache.svg"
caption="Mixer Topology"
%}
>}}
The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry.
The sidecar has local caching such that a relatively large percentage of precondition checks can be performed from cache. Additionally, the
@ -61,11 +59,11 @@ monitoring, quotas, ACL checking, and more. The exact set of
adapters used at runtime is determined through configuration and can easily be
extended to target new or custom infrastructure backends.
{% include image.html width="35%" ratio="138%"
link="./img/adapters.svg"
{{< image width="35%" ratio="138%"
link="../img/adapters.svg"
alt="Showing Mixer with adapters."
caption="Mixer and its Adapters"
%}
>}}
## Reliability and latency
@ -82,10 +80,10 @@ The sidecar proxies that sit next to each service instance in the mesh must nece
caching and buffering. Mixer, however, lives independently and can use considerably larger caches and output buffers. Mixer thus acts as a highly-scaled and highly-available second-level
cache for the sidecars.
{% include image.html width="75%" ratio="65.89%"
link="./img/topology-with-cache.svg"
{{< image width="75%" ratio="65.89%"
link="../img/topology-with-cache.svg"
caption="Mixer Topology"
%}
>}}
Since Mixer’s expected availability is considerably higher than most infrastructure backends (those often have availability of perhaps 99.9%). Mixer's local
caches and buffers not only contribute to reduce latency, they also help mask infrastructure backend failures by being able to continue operating
@ -96,4 +94,4 @@ sent to backends (through local aggregation). Both of these can reduce operation
## What's next
* Read the [Mixer adapter model]({{home}}/blog/2017/adapter-model.html) blog post.
* Read the [Mixer adapter model](/blog/2017/adapter-model/) blog post.

6
content/docs/concepts/security/_index.md
View File

@ -1,10 +1,6 @@
---
title: Security
description: Describes Istio's authorization and authentication functionality.
weight: 30
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}

19
content/docs/concepts/security/authn-policy.md
View File

@ -1,15 +1,14 @@
---
title: Istio Authentication Policy
description: Describes Istio authentication policy
title: Authentication Policy
description: Describes Istio's authentication policy
weight: 10
redirect_from:
aliases:
- /docs/concepts/network-and-auth/auth.html
---
{% include home.html %}
Istio authentication policy enables operators to specify authentication requirements for a service (or services). Istio authentication policy is composed of two parts:
* Peer: verifies the party, the direct client, that makes the connection. The common authentication mechanism for this is [mutual TLS]({{home}}/docs/concepts/security/mutual-tls.html). Istio is responsible for managing both client and server sides to enforce the policy.
* Peer: verifies the party, the direct client, that makes the connection. The common authentication mechanism for this is [mutual TLS](/docs/concepts/security/mutual-tls/). Istio is responsible for managing both client and server sides to enforce the policy.
* Origin: verifies the party, the original client, that makes the request (e.g end-users, devices etc). JWT is the only supported mechanism for origin authentication at the moment. Istio configures the server side to perform authentication, but doesn't enforce that the client side sends the required token.
@ -19,10 +18,10 @@ Identities from both authentication parts, if applicable, are output to the next
Authentication policies are saved in Istio config store (in 0.7, the storage implementation uses Kubernetes CRD), and distributed by control plane. Depending on the size of the mesh, config propagation may take a few seconds to a few minutes. During the transition, you can expect traffic lost or inconsistent authentication results.
{% include image.html width="80%" ratio="75%"
link="./img/authn.svg"
{{< image width="80%" ratio="75%"
link="../img/authn.svg"
caption="Authentication Policy Architecture"
%}
>}}
Policy is scoped to namespaces, with (optional) target selector rules to narrow down the set of services (within the same namespace as the policy) on which the policy should be applied. This aligns with the ACL model based on Kubernetes RBAC. More specifically, only the admin of the namespace can set policies for services in that namespace.
@ -40,7 +39,7 @@ Origin principal (principal from origin authentication) is not explicitly output
### Target selectors
Defines rule to find service(s) on which policy should be applied. If no rule is provided, the policy is matched to all services in the namespace, so-called namespace-level policy (as opposed to service-level policies which have non-empty selector rules). Istio uses the service-level policy if available, otherwise it falls back to namespace-level policy. If neither is defined, it uses the default policy based on service mesh config and/or service annotation, which can only set mutual TLS setting (these are mechanisms before Istio 0.7 to config mutual TLS for Istio service mesh). See [testing Istio mutual TLS]({{home}}/docs/tasks/security/mutual-tls.html) and [per-service mutual TLS enablement]({{home}}/docs/tasks/security/per-service-mtls.html) for more details.
Defines rule to find service(s) on which policy should be applied. If no rule is provided, the policy is matched to all services in the namespace, so-called namespace-level policy (as opposed to service-level policies which have non-empty selector rules). Istio uses the service-level policy if available, otherwise it falls back to namespace-level policy. If neither is defined, it uses the default policy based on service mesh config and/or service annotation, which can only set mutual TLS setting (these are mechanisms before Istio 0.7 to config mutual TLS for Istio service mesh). See [testing Istio mutual TLS](/docs/tasks/security/mutual-tls/) and [per-service mutual TLS enablement](/docs/tasks/security/per-service-mtls/) for more details.
Operators are responsible for avoiding conflicts, e.g create more than one service-level policy that matches to the same service(s) (or more than one namespace-level policy on the same namespace).
@ -84,4 +83,4 @@ Defines what is the principal from the authentication. By default, this will be
## What's next
Try out the [Basic Istio authentication policy]({{home}}/docs/tasks/security/authn-policy.html) tutorial.
Try out the [Basic Istio authentication policy](/docs/tasks/security/authn-policy/) tutorial.

17
content/docs/concepts/security/mutual-tls.md
View File

@ -2,14 +2,9 @@
title: Mutual TLS Authentication
description: Describes Istio's mutual TLS authentication architecture which provides a strong service identity and secure communication channels between services.
weight: 10
---
{% include home.html %}
## Overview
Istio's aim is to enhance the security of microservices and their communication without requiring service code changes. It is responsible for:
Istio aims to enhance the security of microservices and their communication without requiring service code changes. It is responsible for:
* Providing each service with a strong identity that represents its role to enable interoperability across clusters and clouds
@ -24,11 +19,11 @@ security. This diagram describes how Istio is used to secure the service-to-serv
as the service account 'frontend-team' and service 'backend' running as the service account 'backend-team'. Istio supports services running
on both Kubernetes containers and VM/bare-metal machines.
{% include image.html width="80%" ratio="56.25%"
link="./img/mutual-tls/auth.svg"
{{< image width="80%" ratio="56.25%"
link="../img/mutual-tls/auth.svg"
alt="Components making up the Istio auth model."
caption="Istio Security Architecture"
%}
>}}
As illustrated in the diagram, Istio leverages secret volume mount to deliver keys/certs from Citadel to Kubernetes containers. For services running on
VM/bare-metal machines, we introduce a node agent, which is a process running on each VM/bare-metal machine. It generates the private key and CSR (certificate
@ -99,7 +94,7 @@ pair for each of the existing and new service accounts, and sends them to the AP
1. When a pod is created, API Server mounts the key and certificate pair according to the service account using [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
1. [Pilot]({{home}}/docs/concepts/traffic-management/pilot.html) generates the config with proper key and certificate and secure naming information,
1. [Pilot](/docs/concepts/traffic-management/pilot/) generates the config with proper key and certificate and secure naming information,
which defines what service account(s) can run a certain service, and passes it to Envoy.
### Deployment phase (VM/bare-metal Machines Scenario)
@ -140,7 +135,7 @@ Let's consider a 3-tier application with three services: photo-frontend, photo-b
In this scenario, a cluster admin creates 3 namespaces: istio-citadel-ns, photo-ns, and datastore-ns. Admin has access to all namespaces, and each team only has
access to its own namespace. The photo SRE team creates 2 service accounts to run photo-frontend and photo-backend respectively in namespace photo-ns. The
datastore SRE team creates 1 service account to run the datastore service in namespace datastore-ns. Moreover, we need to enforce the service access control
in [Istio Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html) such that photo-frontend cannot access datastore.
in [Istio Mixer](/docs/concepts/policies-and-telemetry/overview/) such that photo-frontend cannot access datastore.
In this setup, Citadel is able to provide keys and certificates management for all namespaces, and isolate
microservice deployments from each other.

12
content/docs/concepts/security/rbac.md
View File

@ -2,9 +2,7 @@
title: Istio Role-Based Access Control (RBAC)
description: Describes Istio RBAC which provides access control for services in Istio Mesh.
weight: 20
---
{% include home.html %}
## Overview
@ -22,11 +20,11 @@ It features:
The diagram below shows the Istio RBAC architecture. Operators specify Istio RBAC policies. The policies are saved in
the Istio config store.
{% include image.html width="80%" ratio="56.25%"
link="./img/IstioRBAC.svg"
{{< image width="80%" ratio="56.25%"
link="../img/IstioRBAC.svg"
alt="Istio RBAC"
caption="Istio RBAC Architecture"
%}
>}}
The Istio RBAC engine does two things:
* **Fetch RBAC policy.** Istio RBAC engine watches for changes on RBAC policy. It fetches the updated RBAC policy if it sees any changes.
@ -35,7 +33,7 @@ request context against the RBAC policies, and returns the authorization result
### Request context
In the current release, the Istio RBAC engine is implemented as a [Mixer adapter]({{home}}/docs/concepts/policies-and-telemetry/overview.html#adapters).
In the current release, the Istio RBAC engine is implemented as a [Mixer adapter](/docs/concepts/policies-and-telemetry/overview/#adapters).
The request context is provided as an instance of the
[authorization template](https://github.com/istio/istio/blob/master/mixer/template/authorization/template.proto). The request context
contains all the information about the request and the environment that an authorization module needs to know. In particular, it has two parts:
@ -248,4 +246,4 @@ spec:
## What's next
Try out the [Istio RBAC with Bookinfo]({{home}}/docs/tasks/security/role-based-access-control.html) sample.
Try out the [Istio RBAC with Bookinfo](/docs/tasks/security/role-based-access-control/) sample.

6
content/docs/concepts/traffic-management/_index.md
View File

@ -1,10 +1,6 @@
---
title: Traffic Management
description: Describes the various Istio features focused on traffic routing and control.
weight: 20
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}

7
content/docs/concepts/traffic-management/fault-injection.md
View File

@ -1,14 +1,11 @@
---
title: Fault Injection
description: Introduces the idea of systematic fault injection that can be used to uncover conflicting failure recovery policies across services.
weight: 40
toc: false
---
While Envoy sidecar/proxy provides a host of
[failure recovery mechanisms](./handling-failures.html) to services running
[failure recovery mechanisms](/docs/concepts/traffic-management/handling-failures/) to services running
on Istio, it is still
imperative to test the end-to-end failure recovery capability of the
application as a whole. Misconfigured failure recovery policies (e.g.,
@ -31,4 +28,4 @@ increased network latency, or an overloaded upstream service. Aborts are
crash failures that mimic failures in upstream services. Aborts usually
manifest in the form of HTTP error codes, or TCP connection failures.
Refer to [Istio's traffic management rules](./rules-configuration.html) for more details.
Refer to [Istio's traffic management rules](/docs/concepts/traffic-management/rules-configuration/) for more details.

9
content/docs/concepts/traffic-management/handling-failures.md
View File

@ -1,11 +1,8 @@
---
title: Handling Failures
description: An overview of failure recovery capabilities in Envoy that can be leveraged by unmodified applications to improve robustness and prevent cascading failures.
weight: 30
---
{% include home.html %}
Envoy provides a set of out-of-the-box _opt-in_ failure recovery features
that can be taken advantage of by the services in an application. Features
@ -23,7 +20,7 @@ include:
instance in the load balancing pool
These features can be dynamically configured at runtime through
[Istio's traffic management rules](./rules-configuration.html).
[Istio's traffic management rules](/docs/concepts/traffic-management/rules-configuration/).
The jitter between retries minimizes the impact of retries on an overloaded
upstream service, while timeout budgets ensure that the calling service
@ -44,9 +41,9 @@ and prevent localized failures from cascading instability to other nodes.
Istio's traffic management rules allow
operators to set global defaults for failure recovery per
service/version. However, consumers of a service can also override
[timeout]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#HTTPTimeout)
[timeout](/docs/reference/config/istio.routing.v1alpha1/#HTTPTimeout)
and
[retry]({{home}}/docs/reference/config/istio.routing.v1alpha1.html#HTTPRetry)
[retry](/docs/reference/config/istio.routing.v1alpha1/#HTTPRetry)
defaults by providing request-level overrides through special HTTP headers.
With the Envoy proxy implementation, the headers are `x-envoy-upstream-rq-timeout-ms` and
`x-envoy-max-retries`, respectively.

11
content/docs/concepts/traffic-management/load-balancing.md
View File

@ -1,10 +1,7 @@
---
title: Discovery & Load Balancing
description: Describes how traffic is load balanced across instances of a service in the mesh.
weight: 25
toc: false
---
This page describes how Istio load balances traffic across instances of a
@ -23,10 +20,10 @@ registry and provides a platform-agnostic service discovery
interface. Envoy instances in the mesh perform service discovery and
dynamically update their load balancing pools accordingly.
{% include image.html width="80%" ratio="74.79%"
link="./img/pilot/LoadBalancing.svg"
{{< image width="80%" ratio="74.79%"
link="../img/pilot/LoadBalancing.svg"
caption="Discovery and Load Balancing"
%}
>}}
As illustrated in the figure above, services in the mesh access each other
using their DNS names. All HTTP traffic bound to a service is automatically
@ -44,7 +41,7 @@ check failures for a given instance exceeds a pre-specified threshold, it
will be ejected from the load balancing pool. Similarly, when the number of
health checks that pass exceed a pre-specified threshold, the instance will
be added back into the load balancing pool. You can find out more about Envoy's
failure-handling features in [Handling Failures](./handling-failures.html).
failure-handling features in [Handling Failures](/docs/concepts/traffic-management/handling-failures/).
Services can actively shed load by responding with a HTTP 503 to a health
check. In such an event, the service instance will be immediately removed

22
content/docs/concepts/traffic-management/overview.md
View File

@ -1,16 +1,12 @@
---
title: Overview
description: Provides a conceptual overview of traffic management in Istio and the features it enables.
weight: 1
---
{% include home.html %}
This page provides an overview of how traffic management works
in Istio, including the benefits of its traffic management
principles. It assumes that you've already read [What Is Istio?]({{home}}/docs/concepts/what-is-istio/overview.html)
principles. It assumes that you've already read [What Is Istio?](/docs/concepts/what-is-istio/overview/)
and are familiar with Istio's high-level architecture. You can
find out more about individual traffic management features in the other
guides in this section.
@ -18,7 +14,7 @@ guides in this section.
## Pilot and Envoy
The core component used for traffic management in Istio is
[Pilot](./pilot.html), which manages and configures all the Envoy
[Pilot](/docs/concepts/traffic-management/pilot/), which manages and configures all the Envoy
proxy instances deployed in a particular Istio service mesh. It lets you
specify what rules you want to use to route traffic between Envoy proxies
and configure failure recovery features such as timeouts, retries, and
@ -26,7 +22,7 @@ circuit breakers. It also maintains a canonical model of all the services
in the mesh and uses this to let Envoys know about the other instances in
the mesh via its discovery service.
Each Envoy instance maintains [load balancing information](./load-balancing.html)
Each Envoy instance maintains [load balancing information](/docs/concepts/traffic-management/load-balancing/)
based on the information it gets from Pilot and periodic health-checks
of other instances in its load-balancing pool, allowing it to intelligently
distribute traffic between destination instances while following its specified
@ -43,17 +39,17 @@ of traffic for a particular service to go to a canary version irrespective
of the size of the canary deployment, or send traffic to a particular version
depending on the content of the request.
{% include image.html width="85%" ratio="69.52%"
link="./img/pilot/TrafficManagementOverview.svg"
{{< image width="85%" ratio="69.52%"
link="../img/pilot/TrafficManagementOverview.svg"
caption="Traffic Management with Istio"
%}
>}}
Decoupling traffic flow from infrastructure scaling like this allows Istio
to provide a variety of traffic management features that live outside the
application code. As well as dynamic [request routing](request-routing.html)
application code. As well as dynamic [request routing](/docs/concepts/traffic-management/request-routing/)
for A/B testing, gradual rollouts, and canary releases, it also handles
[failure recovery](handling-failures.html) using timeouts, retries, and
circuit breakers, and finally [fault injection](fault-injection.html) to
[failure recovery](/docs/concepts/traffic-management/handling-failures/) using timeouts, retries, and
circuit breakers, and finally [fault injection](/docs/concepts/traffic-management/fault-injection/) to
test the compatibility of failure recovery policies across services. These
capabilities are all realized through the Envoy sidecars/proxies deployed
across the service mesh.

14
content/docs/concepts/traffic-management/pilot.md
View File

@ -1,23 +1,19 @@
---
title: Pilot
description: Introduces Pilot, the component responsible for managing a distributed deployment of Envoy proxies in the service mesh.
weight: 10
toc: false
redirect_from:
aliases:
- /docs/concepts/traffic-management/manager.html
---
{% include home.html %}
Pilot is responsible for the lifecycle of Envoy instances deployed
across the Istio service mesh.
{% include image.html width="60%" ratio="72.17%"
link="./img/pilot/PilotAdapters.svg"
alt="Pilot's overall architecture."
{{< image width='60%' ratio="72.17%"
link="../img/pilot/PilotAdapters.svg"
caption="Pilot Architecture"
%}
>}}
As illustrated in the figure above, Pilot maintains a canonical
representation of services in the mesh that is independent of the underlying
@ -36,5 +32,5 @@ These APIs decouple Envoy from platform-specific nuances, simplifying the
design and increasing portability across platforms.
Operators can specify high-level traffic management rules through
[Pilot's Rules API]({{home}}/docs/reference/config/istio.routing.v1alpha1.html). These rules are translated into low-level
[Pilot's Rules API](/docs/reference/config/istio.routing.v1alpha1/). These rules are translated into low-level
configurations and distributed to Envoy instances via the discovery API.

23
content/docs/concepts/traffic-management/request-routing.md
View File

@ -1,17 +1,14 @@
---
title: Request Routing
description: Describes how requests are routed between services in an Istio service mesh.
weight: 20
---
{% include home.html %}
This page describes how requests are routed between services in an Istio service mesh.
## Service model and service versions
As described in [Pilot](./pilot.html), the canonical representation
As described in [Pilot](/docs/concepts/traffic-management/pilot/), the canonical representation
of services in a particular mesh is maintained by Pilot. The Istio
model of a service is independent of how it is represented in the underlying
platform (Kubernetes, Mesos, Cloud Foundry,
@ -25,16 +22,16 @@ way to subdivide service instances by versions (`v1`, `v2`) or environment
versions: they could be iterative changes to the same service, deployed in
different environments (prod, staging, dev, etc.). Common scenarios where
this is used include A/B testing or canary rollouts. Istio's [traffic
routing rules](./rules-configuration.html) can refer to service versions to provide
routing rules](/docs/concepts/traffic-management/rules-configuration/) can refer to service versions to provide
additional control over traffic between services.
## Communication between services
{% include image.html width="60%" ratio="100.42%"
link="./img/pilot/ServiceModel_Versions.svg"
{{< image width='60%' ratio="100.42%"
link="../img/pilot/ServiceModel_Versions.svg"
alt="Showing how service versions are handled."
caption="Service Versions"
%}
>}}
As illustrated in the figure above, clients of a service have no knowledge
of different versions of the service. They can continue to access the
@ -46,14 +43,14 @@ Envoy determines its actual choice of service version dynamically
based on the routing rules specified by the operator using Pilot. This
model enables the application code to decouple itself from the evolution of its dependent
services, while providing other benefits as well (see
[Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html)). Routing
[Mixer](/docs/concepts/policies-and-telemetry/overview/)). Routing
rules allow Envoy to select a version based
on criteria such as headers, tags associated with
source/destination, and/or by weights assigned to each version.
Istio also provides load balancing for traffic to multiple instances of
the same service version. You can find out more about this in [Discovery
and Load-Balancing](./load-balancing.html).
and Load-Balancing](/docs/concepts/traffic-management/load-balancing/).
Istio does not provide a DNS. Applications can try to resolve the
FQDN using the DNS service present in the underlying platform (kube-dns,
@ -70,9 +67,9 @@ via the sidecar Envoy, operators can add failure recovery features such as
timeouts, retries, circuit breakers, etc., and obtain detailed metrics on
the connections to these services.
{% include image.html width="60%" ratio="28.88%"
link="./img/pilot/ServiceModel_RequestFlow.svg"
{{< image width="60%" ratio="28.88%"
link="../img/pilot/ServiceModel_RequestFlow.svg"
alt="Ingress and Egress through Envoy."
caption="Request Flow"
%}
>}}

31
content/docs/concepts/traffic-management/rules-configuration.md
View File

@ -1,11 +1,8 @@
---
title: Rules Configuration
description: Provides a high-level overview of the configuration model used by Istio to configure traffic management rules in the service mesh.
weight: 50
---
{% include home.html %}
Istio provides a simple configuration model to
control how API calls and layer-4 traffic flow across various
@ -61,21 +58,21 @@ For example, in a Kubernetes deployment of Istio, "version: v1" indicates that
only pods containing the label "version: v1" will receive traffic.
Rules can be configured using the
[istioctl CLI]({{home}}/docs/reference/commands/istioctl.html), or in a Kubernetes
[istioctl CLI](/docs/reference/commands/istioctl/), or in a Kubernetes
deployment using the `kubectl` command instead, although only `istioctl` will
perform model validation and is recommended. See the
[configuring request routing task]({{home}}/docs/tasks/traffic-management/request-routing.html)
[configuring request routing task](/docs/tasks/traffic-management/request-routing/)
for examples.
There are four traffic management configuration resources in Istio:
**VirtualService**, **DestinationRule**, **ServiceEntry**, and **Gateway**.
A few important aspects of these resources are described below.
See [networking reference]({{home}}/docs/reference/config/istio.networking.v1alpha3.html)
See [networking reference](/docs/reference/config/istio.networking.v1alpha3/)
for detailed information.
## Virtual Services
A [VirtualService]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#VirtualService)
A [VirtualService](/docs/reference/config/istio.networking.v1alpha3/#VirtualService)
defines the rules that control how requests for a service are routed within an Istio service mesh.
For example, a virtual service could route requests to different versions of a service or, in fact,
to a completely different service than was requested.
@ -298,9 +295,9 @@ spec:
```
Note that request timeouts and retries can also be
[overridden on a per-request basis](./handling-failures.html#fine-tuning).
[overridden on a per-request basis](/docs/concepts/traffic-management/handling-failures#fine-tuning).
See the [request timeouts task]({{home}}/docs/tasks/traffic-management/request-timeouts.html) for a demonstration of timeout control.
See the [request timeouts task](/docs/tasks/traffic-management/request-timeouts/) for a demonstration of timeout control.
### Injecting faults in the request path
@ -383,7 +380,7 @@ spec:
subset: v1
```
To see fault injection in action, see the [fault injection task]({{home}}/docs/tasks/traffic-management/fault-injection.html).
To see fault injection in action, see the [fault injection task](/docs/tasks/traffic-management/fault-injection/).
### HTTP route rules have precedence
@ -445,7 +442,7 @@ priorities of each rule when there is more than one.
## Destination Rules
A [DestinationRule]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#DestinationRule)
A [DestinationRule](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule)
configures the set of policies to be applied to a request after `VirtualService` routing has occurred. They are
intended to be authored by service owners, describing the circuit breakers, load balancer settings, TLS settings, etc..
@ -506,7 +503,7 @@ spec:
maxConnections: 100
```
See the [circuit-breaking task]({{home}}/docs/tasks/traffic-management/circuit-breaking.html) for a demonstration of circuit breaker control.
See the [circuit-breaking task](/docs/tasks/traffic-management/circuit-breaking/) for a demonstration of circuit breaker control.
### DestinationRule evaluation
@ -599,7 +596,7 @@ start, is generally considered a best practice in Istio.
## Service Entries
A [ServiceEntry]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#ServiceEntry)
A [ServiceEntry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry)
is used to add additional entries into the service registry that Istio maintains internally.
It is most commonly used to enable requests to services outside of an Istio service mesh.
For example, the following `ServiceEntry` can be used to allow external calls to services hosted
@ -663,12 +660,12 @@ timeout and fault injection policies are all supported for external destinations
Weighted (version-based) routing is not possible, however, since there is no notion
of multiple versions of an external service.
See the [egress task]({{home}}/docs/tasks/traffic-management/egress.html) for a more
See the [egress task](/docs/tasks/traffic-management/egress/) for a more
about accessing external services.
## Gateways
A [Gateway]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#Gateway)
A [Gateway](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
configure a load balancer for HTTP/TCP traffic, most commonly operating at the edge of the
mesh to enable ingress traffic for an application.
@ -721,11 +718,11 @@ spec:
...
```
See the [ingress task]({{home}}/docs/tasks/traffic-management/ingress.html) for a
See the [ingress task](/docs/tasks/traffic-management/ingress/) for a
complete ingress gateway example.
Although primarily used to manage ingress traffic, a `Gateway` can also be used to model
a purely internal or egress proxy. Irrespective of the location, all gateways
can be configured and controlled in the same way. Refer to the
[gateway reference]({{home}}/docs/reference/config/istio.networking.v1alpha3.html#Gateway)
[gateway reference](/docs/reference/config/istio.networking.v1alpha3/#Gateway)
for details.

6
content/docs/concepts/what-is-istio/_index.md
View File

@ -1,10 +1,6 @@
---
title: What is Istio?
description: A broad overview of the Istio system.
weight: 10
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}

2
content/docs/concepts/what-is-istio/goals.md
View File

@ -1,9 +1,7 @@
---
title: Design Goals
description: Describes the core principles that Istio's design adheres to.
weight: 20
---
This page outlines the core principles that guide Istio's design.

33
content/docs/concepts/what-is-istio/overview.md
View File

@ -1,17 +1,14 @@
---
title: Overview
description: Provides a conceptual introduction to Istio, including the problems it solves and its high-level architecture.
weight: 15
---
{% include home.html %}
This document introduces Istio: an open platform to connect, manage, and secure microservices. Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured and managed using Istio's control plane functionality.
Istio currently supports service deployment on Kubernetes, as well as services registered with Consul or Eureka and services running on individual VMs.
For detailed conceptual information about Istio components see our other [Concepts]({{home}}/docs/concepts/) guides.
For detailed conceptual information about Istio components see our other [Concepts](/docs/concepts/) guides.
## Why use Istio?
@ -60,11 +57,11 @@ configuring proxies to route traffic, and configuring Mixers to enforce policies
The following diagram shows the different components that make up each plane:
{% include image.html width="80%" ratio="56.25%"
link="./img/overview/arch.svg"
{{< image width="80%" ratio="56.25%"
link="../img/overview/arch.svg"
alt="The overall architecture of an Istio-based application."
caption="Istio Architecture"
%}
>}}
### Envoy
@ -72,17 +69,17 @@ Istio uses an extended version of the [Envoy](https://envoyproxy.github.io/envoy
Istio leverages Envoy’s many built-in features such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers,
health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics.
Envoy is deployed as a **sidecar** to the relevant service in the same Kubernetes pod. This allows Istio to extract a wealth of signals about traffic behavior as [attributes]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes), which in turn it can use in [Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html) to enforce policy decisions, and be sent to monitoring systems to provide information about the behavior of the entire mesh. The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code. You can read more about why we chose this approach in our [Design Goals]({{home}}/docs/concepts/what-is-istio/goals.html).
Envoy is deployed as a **sidecar** to the relevant service in the same Kubernetes pod. This allows Istio to extract a wealth of signals about traffic behavior as [attributes](/docs/concepts/policies-and-telemetry/config/#attributes), which in turn it can use in [Mixer](/docs/concepts/policies-and-telemetry/overview/) to enforce policy decisions, and be sent to monitoring systems to provide information about the behavior of the entire mesh. The sidecar proxy model also allows you to add Istio capabilities to an existing deployment with no need to rearchitect or rewrite code. You can read more about why we chose this approach in our [Design Goals](/docs/concepts/what-is-istio/goals/).
### Mixer
[Mixer]({{home}}/docs/concepts/policies-and-telemetry/overview.html) is a platform-independent component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other
services. The proxy extracts request level [attributes]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes), which are sent to Mixer for evaluation. More information on this attribute extraction and policy
evaluation can be found in [Mixer Configuration]({{home}}/docs/concepts/policies-and-telemetry/config.html). Mixer includes a flexible plugin model enabling it to interface with a variety of host environments and infrastructure backends, abstracting the Envoy proxy and Istio-managed services from these details.
[Mixer](/docs/concepts/policies-and-telemetry/overview/) is a platform-independent component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other
services. The proxy extracts request level [attributes](/docs/concepts/policies-and-telemetry/config/#attributes), which are sent to Mixer for evaluation. More information on this attribute extraction and policy
evaluation can be found in [Mixer Configuration](/docs/concepts/policies-and-telemetry/config/). Mixer includes a flexible plugin model enabling it to interface with a variety of host environments and infrastructure backends, abstracting the Envoy proxy and Istio-managed services from these details.
### Pilot
[Pilot]({{home}}/docs/concepts/traffic-management/pilot.html) provides
[Pilot](/docs/concepts/traffic-management/pilot/) provides
service discovery for the Envoy sidecars, traffic management capabilities
for intelligent routing (e.g., A/B tests, canary deployments, etc.),
and resiliency (timeouts, retries, circuit breakers, etc.). It converts
@ -97,17 +94,17 @@ interface for traffic management.
### Citadel
[Citadel]({{home}}/docs/concepts/security/) provides strong service-to-service and end-user authentication, with built-in identity and
[Citadel](/docs/concepts/security/) provides strong service-to-service and end-user authentication, with built-in identity and
credential management. It can be used to upgrade unencrypted traffic in the service mesh, and provides operators the ability to enforce
policy based on service identity rather than network controls. Starting from release 0.5, Istio supports
[role-based access control]({{home}}/docs/concepts/security/rbac.html) to control who can access your services.
[role-based access control](/docs/concepts/security/rbac/) to control who can access your services.
## What's next
- Learn about Istio's [design goals]({{home}}/docs/concepts/what-is-istio/goals.html).
- Learn about Istio's [design goals](/docs/concepts/what-is-istio/goals/).
- Explore our [Guides]({{home}}/docs/guides/).
- Explore our [Guides](/docs/guides/).
- Read about Istio components in detail in our other [Concepts]({{home}}/docs/concepts/) guides.
- Read about Istio components in detail in our other [Concepts](/docs/concepts/) guides.
- Learn how to deploy Istio with your own services using our [Tasks]({{home}}/docs/tasks/) guides.
- Learn how to deploy Istio with your own services using our [Tasks](/docs/tasks/) guides.

6
content/docs/guides/_index.md
View File

@ -2,9 +2,7 @@
title: Guides
description: Guides include a variety of fully working example uses for Istio that you can experiment with.
weight: 30
toc: false
redirect_from:
type: section-index
aliases:
/docs/samples/index.html
---
{% include section-index.html docs=site.docs %}

31
content/docs/guides/bookinfo.md
View File

@ -2,12 +2,11 @@
title: Bookinfo Sample Application
description: This guide deploys a sample application composed of four separate microservices which will be used to demonstrate various features of the Istio service mesh.
weight: 10
redirect_from:
aliases:
- /docs/samples/bookinfo.html
---
{% include home.html %}
> Note: This guide assumes you will be using the new [v1alpha3 traffic management API]({{home}}/blog/2018/v1alpha3-routing.html).
> Note: This guide assumes you will be using the new [v1alpha3 traffic management API](/blog/2018/v1alpha3-routing/).
The old API has been deprecated and will be removed in the next Istio release.
If you need to use the old version, you can follow the old instructions [here](https://archive.istio.io/v0.6/docs/guides/bookinfo.html),
but note that on Kubernetes you will need to run an additional command (`kubectl apply -f samples/bookinfo/kube/bookinfo-gateway.yaml`)
@ -38,10 +37,10 @@ There are 3 versions of the reviews microservice:
The end-to-end architecture of the application is shown below.
{% include image.html width="80%" ratio="68.52%"
link="./img/bookinfo/noistio.svg"
{{< image width="80%" ratio="68.52%"
link="../img/bookinfo/noistio.svg"
caption="Bookinfo Application without Istio"
%}
>}}
This application is polyglot, i.e., the microservices are written in different languages.
It’s worth noting that these services have no dependencies on Istio, but make an interesting
@ -51,7 +50,7 @@ for the reviews service.
## Before you begin
If you haven't already done so, setup Istio by following the instructions
corresponding to your platform [installation guide]({{home}}/docs/setup/).
corresponding to your platform [installation guide](/docs/setup/).
## Deploying the application
@ -61,10 +60,10 @@ Istio-enabled environment, with Envoy sidecars injected along side each service.
The needed commands and configuration vary depending on the runtime environment
although in all cases the resulting deployment will look like this:
{% include image.html width="80%" ratio="59.08%"
link="./img/bookinfo/withistio.svg"
{{< image width="80%" ratio="59.08%"
link="../img/bookinfo/withistio.svg"
caption="Bookinfo Application"
%}
>}}
All of the microservices will be packaged with an Envoy sidecar that intercepts incoming
and outgoing calls for the services, providing the hooks needed to externally control,
@ -81,7 +80,7 @@ To start the application, follow the instructions below corresponding to your Is
1. Bring up the application containers:
* If you are using [manual sidecar injection]({{home}}/docs/setup/kubernetes/sidecar-injection.html#manual-sidecar-injection),
* If you are using [manual sidecar injection](/docs/setup/kubernetes/sidecar-injection/#manual-sidecar-injection),
use the following command
```command
@ -89,10 +88,10 @@ To start the application, follow the instructions below corresponding to your Is
```
The `istioctl kube-inject` command is used to manually modify the `bookinfo.yaml`
file before creating the deployments as documented [here]({{home}}/docs/reference/commands/istioctl.html#istioctl kube-inject).
file before creating the deployments as documented [here](/docs/reference/commands/istioctl/#istioctl kube-inject).
* If you are using a cluster with
[automatic sidecar injection]({{home}}/docs/setup/kubernetes/sidecar-injection.html#automatic-sidecar-injection)
[automatic sidecar injection](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection)
enabled, simply deploy the services using `kubectl`
```command
@ -138,7 +137,7 @@ To start the application, follow the instructions below corresponding to your Is
#### Determining the ingress IP and port
Follow [the instructions]({{home}}/docs/tasks/traffic-management/ingress.html#determining-the-ingress-ip-and-ports) to set the `INGRESS_HOST` and `INGRESS_PORT` variables. Set `GATEWAY_URL`:
Follow [the instructions](/docs/tasks/traffic-management/ingress/#determining-the-ingress-ip-and-ports) to set the `INGRESS_HOST` and `INGRESS_PORT` variables. Set `GATEWAY_URL`:
```command
$ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
@ -195,8 +194,8 @@ version routing.
You can now use this sample to experiment with Istio's features for
traffic routing, fault injection, rate limiting, etc..
To proceed, refer to one or more of the [Istio Guides]({{home}}/docs/guides),
depending on your interest. [Intelligent Routing]({{home}}/docs/guides/intelligent-routing.html)
To proceed, refer to one or more of the [Istio Guides](/docs/guides),
depending on your interest. [Intelligent Routing](/docs/guides/intelligent-routing/)
is a good place to start for beginners.
## Cleanup

12
content/docs/guides/endpoints.md
View File

@ -1,10 +1,8 @@
---
title: Install Istio for Google Cloud Endpoints Services
description: Explains how to manually integrate Google Cloud Endpoints services with Istio.
weight: 42
---
{% include home.html %}
This document shows how to manually integrate Istio with existing
Google Cloud Endpoints services.
@ -21,12 +19,12 @@ You may test the service using the following command:
$ curl --request POST --header "content-type:application/json" --data '{"message":"hello world"}' "http://${EXTERNAL_IP}:80/echo?key=${ENDPOINTS_KEY}"
```
You need to install Istio with [instructions]({{home}}/docs/setup/kubernetes/quick-start.html#google-kubernetes-engine).
You need to install Istio with [instructions](/docs/setup/kubernetes/quick-start/#google-kubernetes-engine).
## HTTP Endpoints service
1. Inject the service into the mesh using `--includeIPRanges` by following the
[instructions]({{home}}/docs/tasks/traffic-management/egress.html#calling-external-services-directly)
[instructions](/docs/tasks/traffic-management/egress/#calling-external-services-directly)
so that Egress is allowed to call external services directly.
Otherwise, ESP won't be able to access Google cloud service control.
@ -53,7 +51,7 @@ Otherwise, ESP won't be able to access Google cloud service control.
EOF
```
1. Get the Ingress IP through [instructions]({{home}}/docs/tasks/traffic-management/ingress.html#verifying-the-gateway-for-http).
1. Get the Ingress IP through [instructions](/docs/tasks/traffic-management/ingress/#verifying-the-gateway-for-http).
You can verify accessing the Endpoints service through Ingress:
```command
@ -89,7 +87,7 @@ Adding `"--http_port=8081"` in the ESP deployment arguments and expose the HTTP
1. After this, you will find access to `EXTERNAL_IP` no longer works because istio proxy only accept secure mesh connections.
Accessing through Ingress works because Ingress does HTTP terminations.
1. To secure the access at Ingress, following the [instructions]({{home}}/docs/tasks/traffic-management/ingress.html#add-a-secure-port-https-to-our-gateway).
1. To secure the access at Ingress, following the [instructions](/docs/tasks/traffic-management/ingress/#add-a-secure-port-https-to-our-gateway).
1. You can verify accessing the Endpoints service through secure Ingress:
@ -111,7 +109,7 @@ This solution uses Istio proxy for TCP bypassing. The traffic is secured through
```
1. Update the mesh service deployment. See further readings on port naming rules
[here]({{home}}/docs/setup/kubernetes/sidecar-injection.html#pod-spec-requirements).
[here](/docs/setup/kubernetes/sidecar-injection/#pod-spec-requirements).
1. You can verify access to the Endpoints service through secure Ingress:

14
content/docs/guides/integrating-vms.md
View File

@ -1,10 +1,8 @@
---
title: Integrating Virtual Machines
description: This sample deploys the Bookinfo services across Kubernetes and a set of virtual machines, and illustrates how to use the Istio service mesh to control this infrastructure as a single mesh.
weight: 60
---
{% include home.html %}
This sample deploys the Bookinfo services across Kubernetes and a set of
Virtual Machines, and illustrates how to use Istio service mesh to control
@ -16,21 +14,21 @@ VMs cannot initiate any direct communication to Kubernetes Pods even when using
## Overview
{% include image.html width="80%" ratio="56.78%"
link="./img/mesh-expansion.svg"
{{< image width="80%" ratio="56.78%"
link="../img/mesh-expansion.svg"
caption="Bookinfo Application with Istio Mesh Expansion"
%}
>}}
<!-- source of the drawing https://docs.google.com/drawings/d/1gQp1OTusiccd-JUOHktQ9RFZaqREoQbwl2Vb-P3XlRQ/edit -->
## Before you begin
* Setup Istio by following the instructions in the
[Installation guide]({{home}}/docs/setup/kubernetes/quick-start.html).
[Installation guide](/docs/setup/kubernetes/quick-start/).
* Deploy the [Bookinfo]({{home}}/docs/guides/bookinfo.html) sample application (in the `bookinfo` namespace).
* Deploy the [Bookinfo](/docs/guides/bookinfo/) sample application (in the `bookinfo` namespace).
* Create a VM named 'vm-1' in the same project as Istio cluster, and [Join the Mesh]({{home}}/docs/setup/kubernetes/mesh-expansion.html).
* Create a VM named 'vm-1' in the same project as Istio cluster, and [Join the Mesh](/docs/setup/kubernetes/mesh-expansion/).
## Running MySQL on the VM

16
content/docs/guides/intelligent-routing.md
View File

@ -1,10 +1,8 @@
---
title: Intelligent Routing
description: This guide demonstrates how to use various traffic management capabilities of an Istio service mesh.
weight: 20
---
{% include home.html %}
This guide demonstrates how to use various traffic management capabilities
of an Istio service mesh.
@ -16,32 +14,32 @@ to externally control service monitoring and tracing, request (version) routing,
security and policy enforcement, etc., in a consistent way across the services,
for the application as a whole.
In this guide, we will use the [Bookinfo sample application]({{home}}/docs/guides/bookinfo.html)
In this guide, we will use the [Bookinfo sample application](/docs/guides/bookinfo/)
to show how operators can dynamically configure request routing and fault injection
for a running application.
## Before you begin
* Install the Istio control plane by following the instructions
corresponding to your platform [installation guide]({{home}}/docs/setup/).
corresponding to your platform [installation guide](/docs/setup/).
* Run the Bookinfo sample application by following the applicable
[application deployment instructions]({{home}}/docs/guides/bookinfo.html#deploying-the-application).
[application deployment instructions](/docs/guides/bookinfo/#deploying-the-application).
## Tasks
1. [Request routing]({{home}}/docs/tasks/traffic-management/request-routing.html) This task will first
1. [Request routing](/docs/tasks/traffic-management/request-routing/) This task will first
direct all incoming traffic for the Bookinfo application to the v1 version of the
`reviews` service. It will then send traffic only from a specific test user to version v2,
leaving all other users unaffected.
1. [Fault injection]({{home}}/docs/tasks/traffic-management/fault-injection.html) We will now use Istio to
1. [Fault injection](/docs/tasks/traffic-management/fault-injection/) We will now use Istio to
test the resiliency of the Bookinfo application by injecting an artificial delay in
requests between the `reviews:v2` and `ratings` services. Observing the resulting behavior
as the test user, we will notice that the v2 version of the `reviews` service has a bug.
Note that all other users are unaware of this testing against the live system.
1. [Traffic Shifting]({{home}}/docs/tasks/traffic-management/traffic-shifting.html) Finally, we will
1. [Traffic Shifting](/docs/tasks/traffic-management/traffic-shifting/) Finally, we will
use Istio to gradually migrate traffic for all users from to a v3 version of
the `reviews` service, one which includes the fix for the bug discovered in v2.
@ -49,5 +47,5 @@ for a running application.
When you're finished experimenting with the Bookinfo sample, you can
uninstall it by following the
[Bookinfo cleanup instructions]({{home}}/docs/guides/bookinfo.html#cleanup)
[Bookinfo cleanup instructions](/docs/guides/bookinfo/#cleanup)
corresponding to your environment.

31
content/docs/guides/policy-enforcement.md
View File

@ -1,31 +0,0 @@
---
title: Policy Enforcement
description: This sample uses the Bookinfo application to demonstrate policy enforcement using Istio Mixer.
weight: 40
draft: true
---
{% include home.html %}
This sample uses the Bookinfo application to demonstrate policy enforcement using Istio Mixer.
## Overview
Provide a high level overview of what users can expect to learn, why these
features are important, and so on. This is not a task, but a feature of
Istio.
## Before you begin
* Describe installation options.
* Install Istio control plane in a Kubernetes cluster by following the quick start instructions in the
[Installation guide]({{home}}/docs/setup/kubernetes/quick-start.html).
## Application Setup
1. Steps
## Tasks
1. some tasks that will complete the goal of this sample.

29
content/docs/guides/security.md
View File

@ -1,29 +0,0 @@
---
title: Security
description: This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
weight: 30
draft: true
---
{% include home.html %}
This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
## Overview
Placeholder.
## Before you begin
* Describe installation options.
* Install Istio control plane in a Kubernetes cluster by following the quick start instructions in the
[Installation guide]({{home}}/docs/setup/kubernetes/quick-start.html).
## Application Setup
1. Steps
## Tasks
1. some tasks that will complete the goal of this sample.

18
content/docs/guides/telemetry.md
View File

@ -1,10 +1,8 @@
---
title: In-Depth Telemetry
description: This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
weight: 30
---
{% include home.html %}
This sample demonstrates how to obtain uniform metrics, logs, traces across different services using Istio Mixer and Istio sidecar.
@ -15,7 +13,7 @@ to externally control service monitoring and tracing, request (version) routing,
security and policy enforcement, etc., in a consistent way across the services,
for the application as a whole.
In this guide, we will use the [Bookinfo sample application]({{home}}/docs/guides/bookinfo.html)
In this guide, we will use the [Bookinfo sample application](/docs/guides/bookinfo/)
to show how operators can obtain uniform metrics and traces from running
applications involving diverse language frameworks without relying on
developers to manually instrument their applications.
@ -23,22 +21,22 @@ developers to manually instrument their applications.
## Before you begin
* Install the Istio control plane by following the instructions
corresponding to your platform [installation guide]({{home}}/docs/setup/).
corresponding to your platform [installation guide](/docs/setup/).
* Run the Bookinfo sample application by following the applicable
[application deployment instructions]({{home}}/docs/guides/bookinfo.html#deploying-the-application).
[application deployment instructions](/docs/guides/bookinfo/#deploying-the-application).
## Tasks
1. [Collecting metrics]({{home}}/docs/tasks/telemetry/metrics-logs.html)
1. [Collecting metrics](/docs/tasks/telemetry/metrics-logs/)
This task will configure Mixer to collect a uniform set of metrics
across all services in the Bookinfo application.
1. [Querying metrics]({{home}}/docs/tasks/telemetry/querying-metrics.html)
1. [Querying metrics](/docs/tasks/telemetry/querying-metrics/)
This task installs the Prometheus add-on for metrics collection and
demonstrates querying a configured Prometheus server for Istio metrics.
1. [Distributed tracing]({{home}}/docs/tasks/telemetry/distributed-tracing.html)
1. [Distributed tracing](/docs/tasks/telemetry/distributed-tracing/)
We will now use Istio to trace how requests are flowing across services
in the application. Distributed tracing speeds up troubleshooting by
allowing developers to quickly understand how different services
@ -46,7 +44,7 @@ developers to manually instrument their applications.
can be a valuable tool to diagnosis and troubleshooting in distributed
applications.
1. [Using the Istio Dashboard]({{home}}/docs/tasks/telemetry/using-istio-dashboard.html)
1. [Using the Istio Dashboard](/docs/tasks/telemetry/using-istio-dashboard/)
This task installs the Grafana add-on with a preconfigured dashboard
for monitoring mesh traffic.
@ -54,5 +52,5 @@ developers to manually instrument their applications.
When you're finished experimenting with the Bookinfo sample, you can
uninstall it by following the
[Bookinfo cleanup instructions]({{home}}/docs/guides/bookinfo.html#cleanup)
[Bookinfo cleanup instructions](/docs/guides/bookinfo/#cleanup)
corresponding to your environment.

22
content/docs/guides/using-external-services.md
View File

@ -1,22 +0,0 @@
---
title: Integrating with External Services
description: This sample integrates third party services with Bookinfo and demonstrates how to use Istio service mesh to provide metrics, and routing functions for these services.
weight: 50
draft: true
---
{% include home.html %}
This sample integrates third party services with Bookinfo and demonstrates how to use Istio service mesh to provide metrics, and routing functions for these services.
## Overview
Placeholder.
## Application Setup
1. Steps
## Tasks
1. some tasks that will complete the goal of this sample.

7
content/docs/reference/_index.md
View File

@ -1,11 +1,6 @@
---
title: Reference
description: The Reference section contains detailed authoritative reference material such as command-line options, configuration options, and API calling parameters.
index: true
weight: 60
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}

7
content/docs/reference/commands/_index.md
View File

@ -1,11 +1,6 @@
---
title: Commands
description: Describes usage and options of the Istio commands and utilities.
weight: 30
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}

6
content/docs/reference/config/_index.md
View File

@ -1,10 +1,6 @@
---
title: Configuration
description: Detailed information on configuration options.
weight: 20
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}

5
content/docs/reference/config/policy-and-telemetry/_index.md
View File

@ -2,8 +2,7 @@
title: Policies and Telemetry
description: Describes how to configure Istio's policy and telemetry features.
weight: 30
redirect_from:
type: section-index
aliases:
- /docs/reference/config/mixer/index.html
---
{% include section-index.html docs=site.docs %}

6
content/docs/reference/config/policy-and-telemetry/adapters/_index.md
View File

@ -1,13 +1,9 @@
---
title: Adapters
description: Mixer adapters allow Istio to interface to a variety of infrastructure backends for such things as metrics and logs.
weight: 40
toc: false
type: section-index
---
{% include section-index.html docs=site.docs %}
To implement a new adapter for Mixer, please refer to the
[Adapter Developer's Guide](https://github.com/istio/istio/wiki/Mixer-Adapter-Dev-Guide).

2
content/docs/reference/config/policy-and-telemetry/adapters/circonus.html
View File

@ -10,7 +10,7 @@ number_of_entries: 3
<p>The <code>circonus</code> adapter enables Istio to deliver metric data to the
<a href="https://www.circonus.com">Circonus</a> monitoring backend.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">metric template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">metric template</a>.</p>
<h2 id="Params">Params</h2>
<section>

4
content/docs/reference/config/policy-and-telemetry/adapters/cloudwatch.html
View File

@ -14,12 +14,12 @@ number_of_entries: 3
(see <a href="https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html">AWS docs</a>).</p>
<p>To activate the CloudWatch adapter, operators need to provide configuration for the
<a href="{{site.baseurl}}/docs/reference/config/adapters/cloudwatch.html">cloudwatch adapter</a>.</p>
<a href="/docs/reference/config/policy-and-telemetry/adapters/cloudwatch/">cloudwatch adapter</a>.</p>
<p>The handler configuration must contain the same metrics as the instance configuration.
The metrics specified in both instance and handler configurations will be sent to CloudWatch.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">metric template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">metric template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/datadog.html
View File

@ -10,7 +10,7 @@ number_of_entries: 3
<p>The <code>dogstatsd</code> adapter is designed to deliver Istio metric instances to a
listening <a href="https://www.datadoghq.com/">DataDog</a> agent.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">metric template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">metric template</a>.</p>
<h2 id="Params">Params</h2>
<section>

6
content/docs/reference/config/policy-and-telemetry/adapters/denier.html
View File

@ -10,9 +10,9 @@ number_of_entries: 2
<p>The <code>denier</code> adapter is designed to always return a denial to precondition
checks. You can specify the exact error to return for these denials.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/checknothing.html">checknothing template</a>,
the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/listentry.html">listentry template</a>,
and the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/quota.html">quota template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/checknothing/">checknothing template</a>,
the <a href="/docs/reference/config/policy-and-telemetry/templates/listentry/">listentry template</a>,
and the <a href="/docs/reference/config/policy-and-telemetry/templates/quota/">quota template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/fluentd.html
View File

@ -10,7 +10,7 @@ number_of_entries: 1
<p>The <code>fluentd</code> adapter is designed to deliver Istio log entries to a
listening <a href="https://www.fluentd.org">fluentd</a> daemon.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/logentry.html">logentry template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/logentry/">logentry template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/kubernetesenv.html
View File

@ -10,7 +10,7 @@ number_of_entries: 1
<p>The <code>kubernetesenv</code> adapter extracts information from a Kubernetes environment
and produces attribtes that can be used in downstream adapters.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/kubernetes.html">kubernetesenv template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/kubernetes/">kubernetesenv template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/list.html
View File

@ -12,7 +12,7 @@ checks. You can configure the adapter with the list to check, or you can point
it to a URL from where the list should be fetched. Lists can be simple strings,
IP addresses, or regex patterns.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/listentry.html">listentry template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/listentry/">listentry template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/memquota.html
View File

@ -15,7 +15,7 @@ instance of Mixer running for the whole mesh (i.e. non-HA configuration)
and if that single instance crashes, all outstanding quota values will
be lost.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/quota.html">quota template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/quota/">quota template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/opa.html
View File

@ -10,7 +10,7 @@ number_of_entries: 1
<p>The <code>opa</code> adapter exposes an <a href="http://www.openpolicyagent.org">Open Policy Agent</a> engine
that provides sophisticated access control mechanisms.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/authorization.html">authorization template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/authorization/">authorization template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/rbac.html
View File

@ -10,7 +10,7 @@ number_of_entries: 1
<p>The <code>rbac</code> adapter provides Role-Based Access Control (RBAC) functionality for
for services within the Istio mesh.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/authorization.html">authorization template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/authorization/">authorization template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/redisquota.html
View File

@ -10,7 +10,7 @@ number_of_entries: 4
<p>The <code>redisquota</code> adapter can be used to support Istio&rsquo;s quota management
system. It depends on a Redis server to store quota values.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/quota.html">quota template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/quota/">quota template</a>.</p>
<h2 id="Params">Params</h2>
<section>

6
content/docs/reference/config/policy-and-telemetry/adapters/servicecontrol.html
View File

@ -10,9 +10,9 @@ number_of_entries: 4
<p>The <code>servicecontrol</code> adapter delivers logs and metrics to
<a href="https://cloud.google.com/service-control">Google Service Control</a>.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/servicecontrolreport.html">servicecontrolreport template</a>,
the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/quota.html">quota template</a>,
and the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/apikey.html">apikey template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/servicecontrolreport/">servicecontrolreport template</a>,
the <a href="/docs/reference/config/policy-and-telemetry/templates/quota/">quota template</a>,
and the <a href="/docs/reference/config/policy-and-telemetry/templates/apikey/">apikey template</a>.</p>
<h2 id="GcpServiceSetting">GcpServiceSetting</h2>
<section>

4
content/docs/reference/config/policy-and-telemetry/adapters/solarwinds.html
View File

@ -11,8 +11,8 @@ number_of_entries: 3
<a href="https://www.papertrailapp.com">Papertrail</a> logging backend and the
<a href="https://www.appoptics.com">AppOptics</a> monitoring backend.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">metric template</a>
and the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">logentry template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">metric template</a>
and the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">logentry template</a>.</p>
<h2 id="Params">Params</h2>
<section>

4
content/docs/reference/config/policy-and-telemetry/adapters/stackdriver.html
View File

@ -10,8 +10,8 @@ number_of_entries: 11
<p>The <code>stackdriver</code> adapter enables Istio to deliver log and metric data to the
<a href="https://cloud.google.com/stackdriver/">Stackdriver</a> logging and monitoring backend.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">metric template</a>,
and the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/logentry.html">logentry template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">metric template</a>,
and the <a href="/docs/reference/config/policy-and-telemetry/templates/logentry/">logentry template</a>.</p>
<h2 id="Params">Params</h2>
<section>

2
content/docs/reference/config/policy-and-telemetry/adapters/statsd.html
View File

@ -10,7 +10,7 @@ number_of_entries: 3
<p>The <code>statsd</code> adapter enables Istio to deliver metric data to a
<a href="https://github.com/etsy/statsd">StatsD</a> monitoring backend.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">metric template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">metric template</a>.</p>
<h2 id="Params">Params</h2>
<section>

4
content/docs/reference/config/policy-and-telemetry/adapters/stdio.html
View File

@ -14,8 +14,8 @@ reachable file. When outputting to files, you can enable file rotation
such that the adapter will automatically manage a set of file backups
as data is generated.</p>
<p>This adapter supports the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/logentry.html">logentry template</a>.
and the <a href="{{site.baseurl}}/docs/reference/config/policy-and-telemetry/templates/metric.html">metric template</a>.</p>
<p>This adapter supports the <a href="/docs/reference/config/policy-and-telemetry/templates/logentry/">logentry template</a>.
and the <a href="/docs/reference/config/policy-and-telemetry/templates/metric/">metric template</a>.</p>
<h2 id="Params">Params</h2>
<section>

7
content/docs/reference/config/policy-and-telemetry/attribute-vocabulary.md
View File

@ -2,13 +2,12 @@
title: Attribute Vocabulary
description: Describes the base attribute vocabulary used for policy and control.
weight: 10
redirect_from:
aliases:
- /docs/reference/config/policy-and-telemetry/attribute-vocabulary.html
---
{% include home.html %}
Attributes are a central concept used throughout Istio. You can find a description of what attributes are
and what they are used for [here]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes).
and what they are used for [here](/docs/concepts/policies-and-telemetry/config/#attributes).
A given Istio deployment has a fixed vocabulary of attributes that it understands. The specific vocabulary is
determined by the set of attribute producers being used in the deployment. The primary attribute producer in Istio
@ -67,7 +66,7 @@ deployments will have agents (Envoy or Mixer adapters) that produce these attrib
| context.time | timestamp | The timestamp of Mixer operation. | |
| api.service | string | The public service name. This is different than the in-mesh service identity and reflects the name of the service exposed to the client. | my-svc.com |
| api.version | string | The API version. | v1alpha1 |
| api.operation | string | Unique string used to identify the operation. The id is unique among all operations described in a specific <service, version>. | getPetsById |
| api.operation | string | Unique string used to identify the operation. The id is unique among all operations described in a specific &lt;service, version&gt;. | getPetsById |
| api.protocol | string | The protocol type of the API call. Mainly for monitoring/analytics. Note that this is the frontend protocol exposed to the client, not the protocol implemented by the backend service. | "http", “https”, or "grpc" |
| request.auth.principal | string | The authenticated principal of the request. This is a string of the issuer (`iss`) and subject (`sub`) claims within a JWT concatenated with “/” with a percent-encoded subject value. This attribute may come from the peer or the origin in the Istio authentication policy, depending on the binding rule defined in the Istio authentication policy. | accounts.my-svc.com/104958560606 |
| request.auth.audiences | string | The intended audience(s) for this authentication information. This should reflect the audience (`aud`) claim within a JWT. | ['my-svc.com', 'scopes/read'] |

10
content/docs/reference/config/policy-and-telemetry/expression-language.md
View File

@ -2,19 +2,15 @@
title: Expression Language
description: Mixer config expression language reference.
weight: 20
redirect_from:
aliases:
- /docs/reference/config/policy-and-telemetry/expression-language.html
---
{% include home.html %}
{% capture mixerConfig %}{{home}}/docs/concepts/policies-and-telemetry/config.html{% endcapture %}
This page describes how to use the Mixer config expression language (CEXL).
## Background
Mixer configuration uses an expression language (CEXL) to specify match expressions and [mapping expressions]({{mixerConfig}}#attribute-expressions). CEXL expressions map a set of typed [attributes]({{home}}/docs/concepts/policies-and-telemetry/config.html#attributes) and constants to a typed
Mixer configuration uses an expression language (CEXL) to specify match expressions and [mapping expressions](/docs/concepts/policies-and-telemetry/config/#attribute-expressions). CEXL expressions map a set of typed [attributes](/docs/concepts/policies-and-telemetry/config/#attributes) and constants to a typed
[value](https://github.com/istio/api/blob/master/policy/v1beta1/value_type.proto).
## Syntax
@ -45,7 +41,7 @@ CEXL supports the following functions.
## Type checking
CEXL variables are attributes from the typed [attribute vocabulary]({{home}}/docs/reference/config/policy-and-telemetry/attribute-vocabulary.html), constants are implicitly typed and, functions are explicitly typed.
CEXL variables are attributes from the typed [attribute vocabulary](/docs/reference/config/policy-and-telemetry/attribute-vocabulary/), constants are implicitly typed and, functions are explicitly typed.
Mixer validates a CEXL expression and resolves it to a type during config validation.
Selectors must resolve to a boolean value and mapping expressions must resolve to the type they are mapping into. Config validation fails if a selector fails to resolve to a boolean or if a mapping expression resolves to an incorrect type.

Some files were not shown because too many files have changed in this diff Show More