mirror of https://github.com/istio/istio.io.git
Introduce better linking support to github.com/istio/istio (#1443)
- Within a code block, you can now surround a relative file path with @@. This will
cause the path to be rendered as a link to raw.githubusercontent.com/istio/istio/<path>.
This lets the user click on the link to see the content of the file, which is mighty
handy.
- Updated all code blocks to take advantage of the above.
- Introduce support for {{< branch_name >}} which returns the source code branch
name associated with the current doc site.
- Use {{< branch_name >}} in all our references to content in istio/istio on GitHub. This thus
pins our references to the correct version of the content in GitHub. This prevents errors from
gradually appearing in our doc set as content in GitHub starts to diverge from the expectation
in the site content.
(cherry picked from commit 1dcd301
)
This commit is contained in:
parent
6827d5053a
commit
6962982274
|
@ -277,6 +277,22 @@ There
|
|||
If the output is the command is JSON or YAML, you can use `command-output-as-json` and `command-output-as-yaml`
|
||||
instead of merely `command` in order to apply syntax coloring to the command's output.
|
||||
|
||||
### Showing references to Istio GitHub files
|
||||
|
||||
If your code block references a file from Istio's GitHub repo, you can surround the relative path name of the file with a pair
|
||||
of @ symbols. These indicate the path should be rendered as a link to the file from the current branch. For example:
|
||||
|
||||
<pre class="language-markdown"><code>```command
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-reviews-v3.yaml@
|
||||
```
|
||||
</code></pre>
|
||||
|
||||
This will be rendered as:
|
||||
|
||||
```command
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-reviews-v3.yaml@
|
||||
```
|
||||
|
||||
## Displaying file content
|
||||
|
||||
You can pull in an external file and display its content as a preformatted block. This is handy to display a
|
||||
|
@ -285,13 +301,22 @@ config file or a test file. To do so, you use a statement such as:
|
|||
```markdown
|
||||
{{</* file_content url="https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml" lang="yaml" */>}}
|
||||
```
|
||||
|
||||
which produces the following result:
|
||||
|
||||
{{< file_content url="https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml" lang="yaml" >}}
|
||||
|
||||
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
|
||||
enabled so it may be used here.
|
||||
GitHub raw content site (raw.githubusercontent.com) is may be used here.
|
||||
|
||||
## Referencing GitHub files
|
||||
|
||||
When referencing files from Istio's GitHub repo, it is best to reference a specific branch in the repo. To reference the specific
|
||||
branch that the documentation site is currently targeting, you use the annotation {{</* branch_name */>}}. For example:
|
||||
|
||||
```maerdown
|
||||
See this [source file](https://github.com/istio/istio/blob/{{</* branch_name */>}}/mixer/cmd/mixs/cmd/server.go)/
|
||||
```
|
||||
|
||||
## Renaming or moving pages
|
||||
|
||||
|
|
|
@ -72,7 +72,7 @@ Below is our list of existing features and their current phases. This informatio
|
|||
| [Service-to-service mutual TLS](/docs/concepts/security/mutual-tls/) | Stable
|
||||
| [Authentication policy](/docs/concepts/security/authn-policy/) | 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
|
||||
| [OPA Checker](https://github.com/istio/istio/blob/{{<branch_name>}}/mixer/adapter/opa/README.md) | Alpha
|
||||
| RBAC Mixer Adapter | Alpha
|
||||
| [API Keys](/docs/reference/config/policy-and-telemetry/templates/apikey/) | Alpha
|
||||
|
||||
|
|
|
@ -95,5 +95,5 @@ Istio Auth is part of the broader security story for containers. Red Hat, a part
|
|||
|
||||
Istio Auth is the first step towards providing a full stack of capabilities to protect services with sensitive data from external attacks and insider
|
||||
threats. While the initial version runs on Kubernetes, our goal is to enable Istio Auth to secure services across diverse production environments. We encourage the
|
||||
community to [join us](https://github.com/istio/istio/blob/master/security) in making robust service security easy and ubiquitous across different application
|
||||
community to [join us](https://github.com/istio/istio/blob/{{<branch_name>}}/security) in making robust service security easy and ubiquitous across different application
|
||||
stacks and runtime platforms.
|
||||
|
|
|
@ -216,4 +216,4 @@ 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]() 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).
|
||||
The sample code used in this article can be found [here](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/helloworld).
|
||||
|
|
|
@ -87,4 +87,4 @@ Handlers provide configuration data for individual adapters, templates determine
|
|||
|
||||
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).
|
||||
[here](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/bookinfo/kube).
|
||||
|
|
|
@ -34,7 +34,7 @@ Here is a copy of the end-to-end architecture of the application from the origin
|
|||
Let's add a new version of the _details_ microservice, _v2_, that fetches the book details from [Google Books APIs](https://developers.google.com/books/docs/v1/getting_started).
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-details-v2.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-details-v2.yaml@)
|
||||
```
|
||||
|
||||
The updated architecture of the application now looks as follows:
|
||||
|
@ -140,7 +140,7 @@ sends regular HTTPS requests, encrypted end-to-end. On the bottom, the same micr
|
|||
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):
|
||||
Here is how we code this behavior in the [Bookinfo details microservice code](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/bookinfo/src/details/details.rb), using the Ruby [net/http module](https://docs.ruby-lang.org/en/2.0.0/Net/HTTP.html):
|
||||
|
||||
```ruby
|
||||
uri = URI.parse('https://www.googleapis.com/books/v1/volumes?q=isbn:' + isbn)
|
||||
|
@ -156,7 +156,7 @@ Note that the port is derived by the `URI.parse` from the URI's schema (https://
|
|||
When the `WITH_ISTIO` environment variable is defined, the request is performed without SSL (plain HTTP).
|
||||
|
||||
We set the `WITH_ISTIO` environment variable to _"true"_ in the
|
||||
[Kubernetes deployment spec of details v2](https://github.com/istio/istio/blob/master/samples/bookinfo/kube/bookinfo-details-v2.yaml),
|
||||
[Kubernetes deployment spec of details v2](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/bookinfo/kube/bookinfo-details-v2.yaml),
|
||||
the `container` section:
|
||||
|
||||
```yaml
|
||||
|
|
|
@ -20,7 +20,7 @@ For this task I set up an instance of [MySQL](https://www.mysql.com). You can us
|
|||
1. To initialize the database, I run the following command entering the password when prompted. The command is performed with the credentials of the `admin` user, created by default by [Compose for MySQL](https://www.ibm.com/cloud/compose/mysql).
|
||||
|
||||
```command
|
||||
$ curl -s https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/src/mysql/mysqldb-init.sql | \
|
||||
$ curl -s https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/samples/bookinfo/src/mysql/mysqldb-init.sql | \
|
||||
mysqlsh --sql --ssl-mode=REQUIRED -u admin -p --host <the database host> --port <the database port>
|
||||
```
|
||||
|
||||
|
@ -29,7 +29,7 @@ For this task I set up an instance of [MySQL](https://www.mysql.com). You can us
|
|||
When using the `mysql` client and a local MySQL database, I would run:
|
||||
|
||||
```command
|
||||
$ curl -s https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/src/mysql/mysqldb-init.sql | \
|
||||
$ curl -s https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/samples/bookinfo/src/mysql/mysqldb-init.sql | \
|
||||
mysql -u root -p
|
||||
```
|
||||
|
||||
|
@ -148,7 +148,7 @@ As a reminder, here is the end-to-end architecture of the application from the [
|
|||
1. I apply the modified spec to deploy the version of the _ratings_ microservice, _v2-mysql_, that will use my database.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-ratings-v2-mysql.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-ratings-v2-mysql.yaml@)
|
||||
deployment "ratings-v2-mysql" created
|
||||
```
|
||||
|
||||
|
@ -156,7 +156,7 @@ As a reminder, here is the end-to-end architecture of the application from the [
|
|||
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
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-ratings-mysql.yaml@
|
||||
Created config route-rule/default/ratings-test-v2-mysql at revision 1918799
|
||||
Created config route-rule/default/reviews-test-ratings-v2 at revision 1918800
|
||||
```
|
||||
|
@ -285,7 +285,7 @@ with Istio. The Istio control plane does not have to be accessible from the mach
|
|||
1. Remove the route rules:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/route-rule-ratings-mysql.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/route-rule-ratings-mysql.yaml@
|
||||
Deleted config: route-rule/default/ratings-test-v2-mysql
|
||||
Deleted config: route-rule/default/reviews-test-ratings-v2
|
||||
```
|
||||
|
@ -293,7 +293,7 @@ with Istio. The Istio control plane does not have to be accessible from the mach
|
|||
1. Undeploy _ratings v2-mysql_:
|
||||
|
||||
```command
|
||||
$ kubectl delete -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-ratings-v2-mysql.yaml)
|
||||
$ kubectl delete -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-ratings-v2-mysql.yaml@)
|
||||
deployment "ratings-v2-mysql" deleted
|
||||
```
|
||||
|
||||
|
|
|
@ -54,8 +54,8 @@ pods that make up the control plane (mixer, pilot, ingress, CA). Deploying the t
|
|||
control plane yaml files:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio.yaml
|
||||
$ kubectl apply -f install/kubernetes/istio-system1.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio.yaml@
|
||||
$ kubectl apply -f @install/kubernetes/istio-system1.yaml@
|
||||
```
|
||||
Results in two Istio control planes running in two namespaces.
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@ request context against the RBAC policies, and returns the authorization result
|
|||
|
||||
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
|
||||
[authorization template](/docs/reference/config/policy-and-telemetry/templates/authorization/). 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:
|
||||
|
||||
* **subject** contains a list of properties that identify the caller identity, including `"user"` name/ID, `"groups"` the subject belongs to,
|
||||
|
|
|
@ -84,7 +84,7 @@ To start the application, follow the instructions below corresponding to your Is
|
|||
use the following command
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject --debug -f samples/bookinfo/kube/bookinfo.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject --debug -f @samples/bookinfo/kube/bookinfo.yaml@)
|
||||
```
|
||||
|
||||
The `istioctl kube-inject` command is used to manually modify the `bookinfo.yaml`
|
||||
|
@ -95,7 +95,7 @@ To start the application, follow the instructions below corresponding to your Is
|
|||
enabled, simply deploy the services using `kubectl`
|
||||
|
||||
```command
|
||||
$ kubectl apply -f samples/bookinfo/kube/bookinfo.yaml
|
||||
$ kubectl apply -f @samples/bookinfo/kube/bookinfo.yaml@
|
||||
```
|
||||
|
||||
Either of the above commands launches all four microservices as illustrated in the above diagram.
|
||||
|
@ -107,7 +107,7 @@ To start the application, follow the instructions below corresponding to your Is
|
|||
1. Define the ingress gateway for the application:
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/routing/bookinfo-gateway.yaml
|
||||
$ istioctl create -f @samples/bookinfo/routing/bookinfo-gateway.yaml@
|
||||
```
|
||||
|
||||
1. Confirm all services and pods are correctly defined and running:
|
||||
|
@ -154,15 +154,15 @@ To start the application, follow the instructions below corresponding to your Is
|
|||
To test with Consul, run the following commands:
|
||||
|
||||
```command
|
||||
$ docker-compose -f samples/bookinfo/consul/bookinfo.yaml up -d
|
||||
$ docker-compose -f samples/bookinfo/consul/bookinfo.sidecars.yaml up -d
|
||||
$ docker-compose -f @samples/bookinfo/consul/bookinfo.yaml@ up -d
|
||||
$ docker-compose -f @samples/bookinfo/consul/bookinfo.sidecars.yaml@ up -d
|
||||
```
|
||||
|
||||
To test with Eureka, run the following commands:
|
||||
|
||||
```command
|
||||
$ docker-compose -f samples/bookinfo/eureka/bookinfo.yaml up -d
|
||||
$ docker-compose -f samples/bookinfo/eureka/bookinfo.sidecars.yaml up -d
|
||||
$ docker-compose -f @samples/bookinfo/eureka/bookinfo.yaml@ up -d
|
||||
$ docker-compose -f @samples/bookinfo/eureka/bookinfo.sidecars.yaml@ up -d
|
||||
```
|
||||
|
||||
1. Confirm that all docker containers are running:
|
||||
|
@ -210,7 +210,7 @@ uninstall and clean it up using the following instructions.
|
|||
1. Delete the routing rules and terminate the application pods
|
||||
|
||||
```command
|
||||
$ samples/bookinfo/kube/cleanup.sh
|
||||
$ @samples/bookinfo/kube/cleanup.sh@
|
||||
```
|
||||
|
||||
1. Confirm shutdown
|
||||
|
@ -228,13 +228,13 @@ uninstall and clean it up using the following instructions.
|
|||
In a Consul setup, run the following command:
|
||||
|
||||
```command
|
||||
$ samples/bookinfo/consul/cleanup.sh
|
||||
$ @samples/bookinfo/consul/cleanup.sh@
|
||||
```
|
||||
|
||||
In a Eureka setup, run the following command:
|
||||
|
||||
```command
|
||||
$ samples/bookinfo/eureka/cleanup.sh
|
||||
$ @samples/bookinfo/eureka/cleanup.sh@
|
||||
```
|
||||
|
||||
1. Confirm cleanup
|
||||
|
|
|
@ -52,7 +52,7 @@ You can find details of configuring MySQL at [Mysql](https://mariadb.com/kb/en/l
|
|||
On the VM add ratings database to mysql.
|
||||
|
||||
```command
|
||||
$ curl -q https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/src/mysql/mysqldb-init.sql | mysql -u root -ppassword
|
||||
$ curl -q https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/samples/bookinfo/src/mysql/mysqldb-init.sql | mysql -u root -ppassword
|
||||
```
|
||||
|
||||
To make it easy to visually inspect the difference in the output of the Bookinfo application, you can change the ratings that are generated by using the
|
||||
|
@ -109,15 +109,15 @@ Note that the 'mysqldb' virtual machine does not need and should not have specia
|
|||
The ratings service in bookinfo will use the DB on the machine. To verify that it works, create version 2 of the ratings service that uses the mysql db on the VM. Then specify route rules that force the review service to use the ratings version 2.
|
||||
|
||||
```command
|
||||
$ istioctl kube-inject -n bookinfo -f samples/bookinfo/kube/bookinfo-ratings-v2-mysql-vm.yaml | kubectl apply -n bookinfo -f -
|
||||
$ istioctl kube-inject -n bookinfo -f @samples/bookinfo/kube/bookinfo-ratings-v2-mysql-vm.yaml@ | kubectl apply -n bookinfo -f -
|
||||
```
|
||||
Create route rules that will force bookinfo to use the ratings back end:
|
||||
|
||||
```command
|
||||
$ istioctl create -n bookinfo -f samples/bookinfo/kube/route-rule-ratings-mysql-vm.yaml
|
||||
$ istioctl create -n bookinfo -f @samples/bookinfo/kube/route-rule-ratings-mysql-vm.yaml@
|
||||
```
|
||||
|
||||
You can verify the output of the Bookinfo application is showing 1 star from Reviewer1 and 4 stars from Reviewer2 or change the ratings on your VM and see the
|
||||
results.
|
||||
|
||||
You can also find some troubleshooting and other information in the [RawVM MySQL](https://github.com/istio/istio/blob/master/samples/rawvm/README.md) document in the meantime.
|
||||
You can also find some troubleshooting and other information in the [RawVM MySQL](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/rawvm/README.md) document in the meantime.
|
||||
|
|
|
@ -6,10 +6,10 @@ weight: 20
|
|||
|
||||
We use Go’s native tools to write targeted micro-benchmarks in performance sensitive areas. Our main goal with this approach is to provide easy-to-use micro-benchmarks that developers can use to perform quick before/after performance comparisons for their changes.
|
||||
|
||||
See the [sample micro-benchmark](https://github.com/istio/istio/blob/master/mixer/test/perf/singlecheck_test.go) for Mixer that measures the performance of attribute processing code.
|
||||
See the [sample micro-benchmark](https://github.com/istio/istio/blob/{{<branch_name>}}/mixer/test/perf/singlecheck_test.go) for Mixer that measures the performance of attribute processing code.
|
||||
|
||||
The developers can also utilize a golden-files approach to capture the state of their benchmark results in the source tree for keeping track and referencing purposes. GitHub has this [baseline file](https://github.com/istio/istio/blob/master/mixer/test/perf/bench.baseline).
|
||||
The developers can also utilize a golden-files approach to capture the state of their benchmark results in the source tree for keeping track and referencing purposes. GitHub has this [baseline file](https://github.com/istio/istio/blob/{{<branch_name>}}/mixer/test/perf/bench.baseline).
|
||||
|
||||
Due to the nature of this testing type, there is a high-variance in latency numbers across machines. It is recommended that micro-benchmark numbers captured in this way are compared only against the previous runs on the same machine.
|
||||
|
||||
The [perfcheck.sh](https://github.com/istio/istio/blob/master/bin/perfcheck.sh) script can be used to quickly run benchmarks in a sub-folder and compare its results against the co-located baseline files.
|
||||
The [perfcheck.sh](https://github.com/istio/istio/blob/{{<branch_name>}}/bin/perfcheck.sh) script can be used to quickly run benchmarks in a sub-folder and compare its results against the co-located baseline files.
|
||||
|
|
|
@ -11,6 +11,6 @@ weight: 25
|
|||
>}}
|
||||
|
||||
The synthetic benchmark scenarios and the source code of the tests are described
|
||||
on [GitHub](https://github.com/istio/istio/tree/master/tools#istio-load-testing-user-guide)
|
||||
on [GitHub](https://github.com/istio/istio/blob/{{<branch_name>}}/tools#istio-load-testing-user-guide)
|
||||
|
||||
<!-- add blueperf and more details -->
|
||||
|
|
|
@ -114,7 +114,7 @@ Part of the sidecar installation should involve setting up appropriate IP
|
|||
Table rules to transparently route application's network traffic through
|
||||
the Istio sidecars. The IP table script to setup such forwarding can be
|
||||
found in the
|
||||
[here](https://raw.githubusercontent.com/istio/istio/master/tools/deb/istio-iptables.sh).
|
||||
[here](https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/tools/deb/istio-iptables.sh).
|
||||
|
||||
> This script must be executed before starting the application or
|
||||
> the sidecar process.
|
||||
|
|
|
@ -46,7 +46,7 @@ For example, run the following command on a MacOS or Linux system:
|
|||
1. Bring up the Istio control plane containers:
|
||||
|
||||
```command
|
||||
$ docker-compose -f install/consul/istio.yaml up -d
|
||||
$ docker-compose -f @install/consul/istio.yaml@ up -d
|
||||
```
|
||||
|
||||
1. Confirm that all docker containers are running:
|
||||
|
@ -85,7 +85,7 @@ $ docker-compose -f <your-app-spec>.yaml up -d
|
|||
Uninstall Istio core components by removing the docker containers:
|
||||
|
||||
```command
|
||||
$ docker-compose -f install/consul/istio.yaml down
|
||||
$ docker-compose -f @install/consul/istio.yaml@ down
|
||||
```
|
||||
|
||||
## What's next
|
||||
|
|
|
@ -94,7 +94,7 @@ service mesh.
|
|||
Part of the sidecar installation should involve setting up appropriate IP
|
||||
Table rules to transparently route application's network traffic through
|
||||
the Istio sidecars. The IP table script to setup such forwarding can be
|
||||
found [here](https://raw.githubusercontent.com/istio/istio/master/tools/deb/istio-iptables.sh).
|
||||
found [here](https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/tools/deb/istio-iptables.sh).
|
||||
|
||||
> This script must be executed before starting the application or
|
||||
> the sidecar process.
|
||||
|
|
|
@ -40,7 +40,7 @@ For example, run the following command on a MacOS or Linux system:
|
|||
1. Bring up the Istio control plane containers:
|
||||
|
||||
```command
|
||||
$ docker-compose -f install/eureka/istio.yaml up -d
|
||||
$ docker-compose -f @install/eureka/istio.yaml@ up -d
|
||||
```
|
||||
|
||||
1. Confirm that all docker containers are running:
|
||||
|
@ -79,7 +79,7 @@ $ docker-compose -f <your-app-spec>.yaml up -d
|
|||
Uninstall Istio core components by removing the docker containers:
|
||||
|
||||
```command
|
||||
$ docker-compose -f install/eureka/istio.yaml down
|
||||
$ docker-compose -f @install/eureka/istio.yaml@ down
|
||||
```
|
||||
|
||||
## What's next
|
||||
|
|
|
@ -31,13 +31,13 @@ recommended.
|
|||
(requires Kubernetes >=1.9.0):
|
||||
|
||||
```command
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system > $HOME/istio.yaml
|
||||
$ helm template @install/kubernetes/helm/istio@ --name istio --namespace istio-system > $HOME/istio.yaml
|
||||
```
|
||||
|
||||
* Without the sidecar injection webhook:
|
||||
|
||||
```command
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml
|
||||
$ helm template @install/kubernetes/helm/istio@ --name istio --namespace istio-system --set sidecarInjectorWebhook.enabled=false > $HOME/istio.yaml
|
||||
```
|
||||
|
||||
1. Install the components via the manifest:
|
||||
|
@ -58,7 +58,7 @@ to manage the lifecycle of Istio.
|
|||
1. If a service account has not already been installed for Tiller, install one:
|
||||
|
||||
```command
|
||||
$ kubectl create -f install/kubernetes/helm/helm-service-account.yaml
|
||||
$ kubectl create -f @install/kubernetes/helm/helm-service-account.yaml@
|
||||
```
|
||||
|
||||
1. Install Tiller on your cluster with the service account:
|
||||
|
@ -72,13 +72,13 @@ to manage the lifecycle of Istio.
|
|||
* With [automatic sidecar injection](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection) (requires Kubernetes >=1.9.0):
|
||||
|
||||
```command
|
||||
$ helm install install/kubernetes/helm/istio --name istio --namespace istio-system
|
||||
$ helm install @install/kubernetes/helm/istio@ --name istio --namespace istio-system
|
||||
```
|
||||
|
||||
* Without the sidecar injection webhook:
|
||||
|
||||
```command
|
||||
$ helm install install/kubernetes/helm/istio --name istio --namespace istio-system --set sidecarInjectorWebhook.enabled=false
|
||||
$ helm install @install/kubernetes/helm/istio@ --name istio --namespace istio-system --set sidecarInjectorWebhook.enabled=false
|
||||
```
|
||||
|
||||
## Customization with Helm
|
||||
|
@ -109,7 +109,7 @@ following table:
|
|||
|
||||
The Helm chart also offers significant customization options per individual
|
||||
service. Customize these per-service options at your own risk. The per-service options are exposed via
|
||||
the [`values.yaml`](https://raw.githubusercontent.com/istio/istio/master/install/kubernetes/helm/istio/values.yaml) file.
|
||||
the [`values.yaml`](https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/install/kubernetes/helm/istio/values.yaml) file.
|
||||
|
||||
## What's next
|
||||
|
||||
|
|
|
@ -27,9 +27,9 @@ separate documents will cover these advanced configurations.
|
|||
Setup consists of preparing the mesh for expansion and installing and configuring each VM.
|
||||
|
||||
An example script to help with Kubernetes setup is available as part of the release bundle and in
|
||||
[install/tools/setupMeshEx.sh](https://raw.githubusercontent.com/istio/istio/master/install/tools/setupMeshEx.sh). Check the script content and environment variables supported (like GCP_OPTS).
|
||||
[install/tools/setupMeshEx.sh](https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/install/tools/setupMeshEx.sh). Check the script content and environment variables supported (like GCP_OPTS).
|
||||
|
||||
An example script to help configure a machine is available as part of the release bundle and in [install/tools/setupIstioVM.sh](https://raw.githubusercontent.com/istio/istio/master/install/tools/setupIstioVM.sh).
|
||||
An example script to help configure a machine is available as part of the release bundle and in [install/tools/setupIstioVM.sh](https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/install/tools/setupIstioVM.sh).
|
||||
You should customize it based on your provisioning tools and DNS requirements.
|
||||
|
||||
### Preparing the Kubernetes cluster for expansion
|
||||
|
@ -41,7 +41,7 @@ the cloud provider or private cloud (for example IBM Cloud Private) doesn't have
|
|||
support out of box.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/mesh-expansion.yaml
|
||||
$ kubectl apply -f @install/kubernetes/mesh-expansion.yaml@
|
||||
```
|
||||
|
||||
* Generate the Istio `cluster.env` configuration to be deployed in the VMs. This file contains
|
||||
|
@ -49,7 +49,7 @@ the cluster IP address ranges to intercept.
|
|||
|
||||
```command
|
||||
$ export GCP_OPTS="--zone MY_ZONE --project MY_PROJECT"
|
||||
$ install/tools/setupMeshEx.sh generateClusterEnv MY_CLUSTER_NAME
|
||||
$ @install/tools/setupMeshEx.sh@ generateClusterEnv MY_CLUSTER_NAME
|
||||
```
|
||||
|
||||
Here's an example generated file
|
||||
|
@ -63,7 +63,7 @@ the cluster IP address ranges to intercept.
|
|||
cluster service names, which will be intercepted by the sidecar and forwarded.
|
||||
|
||||
```command
|
||||
$ install/tools/setupMeshEx.sh generateDnsmasq
|
||||
$ @install/tools/setupMeshEx.sh@ generateDnsmasq
|
||||
```
|
||||
|
||||
Here's an example generated file
|
||||
|
@ -92,13 +92,13 @@ $ export SERVICE_NAMESPACE=vm
|
|||
If you are running on a GCE VM, run
|
||||
|
||||
```command
|
||||
$ install/tools/setupMeshEx.sh gceMachineSetup VM_NAME
|
||||
$ @install/tools/setupMeshEx.sh@ gceMachineSetup VM_NAME
|
||||
```
|
||||
|
||||
Otherwise, run
|
||||
|
||||
```command
|
||||
$ install/tools/setupMeshEx.sh machineSetup VM_NAME
|
||||
$ @install/tools/setupMeshEx.sh@ machineSetup VM_NAME
|
||||
```
|
||||
|
||||
GCE provides better user experience since node agent can always relies on
|
||||
|
@ -191,7 +191,7 @@ that will have mTLS enabled by default.
|
|||
On a Mac either `brew install base64` or `set BASE64_DECODE="/usr/bin/base64 -D"`
|
||||
|
||||
```command
|
||||
install/tools/setupMeshEx.sh machineCerts ACCOUNT NAMESPACE
|
||||
$ @install/tools/setupMeshEx.sh@ machineCerts ACCOUNT NAMESPACE
|
||||
```
|
||||
|
||||
The generated files (`key.pem`, `root-cert.pem`, `cert-chain.pem`) must be copied to /etc/certs on each machine, readable by istio-proxy.
|
||||
|
|
|
@ -159,7 +159,7 @@ $ export STATSD_POD_IP=$(kubectl -n istio-system get pod -l istio=statsd-prom-br
|
|||
install one:
|
||||
|
||||
```command
|
||||
$ kubectl create -f install/kubernetes/helm/helm-service-account.yaml
|
||||
$ kubectl create -f @install/kubernetes/helm/helm-service-account.yaml@
|
||||
```
|
||||
|
||||
1. Initialize Helm:
|
||||
|
|
|
@ -42,7 +42,7 @@ caption="GKE-IAM Role"
|
|||
|
||||
1. Once you have an account and project enabled, click the following link to open the Deployment Manager.
|
||||
|
||||
[Istio GKE Deployment Manager](https://accounts.google.com/signin/v2/identifier?service=cloudconsole&continue=https://console.cloud.google.com/launcher/config?templateurl=https://raw.githubusercontent.com/istio/istio/master/install/gcp/deployment_manager/istio-cluster.jinja&followup=https://console.cloud.google.com/launcher/config?templateurl=https://raw.githubusercontent.com/istio/istio/master/install/gcp/deployment_manager/istio-cluster.jinja&flowName=GlifWebSignIn&flowEntry=ServiceLogin)
|
||||
[Istio GKE Deployment Manager](https://accounts.google.com/signin/v2/identifier?service=cloudconsole&continue=https://console.cloud.google.com/launcher/config?templateurl=https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/install/gcp/deployment_manager/istio-cluster.jinja&followup=https://console.cloud.google.com/launcher/config?templateurl=https://raw.githubusercontent.com/istio/istio/master/install/gcp/deployment_manager/istio-cluster.jinja&flowName=GlifWebSignIn&flowEntry=ServiceLogin)
|
||||
|
||||
We recommend that you leave the default settings as the rest of this tutorial shows how to access the installed features. By default the tool creates a
|
||||
GKE alpha cluster with the specified settings, then installs the Istio [control plane](/docs/concepts/what-is-istio/overview/#architecture), the
|
||||
|
|
|
@ -257,7 +257,7 @@ Install Istio's core components. Choose one of the four _**mutually exclusive**_
|
|||
* Install Istio without enabling [mutual TLS authentication](/docs/concepts/security/mutual-tls/) between sidecars. Choose this option for clusters with existing applications, applications where services with an Istio sidecar need to be able to communicate with other non-Istio Kubernetes services, and applications that use [liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/), headless services, or StatefulSets.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-demo.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-demo.yaml@
|
||||
```
|
||||
|
||||
OR
|
||||
|
@ -265,7 +265,7 @@ OR
|
|||
* Install Istio and enforce mutual TLS authentication between sidecars by default. Use this option only on a fresh kubernetes cluster where newly deployed workloads are guaranteed to have Istio sidecars installed.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-demo-auth.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-demo-auth.yaml@
|
||||
```
|
||||
|
||||
OR
|
||||
|
@ -347,7 +347,7 @@ It is safe to ignore errors for non-existent resources because they may have bee
|
|||
If you installed Istio with `istio-demo.yaml`:
|
||||
|
||||
```command
|
||||
$ kubectl delete -f install/kubernetes/istio-demo.yaml
|
||||
$ kubectl delete -f @install/kubernetes/istio-demo.yaml@
|
||||
```
|
||||
|
||||
otherwise [uninstall Istio with Helm](/docs/setup/kubernetes/helm-install/#uninstall).
|
||||
|
|
|
@ -70,7 +70,7 @@ configuration from the `istio` ConfigMap. Additional parameter overrides
|
|||
are available via flags (see `istioctl kube-inject --help`).
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
|
||||
```
|
||||
|
||||
`kube-inject` can also be run without access to a running Kubernetes
|
||||
|
@ -93,7 +93,7 @@ Run `kube-inject` over the input file.
|
|||
$ istioctl kube-inject \
|
||||
--injectConfigFile inject-config.yaml \
|
||||
--meshConfigFile mesh-config.yaml \
|
||||
--filename samples/sleep/sleep.yaml \
|
||||
--filename @samples/sleep/sleep.yaml@ \
|
||||
--output sleep-injected.yaml
|
||||
```
|
||||
|
||||
|
@ -133,7 +133,7 @@ use [Helm](/docs/setup/kubernetes/helm-install/) to generate an updated istio.ya
|
|||
with the option `sidecarInjectorWebhook.enabled` set to `false`. E.g.
|
||||
|
||||
```command
|
||||
$ helm template --namespace=istio-system --set sidecarInjectorWebhook.enabled=false install/kubernetes/helm/istio > istio.yaml
|
||||
$ helm template --namespace=istio-system --set sidecarInjectorWebhook.enabled=false @install/kubernetes/helm/istio@ > istio.yaml
|
||||
$ kubectl create ns istio-system
|
||||
$ kubectl apply -n istio-system -f istio.yaml
|
||||
```
|
||||
|
@ -146,7 +146,7 @@ service in `values.yaml`. You can override the default values to customize the i
|
|||
Deploy sleep app. Verify both deployment and pod have a single container.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f samples/sleep/sleep.yaml
|
||||
$ kubectl apply -f @samples/sleep/sleep.yaml@
|
||||
$ kubectl get deployment -o wide
|
||||
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
|
||||
sleep 1 1 1 1 12m sleep tutum/curl app=sleep
|
||||
|
@ -304,12 +304,12 @@ containers:
|
|||
- sleep
|
||||
```
|
||||
|
||||
when applied over a pod defined by the pod template spec in [samples/sleep/sleep.yaml](https://raw.githubusercontent.com/istio/istio/master/samples/sleep/sleep.yaml).
|
||||
when applied over a pod defined by the pod template spec in [samples/sleep/sleep.yaml](https://raw.githubusercontent.com/istio/istio/{{<branch_name>}}/samples/sleep/sleep.yaml).
|
||||
|
||||
#### Uninstalling the webhook
|
||||
|
||||
```command
|
||||
$ kubectl delete -f install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml
|
||||
$ kubectl delete -f @install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml@
|
||||
```
|
||||
|
||||
The above command will not remove the injected sidecars from
|
||||
|
|
|
@ -21,16 +21,16 @@ First, generate the desired Istio control plane yaml file, e.g.
|
|||
|
||||
```command
|
||||
$ helm template --namespace istio-system --set global.proxy.image=proxy \
|
||||
--values install/kubernetes/helm/istio/values-istio.yaml \
|
||||
install/kubernetes/helm/istio >> install/kubernetes/istio.yaml
|
||||
--values @install/kubernetes/helm/istio/values-istio.yaml@ \
|
||||
@install/kubernetes/helm/istio@ >> install/kubernetes/istio.yaml
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```command
|
||||
$ helm template --namespace istio-system --set global.proxy.image=proxy \
|
||||
--values install/kubernetes/helm/istio/values-istio-auth.yaml \
|
||||
install/kubernetes/helm/istio >> install/kubernetes/istio-auth.yaml
|
||||
--values @install/kubernetes/helm/istio/values-istio-auth.yaml@ \
|
||||
@install/kubernetes/helm/istio@ >> install/kubernetes/istio-auth.yaml
|
||||
```
|
||||
|
||||
If using Kubernetes versions prior to 1.9, you should add `--set sidecarInjectorWebhook.enabled=false`.
|
||||
|
@ -38,13 +38,13 @@ If using Kubernetes versions prior to 1.9, you should add `--set sidecarInjector
|
|||
Second, simply apply the new version of the desired Istio control plane yaml file directly, e.g.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio.yaml@
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-auth.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-auth.yaml@
|
||||
```
|
||||
|
||||
The rolling update process will upgrade all deployments and configmaps to the new version. After this process finishes,
|
||||
|
|
|
@ -21,8 +21,8 @@ service.
|
|||
user to v3.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/route-rule-reviews-test-v2.yaml
|
||||
$ istioctl create -f samples/bookinfo/kube/route-rule-reviews-v3.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-reviews-test-v2.yaml@
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-reviews-v3.yaml@
|
||||
```
|
||||
|
||||
> If you have a conflicting rule that you set in previous tasks,
|
||||
|
@ -50,13 +50,9 @@ Consider `ratings` as an external paid service like Rotten Tomatoes® with
|
|||
enable rate limiting.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml@
|
||||
```
|
||||
|
||||
The file looks like:
|
||||
|
||||
{{< file_content url="https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml" lang="yaml" >}}
|
||||
|
||||
1. Confirm the `memquota` was created:
|
||||
|
||||
```command-output-as-yaml
|
||||
|
@ -251,14 +247,14 @@ with the given namespace.
|
|||
* Remove the rate limit configuration:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/mixer-rule-ratings-ratelimit.yaml@
|
||||
```
|
||||
|
||||
* Remove the application routing rules:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/route-rule-reviews-test-v2.yaml
|
||||
$ istioctl delete -f samples/bookinfo/kube/route-rule-reviews-v3.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/route-rule-reviews-test-v2.yaml@
|
||||
$ istioctl delete -f @samples/bookinfo/kube/route-rule-reviews-v3.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -18,17 +18,17 @@ Through this task, you will learn how to:
|
|||
|
||||
* Have a Kubernetes cluster with Istio installed, without global mutual TLS enabled (e.g use `install/kubernetes/istio-demo.yaml` as described in [installation steps](/docs/setup/kubernetes/quick-start/#installation-steps), or set `global.mtls.enabled` to false using [Helm](/docs/setup/kubernetes/helm-install/)).
|
||||
|
||||
* For demo, create two namespaces `foo` and `bar`, and deploy [httpbin](https://github.com/istio/istio/tree/master/samples/httpbin) and [sleep](https://github.com/istio/istio/tree/master/samples/sleep) with sidecar on both of them. Also, run another sleep app without sidecar (to keep it separate, run it in `legacy` namespace)
|
||||
* For demo, create two namespaces `foo` and `bar`, and deploy [httpbin](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/httpbin) and [sleep](https://github.com/istio/istio/tree/master/samples/sleep) with sidecar on both of them. Also, run another sleep app without sidecar (to keep it separate, run it in `legacy` namespace)
|
||||
|
||||
```command
|
||||
$ kubectl create ns foo
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n foo
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n foo
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n foo
|
||||
$ kubectl create ns bar
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml) -n bar
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml) -n bar
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n bar
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n bar
|
||||
$ kubectl create ns legacy
|
||||
$ kubectl apply -f samples/sleep/sleep.yaml -n legacy
|
||||
$ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy
|
||||
```
|
||||
|
||||
* Verifying setup by sending an http request (using curl command) from any sleep pod (among those in namespace `foo`, `bar` or `legacy`) to either `httpbin.foo` or `httpbin.bar`. All requests should success with HTTP code 200.
|
||||
|
@ -250,7 +250,7 @@ $ kubectl exec $(kubectl get pod -l app=sleep -n legacy -o jsonpath={.items..met
|
|||
|
||||
## Setup end-user authentication
|
||||
|
||||
You will need a valid JWT (corresponding to the JWKS endpoint you want to use for the demo). Please follow the instructions [here](https://github.com/istio/istio/tree/master/security/tools/jwt) to create one. You can also use your own JWT/JWKS endpoint for the demo. Once you have that, export to some environment variables.
|
||||
You will need a valid JWT (corresponding to the JWKS endpoint you want to use for the demo). Please follow the instructions [here](https://github.com/istio/istio/blob/{{<branch_name>}}/security/tools/jwt) to create one. You can also use your own JWT/JWKS endpoint for the demo. Once you have that, export to some environment variables.
|
||||
|
||||
```command
|
||||
$ export SVC_ACCOUNT="example@my-project.iam.gserviceaccount.com"
|
||||
|
|
|
@ -19,8 +19,8 @@ This task shows how to control access to a service using the Kubernetes labels.
|
|||
test user "jason" to version v2 and requests from any other user to v3.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/route-rule-reviews-test-v2.yaml
|
||||
$ istioctl create -f samples/bookinfo/kube/route-rule-reviews-v3.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-reviews-test-v2.yaml@
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-reviews-v3.yaml@
|
||||
```
|
||||
|
||||
> If you have conflicting rules that you set in previous tasks,
|
||||
|
@ -50,7 +50,7 @@ of the `reviews` service. We would like to cut off access to version `v3` of the
|
|||
Run the following command to set up the deny rule along with a handler and an instance.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/mixer-rule-deny-label.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/mixer-rule-deny-label.yaml@
|
||||
Created config denier/default/denyreviewsv3handler at revision 2882105
|
||||
Created config checknothing/default/denyreviewsv3request at revision 2882106
|
||||
Created config rule/default/denyreviewsv3 at revision 2882107
|
||||
|
@ -84,7 +84,7 @@ Istio also supports attribute-based whitelists and blacklists. The following whi
|
|||
1. Remove the denier configuration that you added in the previous section.
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/mixer-rule-deny-label.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/mixer-rule-deny-label.yaml@
|
||||
```
|
||||
|
||||
1. Verify that when you access the Bookinfo `productpage` (http://$GATEWAY_URL/productpage) without logging in, you see red stars.
|
||||
|
@ -168,8 +168,8 @@ Verify that after logging in as "jason" you see black stars.
|
|||
* Remove the application routing rules:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/route-rule-reviews-test-v2.yaml
|
||||
$ istioctl delete -f samples/bookinfo/kube/route-rule-reviews-v3.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/route-rule-reviews-test-v2.yaml@
|
||||
$ istioctl delete -f @samples/bookinfo/kube/route-rule-reviews-v3.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -35,7 +35,7 @@ this feature is not needed if the production setup is not using the
|
|||
Deploy Citadel with health checking enabled.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-citadel-with-health-check.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-citadel-with-health-check.yaml@
|
||||
```
|
||||
|
||||
Deploy the `istio-citadel` service so that the CSR service can be found by the health checker.
|
||||
|
@ -123,14 +123,14 @@ continuously failed health checks.
|
|||
* To disable health checking on Citadel:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-auth.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-auth.yaml@
|
||||
$ kubectl delete svc istio-citadel -n istio-system
|
||||
```
|
||||
|
||||
* To remove Citadel:
|
||||
|
||||
```command
|
||||
$ kubectl delete -f install/kubernetes/istio-citadel-with-health-check.yaml
|
||||
$ kubectl delete -f @install/kubernetes/istio-citadel-with-health-check.yaml@
|
||||
$ kubectl delete svc istio-citadel -n istio-system
|
||||
```
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ $ configmap "nginxconfigmap" created
|
|||
This section creates a NGINX-based HTTPS service.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f samples/https/nginx-app.yaml
|
||||
$ kubectl apply -f @samples/https/nginx-app.yaml@
|
||||
service "my-nginx" created
|
||||
replicationcontroller "my-nginx" created
|
||||
```
|
||||
|
@ -50,7 +50,7 @@ replicationcontroller "my-nginx" created
|
|||
Then, create another pod to call this service.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f samples/sleep/sleep.yaml)
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f @samples/sleep/sleep.yaml@)
|
||||
```
|
||||
|
||||
Get the pods
|
||||
|
@ -100,7 +100,7 @@ $ kubectl delete -f nginx-app.yaml
|
|||
Deploy it with a sidecar
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f samples/https/nginx-app.yaml)
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f @samples/https/nginx-app.yaml@)
|
||||
```
|
||||
|
||||
Make sure the pod is up and running
|
||||
|
@ -138,7 +138,7 @@ You need to deploy Istio control plane with mTLS enabled. If you have istio
|
|||
control plane with mTLS disabled installed, please delete it:
|
||||
|
||||
```command
|
||||
$ kubectl delete -f install/kubernetes/istio.yaml
|
||||
$ kubectl delete -f @install/kubernetes/istio.yaml@
|
||||
```
|
||||
|
||||
And wait for everything is down, i.e., there is no pod in control plane namespace (istio-system).
|
||||
|
@ -151,7 +151,7 @@ No resources found.
|
|||
Then deploy the Istio control plane with mTLS enabled:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-auth.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-auth.yaml@
|
||||
```
|
||||
|
||||
Make sure everything is up and running:
|
||||
|
@ -168,10 +168,10 @@ istio-pilot-6954dcd96d-phh5z 2/2 Running 0 2m
|
|||
Then redeploy the HTTPS service and sleep service
|
||||
|
||||
```command
|
||||
$ kubectl delete -f <(bin/istioctl kube-inject --debug -f samples/sleep/sleep.yaml)
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f samples/sleep/sleep.yaml)
|
||||
$ kubectl delete -f <(bin/istioctl kube-inject --debug -f samples/https/nginx-app.yaml)
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f samples/https/nginx-app.yaml)
|
||||
$ kubectl delete -f <(bin/istioctl kube-inject --debug -f @samples/sleep/sleep.yaml@)
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f @samples/sleep/sleep.yaml@)
|
||||
$ kubectl delete -f <(bin/istioctl kube-inject --debug -f @samples/https/nginx-app.yaml@)
|
||||
$ kubectl apply -f <(bin/istioctl kube-inject --debug -f @samples/https/nginx-app.yaml@)
|
||||
```
|
||||
|
||||
Make sure the pod is up and running
|
||||
|
|
|
@ -17,18 +17,18 @@ This task assumes you have a Kubernetes cluster:
|
|||
* Installed Istio with global mTLS enabled:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-auth.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-auth.yaml@
|
||||
```
|
||||
_**OR**_
|
||||
Using [Helm](/docs/setup/kubernetes/helm-install/) with `global.mtls.enabled` to `true`.
|
||||
|
||||
> Starting with Istio 0.7, you can use [authentication policy](/docs/concepts/security/authn-policy/) to config mTLS for all/selected services in a namespace (repeated for all namespaces to get global setting). See [authentication policy task](/docs/tasks/security/authn-policy/)
|
||||
|
||||
* For demo, deploy [httpbin](https://github.com/istio/istio/tree/master/samples/httpbin) and [sleep](https://github.com/istio/istio/tree/master/samples/sleep) with Envoy sidecar. For simplicity, the demo is setup in the `default` namespace. If you wish to use a different namespace, please add `-n yournamespace` appropriately to the example commands in the next section.
|
||||
* For demo, deploy [httpbin](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/httpbin) and [sleep](https://github.com/istio/istio/tree/master/samples/sleep) with Envoy sidecar. For simplicity, the demo is setup in the `default` namespace. If you wish to use a different namespace, please add `-n yournamespace` appropriately to the example commands in the next section.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml --debug)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml --debug)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@ --debug)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@ --debug)
|
||||
```
|
||||
> Use `--debug` to inject the sidecar container with proxy-debug image, which is needed to run `curl` command from istio-proxy container later in the demo.
|
||||
|
||||
|
@ -139,7 +139,7 @@ Assuming mutual TLS authentication is properly turned on, it should not affect c
|
|||
|
||||
```command
|
||||
$ kubectl create ns legacy
|
||||
$ kubectl apply -f samples/sleep/sleep.yaml -n legacy
|
||||
$ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy
|
||||
```
|
||||
|
||||
1. Wait after the pod status changes to `Running`, issue the familiar `curl` command. The request should fail as the pod doesn't have a sidecar to help initiate TLS communication.
|
||||
|
|
|
@ -46,7 +46,7 @@ The following steps enable plugging in the certificates and key into Citadel:
|
|||
1. Redeploy Citadel, which reads the certificates and key from the secret-mount files:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/istio-citadel-plugin-certs.yaml
|
||||
$ kubectl apply -f @install/kubernetes/istio-citadel-plugin-certs.yaml@
|
||||
```
|
||||
|
||||
> Note: if you are using different certificate/key file or secret names,
|
||||
|
@ -93,9 +93,9 @@ This requires you have `openssl` installed on your machine.
|
|||
1. Verify the root certificate is the same as the one specified by operator:
|
||||
|
||||
```command
|
||||
openssl x509 -in samples/certs/root-cert.pem -text -noout > /tmp/root-cert.crt.txt
|
||||
openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt
|
||||
diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
|
||||
$ openssl x509 -in @samples/certs/root-cert.pem@ -text -noout > /tmp/root-cert.crt.txt
|
||||
$ openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt
|
||||
$ diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt
|
||||
```
|
||||
|
||||
Expect the output to be empty.
|
||||
|
@ -104,7 +104,7 @@ This requires you have `openssl` installed on your machine.
|
|||
|
||||
```command
|
||||
$ tail -n 22 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem
|
||||
$ openssl x509 -in samples/certs/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt
|
||||
$ openssl x509 -in @samples/certs/ca-cert.pem@ -text -noout > /tmp/ca-cert.crt.txt
|
||||
$ openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt
|
||||
$ diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt
|
||||
```
|
||||
|
@ -115,12 +115,7 @@ This requires you have `openssl` installed on your machine.
|
|||
|
||||
```command
|
||||
$ head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem
|
||||
$ openssl verify -CAfile <(cat samples/certs/ca-cert.pem samples/certs/root-cert.pem) /tmp/pod-cert-chain-workload.pem
|
||||
```
|
||||
|
||||
Expect the following output:
|
||||
|
||||
```command
|
||||
$ openssl verify -CAfile <(cat @samples/certs/ca-cert.pem@ @samples/certs/root-cert.pem@) /tmp/pod-cert-chain-workload.pem
|
||||
/tmp/pod-cert-chain-workload.pem: OK
|
||||
```
|
||||
|
||||
|
@ -135,10 +130,10 @@ This requires you have `openssl` installed on your machine.
|
|||
* To remove the Istio components:
|
||||
|
||||
```command
|
||||
$ kubectl delete -f install/kubernetes/istio-auth.yaml
|
||||
$ kubectl delete -f @install/kubernetes/istio-auth.yaml@
|
||||
```
|
||||
|
||||
## What's next
|
||||
|
||||
* Read more about [Citadel (codename is istio\_ca) arguments](/docs/reference/commands/istio_ca/).
|
||||
* Read [how the sample certificates and keys are generated](https://github.com/istio/istio/blob/master/security/samples/plugin_ca_certs).
|
||||
* Read [how the sample certificates and keys are generated](https://github.com/istio/istio/blob/{{<branch_name>}}/security/samples/plugin_ca_certs).
|
||||
|
|
|
@ -17,7 +17,7 @@ RBAC from [Istio RBAC concept page](/docs/concepts/security/rbac/).
|
|||
* Deploy the [Bookinfo](/docs/guides/bookinfo/) sample application.
|
||||
|
||||
> The current Istio release may not have the up-to-date Istio RBAC samples. So before you continue, you
|
||||
need to copy the following configuration files from <https://github.com/istio/istio/tree/master/samples/bookinfo/kube> to
|
||||
need to copy these [configuration files](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/bookinfo/kube) to
|
||||
`samples/bookinfo/kube` directory under where you installed Istio, and replace the original ones. The files include
|
||||
`bookinfo-add-serviceaccount.yaml`, `istio-rbac-enable.yaml`, `istio-rbac-namespace.yaml`, `istio-rbac-productpage.yaml`,
|
||||
`istio-rbac-details-reviews.yaml`, `istio-rbac-ratings.yaml`.
|
||||
|
@ -32,7 +32,7 @@ microservices running under them.
|
|||
with the service account.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-add-serviceaccount.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-add-serviceaccount.yaml@)
|
||||
serviceaccount "bookinfo-productpage" created
|
||||
deployment "productpage-v1" configured
|
||||
serviceaccount "bookinfo-reviews" created
|
||||
|
@ -55,13 +55,13 @@ and specify the namespace, say `"your-namespace"`, in the `match` statement in `
|
|||
`"match: destination.namespace == "your-namespace"`.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/istio-rbac-enable.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/istio-rbac-enable.yaml@
|
||||
```
|
||||
|
||||
> If you have conflicting rules that you set in previous tasks, use `istioctl replace` instead of `istioctl create`.
|
||||
|
||||
It also defines "requestcontext", which is an instance of the
|
||||
[authorization template](https://github.com/istio/istio/blob/master/mixer/template/authorization/template.proto).
|
||||
[authorization template](/docs/reference/config/policy-and-telemetry/templates/authorization/).
|
||||
"requestcontext" defines the input to the RBAC engine at runtime.
|
||||
|
||||
Point your browser at the Bookinfo `productpage` (http://$GATEWAY_URL/productpage). Now you should see
|
||||
|
@ -81,8 +81,9 @@ any service in "default" namespace that has "app" label set to one of the values
|
|||
is accessible by services in the same namespace (i.e., "default" namespace) and services in "istio-system" namespace.
|
||||
|
||||
Run the following command to create a namespace-level access control policy.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/istio-rbac-namespace.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/istio-rbac-namespace.yaml@
|
||||
```
|
||||
|
||||
The policy does the following:
|
||||
|
@ -142,7 +143,7 @@ with "Book Details" section in the lower left part and "Book Reviews" section in
|
|||
Remove the following configuration before you proceed to the next task:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/istio-rbac-namespace.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/istio-rbac-namespace.yaml@
|
||||
```
|
||||
|
||||
## Service-level access control
|
||||
|
@ -160,8 +161,9 @@ access to the services in Bookinfo sample.
|
|||
In this step, we will create a policy that allows external requests to view `productpage` service via Ingress.
|
||||
|
||||
Run the following command:
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/istio-rbac-productpage.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/istio-rbac-productpage.yaml@
|
||||
```
|
||||
|
||||
The policy does the following:
|
||||
|
@ -212,7 +214,7 @@ We will create a policy to allow "productpage" service to read "details" and "re
|
|||
Run the following command:
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/istio-rbac-details-reviews.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/istio-rbac-details-reviews.yaml@
|
||||
```
|
||||
|
||||
The policy does the following:
|
||||
|
@ -265,7 +267,7 @@ We will create a policy to allow "reviews" service to read "ratings" service. No
|
|||
Run the following command to create a policy that allows "reviews" service to read "ratings" service.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/istio-rbac-ratings.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/istio-rbac-ratings.yaml@
|
||||
```
|
||||
|
||||
The policy does the following:
|
||||
|
@ -330,9 +332,9 @@ spec:
|
|||
* Remove Istio RBAC policy configuration:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/istio-rbac-ratings.yaml
|
||||
$ istioctl delete -f samples/bookinfo/kube/istio-rbac-details-reviews.yaml
|
||||
$ istioctl delete -f samples/bookinfo/kube/istio-rbac-productpage.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/istio-rbac-ratings.yaml@
|
||||
$ istioctl delete -f @samples/bookinfo/kube/istio-rbac-details-reviews.yaml@
|
||||
$ istioctl delete -f @samples/bookinfo/kube/istio-rbac-productpage.yaml@
|
||||
```
|
||||
|
||||
Alternatively, you can delete all `ServiceRole` and `ServiceRoleBinding` resources by running the following commands:
|
||||
|
@ -345,7 +347,7 @@ spec:
|
|||
* Disable Istio RBAC:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/istio-rbac-enable.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/istio-rbac-enable.yaml@
|
||||
```
|
||||
|
||||
## What's next
|
||||
|
|
|
@ -25,7 +25,7 @@ For the format of the service account in Istio, please refer to the
|
|||
and redeploy the service `productpage` with the service account.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-add-serviceaccount.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-add-serviceaccount.yaml@)
|
||||
serviceaccount "bookinfo-productpage" created
|
||||
deployment "productpage-v1" configured
|
||||
```
|
||||
|
@ -48,7 +48,7 @@ the `productpage` service.
|
|||
|
||||
Run the following command to set up the deny rule along with a handler and an instance.
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/mixer-rule-deny-serviceaccount.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/mixer-rule-deny-serviceaccount.yaml@
|
||||
Created config denier/default/denyproductpagehandler at revision 2877836
|
||||
Created config checknothing/default/denyproductpagerequest at revision 2877837
|
||||
Created config rule/default/denyproductpage at revision 2877838
|
||||
|
@ -80,7 +80,7 @@ the `productpage` service.
|
|||
* Remove the mixer configuration:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/kube/mixer-rule-deny-serviceaccount.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/kube/mixer-rule-deny-serviceaccount.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -24,7 +24,7 @@ the example application throughout this task.
|
|||
In Kubernetes environments, execute the following command:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/addons/servicegraph.yaml
|
||||
$ kubectl apply -f @install/kubernetes/addons/servicegraph.yaml@
|
||||
```
|
||||
|
||||
1. Verify that the service is running in your cluster.
|
||||
|
@ -88,7 +88,7 @@ the example application throughout this task.
|
|||
|
||||
### About the Servicegraph add-on
|
||||
|
||||
The [Servicegraph](https://github.com/istio/istio/tree/master/addons/servicegraph)
|
||||
The [Servicegraph](https://github.com/istio/istio/tree/{{<branch_name>}}/addons/servicegraph)
|
||||
service provides endpoints for generating and visualizing a graph of
|
||||
services within a mesh. It exposes the following endpoints:
|
||||
|
||||
|
@ -117,7 +117,7 @@ depends on the standard Istio metric configuration.
|
|||
Servicegraph add-on:
|
||||
|
||||
```command
|
||||
$ kubectl delete -f install/kubernetes/addons/servicegraph.yaml
|
||||
$ kubectl delete -f @install/kubernetes/addons/servicegraph.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -115,13 +115,13 @@ will generate and collect automatically.
|
|||
simply deploy the services using `kubectl`:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f samples/bookinfo/kube/bookinfo-ratings-v2.yaml
|
||||
$ kubectl apply -f @samples/bookinfo/kube/bookinfo-ratings-v2.yaml@
|
||||
```
|
||||
|
||||
If you are using manual sidecar injection, use the following command instead:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-ratings-v2.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-ratings-v2.yaml@)
|
||||
deployment "ratings-v2" configured
|
||||
```
|
||||
|
||||
|
@ -131,13 +131,13 @@ will generate and collect automatically.
|
|||
simply deploy the services using `kubectl`:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f samples/bookinfo/kube/bookinfo-db.yaml
|
||||
$ kubectl apply -f @samples/bookinfo/kube/bookinfo-db.yaml@
|
||||
```
|
||||
|
||||
If you are using manual sidecar injection, use the following command instead:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/bookinfo/kube/bookinfo-db.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/kube/bookinfo-db.yaml@)
|
||||
service "mongodb" configured
|
||||
deployment "mongodb-v1" configured
|
||||
```
|
||||
|
@ -145,7 +145,7 @@ will generate and collect automatically.
|
|||
1. Add routing rules to send traffic to `v2` of the `ratings` service:
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/kube/route-rule-ratings-db.yaml
|
||||
$ istioctl create -f @samples/bookinfo/kube/route-rule-ratings-db.yaml@
|
||||
Created config route-rule//ratings-test-v2 at revision 7216403
|
||||
Created config route-rule//reviews-test-ratings-v2 at revision 7216404
|
||||
```
|
||||
|
|
|
@ -24,7 +24,7 @@ the example application throughout this task.
|
|||
In Kubernetes environments, execute the following command:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f install/kubernetes/addons/grafana.yaml
|
||||
$ kubectl apply -f @install/kubernetes/addons/grafana.yaml@
|
||||
```
|
||||
|
||||
1. Verify that the service is running in your cluster.
|
||||
|
@ -103,7 +103,7 @@ For more on how to create, configure, and edit dashboards, please see the
|
|||
add-on:
|
||||
|
||||
```command
|
||||
$ kubectl delete -f install/kubernetes/addons/grafana.yaml
|
||||
$ kubectl delete -f @install/kubernetes/addons/grafana.yaml@
|
||||
```
|
||||
|
||||
* Remove any `kubectl port-forward` processes that may be running:
|
||||
|
|
|
@ -13,11 +13,11 @@ This task demonstrates the circuit-breaking capability for resilient application
|
|||
* Setup Istio by following the instructions in the
|
||||
[Installation guide](/docs/setup/).
|
||||
|
||||
* Start the [httpbin](https://github.com/istio/istio/tree/master/samples/httpbin) sample
|
||||
* Start the [httpbin](https://github.com/istio/istio/tree/{{<branch_name>}}/samples/httpbin) sample
|
||||
which will be used as the backend service for our task
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject --debug -f samples/httpbin/httpbin.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject --debug -f @samples/httpbin/httpbin.yaml@)
|
||||
```
|
||||
|
||||
## Circuit breaker
|
||||
|
@ -81,7 +81,7 @@ Let's set up a scenario to demonstrate the circuit-breaking capabilities of Isti
|
|||
Now that we've set up rules for calling the `httpbin` service, let's create a client we can use to send traffic to our service and see whether we can trip the circuit breaking policies. We're going to use a simple load-testing client called [fortio](https://github.com/istio/fortio). With this client we can control the number of connections, concurrency, and delays of outgoing HTTP calls. In this step, we'll set up a client that is injected with the istio sidecar proxy so our network interactions are governed by Istio:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject --debug -f samples/httpbin/sample-client/fortio-deploy.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject --debug -f @samples/httpbin/sample-client/fortio-deploy.yaml@)
|
||||
```
|
||||
|
||||
Now we should be able to log into that client pod and use the simple fortio tool to call `httpbin`. We'll pass in `-curl` to indicate we just want to make one call:
|
||||
|
@ -227,7 +227,7 @@ We see `12` for the `upstream_rq_pending_overflow` value which means `12` calls
|
|||
$ istioctl delete destinationrule httpbin
|
||||
```
|
||||
|
||||
1. Shutdown the [httpbin](https://github.com/istio/istio/tree/master/samples/httpbin) service and client.
|
||||
1. Shutdown the [httpbin](https://github.com/istio/istio/tree/{{<branch_name>}}/samples/httpbin) service and client.
|
||||
|
||||
```command
|
||||
$ kubectl delete deploy httpbin fortio-deploy
|
||||
|
|
|
@ -15,10 +15,10 @@ This task describes how to configure Istio to expose external TCP services to ap
|
|||
* Setup Istio by following the instructions in the
|
||||
[Installation guide](/docs/setup/).
|
||||
|
||||
* Start the [sleep](https://github.com/istio/istio/tree/master/samples/sleep) sample application which will be used as a test source for external calls.
|
||||
* Start the [sleep](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/sleep) sample application which will be used as a test source for external calls.
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
|
||||
```
|
||||
|
||||
**Note**: any pod that you can execute `curl` from is good enough.
|
||||
|
@ -62,7 +62,7 @@ This command instructs the Istio proxy to forward requests on port 443 of any of
|
|||
|
||||
## Access wikipedia.org by HTTPS
|
||||
|
||||
1. `kubectl exec` into the pod to be used as the test source. If you are using the [sleep](https://github.com/istio/istio/tree/master/samples/sleep) application, run the following command:
|
||||
1. `kubectl exec` into the pod to be used as the test source. If you are using the [sleep](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/sleep) application, run the following command:
|
||||
|
||||
```command
|
||||
$ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep bash
|
||||
|
@ -94,10 +94,10 @@ This command instructs the Istio proxy to forward requests on port 443 of any of
|
|||
$ istioctl delete serviceentry wikipedia-ext
|
||||
```
|
||||
|
||||
1. Shutdown the [sleep](https://github.com/istio/istio/tree/master/samples/sleep) application.
|
||||
1. Shutdown the [sleep](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/sleep) application.
|
||||
|
||||
```command
|
||||
$ kubectl delete -f samples/sleep/sleep.yaml
|
||||
$ kubectl delete -f @samples/sleep/sleep.yaml@
|
||||
```
|
||||
|
||||
## What's next
|
||||
|
|
|
@ -22,18 +22,18 @@ or alternatively, to simply bypass the Istio proxy for a specific range of IPs.
|
|||
* Setup Istio by following the instructions in the
|
||||
[Installation guide](/docs/setup/).
|
||||
|
||||
* Start the [sleep](https://github.com/istio/istio/tree/master/samples/sleep) sample
|
||||
* Start the [sleep](https://github.com/istio/istio/tree/{{<branch_name>}}/samples/sleep) sample
|
||||
which will be used as a test source for external calls.
|
||||
|
||||
If you have enabled [automatic sidecar injection](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection), do
|
||||
|
||||
```command
|
||||
$ kubectl apply -f samples/sleep/sleep.yaml
|
||||
$ kubectl apply -f @samples/sleep/sleep.yaml@
|
||||
```
|
||||
otherwise, you have to manually inject the sidecar before deploying the `sleep` application:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/sleep/sleep.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@)
|
||||
```
|
||||
|
||||
Note that any pod that you can `exec` and `curl` from would do.
|
||||
|
@ -265,16 +265,16 @@ cloud provider specific knowledge and configuration.
|
|||
$ istioctl delete virtualservice httpbin-ext
|
||||
```
|
||||
|
||||
1. Shutdown the [sleep](https://github.com/istio/istio/tree/master/samples/sleep) service.
|
||||
1. Shutdown the [sleep](https://github.com/istio/istio/tree/{{<branch_name>}}/samples/sleep) service.
|
||||
|
||||
```command
|
||||
$ kubectl delete -f samples/sleep/sleep.yaml
|
||||
$ kubectl delete -f @samples/sleep/sleep.yaml@
|
||||
```
|
||||
|
||||
1. Update the `ConfigMap` _istio-sidecar-injector_ to redirect all outbound traffic to the sidecar proxies:
|
||||
|
||||
```plain
|
||||
$ helm template install/kubernetes/helm/istio <the flags you used to install Istio> -x templates/sidecar-injector-configmap.yaml | kubectl apply -f -
|
||||
$ helm template install/kubernetes/helm/istio <the flags you used to install Istio> -x @templates/sidecar-injector-configmap.yaml@ | kubectl apply -f -
|
||||
```
|
||||
## What's next
|
||||
|
||||
|
|
|
@ -22,8 +22,8 @@ This task shows how to inject delays and test the resiliency of your application
|
|||
commands:
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl replace -f samples/bookinfo/routing/route-rule-reviews-test-v2.yaml
|
||||
$ istioctl create -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
$ istioctl replace -f @samples/bookinfo/routing/route-rule-reviews-test-v2.yaml@
|
||||
```
|
||||
|
||||
# Fault injection
|
||||
|
@ -38,7 +38,7 @@ continue without any errors.
|
|||
1. Create a fault injection rule to delay traffic coming from user "jason" (our test user)
|
||||
|
||||
```command
|
||||
$ istioctl replace -f samples/bookinfo/routing/route-rule-ratings-test-delay.yaml
|
||||
$ istioctl replace -f @samples/bookinfo/routing/route-rule-ratings-test-delay.yaml@
|
||||
```
|
||||
|
||||
Confirm the rule is created:
|
||||
|
@ -118,7 +118,7 @@ message.
|
|||
1. Create a fault injection rule to send an HTTP abort for user "jason"
|
||||
|
||||
```command
|
||||
$ istioctl replace -f samples/bookinfo/routing/route-rule-ratings-test-abort.yaml
|
||||
$ istioctl replace -f @samples/bookinfo/routing/route-rule-ratings-test-abort.yaml@
|
||||
```
|
||||
|
||||
Confirm the rule is created
|
||||
|
@ -163,7 +163,7 @@ message.
|
|||
* Remove the application routing rules:
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -22,18 +22,18 @@ This task describes how to configure Istio to expose a service outside of the se
|
|||
|
||||
* Make sure your current directory is the `istio` directory.
|
||||
|
||||
* Start the [httpbin](https://github.com/istio/istio/tree/master/samples/httpbin) sample,
|
||||
* Start the [httpbin](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/httpbin) sample,
|
||||
which will be used as the destination service to be exposed externally.
|
||||
|
||||
If you have enabled [automatic sidecar injection](/docs/setup/kubernetes/sidecar-injection/#automatic-sidecar-injection), do
|
||||
|
||||
```command
|
||||
$ kubectl apply -f samples/httpbin/httpbin.yaml
|
||||
$ kubectl apply -f @samples/httpbin/httpbin.yaml@
|
||||
```
|
||||
otherwise, you have to manually inject the sidecar before deploying the `httpbin` application:
|
||||
|
||||
```command
|
||||
$ kubectl apply -f <(istioctl kube-inject -f samples/httpbin/httpbin.yaml)
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@)
|
||||
```
|
||||
|
||||
* A private key and certificate can be created for testing using [OpenSSL](https://www.openssl.org/).
|
||||
|
@ -330,13 +330,13 @@ external traffic.
|
|||
|
||||
## Cleanup
|
||||
|
||||
Delete the `Gateway` configuration, the `VirtualService` and the secret, and shutdown the [httpbin](https://github.com/istio/istio/tree/master/samples/httpbin) service:
|
||||
Delete the `Gateway` configuration, the `VirtualService` and the secret, and shutdown the [httpbin](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/httpbin) service:
|
||||
|
||||
```command
|
||||
$ istioctl delete gateway httpbin-gateway
|
||||
$ istioctl delete virtualservice httpbin
|
||||
$ kubectl delete --ignore-not-found=true -n istio-system secret istio-ingressgateway-certs
|
||||
$ kubectl delete --ignore-not-found=true -f samples/httpbin/httpbin.yaml
|
||||
$ kubectl delete --ignore-not-found=true -f @samples/httpbin/httpbin.yaml@
|
||||
```
|
||||
|
||||
## What's next
|
||||
|
|
|
@ -237,7 +237,7 @@ Let's set up a scenario to demonstrate the traffic-mirroring capabilities of Ist
|
|||
$ istioctl delete destinationrule httpbin
|
||||
```
|
||||
|
||||
1. Shutdown the [httpbin](https://github.com/istio/istio/tree/master/samples/httpbin) service and client.
|
||||
1. Shutdown the [httpbin](https://github.com/istio/istio/tree/{{<branch_name>}}/samples/httpbin) service and client.
|
||||
|
||||
```command
|
||||
$ kubectl delete deploy httpbin-v1 httpbin-v2 sleep
|
||||
|
|
|
@ -32,7 +32,7 @@ you'll need to use `replace` rather than `create` in the following command.
|
|||
1. Set the default version for all microservices to v1.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl create -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
```
|
||||
|
||||
> In a Kubernetes deployment of Istio, you can replace `istioctl`
|
||||
|
@ -122,7 +122,7 @@ you'll need to use `replace` rather than `create` in the following command.
|
|||
`reviews:v2` instances.
|
||||
|
||||
```command
|
||||
$ istioctl replace -f samples/bookinfo/routing/route-rule-reviews-test-v2.yaml
|
||||
$ istioctl replace -f @samples/bookinfo/routing/route-rule-reviews-test-v2.yaml@
|
||||
```
|
||||
|
||||
Confirm the rule is created:
|
||||
|
@ -171,7 +171,7 @@ all users to v2, optionally in a gradual fashion. We'll explore this in a separa
|
|||
* Remove the application routing rules.
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -20,7 +20,7 @@ This task shows you how to setup request timeouts in Envoy using Istio.
|
|||
* Initialize the application version routing by running the following command:
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl create -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
```
|
||||
|
||||
## Request timeouts
|
||||
|
@ -133,7 +133,7 @@ the timeout is specified in millisecond (instead of second) units.
|
|||
* Remove the application routing rules.
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -26,7 +26,7 @@ two steps: 50%, 100%.
|
|||
1. Set the default version for all microservices to v1.
|
||||
|
||||
```command
|
||||
$ istioctl create -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl create -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
```
|
||||
|
||||
1. Confirm v1 is the active version of the `reviews` service by opening http://$GATEWAY_URL/productpage in your browser.
|
||||
|
@ -37,7 +37,7 @@ two steps: 50%, 100%.
|
|||
1. First, transfer 50% of the traffic from `reviews:v1` to `reviews:v3` with the following command:
|
||||
|
||||
```command
|
||||
$ istioctl replace -f samples/bookinfo/routing/route-rule-reviews-50-v3.yaml
|
||||
$ istioctl replace -f @samples/bookinfo/routing/route-rule-reviews-50-v3.yaml@
|
||||
```
|
||||
|
||||
Confirm the rule was replaced:
|
||||
|
@ -73,7 +73,7 @@ two steps: 50%, 100%.
|
|||
1. When version v3 of the `reviews` microservice is considered stable, we can route 100% of the traffic to `reviews:v3`:
|
||||
|
||||
```command
|
||||
$ istioctl replace -f samples/bookinfo/routing/route-rule-reviews-v3.yaml
|
||||
$ istioctl replace -f @samples/bookinfo/routing/route-rule-reviews-v3.yaml@
|
||||
```
|
||||
|
||||
You can now log into the `productpage` as any user and you should always see book reviews
|
||||
|
@ -93,7 +93,7 @@ For more about version routing with autoscaling, check out [Canary Deployments u
|
|||
* Remove the application routing rules.
|
||||
|
||||
```command
|
||||
$ istioctl delete -f samples/bookinfo/routing/route-rule-all-v1.yaml
|
||||
$ istioctl delete -f @samples/bookinfo/routing/route-rule-all-v1.yaml@
|
||||
```
|
||||
|
||||
* If you are not planning to explore any follow-on tasks, refer to the
|
||||
|
|
|
@ -3,3 +3,4 @@ preliminary: false
|
|||
archive: false
|
||||
archive_date: YYYY-MM-DD
|
||||
search_engine_id: "013699703217164175118:veyyqmfmpj4"
|
||||
branch_name: master
|
||||
|
|
|
@ -48,6 +48,10 @@
|
|||
<script async src='https://www.google-analytics.com/analytics.js'></script>
|
||||
<!-- End Google Analytics -->
|
||||
|
||||
<script>
|
||||
var branchName = "{{ .Site.Data.args.branch_name }}";
|
||||
</script>
|
||||
|
||||
<!-- RSS -->
|
||||
<link rel="alternate" type="application/rss+xml" title="Istio Blog" href="/feed.xml">
|
||||
|
||||
|
|
|
@ -0,0 +1 @@
|
|||
{{ .Site.Data.args.branch_name}}
|
|
@ -283,6 +283,8 @@ function handleDOMLoaded() {
|
|||
}
|
||||
|
||||
if (cmd !== "") {
|
||||
cmd = cmd.replace(/@(.*?)@/g, "<a href='https://raw.githubusercontent.com/istio/istio/" + branchName + "/$1'>$1</a>");
|
||||
|
||||
var html = "<div class='command'>" + cmd + "</div>";
|
||||
|
||||
var output = "";
|
||||
|
|
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
Loading…
Reference in New Issue