mirror of https://github.com/istio/istio.io.git
Automator: update istio.io@ reference docs (#14739)
This commit is contained in:
Istio Automation
GitHub
parent
5113461412
commit
eb912e6aeb
|
|
@ -696,7 +696,7 @@ These environment variables affect the behavior of the <code>install-cni</code>
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -778,6 +778,12 @@ These environment variables affect the behavior of the <code>install-cni</code>
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENVOY_USER</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio-proxy</code></td>
|
||||
|
|
@ -834,7 +840,7 @@ These environment variables affect the behavior of the <code>install-cni</code>
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -926,12 +932,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, istiod will skip verifying the certificate of the JWKS server.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_POLICY</code></td>
|
||||
<td>String</td>
|
||||
<td><code>third-party-jwt</code></td>
|
||||
<td>The JWT validation policy.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>KUBECFG_FILE_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>ZZZ-istio-cni-kubeconfig</code></td>
|
||||
|
|
@ -1016,12 +1016,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NODE_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -1172,12 +1166,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -1292,6 +1280,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1430,12 +1430,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>POD_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -18,10 +18,86 @@ remove_toc_prefix: 'operator '
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -40,10 +116,86 @@ See each sub-command's help for details on how to use the generated script.
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -73,14 +225,90 @@ If it is not installed already, you can install it via your OS's package man
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -105,14 +333,90 @@ If it is not installed already, you can install it via your OS's package man
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -136,14 +440,90 @@ to your powershell profile.
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -174,14 +554,90 @@ to enable it. You can execute the following once:</p>
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -200,6 +656,26 @@ to enable it. You can execute the following once:</p>
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--ctrlz_address <string></code></td>
|
||||
<td>The IP Address to listen on for the ControlZ introspection facility. Use '*' to indicate all addresses. (default `localhost`)</td>
|
||||
</tr>
|
||||
|
|
@ -208,10 +684,22 @@ to enable it. You can execute the following once:</p>
|
|||
<td>The IP port to use for the ControlZ introspection facility (default `9876`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--force</code></td>
|
||||
<td>Proceed even with validation errors. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
|
|
@ -221,11 +709,11 @@ to enable it. You can execute the following once:</p>
|
|||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_caller <string></code></td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] (default ``)</td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, krt, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_output_level <string></code></td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, krt, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_rotate <string></code></td>
|
||||
|
|
@ -245,7 +733,7 @@ to enable it. You can execute the following once:</p>
|
|||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_stacktrace_level <string></code></td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, krt, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_target <stringArray></code></td>
|
||||
|
|
@ -256,6 +744,10 @@ to enable it. You can execute the following once:</p>
|
|||
<td>Defines the concurrency limit for operator to reconcile IstioOperatorSpec in parallel. Default value is 1. (default `1`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--monitoring-host <string></code></td>
|
||||
<td>HTTP host to use for operator's self-monitoring information (default `0.0.0.0`)</td>
|
||||
</tr>
|
||||
|
|
@ -264,6 +756,46 @@ to enable it. You can execute the following once:</p>
|
|||
<td>HTTP port to use for operator's self-monitoring information (default `8383`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -283,21 +815,116 @@ to enable it. You can execute the following once:</p>
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--output <string></code></td>
|
||||
<td><code>-o</code></td>
|
||||
<td>One of 'yaml' or 'json'. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--short</code></td>
|
||||
<td><code>-s</code></td>
|
||||
<td>Use --short=false to generate full version information </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
|
|
@ -373,7 +1000,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -461,6 +1088,12 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>EXTERNAL_ISTIOD</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -511,7 +1144,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -615,12 +1248,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, istiod will skip verifying the certificate of the JWKS server.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_POLICY</code></td>
|
||||
<td>String</td>
|
||||
<td><code>third-party-jwt</code></td>
|
||||
<td>The JWT validation policy.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>K_REVISION</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -669,12 +1296,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PERSIST_OLDEST_FIRST_HEURISTIC_FOR_VIRTUAL_SERVICE_HOST_MATCHING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -819,12 +1440,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -939,6 +1554,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1077,12 +1704,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PLATFORM</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
|
|||
|
|
@ -543,11 +543,6 @@ to enable it. You can execute the following once:</p>
|
|||
<td>Insert tracing logs for each iptables rules, using the LOG chain. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--iptables-version <string></code></td>
|
||||
<td></td>
|
||||
<td>version of iptables command. If not set, this is automatically detected. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--istio-exclude-interfaces <string></code></td>
|
||||
<td><code>-c</code></td>
|
||||
<td>Comma separated list of NIC (optional). Neither inbound nor outbound traffic will be captured. (default ``)</td>
|
||||
|
|
@ -1136,7 +1131,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -1224,6 +1219,12 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENVOY_PROMETHEUS_PORT</code></td>
|
||||
<td>Integer</td>
|
||||
<td><code>15090</code></td>
|
||||
|
|
@ -1376,7 +1377,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -1576,12 +1577,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>OUTPUT_CERTS</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -1738,12 +1733,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -1858,6 +1847,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1996,12 +1997,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PKCS8_KEY</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
|
|||
|
|
@ -269,12 +269,12 @@ to enable it. You can execute the following once:</p>
|
|||
<tr>
|
||||
<td><code>--log_caller <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] (default ``)</td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, krt, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_output_level <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, krt, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_rotate <string></code></td>
|
||||
|
|
@ -299,7 +299,7 @@ to enable it. You can execute the following once:</p>
|
|||
<tr>
|
||||
<td><code>--log_stacktrace_level <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, krt, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_target <stringArray></code></td>
|
||||
|
|
@ -535,7 +535,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -623,6 +623,12 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>EXTERNAL_CA</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -709,7 +715,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -813,12 +819,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, istiod will skip verifying the certificate of the JWKS server.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_POLICY</code></td>
|
||||
<td>String</td>
|
||||
<td><code>third-party-jwt</code></td>
|
||||
<td>The JWT validation policy.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_RULE</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -897,12 +897,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PERSIST_OLDEST_FIRST_HEURISTIC_FOR_VIRTUAL_SERVICE_HOST_MATCHING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1047,12 +1041,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -1167,6 +1155,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1305,12 +1305,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PLATFORM</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
|
|||
|
|
@ -28,7 +28,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of configuration analysis message codes to suppress when Istio analyzers are run. For example, to suppress reporting of IST0103 (PodMissingProxy) and IST0108 (UnknownAnnotation) on a resource, apply the annotation 'galley.istio.io/analyze-suppress=IST0108,IST0103'. If the value is '*', then all configuration analysis messages are suppressed.</td>
|
||||
<td><p>A comma separated list of configuration analysis message codes to suppress when Istio analyzers are run. For example, to suppress reporting of IST0103 (PodMissingProxy) and IST0108 (UnknownAnnotation) on a resource, apply the annotation ‘galley.istio.io/analyze-suppress=IST0108,IST0103’. If the value is ‘*’, then all configuration analysis messages are suppressed.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -49,7 +50,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>The name of the inject template(s) to use, as a comma separate list. See https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#custom-templates-experimental for more information.</td>
|
||||
<td><p>The name of the inject template(s) to use, as a comma separate list. See <a href="/docs/setup/additional-setup/sidecar-injection/#custom-templates-experimental" target="_blank">https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#custom-templates-experimental</a> for more information.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -70,7 +72,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Represents the name of the chart used to create this resource.</td>
|
||||
<td><p>Represents the name of the chart used to create this resource.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -91,7 +94,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Represents the generation to which the resource was last reconciled.</td>
|
||||
<td><p>Represents the generation to which the resource was last reconciled.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -112,7 +116,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Represents the Istio version associated with the resource</td>
|
||||
<td><p>Represents the Istio version associated with the resource</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -133,7 +138,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not the given resource is in dry-run mode. See https://istio.io/latest/docs/tasks/security/authorization/authz-dry-run/ for more information.</td>
|
||||
<td><p>Specifies whether or not the given resource is in dry-run mode. See <a href="/docs/tasks/security/authorization/authz-dry-run/" target="_blank">https://istio.io/latest/docs/tasks/security/authorization/authz-dry-run/</a> for more information.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -154,7 +160,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies a control plane revision to which a given proxy is connected. This annotation is added automatically, not set by a user. In contrary to the label istio.io/rev, it represents the actual revision, not the requested revision.</td>
|
||||
<td><p>Specifies a control plane revision to which a given proxy is connected. This annotation is added automatically, not set by a user. In contrary to the label istio.io/rev, it represents the actual revision, not the requested revision.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -175,7 +182,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Annotation on an Ingress resources denoting the class of controllers responsible for it.</td>
|
||||
<td><p>Annotation on an Ingress resources denoting the class of controllers responsible for it.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -196,7 +204,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the namespaces to which this service should be exported to. A value of '*' indicates it is reachable within the mesh '.' indicates it is reachable within its namespace.</td>
|
||||
<td><p>Specifies the namespaces to which this service should be exported to. A value of ‘*’ indicates it is reachable within the mesh ‘.’ indicates it is reachable within its namespace.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -217,7 +226,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies if application Prometheus metric will be merged with Envoy metrics for this workload.</td>
|
||||
<td><p>Specifies if application Prometheus metric will be merged with Envoy metrics for this workload.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -238,7 +248,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Overrides for the proxy configuration for this specific proxy. Available options can be found at https://istio.io/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig.</td>
|
||||
<td><p>Overrides for the proxy configuration for this specific proxy. Available options can be found at <a href="/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig" target="_blank">https://istio.io/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig</a>.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -259,7 +270,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the list of ports exposed by the application container. Used by the Envoy sidecar readiness probe to determine that Envoy is configured and ready to receive traffic.</td>
|
||||
<td><p>Specifies the list of ports exposed by the application container. Used by the Envoy sidecar readiness probe to determine that Envoy is configured and ready to receive traffic.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -280,7 +292,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the failure threshold for the Envoy sidecar readiness probe.</td>
|
||||
<td><p>Specifies the failure threshold for the Envoy sidecar readiness probe.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -301,7 +314,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the initial delay (in seconds) for the Envoy sidecar readiness probe.</td>
|
||||
<td><p>Specifies the initial delay (in seconds) for the Envoy sidecar readiness probe.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -322,7 +336,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the period (in seconds) for the Envoy sidecar readiness probe.</td>
|
||||
<td><p>Specifies the period (in seconds) for the Envoy sidecar readiness probe.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -343,7 +358,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the log output level for pilot-agent.</td>
|
||||
<td><p>Specifies the log output level for pilot-agent.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -364,7 +380,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies an alternative Envoy bootstrap configuration file.</td>
|
||||
<td><p>Specifies an alternative Envoy bootstrap configuration file.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -385,7 +402,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the component log level for Envoy.</td>
|
||||
<td><p>Specifies the component log level for Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -406,7 +424,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the auth policy used by the Istio control plane. If NONE, traffic will not be encrypted. If MUTUAL_TLS, traffic between Envoy sidecar will be wrapped into mutual TLS connections.</td>
|
||||
<td><p>Specifies the auth policy used by the Istio control plane. If NONE, traffic will not be encrypted. If MUTUAL_TLS, traffic between Envoy sidecar will be wrapped into mutual TLS connections.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -427,7 +446,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the XDS discovery address to be used by the Envoy sidecar.</td>
|
||||
<td><p>Specifies the XDS discovery address to be used by the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -448,7 +468,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not an Envoy sidecar should enable core dump.</td>
|
||||
<td><p>Specifies whether or not an Envoy sidecar should enable core dump.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -469,7 +490,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>An additional list of tags to extract from the in-proxy Istio Wasm telemetry. Each additional tag needs to be present in this list.</td>
|
||||
<td><p>An additional list of tags to extract from the in-proxy Istio Wasm telemetry. Each additional tag needs to be present in this list.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -490,7 +512,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not an Envoy sidecar should be automatically injected into the workload. Deprecated in favor of `sidecar.istio.io/inject` label.</td>
|
||||
<td><p>Specifies whether or not an Envoy sidecar should be automatically injected into the workload. Deprecated in favor of <code>sidecar.istio.io/inject</code> label.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -511,7 +534,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the mode used to redirect inbound connections to Envoy (REDIRECT or TPROXY).</td>
|
||||
<td><p>Specifies the mode used to redirect inbound connections to Envoy (REDIRECT or TPROXY).</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -532,7 +556,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the log level for Envoy.</td>
|
||||
<td><p>Specifies the log level for Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -553,7 +578,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the requested CPU setting for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the requested CPU setting for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -574,7 +600,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the CPU limit for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the CPU limit for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -595,7 +622,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the Docker image to be used by the Envoy sidecar.</td>
|
||||
<td><p>Specifies the Docker image to be used by the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -616,7 +644,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the Docker image type to be used by the Envoy sidecar. Istio publishes debug and distroless image types for every release tag.</td>
|
||||
<td><p>Specifies the Docker image type to be used by the Envoy sidecar. Istio publishes debug and distroless image types for every release tag.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -637,7 +666,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the requested memory setting for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the requested memory setting for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -658,7 +688,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the memory limit for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the memory limit for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -679,7 +710,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Rewrite HTTP readiness and liveness probes to be redirected to the Envoy sidecar.</td>
|
||||
<td><p>Rewrite HTTP readiness and liveness probes to be redirected to the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -700,7 +732,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the custom histogram buckets with a prefix matcher to separate the Istio mesh metrics from the Envoy stats, e.g. `{"istiocustom":[1,5,10,50,100,500,1000,5000,10000],"cluster.xds-grpc":[1,5,10,25,50,100,250,500,1000,2500,5000,10000]}`. Default buckets are `[0.5,1,5,10,25,50,100,250,500,1000,2500,5000,10000,30000,60000,300000,600000,1800000,3600000]`.</td>
|
||||
<td><p>Specifies the custom histogram buckets with a prefix matcher to separate the Istio mesh metrics from the Envoy stats, e.g. <code>{"istiocustom":[1,5,10,50,100,500,1000,5000,10000],"cluster.xds-grpc":[1,5,10,25,50,100,250,500,1000,2500,5000,10000]}</code>. Default buckets are <code>[0.5,1,5,10,25,50,100,250,500,1000,2500,5000,10000,30000,60000,300000,600000,1800000,3600000]</code>.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -721,7 +754,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the comma separated list of prefixes of the stats to be emitted by Envoy.</td>
|
||||
<td><p>Specifies the comma separated list of prefixes of the stats to be emitted by Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -742,7 +776,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the comma separated list of regexes the stats should match to be emitted by Envoy.</td>
|
||||
<td><p>Specifies the comma separated list of regexes the stats should match to be emitted by Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -763,7 +798,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the comma separated list of suffixes of the stats to be emitted by Envoy.</td>
|
||||
<td><p>Specifies the comma separated list of suffixes of the stats to be emitted by Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -784,7 +820,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Generated by Envoy sidecar injection that indicates the status of the operation. Includes a version hash of the executed template, as well as names of injected resources.</td>
|
||||
<td><p>Generated by Envoy sidecar injection that indicates the status of the operation. Includes a version hash of the executed template, as well as names of injected resources.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -805,7 +842,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies one or more user volumes (as a JSON array) to be added to the Envoy sidecar.</td>
|
||||
<td><p>Specifies one or more user volumes (as a JSON array) to be added to the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -826,7 +864,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies one or more user volume mounts (as a JSON array) to be added to the Envoy sidecar.</td>
|
||||
<td><p>Specifies one or more user volume mounts (as a JSON array) to be added to the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -847,7 +886,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the HTTP status Port for the Envoy sidecar. If zero, the sidecar will not provide status.</td>
|
||||
<td><p>Specifies the HTTP status Port for the Envoy sidecar. If zero, the sidecar will not provide status.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -868,7 +908,162 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma-separated list of clusters (or * for any) running istiod that should attempt leader election for a remote cluster thats system namespace includes this annotation. Istiod will not attempt to lead unannotated remote clusters.</td>
|
||||
<td><p>A comma-separated list of clusters (or * for any) running istiod that should attempt leader election for a remote cluster thats system namespace includes this annotation. Istiod will not attempt to lead unannotated remote clusters.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeInboundPorts">traffic.istio.io/excludeInboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeInboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of inbound ports to be excluded from redirection to Envoy. Only applies when all inbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeInterfaces">traffic.istio.io/excludeInterfaces</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeInterfaces</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of interfaces to be excluded from Istio traffic capture</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeOutboundIPRanges">traffic.istio.io/excludeOutboundIPRanges</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeOutboundIPRanges</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to be excluded from redirection. Only applies when all outbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeOutboundPorts">traffic.istio.io/excludeOutboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeOutboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of outbound ports to be excluded from redirection to Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficIncludeInboundPorts">traffic.istio.io/includeInboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/includeInboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of inbound ports for which traffic is to be redirected to Envoy. The wildcard character ‘*’ can be used to configure redirection for all ports. An empty list will disable all inbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficIncludeOutboundIPRanges">traffic.istio.io/includeOutboundIPRanges</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/includeOutboundIPRanges</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to redirect to Envoy (optional). The wildcard character ‘*’ can be used to redirect all outbound traffic. An empty list will disable all outbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficIncludeOutboundPorts">traffic.istio.io/includeOutboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/includeOutboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of outbound ports for which traffic is to be redirected to Envoy, regardless of the destination IP.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -889,7 +1084,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>This annotation is a set of node-labels (key1=value,key2=value). If the annotated Service is of type NodePort and is a multi-network gateway (see topology.istio.io/network), the addresses for selected nodes will be used for cross-network communication.</td>
|
||||
<td><p>This annotation is a set of node-labels (key1=value,key2=value). If the annotated Service is of type NodePort and is a multi-network gateway (see topology.istio.io/network), the addresses for selected nodes will be used for cross-network communication.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -910,7 +1106,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of inbound ports to be excluded from redirection to Envoy. Only applies when all inbound traffic (i.e. '*') is being redirected.</td>
|
||||
<td><p>A comma separated list of inbound ports to be excluded from redirection to Envoy. Only applies when all inbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -931,7 +1128,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of interfaces to be excluded from Istio traffic capture</td>
|
||||
<td><p>A comma separated list of interfaces to be excluded from Istio traffic capture</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -952,7 +1150,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of IP ranges in CIDR form to be excluded from redirection. Only applies when all outbound traffic (i.e. '*') is being redirected.</td>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to be excluded from redirection. Only applies when all outbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -973,7 +1172,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of outbound ports to be excluded from redirection to Envoy.</td>
|
||||
<td><p>A comma separated list of outbound ports to be excluded from redirection to Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -994,7 +1194,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of inbound ports for which traffic is to be redirected to Envoy. The wildcard character '*' can be used to configure redirection for all ports. An empty list will disable all inbound redirection.</td>
|
||||
<td><p>A comma separated list of inbound ports for which traffic is to be redirected to Envoy. The wildcard character ‘*’ can be used to configure redirection for all ports. An empty list will disable all inbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -1015,7 +1216,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of IP ranges in CIDR form to redirect to Envoy (optional). The wildcard character '*' can be used to redirect all outbound traffic. An empty list will disable all outbound redirection.</td>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to redirect to Envoy (optional). The wildcard character ‘*’ can be used to redirect all outbound traffic. An empty list will disable all outbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -1036,7 +1238,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of outbound ports for which traffic is to be redirected to Envoy, regardless of the destination IP.</td>
|
||||
<td><p>A comma separated list of outbound ports for which traffic is to be redirected to Envoy, regardless of the destination IP.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -1057,7 +1260,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of virtual interfaces whose inbound traffic (from VM) will be treated as outbound.</td>
|
||||
<td><p>A comma separated list of virtual interfaces whose inbound traffic (from VM) will be treated as outbound.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -7,7 +7,7 @@ location: https://istio.io/docs/reference/config/istio.mesh.v1alpha1.html
|
|||
layout: protoc-gen-docs
|
||||
generator: protoc-gen-docs
|
||||
weight: 20
|
||||
number_of_entries: 66
|
||||
number_of_entries: 73
|
||||
---
|
||||
<p>Configuration affecting the service mesh as a whole.</p>
|
||||
|
||||
|
|
@ -243,6 +243,19 @@ monitored. Can be overridden at a Sidecar level by setting the
|
|||
API</a>.
|
||||
Default mode is <code>ALLOW_ANY</code> which means outbound traffic to unknown destinations will be allowed.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-inbound_traffic_policy">
|
||||
<td><code>inboundTrafficPolicy</code></td>
|
||||
<td><code><a href="#MeshConfig-InboundTrafficPolicy">InboundTrafficPolicy</a></code></td>
|
||||
<td>
|
||||
<p>Set the default behavior of the sidecar for handling inbound
|
||||
traffic to the application. If your application listens on
|
||||
localhost, you will need to set this to <code>LOCALHOST</code>.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -725,6 +738,30 @@ No
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-InboundTrafficPolicy">MeshConfig.InboundTrafficPolicy</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-InboundTrafficPolicy-mode">
|
||||
<td><code>mode</code></td>
|
||||
<td><code><a href="#MeshConfig-InboundTrafficPolicy-Mode">Mode</a></code></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-CertificateData">MeshConfig.CertificateData</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
|
|
@ -1352,17 +1389,6 @@ No
|
|||
<p>Sets the HTTP status that is returned to the client when there is a network error to the authorization service.
|
||||
The default status is “403” (HTTP Forbidden).</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-EnvoyExternalAuthorizationHttpProvider-include_headers_in_check">
|
||||
<td><code>includeHeadersInCheck</code></td>
|
||||
<td><code>string[]</code></td>
|
||||
<td>
|
||||
<p>DEPRECATED. Use include_request_headers_in_check instead.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -1482,6 +1508,17 @@ except the presence match):</p>
|
|||
<li>Suffix match: “*abc” will match on value “abc” and “xabc”.</li>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-EnvoyExternalAuthorizationHttpProvider-include_headers_in_check" class="deprecated ">
|
||||
<td><code>includeHeadersInCheck</code></td>
|
||||
<td><code>string[]</code></td>
|
||||
<td>
|
||||
<p>DEPRECATED. Use include_request_headers_in_check instead.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -2280,6 +2317,208 @@ No
|
|||
<p>Optional. Controls the overall path length allowed in a reported span.
|
||||
NOTE: currently only controls max length of the path tag.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-OpenTelemetryTracingProvider-http">
|
||||
<td><code>http</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-HttpService">HttpService</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Specifies the configuration for exporting OTLP traces via HTTP.
|
||||
When empty, traces will be exported via gRPC.</p>
|
||||
<p>The following example shows how to configure the OpenTelemetry ExtensionProvider to export via HTTP:</p>
|
||||
<ol>
|
||||
<li>Add/change the OpenTelemetry extension provider in <code>MeshConfig</code></li>
|
||||
</ol>
|
||||
<pre><code class="language-yaml">- name: otel-tracing
|
||||
opentelemetry:
|
||||
port: 443
|
||||
service: my.olly-backend.com
|
||||
http:
|
||||
path: "/api/otlp/traces"
|
||||
timeout: 10s
|
||||
headers:
|
||||
- name: "my-custom-header"
|
||||
value: "some value"
|
||||
</code></pre>
|
||||
<ol start="2">
|
||||
<li>Deploy a <code>ServiceEntry</code> for the observability back-end</li>
|
||||
</ol>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: my-olly-backend
|
||||
spec:
|
||||
hosts:
|
||||
- my.olly-backend.com
|
||||
ports:
|
||||
- number: 443
|
||||
name: https-port
|
||||
protocol: HTTPS
|
||||
resolution: DNS
|
||||
location: MESH_EXTERNAL
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: my-olly-backend
|
||||
spec:
|
||||
host: my.olly-backend.com
|
||||
trafficPolicy:
|
||||
portLevelSettings:
|
||||
- port:
|
||||
number: 443
|
||||
tls:
|
||||
mode: SIMPLE
|
||||
</code></pre>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-OpenTelemetryTracingProvider-resource_detectors">
|
||||
<td><code>resourceDetectors</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-ResourceDetectors">ResourceDetectors</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Specifies <a href="https://opentelemetry.io/docs/specs/otel/resource/sdk/">Resource Detectors</a>
|
||||
to be used by the OpenTelemetry Tracer. When multiple resources are provided, they are merged
|
||||
according to the OpenTelemetry <a href="https://opentelemetry.io/docs/specs/otel/resource/sdk/#merge">Resource specification</a>.</p>
|
||||
<p>The following example shows how to configure the Environment Resource Detector, that will
|
||||
read the attributes from the environment variable <code>OTEL_RESOURCE_ATTRIBUTES</code>:</p>
|
||||
<pre><code class="language-yaml">- name: otel-tracing
|
||||
opentelemetry:
|
||||
port: 443
|
||||
service: my.olly-backend.com
|
||||
resource_detectors:
|
||||
environment: {}
|
||||
</code></pre>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-HttpService">MeshConfig.ExtensionProvider.HttpService</h2>
|
||||
<section>
|
||||
<p>Defines configuration for an HTTP service that can be used by an Extension Provider.
|
||||
that does communication via HTTP.</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpService-path">
|
||||
<td><code>path</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>REQUIRED. Specifies the path on the service.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpService-timeout">
|
||||
<td><code>timeout</code></td>
|
||||
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">Duration</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Specifies the timeout for the HTTP request.
|
||||
If not specified, the default is 3s.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpService-headers">
|
||||
<td><code>headers</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-HttpHeader">HttpHeader[]</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Allows specifying custom HTTP headers that will be added
|
||||
to each HTTP request sent.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-HttpHeader">MeshConfig.ExtensionProvider.HttpHeader</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpHeader-name">
|
||||
<td><code>name</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>REQUIRED. The HTTP header name.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpHeader-value">
|
||||
<td><code>value</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>REQUIRED. The HTTP header value.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-ResourceDetectors">MeshConfig.ExtensionProvider.ResourceDetectors</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-ExtensionProvider-ResourceDetectors-environment">
|
||||
<td><code>environment</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-ResourceDetectors-EnvironmentResourceDetector">EnvironmentResourceDetector</a></code></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-ResourceDetectors-dynatrace">
|
||||
<td><code>dynatrace</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-ResourceDetectors-DynatraceResourceDetector">DynatraceResourceDetector</a></code></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -2422,6 +2661,22 @@ No
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-ResourceDetectors-EnvironmentResourceDetector">MeshConfig.ExtensionProvider.ResourceDetectors.EnvironmentResourceDetector</h2>
|
||||
<section>
|
||||
<p>OpenTelemetry Environment Resource Detector.
|
||||
The resource detector reads attributes from the environment variable <code>OTEL_RESOURCE_ATTRIBUTES</code>
|
||||
and adds them to the OpenTelemetry resource.</p>
|
||||
<p>See: <a href="https://opentelemetry.io/docs/specs/otel/resource/sdk/#specifying-resource-information-via-an-environment-variable">Resource specification</a></p>
|
||||
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-ResourceDetectors-DynatraceResourceDetector">MeshConfig.ExtensionProvider.ResourceDetectors.DynatraceResourceDetector</h2>
|
||||
<section>
|
||||
<p>Dynatrace Resource Detector.
|
||||
The resource detector reads from the Dynatrace enrichment files
|
||||
and adds host/process related attributes to the OpenTelemetry resource.</p>
|
||||
<p>See: <a href="https://docs.dynatrace.com/docs/shortlink/enrichment-files">Enrich ingested data with Dynatrace-specific dimensions</a></p>
|
||||
|
||||
</section>
|
||||
<h2 id="k8s-io-apimachinery-pkg-apis-meta-v1-LabelSelector">k8s.io.apimachinery.pkg.apis.meta.v1.LabelSelector</h2>
|
||||
<section>
|
||||
|
|
@ -3958,6 +4213,35 @@ service registry as well as those defined through ServiceEntries</p>
|
|||
<p>outbound traffic to unknown destinations will be allowed, in case
|
||||
there are no services or ServiceEntries for the destination port</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-InboundTrafficPolicy-Mode">MeshConfig.InboundTrafficPolicy.Mode</h2>
|
||||
<section>
|
||||
<table class="enum-values">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-InboundTrafficPolicy-Mode-PASSTHROUGH">
|
||||
<td><code>PASSTHROUGH</code></td>
|
||||
<td>
|
||||
<p>inbound traffic will be passed through to the destination listening
|
||||
on Pod IP. This matches the behavior without Istio enabled at all
|
||||
allowing proxy to be transparent.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-InboundTrafficPolicy-Mode-LOCALHOST">
|
||||
<td><code>LOCALHOST</code></td>
|
||||
<td>
|
||||
<p>inbound traffic will be sent to the destinations listening on localhost.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
|
|
@ -28,7 +28,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Istio control plane revision associated with the resource; e.g. `canary`</td>
|
||||
<td><p>Istio control plane revision associated with the resource; e.g. <code>canary</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -49,7 +50,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>IstioGatewayPortLabel overrides the default 15443 value to use for a multi-network gateway's port</td>
|
||||
<td><p>IstioGatewayPortLabel overrides the default 15443 value to use for a multi-network gateway’s port</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -70,7 +72,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>The name of the canonical service a workload belongs to</td>
|
||||
<td><p>The name of the canonical service a workload belongs to</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -91,7 +94,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>The name of a revision within a canonical service that the workload belongs to</td>
|
||||
<td><p>The name of a revision within a canonical service that the workload belongs to</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -112,7 +116,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not an Envoy sidecar should be automatically injected into the workload.</td>
|
||||
<td><p>Specifies whether or not an Envoy sidecar should be automatically injected into the workload.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -133,7 +138,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>This label is applied to a workload internally that identifies the Kubernetes cluster containing the workload. The cluster ID is specified during Istio installation for each cluster via `values.global.multiCluster.clusterName`. It should be noted that this is only used internally within Istio and is not an actual label on workload pods. If a pod contains this label, it will be overridden by Istio internally with the cluster ID specified during Istio installation. This label provides a way to select workloads by cluster when using DestinationRules. For example, a service owner could create a DestinationRule containing a subset per cluster and then use these subsets to control traffic flow to each cluster independently.</td>
|
||||
<td><p>This label is applied to a workload internally that identifies the Kubernetes cluster containing the workload. The cluster ID is specified during Istio installation for each cluster via <code>values.global.multiCluster.clusterName</code>. It should be noted that this is only used internally within Istio and is not an actual label on workload pods. If a pod contains this label, it will be overridden by Istio internally with the cluster ID specified during Istio installation. This label provides a way to select workloads by cluster when using DestinationRules. For example, a service owner could create a DestinationRule containing a subset per cluster and then use these subsets to control traffic flow to each cluster independently.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -154,7 +160,37 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A label used to identify the network for one or more pods. This is used<br>internally by Istio to group pods resident in the same L3 domain/network.<br>Istio assumes that pods in the same network are directly reachable from<br>one another. When pods are in different networks, an Istio Gateway<br>(e.g. east-west gateway) is typically used to establish connectivity<br>(with AUTO_PASSTHROUGH mode). This label can be applied to the following<br>resources to help automate Istio's multi-network configuration.<br><br>* Istio System Namespace: Applying this label to the system namespace<br> establishes a default network for pods managed by the control plane.<br> This is typically configured during control plane installation using an<br> admin-specified value.<br><br>* Pod: Applying this label to a pod allows overriding the default network<br> on a per-pod basis. This is typically applied to the pod via webhook<br> injection, but can also be manually specified on the pod by the service<br> owner. The Istio installation in each cluster configures webhook injection<br> using an admin-specified value.<br><br>* Gateway Service: Applying this label to the Service for an Istio Gateway,<br> indicates that Istio should use this service as the gateway for the<br> network, when configuring cross-network traffic. Istio will configure<br> pods residing outside of the network to access the Gateway service<br> via `spec.externalIPs`, `status.loadBalancer.ingress[].ip`, or in the case<br> of a NodePort service, the Node's address. The label is configured when<br> installing the gateway (e.g. east-west gateway) and should match either<br> the default network for the control plane (as specified by the Istio System<br> Namespace label) or the network of the targeted pods.</td>
|
||||
<td><p>A label used to identify the network for one or more pods. This is used
|
||||
internally by Istio to group pods resident in the same L3 domain/network.
|
||||
Istio assumes that pods in the same network are directly reachable from
|
||||
one another. When pods are in different networks, an Istio Gateway
|
||||
(e.g. east-west gateway) is typically used to establish connectivity
|
||||
(with AUTO_PASSTHROUGH mode). This label can be applied to the following
|
||||
resources to help automate Istio’s multi-network configuration.</p>
|
||||
|
||||
<ul>
|
||||
<li><p>Istio System Namespace: Applying this label to the system namespace
|
||||
establishes a default network for pods managed by the control plane.
|
||||
This is typically configured during control plane installation using an
|
||||
admin-specified value.</p></li>
|
||||
|
||||
<li><p>Pod: Applying this label to a pod allows overriding the default network
|
||||
on a per-pod basis. This is typically applied to the pod via webhook
|
||||
injection, but can also be manually specified on the pod by the service
|
||||
owner. The Istio installation in each cluster configures webhook injection
|
||||
using an admin-specified value.</p></li>
|
||||
|
||||
<li><p>Gateway Service: Applying this label to the Service for an Istio Gateway,
|
||||
indicates that Istio should use this service as the gateway for the
|
||||
network, when configuring cross-network traffic. Istio will configure
|
||||
pods residing outside of the network to access the Gateway service
|
||||
via <code>spec.externalIPs</code>, <code>status.loadBalancer.ingress[].ip</code>, or in the case
|
||||
of a NodePort service, the Node’s address. The label is configured when
|
||||
installing the gateway (e.g. east-west gateway) and should match either
|
||||
the default network for the control plane (as specified by the Istio System
|
||||
Namespace label) or the network of the targeted pods.</p></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -175,7 +211,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>User-provided node label for identifying the locality subzone of a workload. This allows admins to specify a more granular level of locality than what is offered by default with Kubernetes regions and zones.</td>
|
||||
<td><p>User-provided node label for identifying the locality subzone of a workload. This allows admins to specify a more granular level of locality than what is offered by default with Kubernetes regions and zones.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -16,20 +16,6 @@ for load balancing, connection pool size from the sidecar, and outlier
|
|||
detection settings to detect and evict unhealthy hosts from the load
|
||||
balancing pool. For example, a simple load balancing policy for the
|
||||
ratings service would look as follows:</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -40,34 +26,11 @@ spec:
|
|||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Version specific policies can be specified by defining a named
|
||||
<code>subset</code> and overriding the settings specified at the service level. The
|
||||
following rule uses a round robin load balancing policy for all traffic
|
||||
going to a subset named testversion that is composed of endpoints (e.g.,
|
||||
pods) with labels (version:v3).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
subsets:
|
||||
- name: testversion
|
||||
labels:
|
||||
version: v3
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -85,35 +48,12 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p><strong>Note:</strong> Policies specified for subsets will not take effect until
|
||||
a route rule explicitly sends traffic to this subset.</p>
|
||||
<p>Traffic policies can be customized to specific ports as well. The
|
||||
following rule uses the least connection load balancing policy for all
|
||||
traffic to port 80, while uses a round robin load balancing setting for
|
||||
traffic to the port 9080.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings-port
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy: # Apply to all ports
|
||||
portLevelSettings:
|
||||
- port:
|
||||
number: 80
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
- port:
|
||||
number: 9080
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -131,34 +71,9 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Destination Rules can be customized to specific workloads as well.
|
||||
The following example shows how a destination rule can be applied to a
|
||||
specific workload using the workloadSelector configuration.</p>
|
||||
<p>{{<tabset category-name="selector-example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: configure-client-mtls-dr-with-workloadselector
|
||||
spec:
|
||||
host: example.com
|
||||
workloadSelector:
|
||||
matchLabels:
|
||||
app: ratings
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
portLevelSettings:
|
||||
- port:
|
||||
number: 31443
|
||||
tls:
|
||||
credentialName: client-credential
|
||||
mode: MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -178,8 +93,6 @@ spec:
|
|||
credentialName: client-credential
|
||||
mode: MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="DestinationRule">DestinationRule</h2>
|
||||
<section>
|
||||
|
|
@ -398,27 +311,6 @@ service-level can be overridden at a subset-level. The following rule
|
|||
uses a round robin load balancing policy for all traffic going to a
|
||||
subset named testversion that is composed of endpoints (e.g., pods) with
|
||||
labels (version:v3).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
subsets:
|
||||
- name: testversion
|
||||
labels:
|
||||
version: v3
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -436,8 +328,6 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p><strong>Note:</strong> Policies specified for subsets will not take effect until
|
||||
a route rule explicitly sends traffic to this subset.</p>
|
||||
<p>One or more labels are typically required to identify the subset destination,
|
||||
|
|
@ -505,20 +395,6 @@ load balancing
|
|||
for more details.</p>
|
||||
<p>For example, the following rule uses a round robin load balancing policy
|
||||
for all traffic going to the ratings service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -529,28 +405,9 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example sets up sticky sessions for the ratings service
|
||||
hashing-based load balancer for the same ratings service using the
|
||||
the User cookie as the hash key.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
consistentHash:
|
||||
httpCookie:
|
||||
name: user
|
||||
ttl: 0s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -564,8 +421,6 @@ spec:
|
|||
name: user
|
||||
ttl: 0s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -637,25 +492,6 @@ for more details. Connection pool settings can be applied at the TCP
|
|||
level as well as at HTTP level.</p>
|
||||
<p>For example, the following rule sets a limit of 100 connections to redis
|
||||
service called myredissrv with a connect timeout of 30ms</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-redis
|
||||
spec:
|
||||
host: myredissrv.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
connectionPool:
|
||||
tcp:
|
||||
maxConnections: 100
|
||||
connectTimeout: 30ms
|
||||
tcpKeepalive:
|
||||
time: 7200s
|
||||
interval: 75s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -671,8 +507,6 @@ spec:
|
|||
time: 7200s
|
||||
interval: 75s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -725,28 +559,6 @@ with no more than 10 req/connection to the “reviews” service. In add
|
|||
it sets a limit of 1000 concurrent HTTP2 requests and configures upstream
|
||||
hosts to be scanned every 5 mins so that any host that fails 7 consecutive
|
||||
times with a 502, 503, or 504 error code will be ejected for 15 minutes.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-cb-policy
|
||||
spec:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
connectionPool:
|
||||
tcp:
|
||||
maxConnections: 100
|
||||
http:
|
||||
http2MaxRequests: 1000
|
||||
maxRequestsPerConnection: 10
|
||||
outlierDetection:
|
||||
consecutive5xxErrors: 7
|
||||
interval: 5m
|
||||
baseEjectionTime: 15m
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -765,8 +577,6 @@ spec:
|
|||
interval: 5m
|
||||
baseEjectionTime: 15m
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -918,23 +728,6 @@ context</a>
|
|||
for more details. These settings are common to both HTTP and TCP upstreams.</p>
|
||||
<p>For example, the following rule configures a client to use mutual TLS
|
||||
for connections to upstream database cluster.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: db-mtls
|
||||
spec:
|
||||
host: mydbserver.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: MUTUAL
|
||||
clientCertificate: /etc/certs/myclientcert.pem
|
||||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -948,24 +741,8 @@ spec:
|
|||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following rule configures a client to use TLS when talking to a
|
||||
foreign service whose domain matches *.foo.com.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: tls-foo
|
||||
spec:
|
||||
host: "*.foo.com"
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: SIMPLE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -976,24 +753,8 @@ spec:
|
|||
tls:
|
||||
mode: SIMPLE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following rule configures a client to use Istio mutual TLS when talking
|
||||
to rating services.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: ratings-istio-mtls
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: ISTIO_MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -1004,8 +765,6 @@ spec:
|
|||
tls:
|
||||
mode: ISTIO_MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1145,6 +904,21 @@ SAN will be skipped.</p>
|
|||
be <code>true</code> by default in a later version where, going forward, it will be
|
||||
enabled by default.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="ClientTLSSettings-ca_crl">
|
||||
<td><code>caCrl</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>OPTIONAL: The path to the file containing the certificate revocation list (CRL)
|
||||
to use in verifying a presented server certificate. <code>CRL</code> is a list of certificates
|
||||
that have been revoked by the CA (Certificate Authority) before their scheduled expiration date.
|
||||
If specified, the proxy will verify if the presented certificate is part of the revoked list of certificates.
|
||||
If omitted, the proxy will not verify the certificate against the <code>crl</code>.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -1272,6 +1046,7 @@ The following labels which have special semantic meaning are also supported:</p>
|
|||
<li><code>topology.kubernetes.io/region</code> is used to match the region metadata of an endpoint, which maps to Kubernetes node label <code>topology.kubernetes.io/region</code> or the deprecated label <code>failure-domain.beta.kubernetes.io/region</code>.</li>
|
||||
<li><code>topology.kubernetes.io/zone</code> is used to match the zone metadata of an endpoint, which maps to Kubernetes node label <code>topology.kubernetes.io/zone</code> or the deprecated label <code>failure-domain.beta.kubernetes.io/zone</code>.</li>
|
||||
<li><code>topology.istio.io/subzone</code> is used to match the subzone metadata of an endpoint, which maps to Istio node label <code>topology.istio.io/subzone</code>.</li>
|
||||
<li><code>kubernetes.io/hostname</code> is used to match the current node of an endpoint, which maps to Kubernetes node label <code>kubernetes.io/hostname</code>.</li>
|
||||
</ul>
|
||||
<p>The below topology config indicates the following priority levels:</p>
|
||||
<pre><code class="language-yaml">failoverPriority:
|
||||
|
|
|
|||
|
|
@ -20,61 +20,6 @@ as a load balancer exposing port 80 and 9080 (http), 443 (https),
|
|||
applied to the proxy running on a pod with labels <code>app: my-gateway-controller</code>. While Istio will configure the proxy to listen
|
||||
on these ports, it is the responsibility of the user to ensure that
|
||||
external traffic to these ports are allowed into the mesh.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-gateway
|
||||
namespace: some-config-namespace
|
||||
spec:
|
||||
selector:
|
||||
app: my-gateway-controller
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- uk.bookinfo.com
|
||||
- eu.bookinfo.com
|
||||
tls:
|
||||
httpsRedirect: true # sends 301 redirect for http requests
|
||||
- port:
|
||||
number: 443
|
||||
name: https-443
|
||||
protocol: HTTPS
|
||||
hosts:
|
||||
- uk.bookinfo.com
|
||||
- eu.bookinfo.com
|
||||
tls:
|
||||
mode: SIMPLE # enables HTTPS on this port
|
||||
serverCertificate: /etc/certs/servercert.pem
|
||||
privateKey: /etc/certs/privatekey.pem
|
||||
- port:
|
||||
number: 9443
|
||||
name: https-9443
|
||||
protocol: HTTPS
|
||||
hosts:
|
||||
- "bookinfo-namespace/*.bookinfo.com"
|
||||
tls:
|
||||
mode: SIMPLE # enables HTTPS on this port
|
||||
credentialName: bookinfo-secret # fetches certs from Kubernetes secret
|
||||
- port:
|
||||
number: 9080
|
||||
name: http-wildcard
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "*"
|
||||
- port:
|
||||
number: 2379 # to expose internal service via external port 2379
|
||||
name: mongo
|
||||
protocol: MONGO
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -126,8 +71,6 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The Gateway specification above describes the L4-L6 properties of a load
|
||||
balancer. A <code>VirtualService</code> can then be bound to a gateway to control
|
||||
the forwarding of traffic arriving at a particular host or gateway port.</p>
|
||||
|
|
@ -141,46 +84,6 @@ in the qa version. The same rule is also applicable inside the mesh for
|
|||
requests to the “reviews.prod.svc.cluster.local” service. This rule is
|
||||
applicable across ports 443, 9080. Note that <code>http://uk.bookinfo.com</code>
|
||||
gets redirected to <code>https://uk.bookinfo.com</code> (i.e. 80 redirects to 443).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-rule
|
||||
namespace: bookinfo-namespace
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
- uk.bookinfo.com
|
||||
- eu.bookinfo.com
|
||||
gateways:
|
||||
- some-config-namespace/my-gateway
|
||||
- mesh # applies to all the sidecars in the mesh
|
||||
http:
|
||||
- match:
|
||||
- headers:
|
||||
cookie:
|
||||
exact: "user=dev-123"
|
||||
route:
|
||||
- destination:
|
||||
port:
|
||||
number: 7777
|
||||
host: reviews.qa.svc.cluster.local
|
||||
- match:
|
||||
- uri:
|
||||
prefix: /reviews/
|
||||
route:
|
||||
- destination:
|
||||
port:
|
||||
number: 9080 # can be omitted if it's the only port for reviews
|
||||
host: reviews.prod.svc.cluster.local
|
||||
weight: 80
|
||||
- destination:
|
||||
host: reviews.qa.svc.cluster.local
|
||||
weight: 20
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -217,35 +120,10 @@ spec:
|
|||
host: reviews.qa.svc.cluster.local
|
||||
weight: 20
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following VirtualService forwards traffic arriving at (external)
|
||||
port 27017 to internal Mongo server on port 5555. This rule is not
|
||||
applicable internally in the mesh as the gateway list omits the
|
||||
reserved name <code>mesh</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-mongo
|
||||
namespace: bookinfo-namespace
|
||||
spec:
|
||||
hosts:
|
||||
- mongosvr.prod.svc.cluster.local # name of internal Mongo service
|
||||
gateways:
|
||||
- some-config-namespace/my-gateway # can omit the namespace if gateway is in same namespace as virtual service.
|
||||
tcp:
|
||||
- match:
|
||||
- port: 27017
|
||||
route:
|
||||
- destination:
|
||||
host: mongo.prod.svc.cluster.local
|
||||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -265,34 +143,11 @@ spec:
|
|||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is possible to restrict the set of virtual services that can bind to
|
||||
a gateway server using the namespace/hostname syntax in the hosts field.
|
||||
For example, the following Gateway allows any virtual service in the ns1
|
||||
namespace to bind to it, while restricting only the virtual service with
|
||||
foo.bar.com host in the ns2 namespace to bind to it.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-gateway
|
||||
namespace: some-config-namespace
|
||||
spec:
|
||||
selector:
|
||||
app: my-gateway-controller
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "ns1/*"
|
||||
- "ns2/foo.bar.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -310,8 +165,6 @@ spec:
|
|||
- "ns1/*"
|
||||
- "ns2/foo.bar.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="Gateway">Gateway</h2>
|
||||
<section>
|
||||
|
|
@ -368,25 +221,6 @@ No
|
|||
<section>
|
||||
<p><code>Server</code> describes the properties of the proxy on a given load balancer
|
||||
port. For example,</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-ingress
|
||||
spec:
|
||||
selector:
|
||||
app: my-ingressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http2
|
||||
protocol: HTTP2
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -402,28 +236,7 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Another example</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-tcp-ingress
|
||||
spec:
|
||||
selector:
|
||||
app: my-tcp-ingressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 27018
|
||||
name: mongo
|
||||
protocol: MONGO
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -439,31 +252,7 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following is an example of TLS configuration for port 443</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-tls-ingress
|
||||
spec:
|
||||
selector:
|
||||
app: my-tls-ingressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 443
|
||||
name: https
|
||||
protocol: HTTPS
|
||||
hosts:
|
||||
- "*"
|
||||
tls:
|
||||
mode: SIMPLE
|
||||
credentialName: tls-cert
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -482,8 +271,6 @@ spec:
|
|||
mode: SIMPLE
|
||||
credentialName: tls-cert
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -712,6 +499,21 @@ No
|
|||
containing certificate authority certificates to use in verifying a presented
|
||||
client side certificate.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="ServerTLSSettings-ca_crl">
|
||||
<td><code>caCrl</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>OPTIONAL: The path to the file containing the certificate revocation list (CRL)
|
||||
to use in verifying a presented client side certificate. <code>CRL</code> is a list of certificates
|
||||
that have been revoked by the CA (Certificate Authority) before their scheduled expiration date.
|
||||
If specified, the proxy will verify if the presented certificate is part of the revoked list of certificates.
|
||||
If omitted, the proxy will not verify the certificate against the <code>crl</code>.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
|
|||
|
|
@ -28,26 +28,6 @@ services.</p>
|
|||
<p>The following example declares a few external APIs accessed by internal
|
||||
applications over HTTPS. The sidecar inspects the SNI value in the
|
||||
ClientHello message to route to the appropriate external service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-https
|
||||
spec:
|
||||
hosts:
|
||||
- api.dropboxapi.com
|
||||
- www.googleapis.com
|
||||
- api.facebook.com
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 443
|
||||
name: https
|
||||
protocol: TLS
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -64,35 +44,10 @@ spec:
|
|||
protocol: TLS
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following configuration adds a set of MongoDB instances running on
|
||||
unmanaged VMs to Istio’s registry, so that these services can be treated
|
||||
as any other service in the mesh. The associated DestinationRule is used
|
||||
to initiate mTLS connections to the database instances.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-mongocluster
|
||||
spec:
|
||||
hosts:
|
||||
- mymongodb.somedomain # not used
|
||||
addresses:
|
||||
- 192.192.192.192/24 # VIPs
|
||||
ports:
|
||||
- number: 27018
|
||||
name: mongodb
|
||||
protocol: MONGO
|
||||
location: MESH_INTERNAL
|
||||
resolution: STATIC
|
||||
endpoints:
|
||||
- address: 2.2.2.2
|
||||
- address: 3.3.3.3
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -112,26 +67,7 @@ spec:
|
|||
- address: 2.2.2.2
|
||||
- address: 3.3.3.3
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>and the associated DestinationRule</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: mtls-mongocluster
|
||||
spec:
|
||||
host: mymongodb.somedomain
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: MUTUAL
|
||||
clientCertificate: /etc/certs/myclientcert.pem
|
||||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -145,30 +81,9 @@ spec:
|
|||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example uses a combination of service entry and TLS
|
||||
routing in a virtual service to steer traffic based on the SNI value to
|
||||
an internal egress firewall.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-redirect
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
- "*.wikipedia.org"
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 443
|
||||
name: https
|
||||
protocol: TLS
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -184,30 +99,7 @@ spec:
|
|||
protocol: TLS
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated VirtualService to route based on the SNI value.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: tls-routing
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
- "*.wikipedia.org"
|
||||
tls:
|
||||
- match:
|
||||
- sniHosts:
|
||||
- wikipedia.org
|
||||
- "*.wikipedia.org"
|
||||
route:
|
||||
- destination:
|
||||
host: internal-egress-firewall.ns1.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -225,8 +117,6 @@ spec:
|
|||
- destination:
|
||||
host: internal-egress-firewall.ns1.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The virtual service with TLS match serves to override the default SNI
|
||||
match. In the absence of a virtual service, traffic will be forwarded to
|
||||
the wikipedia domains.</p>
|
||||
|
|
@ -237,27 +127,6 @@ declaration to other namespaces in the mesh. By default, a service is exported
|
|||
to all namespaces. The following example restricts the visibility to the
|
||||
current namespace, represented by “.”, so that it cannot be used by other
|
||||
namespaces.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-httpbin
|
||||
namespace : egress
|
||||
spec:
|
||||
hosts:
|
||||
- example.com
|
||||
exportTo:
|
||||
- "."
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -275,29 +144,7 @@ spec:
|
|||
protocol: HTTP
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Define a gateway to handle all egress traffic.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: istio-egressgateway
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
istio: egressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -314,47 +161,12 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated <code>VirtualService</code> to route from the sidecar to the
|
||||
gateway service (<code>istio-egressgateway.istio-system.svc.cluster.local</code>), as
|
||||
well as route from the gateway to the external service. Note that the
|
||||
virtual service is exported to all namespaces enabling them to route traffic
|
||||
through the gateway to the external service. Forcing traffic to go through
|
||||
a managed middle proxy like this is a common practice.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: gateway-routing
|
||||
namespace: egress
|
||||
spec:
|
||||
hosts:
|
||||
- example.com
|
||||
exportTo:
|
||||
- "*"
|
||||
gateways:
|
||||
- mesh
|
||||
- istio-egressgateway
|
||||
http:
|
||||
- match:
|
||||
- port: 80
|
||||
gateways:
|
||||
- mesh
|
||||
route:
|
||||
- destination:
|
||||
host: istio-egressgateway.istio-system.svc.cluster.local
|
||||
- match:
|
||||
- port: 80
|
||||
gateways:
|
||||
- istio-egressgateway
|
||||
route:
|
||||
- destination:
|
||||
host: example.com
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -384,30 +196,10 @@ spec:
|
|||
- destination:
|
||||
host: example.com
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example demonstrates the use of wildcards in the hosts for
|
||||
external services. If the connection has to be routed to the IP address
|
||||
requested by the application (i.e. application resolves DNS and attempts
|
||||
to connect to a specific IP), the resolution mode must be set to <code>NONE</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-wildcard-example
|
||||
spec:
|
||||
hosts:
|
||||
- "*.bar.com"
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -422,31 +214,9 @@ spec:
|
|||
protocol: HTTP
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example demonstrates a service that is available via a
|
||||
Unix Domain Socket on the host of the client. The resolution must be
|
||||
set to STATIC to use Unix address endpoints.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: unix-domain-socket-example
|
||||
spec:
|
||||
hosts:
|
||||
- "example.unix.local"
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: STATIC
|
||||
endpoints:
|
||||
- address: unix:///var/run/example/socket
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -463,8 +233,6 @@ spec:
|
|||
endpoints:
|
||||
- address: unix:///var/run/example/socket
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>For HTTP-based services, it is possible to create a <code>VirtualService</code>
|
||||
backed by multiple DNS addressable endpoints. In such a scenario, the
|
||||
application can use the <code>HTTP_PROXY</code> environment variable to transparently
|
||||
|
|
@ -472,34 +240,6 @@ reroute API calls for the <code>VirtualService</code> to a chosen backend. For
|
|||
example, the following configuration creates a non-existent external
|
||||
service called foo.bar.com backed by three domains: us.foo.bar.com:8080,
|
||||
uk.foo.bar.com:9080, and in.foo.bar.com:7080</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-dns
|
||||
spec:
|
||||
hosts:
|
||||
- foo.bar.com
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: DNS
|
||||
endpoints:
|
||||
- address: us.foo.bar.com
|
||||
ports:
|
||||
http: 8080
|
||||
- address: uk.foo.bar.com
|
||||
ports:
|
||||
http: 9080
|
||||
- address: in.foo.bar.com
|
||||
ports:
|
||||
http: 7080
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -524,8 +264,6 @@ spec:
|
|||
ports:
|
||||
http: 7080
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>With <code>HTTP_PROXY=http://localhost/</code>, calls from the application to
|
||||
<code>http://foo.bar.com</code> will be load balanced across the three domains
|
||||
specified above. In other words, a call to <code>http://foo.bar.com/baz</code> would
|
||||
|
|
@ -533,30 +271,6 @@ be translated to <code>http://uk.foo.bar.com/baz</code>.</p>
|
|||
<p>The following example illustrates the usage of a <code>ServiceEntry</code>
|
||||
containing a subject alternate name
|
||||
whose format conforms to the <a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md">SPIFFE standard</a>:</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace : httpbin-ns
|
||||
spec:
|
||||
hosts:
|
||||
- example.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: STATIC
|
||||
endpoints:
|
||||
- address: 2.2.2.2
|
||||
- address: 3.3.3.3
|
||||
subjectAltNames:
|
||||
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -577,8 +291,6 @@ spec:
|
|||
subjectAltNames:
|
||||
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example demonstrates the use of <code>ServiceEntry</code> with a
|
||||
<code>workloadSelector</code> to handle the migration of a service
|
||||
<code>details.bookinfo.com</code> from VMs to Kubernetes. The service has two
|
||||
|
|
@ -586,32 +298,6 @@ VM-based instances with sidecars as well as a set of Kubernetes
|
|||
pods managed by a standard deployment object. Consumers of this
|
||||
service in the mesh will be automatically load balanced across the
|
||||
VMs and Kubernetes.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-vm-1
|
||||
spec:
|
||||
serviceAccount: details
|
||||
address: 2.2.2.2
|
||||
labels:
|
||||
app: details
|
||||
instance-id: vm1
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-vm-2
|
||||
spec:
|
||||
serviceAccount: details
|
||||
address: 3.3.3.3
|
||||
labels:
|
||||
app: details
|
||||
instance-id: vm2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -634,33 +320,10 @@ spec:
|
|||
app: details
|
||||
instance-id: vm2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Assuming there is also a Kubernetes deployment with pod labels
|
||||
<code>app: details</code> using the same service account <code>details</code>, the
|
||||
following service entry declares a service spanning both VMs and
|
||||
Kubernetes:</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
hosts:
|
||||
- details.bookinfo.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: STATIC
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: details
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -678,8 +341,6 @@ spec:
|
|||
labels:
|
||||
app: details
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="ServiceEntry">ServiceEntry</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -48,21 +48,6 @@ in the root namespace called <code>istio-config</code>, that configures
|
|||
sidecars in all namespaces to allow egress traffic only to other
|
||||
workloads in the same namespace as well as to services in the
|
||||
<code>istio-system</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: default
|
||||
namespace: istio-config
|
||||
spec:
|
||||
egress:
|
||||
- hosts:
|
||||
- "./*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -74,29 +59,11 @@ spec:
|
|||
- "./*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The example below declares a <code>Sidecar</code> configuration in the
|
||||
<code>prod-us1</code> namespace that overrides the global default defined
|
||||
above, and configures the sidecars in the namespace to allow egress
|
||||
traffic to public services in the <code>prod-us1</code>, <code>prod-apis</code>, and the
|
||||
<code>istio-system</code> namespaces.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: default
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
egress:
|
||||
- hosts:
|
||||
- "prod-us1/*"
|
||||
- "prod-apis/*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -109,8 +76,6 @@ spec:
|
|||
- "prod-apis/*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares a <code>Sidecar</code> configuration in the
|
||||
<code>prod-us1</code> namespace for all pods with labels <code>app: ratings</code>
|
||||
belonging to the <code>ratings.prod-us1</code> service. The workload accepts
|
||||
|
|
@ -119,35 +84,6 @@ the attached workload instance listening on a Unix domain
|
|||
socket. In the egress direction, in addition to the <code>istio-system</code>
|
||||
namespace, the sidecar proxies only HTTP traffic bound for port
|
||||
9080 for services in the <code>prod-us1</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: ratings
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: ratings
|
||||
ingress:
|
||||
- port:
|
||||
number: 9080
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
defaultEndpoint: unix:///var/run/someuds.sock
|
||||
egress:
|
||||
- port:
|
||||
number: 9080
|
||||
protocol: HTTP
|
||||
name: egresshttp
|
||||
hosts:
|
||||
- "prod-us1/*"
|
||||
- hosts:
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -173,8 +109,6 @@ spec:
|
|||
- hosts:
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>If the workload is deployed without IPTables-based traffic capture,
|
||||
the <code>Sidecar</code> configuration is the only way to configure the ports
|
||||
on the proxy attached to the workload instance. The following
|
||||
|
|
@ -189,36 +123,6 @@ it to the application listening on <code>127.0.0.1:8080</code>. It also allows
|
|||
the application to communicate with a backing MySQL database on
|
||||
<code>127.0.0.1:3306</code>, that then gets proxied to the externally hosted
|
||||
MySQL service at <code>mysql.foo.com:3306</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: no-ip-tables
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: productpage
|
||||
ingress:
|
||||
- port:
|
||||
number: 9080 # binds to proxy_instance_ip:9080 (0.0.0.0:9080, if no unicast IP is available for the instance)
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
defaultEndpoint: 127.0.0.1:8080
|
||||
captureMode: NONE # not needed if metadata is set for entire proxy
|
||||
egress:
|
||||
- port:
|
||||
number: 3306
|
||||
protocol: MYSQL
|
||||
name: egressmysql
|
||||
captureMode: NONE # not needed if metadata is set for entire proxy
|
||||
bind: 127.0.0.1
|
||||
hosts:
|
||||
- "*/mysql.foo.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -245,28 +149,7 @@ spec:
|
|||
hosts:
|
||||
- "*/mysql.foo.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated service entry for routing to <code>mysql.foo.com:3306</code></p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-mysql
|
||||
namespace: ns1
|
||||
spec:
|
||||
hosts:
|
||||
- mysql.foo.com
|
||||
ports:
|
||||
- number: 3306
|
||||
name: mysql
|
||||
protocol: MYSQL
|
||||
location: MESH_EXTERNAL
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -282,8 +165,6 @@ spec:
|
|||
location: MESH_EXTERNAL
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is also possible to mix and match traffic capture modes in a single
|
||||
proxy. For example, consider a setup where internal services are on the
|
||||
<code>192.168.0.0/16</code> subnet. So, IP tables are setup on the VM to capture all
|
||||
|
|
@ -295,36 +176,6 @@ listener on <code>172.16.1.32:80</code> (the VM’s IP) for traffic arriving
|
|||
<p><strong>NOTE</strong>: The <code>ISTIO_META_INTERCEPTION_MODE</code> metadata on the
|
||||
proxy in the VM should contain <code>REDIRECT</code> or <code>TPROXY</code> as its value,
|
||||
implying that IP tables based traffic capture is active.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: partial-ip-tables
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: productpage
|
||||
ingress:
|
||||
- bind: 172.16.1.32
|
||||
port:
|
||||
number: 80 # binds to 172.16.1.32:80
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
defaultEndpoint: 127.0.0.1:8080
|
||||
captureMode: NONE
|
||||
egress:
|
||||
# use the system detected defaults
|
||||
# sets up configuration to handle outbound traffic to services
|
||||
# in 192.168.0.0/16 subnet, based on information provided by the
|
||||
# service registry
|
||||
- captureMode: IPTABLES
|
||||
hosts:
|
||||
- "*/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -351,8 +202,6 @@ spec:
|
|||
hosts:
|
||||
- "*/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares a <code>Sidecar</code> configuration in the
|
||||
<code>prod-us1</code> namespace for all pods with labels <code>app: ratings</code>
|
||||
belonging to the <code>ratings.prod-us1</code> service. The service accepts
|
||||
|
|
@ -365,9 +214,7 @@ in order to set mTLS mode to “DISABLE” on specific
|
|||
ports.
|
||||
In this example, the mTLS mode is disabled on PORT 80.
|
||||
This feature is currently experimental.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: ratings
|
||||
|
|
@ -386,10 +233,8 @@ spec:
|
|||
mode: SIMPLE
|
||||
privateKey: "/etc/certs/privatekey.pem"
|
||||
serverCertificate: "/etc/certs/servercert.pem"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: v1
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: ratings
|
||||
|
|
@ -403,10 +248,8 @@ spec:
|
|||
targetPort: 80
|
||||
selector:
|
||||
app: ratings
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
name: ratings-peer-auth
|
||||
|
|
@ -421,8 +264,6 @@ spec:
|
|||
80:
|
||||
mode: DISABLE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>In addition to configuring traffic capture and how traffic is forwarded to the app,
|
||||
it’s possible to control inbound connection pool settings. By default, Istio pushes
|
||||
connection pool settings from <code>DestinationRules</code> to both clients (for outbound
|
||||
|
|
@ -430,39 +271,6 @@ connections to the service) as well as servers (for inbound connections to a ser
|
|||
instance). Using the <code>InboundConnectionPool</code> and per-port <code>ConnectionPool</code> settings
|
||||
in a <code>Sidecar</code> allow you to control those connection pools for the server separately
|
||||
from the settings pushed to all clients.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: connection-pool-settings
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: productpage
|
||||
inboundConnectionPool:
|
||||
http:
|
||||
http1MaxPendingRequests: 1024
|
||||
http2MaxRequests: 1024
|
||||
maxRequestsPerConnection: 1024
|
||||
maxRetries: 100
|
||||
ingress:
|
||||
- port:
|
||||
number: 80
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
connectionPool:
|
||||
http:
|
||||
http1MaxPendingRequests: 1024
|
||||
http2MaxRequests: 1024
|
||||
maxRequestsPerConnection: 1024
|
||||
maxRetries: 100
|
||||
tcp:
|
||||
maxConnections: 100
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -492,8 +300,6 @@ spec:
|
|||
tcp:
|
||||
maxConnections: 100
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="Sidecar">Sidecar</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -43,36 +43,6 @@ to be customized for specific client contexts.</p>
|
|||
pods of the reviews service with label “version: v1”. In addition,
|
||||
HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will
|
||||
be rewritten to /newcatalog and sent to pods with label “version: v2”.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- name: "reviews-v2-routes"
|
||||
match:
|
||||
- uri:
|
||||
prefix: "/wpcatalog"
|
||||
- uri:
|
||||
prefix: "/consumercatalog"
|
||||
rewrite:
|
||||
uri: "/newcatalog"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v2
|
||||
- name: "reviews-v1-route"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -99,29 +69,9 @@ spec:
|
|||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>A subset/version of a route destination is identified with a reference
|
||||
to a named service subset which must be declared in a corresponding
|
||||
<code>DestinationRule</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-destination
|
||||
spec:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -136,8 +86,6 @@ spec:
|
|||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="VirtualService">VirtualService</h2>
|
||||
<section>
|
||||
|
|
@ -301,35 +249,6 @@ domain names over short names.</em></p>
|
|||
<p>The following Kubernetes example routes all traffic by default to pods
|
||||
of the reviews service with label “version: v1” (i.e., subset v1), and
|
||||
some to subset v2, in a Kubernetes environment.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
namespace: foo
|
||||
spec:
|
||||
hosts:
|
||||
- reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
prefix: "/wpcatalog"
|
||||
- uri:
|
||||
prefix: "/consumercatalog"
|
||||
rewrite:
|
||||
uri: "/newcatalog"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subset: v2
|
||||
- route:
|
||||
- destination:
|
||||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -355,28 +274,7 @@ spec:
|
|||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated DestinationRule</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-destination
|
||||
namespace: foo
|
||||
spec:
|
||||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -392,8 +290,6 @@ spec:
|
|||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following VirtualService sets a timeout of 5s for all calls to
|
||||
productpage.prod.svc.cluster.local service in Kubernetes. Notice that
|
||||
there are no subsets defined in this rule. Istio will fetch all
|
||||
|
|
@ -403,24 +299,6 @@ that this rule is set in the istio-system namespace but uses the fully
|
|||
qualified domain name of the productpage service,
|
||||
productpage.prod.svc.cluster.local. Therefore the rule’s namespace does
|
||||
not have an impact in resolving the name of the productpage service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: my-productpage-rule
|
||||
namespace: istio-system
|
||||
spec:
|
||||
hosts:
|
||||
- productpage.prod.svc.cluster.local # ignores rule namespace
|
||||
http:
|
||||
- timeout: 5s
|
||||
route:
|
||||
- destination:
|
||||
host: productpage.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -435,44 +313,11 @@ spec:
|
|||
- destination:
|
||||
host: productpage.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>To control routing for traffic bound to services outside the mesh, external
|
||||
services must first be added to Istio’s internal service registry using the
|
||||
ServiceEntry resource. VirtualServices can then be defined to control traffic
|
||||
bound to these external services. For example, the following rules define a
|
||||
Service for wikipedia.org and set a timeout of 5s for HTTP requests.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-wikipedia
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: example-http
|
||||
protocol: HTTP
|
||||
resolution: DNS
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: my-wiki-rule
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
http:
|
||||
- timeout: 5s
|
||||
route:
|
||||
- destination:
|
||||
host: wikipedia.org
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -500,8 +345,6 @@ spec:
|
|||
- destination:
|
||||
host: wikipedia.org
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -892,36 +735,6 @@ The following VirtualService adds a <code>test</code> header with the value <cod
|
|||
to requests that are routed to any <code>reviews</code> service destination.
|
||||
It also removes the <code>foo</code> response header, but only from responses
|
||||
coming from the <code>v1</code> subset (version) of the <code>reviews</code> service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- headers:
|
||||
request:
|
||||
set:
|
||||
test: "true"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v2
|
||||
weight: 25
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
headers:
|
||||
response:
|
||||
remove:
|
||||
- foo
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -948,8 +761,6 @@ spec:
|
|||
- foo
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -994,35 +805,6 @@ No
|
|||
traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS
|
||||
traffic arriving at port 443 of gateway called “mygateway” to internal
|
||||
services in the mesh based on the SNI value.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-sni
|
||||
spec:
|
||||
hosts:
|
||||
- "*.bookinfo.com"
|
||||
gateways:
|
||||
- mygateway
|
||||
tls:
|
||||
- match:
|
||||
- port: 443
|
||||
sniHosts:
|
||||
- login.bookinfo.com
|
||||
route:
|
||||
- destination:
|
||||
host: login.prod.svc.cluster.local
|
||||
- match:
|
||||
- port: 443
|
||||
sniHosts:
|
||||
- reviews.bookinfo.com
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1048,8 +830,6 @@ spec:
|
|||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1094,26 +874,6 @@ No
|
|||
<p>Describes match conditions and actions for routing TCP traffic. The
|
||||
following routing rule forwards traffic arriving at port 27017 for
|
||||
mongo.prod.svc.cluster.local to another Mongo server on port 5555.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-mongo
|
||||
spec:
|
||||
hosts:
|
||||
- mongo.prod.svc.cluster.local
|
||||
tcp:
|
||||
- match:
|
||||
- port: 27017
|
||||
route:
|
||||
- destination:
|
||||
host: mongo.backup.svc.cluster.local
|
||||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1130,8 +890,6 @@ spec:
|
|||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1178,29 +936,6 @@ rule to be applied to the HTTP request. For example, the following
|
|||
restricts the rule to match only requests where the URL path
|
||||
starts with /ratings/v2/ and the request contains a custom <code>end-user</code> header
|
||||
with value <code>jason</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- headers:
|
||||
end-user:
|
||||
exact: jason
|
||||
uri:
|
||||
prefix: "/ratings/v2/"
|
||||
ignoreUriCase: true
|
||||
route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1220,8 +955,6 @@ spec:
|
|||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>HTTPMatchRequest CANNOT be empty.
|
||||
<strong>Note:</strong></p>
|
||||
<ol>
|
||||
|
|
@ -1513,28 +1246,6 @@ determine the proportion of traffic it receives. For example, the
|
|||
following rule will route 25% of traffic for the “reviews” service to
|
||||
instances with the “v2” tag and the remaining traffic (i.e., 75%) to
|
||||
“v1”.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v2
|
||||
weight: 25
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1553,27 +1264,7 @@ spec:
|
|||
subset: v1
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated DestinationRule</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-destination
|
||||
spec:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -1588,31 +1279,9 @@ spec:
|
|||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Traffic can also be split across two entirely different services without
|
||||
having to define new subsets. For example, the following rule forwards 25% of
|
||||
traffic to reviews.com to dev.reviews.com</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route-two-domains
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.com
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: dev.reviews.com
|
||||
weight: 25
|
||||
- destination:
|
||||
host: reviews.com
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1629,8 +1298,6 @@ spec:
|
|||
host: reviews.com
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1910,26 +1577,6 @@ where the Authority/Host and the URI in the response can be swapped with
|
|||
the specified values. For example, the following rule redirects
|
||||
requests for /v1/getProductRatings API on the ratings service to
|
||||
/v1/bookRatings provided by the bookratings service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
redirect:
|
||||
uri: /v1/bookRatings
|
||||
authority: newratings.default.svc.cluster.local
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1946,8 +1593,6 @@ spec:
|
|||
authority: newratings.default.svc.cluster.local
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2044,27 +1689,6 @@ No
|
|||
<p>HTTPDirectResponse can be used to send a fixed response to clients.
|
||||
For example, the following rule returns a fixed 503 status with a body
|
||||
to requests for /v1/getProductRatings API.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
directResponse:
|
||||
status: 503
|
||||
body:
|
||||
string: "unknown error"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2082,31 +1706,8 @@ spec:
|
|||
string: "unknown error"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is also possible to specify a binary response body.
|
||||
This is mostly useful for non text-based protocols such as gRPC.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
directResponse:
|
||||
status: 503
|
||||
body:
|
||||
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2124,36 +1725,9 @@ spec:
|
|||
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is good practice to add headers in the HTTPRoute
|
||||
as well as the direct_response, for example to specify
|
||||
the returned Content-Type.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
directResponse:
|
||||
status: 503
|
||||
body:
|
||||
string: "{\"error\": \"unknown error\"}"
|
||||
headers:
|
||||
response:
|
||||
set:
|
||||
content-type: "application/json"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2175,8 +1749,6 @@ spec:
|
|||
content-type: "text/plain"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2258,28 +1830,6 @@ before forwarding the request to the destination. Rewrite primitive can
|
|||
be used only with HTTPRouteDestination. The following example
|
||||
demonstrates how to rewrite the URL prefix for api call (/ratings) to
|
||||
ratings service before making the actual API call.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
prefix: /ratings
|
||||
rewrite:
|
||||
uri: /v1/bookRatings
|
||||
route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2298,8 +1848,6 @@ spec:
|
|||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2452,27 +2000,6 @@ example, the following rule sets the maximum number of retries to 3 when
|
|||
calling ratings:v1 service, with a 2s timeout per retry attempt.
|
||||
A retry will be attempted if there is a connect-failure, refused_stream
|
||||
or when the upstream server responds with Service Unavailable(503).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
retries:
|
||||
attempts: 3
|
||||
perTryTimeout: 2s
|
||||
retryOn: connect-failure,refused-stream,503
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2490,8 +2017,6 @@ spec:
|
|||
perTryTimeout: 2s
|
||||
retryOn: gateway-error,connect-failure,refused-stream
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2572,33 +2097,6 @@ the following rule restricts cross origin requests to those originating
|
|||
from example.com domain using HTTP POST/GET, and sets the
|
||||
<code>Access-Control-Allow-Credentials</code> header to false. In addition, it only
|
||||
exposes <code>X-Foo-bar</code> header and sets an expiry period of 1 day.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
corsPolicy:
|
||||
allowOrigins:
|
||||
- exact: https://example.com
|
||||
allowMethods:
|
||||
- POST
|
||||
- GET
|
||||
allowCredentials: false
|
||||
allowHeaders:
|
||||
- X-Foo-Bar
|
||||
maxAge: "24h"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2622,8 +2120,6 @@ spec:
|
|||
- X-Foo-Bar
|
||||
maxAge: "24h"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2917,31 +2413,6 @@ No
|
|||
forwarding path. The following example will introduce a 5 second delay
|
||||
in 1 out of every 1000 requests to the “v1” version of the “reviews”
|
||||
service from all pods with label env: prod</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- sourceLabels:
|
||||
env: prod
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
fault:
|
||||
delay:
|
||||
percentage:
|
||||
value: 0.1
|
||||
fixedDelay: 5s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2963,8 +2434,6 @@ spec:
|
|||
value: 0.1
|
||||
fixedDelay: 5s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The <em>fixedDelay</em> field is used to indicate the amount of delay in seconds.
|
||||
The optional <em>percentage</em> field can be used to only delay a certain
|
||||
percentage of requests. If left unspecified, no request will be delayed.</p>
|
||||
|
|
@ -3024,28 +2493,6 @@ No
|
|||
<p>Abort specification is used to prematurely abort a request with a
|
||||
pre-specified error code. The following example will return an HTTP 400
|
||||
error code for 1 out of every 1000 requests to the “ratings” service “v1”.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
fault:
|
||||
abort:
|
||||
percentage:
|
||||
value: 0.1
|
||||
httpStatus: 400
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -3064,8 +2511,6 @@ spec:
|
|||
value: 0.1
|
||||
httpStatus: 400
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The <em>httpStatus</em> field is used to indicate the HTTP status code to
|
||||
return to the caller. The optional <em>percentage</em> field can be used to only
|
||||
abort a certain percentage of requests. If not specified, no request will be
|
||||
|
|
|
|||
|
|
@ -30,25 +30,6 @@ account. The service is exposed on port 80 to applications in the
|
|||
mesh. The HTTP traffic to this service is wrapped in Istio mutual
|
||||
TLS and sent to sidecars on VMs on target port 8080, that in turn
|
||||
forward it to the application on localhost on the same port.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
# use of the service account indicates that the workload has a
|
||||
# sidecar proxy bootstrapped with this service account. Pods with
|
||||
# sidecars will automatically communicate with the workload using
|
||||
# istio mutual TLS.
|
||||
serviceAccount: details-legacy
|
||||
address: 2.2.2.2
|
||||
labels:
|
||||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -64,31 +45,7 @@ spec:
|
|||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>and the associated service entry</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
hosts:
|
||||
- details.bookinfo.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
targetPort: 8080
|
||||
resolution: STATIC
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -107,32 +64,11 @@ spec:
|
|||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares the same VM workload using
|
||||
its fully qualified DNS name. The service entry’s resolution
|
||||
mode should be changed to DNS to indicate that the client-side
|
||||
sidecars should dynamically resolve the DNS name at runtime before
|
||||
forwarding the request.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
# use of the service account indicates that the workload has a
|
||||
# sidecar proxy bootstrapped with this service account. Pods with
|
||||
# sidecars will automatically communicate with the workload using
|
||||
# istio mutual TLS.
|
||||
serviceAccount: details-legacy
|
||||
address: vm1.vpc01.corp.net
|
||||
labels:
|
||||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -148,31 +84,7 @@ spec:
|
|||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>and the associated service entry</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
hosts:
|
||||
- details.bookinfo.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
targetPort: 8080
|
||||
resolution: DNS
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -191,28 +103,12 @@ spec:
|
|||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares a VM workload without an address.
|
||||
An alternative to having istiod read from remote API servers is
|
||||
to write a <code>WorkloadEntry</code> in the local cluster that represents
|
||||
the Workload(s) in the remote network with the given labels. A
|
||||
single <code>WorkloadEntry</code> with weights represent the aggregate of all
|
||||
the actual workloads in a given remote network.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: foo-workloads-cluster-2
|
||||
spec:
|
||||
serviceAccount: foo
|
||||
network: cluster-2-network
|
||||
labels:
|
||||
app: foo
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -223,8 +119,6 @@ spec:
|
|||
labels:
|
||||
app: foo
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="WorkloadEntry">WorkloadEntry</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -22,40 +22,6 @@ of workloads that will be registered under <code>reviews</code> in namespace
|
|||
instance during the bootstrap process, and the ports 3550 and 8080
|
||||
will be associated with the workload group and use service account <code>default</code>.
|
||||
<code>app.kubernetes.io/version</code> is just an arbitrary example of a label.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadGroup
|
||||
metadata:
|
||||
name: reviews
|
||||
namespace: bookinfo
|
||||
spec:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: reviews
|
||||
app.kubernetes.io/version: "1.3.4"
|
||||
template:
|
||||
ports:
|
||||
grpc: 3550
|
||||
http: 8080
|
||||
serviceAccount: default
|
||||
probe:
|
||||
initialDelaySeconds: 5
|
||||
timeoutSeconds: 3
|
||||
periodSeconds: 4
|
||||
successThreshold: 3
|
||||
failureThreshold: 3
|
||||
httpGet:
|
||||
path: /foo/bar
|
||||
host: 127.0.0.1
|
||||
port: 3100
|
||||
scheme: HTTPS
|
||||
httpHeaders:
|
||||
- name: Lit-Header
|
||||
value: Im-The-Best
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadGroup
|
||||
metadata:
|
||||
|
|
@ -86,8 +52,6 @@ spec:
|
|||
- name: Lit-Header
|
||||
value: Im-The-Best
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="WorkloadGroup">WorkloadGroup</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -44,34 +44,6 @@ but it is useful to be explicit in the policy.</p>
|
|||
</ul>
|
||||
<p>when the request has a valid JWT token issued by <code>https://accounts.google.com</code>.</p>
|
||||
<p>Any other requests will be denied.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals: ["cluster.local/ns/default/sa/sleep"]
|
||||
- source:
|
||||
namespaces: ["test"]
|
||||
to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
paths: ["/info*"]
|
||||
- operation:
|
||||
methods: ["POST"]
|
||||
paths: ["/data"]
|
||||
when:
|
||||
- key: request.auth.claims[iss]
|
||||
values: ["https://accounts.google.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -96,30 +68,9 @@ spec:
|
|||
- key: request.auth.claims[iss]
|
||||
values: ["https://accounts.google.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following is another example that sets <code>action</code> to <code>DENY</code> to create a deny policy.
|
||||
It denies requests from the <code>dev</code> namespace to the <code>POST</code> method on all workloads
|
||||
in the <code>foo</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
action: DENY
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
namespaces: ["dev"]
|
||||
to:
|
||||
- operation:
|
||||
methods: ["POST"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -135,28 +86,9 @@ spec:
|
|||
- operation:
|
||||
methods: ["POST"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following is another example that sets <code>action</code> to <code>DENY</code> to create a deny policy.
|
||||
It denies all the requests with <code>POST</code> method on port <code>8080</code> on all workloads
|
||||
in the <code>foo</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
action: DENY
|
||||
rules:
|
||||
- to:
|
||||
- operation:
|
||||
methods: ["POST"]
|
||||
ports: ["8080"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -170,34 +102,12 @@ spec:
|
|||
methods: ["POST"]
|
||||
ports: ["8080"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>When this rule is applied to TCP traffic, the <code>method</code> field (as will all HTTP based attributes) cannot be processed.
|
||||
For a <code>DENY</code> rule, missing attributes are treated as matches. This means all TCP traffic on port <code>8080</code> would be denied in the example above.
|
||||
If we were to remove the <code>ports</code> match, all TCP traffic would be denied. As a result, it is recommended to always scope <code>DENY</code> policies to a specific port,
|
||||
especially when using HTTP attributes <a href="/docs/tasks/security/authorization/authz-tcp/">Authorization Policy for TCP Ports</a>.</p>
|
||||
<p>The following authorization policy sets the <code>action</code> to <code>AUDIT</code>. It will audit any <code>GET</code> requests to the path with the
|
||||
prefix <code>/user/profile</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
namespace: ns1
|
||||
name: anyname
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: myapi
|
||||
action: AUDIT
|
||||
rules:
|
||||
- to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
paths: ["/user/profile/*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -214,8 +124,6 @@ spec:
|
|||
methods: ["GET"]
|
||||
paths: ["/user/profile/*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Authorization Policy scope (target) is determined by “metadata/namespace” and
|
||||
an optional <code>selector</code>.</p>
|
||||
<ul>
|
||||
|
|
@ -225,18 +133,6 @@ namespace, the policy applies to all namespaces in a mesh.</li>
|
|||
</ul>
|
||||
<p>For example, the following authorization policy applies to all workloads in namespace <code>foo</code>. It allows nothing and effectively denies
|
||||
all requests to workloads in namespace <code>foo</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-nothing
|
||||
namespace: foo
|
||||
spec:
|
||||
{}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -245,22 +141,7 @@ metadata:
|
|||
spec:
|
||||
{}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following authorization policy allows all requests to workloads in namespace <code>foo</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-all
|
||||
namespace: foo
|
||||
spec:
|
||||
rules:
|
||||
- {}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -270,24 +151,8 @@ spec:
|
|||
rules:
|
||||
- {}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following authorization policy applies to workloads containing label <code>app: httpbin</code> in namespace <code>bar</code>. It allows
|
||||
nothing and effectively denies all requests to the selected workloads.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-nothing
|
||||
namespace: bar
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -298,24 +163,8 @@ spec:
|
|||
matchLabels:
|
||||
app: httpbin
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following authorization policy applies to workloads containing label <code>version: v1</code> in all namespaces in the mesh.
|
||||
(Assuming the root namespace is configured to <code>istio-system</code>).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-nothing
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
version: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -326,33 +175,11 @@ spec:
|
|||
matchLabels:
|
||||
version: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example shows you how to set up an authorization policy using an <a href="/docs/reference/config/annotations/">experimental annotation</a>
|
||||
<code>istio.io/dry-run</code> to dry-run the policy without actually enforcing it.</p>
|
||||
<p>The dry-run annotation allows you to better understand the effect of an authorization policy before applying it to the production traffic.
|
||||
This helps to reduce the risk of breaking the production traffic caused by an incorrect authorization policy.
|
||||
For more information, see <a href="/docs/tasks/security/authorization/authz-dry-run/">dry-run tasks</a>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: dry-run-example
|
||||
annotations:
|
||||
"istio.io/dry-run": "true"
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
action: DENY
|
||||
rules:
|
||||
- to:
|
||||
- operation:
|
||||
paths: ["/headers"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -369,8 +196,6 @@ spec:
|
|||
- operation:
|
||||
paths: ["/headers"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="AuthorizationPolicy">AuthorizationPolicy</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -205,6 +205,18 @@ The header specified in each operation in the list must be unique. Nested claims
|
|||
</code></pre>
|
||||
<p>[Experimental] This feature is a experimental feature.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="JWTRule-timeout">
|
||||
<td><code>timeout</code></td>
|
||||
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">Duration</a></code></td>
|
||||
<td>
|
||||
<p>The maximum amount of time that the resolver, determined by the PILOT_JWT_ENABLE_REMOTE_JWKS environment variable,
|
||||
will spend waiting for the JWKS to be fetched. Default is 5s.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ spec:
|
|||
mode: STRICT
|
||||
</code></pre>
|
||||
<p>For mesh level, put the policy in root-namespace according to your Istio installation.</p>
|
||||
<p>Policies to allow both mTLS & plaintext traffic for all workloads under namespace <code>foo</code>, but
|
||||
<p>Policies to allow both mTLS and plaintext traffic for all workloads under namespace <code>foo</code>, but
|
||||
require mTLS for workload <code>finance</code>.</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
|
|
@ -48,8 +48,9 @@ spec:
|
|||
mtls:
|
||||
mode: STRICT
|
||||
</code></pre>
|
||||
<p>Policy to allow mTLS strict for all workloads, but leave port 8080 to
|
||||
plaintext:</p>
|
||||
<p>Policy that enables strict mTLS for all workloads, but leaves the port <code>8080</code> to
|
||||
plaintext. Note the port value in the <code>portLevelMtls</code> field refers to the port
|
||||
of the workload, not the port of the Kubernetes service.</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
|
|
@ -65,8 +66,8 @@ spec:
|
|||
8080:
|
||||
mode: DISABLE
|
||||
</code></pre>
|
||||
<p>Policy to inherit mTLS mode from namespace (or mesh) settings, and overwrite
|
||||
settings for port 8080</p>
|
||||
<p>Policy that inherits mTLS mode from namespace (or mesh) settings, and disables
|
||||
mTLS for workload port <code>8080</code>.</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
|
|
@ -123,7 +124,8 @@ No
|
|||
<td><code>map<uint32, <a href="#PeerAuthentication-MutualTLS">MutualTLS</a>></code></td>
|
||||
<td>
|
||||
<p>Port specific mutual TLS settings. These only apply when a workload selector
|
||||
is specified.</p>
|
||||
is specified. The port refers to the port of the workload, not the port of the
|
||||
Kubernetes service.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
|
@ -174,7 +176,7 @@ No
|
|||
<tr id="PeerAuthentication-MutualTLS-Mode-UNSET">
|
||||
<td><code>UNSET</code></td>
|
||||
<td>
|
||||
<p>Inherit from parent, if has one. Otherwise treated as PERMISSIVE.</p>
|
||||
<p>Inherit from parent, if has one. Otherwise treated as <code>PERMISSIVE</code>.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -21,37 +21,6 @@ Examples:</p>
|
|||
<ul>
|
||||
<li>Require JWT for all request for workloads that have label <code>app:httpbin</code></li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
jwtRules:
|
||||
- issuer: "issuer-foo"
|
||||
jwksUri: https://example.com/.well-known/jwks.json
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -79,38 +48,11 @@ spec:
|
|||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<ul>
|
||||
<li>A policy in the root namespace (“istio-system” by default) applies to workloads in all namespaces
|
||||
in a mesh. The following policy makes all workloads only accept requests that contain a
|
||||
valid JWT token.</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: req-authn-for-all
|
||||
namespace: istio-system
|
||||
spec:
|
||||
jwtRules:
|
||||
- issuer: "issuer-foo"
|
||||
jwksUri: https://example.com/.well-known/jwks.json
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: require-jwt-for-all
|
||||
namespace: istio-system
|
||||
spec:
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -132,53 +74,11 @@ spec:
|
|||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<ul>
|
||||
<li>The next example shows how to set a different JWT requirement for a different <code>host</code>. The <code>RequestAuthentication</code>
|
||||
declares it can accept JWTs issued by either <code>issuer-foo</code> or <code>issuer-bar</code> (the public key set is implicitly
|
||||
set from the OpenID Connect spec).</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
jwtRules:
|
||||
- issuer: "issuer-foo"
|
||||
- issuer: "issuer-bar"
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["issuer-foo/*"]
|
||||
to:
|
||||
- operation:
|
||||
hosts: ["example.com"]
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["issuer-bar/*"]
|
||||
to:
|
||||
- operation:
|
||||
hosts: ["another-host.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -215,34 +115,11 @@ spec:
|
|||
- operation:
|
||||
hosts: ["another-host.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<ul>
|
||||
<li>You can fine tune the authorization policy to set different requirement per path. For example,
|
||||
to require JWT on all paths, except /healthz, the same <code>RequestAuthentication</code> can be used, but the
|
||||
authorization policy could be:</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
- to:
|
||||
- operation:
|
||||
paths: ["/healthz"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -260,8 +137,6 @@ spec:
|
|||
- operation:
|
||||
paths: ["/healthz"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>[Experimental] Routing based on derived <a href="/docs/reference/config/security/conditions/">metadata</a>
|
||||
is now supported. A prefix ‘@’ is used to denote a match against internal metadata instead of the headers in the request.
|
||||
Currently this feature is only supported for the following metadata:</p>
|
||||
|
|
@ -277,62 +152,6 @@ For more information, see <a href="/docs/tasks/security/authentication/jwt-route
|
|||
<li>AuthorizationPolicy to check for valid principals in the request. This makes the JWT required for the request.</li>
|
||||
<li>VirtualService to route the request based on the “sub” claim.</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: jwt-on-ingress
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: istio-ingressgateway
|
||||
jwtRules:
|
||||
- issuer: "example.com"
|
||||
jwksUri: https://example.com/.well-known/jwks.json
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: require-jwt
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: istio-ingressgateway
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: route-jwt
|
||||
spec:
|
||||
hosts:
|
||||
- foo.prod.svc.cluster.local
|
||||
gateways:
|
||||
- istio-ingressgateway
|
||||
http:
|
||||
- name: "v2"
|
||||
match:
|
||||
- headers:
|
||||
"@request.auth.claims.sub":
|
||||
exact: "dev"
|
||||
route:
|
||||
- destination:
|
||||
host: foo.prod.svc.cluster.local
|
||||
subset: v2
|
||||
- name: "default"
|
||||
route:
|
||||
- destination:
|
||||
host: foo.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -385,8 +204,6 @@ spec:
|
|||
host: foo.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
|
|||
|
|
@ -85,8 +85,6 @@ Telemetry, and WasmPlugin CRDs to target a Kubernetes Gateway.</p>
|
|||
a PolicyTargetReference. The example sets <code>action</code> to <code>DENY</code> to create a deny policy.
|
||||
It denies all the requests with <code>POST</code> method on port <code>8080</code> directed through the
|
||||
<code>waypoint</code> Gateway in the <code>foo</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -104,8 +102,6 @@ spec:
|
|||
methods: ["POST"]
|
||||
ports: ["8080"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
|
|||
|
|
@ -696,7 +696,7 @@ These environment variables affect the behavior of the <code>install-cni</code>
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -778,6 +778,12 @@ These environment variables affect the behavior of the <code>install-cni</code>
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENVOY_USER</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio-proxy</code></td>
|
||||
|
|
@ -834,7 +840,7 @@ These environment variables affect the behavior of the <code>install-cni</code>
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -926,12 +932,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, istiod will skip verifying the certificate of the JWKS server.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_POLICY</code></td>
|
||||
<td>String</td>
|
||||
<td><code>third-party-jwt</code></td>
|
||||
<td>The JWT validation policy.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>KUBECFG_FILE_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>ZZZ-istio-cni-kubeconfig</code></td>
|
||||
|
|
@ -1016,12 +1016,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NODE_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -1172,12 +1166,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -1292,6 +1280,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1430,12 +1430,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>POD_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -18,10 +18,86 @@ remove_toc_prefix: 'operator '
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -40,10 +116,86 @@ See each sub-command's help for details on how to use the generated script.
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -73,14 +225,90 @@ If it is not installed already, you can install it via your OS's package man
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -105,14 +333,90 @@ If it is not installed already, you can install it via your OS's package man
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -136,14 +440,90 @@ to your powershell profile.
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -174,14 +554,90 @@ to enable it. You can execute the following once:</p>
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--no-descriptions</code></td>
|
||||
<td>disable completion descriptions </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -200,6 +656,26 @@ to enable it. You can execute the following once:</p>
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--ctrlz_address <string></code></td>
|
||||
<td>The IP Address to listen on for the ControlZ introspection facility. Use '*' to indicate all addresses. (default `localhost`)</td>
|
||||
</tr>
|
||||
|
|
@ -208,10 +684,22 @@ to enable it. You can execute the following once:</p>
|
|||
<td>The IP port to use for the ControlZ introspection facility (default `9876`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--force</code></td>
|
||||
<td>Proceed even with validation errors. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
|
|
@ -221,11 +709,11 @@ to enable it. You can execute the following once:</p>
|
|||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_caller <string></code></td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] (default ``)</td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, krt, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_output_level <string></code></td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, krt, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_rotate <string></code></td>
|
||||
|
|
@ -245,7 +733,7 @@ to enable it. You can execute the following once:</p>
|
|||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_stacktrace_level <string></code></td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, all, analysis, authn, ca, controllers, controlleruntime, default, delta, file, gateway, installer, klog, krt, kube, model, monitoring, patch, processing, retry, security, serviceentry, spiffe, status, tpath, translator, trustBundle, util, validation, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_target <stringArray></code></td>
|
||||
|
|
@ -256,6 +744,10 @@ to enable it. You can execute the following once:</p>
|
|||
<td>Defines the concurrency limit for operator to reconcile IstioOperatorSpec in parallel. Default value is 1. (default `1`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--monitoring-host <string></code></td>
|
||||
<td>HTTP host to use for operator's self-monitoring information (default `0.0.0.0`)</td>
|
||||
</tr>
|
||||
|
|
@ -264,6 +756,46 @@ to enable it. You can execute the following once:</p>
|
|||
<td>HTTP port to use for operator's self-monitoring information (default `8383`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
</tr>
|
||||
|
|
@ -283,21 +815,116 @@ to enable it. You can execute the following once:</p>
|
|||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>--all-features</code></td>
|
||||
<td></td>
|
||||
<td>Whether to enable all supported features for conformance tests </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--allow-crds-mismatch</code></td>
|
||||
<td></td>
|
||||
<td>Flag to allow the suite not to fail in case there is a mismatch between CRDs versions and channels. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--cleanup-base-resources</code></td>
|
||||
<td></td>
|
||||
<td>Whether to cleanup base test resources after the run </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--conformance-profiles <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of the conformance profiles to run (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--contact <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of contact information for the maintainers (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--debug</code></td>
|
||||
<td></td>
|
||||
<td>Whether to print debug logs </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--exempt-features <string></code></td>
|
||||
<td></td>
|
||||
<td>Exempt Features excluded from conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--gateway-class <string></code></td>
|
||||
<td></td>
|
||||
<td>Name of GatewayClass to use for tests (default `gateway-conformance`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--kubeconfig <string></code></td>
|
||||
<td></td>
|
||||
<td>Paths to a kubeconfig. Only required if out-of-cluster. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--mode <string></code></td>
|
||||
<td></td>
|
||||
<td>The operating mode of the implementation. (default `default`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-annotations <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of name=value annotations to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--namespace-labels <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of name=value labels to add to test namespaces (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--organization <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's Organization to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--output <string></code></td>
|
||||
<td><code>-o</code></td>
|
||||
<td>One of 'yaml' or 'json'. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--project <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's project to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--report-output <string></code></td>
|
||||
<td></td>
|
||||
<td>The file where to write the conformance report (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--run-test <string></code></td>
|
||||
<td></td>
|
||||
<td>Name of a single test to run, instead of the whole suite (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--short</code></td>
|
||||
<td><code>-s</code></td>
|
||||
<td>Use --short=false to generate full version information </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--skip-tests <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of tests to skip (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--supported-features <string></code></td>
|
||||
<td></td>
|
||||
<td>Supported features included in conformance tests suites (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--url <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's url to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--version <string></code></td>
|
||||
<td></td>
|
||||
<td>Implementation's version to issue conformance to (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--vklog <Level></code></td>
|
||||
<td></td>
|
||||
<td>number for the log level verbosity. Like -v flag. ex: --vklog=9 (default `0`)</td>
|
||||
|
|
@ -373,7 +1000,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -461,6 +1088,12 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>EXTERNAL_ISTIOD</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -511,7 +1144,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -615,12 +1248,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, istiod will skip verifying the certificate of the JWKS server.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_POLICY</code></td>
|
||||
<td>String</td>
|
||||
<td><code>third-party-jwt</code></td>
|
||||
<td>The JWT validation policy.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>K_REVISION</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -669,12 +1296,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PERSIST_OLDEST_FIRST_HEURISTIC_FOR_VIRTUAL_SERVICE_HOST_MATCHING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -819,12 +1440,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -939,6 +1554,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1077,12 +1704,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PLATFORM</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
|
|||
|
|
@ -543,11 +543,6 @@ to enable it. You can execute the following once:</p>
|
|||
<td>Insert tracing logs for each iptables rules, using the LOG chain. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--iptables-version <string></code></td>
|
||||
<td></td>
|
||||
<td>version of iptables command. If not set, this is automatically detected. (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--istio-exclude-interfaces <string></code></td>
|
||||
<td><code>-c</code></td>
|
||||
<td>Comma separated list of NIC (optional). Neither inbound nor outbound traffic will be captured. (default ``)</td>
|
||||
|
|
@ -1136,7 +1131,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -1224,6 +1219,12 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENVOY_PROMETHEUS_PORT</code></td>
|
||||
<td>Integer</td>
|
||||
<td><code>15090</code></td>
|
||||
|
|
@ -1376,7 +1377,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -1576,12 +1577,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>OUTPUT_CERTS</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -1738,12 +1733,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -1858,6 +1847,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1996,12 +1997,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PKCS8_KEY</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
|
|||
|
|
@ -269,12 +269,12 @@ to enable it. You can execute the following once:</p>
|
|||
<tr>
|
||||
<td><code>--log_caller <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] (default ``)</td>
|
||||
<td>Comma-separated list of scopes for which to include caller information, scopes can be any of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, krt, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] (default ``)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_output_level <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level of messages to output, in the form of <scope>:<level>,<scope>:<level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, krt, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:info`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_rotate <string></code></td>
|
||||
|
|
@ -299,7 +299,7 @@ to enable it. You can execute the following once:</p>
|
|||
<tr>
|
||||
<td><code>--log_stacktrace_level <string></code></td>
|
||||
<td></td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
<td>Comma-separated minimum per-scope logging level at which stack traces are captured, in the form of <scope>:<level>,<scope:level>,... where scope can be one of [ads, adsc, all, analysis, authn, authorization, ca, controllers, default, delta, deltaadsc, file, gateway, grpcgen, ingress status, klog, krt, kube, model, monitor, monitoring, pkica, pkira, processing, retry, rootcertrotator, secretcontroller, security, serverca, serviceentry, spiffe, status, trustBundle, validation, validationController, validationServer, wasm, wle] and level can be one of [debug, info, warn, error, fatal, none] (default `default:none`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--log_target <stringArray></code></td>
|
||||
|
|
@ -535,7 +535,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ENABLE_ENHANCED_RESOURCE_SCOPING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, meshConfig.discoverySelectors will limit the CustomResource configurations(like Gateway,VirtualService,DestinationRule,Ingress, etc)that can be processed by pilot. This will also restrict the root-ca certificate distribution.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -623,6 +623,12 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<td>If enabled, the TLS configuration on Sidecar.ingress will take effect</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>ENABLE_VTPROTOBUF</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td>If true, will use optimized vtprotobuf based marshaling. Requires a build with -tags=vtprotobuf.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>EXTERNAL_CA</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -709,7 +715,7 @@ https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/security/ssl#fip
|
|||
<tr>
|
||||
<td><code>ISTIO_DELTA_XDS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, pilot will only send the delta configs as opposed to the state of the world on a Resource Request. This feature uses the delta xds api, but does not currently send the actual deltas.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -813,12 +819,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, istiod will skip verifying the certificate of the JWKS server.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_POLICY</code></td>
|
||||
<td>String</td>
|
||||
<td><code>third-party-jwt</code></td>
|
||||
<td>The JWT validation policy.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>JWT_RULE</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
@ -897,12 +897,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If set to a non-zero value, enables mutex profiling a rate of 1/MUTEX_PROFILE_FRACTION events. For example, '1000' will record 0.1% of events. Set to 0 to disable entirely.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>NATIVE_METADATA_EXCHANGE</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If set, uses a native implementation of the HTTP metadata exchange filter</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PERSIST_OLDEST_FIRST_HEURISTIC_FOR_VIRTUAL_SERVICE_HOST_MATCHING</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1047,12 +1041,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, HBONE support can be configured for proxies. Note: proxies must opt in on a per-proxy basis with ENABLE_HBONE to actually get HBONE config, in addition to this flag.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_HEADLESS_SERVICE_POD_LISTENERS</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
<td>If enabled, for a headless service/stateful set in Kubernetes, pilot will generate an outbound listener for each pod in a headless service. This feature should be disabled if headless services have a large number of pods.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_ENABLE_K8S_SELECT_WORKLOAD_ENTRIES</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>true</code></td>
|
||||
|
|
@ -1167,6 +1155,18 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If enabled, Pilot will send only clusters that referenced in gateway virtual services attached to gateway</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_CONTROLLER_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio.io/gateway-controller</code></td>
|
||||
<td>Gateway API controller name. istiod will only reconcile Gateway API resources referencing a GatewayClass with this controller name</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME</code></td>
|
||||
<td>String</td>
|
||||
<td><code>istio</code></td>
|
||||
<td>Name of the default GatewayClass</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_HTTP10</code></td>
|
||||
<td>Boolean</td>
|
||||
<td><code>false</code></td>
|
||||
|
|
@ -1305,12 +1305,6 @@ Only applies when traffic from all groups (i.e. "*") is being redirected
|
|||
<td>If true, Pilot will collect metrics for XDS cache efficiency.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PILOT_XDS_SEND_TIMEOUT</code></td>
|
||||
<td>Time Duration</td>
|
||||
<td><code>0s</code></td>
|
||||
<td>The timeout to send the XDS configuration to proxies. After this timeout is reached, Pilot will discard that push.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>PLATFORM</code></td>
|
||||
<td>String</td>
|
||||
<td><code></code></td>
|
||||
|
|
|
|||
|
|
@ -28,7 +28,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of configuration analysis message codes to suppress when Istio analyzers are run. For example, to suppress reporting of IST0103 (PodMissingProxy) and IST0108 (UnknownAnnotation) on a resource, apply the annotation 'galley.istio.io/analyze-suppress=IST0108,IST0103'. If the value is '*', then all configuration analysis messages are suppressed.</td>
|
||||
<td><p>A comma separated list of configuration analysis message codes to suppress when Istio analyzers are run. For example, to suppress reporting of IST0103 (PodMissingProxy) and IST0108 (UnknownAnnotation) on a resource, apply the annotation ‘galley.istio.io/analyze-suppress=IST0108,IST0103’. If the value is ‘*’, then all configuration analysis messages are suppressed.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -49,7 +50,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>The name of the inject template(s) to use, as a comma separate list. See https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#custom-templates-experimental for more information.</td>
|
||||
<td><p>The name of the inject template(s) to use, as a comma separate list. See <a href="/latest/docs/setup/additional-setup/sidecar-injection/#custom-templates-experimental" target="_blank">https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#custom-templates-experimental</a> for more information.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -70,7 +72,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Represents the name of the chart used to create this resource.</td>
|
||||
<td><p>Represents the name of the chart used to create this resource.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -91,7 +94,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Represents the generation to which the resource was last reconciled.</td>
|
||||
<td><p>Represents the generation to which the resource was last reconciled.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -112,7 +116,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Represents the Istio version associated with the resource</td>
|
||||
<td><p>Represents the Istio version associated with the resource</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -133,7 +138,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not the given resource is in dry-run mode. See https://istio.io/latest/docs/tasks/security/authorization/authz-dry-run/ for more information.</td>
|
||||
<td><p>Specifies whether or not the given resource is in dry-run mode. See <a href="/latest/docs/tasks/security/authorization/authz-dry-run/" target="_blank">https://istio.io/latest/docs/tasks/security/authorization/authz-dry-run/</a> for more information.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -154,7 +160,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies a control plane revision to which a given proxy is connected. This annotation is added automatically, not set by a user. In contrary to the label istio.io/rev, it represents the actual revision, not the requested revision.</td>
|
||||
<td><p>Specifies a control plane revision to which a given proxy is connected. This annotation is added automatically, not set by a user. In contrary to the label istio.io/rev, it represents the actual revision, not the requested revision.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -175,7 +182,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Annotation on an Ingress resources denoting the class of controllers responsible for it.</td>
|
||||
<td><p>Annotation on an Ingress resources denoting the class of controllers responsible for it.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -196,7 +204,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the namespaces to which this service should be exported to. A value of '*' indicates it is reachable within the mesh '.' indicates it is reachable within its namespace.</td>
|
||||
<td><p>Specifies the namespaces to which this service should be exported to. A value of ‘*’ indicates it is reachable within the mesh ‘.’ indicates it is reachable within its namespace.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -217,7 +226,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies if application Prometheus metric will be merged with Envoy metrics for this workload.</td>
|
||||
<td><p>Specifies if application Prometheus metric will be merged with Envoy metrics for this workload.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -238,7 +248,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Overrides for the proxy configuration for this specific proxy. Available options can be found at https://istio.io/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig.</td>
|
||||
<td><p>Overrides for the proxy configuration for this specific proxy. Available options can be found at <a href="/zh/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig" target="_blank">https://istio.io/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig</a>.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -259,7 +270,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the list of ports exposed by the application container. Used by the Envoy sidecar readiness probe to determine that Envoy is configured and ready to receive traffic.</td>
|
||||
<td><p>Specifies the list of ports exposed by the application container. Used by the Envoy sidecar readiness probe to determine that Envoy is configured and ready to receive traffic.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -280,7 +292,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the failure threshold for the Envoy sidecar readiness probe.</td>
|
||||
<td><p>Specifies the failure threshold for the Envoy sidecar readiness probe.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -301,7 +314,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the initial delay (in seconds) for the Envoy sidecar readiness probe.</td>
|
||||
<td><p>Specifies the initial delay (in seconds) for the Envoy sidecar readiness probe.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -322,7 +336,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the period (in seconds) for the Envoy sidecar readiness probe.</td>
|
||||
<td><p>Specifies the period (in seconds) for the Envoy sidecar readiness probe.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -343,7 +358,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the log output level for pilot-agent.</td>
|
||||
<td><p>Specifies the log output level for pilot-agent.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -364,7 +380,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies an alternative Envoy bootstrap configuration file.</td>
|
||||
<td><p>Specifies an alternative Envoy bootstrap configuration file.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -385,7 +402,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the component log level for Envoy.</td>
|
||||
<td><p>Specifies the component log level for Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -406,7 +424,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the auth policy used by the Istio control plane. If NONE, traffic will not be encrypted. If MUTUAL_TLS, traffic between Envoy sidecar will be wrapped into mutual TLS connections.</td>
|
||||
<td><p>Specifies the auth policy used by the Istio control plane. If NONE, traffic will not be encrypted. If MUTUAL_TLS, traffic between Envoy sidecar will be wrapped into mutual TLS connections.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -427,7 +446,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the XDS discovery address to be used by the Envoy sidecar.</td>
|
||||
<td><p>Specifies the XDS discovery address to be used by the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -448,7 +468,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not an Envoy sidecar should enable core dump.</td>
|
||||
<td><p>Specifies whether or not an Envoy sidecar should enable core dump.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -469,7 +490,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>An additional list of tags to extract from the in-proxy Istio Wasm telemetry. Each additional tag needs to be present in this list.</td>
|
||||
<td><p>An additional list of tags to extract from the in-proxy Istio Wasm telemetry. Each additional tag needs to be present in this list.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -490,7 +512,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not an Envoy sidecar should be automatically injected into the workload. Deprecated in favor of `sidecar.istio.io/inject` label.</td>
|
||||
<td><p>Specifies whether or not an Envoy sidecar should be automatically injected into the workload. Deprecated in favor of <code>sidecar.istio.io/inject</code> label.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -511,7 +534,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the mode used to redirect inbound connections to Envoy (REDIRECT or TPROXY).</td>
|
||||
<td><p>Specifies the mode used to redirect inbound connections to Envoy (REDIRECT or TPROXY).</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -532,7 +556,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the log level for Envoy.</td>
|
||||
<td><p>Specifies the log level for Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -553,7 +578,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the requested CPU setting for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the requested CPU setting for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -574,7 +600,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the CPU limit for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the CPU limit for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -595,7 +622,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the Docker image to be used by the Envoy sidecar.</td>
|
||||
<td><p>Specifies the Docker image to be used by the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -616,7 +644,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the Docker image type to be used by the Envoy sidecar. Istio publishes debug and distroless image types for every release tag.</td>
|
||||
<td><p>Specifies the Docker image type to be used by the Envoy sidecar. Istio publishes debug and distroless image types for every release tag.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -637,7 +666,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the requested memory setting for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the requested memory setting for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -658,7 +688,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the memory limit for the Envoy sidecar.</td>
|
||||
<td><p>Specifies the memory limit for the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -679,7 +710,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Rewrite HTTP readiness and liveness probes to be redirected to the Envoy sidecar.</td>
|
||||
<td><p>Rewrite HTTP readiness and liveness probes to be redirected to the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -700,7 +732,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the custom histogram buckets with a prefix matcher to separate the Istio mesh metrics from the Envoy stats, e.g. `{"istiocustom":[1,5,10,50,100,500,1000,5000,10000],"cluster.xds-grpc":[1,5,10,25,50,100,250,500,1000,2500,5000,10000]}`. Default buckets are `[0.5,1,5,10,25,50,100,250,500,1000,2500,5000,10000,30000,60000,300000,600000,1800000,3600000]`.</td>
|
||||
<td><p>Specifies the custom histogram buckets with a prefix matcher to separate the Istio mesh metrics from the Envoy stats, e.g. <code>{"istiocustom":[1,5,10,50,100,500,1000,5000,10000],"cluster.xds-grpc":[1,5,10,25,50,100,250,500,1000,2500,5000,10000]}</code>. Default buckets are <code>[0.5,1,5,10,25,50,100,250,500,1000,2500,5000,10000,30000,60000,300000,600000,1800000,3600000]</code>.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -721,7 +754,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the comma separated list of prefixes of the stats to be emitted by Envoy.</td>
|
||||
<td><p>Specifies the comma separated list of prefixes of the stats to be emitted by Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -742,7 +776,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the comma separated list of regexes the stats should match to be emitted by Envoy.</td>
|
||||
<td><p>Specifies the comma separated list of regexes the stats should match to be emitted by Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -763,7 +798,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the comma separated list of suffixes of the stats to be emitted by Envoy.</td>
|
||||
<td><p>Specifies the comma separated list of suffixes of the stats to be emitted by Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -784,7 +820,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Generated by Envoy sidecar injection that indicates the status of the operation. Includes a version hash of the executed template, as well as names of injected resources.</td>
|
||||
<td><p>Generated by Envoy sidecar injection that indicates the status of the operation. Includes a version hash of the executed template, as well as names of injected resources.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -805,7 +842,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies one or more user volumes (as a JSON array) to be added to the Envoy sidecar.</td>
|
||||
<td><p>Specifies one or more user volumes (as a JSON array) to be added to the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -826,7 +864,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies one or more user volume mounts (as a JSON array) to be added to the Envoy sidecar.</td>
|
||||
<td><p>Specifies one or more user volume mounts (as a JSON array) to be added to the Envoy sidecar.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -847,7 +886,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies the HTTP status Port for the Envoy sidecar. If zero, the sidecar will not provide status.</td>
|
||||
<td><p>Specifies the HTTP status Port for the Envoy sidecar. If zero, the sidecar will not provide status.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -868,7 +908,162 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma-separated list of clusters (or * for any) running istiod that should attempt leader election for a remote cluster thats system namespace includes this annotation. Istiod will not attempt to lead unannotated remote clusters.</td>
|
||||
<td><p>A comma-separated list of clusters (or * for any) running istiod that should attempt leader election for a remote cluster thats system namespace includes this annotation. Istiod will not attempt to lead unannotated remote clusters.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeInboundPorts">traffic.istio.io/excludeInboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeInboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of inbound ports to be excluded from redirection to Envoy. Only applies when all inbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeInterfaces">traffic.istio.io/excludeInterfaces</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeInterfaces</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of interfaces to be excluded from Istio traffic capture</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeOutboundIPRanges">traffic.istio.io/excludeOutboundIPRanges</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeOutboundIPRanges</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to be excluded from redirection. Only applies when all outbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficExcludeOutboundPorts">traffic.istio.io/excludeOutboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/excludeOutboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of outbound ports to be excluded from redirection to Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficIncludeInboundPorts">traffic.istio.io/includeInboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/includeInboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of inbound ports for which traffic is to be redirected to Envoy. The wildcard character ‘*’ can be used to configure redirection for all ports. An empty list will disable all inbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficIncludeOutboundIPRanges">traffic.istio.io/includeOutboundIPRanges</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/includeOutboundIPRanges</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to redirect to Envoy (optional). The wildcard character ‘*’ can be used to redirect all outbound traffic. An empty list will disable all outbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<h2 id="TrafficIncludeOutboundPorts">traffic.istio.io/includeOutboundPorts</h2>
|
||||
<table class="annotations">
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<td><code>traffic.istio.io/includeOutboundPorts</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Feature Status</th>
|
||||
<td>Alpha</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Resource Types</th>
|
||||
<td>[Pod]</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td><p>A comma separated list of outbound ports for which traffic is to be redirected to Envoy, regardless of the destination IP.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -889,7 +1084,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>This annotation is a set of node-labels (key1=value,key2=value). If the annotated Service is of type NodePort and is a multi-network gateway (see topology.istio.io/network), the addresses for selected nodes will be used for cross-network communication.</td>
|
||||
<td><p>This annotation is a set of node-labels (key1=value,key2=value). If the annotated Service is of type NodePort and is a multi-network gateway (see topology.istio.io/network), the addresses for selected nodes will be used for cross-network communication.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -910,7 +1106,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of inbound ports to be excluded from redirection to Envoy. Only applies when all inbound traffic (i.e. '*') is being redirected.</td>
|
||||
<td><p>A comma separated list of inbound ports to be excluded from redirection to Envoy. Only applies when all inbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -931,7 +1128,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of interfaces to be excluded from Istio traffic capture</td>
|
||||
<td><p>A comma separated list of interfaces to be excluded from Istio traffic capture</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -952,7 +1150,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of IP ranges in CIDR form to be excluded from redirection. Only applies when all outbound traffic (i.e. '*') is being redirected.</td>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to be excluded from redirection. Only applies when all outbound traffic (i.e. ‘*’) is being redirected.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -973,7 +1172,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of outbound ports to be excluded from redirection to Envoy.</td>
|
||||
<td><p>A comma separated list of outbound ports to be excluded from redirection to Envoy.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -994,7 +1194,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of inbound ports for which traffic is to be redirected to Envoy. The wildcard character '*' can be used to configure redirection for all ports. An empty list will disable all inbound redirection.</td>
|
||||
<td><p>A comma separated list of inbound ports for which traffic is to be redirected to Envoy. The wildcard character ‘*’ can be used to configure redirection for all ports. An empty list will disable all inbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -1015,7 +1216,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of IP ranges in CIDR form to redirect to Envoy (optional). The wildcard character '*' can be used to redirect all outbound traffic. An empty list will disable all outbound redirection.</td>
|
||||
<td><p>A comma separated list of IP ranges in CIDR form to redirect to Envoy (optional). The wildcard character ‘*’ can be used to redirect all outbound traffic. An empty list will disable all outbound redirection.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -1036,7 +1238,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of outbound ports for which traffic is to be redirected to Envoy, regardless of the destination IP.</td>
|
||||
<td><p>A comma separated list of outbound ports for which traffic is to be redirected to Envoy, regardless of the destination IP.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -1057,7 +1260,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A comma separated list of virtual interfaces whose inbound traffic (from VM) will be treated as outbound.</td>
|
||||
<td><p>A comma separated list of virtual interfaces whose inbound traffic (from VM) will be treated as outbound.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -7,7 +7,7 @@ location: https://istio.io/docs/reference/config/istio.mesh.v1alpha1.html
|
|||
layout: protoc-gen-docs
|
||||
generator: protoc-gen-docs
|
||||
weight: 20
|
||||
number_of_entries: 66
|
||||
number_of_entries: 73
|
||||
---
|
||||
<p>Configuration affecting the service mesh as a whole.</p>
|
||||
|
||||
|
|
@ -243,6 +243,19 @@ monitored. Can be overridden at a Sidecar level by setting the
|
|||
API</a>.
|
||||
Default mode is <code>ALLOW_ANY</code> which means outbound traffic to unknown destinations will be allowed.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-inbound_traffic_policy">
|
||||
<td><code>inboundTrafficPolicy</code></td>
|
||||
<td><code><a href="#MeshConfig-InboundTrafficPolicy">InboundTrafficPolicy</a></code></td>
|
||||
<td>
|
||||
<p>Set the default behavior of the sidecar for handling inbound
|
||||
traffic to the application. If your application listens on
|
||||
localhost, you will need to set this to <code>LOCALHOST</code>.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -725,6 +738,30 @@ No
|
|||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-InboundTrafficPolicy">MeshConfig.InboundTrafficPolicy</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-InboundTrafficPolicy-mode">
|
||||
<td><code>mode</code></td>
|
||||
<td><code><a href="#MeshConfig-InboundTrafficPolicy-Mode">Mode</a></code></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-CertificateData">MeshConfig.CertificateData</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
|
|
@ -1352,17 +1389,6 @@ No
|
|||
<p>Sets the HTTP status that is returned to the client when there is a network error to the authorization service.
|
||||
The default status is “403” (HTTP Forbidden).</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-EnvoyExternalAuthorizationHttpProvider-include_headers_in_check">
|
||||
<td><code>includeHeadersInCheck</code></td>
|
||||
<td><code>string[]</code></td>
|
||||
<td>
|
||||
<p>DEPRECATED. Use include_request_headers_in_check instead.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -1482,6 +1508,17 @@ except the presence match):</p>
|
|||
<li>Suffix match: “*abc” will match on value “abc” and “xabc”.</li>
|
||||
</ul>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-EnvoyExternalAuthorizationHttpProvider-include_headers_in_check" class="deprecated ">
|
||||
<td><code>includeHeadersInCheck</code></td>
|
||||
<td><code>string[]</code></td>
|
||||
<td>
|
||||
<p>DEPRECATED. Use include_request_headers_in_check instead.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -2280,6 +2317,208 @@ No
|
|||
<p>Optional. Controls the overall path length allowed in a reported span.
|
||||
NOTE: currently only controls max length of the path tag.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-OpenTelemetryTracingProvider-http">
|
||||
<td><code>http</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-HttpService">HttpService</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Specifies the configuration for exporting OTLP traces via HTTP.
|
||||
When empty, traces will be exported via gRPC.</p>
|
||||
<p>The following example shows how to configure the OpenTelemetry ExtensionProvider to export via HTTP:</p>
|
||||
<ol>
|
||||
<li>Add/change the OpenTelemetry extension provider in <code>MeshConfig</code></li>
|
||||
</ol>
|
||||
<pre><code class="language-yaml">- name: otel-tracing
|
||||
opentelemetry:
|
||||
port: 443
|
||||
service: my.olly-backend.com
|
||||
http:
|
||||
path: "/api/otlp/traces"
|
||||
timeout: 10s
|
||||
headers:
|
||||
- name: "my-custom-header"
|
||||
value: "some value"
|
||||
</code></pre>
|
||||
<ol start="2">
|
||||
<li>Deploy a <code>ServiceEntry</code> for the observability back-end</li>
|
||||
</ol>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: my-olly-backend
|
||||
spec:
|
||||
hosts:
|
||||
- my.olly-backend.com
|
||||
ports:
|
||||
- number: 443
|
||||
name: https-port
|
||||
protocol: HTTPS
|
||||
resolution: DNS
|
||||
location: MESH_EXTERNAL
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: my-olly-backend
|
||||
spec:
|
||||
host: my.olly-backend.com
|
||||
trafficPolicy:
|
||||
portLevelSettings:
|
||||
- port:
|
||||
number: 443
|
||||
tls:
|
||||
mode: SIMPLE
|
||||
</code></pre>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-OpenTelemetryTracingProvider-resource_detectors">
|
||||
<td><code>resourceDetectors</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-ResourceDetectors">ResourceDetectors</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Specifies <a href="https://opentelemetry.io/docs/specs/otel/resource/sdk/">Resource Detectors</a>
|
||||
to be used by the OpenTelemetry Tracer. When multiple resources are provided, they are merged
|
||||
according to the OpenTelemetry <a href="https://opentelemetry.io/docs/specs/otel/resource/sdk/#merge">Resource specification</a>.</p>
|
||||
<p>The following example shows how to configure the Environment Resource Detector, that will
|
||||
read the attributes from the environment variable <code>OTEL_RESOURCE_ATTRIBUTES</code>:</p>
|
||||
<pre><code class="language-yaml">- name: otel-tracing
|
||||
opentelemetry:
|
||||
port: 443
|
||||
service: my.olly-backend.com
|
||||
resource_detectors:
|
||||
environment: {}
|
||||
</code></pre>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-HttpService">MeshConfig.ExtensionProvider.HttpService</h2>
|
||||
<section>
|
||||
<p>Defines configuration for an HTTP service that can be used by an Extension Provider.
|
||||
that does communication via HTTP.</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpService-path">
|
||||
<td><code>path</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>REQUIRED. Specifies the path on the service.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpService-timeout">
|
||||
<td><code>timeout</code></td>
|
||||
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">Duration</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Specifies the timeout for the HTTP request.
|
||||
If not specified, the default is 3s.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpService-headers">
|
||||
<td><code>headers</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-HttpHeader">HttpHeader[]</a></code></td>
|
||||
<td>
|
||||
<p>Optional. Allows specifying custom HTTP headers that will be added
|
||||
to each HTTP request sent.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-HttpHeader">MeshConfig.ExtensionProvider.HttpHeader</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpHeader-name">
|
||||
<td><code>name</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>REQUIRED. The HTTP header name.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-HttpHeader-value">
|
||||
<td><code>value</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>REQUIRED. The HTTP header value.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-ResourceDetectors">MeshConfig.ExtensionProvider.ResourceDetectors</h2>
|
||||
<section>
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Field</th>
|
||||
<th>Type</th>
|
||||
<th>Description</th>
|
||||
<th>Required</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-ExtensionProvider-ResourceDetectors-environment">
|
||||
<td><code>environment</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-ResourceDetectors-EnvironmentResourceDetector">EnvironmentResourceDetector</a></code></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-ExtensionProvider-ResourceDetectors-dynatrace">
|
||||
<td><code>dynatrace</code></td>
|
||||
<td><code><a href="#MeshConfig-ExtensionProvider-ResourceDetectors-DynatraceResourceDetector">DynatraceResourceDetector</a></code></td>
|
||||
<td>
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -2422,6 +2661,22 @@ No
|
|||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-ResourceDetectors-EnvironmentResourceDetector">MeshConfig.ExtensionProvider.ResourceDetectors.EnvironmentResourceDetector</h2>
|
||||
<section>
|
||||
<p>OpenTelemetry Environment Resource Detector.
|
||||
The resource detector reads attributes from the environment variable <code>OTEL_RESOURCE_ATTRIBUTES</code>
|
||||
and adds them to the OpenTelemetry resource.</p>
|
||||
<p>See: <a href="https://opentelemetry.io/docs/specs/otel/resource/sdk/#specifying-resource-information-via-an-environment-variable">Resource specification</a></p>
|
||||
|
||||
</section>
|
||||
<h2 id="MeshConfig-ExtensionProvider-ResourceDetectors-DynatraceResourceDetector">MeshConfig.ExtensionProvider.ResourceDetectors.DynatraceResourceDetector</h2>
|
||||
<section>
|
||||
<p>Dynatrace Resource Detector.
|
||||
The resource detector reads from the Dynatrace enrichment files
|
||||
and adds host/process related attributes to the OpenTelemetry resource.</p>
|
||||
<p>See: <a href="https://docs.dynatrace.com/docs/shortlink/enrichment-files">Enrich ingested data with Dynatrace-specific dimensions</a></p>
|
||||
|
||||
</section>
|
||||
<h2 id="k8s-io-apimachinery-pkg-apis-meta-v1-LabelSelector">k8s.io.apimachinery.pkg.apis.meta.v1.LabelSelector</h2>
|
||||
<section>
|
||||
|
|
@ -3958,6 +4213,35 @@ service registry as well as those defined through ServiceEntries</p>
|
|||
<p>outbound traffic to unknown destinations will be allowed, in case
|
||||
there are no services or ServiceEntries for the destination port</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</section>
|
||||
<h2 id="MeshConfig-InboundTrafficPolicy-Mode">MeshConfig.InboundTrafficPolicy.Mode</h2>
|
||||
<section>
|
||||
<table class="enum-values">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr id="MeshConfig-InboundTrafficPolicy-Mode-PASSTHROUGH">
|
||||
<td><code>PASSTHROUGH</code></td>
|
||||
<td>
|
||||
<p>inbound traffic will be passed through to the destination listening
|
||||
on Pod IP. This matches the behavior without Istio enabled at all
|
||||
allowing proxy to be transparent.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="MeshConfig-InboundTrafficPolicy-Mode-LOCALHOST">
|
||||
<td><code>LOCALHOST</code></td>
|
||||
<td>
|
||||
<p>inbound traffic will be sent to the destinations listening on localhost.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
|
|
|
|||
|
|
@ -28,7 +28,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Istio control plane revision associated with the resource; e.g. `canary`</td>
|
||||
<td><p>Istio control plane revision associated with the resource; e.g. <code>canary</code></p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -49,7 +50,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>IstioGatewayPortLabel overrides the default 15443 value to use for a multi-network gateway's port</td>
|
||||
<td><p>IstioGatewayPortLabel overrides the default 15443 value to use for a multi-network gateway’s port</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -70,7 +72,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>The name of the canonical service a workload belongs to</td>
|
||||
<td><p>The name of the canonical service a workload belongs to</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -91,7 +94,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>The name of a revision within a canonical service that the workload belongs to</td>
|
||||
<td><p>The name of a revision within a canonical service that the workload belongs to</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -112,7 +116,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>Specifies whether or not an Envoy sidecar should be automatically injected into the workload.</td>
|
||||
<td><p>Specifies whether or not an Envoy sidecar should be automatically injected into the workload.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -133,7 +138,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>This label is applied to a workload internally that identifies the Kubernetes cluster containing the workload. The cluster ID is specified during Istio installation for each cluster via `values.global.multiCluster.clusterName`. It should be noted that this is only used internally within Istio and is not an actual label on workload pods. If a pod contains this label, it will be overridden by Istio internally with the cluster ID specified during Istio installation. This label provides a way to select workloads by cluster when using DestinationRules. For example, a service owner could create a DestinationRule containing a subset per cluster and then use these subsets to control traffic flow to each cluster independently.</td>
|
||||
<td><p>This label is applied to a workload internally that identifies the Kubernetes cluster containing the workload. The cluster ID is specified during Istio installation for each cluster via <code>values.global.multiCluster.clusterName</code>. It should be noted that this is only used internally within Istio and is not an actual label on workload pods. If a pod contains this label, it will be overridden by Istio internally with the cluster ID specified during Istio installation. This label provides a way to select workloads by cluster when using DestinationRules. For example, a service owner could create a DestinationRule containing a subset per cluster and then use these subsets to control traffic flow to each cluster independently.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -154,7 +160,37 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>A label used to identify the network for one or more pods. This is used<br>internally by Istio to group pods resident in the same L3 domain/network.<br>Istio assumes that pods in the same network are directly reachable from<br>one another. When pods are in different networks, an Istio Gateway<br>(e.g. east-west gateway) is typically used to establish connectivity<br>(with AUTO_PASSTHROUGH mode). This label can be applied to the following<br>resources to help automate Istio's multi-network configuration.<br><br>* Istio System Namespace: Applying this label to the system namespace<br> establishes a default network for pods managed by the control plane.<br> This is typically configured during control plane installation using an<br> admin-specified value.<br><br>* Pod: Applying this label to a pod allows overriding the default network<br> on a per-pod basis. This is typically applied to the pod via webhook<br> injection, but can also be manually specified on the pod by the service<br> owner. The Istio installation in each cluster configures webhook injection<br> using an admin-specified value.<br><br>* Gateway Service: Applying this label to the Service for an Istio Gateway,<br> indicates that Istio should use this service as the gateway for the<br> network, when configuring cross-network traffic. Istio will configure<br> pods residing outside of the network to access the Gateway service<br> via `spec.externalIPs`, `status.loadBalancer.ingress[].ip`, or in the case<br> of a NodePort service, the Node's address. The label is configured when<br> installing the gateway (e.g. east-west gateway) and should match either<br> the default network for the control plane (as specified by the Istio System<br> Namespace label) or the network of the targeted pods.</td>
|
||||
<td><p>A label used to identify the network for one or more pods. This is used
|
||||
internally by Istio to group pods resident in the same L3 domain/network.
|
||||
Istio assumes that pods in the same network are directly reachable from
|
||||
one another. When pods are in different networks, an Istio Gateway
|
||||
(e.g. east-west gateway) is typically used to establish connectivity
|
||||
(with AUTO_PASSTHROUGH mode). This label can be applied to the following
|
||||
resources to help automate Istio’s multi-network configuration.</p>
|
||||
|
||||
<ul>
|
||||
<li><p>Istio System Namespace: Applying this label to the system namespace
|
||||
establishes a default network for pods managed by the control plane.
|
||||
This is typically configured during control plane installation using an
|
||||
admin-specified value.</p></li>
|
||||
|
||||
<li><p>Pod: Applying this label to a pod allows overriding the default network
|
||||
on a per-pod basis. This is typically applied to the pod via webhook
|
||||
injection, but can also be manually specified on the pod by the service
|
||||
owner. The Istio installation in each cluster configures webhook injection
|
||||
using an admin-specified value.</p></li>
|
||||
|
||||
<li><p>Gateway Service: Applying this label to the Service for an Istio Gateway,
|
||||
indicates that Istio should use this service as the gateway for the
|
||||
network, when configuring cross-network traffic. Istio will configure
|
||||
pods residing outside of the network to access the Gateway service
|
||||
via <code>spec.externalIPs</code>, <code>status.loadBalancer.ingress[].ip</code>, or in the case
|
||||
of a NodePort service, the Node’s address. The label is configured when
|
||||
installing the gateway (e.g. east-west gateway) and should match either
|
||||
the default network for the control plane (as specified by the Istio System
|
||||
Namespace label) or the network of the targeted pods.</p></li>
|
||||
</ul>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -175,7 +211,8 @@ Istio supports to control its behavior.
|
|||
</tr>
|
||||
<tr>
|
||||
<th>Description</th>
|
||||
<td>User-provided node label for identifying the locality subzone of a workload. This allows admins to specify a more granular level of locality than what is offered by default with Kubernetes regions and zones.</td>
|
||||
<td><p>User-provided node label for identifying the locality subzone of a workload. This allows admins to specify a more granular level of locality than what is offered by default with Kubernetes regions and zones.</p>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -16,20 +16,6 @@ for load balancing, connection pool size from the sidecar, and outlier
|
|||
detection settings to detect and evict unhealthy hosts from the load
|
||||
balancing pool. For example, a simple load balancing policy for the
|
||||
ratings service would look as follows:</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -40,34 +26,11 @@ spec:
|
|||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Version specific policies can be specified by defining a named
|
||||
<code>subset</code> and overriding the settings specified at the service level. The
|
||||
following rule uses a round robin load balancing policy for all traffic
|
||||
going to a subset named testversion that is composed of endpoints (e.g.,
|
||||
pods) with labels (version:v3).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
subsets:
|
||||
- name: testversion
|
||||
labels:
|
||||
version: v3
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -85,35 +48,12 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p><strong>Note:</strong> Policies specified for subsets will not take effect until
|
||||
a route rule explicitly sends traffic to this subset.</p>
|
||||
<p>Traffic policies can be customized to specific ports as well. The
|
||||
following rule uses the least connection load balancing policy for all
|
||||
traffic to port 80, while uses a round robin load balancing setting for
|
||||
traffic to the port 9080.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings-port
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy: # Apply to all ports
|
||||
portLevelSettings:
|
||||
- port:
|
||||
number: 80
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
- port:
|
||||
number: 9080
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -131,34 +71,9 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Destination Rules can be customized to specific workloads as well.
|
||||
The following example shows how a destination rule can be applied to a
|
||||
specific workload using the workloadSelector configuration.</p>
|
||||
<p>{{<tabset category-name="selector-example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: configure-client-mtls-dr-with-workloadselector
|
||||
spec:
|
||||
host: example.com
|
||||
workloadSelector:
|
||||
matchLabels:
|
||||
app: ratings
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
portLevelSettings:
|
||||
- port:
|
||||
number: 31443
|
||||
tls:
|
||||
credentialName: client-credential
|
||||
mode: MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -178,8 +93,6 @@ spec:
|
|||
credentialName: client-credential
|
||||
mode: MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="DestinationRule">DestinationRule</h2>
|
||||
<section>
|
||||
|
|
@ -398,27 +311,6 @@ service-level can be overridden at a subset-level. The following rule
|
|||
uses a round robin load balancing policy for all traffic going to a
|
||||
subset named testversion that is composed of endpoints (e.g., pods) with
|
||||
labels (version:v3).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: LEAST_REQUEST
|
||||
subsets:
|
||||
- name: testversion
|
||||
labels:
|
||||
version: v3
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -436,8 +328,6 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p><strong>Note:</strong> Policies specified for subsets will not take effect until
|
||||
a route rule explicitly sends traffic to this subset.</p>
|
||||
<p>One or more labels are typically required to identify the subset destination,
|
||||
|
|
@ -505,20 +395,6 @@ load balancing
|
|||
for more details.</p>
|
||||
<p>For example, the following rule uses a round robin load balancing policy
|
||||
for all traffic going to the ratings service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -529,28 +405,9 @@ spec:
|
|||
loadBalancer:
|
||||
simple: ROUND_ROBIN
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example sets up sticky sessions for the ratings service
|
||||
hashing-based load balancer for the same ratings service using the
|
||||
the User cookie as the hash key.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-ratings
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
loadBalancer:
|
||||
consistentHash:
|
||||
httpCookie:
|
||||
name: user
|
||||
ttl: 0s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -564,8 +421,6 @@ spec:
|
|||
name: user
|
||||
ttl: 0s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -637,25 +492,6 @@ for more details. Connection pool settings can be applied at the TCP
|
|||
level as well as at HTTP level.</p>
|
||||
<p>For example, the following rule sets a limit of 100 connections to redis
|
||||
service called myredissrv with a connect timeout of 30ms</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: bookinfo-redis
|
||||
spec:
|
||||
host: myredissrv.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
connectionPool:
|
||||
tcp:
|
||||
maxConnections: 100
|
||||
connectTimeout: 30ms
|
||||
tcpKeepalive:
|
||||
time: 7200s
|
||||
interval: 75s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -671,8 +507,6 @@ spec:
|
|||
time: 7200s
|
||||
interval: 75s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -725,28 +559,6 @@ with no more than 10 req/connection to the “reviews” service. In add
|
|||
it sets a limit of 1000 concurrent HTTP2 requests and configures upstream
|
||||
hosts to be scanned every 5 mins so that any host that fails 7 consecutive
|
||||
times with a 502, 503, or 504 error code will be ejected for 15 minutes.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-cb-policy
|
||||
spec:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
connectionPool:
|
||||
tcp:
|
||||
maxConnections: 100
|
||||
http:
|
||||
http2MaxRequests: 1000
|
||||
maxRequestsPerConnection: 10
|
||||
outlierDetection:
|
||||
consecutive5xxErrors: 7
|
||||
interval: 5m
|
||||
baseEjectionTime: 15m
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -765,8 +577,6 @@ spec:
|
|||
interval: 5m
|
||||
baseEjectionTime: 15m
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -918,23 +728,6 @@ context</a>
|
|||
for more details. These settings are common to both HTTP and TCP upstreams.</p>
|
||||
<p>For example, the following rule configures a client to use mutual TLS
|
||||
for connections to upstream database cluster.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: db-mtls
|
||||
spec:
|
||||
host: mydbserver.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: MUTUAL
|
||||
clientCertificate: /etc/certs/myclientcert.pem
|
||||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -948,24 +741,8 @@ spec:
|
|||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following rule configures a client to use TLS when talking to a
|
||||
foreign service whose domain matches *.foo.com.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: tls-foo
|
||||
spec:
|
||||
host: "*.foo.com"
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: SIMPLE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -976,24 +753,8 @@ spec:
|
|||
tls:
|
||||
mode: SIMPLE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following rule configures a client to use Istio mutual TLS when talking
|
||||
to rating services.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: ratings-istio-mtls
|
||||
spec:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: ISTIO_MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -1004,8 +765,6 @@ spec:
|
|||
tls:
|
||||
mode: ISTIO_MUTUAL
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1145,6 +904,21 @@ SAN will be skipped.</p>
|
|||
be <code>true</code> by default in a later version where, going forward, it will be
|
||||
enabled by default.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="ClientTLSSettings-ca_crl">
|
||||
<td><code>caCrl</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>OPTIONAL: The path to the file containing the certificate revocation list (CRL)
|
||||
to use in verifying a presented server certificate. <code>CRL</code> is a list of certificates
|
||||
that have been revoked by the CA (Certificate Authority) before their scheduled expiration date.
|
||||
If specified, the proxy will verify if the presented certificate is part of the revoked list of certificates.
|
||||
If omitted, the proxy will not verify the certificate against the <code>crl</code>.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
@ -1272,6 +1046,7 @@ The following labels which have special semantic meaning are also supported:</p>
|
|||
<li><code>topology.kubernetes.io/region</code> is used to match the region metadata of an endpoint, which maps to Kubernetes node label <code>topology.kubernetes.io/region</code> or the deprecated label <code>failure-domain.beta.kubernetes.io/region</code>.</li>
|
||||
<li><code>topology.kubernetes.io/zone</code> is used to match the zone metadata of an endpoint, which maps to Kubernetes node label <code>topology.kubernetes.io/zone</code> or the deprecated label <code>failure-domain.beta.kubernetes.io/zone</code>.</li>
|
||||
<li><code>topology.istio.io/subzone</code> is used to match the subzone metadata of an endpoint, which maps to Istio node label <code>topology.istio.io/subzone</code>.</li>
|
||||
<li><code>kubernetes.io/hostname</code> is used to match the current node of an endpoint, which maps to Kubernetes node label <code>kubernetes.io/hostname</code>.</li>
|
||||
</ul>
|
||||
<p>The below topology config indicates the following priority levels:</p>
|
||||
<pre><code class="language-yaml">failoverPriority:
|
||||
|
|
|
|||
|
|
@ -20,61 +20,6 @@ as a load balancer exposing port 80 and 9080 (http), 443 (https),
|
|||
applied to the proxy running on a pod with labels <code>app: my-gateway-controller</code>. While Istio will configure the proxy to listen
|
||||
on these ports, it is the responsibility of the user to ensure that
|
||||
external traffic to these ports are allowed into the mesh.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-gateway
|
||||
namespace: some-config-namespace
|
||||
spec:
|
||||
selector:
|
||||
app: my-gateway-controller
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- uk.bookinfo.com
|
||||
- eu.bookinfo.com
|
||||
tls:
|
||||
httpsRedirect: true # sends 301 redirect for http requests
|
||||
- port:
|
||||
number: 443
|
||||
name: https-443
|
||||
protocol: HTTPS
|
||||
hosts:
|
||||
- uk.bookinfo.com
|
||||
- eu.bookinfo.com
|
||||
tls:
|
||||
mode: SIMPLE # enables HTTPS on this port
|
||||
serverCertificate: /etc/certs/servercert.pem
|
||||
privateKey: /etc/certs/privatekey.pem
|
||||
- port:
|
||||
number: 9443
|
||||
name: https-9443
|
||||
protocol: HTTPS
|
||||
hosts:
|
||||
- "bookinfo-namespace/*.bookinfo.com"
|
||||
tls:
|
||||
mode: SIMPLE # enables HTTPS on this port
|
||||
credentialName: bookinfo-secret # fetches certs from Kubernetes secret
|
||||
- port:
|
||||
number: 9080
|
||||
name: http-wildcard
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "*"
|
||||
- port:
|
||||
number: 2379 # to expose internal service via external port 2379
|
||||
name: mongo
|
||||
protocol: MONGO
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -126,8 +71,6 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The Gateway specification above describes the L4-L6 properties of a load
|
||||
balancer. A <code>VirtualService</code> can then be bound to a gateway to control
|
||||
the forwarding of traffic arriving at a particular host or gateway port.</p>
|
||||
|
|
@ -141,46 +84,6 @@ in the qa version. The same rule is also applicable inside the mesh for
|
|||
requests to the “reviews.prod.svc.cluster.local” service. This rule is
|
||||
applicable across ports 443, 9080. Note that <code>http://uk.bookinfo.com</code>
|
||||
gets redirected to <code>https://uk.bookinfo.com</code> (i.e. 80 redirects to 443).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-rule
|
||||
namespace: bookinfo-namespace
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
- uk.bookinfo.com
|
||||
- eu.bookinfo.com
|
||||
gateways:
|
||||
- some-config-namespace/my-gateway
|
||||
- mesh # applies to all the sidecars in the mesh
|
||||
http:
|
||||
- match:
|
||||
- headers:
|
||||
cookie:
|
||||
exact: "user=dev-123"
|
||||
route:
|
||||
- destination:
|
||||
port:
|
||||
number: 7777
|
||||
host: reviews.qa.svc.cluster.local
|
||||
- match:
|
||||
- uri:
|
||||
prefix: /reviews/
|
||||
route:
|
||||
- destination:
|
||||
port:
|
||||
number: 9080 # can be omitted if it's the only port for reviews
|
||||
host: reviews.prod.svc.cluster.local
|
||||
weight: 80
|
||||
- destination:
|
||||
host: reviews.qa.svc.cluster.local
|
||||
weight: 20
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -217,35 +120,10 @@ spec:
|
|||
host: reviews.qa.svc.cluster.local
|
||||
weight: 20
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following VirtualService forwards traffic arriving at (external)
|
||||
port 27017 to internal Mongo server on port 5555. This rule is not
|
||||
applicable internally in the mesh as the gateway list omits the
|
||||
reserved name <code>mesh</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-mongo
|
||||
namespace: bookinfo-namespace
|
||||
spec:
|
||||
hosts:
|
||||
- mongosvr.prod.svc.cluster.local # name of internal Mongo service
|
||||
gateways:
|
||||
- some-config-namespace/my-gateway # can omit the namespace if gateway is in same namespace as virtual service.
|
||||
tcp:
|
||||
- match:
|
||||
- port: 27017
|
||||
route:
|
||||
- destination:
|
||||
host: mongo.prod.svc.cluster.local
|
||||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -265,34 +143,11 @@ spec:
|
|||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is possible to restrict the set of virtual services that can bind to
|
||||
a gateway server using the namespace/hostname syntax in the hosts field.
|
||||
For example, the following Gateway allows any virtual service in the ns1
|
||||
namespace to bind to it, while restricting only the virtual service with
|
||||
foo.bar.com host in the ns2 namespace to bind to it.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-gateway
|
||||
namespace: some-config-namespace
|
||||
spec:
|
||||
selector:
|
||||
app: my-gateway-controller
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "ns1/*"
|
||||
- "ns2/foo.bar.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -310,8 +165,6 @@ spec:
|
|||
- "ns1/*"
|
||||
- "ns2/foo.bar.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="Gateway">Gateway</h2>
|
||||
<section>
|
||||
|
|
@ -368,25 +221,6 @@ No
|
|||
<section>
|
||||
<p><code>Server</code> describes the properties of the proxy on a given load balancer
|
||||
port. For example,</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-ingress
|
||||
spec:
|
||||
selector:
|
||||
app: my-ingressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http2
|
||||
protocol: HTTP2
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -402,28 +236,7 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Another example</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-tcp-ingress
|
||||
spec:
|
||||
selector:
|
||||
app: my-tcp-ingressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 27018
|
||||
name: mongo
|
||||
protocol: MONGO
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -439,31 +252,7 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following is an example of TLS configuration for port 443</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: my-tls-ingress
|
||||
spec:
|
||||
selector:
|
||||
app: my-tls-ingressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 443
|
||||
name: https
|
||||
protocol: HTTPS
|
||||
hosts:
|
||||
- "*"
|
||||
tls:
|
||||
mode: SIMPLE
|
||||
credentialName: tls-cert
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -482,8 +271,6 @@ spec:
|
|||
mode: SIMPLE
|
||||
credentialName: tls-cert
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -712,6 +499,21 @@ No
|
|||
containing certificate authority certificates to use in verifying a presented
|
||||
client side certificate.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="ServerTLSSettings-ca_crl">
|
||||
<td><code>caCrl</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>OPTIONAL: The path to the file containing the certificate revocation list (CRL)
|
||||
to use in verifying a presented client side certificate. <code>CRL</code> is a list of certificates
|
||||
that have been revoked by the CA (Certificate Authority) before their scheduled expiration date.
|
||||
If specified, the proxy will verify if the presented certificate is part of the revoked list of certificates.
|
||||
If omitted, the proxy will not verify the certificate against the <code>crl</code>.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
|
|||
|
|
@ -28,26 +28,6 @@ services.</p>
|
|||
<p>The following example declares a few external APIs accessed by internal
|
||||
applications over HTTPS. The sidecar inspects the SNI value in the
|
||||
ClientHello message to route to the appropriate external service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-https
|
||||
spec:
|
||||
hosts:
|
||||
- api.dropboxapi.com
|
||||
- www.googleapis.com
|
||||
- api.facebook.com
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 443
|
||||
name: https
|
||||
protocol: TLS
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -64,35 +44,10 @@ spec:
|
|||
protocol: TLS
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following configuration adds a set of MongoDB instances running on
|
||||
unmanaged VMs to Istio’s registry, so that these services can be treated
|
||||
as any other service in the mesh. The associated DestinationRule is used
|
||||
to initiate mTLS connections to the database instances.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-mongocluster
|
||||
spec:
|
||||
hosts:
|
||||
- mymongodb.somedomain # not used
|
||||
addresses:
|
||||
- 192.192.192.192/24 # VIPs
|
||||
ports:
|
||||
- number: 27018
|
||||
name: mongodb
|
||||
protocol: MONGO
|
||||
location: MESH_INTERNAL
|
||||
resolution: STATIC
|
||||
endpoints:
|
||||
- address: 2.2.2.2
|
||||
- address: 3.3.3.3
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -112,26 +67,7 @@ spec:
|
|||
- address: 2.2.2.2
|
||||
- address: 3.3.3.3
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>and the associated DestinationRule</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: mtls-mongocluster
|
||||
spec:
|
||||
host: mymongodb.somedomain
|
||||
trafficPolicy:
|
||||
tls:
|
||||
mode: MUTUAL
|
||||
clientCertificate: /etc/certs/myclientcert.pem
|
||||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -145,30 +81,9 @@ spec:
|
|||
privateKey: /etc/certs/client_private_key.pem
|
||||
caCertificates: /etc/certs/rootcacerts.pem
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example uses a combination of service entry and TLS
|
||||
routing in a virtual service to steer traffic based on the SNI value to
|
||||
an internal egress firewall.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-redirect
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
- "*.wikipedia.org"
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 443
|
||||
name: https
|
||||
protocol: TLS
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -184,30 +99,7 @@ spec:
|
|||
protocol: TLS
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated VirtualService to route based on the SNI value.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: tls-routing
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
- "*.wikipedia.org"
|
||||
tls:
|
||||
- match:
|
||||
- sniHosts:
|
||||
- wikipedia.org
|
||||
- "*.wikipedia.org"
|
||||
route:
|
||||
- destination:
|
||||
host: internal-egress-firewall.ns1.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -225,8 +117,6 @@ spec:
|
|||
- destination:
|
||||
host: internal-egress-firewall.ns1.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The virtual service with TLS match serves to override the default SNI
|
||||
match. In the absence of a virtual service, traffic will be forwarded to
|
||||
the wikipedia domains.</p>
|
||||
|
|
@ -237,27 +127,6 @@ declaration to other namespaces in the mesh. By default, a service is exported
|
|||
to all namespaces. The following example restricts the visibility to the
|
||||
current namespace, represented by “.”, so that it cannot be used by other
|
||||
namespaces.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-httpbin
|
||||
namespace : egress
|
||||
spec:
|
||||
hosts:
|
||||
- example.com
|
||||
exportTo:
|
||||
- "."
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -275,29 +144,7 @@ spec:
|
|||
protocol: HTTP
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Define a gateway to handle all egress traffic.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: istio-egressgateway
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
istio: egressgateway
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Gateway
|
||||
metadata:
|
||||
|
|
@ -314,47 +161,12 @@ spec:
|
|||
hosts:
|
||||
- "*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated <code>VirtualService</code> to route from the sidecar to the
|
||||
gateway service (<code>istio-egressgateway.istio-system.svc.cluster.local</code>), as
|
||||
well as route from the gateway to the external service. Note that the
|
||||
virtual service is exported to all namespaces enabling them to route traffic
|
||||
through the gateway to the external service. Forcing traffic to go through
|
||||
a managed middle proxy like this is a common practice.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: gateway-routing
|
||||
namespace: egress
|
||||
spec:
|
||||
hosts:
|
||||
- example.com
|
||||
exportTo:
|
||||
- "*"
|
||||
gateways:
|
||||
- mesh
|
||||
- istio-egressgateway
|
||||
http:
|
||||
- match:
|
||||
- port: 80
|
||||
gateways:
|
||||
- mesh
|
||||
route:
|
||||
- destination:
|
||||
host: istio-egressgateway.istio-system.svc.cluster.local
|
||||
- match:
|
||||
- port: 80
|
||||
gateways:
|
||||
- istio-egressgateway
|
||||
route:
|
||||
- destination:
|
||||
host: example.com
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -384,30 +196,10 @@ spec:
|
|||
- destination:
|
||||
host: example.com
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example demonstrates the use of wildcards in the hosts for
|
||||
external services. If the connection has to be routed to the IP address
|
||||
requested by the application (i.e. application resolves DNS and attempts
|
||||
to connect to a specific IP), the resolution mode must be set to <code>NONE</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-wildcard-example
|
||||
spec:
|
||||
hosts:
|
||||
- "*.bar.com"
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -422,31 +214,9 @@ spec:
|
|||
protocol: HTTP
|
||||
resolution: NONE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example demonstrates a service that is available via a
|
||||
Unix Domain Socket on the host of the client. The resolution must be
|
||||
set to STATIC to use Unix address endpoints.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: unix-domain-socket-example
|
||||
spec:
|
||||
hosts:
|
||||
- "example.unix.local"
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: STATIC
|
||||
endpoints:
|
||||
- address: unix:///var/run/example/socket
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -463,8 +233,6 @@ spec:
|
|||
endpoints:
|
||||
- address: unix:///var/run/example/socket
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>For HTTP-based services, it is possible to create a <code>VirtualService</code>
|
||||
backed by multiple DNS addressable endpoints. In such a scenario, the
|
||||
application can use the <code>HTTP_PROXY</code> environment variable to transparently
|
||||
|
|
@ -472,34 +240,6 @@ reroute API calls for the <code>VirtualService</code> to a chosen backend. For
|
|||
example, the following configuration creates a non-existent external
|
||||
service called foo.bar.com backed by three domains: us.foo.bar.com:8080,
|
||||
uk.foo.bar.com:9080, and in.foo.bar.com:7080</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-dns
|
||||
spec:
|
||||
hosts:
|
||||
- foo.bar.com
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: DNS
|
||||
endpoints:
|
||||
- address: us.foo.bar.com
|
||||
ports:
|
||||
http: 8080
|
||||
- address: uk.foo.bar.com
|
||||
ports:
|
||||
http: 9080
|
||||
- address: in.foo.bar.com
|
||||
ports:
|
||||
http: 7080
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -524,8 +264,6 @@ spec:
|
|||
ports:
|
||||
http: 7080
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>With <code>HTTP_PROXY=http://localhost/</code>, calls from the application to
|
||||
<code>http://foo.bar.com</code> will be load balanced across the three domains
|
||||
specified above. In other words, a call to <code>http://foo.bar.com/baz</code> would
|
||||
|
|
@ -533,30 +271,6 @@ be translated to <code>http://uk.foo.bar.com/baz</code>.</p>
|
|||
<p>The following example illustrates the usage of a <code>ServiceEntry</code>
|
||||
containing a subject alternate name
|
||||
whose format conforms to the <a href="https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md">SPIFFE standard</a>:</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace : httpbin-ns
|
||||
spec:
|
||||
hosts:
|
||||
- example.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: STATIC
|
||||
endpoints:
|
||||
- address: 2.2.2.2
|
||||
- address: 3.3.3.3
|
||||
subjectAltNames:
|
||||
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -577,8 +291,6 @@ spec:
|
|||
subjectAltNames:
|
||||
- "spiffe://cluster.local/ns/httpbin-ns/sa/httpbin-service-account"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example demonstrates the use of <code>ServiceEntry</code> with a
|
||||
<code>workloadSelector</code> to handle the migration of a service
|
||||
<code>details.bookinfo.com</code> from VMs to Kubernetes. The service has two
|
||||
|
|
@ -586,32 +298,6 @@ VM-based instances with sidecars as well as a set of Kubernetes
|
|||
pods managed by a standard deployment object. Consumers of this
|
||||
service in the mesh will be automatically load balanced across the
|
||||
VMs and Kubernetes.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-vm-1
|
||||
spec:
|
||||
serviceAccount: details
|
||||
address: 2.2.2.2
|
||||
labels:
|
||||
app: details
|
||||
instance-id: vm1
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-vm-2
|
||||
spec:
|
||||
serviceAccount: details
|
||||
address: 3.3.3.3
|
||||
labels:
|
||||
app: details
|
||||
instance-id: vm2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -634,33 +320,10 @@ spec:
|
|||
app: details
|
||||
instance-id: vm2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Assuming there is also a Kubernetes deployment with pod labels
|
||||
<code>app: details</code> using the same service account <code>details</code>, the
|
||||
following service entry declares a service spanning both VMs and
|
||||
Kubernetes:</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
hosts:
|
||||
- details.bookinfo.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
resolution: STATIC
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: details
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -678,8 +341,6 @@ spec:
|
|||
labels:
|
||||
app: details
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="ServiceEntry">ServiceEntry</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -48,21 +48,6 @@ in the root namespace called <code>istio-config</code>, that configures
|
|||
sidecars in all namespaces to allow egress traffic only to other
|
||||
workloads in the same namespace as well as to services in the
|
||||
<code>istio-system</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: default
|
||||
namespace: istio-config
|
||||
spec:
|
||||
egress:
|
||||
- hosts:
|
||||
- "./*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -74,29 +59,11 @@ spec:
|
|||
- "./*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The example below declares a <code>Sidecar</code> configuration in the
|
||||
<code>prod-us1</code> namespace that overrides the global default defined
|
||||
above, and configures the sidecars in the namespace to allow egress
|
||||
traffic to public services in the <code>prod-us1</code>, <code>prod-apis</code>, and the
|
||||
<code>istio-system</code> namespaces.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: default
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
egress:
|
||||
- hosts:
|
||||
- "prod-us1/*"
|
||||
- "prod-apis/*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -109,8 +76,6 @@ spec:
|
|||
- "prod-apis/*"
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares a <code>Sidecar</code> configuration in the
|
||||
<code>prod-us1</code> namespace for all pods with labels <code>app: ratings</code>
|
||||
belonging to the <code>ratings.prod-us1</code> service. The workload accepts
|
||||
|
|
@ -119,35 +84,6 @@ the attached workload instance listening on a Unix domain
|
|||
socket. In the egress direction, in addition to the <code>istio-system</code>
|
||||
namespace, the sidecar proxies only HTTP traffic bound for port
|
||||
9080 for services in the <code>prod-us1</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: ratings
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: ratings
|
||||
ingress:
|
||||
- port:
|
||||
number: 9080
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
defaultEndpoint: unix:///var/run/someuds.sock
|
||||
egress:
|
||||
- port:
|
||||
number: 9080
|
||||
protocol: HTTP
|
||||
name: egresshttp
|
||||
hosts:
|
||||
- "prod-us1/*"
|
||||
- hosts:
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -173,8 +109,6 @@ spec:
|
|||
- hosts:
|
||||
- "istio-system/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>If the workload is deployed without IPTables-based traffic capture,
|
||||
the <code>Sidecar</code> configuration is the only way to configure the ports
|
||||
on the proxy attached to the workload instance. The following
|
||||
|
|
@ -189,36 +123,6 @@ it to the application listening on <code>127.0.0.1:8080</code>. It also allows
|
|||
the application to communicate with a backing MySQL database on
|
||||
<code>127.0.0.1:3306</code>, that then gets proxied to the externally hosted
|
||||
MySQL service at <code>mysql.foo.com:3306</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: no-ip-tables
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: productpage
|
||||
ingress:
|
||||
- port:
|
||||
number: 9080 # binds to proxy_instance_ip:9080 (0.0.0.0:9080, if no unicast IP is available for the instance)
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
defaultEndpoint: 127.0.0.1:8080
|
||||
captureMode: NONE # not needed if metadata is set for entire proxy
|
||||
egress:
|
||||
- port:
|
||||
number: 3306
|
||||
protocol: MYSQL
|
||||
name: egressmysql
|
||||
captureMode: NONE # not needed if metadata is set for entire proxy
|
||||
bind: 127.0.0.1
|
||||
hosts:
|
||||
- "*/mysql.foo.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -245,28 +149,7 @@ spec:
|
|||
hosts:
|
||||
- "*/mysql.foo.com"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated service entry for routing to <code>mysql.foo.com:3306</code></p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-mysql
|
||||
namespace: ns1
|
||||
spec:
|
||||
hosts:
|
||||
- mysql.foo.com
|
||||
ports:
|
||||
- number: 3306
|
||||
name: mysql
|
||||
protocol: MYSQL
|
||||
location: MESH_EXTERNAL
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -282,8 +165,6 @@ spec:
|
|||
location: MESH_EXTERNAL
|
||||
resolution: DNS
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is also possible to mix and match traffic capture modes in a single
|
||||
proxy. For example, consider a setup where internal services are on the
|
||||
<code>192.168.0.0/16</code> subnet. So, IP tables are setup on the VM to capture all
|
||||
|
|
@ -295,36 +176,6 @@ listener on <code>172.16.1.32:80</code> (the VM’s IP) for traffic arriving
|
|||
<p><strong>NOTE</strong>: The <code>ISTIO_META_INTERCEPTION_MODE</code> metadata on the
|
||||
proxy in the VM should contain <code>REDIRECT</code> or <code>TPROXY</code> as its value,
|
||||
implying that IP tables based traffic capture is active.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: partial-ip-tables
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: productpage
|
||||
ingress:
|
||||
- bind: 172.16.1.32
|
||||
port:
|
||||
number: 80 # binds to 172.16.1.32:80
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
defaultEndpoint: 127.0.0.1:8080
|
||||
captureMode: NONE
|
||||
egress:
|
||||
# use the system detected defaults
|
||||
# sets up configuration to handle outbound traffic to services
|
||||
# in 192.168.0.0/16 subnet, based on information provided by the
|
||||
# service registry
|
||||
- captureMode: IPTABLES
|
||||
hosts:
|
||||
- "*/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -351,8 +202,6 @@ spec:
|
|||
hosts:
|
||||
- "*/*"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares a <code>Sidecar</code> configuration in the
|
||||
<code>prod-us1</code> namespace for all pods with labels <code>app: ratings</code>
|
||||
belonging to the <code>ratings.prod-us1</code> service. The service accepts
|
||||
|
|
@ -365,9 +214,7 @@ in order to set mTLS mode to “DISABLE” on specific
|
|||
ports.
|
||||
In this example, the mTLS mode is disabled on PORT 80.
|
||||
This feature is currently experimental.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: ratings
|
||||
|
|
@ -386,10 +233,8 @@ spec:
|
|||
mode: SIMPLE
|
||||
privateKey: "/etc/certs/privatekey.pem"
|
||||
serverCertificate: "/etc/certs/servercert.pem"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: v1
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: ratings
|
||||
|
|
@ -403,10 +248,8 @@ spec:
|
|||
targetPort: 80
|
||||
selector:
|
||||
app: ratings
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
name: ratings-peer-auth
|
||||
|
|
@ -421,8 +264,6 @@ spec:
|
|||
80:
|
||||
mode: DISABLE
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>In addition to configuring traffic capture and how traffic is forwarded to the app,
|
||||
it’s possible to control inbound connection pool settings. By default, Istio pushes
|
||||
connection pool settings from <code>DestinationRules</code> to both clients (for outbound
|
||||
|
|
@ -430,39 +271,6 @@ connections to the service) as well as servers (for inbound connections to a ser
|
|||
instance). Using the <code>InboundConnectionPool</code> and per-port <code>ConnectionPool</code> settings
|
||||
in a <code>Sidecar</code> allow you to control those connection pools for the server separately
|
||||
from the settings pushed to all clients.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
name: connection-pool-settings
|
||||
namespace: prod-us1
|
||||
spec:
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: productpage
|
||||
inboundConnectionPool:
|
||||
http:
|
||||
http1MaxPendingRequests: 1024
|
||||
http2MaxRequests: 1024
|
||||
maxRequestsPerConnection: 1024
|
||||
maxRetries: 100
|
||||
ingress:
|
||||
- port:
|
||||
number: 80
|
||||
protocol: HTTP
|
||||
name: somename
|
||||
connectionPool:
|
||||
http:
|
||||
http1MaxPendingRequests: 1024
|
||||
http2MaxRequests: 1024
|
||||
maxRequestsPerConnection: 1024
|
||||
maxRetries: 100
|
||||
tcp:
|
||||
maxConnections: 100
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: Sidecar
|
||||
metadata:
|
||||
|
|
@ -492,8 +300,6 @@ spec:
|
|||
tcp:
|
||||
maxConnections: 100
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="Sidecar">Sidecar</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -43,36 +43,6 @@ to be customized for specific client contexts.</p>
|
|||
pods of the reviews service with label “version: v1”. In addition,
|
||||
HTTP requests with path starting with /wpcatalog/ or /consumercatalog/ will
|
||||
be rewritten to /newcatalog and sent to pods with label “version: v2”.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- name: "reviews-v2-routes"
|
||||
match:
|
||||
- uri:
|
||||
prefix: "/wpcatalog"
|
||||
- uri:
|
||||
prefix: "/consumercatalog"
|
||||
rewrite:
|
||||
uri: "/newcatalog"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v2
|
||||
- name: "reviews-v1-route"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -99,29 +69,9 @@ spec:
|
|||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>A subset/version of a route destination is identified with a reference
|
||||
to a named service subset which must be declared in a corresponding
|
||||
<code>DestinationRule</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-destination
|
||||
spec:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -136,8 +86,6 @@ spec:
|
|||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="VirtualService">VirtualService</h2>
|
||||
<section>
|
||||
|
|
@ -301,35 +249,6 @@ domain names over short names.</em></p>
|
|||
<p>The following Kubernetes example routes all traffic by default to pods
|
||||
of the reviews service with label “version: v1” (i.e., subset v1), and
|
||||
some to subset v2, in a Kubernetes environment.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
namespace: foo
|
||||
spec:
|
||||
hosts:
|
||||
- reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
prefix: "/wpcatalog"
|
||||
- uri:
|
||||
prefix: "/consumercatalog"
|
||||
rewrite:
|
||||
uri: "/newcatalog"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subset: v2
|
||||
- route:
|
||||
- destination:
|
||||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -355,28 +274,7 @@ spec:
|
|||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated DestinationRule</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-destination
|
||||
namespace: foo
|
||||
spec:
|
||||
host: reviews # interpreted as reviews.foo.svc.cluster.local
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -392,8 +290,6 @@ spec:
|
|||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following VirtualService sets a timeout of 5s for all calls to
|
||||
productpage.prod.svc.cluster.local service in Kubernetes. Notice that
|
||||
there are no subsets defined in this rule. Istio will fetch all
|
||||
|
|
@ -403,24 +299,6 @@ that this rule is set in the istio-system namespace but uses the fully
|
|||
qualified domain name of the productpage service,
|
||||
productpage.prod.svc.cluster.local. Therefore the rule’s namespace does
|
||||
not have an impact in resolving the name of the productpage service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: my-productpage-rule
|
||||
namespace: istio-system
|
||||
spec:
|
||||
hosts:
|
||||
- productpage.prod.svc.cluster.local # ignores rule namespace
|
||||
http:
|
||||
- timeout: 5s
|
||||
route:
|
||||
- destination:
|
||||
host: productpage.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -435,44 +313,11 @@ spec:
|
|||
- destination:
|
||||
host: productpage.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>To control routing for traffic bound to services outside the mesh, external
|
||||
services must first be added to Istio’s internal service registry using the
|
||||
ServiceEntry resource. VirtualServices can then be defined to control traffic
|
||||
bound to these external services. For example, the following rules define a
|
||||
Service for wikipedia.org and set a timeout of 5s for HTTP requests.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: external-svc-wikipedia
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
location: MESH_EXTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: example-http
|
||||
protocol: HTTP
|
||||
resolution: DNS
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: my-wiki-rule
|
||||
spec:
|
||||
hosts:
|
||||
- wikipedia.org
|
||||
http:
|
||||
- timeout: 5s
|
||||
route:
|
||||
- destination:
|
||||
host: wikipedia.org
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -500,8 +345,6 @@ spec:
|
|||
- destination:
|
||||
host: wikipedia.org
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -892,36 +735,6 @@ The following VirtualService adds a <code>test</code> header with the value <cod
|
|||
to requests that are routed to any <code>reviews</code> service destination.
|
||||
It also removes the <code>foo</code> response header, but only from responses
|
||||
coming from the <code>v1</code> subset (version) of the <code>reviews</code> service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- headers:
|
||||
request:
|
||||
set:
|
||||
test: "true"
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v2
|
||||
weight: 25
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
headers:
|
||||
response:
|
||||
remove:
|
||||
- foo
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -948,8 +761,6 @@ spec:
|
|||
- foo
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -994,35 +805,6 @@ No
|
|||
traffic (TLS/HTTPS) The following routing rule forwards unterminated TLS
|
||||
traffic arriving at port 443 of gateway called “mygateway” to internal
|
||||
services in the mesh based on the SNI value.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-sni
|
||||
spec:
|
||||
hosts:
|
||||
- "*.bookinfo.com"
|
||||
gateways:
|
||||
- mygateway
|
||||
tls:
|
||||
- match:
|
||||
- port: 443
|
||||
sniHosts:
|
||||
- login.bookinfo.com
|
||||
route:
|
||||
- destination:
|
||||
host: login.prod.svc.cluster.local
|
||||
- match:
|
||||
- port: 443
|
||||
sniHosts:
|
||||
- reviews.bookinfo.com
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1048,8 +830,6 @@ spec:
|
|||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1094,26 +874,6 @@ No
|
|||
<p>Describes match conditions and actions for routing TCP traffic. The
|
||||
following routing rule forwards traffic arriving at port 27017 for
|
||||
mongo.prod.svc.cluster.local to another Mongo server on port 5555.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: bookinfo-mongo
|
||||
spec:
|
||||
hosts:
|
||||
- mongo.prod.svc.cluster.local
|
||||
tcp:
|
||||
- match:
|
||||
- port: 27017
|
||||
route:
|
||||
- destination:
|
||||
host: mongo.backup.svc.cluster.local
|
||||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1130,8 +890,6 @@ spec:
|
|||
port:
|
||||
number: 5555
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1178,29 +936,6 @@ rule to be applied to the HTTP request. For example, the following
|
|||
restricts the rule to match only requests where the URL path
|
||||
starts with /ratings/v2/ and the request contains a custom <code>end-user</code> header
|
||||
with value <code>jason</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- headers:
|
||||
end-user:
|
||||
exact: jason
|
||||
uri:
|
||||
prefix: "/ratings/v2/"
|
||||
ignoreUriCase: true
|
||||
route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1220,8 +955,6 @@ spec:
|
|||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>HTTPMatchRequest CANNOT be empty.
|
||||
<strong>Note:</strong></p>
|
||||
<ol>
|
||||
|
|
@ -1513,28 +1246,6 @@ determine the proportion of traffic it receives. For example, the
|
|||
following rule will route 25% of traffic for the “reviews” service to
|
||||
instances with the “v2” tag and the remaining traffic (i.e., 75%) to
|
||||
“v1”.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v2
|
||||
weight: 25
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1553,27 +1264,7 @@ spec:
|
|||
subset: v1
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>And the associated DestinationRule</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
name: reviews-destination
|
||||
spec:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subsets:
|
||||
- name: v1
|
||||
labels:
|
||||
version: v1
|
||||
- name: v2
|
||||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: DestinationRule
|
||||
metadata:
|
||||
|
|
@ -1588,31 +1279,9 @@ spec:
|
|||
labels:
|
||||
version: v2
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Traffic can also be split across two entirely different services without
|
||||
having to define new subsets. For example, the following rule forwards 25% of
|
||||
traffic to reviews.com to dev.reviews.com</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route-two-domains
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.com
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: dev.reviews.com
|
||||
weight: 25
|
||||
- destination:
|
||||
host: reviews.com
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1629,8 +1298,6 @@ spec:
|
|||
host: reviews.com
|
||||
weight: 75
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -1910,26 +1577,6 @@ where the Authority/Host and the URI in the response can be swapped with
|
|||
the specified values. For example, the following rule redirects
|
||||
requests for /v1/getProductRatings API on the ratings service to
|
||||
/v1/bookRatings provided by the bookratings service.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
redirect:
|
||||
uri: /v1/bookRatings
|
||||
authority: newratings.default.svc.cluster.local
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -1946,8 +1593,6 @@ spec:
|
|||
authority: newratings.default.svc.cluster.local
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2044,27 +1689,6 @@ No
|
|||
<p>HTTPDirectResponse can be used to send a fixed response to clients.
|
||||
For example, the following rule returns a fixed 503 status with a body
|
||||
to requests for /v1/getProductRatings API.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
directResponse:
|
||||
status: 503
|
||||
body:
|
||||
string: "unknown error"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2082,31 +1706,8 @@ spec:
|
|||
string: "unknown error"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is also possible to specify a binary response body.
|
||||
This is mostly useful for non text-based protocols such as gRPC.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
directResponse:
|
||||
status: 503
|
||||
body:
|
||||
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2124,36 +1725,9 @@ spec:
|
|||
bytes: "dW5rbm93biBlcnJvcg==" # "unknown error" in base64
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>It is good practice to add headers in the HTTPRoute
|
||||
as well as the direct_response, for example to specify
|
||||
the returned Content-Type.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
exact: /v1/getProductRatings
|
||||
directResponse:
|
||||
status: 503
|
||||
body:
|
||||
string: "{\"error\": \"unknown error\"}"
|
||||
headers:
|
||||
response:
|
||||
set:
|
||||
content-type: "application/json"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2175,8 +1749,6 @@ spec:
|
|||
content-type: "text/plain"
|
||||
...
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2258,28 +1830,6 @@ before forwarding the request to the destination. Rewrite primitive can
|
|||
be used only with HTTPRouteDestination. The following example
|
||||
demonstrates how to rewrite the URL prefix for api call (/ratings) to
|
||||
ratings service before making the actual API call.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
prefix: /ratings
|
||||
rewrite:
|
||||
uri: /v1/bookRatings
|
||||
route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2298,8 +1848,6 @@ spec:
|
|||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2452,27 +2000,6 @@ example, the following rule sets the maximum number of retries to 3 when
|
|||
calling ratings:v1 service, with a 2s timeout per retry attempt.
|
||||
A retry will be attempted if there is a connect-failure, refused_stream
|
||||
or when the upstream server responds with Service Unavailable(503).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
retries:
|
||||
attempts: 3
|
||||
perTryTimeout: 2s
|
||||
retryOn: connect-failure,refused-stream,503
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2490,8 +2017,6 @@ spec:
|
|||
perTryTimeout: 2s
|
||||
retryOn: gateway-error,connect-failure,refused-stream
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2572,33 +2097,6 @@ the following rule restricts cross origin requests to those originating
|
|||
from example.com domain using HTTP POST/GET, and sets the
|
||||
<code>Access-Control-Allow-Credentials</code> header to false. In addition, it only
|
||||
exposes <code>X-Foo-bar</code> header and sets an expiry period of 1 day.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
corsPolicy:
|
||||
allowOrigins:
|
||||
- exact: https://example.com
|
||||
allowMethods:
|
||||
- POST
|
||||
- GET
|
||||
allowCredentials: false
|
||||
allowHeaders:
|
||||
- X-Foo-Bar
|
||||
maxAge: "24h"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2622,8 +2120,6 @@ spec:
|
|||
- X-Foo-Bar
|
||||
maxAge: "24h"
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
@ -2917,31 +2413,6 @@ No
|
|||
forwarding path. The following example will introduce a 5 second delay
|
||||
in 1 out of every 1000 requests to the “v1” version of the “reviews”
|
||||
service from all pods with label env: prod</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: reviews-route
|
||||
spec:
|
||||
hosts:
|
||||
- reviews.prod.svc.cluster.local
|
||||
http:
|
||||
- match:
|
||||
- sourceLabels:
|
||||
env: prod
|
||||
route:
|
||||
- destination:
|
||||
host: reviews.prod.svc.cluster.local
|
||||
subset: v1
|
||||
fault:
|
||||
delay:
|
||||
percentage:
|
||||
value: 0.1
|
||||
fixedDelay: 5s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -2963,8 +2434,6 @@ spec:
|
|||
value: 0.1
|
||||
fixedDelay: 5s
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The <em>fixedDelay</em> field is used to indicate the amount of delay in seconds.
|
||||
The optional <em>percentage</em> field can be used to only delay a certain
|
||||
percentage of requests. If left unspecified, no request will be delayed.</p>
|
||||
|
|
@ -3024,28 +2493,6 @@ No
|
|||
<p>Abort specification is used to prematurely abort a request with a
|
||||
pre-specified error code. The following example will return an HTTP 400
|
||||
error code for 1 out of every 1000 requests to the “ratings” service “v1”.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: ratings-route
|
||||
spec:
|
||||
hosts:
|
||||
- ratings.prod.svc.cluster.local
|
||||
http:
|
||||
- route:
|
||||
- destination:
|
||||
host: ratings.prod.svc.cluster.local
|
||||
subset: v1
|
||||
fault:
|
||||
abort:
|
||||
percentage:
|
||||
value: 0.1
|
||||
httpStatus: 400
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
|
|
@ -3064,8 +2511,6 @@ spec:
|
|||
value: 0.1
|
||||
httpStatus: 400
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The <em>httpStatus</em> field is used to indicate the HTTP status code to
|
||||
return to the caller. The optional <em>percentage</em> field can be used to only
|
||||
abort a certain percentage of requests. If not specified, no request will be
|
||||
|
|
|
|||
|
|
@ -30,25 +30,6 @@ account. The service is exposed on port 80 to applications in the
|
|||
mesh. The HTTP traffic to this service is wrapped in Istio mutual
|
||||
TLS and sent to sidecars on VMs on target port 8080, that in turn
|
||||
forward it to the application on localhost on the same port.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
# use of the service account indicates that the workload has a
|
||||
# sidecar proxy bootstrapped with this service account. Pods with
|
||||
# sidecars will automatically communicate with the workload using
|
||||
# istio mutual TLS.
|
||||
serviceAccount: details-legacy
|
||||
address: 2.2.2.2
|
||||
labels:
|
||||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -64,31 +45,7 @@ spec:
|
|||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>and the associated service entry</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
hosts:
|
||||
- details.bookinfo.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
targetPort: 8080
|
||||
resolution: STATIC
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -107,32 +64,11 @@ spec:
|
|||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares the same VM workload using
|
||||
its fully qualified DNS name. The service entry’s resolution
|
||||
mode should be changed to DNS to indicate that the client-side
|
||||
sidecars should dynamically resolve the DNS name at runtime before
|
||||
forwarding the request.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
# use of the service account indicates that the workload has a
|
||||
# sidecar proxy bootstrapped with this service account. Pods with
|
||||
# sidecars will automatically communicate with the workload using
|
||||
# istio mutual TLS.
|
||||
serviceAccount: details-legacy
|
||||
address: vm1.vpc01.corp.net
|
||||
labels:
|
||||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -148,31 +84,7 @@ spec:
|
|||
app: details-legacy
|
||||
instance-id: vm1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>and the associated service entry</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
name: details-svc
|
||||
spec:
|
||||
hosts:
|
||||
- details.bookinfo.com
|
||||
location: MESH_INTERNAL
|
||||
ports:
|
||||
- number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
targetPort: 8080
|
||||
resolution: DNS
|
||||
workloadSelector:
|
||||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: ServiceEntry
|
||||
metadata:
|
||||
|
|
@ -191,28 +103,12 @@ spec:
|
|||
labels:
|
||||
app: details-legacy
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example declares a VM workload without an address.
|
||||
An alternative to having istiod read from remote API servers is
|
||||
to write a <code>WorkloadEntry</code> in the local cluster that represents
|
||||
the Workload(s) in the remote network with the given labels. A
|
||||
single <code>WorkloadEntry</code> with weights represent the aggregate of all
|
||||
the actual workloads in a given remote network.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
name: foo-workloads-cluster-2
|
||||
spec:
|
||||
serviceAccount: foo
|
||||
network: cluster-2-network
|
||||
labels:
|
||||
app: foo
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadEntry
|
||||
metadata:
|
||||
|
|
@ -223,8 +119,6 @@ spec:
|
|||
labels:
|
||||
app: foo
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="WorkloadEntry">WorkloadEntry</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -22,40 +22,6 @@ of workloads that will be registered under <code>reviews</code> in namespace
|
|||
instance during the bootstrap process, and the ports 3550 and 8080
|
||||
will be associated with the workload group and use service account <code>default</code>.
|
||||
<code>app.kubernetes.io/version</code> is just an arbitrary example of a label.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1alpha3" category-value="v1alpha3">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1alpha3
|
||||
kind: WorkloadGroup
|
||||
metadata:
|
||||
name: reviews
|
||||
namespace: bookinfo
|
||||
spec:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: reviews
|
||||
app.kubernetes.io/version: "1.3.4"
|
||||
template:
|
||||
ports:
|
||||
grpc: 3550
|
||||
http: 8080
|
||||
serviceAccount: default
|
||||
probe:
|
||||
initialDelaySeconds: 5
|
||||
timeoutSeconds: 3
|
||||
periodSeconds: 4
|
||||
successThreshold: 3
|
||||
failureThreshold: 3
|
||||
httpGet:
|
||||
path: /foo/bar
|
||||
host: 127.0.0.1
|
||||
port: 3100
|
||||
scheme: HTTPS
|
||||
httpHeaders:
|
||||
- name: Lit-Header
|
||||
value: Im-The-Best
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: networking.istio.io/v1beta1
|
||||
kind: WorkloadGroup
|
||||
metadata:
|
||||
|
|
@ -86,8 +52,6 @@ spec:
|
|||
- name: Lit-Header
|
||||
value: Im-The-Best
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="WorkloadGroup">WorkloadGroup</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -44,34 +44,6 @@ but it is useful to be explicit in the policy.</p>
|
|||
</ul>
|
||||
<p>when the request has a valid JWT token issued by <code>https://accounts.google.com</code>.</p>
|
||||
<p>Any other requests will be denied.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
action: ALLOW
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
principals: ["cluster.local/ns/default/sa/sleep"]
|
||||
- source:
|
||||
namespaces: ["test"]
|
||||
to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
paths: ["/info*"]
|
||||
- operation:
|
||||
methods: ["POST"]
|
||||
paths: ["/data"]
|
||||
when:
|
||||
- key: request.auth.claims[iss]
|
||||
values: ["https://accounts.google.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -96,30 +68,9 @@ spec:
|
|||
- key: request.auth.claims[iss]
|
||||
values: ["https://accounts.google.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following is another example that sets <code>action</code> to <code>DENY</code> to create a deny policy.
|
||||
It denies requests from the <code>dev</code> namespace to the <code>POST</code> method on all workloads
|
||||
in the <code>foo</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
action: DENY
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
namespaces: ["dev"]
|
||||
to:
|
||||
- operation:
|
||||
methods: ["POST"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -135,28 +86,9 @@ spec:
|
|||
- operation:
|
||||
methods: ["POST"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following is another example that sets <code>action</code> to <code>DENY</code> to create a deny policy.
|
||||
It denies all the requests with <code>POST</code> method on port <code>8080</code> on all workloads
|
||||
in the <code>foo</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
action: DENY
|
||||
rules:
|
||||
- to:
|
||||
- operation:
|
||||
methods: ["POST"]
|
||||
ports: ["8080"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -170,34 +102,12 @@ spec:
|
|||
methods: ["POST"]
|
||||
ports: ["8080"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>When this rule is applied to TCP traffic, the <code>method</code> field (as will all HTTP based attributes) cannot be processed.
|
||||
For a <code>DENY</code> rule, missing attributes are treated as matches. This means all TCP traffic on port <code>8080</code> would be denied in the example above.
|
||||
If we were to remove the <code>ports</code> match, all TCP traffic would be denied. As a result, it is recommended to always scope <code>DENY</code> policies to a specific port,
|
||||
especially when using HTTP attributes <a href="/latest/docs/tasks/security/authorization/authz-tcp/">Authorization Policy for TCP Ports</a>.</p>
|
||||
<p>The following authorization policy sets the <code>action</code> to <code>AUDIT</code>. It will audit any <code>GET</code> requests to the path with the
|
||||
prefix <code>/user/profile</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
namespace: ns1
|
||||
name: anyname
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: myapi
|
||||
action: AUDIT
|
||||
rules:
|
||||
- to:
|
||||
- operation:
|
||||
methods: ["GET"]
|
||||
paths: ["/user/profile/*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -214,8 +124,6 @@ spec:
|
|||
methods: ["GET"]
|
||||
paths: ["/user/profile/*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>Authorization Policy scope (target) is determined by “metadata/namespace” and
|
||||
an optional <code>selector</code>.</p>
|
||||
<ul>
|
||||
|
|
@ -225,18 +133,6 @@ namespace, the policy applies to all namespaces in a mesh.</li>
|
|||
</ul>
|
||||
<p>For example, the following authorization policy applies to all workloads in namespace <code>foo</code>. It allows nothing and effectively denies
|
||||
all requests to workloads in namespace <code>foo</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-nothing
|
||||
namespace: foo
|
||||
spec:
|
||||
{}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -245,22 +141,7 @@ metadata:
|
|||
spec:
|
||||
{}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following authorization policy allows all requests to workloads in namespace <code>foo</code>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-all
|
||||
namespace: foo
|
||||
spec:
|
||||
rules:
|
||||
- {}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -270,24 +151,8 @@ spec:
|
|||
rules:
|
||||
- {}
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following authorization policy applies to workloads containing label <code>app: httpbin</code> in namespace <code>bar</code>. It allows
|
||||
nothing and effectively denies all requests to the selected workloads.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-nothing
|
||||
namespace: bar
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -298,24 +163,8 @@ spec:
|
|||
matchLabels:
|
||||
app: httpbin
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following authorization policy applies to workloads containing label <code>version: v1</code> in all namespaces in the mesh.
|
||||
(Assuming the root namespace is configured to <code>istio-system</code>).</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: allow-nothing
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
version: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -326,33 +175,11 @@ spec:
|
|||
matchLabels:
|
||||
version: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>The following example shows you how to set up an authorization policy using an <a href="/latest/docs/reference/config/annotations/">experimental annotation</a>
|
||||
<code>istio.io/dry-run</code> to dry-run the policy without actually enforcing it.</p>
|
||||
<p>The dry-run annotation allows you to better understand the effect of an authorization policy before applying it to the production traffic.
|
||||
This helps to reduce the risk of breaking the production traffic caused by an incorrect authorization policy.
|
||||
For more information, see <a href="/latest/docs/tasks/security/authorization/authz-dry-run/">dry-run tasks</a>.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: dry-run-example
|
||||
annotations:
|
||||
"istio.io/dry-run": "true"
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
action: DENY
|
||||
rules:
|
||||
- to:
|
||||
- operation:
|
||||
paths: ["/headers"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -369,8 +196,6 @@ spec:
|
|||
- operation:
|
||||
paths: ["/headers"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<h2 id="AuthorizationPolicy">AuthorizationPolicy</h2>
|
||||
<section>
|
||||
|
|
|
|||
|
|
@ -205,6 +205,18 @@ The header specified in each operation in the list must be unique. Nested claims
|
|||
</code></pre>
|
||||
<p>[Experimental] This feature is a experimental feature.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="JWTRule-timeout">
|
||||
<td><code>timeout</code></td>
|
||||
<td><code><a href="https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#duration">Duration</a></code></td>
|
||||
<td>
|
||||
<p>The maximum amount of time that the resolver, determined by the PILOT_JWT_ENABLE_REMOTE_JWKS environment variable,
|
||||
will spend waiting for the JWKS to be fetched. Default is 5s.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ spec:
|
|||
mode: STRICT
|
||||
</code></pre>
|
||||
<p>For mesh level, put the policy in root-namespace according to your Istio installation.</p>
|
||||
<p>Policies to allow both mTLS & plaintext traffic for all workloads under namespace <code>foo</code>, but
|
||||
<p>Policies to allow both mTLS and plaintext traffic for all workloads under namespace <code>foo</code>, but
|
||||
require mTLS for workload <code>finance</code>.</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
|
|
@ -48,8 +48,9 @@ spec:
|
|||
mtls:
|
||||
mode: STRICT
|
||||
</code></pre>
|
||||
<p>Policy to allow mTLS strict for all workloads, but leave port 8080 to
|
||||
plaintext:</p>
|
||||
<p>Policy that enables strict mTLS for all workloads, but leaves the port <code>8080</code> to
|
||||
plaintext. Note the port value in the <code>portLevelMtls</code> field refers to the port
|
||||
of the workload, not the port of the Kubernetes service.</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
|
|
@ -65,8 +66,8 @@ spec:
|
|||
8080:
|
||||
mode: DISABLE
|
||||
</code></pre>
|
||||
<p>Policy to inherit mTLS mode from namespace (or mesh) settings, and overwrite
|
||||
settings for port 8080</p>
|
||||
<p>Policy that inherits mTLS mode from namespace (or mesh) settings, and disables
|
||||
mTLS for workload port <code>8080</code>.</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: PeerAuthentication
|
||||
metadata:
|
||||
|
|
@ -123,7 +124,8 @@ No
|
|||
<td><code>map<uint32, <a href="#PeerAuthentication-MutualTLS">MutualTLS</a>></code></td>
|
||||
<td>
|
||||
<p>Port specific mutual TLS settings. These only apply when a workload selector
|
||||
is specified.</p>
|
||||
is specified. The port refers to the port of the workload, not the port of the
|
||||
Kubernetes service.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
|
@ -174,7 +176,7 @@ No
|
|||
<tr id="PeerAuthentication-MutualTLS-Mode-UNSET">
|
||||
<td><code>UNSET</code></td>
|
||||
<td>
|
||||
<p>Inherit from parent, if has one. Otherwise treated as PERMISSIVE.</p>
|
||||
<p>Inherit from parent, if has one. Otherwise treated as <code>PERMISSIVE</code>.</p>
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -21,37 +21,6 @@ Examples:</p>
|
|||
<ul>
|
||||
<li>Require JWT for all request for workloads that have label <code>app:httpbin</code></li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
jwtRules:
|
||||
- issuer: "issuer-foo"
|
||||
jwksUri: https://example.com/.well-known/jwks.json
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -79,38 +48,11 @@ spec:
|
|||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<ul>
|
||||
<li>A policy in the root namespace (“istio-system” by default) applies to workloads in all namespaces
|
||||
in a mesh. The following policy makes all workloads only accept requests that contain a
|
||||
valid JWT token.</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: req-authn-for-all
|
||||
namespace: istio-system
|
||||
spec:
|
||||
jwtRules:
|
||||
- issuer: "issuer-foo"
|
||||
jwksUri: https://example.com/.well-known/jwks.json
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: require-jwt-for-all
|
||||
namespace: istio-system
|
||||
spec:
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -132,53 +74,11 @@ spec:
|
|||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<ul>
|
||||
<li>The next example shows how to set a different JWT requirement for a different <code>host</code>. The <code>RequestAuthentication</code>
|
||||
declares it can accept JWTs issued by either <code>issuer-foo</code> or <code>issuer-bar</code> (the public key set is implicitly
|
||||
set from the OpenID Connect spec).</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
jwtRules:
|
||||
- issuer: "issuer-foo"
|
||||
- issuer: "issuer-bar"
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["issuer-foo/*"]
|
||||
to:
|
||||
- operation:
|
||||
hosts: ["example.com"]
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["issuer-bar/*"]
|
||||
to:
|
||||
- operation:
|
||||
hosts: ["another-host.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -215,34 +115,11 @@ spec:
|
|||
- operation:
|
||||
hosts: ["another-host.com"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<ul>
|
||||
<li>You can fine tune the authorization policy to set different requirement per path. For example,
|
||||
to require JWT on all paths, except /healthz, the same <code>RequestAuthentication</code> can be used, but the
|
||||
authorization policy could be:</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: httpbin
|
||||
namespace: foo
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: httpbin
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
- to:
|
||||
- operation:
|
||||
paths: ["/healthz"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -260,8 +137,6 @@ spec:
|
|||
- operation:
|
||||
paths: ["/healthz"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
<p>[Experimental] Routing based on derived <a href="/latest/docs/reference/config/security/conditions/">metadata</a>
|
||||
is now supported. A prefix ‘@’ is used to denote a match against internal metadata instead of the headers in the request.
|
||||
Currently this feature is only supported for the following metadata:</p>
|
||||
|
|
@ -277,62 +152,6 @@ For more information, see <a href="/latest/docs/tasks/security/authentication/jw
|
|||
<li>AuthorizationPolicy to check for valid principals in the request. This makes the JWT required for the request.</li>
|
||||
<li>VirtualService to route the request based on the “sub” claim.</li>
|
||||
</ul>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1beta1" category-value="v1beta1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1beta1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
name: jwt-on-ingress
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: istio-ingressgateway
|
||||
jwtRules:
|
||||
- issuer: "example.com"
|
||||
jwksUri: https://example.com/.well-known/jwks.json
|
||||
---
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
name: require-jwt
|
||||
namespace: istio-system
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
app: istio-ingressgateway
|
||||
rules:
|
||||
- from:
|
||||
- source:
|
||||
requestPrincipals: ["*"]
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: route-jwt
|
||||
spec:
|
||||
hosts:
|
||||
- foo.prod.svc.cluster.local
|
||||
gateways:
|
||||
- istio-ingressgateway
|
||||
http:
|
||||
- name: "v2"
|
||||
match:
|
||||
- headers:
|
||||
"@request.auth.claims.sub":
|
||||
exact: "dev"
|
||||
route:
|
||||
- destination:
|
||||
host: foo.prod.svc.cluster.local
|
||||
subset: v2
|
||||
- name: "default"
|
||||
route:
|
||||
- destination:
|
||||
host: foo.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}</p>
|
||||
<p>{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: RequestAuthentication
|
||||
metadata:
|
||||
|
|
@ -385,8 +204,6 @@ spec:
|
|||
host: foo.prod.svc.cluster.local
|
||||
subset: v1
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
|
|||
|
|
@ -85,8 +85,6 @@ Telemetry, and WasmPlugin CRDs to target a Kubernetes Gateway.</p>
|
|||
a PolicyTargetReference. The example sets <code>action</code> to <code>DENY</code> to create a deny policy.
|
||||
It denies all the requests with <code>POST</code> method on port <code>8080</code> directed through the
|
||||
<code>waypoint</code> Gateway in the <code>foo</code> namespace.</p>
|
||||
<p>{{<tabset category-name="example">}}
|
||||
{{<tab name="v1" category-value="v1">}}</p>
|
||||
<pre><code class="language-yaml">apiVersion: security.istio.io/v1
|
||||
kind: AuthorizationPolicy
|
||||
metadata:
|
||||
|
|
@ -104,8 +102,6 @@ spec:
|
|||
methods: ["POST"]
|
||||
ports: ["8080"]
|
||||
</code></pre>
|
||||
<p>{{</tab>}}
|
||||
{{</tabset>}}</p>
|
||||
|
||||
<table class="message-fields">
|
||||
<thead>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
features:
|
||||
- name: "Protocols:HTTP1.1/HTTP2/gRPC/TCP"
|
||||
id: "traffic.http_protocols"
|
||||
link: "/docs/ops/configuration/traffic-management/protocol-selection/"
|
||||
level:
|
||||
checklist: features/protocol-support.md
|
||||
maturity: Stable
|
||||
|
|
|
|||
Loading…
Reference in New Issue