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

Merge pull request #841 from docker/ucp-relnotes-693 

changelog for 3.1 incorporated
This commit is contained in:
Justin I. Nevill 2018-11-04 13:18:52 -05:00 committed by GitHub
parent 12979d0f37 985f2b2841
commit d498f264b9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 55 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -21,20 +21,50 @@ upgrade your installation to the latest release.
# Version 3.1 # Version 3.1
## 3.1.0 (2018-11-8) ## 3.1.0 (2018-11-08)
**New Features** ## Bug Fixes
* Default address pool for Swarm is now user configurable
* UCP now supports Kubernetes Network Encryption using IPSec * Swarm placement constraint warning banner no longer shows up for `ucp-auth` services (#14539)
* UCP now supports Kubernetes v1.11 * "update out of sequence" error messages no longer appear when changing admin settings (#7093)
* UCP now supports Kubernetes native role-based access control * Kubernetes namespace status appears in the web interface (#14526)
* UCP now provides service metrics for all API calls, using Prometheus deployed as Kubernetes Daemon Set * UCP Kubernetes compose components always run on managers (#14208)
* UCP now supports use of an external Prometheus instance to scrape metrics from UPC endpoints * `docker network ls --filter id=<id>` now works with a UCP client bundle (#14840)
* UCP supports SAML authentication * Collection deletes are correctly blocked if there is a node in the collection (#13704)
* DTR vulnerability scan data is now available through the UCP web interface
## New Features
### Kubernetes
* Kubernetes is updated to version 1.11.2.
* Kubernetes native RBAC feature manages access control for Kubernetes resources. Users can now create roles for Kubernetes APIs using Kubernetes `Role` and `ClusterRole` objects in the Kubernetes API. They can also grant permissions to users and service accounts with the `RoleBinding` and `ClusterRoleBinding` objects. The web interface for Kubernetes RBAC reflects these changes.
### Logging
Admins can now enable audit logging in the UCP config. This logs all incoming user-initiated requests in the `ucp-controller` logs. Admins can choose whether to log only metadata for incoming requests or the full request body as well. For more information, see [Create UCP audit logs](https://docs.docker.com/ee/ucp/admin/configure/create-audit-logs/).
### Authentication
Admins can configure UCP to use a SAML-enabled identity provider for user authentication. If enabled, users who log into the UCP web interface are redirected to the identity provider's website to log in. Upon log in, users are redirected back to the UCP web interface, authenticated as the user chosen. For more information, see [Enable SAML authentication](https://docs.docker.com/ee/ucp/admin/configure/enable-saml-authentication/).
### Metrics
* The `ucp-metrics` Prometheus server (used to render charts in the UCP interface) was engineered from a container on manager nodes to a Kubernetes daemonset. This lets admins change the daemonset's scheduling rules so that it runs on a set of worker nodes instead of manager nodes. Admins can designate certain UCP nodes to be metrics server nodes, freeing up resources on manager nodes. For more information, see [Collect UCP cluster metrics with Prometheus](https://docs.docker.com/ee/ucp/admin/configure/collect-cluster-metrics/).
* The UCP controller has a `/metricsdiscovery` endpoint so users can connect their own Prometheus instances to scrape UCP metrics data.
### UCP web interface
* If you enable single sign-on for a DTR instance with UCP, the UCP web interface shows image vulnerability data for images in that DTR instance. Containers and services that use images from that DTR instance show any vulnerabilities DTR detects.
* The UCP web interface is redesigned to offer larger views for viewing individual resources, with more information for Kubernetes resources.
### Configs
* UCP now stores its configurations in its internal key-value store instead of in a Swarm configuration so changes can propagate across the cluster more quickly.
## API updates
There are several backward-incompatible changes in the Kubernetes API that may affect user workloads. They are:
**API updates**
* There are several backwards-incompatible changes in the Kube API that may affect user workloads. They are:
* 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. * 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: * 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/notReady` to `node.kubernetes.io/not-ready`
@ -44,14 +74,18 @@ upgrade your installation to the latest release.
* 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. * 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. * 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.
**Known issues** ## Known issues
* You must use the ID of the user, organization, or team if you are manually creating a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. * There are important changes to the upgrade process that, if not correctly followed, can impact the availability of applications running on the Swarm during uprades. These constraints impact any upgrades coming from any Docker Engine version before 18.09 to version 18.09 or greater. For more information about about upgrading Docker Enterprise to version 2.1, see [Upgrade Docker](../upgrade)
* For the `User` subject Kind, the `Name` field should be the ID of the user.
* For the `Group` subject Kind, the format depends on whether you are creating a Binding for a team or an organization: * In the UCP web interface, LDAP settings disappear after submitting them. However, the settings are properly saved. (#15503)
* You must use the ID of the user, organization, or team if you manually create a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. (#14935)
* For the `User` subject Kind, the `Name` field contains the ID of the user.
* For the `Group` subject Kind, the format depends on whether you are create a Binding for a team or an organization:
* For an organization, the format is `org:{org-id}` * For an organization, the format is `org:{org-id}`
* For a team, the format is `team:{org-id}:{team-id}` * For a team, the format is `team:{org-id}:{team-id}`
* In order to deploy Pods with containers using Restricted Parameters, a user must be an admin and a service account must explicitly have a **ClusterRoleBinding** with `cluster-admin` as the **ClusterRole**. Restricted Parameters on Containers include: * To deploy Pods with containers using Restricted Parameters, the user must be an admin and a service account must explicitly have a **ClusterRoleBinding** with `cluster-admin` as the **ClusterRole**. Restricted Parameters on Containers include:
* Host Bind Mounts * Host Bind Mounts
* Privileged Mode * Privileged Mode
* Extra Capabilities * Extra Capabilities
@ -59,14 +93,15 @@ upgrade your installation to the latest release.
* Host IPC * Host IPC
* Host PID * Host PID
* If you delete the built-in **ClusterRole** or **ClusterRoleBinding** for `cluster-admin`, restart the `ucp-kube-apiserver` container on any manager node to recreate them. * If you delete the built-in **ClusterRole** or **ClusterRoleBinding** for `cluster-admin`, restart the `ucp-kube-apiserver` container on any manager node to recreate them. (#14483)
**Deprecated features** ## Deprecated features
The following features are deprecated in UCP 3.1 The following features are deprecated in UCP 3.1
* Collections * Collections
* Nested collections are deprecated and will be removed in future versions of the product. Customers should use non-nested collections going forward. * User-created nested collections more than 2 layers deep within the root `/Swarm/` collection are deprecated and will be removed in future versions of the product. In the future, we recommend that at most only two levels of collections be created within UCP under the shared Cluster collection designated as `/Swarm/`. For example, if a production collection is created as a collection under the cluster collection `/Swarm/` as `/Swarm/production/` then at most one level of nestedness should be created, as in `/Swarm/production/app/`.
* Kubernetes * Kubernetes
* **PersistentVolumeLabel** admission controller is deprecated in Kubernetes 1.11. This functionality will be migrated to Cloud Controller Manager [https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/) * **PersistentVolumeLabel** admission controller is deprecated in Kubernetes 1.11. This functionality will be migrated to Cloud Controller Manager [https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/)
* `--cni-install-url` is deprecated in favor of `--unmanaged-cni` * `--cni-install-url` is deprecated in favor of `--unmanaged-cni`