mirror of https://github.com/istio/istio.io.git
Content changes to prepare to switch to the new Hugo. (#5993)
These fix problems encountered when switching to the new Hugo which has a completely different markdown engine. I went through diffs of the generated HTML and made required adjustments.
This commit is contained in:
Martin Taillefer
GitHub
parent
a6e1ce49e3
commit
c863bea599
|
|
@ -33,7 +33,7 @@ description: Connect, secure, control, and observe services.
|
|||
{{< inline_image "landing/istio-logo.svg" >}}
|
||||
<div id="hero-text">
|
||||
<h1 id="hero-label">Istio</h1>
|
||||
<h1 id="hero-lead">Connect, secure, control, and observe services.
|
||||
<h1 id="hero-lead">Connect, secure, control, and observe services.</h1>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
|
@ -155,13 +155,13 @@ A few front-matter fields are specific to section pages (i.e. for files names `_
|
|||
|
||||
There are a few more front matter fields available specifically for blog posts:
|
||||
|
||||
|Field | Description
|
||||
|----------------|------------
|
||||
|`publishdate` | Date of the post's original publication
|
||||
|`last_update` | Date when the post last received a major revision
|
||||
|`attribution` | Optional name of the post's author
|
||||
|`twitter` | Optional Twitter handle of the post's author
|
||||
|`target_release`| Release this blog is written with in mind (this is normally the current major Istio release at the time the blog is authored or updated)
|
||||
|Field | Description
|
||||
|-----------------|------------
|
||||
|`publishdate` | Date of the post's original publication
|
||||
|`last_update` | Date when the post last received a major revision
|
||||
|`attribution` | Optional name of the post's author
|
||||
|`twitter` | Optional Twitter handle of the post's author
|
||||
|`target_release` | Release this blog is written with in mind (this is normally the current major Istio release at the time the blog is authored or updated)
|
||||
|
||||
## Adding images
|
||||
|
||||
|
|
|
|||
|
|
@ -42,17 +42,17 @@ represents. For example:
|
|||
|
||||
### Use **bold** for user interface elements
|
||||
|
||||
|Do |Don't
|
||||
|-----------------|------
|
||||
|Click **Fork**. |Click "Fork".
|
||||
|Select **Other**.|Select 'Other'.
|
||||
|Do | Don't
|
||||
|------------------|------
|
||||
|Click **Fork**. | Click "Fork".
|
||||
|Select **Other**. | Select 'Other'.
|
||||
|
||||
### Use _italics_ to define or introduce new terms
|
||||
|
||||
|Do |Don't
|
||||
|Do | Don't
|
||||
|-------------------------------------------|---
|
||||
|A _cluster_ is a set of nodes ... |A "cluster" is a set of nodes ...
|
||||
|These components form the _control plane_. |These components form the **control plane**.
|
||||
|A _cluster_ is a set of nodes ... | A "cluster" is a set of nodes ...
|
||||
|These components form the _control plane_. | These components form the **control plane**.
|
||||
|
||||
### Use `code` style for filenames, directories, and paths
|
||||
|
||||
|
|
@ -66,8 +66,8 @@ represents. For example:
|
|||
|
||||
|Do | Don't
|
||||
|----------------------------|------
|
||||
|The `foo run` command creates a `Deployment`.|The "foo run" command creates a `Deployment`.
|
||||
|For declarative management, use `foo apply`.|For declarative management, use "foo apply".
|
||||
|The `foo run` command creates a `Deployment`. | The "foo run" command creates a `Deployment`.
|
||||
|For declarative management, use `foo apply`. | For declarative management, use "foo apply".
|
||||
|
||||
### Use `code` style for object field names
|
||||
|
||||
|
|
|
|||
|
|
@ -13,11 +13,11 @@ The different types represent different product quality levels and different lev
|
|||
from the Istio team. In this context, *support* means that we will produce patch releases for critical issues and
|
||||
offer technical assistance. Separately, 3rd parties and partners may offer longer-term support solutions.
|
||||
|
||||
|Type | Support Level | Quality and Recommended Use
|
||||
|-----------------|----------------------------------------------------------|----------------------------
|
||||
|Development Build| No support | Dangerous, may not be fully reliable. Useful to experiment with.
|
||||
|LTS Release | Support is provided until 3 months after the next LTS | Safe to deploy in production. Users are encouraged to upgrade to these releases as soon as possible.
|
||||
|Patches | Same as the corresponding Snapshot/LTS release | Users are encouraged to adopt patch releases as soon as they are available for a given release.
|
||||
|Type | Support Level | Quality and Recommended Use
|
||||
|------------------|----------------------------------------------------------|----------------------------
|
||||
|Development Build | No support | Dangerous, may not be fully reliable. Useful to experiment with.
|
||||
|LTS Release | Support is provided until 3 months after the next LTS | Safe to deploy in production. Users are encouraged to upgrade to these releases as soon as possible.
|
||||
|Patches | Same as the corresponding Snapshot/LTS release | Users are encouraged to adopt patch releases as soon as they are available for a given release.
|
||||
|
||||
You can find available releases on the [releases page](https://github.com/istio/istio/releases),
|
||||
and if you're the adventurous type, you can learn about our development builds on the [development builds wiki](https://github.com/istio/istio/wiki/Dev%20Builds).
|
||||
|
|
|
|||
|
|
@ -1129,7 +1129,7 @@ section.
|
|||
$ kubectl delete envoyfilter forward-downstream-sni egress-gateway-sni-verifier
|
||||
{{< /text >}}
|
||||
|
||||
1. Delete the configuration items for the `egressgateway-with-sni-proxy` `Deployment`:
|
||||
1. Delete the configuration items for the `egressgateway-with-sni-proxy` deployment:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete serviceentry sni-proxy
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ The `ServiceRole` and `ServiceRoleBinding` above expressed "*who* is allowed to
|
|||
### Service/method level isolation with/without primary identities
|
||||
|
||||
Here is another example that demonstrates finer grained access control at service/method level. The first step
|
||||
is to define a `book-reader` `ServiceRole` that allows READ access to `/books/*` resource in `bookstore` service.
|
||||
is to define a `book-reader` service role that allows READ access to `/books/*` resource in `bookstore` service.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
---
|
||||
This is some boilerplate *markdown* _text_.
|
||||
This is some boilerplate **markdown** _text_.
|
||||
|
||||
{{< text plain >}}
|
||||
A sample nested text block.
|
||||
{{< /text >}}
|
||||
A sample nested text block in a boilerplate.
|
||||
{{< /text >}}
|
||||
|
|
@ -177,17 +177,17 @@ cluster.
|
|||
|
||||
| Resource Kind| Resource Name | Function |
|
||||
| ---------------------------- |--------------------------- | ----------------- |
|
||||
| `configmap` | `coredns` | Send *.global request to `istiocordns` service |
|
||||
| `service` | `istiocoredns` | Resolve *.global to Istio Ingress gateway |
|
||||
| `gateway.networking.istio.io` | `meshexpansion-gateway` | Open port for Pilot, Citadel and Mixer |
|
||||
| `gateway.networking.istio.io` | `istio-multicluster-ingressgateway`| Open port 15443 for inbound *.global traffic |
|
||||
| `envoyfilter.networking.istio.io` | `istio-multicluster-ingressgateway`| Transform `*.global` to `*. svc.cluster.local` |
|
||||
| `destinationrule.networking.istio.io`| `istio-multicluster-destinationrule`| Set traffic policy for 15443 traffic |
|
||||
| `destinationrule.networking.istio.io`| `meshexpansion-dr-pilot` | Set traffic policy for `istio-pilot` |
|
||||
| `destinationrule.networking.istio.io`| `istio-policy` | Set traffic policy for `istio-policy` |
|
||||
| `destinationrule.networking.istio.io`| `istio-telemetry` | Set traffic policy for `istio-telemetry` |
|
||||
| `virtualservice.networking.istio.io` | `meshexpansion-vs-pilot` | Set route info for `istio-pilot` |
|
||||
| `virtualservice.networking.istio.io` | `meshexpansion-vs-citadel` | Set route info for `istio-citadel` |
|
||||
| `configmap` | `coredns` | Send *.global request to `istiocordns` service |
|
||||
| `service` | `istiocoredns` | Resolve *.global to Istio Ingress gateway |
|
||||
| `gateway.networking.istio.io` | `meshexpansion-gateway` | Open port for Pilot, Citadel and Mixer |
|
||||
| `gateway.networking.istio.io` | `istio-multicluster-ingressgateway` | Open port 15443 for inbound *.global traffic |
|
||||
| `envoyfilter.networking.istio.io` | `istio-multicluster-ingressgateway` | Transform `*.global` to `*. svc.cluster.local` |
|
||||
| `destinationrule.networking.istio.io` | `istio-multicluster-destinationrule` | Set traffic policy for 15443 traffic |
|
||||
| `destinationrule.networking.istio.io` | `meshexpansion-dr-pilot` | Set traffic policy for `istio-pilot` |
|
||||
| `destinationrule.networking.istio.io` | `istio-policy` | Set traffic policy for `istio-policy` |
|
||||
| `destinationrule.networking.istio.io` | `istio-telemetry` | Set traffic policy for `istio-telemetry` |
|
||||
| `virtualservice.networking.istio.io` | `meshexpansion-vs-pilot` | Set route info for `istio-pilot` |
|
||||
| `virtualservice.networking.istio.io` | `meshexpansion-vs-citadel` | Set route info for `istio-citadel` |
|
||||
|
||||
## Expose service running on cluster to VMs
|
||||
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ of injected sidecar when it was.
|
|||
|
||||
1. Check default policy
|
||||
|
||||
Check the default injection policy in the `istio-sidecar-injector` `configmap`.
|
||||
Check the default injection policy in the `istio-sidecar-injector configmap`.
|
||||
|
||||
{{< text bash yaml >}}
|
||||
$ kubectl -n istio-system get configmap istio-sidecar-injector -o jsonpath='{.data.config}' | grep policy:
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ necessary.
|
|||
|
||||
## Invalid configuration is accepted
|
||||
|
||||
Verify the `istio-galley` `validationwebhookconfiguration` exists and
|
||||
Verify the `istio-galley validationwebhookconfiguration` exists and
|
||||
is correct. The `apiVersion`, `apiGroup`, and `resource` of the
|
||||
invalid configuration should be listed in one of the two `webhooks`
|
||||
entries.
|
||||
|
|
@ -148,7 +148,7 @@ webhooks:
|
|||
{{< /text >}}
|
||||
|
||||
If the `validatingwebhookconfiguration` doesn’t exist, verify the
|
||||
`istio-galley-configuration` `configmap` exists. `istio-galley` uses
|
||||
`istio-galley-configuration configmap` exists. `istio-galley` uses
|
||||
the data from this configmap to create and update the
|
||||
`validatingwebhookconfiguration`.
|
||||
|
||||
|
|
@ -196,7 +196,7 @@ typically caused by an empty `caBundle` in the webhook
|
|||
configuration. Verify that it is not empty (see [verify webhook
|
||||
configuration](#invalid-configuration-is-accepted)). The
|
||||
`istio-galley` deployment consciously reconciles webhook configuration
|
||||
used the `istio-galley-configuration` `configmap` and root certificate
|
||||
used the `istio-galley-configuration configmap` and root certificate
|
||||
mounted from `istio.istio-galley-service-account` secret in the
|
||||
`istio-system` namespace.
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ mounted from `istio.istio-galley-service-account` secret in the
|
|||
{{< /text >}}
|
||||
|
||||
`istio-galley` needs `validatingwebhookconfigurations` write access to
|
||||
create and update the `istio-galley` `validatingwebhookconfiguration`.
|
||||
create and update the `istio-galley validatingwebhookconfiguration`.
|
||||
|
||||
## Creating configuration fails with `no such hosts` or `no endpoints available` errors
|
||||
|
||||
|
|
|
|||
|
|
@ -31,24 +31,24 @@ This logic is captured in the truth table below:
|
|||
|
||||
| `ca.istio.io/override` value | `ca.istio.io/env` match | `enableNamespacesByDefault` configuration | Workload secret created |
|
||||
|------------------------------|-------------------------|-------------------------------------------|-------------------------|
|
||||
|`true`|yes|`true`|yes|
|
||||
|`true`|yes|`false`|yes|
|
||||
|`true`|no|`true`|yes|
|
||||
|`true`|no|`false`|yes|
|
||||
|`true`|unset|`true`|yes|
|
||||
|`true`|unset|`false`|yes|
|
||||
|`false`|yes|`true`|no|
|
||||
|`false`|yes|`false`|no|
|
||||
|`false`|no|`true`|no|
|
||||
|`false`|no|`false`|no|
|
||||
|`false`|unset|`true`|no|
|
||||
|`false`|unset|`false`|no|
|
||||
|unset|yes|`true`|yes|
|
||||
|unset|yes|`false`|yes|
|
||||
|unset|no|`true`|no|
|
||||
|unset|no|`false`|no|
|
||||
|unset|unset|`true`|yes|
|
||||
|unset|unset|`false`|no|
|
||||
|`true` | yes | `true` | yes |
|
||||
|`true` | yes | `false` | yes |
|
||||
|`true` | no | `true` | yes |
|
||||
|`true` | no | `false` | yes |
|
||||
|`true` | unset | `true` | yes |
|
||||
|`true` | unset | `false` | yes |
|
||||
|`false` | yes | `true` | no |
|
||||
|`false` | yes | `false` | no |
|
||||
|`false` | no | `true` | no |
|
||||
|`false` | no | `false` | no |
|
||||
|`false` | unset | `true` | no |
|
||||
|`false` | unset | `false` | no |
|
||||
|unset| yes | `true` | yes |
|
||||
|unset| yes | `false` | yes |
|
||||
|unset| no | `true` | no |
|
||||
|unset| no | `false` | no |
|
||||
|unset| unset | `true` | yes |
|
||||
|unset| unset | `false` | no |
|
||||
|
||||
{{< idea >}}
|
||||
When a namespace transitions from _disabled_ to _enabled_, Citadel will retroactively generate secrets for all `ServiceAccounts` in that namespace. When transitioning from _enabled_ to _disabled_, however, Citadel will not delete the namespace's generated secrets until the root certificate is renewed.
|
||||
|
|
|
|||
|
|
@ -194,7 +194,7 @@ and 10% to the `v2` subset of the the `reviews` service:
|
|||
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-90-10.yaml@
|
||||
{{< /text >}}
|
||||
|
||||
Now describe the `reviews` `v1` pod:
|
||||
Now describe the `reviews v1` pod:
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl x describe pod $REVIEWS_V1_POD
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ deployments will have agents (Envoy or Mixer adapters) that produce these attrib
|
|||
| `destination.owner` | string | Reference to the workload controlling the destination workload instance.| `kubernetes://apis/extensions/v1beta1/namespaces/istio-system/deployments/istio-telemetry` |
|
||||
| `destination.workload.uid` | string | Unique identifier of the destination workload. | `istio://istio-system/workloads/istio-telemetry` |
|
||||
| `destination.workload.name` | string | Destination workload name. | `istio-telemetry` |
|
||||
| `destination.workload.namespace`| string | Destination workload namespace. | `istio-system` |
|
||||
| `destination.workload.namespace` | string | Destination workload namespace. | `istio-system` |
|
||||
| `destination.container.name` | string | Name of the destination workload instance's container. | `mixer` |
|
||||
| `destination.container.image` | string | Image of the destination workload instance's container. | `gcr.io/istio-testing/mixer:0.8.0` |
|
||||
| `destination.service.host` | string | Destination host address. | `istio-telemetry.istio-system.svc.cluster.local` |
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ CEXL supports the following functions.
|
|||
|`.matches` | Regular expression match | `"svc.*".matches(destination.service)` | Matches `destination.service` against regular expression pattern `"svc.*"`.
|
||||
|`.startsWith` | string prefix match | `destination.service.startsWith("acme")` | Checks whether `destination.service` starts with `"acme"`.
|
||||
|`.endsWith` | string postfix match | `destination.service.endsWith("acme")` | Checks whether `destination.service` ends with `"acme"`.
|
||||
|`emptyStringMap` | Create an empty string map | `request.headers` <code>|</code> `emptyStringMap()`| Use `emptyStringMap` to create an empty string map for default value of `request.headers`.
|
||||
|`emptyStringMap` | Create an empty string map | `request.headers` <code>|</code> `emptyStringMap()` | Use `emptyStringMap` to create an empty string map for default value of `request.headers`.
|
||||
|`conditional` | Simulate ternary operator | `conditional((context.reporter.kind` <code>|</code> `"inbound") == "outbound", "client", "server")` | Returns `"client"` if report kind is `outbound` otherwise returns `"server"`.
|
||||
|`toLower` | Convert a string to lowercase letters | `toLower("User-Agent")` | Returns `"user-agent"`.
|
||||
|`size` | Length of a string | `size("admin")` | Returns 5
|
||||
|
|
@ -68,7 +68,7 @@ For example, the expression `request.auth.principal == "user1"` fails evaluation
|
|||
|Expression |Return Type |Description|
|
||||
|-----------|------------|-----------|
|
||||
|`request.size` <code>| 200</code> | **int** | `request.size` if available, otherwise 200.
|
||||
|`request.headers["x-forwarded-host"] == "myhost"`| **boolean**
|
||||
|`(request.headers["x-user-group"] == "admin")` <code>||</code> `(request.auth.principal == "admin")`| **boolean**| True if the user is admin or in the admin group.
|
||||
|`request.headers["x-forwarded-host"] == "myhost"` | **boolean**
|
||||
|`(request.headers["x-user-group"] == "admin")` <code>||</code> `(request.auth.principal == "admin")` | **boolean** | True if the user is admin or in the admin group.
|
||||
|`(request.auth.principal` <code>|</code> `"nobody" ) == "user1"` | **boolean** | True if `request.auth.principal` is "user1", The expression will not error out if `request.auth.principal` is missing.
|
||||
|`source.labels["app"]=="reviews" && source.labels["version"]=="v3"`| **boolean** | True if app label is reviews and version label is v3, false otherwise.
|
||||
|`source.labels["app"]=="reviews" && source.labels["version"]=="v3"` | **boolean** | True if app label is reviews and version label is v3, false otherwise.
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ application pod annotation key.
|
|||
|----------------|--------|---------|-------------|
|
||||
| `sidecar.istio.io/inject` | `true`, `false` | `true` | Indicates whether the Istio proxy sidecar should be injected. If present and `false`, the Istio CNI plugin doesn't configure the namespace's iptables for the pod. |
|
||||
| `sidecar.istio.io/status` | | | Annotation created by Istio's sidecar injection. If missing, the Istio CNI plugin doesn't configure the pod namespace's iptables. |
|
||||
| `sidecar.istio.io/interceptionMode`| `REDIRECT`, `TPROXY` | `REDIRECT` | The iptables redirect mode to use. |
|
||||
| `sidecar.istio.io/interceptionMode` | `REDIRECT`, `TPROXY` | `REDIRECT` | The iptables redirect mode to use. |
|
||||
| `traffic.sidecar.istio.io/includeOutboundIPRanges` | `<IPCidr1>,<IPCidr2>,...` | `"*"` | Comma separated list of IP ranges in CIDR form to redirect to the sidecar proxy. The default value of `"*"` redirects all traffic. |
|
||||
| `traffic.sidecar.istio.io/excludeOutboundIPRanges` | `<IPCidr1>,<IPCidr2>,...` | | Comma separated list of IP ranges in CIDR form to be excluded from redirection. Only applies when `includeOutboundIPRanges` is `"*"`. |
|
||||
| `traffic.sidecar.istio.io/includeInboundPorts` | `<port1>,<port2>,...` | Pod's list of `containerPorts` | Comma separated list of inbound ports for which traffic is to be redirected to the Istio proxy sidecar. The value of `"*"` redirects all ports. |
|
||||
|
|
|
|||
|
|
@ -146,7 +146,7 @@ This will be used to access pilot on `cluster1` securely using the ingress gatew
|
|||
$ echo The ingress gateway of cluster1: address=$INGRESS_HOST, port=$SECURE_INGRESS_PORT
|
||||
{{< /text >}}
|
||||
|
||||
1. Update the gateway address in the mesh network configuration. Edit the `istio` `ConfigMap`:
|
||||
1. Update the gateway address in the mesh network configuration. Edit the `istio ConfigMap`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl edit cm -n istio-system --context=$CTX_CLUSTER1 istio
|
||||
|
|
@ -233,7 +233,7 @@ This will be used to access pilot on `cluster1` securely using the ingress gatew
|
|||
$ echo The ingress gateway of cluster2: address=$INGRESS_HOST, port=$SECURE_INGRESS_PORT
|
||||
{{< /text >}}
|
||||
|
||||
1. Update the gateway address in the mesh network configuration. Edit the `istio` `ConfigMap`:
|
||||
1. Update the gateway address in the mesh network configuration. Edit the `istio ConfigMap`:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl edit cm -n istio-system --context=$CTX_CLUSTER1 istio
|
||||
|
|
|
|||
|
|
@ -671,7 +671,7 @@ The SNI proxy will forward the traffic to port `443`.
|
|||
$ kubectl delete --ignore-not-found=true envoyfilter forward-downstream-sni egress-gateway-sni-verifier
|
||||
{{< /text >}}
|
||||
|
||||
1. Delete the configuration items for the `egressgateway-with-sni-proxy` `Deployment`:
|
||||
1. Delete the configuration items for the `egressgateway-with-sni-proxy` deployment:
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete serviceentry sni-proxy
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ to hold the configuration of the NGINX server:
|
|||
|
||||
## Configure an ingress gateway
|
||||
|
||||
1. Define a `Gateway` with a `server` section for port 443. Note the `PASSTHROUGH` `tls` `mode` which instructs
|
||||
1. Define a `Gateway` with a `server` section for port 443. Note the `PASSTHROUGH` TLS mode which instructs
|
||||
the gateway to pass the ingress traffic AS IS, without terminating TLS.
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
|
|||
|
|
@ -208,7 +208,7 @@ the server will use to verify its clients. Create the secret `istio-ingressgatew
|
|||
secret "istio-ingressgateway-ca-certs" created
|
||||
{{< /text >}}
|
||||
|
||||
1. Redefine your previous `Gateway` to change the `tls` `mode` to `MUTUAL` and to specify `caCertificates`:
|
||||
1. Redefine your previous `Gateway` to change the TLS mode to `MUTUAL` and to specify `caCertificates`:
|
||||
|
||||
{{< warning >}}
|
||||
The location of the certificate **must** be `/etc/istio/ingressgateway-ca-certs`, or the gateway
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Envoy update which contains the final version of the patches.
|
|||
|
||||
- Prevent services with same target port resulting in duplicate inbound listeners ([Issue 9504](https://github.com/istio/istio/issues/9504)).
|
||||
|
||||
- Fix issue with configuring `Sidecar` `egress` ports for namespaces other than `istio-system` resulting in a `envoy.tcp_proxy` filter of `BlackHoleCluster` by auto binding
|
||||
- Fix issue with configuring `Sidecar egress` ports for namespaces other than `istio-system` resulting in a `envoy.tcp_proxy` filter of `BlackHoleCluster` by auto binding
|
||||
to services for `Sidecar` listeners ([Issue 12536](https://github.com/istio/istio/issues/12536)).
|
||||
|
||||
- Fix gateway `vhost` configuration generation issue by favoring more specific host matches ([Issue 12655](https://github.com/istio/istio/issues/12655)).
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ We're pleased to announce the availability of Istio 1.1.8. Please see below for
|
|||
|
||||
## Bug fixes
|
||||
|
||||
- Fix `PASSTHROUGH` `DestinationRules` for CDS clusters ([Issue 13744](https://github.com/istio/istio/issues/13744)).
|
||||
- Fix `PASSTHROUGH DestinationRules` for CDS clusters ([Issue 13744](https://github.com/istio/istio/issues/13744)).
|
||||
- Make the `appVersion` and `version` fields in the Helm charts display the correct Istio version ([Issue 14290](https://github.com/istio/istio/issues/14290)).
|
||||
- Fix Mixer crash affecting both policy and telemetry servers ([Issue 14235](https://github.com/istio/istio/issues/14235)).
|
||||
- Fix multicluster issue where two pods in different clusters could not share the same IP address ([Issue 14066](https://github.com/istio/istio/issues/14066)).
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ The following CRDs remain:
|
|||
|
||||
| Custom Resource Definition name | Purpose |
|
||||
| --- | --- |
|
||||
| `adapter`| Specification of Istio extension declarations |
|
||||
| `adapter` | Specification of Istio extension declarations |
|
||||
| `attributemanifest` | Specification of Istio extension declarations |
|
||||
| `template` | Specification of Istio extension declarations |
|
||||
| `handler` | Specification of extension invocations |
|
||||
|
|
|
|||
|
|
@ -2,38 +2,12 @@
|
|||
title: Istio
|
||||
description: 用于连接、保护、控制和观测服务。
|
||||
---
|
||||
<!-- these script blocks are only for the primary English home page -->
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "http://schema.org",
|
||||
"@type": "Organization",
|
||||
"url": "https://istio.io",
|
||||
"logo": "https://istio.io/img/logo.png",
|
||||
"sameAs": [
|
||||
"https://twitter.com/IstioMesh",
|
||||
"https://discuss.istio.io/"
|
||||
]
|
||||
}
|
||||
</script>
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "http://schema.org",
|
||||
"@type": "WebSite",
|
||||
"url": "https://istio.io/",
|
||||
"potentialAction": {
|
||||
"@type": "SearchAction",
|
||||
"target": "https://istio.io/search?q={search_term_string}",
|
||||
"query-input": "required name=search_term_string"
|
||||
}
|
||||
}
|
||||
</script>
|
||||
|
||||
<main class="landing">
|
||||
<div id="banner">
|
||||
{{< inline_image "landing/istio-logo.svg" >}}
|
||||
<div id="hero-text">
|
||||
<h1 id="hero-label">Istio</h1>
|
||||
<h1 id="hero-lead">连接、保护、控制和观测服务。
|
||||
<h1 id="hero-lead">连接、保护、控制和观测服务。</h1>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
|
@ -19,4 +19,3 @@
|
|||
{{- else -}}
|
||||
{{- errorf "Missing name in boilerplate (%s)" $position -}}
|
||||
{{- end -}}
|
||||
œ
|
||||
Loading…
Reference in New Issue