Add release notes for UCP 3.0.0 (#612)

This commit is contained in:
Jim Galasyn 2018-04-13 15:36:41 -07:00
parent 3bc210b096
commit 7a042af274
1 changed files with 136 additions and 0 deletions

View File

@ -12,6 +12,142 @@ known issues for the latest UCP version.
You can then use [the upgrade instructions](admin/install/upgrade.md), to
upgrade your installation to the latest release.
## Version 3.0.0
(16 April 2018)
The UCP system requirements were updated with 3.0.0. Make sure to
[check the system](https://docs.docker.com/ee/ucp/admin/install/system-requirements/)
requirements before upgrading.
### Orchestration
* UCP now supports Kubernetes as an orchestrator, in addition to the existing
Swarmkit and "classic" Swarm orchestrators. Kubernetes system components are
automatically deployed on all manager and Linux worker nodes managed by UCP.
[Learn more about Kubernetes support](https://docs.docker.com/ee/ucp/ucp-architecture/).
* Worker nodes running Linux on amd64 architectures can be configured to run
only Swarm workloads, only Kubernetes workloads, or mixed workloads. Manager
nodes are by default Mixed in order to support Swarm and Kubernetes system
components. However, it is not recommended to run Worker nodes as Mixed due to
potential resource contention issues.
* Users can deploy Kubernetes workloads through the web UI, and the CLI using
a UCP client bundle and `kubectl`.
[Learn more](https://docs.docker.com/ee/ucp/kubernetes/).
* Users can now use Compose to deploy Kubernetes workloads from the web UI.
[Lean more](https://docs.docker.com/ee/ucp/kubernetes/deploy-with-compose/).
### Networking
* UCP includes Calico as the default CNI plugin for networking of Kubernetes
applications. [Learn more](https://docs.projectcalico.org/v3.1/introduction/).
The following Calico features are supported:
* L3 IP-IP Overlay Data Path.
* BGP control plane.
* Calico IPAM.
* Management of Calico CNI plugin lifecycle.
* Kubernetes Network Policy. This is experimental in 3.0.0.
* You can now use layer 7 routing in your Kubernetes workloads by using an
NGINX-based ingress controller.
[Learn more](https://docs.docker.com/ee/ucp/kubernetes/deploy-ingress-controller/).
* Layer 7 routing for Swarmkit applications has been upgraded to use
Interlock backend.
This adds increased performance, stability, and new features including SSL Termination,
Contextual Path-based Routing, Websocket Support, and Canary Application Instance
deployments. Existing Hostname Routing Mesh (HRM) labels (and newly added labels
with the old format) will automatically migrate to the new format. It is strongly
recommended to use the new format for new applications in order to take advantage
of the new features. [Learn more](https://docs.docker.com/ee/ucp/interlock/).
### Storage
* Support for NFS-based Kubernetes persistent volumes. Additional volume plugins
will be available in future releases.
### Security
* Role-based access control now supports Kubernetes resources.
[Lean more](https://docs.docker.com/ee/ucp/authorization/migrate-kubernetes-roles/).
* In addition to users, teams, organizations, and grants you can now use
Kubernetes Service Accounts as a subject type.
[Learn more](https://docs.docker.com/ee/ucp/kubernetes/create-service-account/).
* You can now create custom roles with Kubernetes API permissions. Default
roles include Kubernetes API permissions based on their access type.
As an example, View-Only contains Swarm and Kubernetes read-only API permissions.
* In addition to collections, grants can now use Kubernetes Namespaces as
a resource set type.
* Admins can now link a Kubernetes namespace to a collection of nodes in order
to isolate users and workloads between different nodes.
* Administrators can now enforce only running trusted images for both swarm and
Kubernetes applications. [Learn more](https://docs.docker.com/ee/ucp/admin/configure/run-only-the-images-you-trust/)
* API support for registering multiple UCP clusters to a single DTR for the
purposes of signed image enforcement. [Learn more](https://docs.docker.com/ee/ucp/admin/configure/integrate-with-multiple-registries/).
* The `Restricted Control` role includes the `User Impersonation` Kubernetes action,
which can allow a user to escalate to admin privileges if the role is granted against
`All Kubernetes Namespaces`. For this version, we recommend that administrators do not
grant the `Restricted Control` role against Kubernetes namespaces, and use custom roles
instead. This issue does not affect any other roles in the system, or any of the grants
using `Restricted Control` against collections.
### Known issues
* Platform support
* Kubernetes is not yet supported for Windows based workloads. Use Swarmkit for
Windows based workloads instead.
* EE 2.0 is not yet supported in IBM Z platforms.
* CLI
* Both Docker and `kubectl` CLIs report that UCP is running Kubernetes 1.8.2,
when in fact it is running 1.8.9.
* Networking
* Calico networking for Kubernetes is not supported for Microsoft Azure. UCP
leverages Azure networking and IPAM for control-plane and connectivity.
[Learn how to deploy EE 2.0 on Azure](https://docs.docker.com/ee/ucp/admin/install/install-on-azure/).
* Azure IPAM will fail if nodes in the cluster are connected to different subnets.
As a workaround ensure network setup avoids multiple subnets. This will be
rectified in an upcoming patch release (#12894).
* UCP Calico control-plane supports full-mesh BGP peering only at release-time.
Calico control-plane may cause high CPU on nodes in clusters above 100 nodes.
A route reflector based partial-mesh BGP control-plane will reduce CPU
consumption when scaling past 100 nodes.
Route-reflector configurations will be included in a future release.
* In some deployments the `kube-dns` component won't be able to resolve external
domain names. [Deploy a ConfigMap to work around this](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#configure-stub-domain-and-upstream-dns-servers).
* Management
* If upgrading UCP through the UI, UCP will not check to ensure the manager node
has the minimum memory required of 4 GB. Upgrading through the CLI does check for
this requirement.
* Putting a node in `drain` mode currently removes only Swarm workloads, and not
Kubernetes workloads. This will be fixed in a future release.
* Kubernetes base image layer uses Ubuntu 16.04 which contains some known CVE
vulnerabilities. These will be removed when the base image layer is updated.
* Running `docker system prune -a` directly on individual worker nodes in the cluster
will potentially delete UCP system images. This behavior will not occur if the
prune command is run using a UCP client bundle.
* Compose for Kubernetes only supports v3 or higher YAML files. Any older
version YAML files will silently fail without errors.
* Linking Kubernetes namespace to a collection of nodes in order to isolate
Kubernetes workloads between different nodes is not working as expected.
[You can use this workaround](https://success.docker.com/article/workaround-for-link-nodes-in-collection-ucp-300).
* Running `kubectl get cs` might show some internal UCP components as
unhealthy when that's not the case.
* Storage
* UCP does not yet support dynamic volume provisioning (NFS volumes do not
support this). This will change in future releases when more volume types
are available.
### Deprecation notice
The following functionality has been deprecated with UCP 3.0.0 and will be
unavailable in the next UCP feature release.
* The web UI is going to stop supporting users to deploy stacks with basic
containers. You should update your Compose files to version 3, and deploy your
stack as a Swarm service or Kubernetes workload.
* The option to integrate with a remote Syslog system is going to be removed
from the UCP web UI. You can configure Docker Engine for this.
* The option to configure a rescheduling policy for basic containers is
deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
## Version 3.0.0-beta3
(8 March 2018)