The `service-cluster-ip-range` Kubernetes API Server flag is currently set to `10.96.0.0/16` and cannot be changed.
Swarm uses a default address pool of `10.0.0.0/16` for its overlay networks. If this conflicts with your current network implementation, please use a custom IP address pool. To specify a custom IP address pool, use the `--default-address-pool` command line option during [Swarm initialization](../../../../engine/swarm/swarm-mode.md).
Swarm uses a default address pool of `10.0.0.0/8` for its overlay networks. If this conflicts with your current network implementation, please use a custom IP address pool. To specify a custom IP address pool, use the `--default-address-pool` command line option during [Swarm initialization](../../../../engine/swarm/swarm-mode.md).
> **Note**: Currently, the UCP installation process does not support this flag. To deploy with a custom IP pool, Swarm must first be installed using this flag and UCP must be installed on top of it.
@ -22,7 +22,7 @@ You can install UCP on-premises or on a cloud provider. Common requirements:
* 8GB of RAM for manager nodes
* 4GB of RAM for worker nodes
* 2 vCPUs for manager nodes
* 5GB of free disk space for the `/var` partition for manager nodes (A minimum of 6GB is recommended.)
* 10GB of free disk space for the `/var` partition for manager nodes (A minimum of 6GB is recommended.)
* 500MB of free disk space for the `/var` partition for worker nodes
**Note**: Increased storage is required for Kubernetes manager nodes in UCP 3.1. If you are upgrading to UCP 3.1, refer to [Kubelet restarting after upgrade to Universal Control Plane 3.1](https://success.docker.com/article/kublet-restarting-after-upgrade-to-universal-control-plane-31) for information on how to increase the size of the `/var/lib/kubelet` filesystem.
@ -86,6 +86,16 @@ host types:
| managers | TCP 12386 | Internal | Port for the authentication worker |
| managers | TCP 12388 | Internal | Internal Port for the Kubernetes API Server |
## Disable `CLOUD_NETCONFIG_MANAGE` for SLES 15
For SUSE Linux Enterprise Server 15 (SLES 15) installations, you must disable `CLOUD_NETCONFIG_MANAGE`
prior to installing UCP.
1. In the network interface configuration file, `/etc/sysconfig/network/ifcfg-eth0`, set
```
CLOUD_NETCONFIG_MANAGE="no"
```
2. Run `service network restart`.
## Avoid firewall conflicts
For SUSE Linux Enterprise Server 12 SP2 (SLES12), the `FW_LO_NOTRACK` flag is turned on by default in the openSUSE firewall. This speeds up packet processing on the loopback interface, and breaks certain firewall setups that need to redirect outgoing packets via custom rules on the local machine.
**Note**: The `docker image pull` command in the previous example is not needed if the images are pulled as described
in the **Procedural** section of [prerequisites](#procedural).
From UCP 3.0: UCP 3.0 -> UCP 3.1
From UCP 2.2: UCP 2.2 -> UCP 3.0
From UCP 2.1: UCP 2.1 -> UCP 2.2
### Upgrade existing nodes in place
This workflow is performed when:
If you’re running a UCP version earlier than 2.1, first upgrade to the latest 2.1 version, then upgrade to 2.2. Use these rules for your upgrade path to UCP 2.2:
- You are upgrading existing worker nodes in place. This workflow also includes adding additional worker nodes if needed.
1. Upgrade manager nodes
- Run the upgrade on a manager node. The `--manual-worker-upgrade` option automatically upgrades manager nodes first and then
allows you to control the upgrade of the UCP components on worker nodes using node labels, as shown in the following example.
```
export ucp_version=3.2.0
docker image pull docker/ucp:$ucp_version
docker container run --rm -it \
--name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp:$ucp_version \
upgrade --manual-worker-upgrade \
--interactive
```
Note: The `docker image pull` command in this example is not needed if the images are pulled as described
in the **Procedural** section of [prerequisites](#procedural).
2. Upgrade worker nodes in place
- On the manager node, after the `--manual-worker-upgrade` command completes, remove the `upgrade-hold` label on one or
more nodes to upgrade the UCP components on those worker nodes in place:
If you’re running a UCP version earlier than 2.1, first upgrade to the latest 2.1 version, then upgrade to 2.2. Use the following rules for your upgrade path to UCP 2.2:
@ -60,7 +60,7 @@ Error log information can be accessed for troubleshooting.
- User workloads no longer experience downtime during an upgrade.
## Deprecations
The following features are deprecated in UCP 3.1:
The following features are deprecated in UCP 3.2:
- Collections
- The ability to create a nested collection of more than 2 layers deep within the root /Swarm/collection is
@ -72,6 +72,11 @@ The following features are deprecated in UCP 3.1:
example, /Swarm/production/app/. See Nested collections for more details.
- UCP `stop` and `restart`
- Additional upgrade functionality has been included which eliminates the need for these commands.
- `ucp-agent-pause`
- `ucp-agent-pause` is no longer supported. To pause UCP reconciliation on a specific node, for example, when repairing unhealthy `etcd` or `rethinkdb` replicas, you can use swarm node labels as shown in the following example:
In order to optimize user experience and security, support for Internet Explorer (IE) version 11 is not provided for Windows 7 with UCP version 3.2. Docker recommends updating to a newer browser version if you plan to use UCP 3.2, or remaining on UCP 3.1.x or older until EOL of IE11 in January 2020.
Maria Bermudez