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
commit d498f264b9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 55 additions and 20 deletions

View File

@ -21,20 +21,50 @@ upgrade your installation to the latest release.
# Version 3.1
## 3.1.0 (2018-11-8)
## 3.1.0 (2018-11-08)
**New Features**
* Default address pool for Swarm is now user configurable
* UCP now supports Kubernetes Network Encryption using IPSec
* UCP now supports Kubernetes v1.11
* UCP now supports Kubernetes native role-based access control
* 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 web interface
## Bug Fixes
* Swarm placement constraint warning banner no longer shows up for `ucp-auth` services (#14539)
* "update out of sequence" error messages no longer appear when changing admin settings (#7093)
* Kubernetes namespace status appears in the web interface (#14526)
* UCP Kubernetes compose components always run on managers (#14208)
* `docker network ls --filter id=<id>` now works with a UCP client bundle (#14840)
* Collection deletes are correctly blocked if there is a node in the collection (#13704)
## 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.
* 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`
@ -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.
* If you have a pod with a subpath volume PVC, theres a chance that after the upgrade, it will conflict with some other pod; see [this pull request](https://github.com/kubernetes/kubernetes/pull/61373). Its not clear if this issue will just prevent those pods from starting or if the whole cluster will fail.
**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.
* 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:
## Known issues
* 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)
* 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 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
* Privileged Mode
* Extra Capabilities
@ -59,14 +93,15 @@ upgrade your installation to the latest release.
* Host IPC
* 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
* 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
* **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`