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

API issues moved

This commit is contained in:
ddeyo 2018-09-26 09:15:06 -07:00
parent 6953670d20
commit 4af13dfb6b
1 changed files with 9 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -32,6 +32,15 @@ upgrade your installation to the latest release.
* UCP suppoprts SAML authentication
* DTR vulnerability scan data is now available through the UCP UI
**API updates**
* There are several backwards-incompatible changes in the Kube API that may affect user workloads. They are:
* **PodSecurityPolicy**: A compatibility issue with the allowPrivilegeEscalation field that caused policies to start denying pods they previously allowed was fixed. If you defined PodSecurityPolicy objects using a 1.8.0 client or server and set allowPrivilegeEscalation to false, these objects must be reapplied after you upgrade.
* These changes are automatically updated for taints. Tolerations for these taints must be updated manually. Specifically, you must:
* Change node.alpha.kubernetes.io/notReady to node.kubernetes.io/not-ready
* Change node.alpha.kubernetes.io/unreachable to node.kubernetes.io/unreachable
* JSON configuration files (i.e. JSON files that you use with `kubectl create -f pod.json`) that contain fields with incorrect casing will no longer be 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 and the API server will once again be enforcing the correct case. 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 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.
# Version 3.0
## 3.0.4 (2018-08-09)
@ -78,17 +87,6 @@ upgrade your installation to the latest release.
* Added support for dynamic volume provisioning in Kubernetes for AWS EBS and
Azure Disk when installing UCP with the `--cloud-provider` option.
**API updates**
* There are several backwards-incompatible changes in the Kube API that may affect user workloads. They are:
* **PodSecurityPolicy**: A compatibility issue with the allowPrivilegeEscalation field that caused policies to start denying pods they previously allowed was fixed. If you defined PodSecurityPolicy objects using a 1.8.0 client or server and set allowPrivilegeEscalation to false, these objects must be reapplied after you upgrade.
* These changes are automatically updated for taints. Tolerations for these taints must be updated manually. Specifically, you must:
* Change node.alpha.kubernetes.io/notReady to node.kubernetes.io/not-ready
* Change node.alpha.kubernetes.io/unreachable to node.kubernetes.io/unreachable
* JSON configuration files (i.e. JSON files that you use with `kubectl create -f pod.json`) that contain fields with incorrect casing will no longer be 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 and the API server will once again be enforcing the correct case. 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 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.
**Bug Fixes**
* Core
* Fixed an issue for anonymous volumes in Compose for Kubernetes.