mirror of https://github.com/istio/istio.io.git
Automator: update istio.io@master reference docs (#6394)
This commit is contained in:
parent
c5c11e10ff
commit
cdd2fc6b29
|
@ -121,6 +121,11 @@ debug and diagnose their Istio mesh.
|
|||
<td>The severity level of analysis at which to display messages. Valid values: [Info Warn Error] (default `Info`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--recursive</code></td>
|
||||
<td><code>-R</code></td>
|
||||
<td>Process directory arguments recursively. Useful when you want to analyze related manifests organized within the same directory. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--suppress <stringArray></code></td>
|
||||
<td><code>-S</code></td>
|
||||
<td>Suppress reporting a message code on a specific resource. Values are supplied in the form <code>=<resource> (e.g. '--suppress "IST0102=DestinationRule primary-dr.default"'). Can be repeated. You can include the wildcard character '*' to support a partial match (e.g. '--suppress "IST0102=DestinationRule *.default" ). (default `[]`)</td>
|
||||
|
@ -148,10 +153,13 @@ debug and diagnose their Istio mesh.
|
|||
istioctl analyze
|
||||
|
||||
# Analyze the current live cluster, simulating the effect of applying additional yaml files
|
||||
istioctl analyze a.yaml b.yaml
|
||||
istioctl analyze a.yaml b.yaml my-app-config/
|
||||
|
||||
# Analyze the current live cluster, simulating the effect of applying a directory of config recursively
|
||||
istioctl analyze --recursive my-istio-config/
|
||||
|
||||
# Analyze yaml files without connecting to a live cluster
|
||||
istioctl analyze --use-kube=false a.yaml b.yaml
|
||||
istioctl analyze --use-kube=false a.yaml b.yaml my-app-config/
|
||||
|
||||
# Analyze the current live cluster and suppress PodMissingProxy for pod mypod in namespace 'testing'.
|
||||
istioctl analyze -S "IST0103=Pod mypod.testing"
|
||||
|
@ -1173,6 +1181,11 @@ THIS COMMAND IS STILL UNDER ACTIVE DEVELOPMENT AND NOT READY FOR PRODUCTION USE.
|
|||
<td>The severity level of analysis at which to display messages. Valid values: [Info Warn Error] (default `Info`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--recursive</code></td>
|
||||
<td><code>-R</code></td>
|
||||
<td>Process directory arguments recursively. Useful when you want to analyze related manifests organized within the same directory. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--suppress <stringArray></code></td>
|
||||
<td><code>-S</code></td>
|
||||
<td>Suppress reporting a message code on a specific resource. Values are supplied in the form <code>=<resource> (e.g. '--suppress "IST0102=DestinationRule primary-dr.default"'). Can be repeated. You can include the wildcard character '*' to support a partial match (e.g. '--suppress "IST0102=DestinationRule *.default" ). (default `[]`)</td>
|
||||
|
@ -1200,10 +1213,13 @@ THIS COMMAND IS STILL UNDER ACTIVE DEVELOPMENT AND NOT READY FOR PRODUCTION USE.
|
|||
istioctl analyze
|
||||
|
||||
# Analyze the current live cluster, simulating the effect of applying additional yaml files
|
||||
istioctl analyze a.yaml b.yaml
|
||||
istioctl analyze a.yaml b.yaml my-app-config/
|
||||
|
||||
# Analyze the current live cluster, simulating the effect of applying a directory of config recursively
|
||||
istioctl analyze --recursive my-istio-config/
|
||||
|
||||
# Analyze yaml files without connecting to a live cluster
|
||||
istioctl analyze --use-kube=false a.yaml b.yaml
|
||||
istioctl analyze --use-kube=false a.yaml b.yaml my-app-config/
|
||||
|
||||
# Analyze the current live cluster and suppress PodMissingProxy for pod mypod in namespace 'testing'.
|
||||
istioctl analyze -S "IST0103=Pod mypod.testing"
|
||||
|
|
|
@ -241,7 +241,7 @@ remove_toc_prefix: 'pilot-agent '
|
|||
</tr>
|
||||
<tr>
|
||||
<td><code>--tokenManagerPlugin <string></code></td>
|
||||
<td>Token provider specific plugin name. (default ``)</td>
|
||||
<td>Token provider specific plugin name. (default `GoogleTokenExchange`)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>--trust-domain <string></code></td>
|
||||
|
|
|
@ -1159,6 +1159,19 @@ No
|
|||
<p>withoutHeader has the same syntax with the header, but has opposite meaning.
|
||||
If a header is matched with a matching rule among withoutHeader, the traffic becomes not matched one.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="HTTPMatchRequest-source_namespace">
|
||||
<td><code>sourceNamespace</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>Source namespace constraining the applicability of a rule to workloads in that namespace.
|
||||
If the VirtualService has a list of gateways specified in the top-level <code>gateways</code> field,
|
||||
it must include the reserved gateway <code>mesh</code> for this field to be applicable.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
@ -2002,6 +2015,19 @@ No
|
|||
in the top-level <code>gateways</code> field of the VirtualService (if any) are overridden. The gateway
|
||||
match is independent of sourceLabels.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="L4MatchAttributes-source_namespace">
|
||||
<td><code>sourceNamespace</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>Source namespace constraining the applicability of a rule to workloads in that namespace.
|
||||
If the VirtualService has a list of gateways specified in the top-level <code>gateways</code> field,
|
||||
it must include the reserved gateway <code>mesh</code> for this field to be applicable.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
@ -2322,6 +2348,19 @@ No
|
|||
in the top-level <code>gateways</code> field of the VirtualService (if any) are overridden. The gateway
|
||||
match is independent of sourceLabels.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
</td>
|
||||
</tr>
|
||||
<tr id="TLSMatchAttributes-source_namespace">
|
||||
<td><code>sourceNamespace</code></td>
|
||||
<td><code>string</code></td>
|
||||
<td>
|
||||
<p>Source namespace constraining the applicability of a rule to workloads in that namespace.
|
||||
If the VirtualService has a list of gateways specified in the top-level <code>gateways</code> field,
|
||||
it must include the reserved gateway <code>mesh</code> for this field to be applicable.</p>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
No
|
||||
|
|
|
@ -26,8 +26,8 @@ that provides sophisticated access control mechanisms.</p>
|
|||
- |+
|
||||
package mixerauthz
|
||||
policy = [
|
||||
{
|
||||
"rule": {
|
||||
{
|
||||
"rule": {
|
||||
"verbs": [
|
||||
"storage.buckets.get"
|
||||
],
|
||||
|
@ -40,7 +40,7 @@ that provides sophisticated access control mechanisms.</p>
|
|||
|
||||
default allow = false
|
||||
|
||||
allow = true {
|
||||
allow = true {
|
||||
rule = policy[_].rule
|
||||
input.subject.user = rule.users[_]
|
||||
input.action.method = rule.verbs[_]
|
||||
|
|
|
@ -425,7 +425,7 @@ No
|
|||
<section>
|
||||
<p>Describes the expiration policy for metrics generated by a prometheus handler.</p>
|
||||
|
||||
<p>Example: A Metrics Expiration Policy of <code>{ metrics_expiry_duration: "10m", expiry_check_interval_duration: "1m" }</code>
|
||||
<p>Example: A Metrics Expiration Policy of <code>{ metrics_expiry_duration: "10m", expiry_check_interval_duration: "1m" }</code>
|
||||
would configure the handler to delete all metrics that have received no updtaes for 10 minutes. Metrics would be checked
|
||||
every minute to determine whether or not they should be expired.</p>
|
||||
|
||||
|
|
|
@ -78,7 +78,7 @@ spec:
|
|||
- destination_version
|
||||
logs:
|
||||
solarwindslogentry.logentry.istio-system:
|
||||
payloadTemplate: '{{or (.originIp) "-"}} - {{or (.sourceUser) "-"}} [{{or (.timestamp.Format "2006-01-02T15:04:05Z07:00") "-"}}] "{{or (.method) "-"}} {{or (.url) "-"}} {{or (.protocol) "-"}}" {{or (.responseCode) "-"}} {{or (.responseSize) "-"}}'
|
||||
payloadTemplate: '{{or (.originIp) "-"}} - {{or (.sourceUser) "-"}} [{{or (.timestamp.Format "2006-01-02T15:04:05Z07:00") "-"}}] "{{or (.method) "-"}} {{or (.url) "-"}} {{or (.protocol) "-"}}" {{or (.responseCode) "-"}} {{or (.responseSize) "-"}}'
|
||||
</code></pre>
|
||||
|
||||
<table class="message-fields">
|
||||
|
@ -187,7 +187,7 @@ No
|
|||
found here: https://golang.org/pkg/text/template/) that will be executed to construct the payload for
|
||||
this log entry.
|
||||
An example template that could be used:
|
||||
{{or (.originIp) “-”}} - {{or (.sourceUser) “-”}} [{{or (.timestamp.Format “2006-01-02T15:04:05Z07:00”) “-”}}] “{{or (.method) “-”}} {{or (.url) “-”}} {{or (.protocol) “-”}}” {{or (.responseCode) “-”}} {{or (.responseSize) “-”}}
|
||||
{{or (.originIp) “-”}} - {{or (.sourceUser) “-”}} [{{or (.timestamp.Format “2006-01-02T15:04:05Z07:00”) “-”}}] “{{or (.method) “-”}} {{or (.url) “-”}} {{or (.protocol) “-”}}” {{or (.responseCode) “-”}} {{or (.responseSize) “-”}}
|
||||
A sample log that will be created after parsing the template with appropriate variables will look like this:
|
||||
Jan 23 21:53:02 istio-mixer-57d88dc4b4-rbgmc istio: 10.32.0.15 - kubernetes://istio-ingress-78545c5bc9-wbr6g.istio-system [2018-01-24T02:53:02Z] “GET /productpage http” 200 5599
|
||||
It will be given the full set of variables for the log to use to construct its result.
|
||||
|
|
|
@ -132,7 +132,7 @@ No
|
|||
the statsd metric name. This allows easier creation of statsd metrics like <code>action_name-response_code</code>.
|
||||
The template strings must conform to go’s text/template syntax. For the example of <code>action_name-response_code</code>,
|
||||
we use the template:
|
||||
<code>{{.apiMethod}}-{{.responseCode}}</code></p>
|
||||
<code>{{.apiMethod}}-{{.responseCode}}</code></p>
|
||||
|
||||
<p>If name_template is the empty string the Istio metric name will be used for statsd metric’s name.</p>
|
||||
|
||||
|
|
|
@ -217,4 +217,19 @@ messages:
|
|||
- name: port
|
||||
type: int
|
||||
- name: targetPort
|
||||
type: string
|
||||
type: string
|
||||
|
||||
- name: "JwtFailureDueToInvalidServicePortPrefix"
|
||||
code: IST0119
|
||||
level: Warning
|
||||
description: "Authentication policy with JWT targets Service with invalid port specification."
|
||||
template: "Authentication policy with JWT targets Service with invalid port specification (port: %d, name: %s, protocol: %s, targetPort: %s)."
|
||||
args:
|
||||
- name: port
|
||||
type: int
|
||||
- name: portName
|
||||
type: string
|
||||
- name: protocol
|
||||
type: string
|
||||
- name: targetPort
|
||||
type: string
|
||||
|
|
Loading…
Reference in New Issue