docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

update

This commit is contained in:
ddeyo 2018-09-28 10:52:32 -07:00
parent 12c2d1872f
commit 79ab9f804a
1 changed files with 1 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
ee/ucp/release-notes.md
View File

@ -30,7 +30,7 @@ upgrade your installation to the latest release.
* UCP now provides service metrics for all API calls, using Prometheus deployed as Kubernetes Daemon Set
* UCP now supports use of an external Prometheus instance to scrape metrics from UPC endpoints
* UCP supports SAML authentication
* DTR vulnerability scan data is now available through the UCP UI
* DTR vulnerability scan data is now available through the UCP web interface
**API updates**
* There are several backwards-incompatible changes in the Kube API that may affect user workloads. They are:
@ -39,7 +39,6 @@ upgrade your installation to the latest release.
* Change `node.alpha.kubernetes.io/notReady` to `node.kubernetes.io/not-ready`
* Change `node.alpha.kubernetes.io/unreachable` to `node.kubernetes.io/unreachable`
For more information about taints and tolerations, see [Taints and Tolerations](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/).
< br />
* JSON configuration used with `kubectl create -f pod.json` containing fields with incorrect casing are no longer valid. You must correct these files before upgrading. When specifying keys in JSON resource definitions during direct API server communication, the keys are case-sensitive. A bug introduced in Kubernetes 1.8 caused the API server to accept a request with incorrect case and coerce it to correct case, but this behaviour has been fixed in 1.11 so the API server will again enforce correct casing. During this time, the `kubectl` tool continued to enforce case-sensitive keys, so users that strictly manage resources with kubectl will be unaffected by this change.
* If you have a pod with a subpath volume PVC, there’s a chance that after the upgrade, it will conflict with some other pod; see [this pull request](https://github.com/kubernetes/kubernetes/pull/61373). It’s not clear if this issue will just prevent those pods from starting or if the whole cluster will fail.