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

use kubectl for managing Istio API resources (#2002) 

* use kubectl consistently throughout for Istio API resource C.R.U.D operations

xref: https://github.com/istio/istio.github.io/issues/1843

* fix typo

* review comments

* remove unnecessary instructions to use `replace` instead of `create`

* fix linter in `zh` content
This commit is contained in:
Jason Young 2018-07-27 10:57:41 -07:00 committed by istio-bot
parent 21a5fb62a7
commit c27351268b
48 changed files with 222 additions and 236 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.spelling
View File

@ -98,6 +98,7 @@ Kops
Kuat
Kube
Kubecon
kubectl
Kubelet
Kubernetes
L3-4
@ -283,7 +284,6 @@ istio-apiserver
istio-system1
istio.io
istio.io.
istioctl
jason
json
jwt.io
@ -297,7 +297,6 @@ kube-proxy
kube-public
kube-system
kubeconfig
kubectl
kubelet
kubernetes
kubernetes.default

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

@ -343,14 +343,14 @@ of @ symbols. These indicate the path should be rendered as a link to the file f
{{< text markdown >}}
{{</* text bash */>}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
{{</* /text */>}}
{{< /text >}}
This will be rendered as:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
{{< /text >}}
### Files and snippets

2
content/about/notes/1.0/index.md
View File

@ -66,7 +66,7 @@ coupled with client-side [destination rules](/docs/concepts/traffic-management/#
- **JWT Authentication**. We now support [JWT authentication](/docs/concepts/security/#authentication) which can
be configured using [authentication policies](/docs/concepts/security/#authentication-policies).
## Istioctl
## `istioctl`
- Added the [`istioctl authn tls-check`](/docs/reference/commands/istioctl/#istioctl-authn-tls-check) command.

8
content/blog/2017/0.1-canary/index.md
View File

@ -88,11 +88,11 @@ 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](/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](/docs/reference/commands/istioctl/) command to set a routing rule something like this:
rule to control the traffic distribution. For example if we want to send 10% of the traffic to the canary, we could use `kubectl`
to set a routing rule something like this:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -183,7 +183,7 @@ helloworld-v2-4095161145-963wt 2/2 Running 0 1h
As mentioned above, the Istio routing rules can be used to route traffic based on specific criteria, allowing more sophisticated canary deployment scenarios. Say, for example, instead of exposing the canary to an arbitrary percentage of users, we want to try it out on internal users, maybe even just a percentage of them. The following command could be used to send 50% of traffic from users at *some-company-name.com* to the canary version, leaving all other users unaffected:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:

8
content/blog/2018/egress-https/index.md
View File

@ -50,7 +50,7 @@ Note that the Google Books web service is outside the Istio service mesh, the bo
Now let's direct all the traffic destined to the _details_ microservice, to _details version v2_, using the following _route rule_:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
@ -83,7 +83,7 @@ So what might have gone wrong? Ah... The answer is that I forgot to enable traff
No worries, let's define an **egress rule** and fix our application:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: config.istio.io/v1alpha2
kind: EgressRule
metadata:
@ -110,7 +110,7 @@ Note that our egress rule allows traffic to any domain matching _*.googleapis.co
We can query our egress rules:
{{< text bash >}}
$ istioctl get egressrules
$ kubectl get egressrules
NAME KIND NAMESPACE
googleapis EgressRule.v1alpha2.config.istio.io default
{{< /text >}}
@ -118,7 +118,7 @@ googleapis EgressRule.v1alpha2.config.istio.io default
We can delete our egress rule:
{{< text bash >}}
$ istioctl delete egressrule googleapis -n default
$ kubectl delete egressrule googleapis -n default
Deleted config: egressrule googleapis
{{< /text >}}

14
content/blog/2018/egress-tcp/index.md
View File

@ -209,9 +209,7 @@ service to _ratings v2-mysql_ that uses your database.
following command.
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-ratings-mysql.yaml@
Updated config virtual-service/default/reviews to revision 23048537
Updated config virtual-service/default/ratings to revision 23048538
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-ratings-mysql.yaml@
{{< /text >}}
The updated architecture appears below. Note that the blue arrows inside the mesh mark the traffic configured according
@ -263,7 +261,7 @@ TCP mesh-external service entries come to our rescue.
1. Define a TCP mesh-external service entry:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3 $MYSQL_DB_PORT
kind: ServiceEntry
metadata:
@ -284,7 +282,7 @@ TCP mesh-external service entries come to our rescue.
1. Review the service entry you just created and check that it contains the correct values:
{{< text bash >}}
$ istioctl get serviceentry mysql-external -o yaml
$ kubectl get serviceentry mysql-external -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -309,7 +307,7 @@ It worked! Accessing the web page of the application displays the ratings withou
Note that you see a one-star rating for both displayed reviews, as expected. You changed the ratings to be one star to
provide us with a visual clue that our external database is indeed being used.
As with service entries for HTTP/HTTPS, you can delete and create service entries for TCP using `istioctl`, dynamically.
As with service entries for HTTP/HTTPS, you can delete and create service entries for TCP using `kubectl`, dynamically.
## Motivation for egress TCP traffic control
@ -383,7 +381,7 @@ which could be beneficial if the consuming applications expect to use that domai
1. Remove the virtual services:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-ratings-mysql.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-ratings-mysql.yaml@
Deleted config: virtual-service/default/reviews
Deleted config: virtual-service/default/ratings
{{< /text >}}
@ -398,7 +396,7 @@ which could be beneficial if the consuming applications expect to use that domai
1. Delete the service entry:
{{< text bash >}}
$ istioctl delete serviceentry mysql-external -n default
$ kubectl delete serviceentry mysql-external -n default
Deleted config: serviceentry mysql-external
{{< /text >}}

8
content/blog/2018/soft-multitenancy/index.md
View File

@ -196,11 +196,11 @@ Although not shown, the application namespaces will also have RBAC settings limi
to certain resources. These RBAC settings could be set by the cluster administrator and/or
the tenant administrator.
### Using `istioctl` in a multi-tenant environment
### Using `kubectl` in a multi-tenant environment
When defining [route rules](https://archive.istio.io/v0.7/docs/reference/config/istio.routing.v1alpha1/#RouteRule)
or [destination policies](https://archive.istio.io/v0.7/docs/reference/config/istio.routing.v1alpha1/#DestinationPolicy),
it is necessary to ensure that the `istioctl` command is scoped to
it is necessary to ensure that the `kubectl` 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
so that it will be applied properly to that tenant's mesh. The *-i* option is used to create
@ -213,13 +213,13 @@ For example, the following command would be required to add a route rule to the
namespace:
{{< text bash >}}
$ istioctl –i istio-system1 create -n ns-1 -f route_rule_v2.yaml
$ kubectl –i istio-system1 apply -n ns-1 -f route_rule_v2.yaml
{{< /text >}}
And can be displayed using the command:
{{< text bash >}}
$ istioctl -i istio-system1 -n ns-1 get routerule
$ kubectl -i istio-system1 -n ns-1 get routerule
NAME KIND NAMESPACE
details-Default RouteRule.v1alpha2.config.istio.io ns-1
productpage-default RouteRule.v1alpha2.config.istio.io ns-1

8
content/blog/2018/v1alpha3-routing/index.md
View File

@ -391,20 +391,20 @@ resource for the destination.
old routing rules:
{{< text bash >}}
$ istioctl create -f my-second-rule-for-destination-abc.yaml
$ kubectl apply -f my-second-rule-for-destination-abc.yaml
{{< /text >}}
`v1alpha3` routing rules:
{{< text bash >}}
$ istioctl replace -f my-updated-rules-for-destination-abc.yaml
$ kubectl apply -f my-updated-rules-for-destination-abc.yaml
{{< /text >}}
Deleting route rules other than the last one for a particular destination is also done using `istioctl replace`.
Deleting route rules other than the last one for a particular destination is also done using `kubectl apply`.
When adding or removing routes that refer to service versions, the `subsets` will need to be updated in
the service's corresponding `DestinationRule`.
As you might have guessed, this is also done using `istioctl replace`.
As you might have guessed, this is also done using `kubectl apply`.
## Summary

2
content/docs/concepts/security/index.md
View File

@ -285,7 +285,7 @@ specify client-side authentication rules in mutual TLS, you need to specify the
`TLSSettings` in the `DestinationRule`. You can find more information in our
[TLS settings reference docs](/docs/reference/config/istio.networking.v1alpha3/#TLSSettings).
Like other Istio configuration, you can specify authentication policies in
`.yaml` files. You deploy policies using `istioctl`.
`.yaml` files. You deploy policies using `kubectl`.
The following example authentication policy specifies that transport
authentication for the `reviews` service must use mutual TLS:

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

@ -363,12 +363,9 @@ spec:
version: v2
{{< /text >}}
Rules can be configured using the
[istioctl CLI](/docs/reference/commands/istioctl/), or in a Kubernetes
deployment using the `kubectl` command instead, although `istioctl` provides
better output and is recommended. See the
[configuring request routing task](/docs/tasks/traffic-management/request-routing/)
for examples.
Rules can be configured using the `kubectl` command. See the
[configuring request routing
task](/docs/tasks/traffic-management/request-routing/) for examples.
The following sections provide a basic overview of the traffic management configuration resources.
See [networking reference](/docs/reference/config/istio.networking.v1alpha3/)

22
content/docs/examples/bookinfo/index.md
View File

@ -135,18 +135,16 @@ Now that the Bookinfo services are up and running, you need to make the applicat
Kubernetes cluster, e.g., from a browser. An [Istio Gateway](/docs/concepts/traffic-management/#gateways)
is used for this purpose.
> Note that the `istioctl` (the Istio CLI) is used in the following commands, instead of `kubectl`. This is because the Kubernetes application is now deployed and the following commands are managing Istio-specific configuration. In a Kubernetes environment, you can replace `istioctl` with `kubectl` if you prefer to stick to one CLI, however, `istioctl` does provide significantly better output and is recommended.
1. Define the ingress gateway for the application:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
$ kubectl apply -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
{{< /text >}}
1. Confirm the gateway has been created:
{{< text bash >}}
$ istioctl get gateway
$ kubectl get gateway
GATEWAY NAME HOSTS NAMESPACE AGE
bookinfo-gateway * default 2d
{{< /text >}}
@ -192,7 +190,7 @@ is used for this purpose.
in `samples/bookinfo/networking` will not work due to an issue with the current implementation of the default subdomain
for short service host names. For now, you need to use the corresponding yaml files in `samples/bookinfo/platform/consul`.
For example, replace `samples/bookinfo/networking/destination-rule-all.yaml` with
`samples/bookinfo/platform/consul/destination-rule-all.yaml` in the `istioctl create` command, below.
`samples/bookinfo/platform/consul/destination-rule-all.yaml` in the `kubectl apply` command, below.
## Confirm the app is running
@ -219,13 +217,13 @@ Run the following command to create default destination rules for the bookinfo s
* If you did **not** enable mutual TLS, execute this command:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/destination-rule-all.yaml@
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
{{< /text >}}
* If you **did** enable mutual TLS, execute this command:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
{{< /text >}}
Wait a few seconds for the destination rules to propagate.
@ -233,7 +231,7 @@ Wait a few seconds for the destination rules to propagate.
You can display the destination rules with the following command:
{{< text bash >}}
$ istioctl get destinationrules -o yaml
$ kubectl get destinationrules -o yaml
{{< /text >}}
## What's next
@ -260,9 +258,9 @@ it up using the following instructions corresponding to your Istio runtime envir
1. Confirm shutdown
{{< text bash >}}
$ istioctl get virtualservices #-- there should be no virtual services
$ istioctl get destinationrules #-- there should be no destination rules
$ istioctl get gateway #-- there should be no gateway
$ kubectl get virtualservices #-- there should be no virtual services
$ kubectl get destinationrules #-- there should be no destination rules
$ kubectl get gateway #-- there should be no gateway
$ kubectl get pods #-- the Bookinfo pods should be deleted
{{< /text >}}
@ -279,6 +277,6 @@ it up using the following instructions corresponding to your Istio runtime envir
1. Confirm cleanup
{{< text bash >}}
$ istioctl get virtualservices #-- there should be no more routing rules
$ kubectl get virtualservices #-- there should be no more routing rules
$ docker ps -a #-- the Bookinfo containers should be deleted
{{< /text >}}

2
content/docs/examples/endpoints/index.md
View File

@ -35,7 +35,7 @@ Otherwise, ESP won't be able to access Google cloud service control.
1. If you want to access the service through Ingress, create the following Ingress definition:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:

2
content/docs/examples/integrating-vms/index.md
View File

@ -121,7 +121,7 @@ $ istioctl kube-inject -n bookinfo -f @samples/bookinfo/platform/kube/bookinfo-r
Create route rules that will force bookinfo to use the ratings back end:
{{< text bash >}}
$ istioctl create -n bookinfo -f @samples/bookinfo/networking/virtual-service-ratings-mysql-vm.yaml@
$ kubectl apply -n bookinfo -f @samples/bookinfo/networking/virtual-service-ratings-mysql-vm.yaml@
{{< /text >}}
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

14
content/docs/setup/consul/quick-start/index.md
View File

@ -26,7 +26,7 @@ Quick Start instructions to install and configure Istio in a Docker Compose setu
installation directory contains:
* Sample applications in `samples/`
* The `istioctl` client binary in the `bin/` directory. `istioctl` is used for creating routing rules and policies.
* The `istioctl` client binary in the `bin/` directory. `istioctl` is used for some debug and diagnostics tasks.
* The `istio.VERSION` configuration file
1. Add the `istioctl` client to your PATH.
@ -36,6 +36,10 @@ For example, run the following command on a macOS or Linux system:
$ export PATH=$PWD/bin:$PATH
{{< /text >}}
1. Install `kubectl` using [these instructions](https://kubernetes.io/docs/tasks/tools/install-kubectl).
`kubectl` is used to create, read, modify, and delete Istio API resources.
1. For Linux users, configure the `DOCKER_GATEWAY` environment variable
{{< text bash >}}
@ -56,12 +60,14 @@ For example, run the following command on a macOS or Linux system:
$ docker ps -a
{{< /text >}}
> If the Istio Pilot container terminates, ensure that you run the `istioctl context-create` command and re-run the command from the previous step.
> If the Istio Pilot container terminates, ensure that you ran the `kubectl config` commands below and re-run the command from the previous step.
1. Configure `istioctl` to use mapped local port for the Istio API server:
1. Configure `kubectl` to use mapped local port for the API server:
{{< text bash >}}
$ istioctl context-create --api-server http://localhost:8080
$ kubectl config set-context istio --cluster=istio
$ kubectl config set-cluster istio --server=http://localhost:8080
$ kubectl config use-context istio
{{< /text >}}
## Deploy your application

3
content/docs/setup/kubernetes/helm-install/index.md
View File

@ -106,7 +106,7 @@ With this minimal set you can install your own application and [configure reques
## Uninstall
* For option 1, uninstall using kubectl:
* For option 1, uninstall using `kubectl`:
{{< text bash >}}
$ kubectl delete -f $HOME/istio.yaml
@ -123,4 +123,3 @@ With this minimal set you can install your own application and [configure reques
{{< text bash >}}
$ kubectl -n istio-system delete job --all
{{< /text >}}

6
content/docs/setup/kubernetes/multicluster-install/index.md
View File

@ -48,7 +48,7 @@ on **one** Kubernetes cluster.
The istio-remote component must be deployed to each remote Kubernetes
cluster. There are two approaches to installing the remote. The remote
can be installed and managed entirely by Helm and Tiller, or via Helm and
kubectl.
`kubectl`.
### Set environment variables for Pod IPs from Istio control plane needed by remote
@ -79,7 +79,7 @@ Proceed to one of the options for connecting the remote cluster to the local clu
**Sidecar Injection.** The default behavior is to enable automatic sidecar injection on the remote clusters. For manual sidecar injection refer to the [manual sidecar example](#remote-cluster-manual-sidecar-injection-example)
### Use kubectl with Helm to connect the remote cluster to the local
### Use `kubectl` with Helm to connect the remote cluster to the local
1. Use the helm template command on a remote to specify the Istio control plane service endpoints:
@ -245,7 +245,7 @@ to conform to the format.
> The uninstall method must match the installation method (`Helm and kubectl` or `Helm and Tiller` based).
### Use kubectl to uninstall istio-remote
### Use `kubectl` to uninstall istio-remote
{{< text bash >}}
$ kubectl delete -f $HOME/istio-remote.yaml

2
content/docs/setup/kubernetes/platform-setup/ibm/index.md
View File

@ -36,5 +36,5 @@ Replace `<cluster-name>` with the name of the cluster you want to use in the fol
## IBM Cloud Private
[Configure the kubectl CLI](https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0/manage_cluster/cfc_cli.html)
[Configure `kubectl`](https://www.ibm.com/support/knowledgecenter/SSBS6K_2.1.0/manage_cluster/cfc_cli.html)
to access the IBM Cloud Private Cluster.

6
content/docs/setup/kubernetes/quick-start/index.md
View File

@ -63,10 +63,10 @@ default:
$ kubectl apply -f install/kubernetes/istio-demo-auth.yaml
{{< /text >}}
### Option 3: Render Kubernetes manifest with Helm and deploy with kubectl
### Option 3: Render Kubernetes manifest with Helm and deploy with `kubectl`
Follow our setup instructions to
[render the Kubernetes manifest with Helm and deploy with kubectl](/docs/setup/kubernetes/helm-install/#option-1-install-with-helm-via-helm-template).
[render the Kubernetes manifest with Helm and deploy with `kubectl`](/docs/setup/kubernetes/helm-install/#option-1-install-with-helm-via-helm-template).
### Option 4: Use Helm and Tiller to manage the Istio deployment
@ -144,7 +144,7 @@ $ kubectl create -n <namespace> -f <your-app-spec>.yaml
{{< /text >}}
If you don't have the Istio-sidecar-injector installed, you must use
[istioctl kube-inject](/docs/reference/commands/istioctl/#istioctl-kube-inject)
[`istioctl kube-inject`](/docs/reference/commands/istioctl/#istioctl-kube-inject)
to manually inject Envoy containers in your application pods before deploying
them:

39
content/docs/tasks/policy-enforcement/denial-and-list/index.md
View File

@ -22,19 +22,19 @@ This task shows how to control access to a service using simple denials or white
that define the service subsets corresponding to each version.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/destination-rule-all.yaml@
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
{{< /text >}}
If you enabled mutual TLS, please run the following instead
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
{{< /text >}}
You can display the destination rules with the following command:
{{< text bash >}}
$ istioctl get destinationrules -o yaml
$ kubectl get destinationrules -o yaml
{{< /text >}}
Since the subset references in virtual services rely on the destination rules,
@ -44,20 +44,17 @@ that define the service subsets corresponding to each version.
test user "jason" to version v2 and requests from any other user to v3.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
and then run the following command:
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@
{{< /text >}}
> If you have conflicting rules that you set in previous tasks,
> use `istioctl replace` instead of `istioctl create`.
>
> If you are using a namespace other than `default`,
> use `istioctl -n namespace ...` to specify the namespace.
> use `kubectl -n namespace ...` to specify the namespace.
## Simple _denials_
@ -80,7 +77,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.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/policy/mixer-rule-deny-label.yaml@
$ kubectl apply -f @samples/bookinfo/policy/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
@ -114,7 +111,7 @@ Istio also supports attribute-based whitelists and blacklists. The following whi
1. Remove the denier configuration that you added in the previous section.
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/policy/mixer-rule-deny-label.yaml@
$ kubectl delete -f @samples/bookinfo/policy/mixer-rule-deny-label.yaml@
{{< /text >}}
1. Verify that when you access the Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`) without logging in, you see red stars.
@ -139,7 +136,7 @@ Istio also supports attribute-based whitelists and blacklists. The following whi
and then run the following command:
{{< text bash >}}
$ istioctl create -f whitelist-handler.yaml
$ kubectl apply -f whitelist-handler.yaml
{{< /text >}}
1. Extract the version label by creating an instance of the [`listentry`](/docs/reference/config/policy-and-telemetry/templates/listentry/) template.
@ -157,7 +154,7 @@ Save the following YAML snippet as `appversion-instance.yaml`:
and then run the following command:
{{< text bash >}}
$ istioctl create -f appversion-instance.yaml
$ kubectl apply -f appversion-instance.yaml
{{< /text >}}
1. Enable `whitelist` checking for the ratings service.
@ -179,7 +176,7 @@ Save the following YAML snippet as `checkversion-rule.yaml`:
and then run the following command:
{{< text bash >}}
$ istioctl create -f checkversion-rule.yaml
$ kubectl apply -f checkversion-rule.yaml
{{< /text >}}
1. Verify that when you access the Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`) without logging in, you see **no** stars.
@ -190,29 +187,29 @@ Verify that after logging in as "jason" you see black stars.
* Remove the mixer configuration:
{{< text bash >}}
$ istioctl delete -f checkversion-rule.yaml
$ istioctl delete -f appversion-instance.yaml
$ istioctl delete -f whitelist-handler.yaml
$ kubectl delete -f checkversion-rule.yaml
$ kubectl delete -f appversion-instance.yaml
$ kubectl delete -f whitelist-handler.yaml
{{< /text >}}
* Remove the application routing rules:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
* Remove the application destination rules:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/destination-rule-all.yaml@
$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all.yaml@
{{< /text >}}
If you enabled mutual TLS, please run the following instead
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
{{< /text >}}
* If you are not planning to explore any follow-on tasks, refer to the
[Bookinfo cleanup](/docs/examples/bookinfo/#cleanup) instructions
to shutdown the application.
to shutdown the application.

10
content/docs/tasks/policy-enforcement/rate-limiting/index.md
View File

@ -28,14 +28,14 @@ service.
1. Set the default version for all services to v1. If you’ve already created route rules for the sample, use `replace` rather than `create` in the following command.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
1. Initialize application version routing on the `reviews` service to
direct requests from the test user "jason" to version v2 and requests from any other user to v3.
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@
{{< /text >}}
## Rate limits
@ -68,7 +68,7 @@ so the configuration to enable rate limiting on both adapters is the same.
enable rate limiting.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/policy/mixer-rule-ratings-ratelimit.yaml@
$ kubectl apply -f @samples/bookinfo/policy/mixer-rule-ratings-ratelimit.yaml@
{{< /text >}}
1. Confirm the `memquota` handler was created:
@ -270,13 +270,13 @@ namespace.
1. Remove the rate limit configuration:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/policy/mixer-rule-ratings-ratelimit.yaml@
$ kubectl delete -f @samples/bookinfo/policy/mixer-rule-ratings-ratelimit.yaml@
{{< /text >}}
1. Remove the application routing rules:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
1. If you are not planning to explore any follow-on tasks, refer to the

34
content/docs/tasks/security/authn-policy/index.md
View File

@ -91,7 +91,7 @@ $ kubectl get destinationrules.networking.istio.io --all-namespaces -o yaml | gr
To set a mesh-wide authentication policy that enables mutual TLS, submit *mesh authentication policy* like below:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
@ -121,7 +121,7 @@ multiple destination rules, one for each applicable service (or namespace). Howe
services so that it is on par with the mesh-wide authentication policy.
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
@ -188,7 +188,7 @@ sleep.bar to httpbin.legacy: 503
To fix this issue, we can add a destination rule to overwrite the TLS setting for `httpbin.legacy`. For example:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@ -216,7 +216,7 @@ command terminated with exit code 35
Again, we can correct this by overriding the destination rule for the API server (`kubernetes.default`)
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@ -260,7 +260,7 @@ The example below shows the policy to enable mutual TLS for all services in name
and specifies a namespace, in this case, `foo`. If you don’t specify a namespace value the policy will apply to the default namespace.
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -277,7 +277,7 @@ EOF
Add corresponding destination rule:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
@ -314,7 +314,7 @@ sleep.legacy to httpbin.legacy: 200
You can also set authentication policy and destination rule for a specific service. Run this command to set another policy only for `httpbin.bar` service.
{{< text bash >}}
$ cat <<EOF | istioctl create -n bar -f -
$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -330,7 +330,7 @@ EOF
And a destination rule:
{{< text bash >}}
$ cat <<EOF | istioctl create -n bar -f -
$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
@ -359,7 +359,7 @@ If we have more services in namespace `bar`, we should see traffic to them won't
we edit the policy slightly to apply on a specific port:
{{< text bash >}}
$ cat <<EOF | istioctl replace -n bar -f -
$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -377,7 +377,7 @@ EOF
And a corresponding change to the destination rule:
{{< text bash >}}
$ cat <<EOF | istioctl replace -n bar -f -
$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
@ -410,7 +410,7 @@ Note that you've already created a namespace-wide policy that enables mutual TLS
`sleep.legacy` to `httpbin.foo` are failing (see above).
{{< text bash >}}
$ cat <<EOF | istioctl create -n foo -f -
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -424,7 +424,7 @@ EOF
and destination rule:
{{< text bash >}}
$ cat <<EOF | istioctl create -n foo -f -
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
@ -464,7 +464,7 @@ this tutorial, we use this [JWT test]({{< github_file >}}/security/tools/jwt/sam
Also, for convenience, expose `httpbin.foo` via ingressgateway (for more details, see the [ingress task](/docs/tasks/traffic-management/ingress/)).
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@ -484,7 +484,7 @@ EOF
{{< /text >}}
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -521,7 +521,7 @@ Now, add a policy that requires end-user JWT for `httpbin.foo`. The next command
be the case if you run [cleanup](#cleanup-part-2) as described). You can run `kubectl get policies.authentication.istio.io -n foo` to confirm.
{{< text bash >}}
$ cat <<EOF | istioctl create -n foo -f -
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -576,7 +576,7 @@ $ for i in `seq 1 10`; do curl --header "Authorization: Bearer $TOKEN" $INGRESS_
End-user authentication and mutual TLS can be used together. Modify the policy above to define both mutual TLS and end-user JWT authentication:
{{< text bash >}}
$ cat <<EOF | istioctl replace -n foo -f -
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -599,7 +599,7 @@ EOF
And add a destination rule:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:

6
content/docs/tasks/security/mtls-migration/index.md
View File

@ -67,7 +67,7 @@ In authentication policy, we have a `PERMISSIVE` mode which makes the server acc
We need to configure the server to this mode.
{{< text bash >}}
$ cat <<EOF | istioctl create -n foo -f -
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -96,7 +96,7 @@ $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sle
Configure Istio services to send mutual TLS traffic by setting `DestinationRule`.
{{< text bash >}}
$ cat <<EOF | istioctl create -n foo -f -
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
@ -131,7 +131,7 @@ then increase the rollout scope and finally apply to all Istio client services.
After migrating all clients to Istio services, injecting Envoy sidecar, we can lock down the `httpbin.foo` to only accept mutual TLS traffic.
{{< text bash >}}
$ cat <<EOF | istioctl create -n foo -f -
$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:

24
content/docs/tasks/security/role-based-access-control/index.md
View File

@ -35,7 +35,7 @@ microservices running under them.
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo-add-serviceaccount.yaml@)
{{< /text >}}
> If you are using a namespace other than `default`, use `istioctl -n namespace ...` to specify the namespace.
> If you are using a namespace other than `default`, use `kubectl -n namespace ...` to specify the namespace.
* There is a major update to RBAC in Istio 1.0. Please make sure to remove any existing RBAC config before continuing.
@ -71,11 +71,9 @@ for the list of supported keys in `constraints` and `properties`.
Run the following command to enable Istio authorization for "default" namespace:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/platform/kube/rbac/rbac-config-ON.yaml@
$ kubectl apply -f @samples/bookinfo/platform/kube/rbac/rbac-config-ON.yaml@
{{< /text >}}
> If you have conflicting rules that you set in previous tasks, use `istioctl replace` instead of `istioctl create`.
Point your browser at the Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`). Now you should see
`"RBAC: access denied"`. This is because Istio authorization is "deny by default", which means that you need to
explicitly define access control policy to grant access to any service.
@ -95,7 +93,7 @@ is accessible by services in the same namespace (i.e., "default" namespace) and
Run the following command to create a namespace-level access control policy:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/platform/kube/rbac/namespace-policy.yaml@
$ kubectl apply -f @samples/bookinfo/platform/kube/rbac/namespace-policy.yaml@
{{< /text >}}
The policy does the following:
@ -155,7 +153,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:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/platform/kube/rbac/namespace-policy.yaml@
$ kubectl delete -f @samples/bookinfo/platform/kube/rbac/namespace-policy.yaml@
{{< /text >}}
## Service-level access control
@ -175,7 +173,7 @@ In this step, we will create a policy that allows external requests to view `pro
Run the following command:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/platform/kube/rbac/productpage-policy.yaml@
$ kubectl apply -f @samples/bookinfo/platform/kube/rbac/productpage-policy.yaml@
{{< /text >}}
The policy does the following:
@ -226,7 +224,7 @@ We will create a policy to allow "productpage" service to read "details" and "re
Run the following command:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/platform/kube/rbac/details-reviews-policy.yaml@
$ kubectl apply -f @samples/bookinfo/platform/kube/rbac/details-reviews-policy.yaml@
{{< /text >}}
The policy does the following:
@ -279,7 +277,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.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/platform/kube/rbac/ratings-policy.yaml@
$ kubectl apply -f @samples/bookinfo/platform/kube/rbac/ratings-policy.yaml@
{{< /text >}}
The policy does the following:
@ -325,9 +323,9 @@ the "black" and "red" ratings in "Book Reviews" section.
* Remove Istio authorization policy configuration:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/platform/kube/rbac/ratings-policy.yaml@
$ istioctl delete -f @samples/bookinfo/platform/kube/rbac/details-reviews-policy.yaml@
$ istioctl delete -f @samples/bookinfo/platform/kube/rbac/productpage-policy.yaml@
$ kubectl delete -f @samples/bookinfo/platform/kube/rbac/ratings-policy.yaml@
$ kubectl delete -f @samples/bookinfo/platform/kube/rbac/details-reviews-policy.yaml@
$ kubectl delete -f @samples/bookinfo/platform/kube/rbac/productpage-policy.yaml@
{{< /text >}}
Alternatively, you can delete all `ServiceRole` and `ServiceRoleBinding` resources by running the following commands:
@ -340,5 +338,5 @@ the "black" and "red" ratings in "Book Reviews" section.
* Disable Istio authorization:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/platform/kube/rbac/rbac-config-ON.yaml@
$ kubectl delete -f @samples/bookinfo/platform/kube/rbac/rbac-config-ON.yaml@
{{< /text >}}

4
content/docs/tasks/telemetry/fluentd/index.md
View File

@ -342,7 +342,7 @@ spec:
Create the resources:
{{< text bash >}}
$ istioctl create -f fluentd-istio.yaml
$ kubectl apply -f fluentd-istio.yaml
Created config logentry/istio-system/newlog at revision 22374
Created config fluentd/istio-system/handler at revision 22375
Created config rule/istio-system/newlogtofluentd at revision 22376
@ -387,7 +387,7 @@ example stack.
* Remove the new telemetry configuration:
{{< text bash >}}
$ istioctl delete -f fluentd-istio.yaml
$ kubectl delete -f fluentd-istio.yaml
{{< /text >}}
* Remove the example Fluentd, Elasticsearch, Kibana stack:

4
content/docs/tasks/telemetry/metrics-logs/index.md
View File

@ -120,7 +120,7 @@ as the example application throughout this task.
1. Push the new configuration.
{{< text bash >}}
$ istioctl create -f new_telemetry.yaml
$ kubectl apply -f new_telemetry.yaml
Created config metric/istio-system/doublerequestcount at revision 1973035
Created config prometheus/istio-system/doublehandler at revision 1973036
Created config rule/istio-system/doubleprom at revision 1973037
@ -291,7 +291,7 @@ here to illustrate how to use `match` expressions to control rule execution.
* Remove the new telemetry configuration:
{{< text bash >}}
$ istioctl delete -f new_telemetry.yaml
$ kubectl delete -f new_telemetry.yaml
{{< /text >}}
* Remove any `kubectl port-forward` processes that may still be running:

12
content/docs/tasks/telemetry/tcp-metrics/index.md
View File

@ -101,7 +101,7 @@ will generate and collect automatically.
1. Push the new configuration.
{{< text bash >}}
$ istioctl create -f tcp_telemetry.yaml
$ kubectl apply -f tcp_telemetry.yaml
Created config metric/default/mongosentbytes at revision 3852843
Created config metric/default/mongoreceivedbytes at revision 3852844
Created config prometheus/default/mongohandler at revision 3852845
@ -147,19 +147,19 @@ will generate and collect automatically.
that define the service subsets corresponding to each version, and the load balancing policy for each subset.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/destination-rule-all.yaml@
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
{{< /text >}}
If you enabled mutual TLS, please run the following instead
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
{{< /text >}}
You can display the destination rules with the following command:
{{< text bash >}}
$ istioctl get destinationrules -o yaml
$ kubectl get destinationrules -o yaml
{{< /text >}}
Since the subset references in virtual services rely on the destination rules,
@ -168,7 +168,7 @@ will generate and collect automatically.
1. Create `ratings` and `reviews` virtual services:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-ratings-db.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-ratings-db.yaml@
Created config virtual-service/default/reviews at revision 3003
Created config virtual-service/default/ratings at revision 3004
{{< /text >}}
@ -239,7 +239,7 @@ protocols within policies.
* Remove the new telemetry configuration:
{{< text bash >}}
$ istioctl delete -f tcp_telemetry.yaml
$ kubectl delete -f tcp_telemetry.yaml
{{< /text >}}
* Remove the `port-forward` process:

8
content/docs/tasks/traffic-management/app-health-check/index.md
View File

@ -52,7 +52,7 @@ Follow these steps to complete the configuration:
1. To configure the authentication policy, run:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -67,7 +67,7 @@ Follow these steps to complete the configuration:
1. To configure the destination rule, run:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
@ -139,7 +139,7 @@ Again, enable mutual TLS for services in the default namespace by adding namespa
1. To configure the authentication policy, run:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
@ -154,7 +154,7 @@ Again, enable mutual TLS for services in the default namespace by adding namespa
1. To configure the destination rule, run:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:

6
content/docs/tasks/traffic-management/circuit-breaking/index.md
View File

@ -41,7 +41,7 @@ configuration by intentionally "tripping" the circuit breaker.
when calling the `httpbin` service:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@ -66,7 +66,7 @@ when calling the `httpbin` service:
1. Verify the destination rule was created correctly:
{{< text bash yaml >}}
$ istioctl get destinationrule httpbin -o yaml
$ kubectl get destinationrule httpbin -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
@ -253,7 +253,7 @@ one connection and request concurrently, you should see some failures when the
1. Remove the rules:
{{< text bash >}}
$ istioctl delete destinationrule httpbin
$ kubectl delete destinationrule httpbin
{{< /text >}}
1. Shutdown the [httpbin]({{< github_tree >}}/samples/httpbin) service and client:

50
content/docs/tasks/traffic-management/egress-gateway/index.md
View File

@ -57,7 +57,7 @@ First direct HTTP traffic without TLS origination
1. Define a `ServiceEntry` for `edition.cnn.com`:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -103,7 +103,7 @@ First direct HTTP traffic without TLS origination
gateway, setting SNI to `edition.cnn.com`.
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
kind: Gateway
metadata:
name: istio-egressgateway
@ -149,7 +149,7 @@ First direct HTTP traffic without TLS origination
otherwise:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
kind: Gateway
metadata:
name: istio-egressgateway
@ -169,7 +169,7 @@ First direct HTTP traffic without TLS origination
1. Define a `VirtualService` to direct the traffic through the egress gateway:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -241,10 +241,10 @@ First direct HTTP traffic without TLS origination
Remove the previous definitions before proceeding to the next step:
{{< text bash >}}
$ istioctl delete gateway istio-egressgateway
$ istioctl delete serviceentry cnn
$ istioctl delete virtualservice direct-through-egress-gateway
$ istioctl delete destinationrule set-sni-for-egress-gateway
$ kubectl delete gateway istio-egressgateway
$ kubectl delete serviceentry cnn
$ kubectl delete virtualservice direct-through-egress-gateway
$ kubectl delete destinationrule set-sni-for-egress-gateway
{{< /text >}}
## Perform TLS origination with the egress `Gateway`
@ -254,7 +254,7 @@ Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Ori
1. Define a `ServiceEntry` for `edition.cnn.com`:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -296,7 +296,7 @@ Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Ori
gateway, setting SNI to `edition.cnn.com`.
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
kind: Gateway
metadata:
name: istio-egressgateway
@ -342,7 +342,7 @@ Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Ori
otherwise:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
kind: Gateway
metadata:
name: istio-egressgateway
@ -363,7 +363,7 @@ Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Ori
origination:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -442,11 +442,11 @@ Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Ori
Remove the Istio configuration items we created:
{{< text bash >}}
$ istioctl delete gateway istio-egressgateway
$ istioctl delete serviceentry cnn
$ istioctl delete virtualservice direct-through-egress-gateway
$ istioctl delete destinationrule originate-tls-for-edition-cnn-com
$ istioctl delete destinationrule set-sni-for-egress-gateway
$ kubectl delete gateway istio-egressgateway
$ kubectl delete serviceentry cnn
$ kubectl delete virtualservice direct-through-egress-gateway
$ kubectl delete destinationrule originate-tls-for-edition-cnn-com
$ kubectl delete destinationrule set-sni-for-egress-gateway
{{< /text >}}
## Direct HTTPS traffic through an egress gateway
@ -457,7 +457,7 @@ You specify the port 443, protocol `TLS` in the corresponding `ServiceEntry`, eg
1. Define a `ServiceEntry` for `edition.cnn.com`:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -492,7 +492,7 @@ The output should be the same as in the previous section.
gateway, setting SNI to `edition.cnn.com`.
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
kind: Gateway
metadata:
name: istio-egressgateway
@ -538,7 +538,7 @@ The output should be the same as in the previous section.
otherwise:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@ -561,7 +561,7 @@ The output should be the same as in the previous section.
1. Define a `VirtualService` to direct the traffic through the egress gateway:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -626,10 +626,10 @@ The output should be the same as in the previous section.
### Cleanup of the egress gateway for HTTPS traffic
{{< text bash >}}
$ istioctl delete serviceentry cnn
$ istioctl delete gateway istio-egressgateway
$ istioctl delete virtualservice direct-through-egress-gateway
$ istioctl delete destinationrule set-sni-for-egress-gateway
$ kubectl delete serviceentry cnn
$ kubectl delete gateway istio-egressgateway
$ kubectl delete virtualservice direct-through-egress-gateway
$ kubectl delete destinationrule set-sni-for-egress-gateway
{{< /text >}}
## Additional security considerations

12
content/docs/tasks/traffic-management/egress-tls-origination/index.md
View File

@ -53,7 +53,7 @@ Note that you use a wildcard `*` in your `hosts` definition: `*.cnn.com`. Using
1. Create a `ServiceEntry` to allow access to an external HTTP and HTTPS services:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -98,7 +98,7 @@ the latency of fetching the content of `http://edition.cnn.com/politics`. The se
In the next section, you configure Istio to perform TLS origination to resolve these two issues. Clean your configuration before proceeding to the next section:
{{< text bash >}}
$ istioctl delete serviceentry cnn
$ kubectl delete serviceentry cnn
{{< /text >}}
## TLS origination for egress traffic
@ -113,7 +113,7 @@ to DNS to correctly configure Envoy.
proxy needs to know exactly which host to access using HTTPS:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -189,9 +189,9 @@ Also note that even for HTTPS originated by the application, the attacker could
1. Remove the Istio configuration items you created:
{{< text bash >}}
$ istioctl delete serviceentry cnn
$ istioctl delete virtualservice rewrite-port-for-edition-cnn-com
$ istioctl delete destinationrule originate-tls-for-edition-cnn-com
$ kubectl delete serviceentry cnn
$ kubectl delete virtualservice rewrite-port-for-edition-cnn-com
$ kubectl delete destinationrule originate-tls-for-edition-cnn-com
{{< /text >}}
1. Shutdown the [sleep]({{< github_tree >}}/samples/sleep) service:

12
content/docs/tasks/traffic-management/egress/index.md
View File

@ -49,7 +49,7 @@ from within your Istio cluster. In this task you access
1. Create a `ServiceEntry` to allow access to an external HTTP service:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -67,7 +67,7 @@ from within your Istio cluster. In this task you access
1. Create a `ServiceEntry` to allow access to an external HTTPS service:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
@ -109,7 +109,7 @@ from within your Istio cluster. In this task you access
Similar to inter-cluster requests, Istio
[routing rules](/docs/concepts/traffic-management/#rule-configuration)
can also be set for external services that are accessed using `ServiceEntry` configurations.
In this example, you use [istioctl](/docs/reference/commands/istioctl/)
In this example, you use [`istioctl`](/docs/reference/commands/istioctl/)
to set a timeout rule on calls to the httpbin.org service.
1. From inside the pod being used as the test source, make a _curl_ request to the `/delay` endpoint of the httpbin.org external service:
@ -129,7 +129,7 @@ to set a timeout rule on calls to the httpbin.org service.
1. Exit the source pod and use `istioctl` to set a 3s timeout on calls to the httpbin.org external service:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -260,8 +260,8 @@ cluster provider specific knowledge and configuration.
1. Remove the rules:
{{< text bash >}}
$ istioctl delete serviceentry httpbin-ext google-ext
$ istioctl delete virtualservice httpbin-ext
$ kubectl delete serviceentry httpbin-ext google-ext
$ kubectl delete virtualservice httpbin-ext
{{< /text >}}
1. Shutdown the [sleep]({{< github_tree >}}/samples/sleep) service:

14
content/docs/tasks/traffic-management/fault-injection/index.md
View File

@ -24,8 +24,8 @@ This task shows you how to inject faults to test the resiliency of your applicat
running the following commands:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
{{< /text >}}
## Injecting an HTTP delay fault
@ -42,13 +42,13 @@ still expect the end-to-end flow to continue without any errors.
`jason`.
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-ratings-test-delay.yaml@
{{< /text >}}
1. Confirm the rule was created:
{{< text bash yaml >}}
$ istioctl get virtualservice ratings -o yaml
$ kubectl get virtualservice ratings -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -145,13 +145,13 @@ ratings not available` message.
1. Create a fault injection rule to send an HTTP abort for user `jason`:
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-ratings-test-abort.yaml@
{{< /text >}}
1. Confirm the rule was created:
{{< text bash yaml >}}
$ istioctl get virtualservice ratings -o yaml
$ kubectl get virtualservice ratings -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -196,7 +196,7 @@ application's `/productpage`.
1. Remove the application routing rules:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
1. If you are not planning to explore any follow-on tasks, refer to the

10
content/docs/tasks/traffic-management/ingress/index.md
View File

@ -133,7 +133,7 @@ Let's see how you can configure a `Gateway` on port 80 for HTTP traffic.
1. Create an Istio `Gateway`:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@ -154,7 +154,7 @@ Let's see how you can configure a `Gateway` on port 80 for HTTP traffic.
1. Configure routes for traffic entering via the `Gateway`:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -225,7 +225,7 @@ As you may have guessed, entering the `httpbin` service URL in a browser won't w
To work around this problem for simple tests and demos, use a wildcard `*` value for the host in the `Gateway` and `VirutualService` configurations. For example, if you change your ingress configuration to the following:
{{< text bash >}}
$ cat <<EOF | istioctl replace -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@ -278,7 +278,7 @@ and exposed an HTTP endpoint of the service to external traffic.
Delete the `Gateway` configuration, the `VirtualService` and the secret, and shutdown the [httpbin]({{< github_tree >}}/samples/httpbin) service:
{{< text bash >}}
$ istioctl delete gateway httpbin-gateway
$ istioctl delete virtualservice httpbin
$ kubectl delete gateway httpbin-gateway
$ kubectl delete virtualservice httpbin
$ kubectl delete --ignore-not-found=true -f @samples/httpbin/httpbin.yaml@
{{< /text >}}

8
content/docs/tasks/traffic-management/mirroring/index.md
View File

@ -126,7 +126,7 @@ In this step, you will change that behavior so that all traffic goes to `v1`.
1. Create a default route rule to route all traffic to `v1` of the service:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -200,7 +200,7 @@ log entries for `v1` and none for `v2`:
1. Change the route rule to mirror traffic to v2:
{{< text bash >}}
$ cat <<EOF | istioctl replace -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -253,8 +253,8 @@ log entries for `v1` and none for `v2`:
1. Remove the rules:
{{< text bash >}}
$ istioctl delete virtualservice httpbin
$ istioctl delete destinationrule httpbin
$ kubectl delete virtualservice httpbin
$ kubectl delete destinationrule httpbin
{{< /text >}}
1. Shutdown the [httpbin]({{< github_tree >}}/samples/httpbin) service and client:

15
content/docs/tasks/traffic-management/request-routing/index.md
View File

@ -33,13 +33,10 @@ in a round robin fashion.
To route to one version only, you apply virtual services that set the default version for the microservices.
In this case, the virtual services will route all traffic to `v1` of each microservice.
> Before continuing, be sure you don't have any existing virtual services applied
to the Bookinfo app. If you already created conflicting virtual services for Bookinfo, you must use `replace` rather than `create` in the following command.
1. Run the following command to apply the virtual services:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
Because configuration propagation is eventually consistent, wait a few seconds
@ -48,7 +45,7 @@ to the Bookinfo app. If you already created conflicting virtual services for Boo
1. Display the defined routes with the following command:
{{< text bash yaml >}}
$ istioctl get virtualservices -o yaml
$ kubectl get virtualservices -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -113,7 +110,7 @@ to the Bookinfo app. If you already created conflicting virtual services for Boo
1. Display the corresponding `subset` definitions:
{{< text bash >}}
$ istioctl get destinationrules -o yaml
$ kubectl get destinationrules -o yaml
{{< /text >}}
You have configured Istio to route to the `v1` version of the Bookinfo microservices,
@ -151,13 +148,13 @@ Remember, `reviews:v2` is the version that includes the star ratings feature.
1. Run the following command to enable the user-based routing:
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml@
{{< /text >}}
1. Confirm the rule is created:
{{< text bash yaml >}}
$ istioctl get virtualservice reviews -o yaml
$ kubectl get virtualservice reviews -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -213,7 +210,7 @@ gradually send traffic from one version of a service to another.
1. Remove the application virtual services.
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
1. If you are not planning to explore any follow-on tasks, refer to the

10
content/docs/tasks/traffic-management/request-timeouts/index.md
View File

@ -19,7 +19,7 @@ This task shows you how to setup request timeouts in Envoy using Istio.
* Initialize the application version routing by running the following command:
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
## Request timeouts
@ -33,7 +33,7 @@ to the `ratings` service.
1. Route requests to v2 of the `reviews` service, i.e., a version that calls the `ratings` service:
{{< text bash >}}
$ cat <<EOF | istioctl replace -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -52,7 +52,7 @@ to the `ratings` service.
1. Add a 2 second delay to calls to the `ratings` service:
{{< text bash >}}
$ cat <<EOF | istioctl replace -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -80,7 +80,7 @@ to the `ratings` service.
1. Now add a half second request timeout for calls to the `reviews` service:
{{< text bash >}}
$ cat <<EOF | istioctl replace -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -134,7 +134,7 @@ the timeout is specified in milliseconds instead of seconds.
* Remove the application routing rules:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
* If you are not planning to explore any follow-on tasks, see the

10
content/docs/tasks/traffic-management/secure-ingress/index.md
View File

@ -76,7 +76,7 @@ with a certificate and a private key. Then you create a `Gateway` definition tha
> The location of the certificate and the private key **must** be `/etc/istio/ingressgateway-certs`, or the gateway will fail to load them.
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@ -101,7 +101,7 @@ with a certificate and a private key. Then you create a `Gateway` definition tha
1. Configure routes for traffic entering via the `Gateway`. Define the same `VirtualService` as in the [Control Ingress Traffic](/docs/tasks/traffic-management/ingress/#configuring-ingress-using-an-istio-gateway) task:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -194,7 +194,7 @@ the server will use to verify its clients. Create the secret `istio-ingressgatew
from, in this case `ca-chain.cert.pem`.
{{< text bash >}}
$ cat <<EOF | istioctl replace -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
@ -329,8 +329,8 @@ In addition to the steps in the previous section, perform the following:
1. Delete the `Gateway` configuration, the `VirtualService`, and the secrets:
{{< text bash >}}
$ istioctl delete gateway httpbin-gateway
$ istioctl delete virtualservice httpbin
$ kubectl delete gateway httpbin-gateway
$ kubectl delete virtualservice httpbin
$ kubectl delete --ignore-not-found=true -n istio-system secret istio-ingressgateway-certs istio-ingressgateway-ca-certs
{{< /text >}}

10
content/docs/tasks/traffic-management/traffic-shifting/index.md
View File

@ -32,7 +32,7 @@ complete the migration by sending %100 of traffic to `reviews:v3`.
each microservice.
{{< text bash >}}
$ istioctl create -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
1. Open the Bookinfo site in your browser. The URL is `http://$GATEWAY_URL/productpage`, where `$GATEWAY_URL` is the External IP address of the ingress, as explained in
@ -46,7 +46,7 @@ the [Bookinfo](/docs/examples/bookinfo/#determining-the-ingress-ip-and-port) doc
1. Transfer 50% of the traffic from `reviews:v1` to `reviews:v3` with the following command:
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml@
{{< /text >}}
Wait a few seconds for the new rules to propagate.
@ -54,7 +54,7 @@ the [Bookinfo](/docs/examples/bookinfo/#determining-the-ingress-ip-and-port) doc
1. Confirm the rule was replaced:
{{< text bash yaml >}}
$ istioctl get virtualservice reviews -o yaml
$ kubectl get virtualservice reviews -o yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
@ -87,7 +87,7 @@ more often.
route 100% of the traffic to `reviews:v3` by applying this virtual service:
{{< text bash >}}
$ istioctl replace -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-v3.yaml@
{{< /text >}}
Now when you refresh the `/productpage` you will always see book reviews
@ -107,7 +107,7 @@ article [Canary Deployments using Istio](/blog/2017/0.1-canary/).
1. Remove the application routing rules:
{{< text bash >}}
$ istioctl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
{{< /text >}}
1. If you are not planning to explore any follow-on tasks, refer to the

2
content/help/faq/security/accessing-non-istio-services.md
View File

@ -8,7 +8,7 @@ This includes the Kubernetes API server, as well as any non-Istio services in th
sidecar, you need to set a destination rule to exempt the service. For example:
{{< text bash >}}
$ cat <<EOF | istioctl create -f -
$ cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:

4
content/help/faq/setup/consul-unset-context.md
View File

@ -1,8 +1,8 @@
---
title: Consul - How do I unset the context changed by istioctl at the end?
title: Consul - How do I unset the context changed by kubectl at the end?
weight: 50
---
Your `kubectl` is switched to use the Istio context at the end of the `istio context-create` command.
Your `kubectl` is switched to use the Istio context at the end of the `kubectl use-context istio` command.
You can use `kubectl config get-contexts` to obtain the list of contexts and
`kubectl config use-context {desired-context}` to switch to use your desired context.

2
content/help/faq/traffic-management/viewing-current-rules.md
View File

@ -3,4 +3,4 @@ title: How can I view the current route rules I have configured with Istio?
weight: 10
---
Rules can be viewed using `istioctl get routerules -o yaml` or `kubectl get routerules -o yaml`.
Rules can be viewed using `kubectl get virtualservice -o yaml`

11
content/help/ops/misc/index.md
View File

@ -11,8 +11,8 @@ When setting route rules to direct traffic to specific versions (subsets) of a s
that the subsets are available before they are used in the routes. Otherwise, calls to the service may return
503 errors during a reconfiguration period.
Creating both the `VirtualServices` and `DestinationRules` that define the corresponding subsets using a single `istioctl`
call (e.g., `istioctl create -f myVirtualServiceAndDestinationRule.yaml` is not sufficient because the
Creating both the `VirtualServices` and `DestinationRules` that define the corresponding subsets using a single `kubectl`
call (e.g., `kubectl apply -f myVirtualServiceAndDestinationRule.yaml` is not sufficient because the
resources propagate (from the configuration server, i.e., Kubernetes API server) to the Pilot instances in an eventually consistent manner. If the
`VirtualService` using the subsets arrives before the `DestinationRule` where the subsets are defined, the Envoy configuration generated by Pilot would refer to non-existent upstream pools, resulting in HTTP 503 errors until all configuration objects are available to Pilot.
@ -20,7 +20,7 @@ To make sure services will have zero down-time when configuring routes with subs
* When adding new subsets:
1. Update `DestinationRules` to add a new subset first, before updating any `VirtualServices` that use it. Apply the rule using istioctl or any platform-specific tooling.
1. Update `DestinationRules` to add a new subset first, before updating any `VirtualServices` that use it. Apply the rule using `kubectl` or any platform-specific tooling.
1. Wait a few seconds for the `DestinationRule` configuration to propagate to the Envoys
@ -467,9 +467,9 @@ scrape Mixer.
## How can I debug issues with the service mesh?
### With istioctl
### With `istioctl`
Istioctl allows you to inspect the current xDS of a given Envoy from its admin interface (locally) or from Pilot using the `proxy-config` or `pc` command.
`istioctl` allows you to inspect the current xDS of a given Envoy from its admin interface (locally) or from Pilot using the `proxy-config` or `pc` command.
For example, to retrieve the configured clusters in an Envoy via the admin interface run the following command:
@ -598,4 +598,3 @@ To find out the envoy version, you can follow below steps:
1. `kubectl exec -it PODNAME -c istio-proxy -n NAMESPACE /bin/bash`
1. `curl localhost:15000/server_info`

2
content/help/ops/security/authorization-restrictive/index.md
View File

@ -7,7 +7,7 @@ weight: 60
When you first enable authorization for a service, all requests are denied by default. After you add one or more authorization policies, then
matching requests should flow through. If all requests continue to be denied, you can try the following:
1. Make sure there is no typo in your policy yaml file. Use `istioctl` instead of `kubectl`, because `istioctl` enforces an additional validation check to prevent errors caused by typos.
1. Make sure there is no typo in your policy yaml file.
1. Avoid enabling authorization for Istio Control Planes Components, including Mixer, Pilot, Ingress. Istio authorization policy is designed for authorizing access to services in Istio Mesh. Enabling it for Istio Control Planes Components may cause unexpected behavior.

4
content_zh/about/notes/1.0/index.md
View File

@ -36,7 +36,7 @@ weight: 92
be configured using [authentication policies](/docs/concepts/security/#authentication-policies).
- **JWT 认证**。我们现在支持可以使用[身份验证策略](/docs/concepts/security/#authentication-policies)配置的 [JWT身份验证](/docs/concepts/security/#authentication)。
## Istioctl
## `istioctl`
- 添加了 [`istioctl authn tls-check`](/docs/reference/commands/istioctl/#istioctl-authn-tls-check) 命令。
@ -56,4 +56,4 @@ weight: 92
- 亚马逊的 EKS 服务尚未实现自动 sidecar 注入。通过使用 [Helm 参数](/docs/setup/kubernetes/helm-install) `--set galley.enabled=false` [手动注入](/docs/setup/kubernetes/sidecar-injection/#manual-sidecar-injection) sidecar 并关闭 galley，可以在亚马逊的 EKS 中使用 Istio。
- 在[多集群部署](/docs/setup/kubernetes/multicluster-install)中，mixer-telemetry 和 mixer-policy 组件不会连接到任何远程集群的 Kubernetes API 端点。这将导致遥测保真度受损，因为与远程集群上的工作负载相关联的一些元数据不完整。
- 当前有 Kubernetes 清单文件可用于独立启用 Citadel 或执行 Citadel 运行状况检查。这些模型还没有通过 Helm 实现。有关详细信息，请参见 [Issue 6922](https://github.com/istio/istio/issues/6922)。
- 当前有 Kubernetes 清单文件可用于独立启用 Citadel 或执行 Citadel 运行状况检查。这些模型还没有通过 Helm 实现。有关详细信息，请参见 [Issue 6922](https://github.com/istio/istio/issues/6922)。

2
content_zh/blog/2018/v1alpha3-routing/index.md
View File

@ -306,7 +306,7 @@ $ istioctl create -f my-second-rule-for-destination-abc.yaml
$ istioctl replace -f my-updated-rules-for-destination-abc.yaml
{{< /text >}}
删除路由规则也使用 istioctl replace 完成，当然删除最后一个路由规则除外（删除最后一个路由规则需要删除 `VirtualService`）。
删除路由规则也使用 `istioctl` replace 完成，当然删除最后一个路由规则除外（删除最后一个路由规则需要删除 `VirtualService`）。
在添加或删除引用服务版本的路由时，需要在该服务相应的 `DestinationRule` 更新 subsets 。 正如你可能猜到的，这也是使用 `istioctl replace` 完成的。

4
content_zh/docs/concepts/traffic-management/index.md
View File

@ -178,7 +178,7 @@ spec:
子集中会指定一或多个标签，用这些标签来区分不同版本的实例。假设在 Kubernetes 上的 Istio 服务网格之中有一个服务，`version: v1` 代表只有标签中包含 "version:v1" 的 Pod 才会收到流量。
规则可以使用 [istioctl 客户端工具](/docs/reference/commands/istioctl/) 进行配置，如果是 Kubernetes 部署，还可以使用 `kubectl` 命令完成同样任务，但是只有 `istioctl` 会在这个过程中对模型进行检查，所以我们推荐使用 `istioctl`。在[配置请求路由任务](/docs/tasks/traffic-management/request-routing/)中包含有配置示例。
规则可以使用 [`istioctl` 客户端工具](/docs/reference/commands/istioctl/) 进行配置，如果是 Kubernetes 部署，还可以使用 `kubectl` 命令完成同样任务，但是只有 `istioctl` 会在这个过程中对模型进行检查，所以我们推荐使用 `istioctl`。在[配置请求路由任务](/docs/tasks/traffic-management/request-routing/)中包含有配置示例。
Istio 中包含有四种流量管理配置资源，分别是 `VirtualService`、`DestinationRule`、`ServiceEntry`、以及 `Gateway`。下面会讲一下这几个资源的一些重点。在[网络参考](/docs/reference/config/istio.networking.v1alpha3/)中可以获得更多这方面的信息。
@ -697,5 +697,3 @@ spec:
在 [Ingress 任务](/docs/tasks/traffic-management/ingress/) 中有完整的 Ingress Gateway 例子。
虽然主要用于管理 Ingress 流量，`Gateway` 还可以用在纯粹的内部服务之间或者 egress 场景下使用。不管处于什么位置，所有的网关都可以以同样的方式进行配置和控制。[Gateway 参考](/docs/reference/config/istio.networking.v1alpha3/#Gateway) 中包含更多细节描述。

2
content_zh/docs/setup/kubernetes/quick-start/index.md
View File

@ -320,7 +320,7 @@ $ kubectl label namespace <namespace> istio-injection=enabled
$ kubectl create -n <namespace> -f <your-app-spec>.yaml
{{< /text >}}
如果您没有安装 Istio-initializer-injector 的话，您必须使用 [istioctl kube-inject](/docs/reference/commands/istioctl/#istioctl-kube-inject) 命令在部署应用之前向应用程序的 Pod 中手动注入 Envoy 容器：
如果您没有安装 Istio-initializer-injector 的话，您必须使用 [`istioctl kube-inject`](/docs/reference/commands/istioctl/#istioctl-kube-inject) 命令在部署应用之前向应用程序的 Pod 中手动注入 Envoy 容器：
{{< text bash >}}
$ kubectl create -f <(istioctl kube-inject -f <your-app-spec>.yaml)

4
content_zh/docs/tasks/traffic-management/egress/index.md
View File

@ -95,7 +95,7 @@ keywords: [traffic-management,egress]
### 为外部服务设置路由规则
通过 `ServiceEntry` 访问外部服务的流量，和网格内流量类似，都可以进行 Istio [路由规则](/docs/concepts/traffic-management/#rule-configuration) 的配置。下面我们使用 [istioctl](/docs/reference/commands/istioctl/) 为 httpbin.org 服务设置一个超时规则。
通过 `ServiceEntry` 访问外部服务的流量，和网格内流量类似，都可以进行 Istio [路由规则](/docs/concepts/traffic-management/#rule-configuration) 的配置。下面我们使用 [`istioctl`](/docs/reference/commands/istioctl/) 为 httpbin.org 服务设置一个超时规则。
1. 在测试 Pod 内部，调用 httpbin.org 这一外部服务的 `/delay` 端点：
@ -245,4 +245,4 @@ $ kubectl exec -it $SOURCE_POD -c sleep curl http://httpbin.org/headers
{{< text bash >}}
$ helm template install/kubernetes/helm/istio <安装 Istio 时所使用的参数> -x templates/sidecar-injector-configmap.yaml | kubectl apply -f -
{{< /text >}}
{{< /text >}}