update upgrade notes with CRD schema instructions (#5174)

* update upgrade notes with CRD schema instructions

* fix lint

* fixes to comments

* add istioctl analyze to suggested steps

* fix linter

* changed heading
This commit is contained in:
Jason Wang 2019-10-18 13:18:57 -07:00 committed by Istio Automation
parent 7b3a0a8591
commit 55d2ef9683
2 changed files with 18 additions and 1 deletions

View File

@ -385,6 +385,7 @@ onboarding
Onboarding
onwards
OP_QUERY
OpenAPI
OpenCensus
OpenID
OpenID_Connect

View File

@ -10,7 +10,7 @@ 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.3.
## Traffic Management
## Traffic management
Services of type `http` are no longer allowed on port 443. This change was made to prevent protocol conflicts with external HTTPS services.
@ -21,3 +21,19 @@ If you depend on this behavior, there are a few options:
* Specify the environment variable `PILOT_BLOCK_HTTP_ON_443=false` to the Pilot deployment. Note: this may be removed in future releases.
See [Protocol Selection](/docs/ops/traffic-management/protocol-selection/) for more information about specifying the protocol of a port
## Configuration management
We introduced OpenAPI v3 schemas in the Kubernetes [Custom Resource Definitions (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) of Istio resources. The schemas describe the Istio resources and help ensure the Istio resources you create and modify are structurally correct.
If one or more fields in your configurations are unknown or have wrong types, they will be rejected by the Kubernetes API server when you create or modify Istio resources. This feature, `CustomResourceValidation`, is on by default for Kubernetes 1.9+ clusters. Please note that existing configurations already in Kubernetes are __NOT__ affected if they stay unchanged.
To help with your upgrade, here are some steps you could take:
* After upgrading Istio, run your Istio configurations with `kubectl apply --dry-run` so that you are able to know if the configurations can be accepted by the API server as well as any possible unknown and/or invalid fields to the API server. (`DryRun` feature is on by default for Kubernetes 1.13+ clusters.)
* Use the [reference documentation](/docs/reference/config/) and/or `kubectl explain` (more details below) to confirm and correct the field names and data types.
* In addition to structural validation, you can also use `istioctl x analyze` to help you detect other potential issues with your Istio configurations. Refer to [here](/docs/ops/diagnostic-tools/istioctl-analyze/) for more details.
If you choose to ignore the validation errors, add `--validate=false` to your `kubectl` command when you create or modify Istio resources. We strongly discourage doing so however, since it is willingly introducing incorrect configuration.
`kubectl explain` shows the structure of a resource in Kubernetes. For example, you can use `kubectl explain virtualservices.networking.istio.io` to see the top-level fields in `VirtualService`. To get all the fields, you can add a `--recursive` flag. In Kubernetes 1.15+, `kubectl explain` is able to work with CRDs by default.