Improve upgrade notice. (#3732)

This commit is contained in:
Martin Taillefer 2019-03-18 09:40:54 -07:00 committed by GitHub
parent e45157cd3c
commit 9ecb917ff1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 50 additions and 50 deletions

View File

@ -53,7 +53,6 @@ admissionregistration.k8s.io
AES-NI
AKS
Alibaba
ALLOW_ANY
alt
analytics
ANDed
@ -104,7 +103,6 @@ CIOs
Circonus
cli
CloudWatch
ClusterRbacConfig
CNI
cnn.com
colocated
@ -240,12 +238,8 @@ istio.io
istio.io.
Istiofied
IstioMesh
istio-ingressgateway
istio-mixer
istio-policy
istio-remote
istio-system
istio-telemetry
jason
Jog
json
@ -310,7 +304,6 @@ myapp
MySQL
mysql
mysqldb
name.namespace.svc.cluster.local
namespace
namespaces
natively
@ -378,7 +371,6 @@ Rajagopalan
ratelimit-handler
RawVM
rbac
RbacConfig
re-applied
re-patch
RedHat

View File

@ -18,6 +18,11 @@ These release notes describe what's different between Istio 1.0.6 and Istio 1.1.
- We recommend a manual upgrade of the control plane and data plane to 1.1. See
[upgrades](/docs/setup/kubernetes/upgrade/) for more information.
{{< warning >}}
Be sure to check out the [upgrade notice](/docs/setup/upgrade-notice) for a concise list of things you should know before
upgrading your deployment to Istio 1.1.
{{< /warning >}}
## Installation
- **CRD Install Separated from Istio Install**. Istios CRDs have been placed into their own Helm chart `istio-init`.

View File

@ -1,38 +0,0 @@
---
title: Breaking & Surprising Changes in 1.1
description: Breaking & surprising changes in Istio 1.1.
weight: 15
---
## Introduction
This page describes changes you need to be aware of when upgrading from Istio 1.0 to 1.1. Here we detail cases where we intentionally broke backwards compatibility. We also mention cases where backwards compatibility was preserved but new behavior was introduced that would be surprising to anyone familiar with the use and operation of Istio 1.0.
For an overview of new features introduced with Istio 1.1, please refer to the [1.1 release notes](/about/notes/1.1/).
## Installation
- Istios CRDs have been placed into their own Helm chart `istio-init`. This prevents loss of custom resource data, facilitates the upgrade process, and enables the Istio project to evolve beyond a Helm-based installation. The [upgrade documentation](/docs/setup/kubernetes/upgrade/) provides the proper procedure for upgrading from Istio 1.0.6 to Istio 1.1.0. Please follow these instructions **carefully and precisely** when upgrading. If `certmanager` is desired, it is mandatory to use the `--set certmanager=true` flag when installing both `istio-init` and Istio charts with either `template` or `tiller` installation modes.
- The 1.0 `istio-remote` chart used for [multicluster VPN](/docs/setup/kubernetes/install/multicluster/vpn/) and [multicluster split horizon](/docs/examples/multicluster/split-horizon-eds/) remote cluster installation has been consolidated into the Istio chart. To generate an equivalent istio-remote chart, use the flag `--set global.istioRemote=true`.
- Addons are no longer be exposed via separate load balancers. Instead addons are now exposed via the Ingress Gateway. To expose an addon via the Ingress Gateway, please follow the [Remotely Accessing Telemetry Addons](/docs/tasks/telemetry/gateways/) guide.
- The built-in Istio Statsd collector has been removed. Istio retains the capability of integrating with your own Statsd collector.
- Grafana, Prometheus, Kiali, and Jaeger passwords and username are now stored in [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/) instead of command line configuration options, `values.yaml`, or configmaps for improved security and compliance.
- Jaeger has replaced Zipkin as the default tracing system.
- The `ingress` series of options for configuring a Kubernetes Ingress have been removed. Kubernetes Ingress is still functional and can be installed by following the [Securing Kubernetes Ingress with Cert-Manager](/docs/examples/advanced-gateways/ingress-certmgr/) guide.
## Traffic Management
- Outbound traffic policy now defaults to ALLOW_ANY. Traffic to unknown ports will be forwarded as-is. Traffic to known ports (e.g., port 80) will be matched with one of the services in the system and forwarded accordingly
- During sidecar routing to a service, destination rules for the target service in the same namespace as the sidecar will take precedence, followed by destination rules in the services namespace, and finally followed by destination rules in other namespaces if applicable.
- We recommend storing gateway resources in the same namespace as the gateway workload (e.g., istio-system in case of istio-ingressgateway). When referring to gateway resources in virtual services, use the namespace/name format instead of using name.namespace.svc.cluster.local
- The optional egress gateway is now disabled by default. It is enabled in the demo profile for users to explore but disabled in all other profiles by default. If you need to control and secure your outbound traffic through the egress gateway, you will need to enable `gateways.istio-egressgateway.enabled=true` manually in any of the non-demo profiles.
## Policy & Telemetry
- Istio-policy is disabled by default. It is enabled in the demo profile for users to explore but disabled in all other profiles. This change is only for Istio-policy not for istio-telemetry. In order to re-enable policy checking, run helm template with `--set global.disablePolicyChecks=false` and re-apply the configuration.
- The Service Graph component has now been deprecated in favor of the Kiali Monitoring tool. For more information about Kiali and its visualization capabilities please refer to the [Telemetry section](/docs/tasks/telemetry/) of the documentation and the [Kiali website](https://www.kiali.io/). If you would like to see new features as they are being developed please check out the [Kiali service mesh observability project](https://www.youtube.com/channel/UCcm2NzDN_UCZKk2yYmOpc5w) on YouTube where you will find the end of sprint demos.
## Security
- RBAC Configuration has been modified to correctly implement cluster scoping. The RbacConfig resource has been replaced with the ClusterRbacConfig resource. Refer to the [Migrating RbacConfig to ClusterRbacConfig](/docs/setup/kubernetes/upgrade/#migrating-from-rbacconfig-to-clusterrbacconfig) documentation for migration instructions.

View File

@ -17,6 +17,11 @@ highly available with multiple replicas.
This flow assumes that the Istio components are installed and upgraded in the
`istio-system` namespace.
{{< warning >}}
Be sure to check out the [upgrade notice](/docs/setup/upgrade-notice) for a concise list of things you should know before
upgrading your deployment to Istio 1.1.
{{< /warning >}}
## Upgrade steps
[Download the new Istio release](/docs/setup/kubernetes/download/)

View File

@ -0,0 +1,36 @@
---
title: 1.1 Upgrade Notice
description: Important changes operators must understand before upgrading to Istio 1.1.
weight: 5
---
This page describes changes you need to be aware of when upgrading from Istio 1.0 to 1.1. Here we detail cases where we intentionally broke backwards compatibility. We also mention cases where backwards compatibility was preserved but new behavior was introduced that would be surprising to someone familiar with the use and operation of Istio 1.0.
For an overview of new features introduced with Istio 1.1, please refer to the [1.1 release notes](/about/notes/1.1/).
## Installation
- Istios CRDs have been placed into their own Helm chart `istio-init`. This prevents loss of custom resource data, facilitates the upgrade process, and enables Istio to evolve beyond a Helm-based installation. The [upgrade documentation](/docs/setup/kubernetes/upgrade/) provides the proper procedures for upgrading from Istio 1.0.6 to Istio 1.1. Please follow these instructions carefully when upgrading. If `certmanager` is desired, use the `--set certmanager=true` flag when installing both `istio-init` and Istio charts with either `template` or `tiller` installation modes.
- The 1.0 `istio-remote` chart used for [multicluster VPN](/docs/setup/kubernetes/install/multicluster/vpn/) and [multicluster split horizon](/docs/examples/multicluster/split-horizon-eds/) remote cluster installation has been consolidated into the Istio chart. To generate an equivalent `istio-remote` chart, use the `--set global.istioRemote=true` flag.
- Addons are no longer exposed via separate load balancers. Instead addons are now exposed via the Ingress Gateway. To expose an addon via the Ingress Gateway, please follow the [Remotely Accessing Telemetry Addons](/docs/tasks/telemetry/gateways/) guide.
- The built-in Istio Statsd collector has been removed. Istio retains the capability of integrating with your own Statsd collector.
- Grafana, Prometheus, Kiali, and Jaeger passwords and usernames are now stored in [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/) instead of command line configuration options, `values.yaml`, or configmaps for improved security and compliance.
- Jaeger has replaced Zipkin as the default tracing system.
- The `ingress` series of options for configuring a Kubernetes Ingress have been removed. Kubernetes Ingress is still functional and can be installed by following the [Securing Kubernetes Ingress with Cert-Manager](/docs/examples/advanced-gateways/ingress-certmgr/) guide.
## Traffic Management
- Outbound traffic policy now defaults to `ALLOW_ANY`. Traffic to unknown ports will be forwarded as-is. Traffic to known ports (e.g., port 80) will be matched with one of the services in the system and forwarded accordingly.
- During sidecar routing to a service, destination rules for the target service in the same namespace as the sidecar will take precedence, followed by destination rules in the services namespace, and finally followed by destination rules in other namespaces if applicable.
- We recommend storing gateway resources in the same namespace as the gateway workload (e.g., `istio-system` in case of `istio-ingressgateway`). When referring to gateway resources in virtual services, use the namespace/name format instead of using `name.namespace.svc.cluster.local`.
- The optional egress gateway is now disabled by default. It is enabled in the demo profile for users to explore but disabled in all other profiles by default. If you need to control and secure your outbound traffic through the egress gateway, you will need to enable `gateways.istio-egressgateway.enabled=true` manually in any of the non-demo profiles.
## Policy & Telemetry
- `istio-policy` is now disabled by default. It is enabled in the demo profile for users to explore but disabled in all other profiles. This change is only for `istio-policy` and not for `istio-telemetry`. In order to re-enable policy checking, run `helm template` with `--set global.disablePolicyChecks=false` and re-apply the configuration.
- The Service Graph component has now been deprecated in favor of [Kiali](https://www.kiali.io/).
## Security
- RBAC configuration has been modified to implement cluster scoping. The `RbacConfig` resource has been replaced with the `ClusterRbacConfig` resource. Refer to [Migrating `RbacConfig` to `ClusterRbacConfig`](/docs/setup/kubernetes/upgrade/#migrating-from-rbacconfig-to-clusterrbacconfig) for migration instructions.

View File

@ -1,10 +1,10 @@
---
title: Why do I see 'istio-mixer' spans in some of my distributed traces?
title: Why do I see `istio-mixer` spans in some of my distributed traces?
weight: 100
---
Mixer generates application-level traces for requests that reach Mixer with tracing headers. Mixer generates spans, labeled 'istio-mixer' for any critical work that it does, including dispatch to individual adapters.
Mixer generates application-level traces for requests that reach Mixer with tracing headers. Mixer generates spans, labeled `istio-mixer` for any critical work that it does, including dispatch to individual adapters.
Envoy caches calls to Mixer on the data path. As a result, calls out to Mixer made via the istio-policy service only happen for certain requests, for example: cache-expiry or different request characteristics. For this reason, you only see Mixer participate in *some* of your traces.
Envoy caches calls to Mixer on the data path. As a result, calls out to Mixer made via the `istio-policy` service only happen for certain requests, for example: cache-expiry or different request characteristics. For this reason, you only see Mixer participate in *some* of your traces.
To turn off the application-level trace spans for Mixer itself, you must edit the deployment configuration for `istio-policy` and remove the `--trace_zipkin_url` command-line parameter.

View File

@ -7,7 +7,7 @@ Mixer 为携带追踪 header 并到达 Mixer 的请求生成应用程序级追
Mixer 会生成 span并将其标记为 `istio-mixer` 以便用于它所做的任何关键工作,包括分发到各个适配器。
Envoy 缓存在数据路径上对 Mixer 的调用。
因此,通过 istio-policy 服务对 Mixer 发出的调用只会在特定的请求中发生,例如:缓存过期或者请求具有不同特征。
因此,通过 `istio-policy` 服务对 Mixer 发出的调用只会在特定的请求中发生,例如:缓存过期或者请求具有不同特征。
正是由于这个原因,您只看到了 Mixer 参与了您的 *一些* 追踪(而非全部)。
要关闭 Mixer 的应用程序级追踪,您必须编辑 `istio-policy` 的部署配置,删除命令行参数 `--trace_zipkin_url`