4dd4fa7463
Acted on Greg's comments Patch 1: Acted on Greg's comments and added the missing files. Patch 2: Solved merge conflicts Signed-off-by: egoncalv <elisamaraaoki.goncalves@windriver.com> Change-Id: I70c5d3b9c3927320f977b62878ee60ab9956fc91
183 lines
7.1 KiB
ReStructuredText
183 lines
7.1 KiB
ReStructuredText
|
|
.. htb1590431033292
|
|
.. _the-kubernetes-update-orchestration-process:
|
|
|
|
=======================================================
|
|
Kubernetes Version Upgrade Cloud Orchestration Overview
|
|
=======================================================
|
|
|
|
For an orchestrated Kubernetes version upgrade you need to first create a
|
|
*Kubernetes Upgrade Orchestration Strategy*, or plan for the automated
|
|
Kubernetes version upgrade procedure.
|
|
|
|
You can customize the Kubernetes version upgrade orchestration by specifying
|
|
the following parameters:
|
|
|
|
|
|
.. _htb1590431033292-ul-pdh-5ms-tlb:
|
|
|
|
- The host types to be upgraded; only **worker-apply-type** is supported.
|
|
|
|
- The alarm restriction mode; **strict** or **relaxed** where the **relaxed**
|
|
mode allows the strategy to be created while there are alarms present that
|
|
are not management-affecting.
|
|
|
|
- The concurrency of the upgrade process; whether to Kubernetes version
|
|
upgrade hosts **serially** or in **parallel**.
|
|
|
|
- The maximum number of worker hosts that can be upgraded together when
|
|
**parallel** mode is selected.
|
|
|
|
|
|
For hosts that have the |prefix|-openstack application running with active
|
|
instances and since the Kubernetes version upgrade is a reboot required
|
|
operation for a host, the strategy offers **stop/start** or **migrate** options
|
|
for managing instances over the **lock/unlock** \(reboot\) steps in the upgrade
|
|
process.
|
|
|
|
You must use the **sw-manager** CLI tool to **create**, and then **apply** the
|
|
upgrade strategy. A created strategy can be monitored with the **show**
|
|
command.
|
|
|
|
Kubernetes version upgrade orchestration automatically iterates through all
|
|
**unlocked-enabled** hosts on the system looking for hosts with the worker
|
|
function that need Kubernetes version upgrade and then proceeds to upgrade them
|
|
on the strategy :command:`apply` action.
|
|
|
|
.. note::
|
|
Controllers (including |AIO| controllers) are upgraded before worker only
|
|
hosts. Storage hosts do not run Kubernetes so Kubernetes is not upgraded
|
|
on them, although they still may be patched.
|
|
|
|
After creating the *Kubernetes Version Upgrade Orchestration Strategy*, you can
|
|
either apply the entire strategy automatically, or manually apply individual
|
|
stages to control and monitor the Kubernetes version upgrade progress one stage
|
|
at a time.
|
|
|
|
When the Kubernetes version upgrade strategy is **applied**, if the system is
|
|
All-in-one, the controllers are upgraded first, one after the other with a
|
|
swact in between, followed by the remaining worker hosts according to the
|
|
selected worker apply concurrency \(**serial** or **parallel**\) method.
|
|
|
|
The strategy creation default is to upgrade the worker hosts serially unless
|
|
the **parallel** worker apply type option is specified which configures the
|
|
Kubernetes version upgrade process for worker hosts to be in parallel \(up to a
|
|
maximum parallel number\) to reduce the overall Kubernetes version upgrade
|
|
installation time.
|
|
|
|
The upgrade takes place in two phases. The first phase upgrades the patches
|
|
(controllers, storage and then workers), and the second phase upgrades
|
|
Kubernetes based on those patches (controllers, then hosts).
|
|
|
|
.. _htb1590431033292-ol-a1b-v5s-tlb:
|
|
|
|
#. Alarm query. This step is an upgrade pre-check.
|
|
|
|
#. Initiate the Kubernetes version upgrade.
|
|
|
|
#. Download Kubernetes Images.
|
|
|
|
#. Upgrade the first Control Plane.
|
|
|
|
#. Upgrade Kubernetes networking.
|
|
|
|
#. Upgrade the second control plane (on duplex environments only).
|
|
|
|
#. Patch the hosts.
|
|
|
|
#. Patch controller nodes if they are not |AIO|.
|
|
|
|
#. Patch storage nodes.
|
|
|
|
#. Patch worker nodes (this includes |AIO| controllers).
|
|
|
|
#. Upgrade Kubelets on the hosts (controllers then workers. If controllers
|
|
are |AIO| they are processed before regular workers).
|
|
|
|
#. Swact if the host is the active controller.
|
|
|
|
#. Lock the host.
|
|
|
|
#. Upgrade kubelet.
|
|
|
|
#. Unlock the host.
|
|
|
|
#. Restore |VMs| (if applicable).
|
|
|
|
#. Complete the Kubernetes version upgrade.
|
|
|
|
Systems with |prefix|-openstack application enabled could include additional
|
|
instance management steps. For more information, see :ref:`Kubernetes Version
|
|
Upgrade Operations Requiring Manual Migration
|
|
<kubernetes-update-operations-requiring-manual-migration>`.
|
|
|
|
On systems with |prefix|-openstack application, the *Kubernetes Version Upgrade
|
|
Orchestration Strategy* considers any configured server groups and host
|
|
aggregates when creating the stages to reduce the impact to running instances.
|
|
The *Kubernetes Version Upgrade Orchestration Strategy* automatically manages
|
|
the instances during the strategy application process. The instance management
|
|
options include **start-stop** or **migrate**.
|
|
|
|
|
|
.. _htb1590431033292-ul-vcp-dvs-tlb:
|
|
|
|
- **start-stop**: where instances are stopped following the actual Kubernetes
|
|
upgrade but before the lock operation and then automatically started again
|
|
after the unlock completes. This is typically used for instances that do
|
|
not support migration or for cases where migration takes too long. To
|
|
ensure this does not impact the high-level service being provided by the
|
|
instance, the instance\(s\) should be protected and grouped into an
|
|
anti-affinity server group\(s\) with its standby instance.
|
|
|
|
- **migrate**: where instances are moved off a host following the Kubernetes
|
|
upgrade but before the host is locked. Instances with **Live Migration**
|
|
support are **Live Migrated**. Otherwise, they are **Cold Migrated**.
|
|
|
|
|
|
.. _kubernetes-update-operations-requiring-manual-migration:
|
|
|
|
----------------------------------------
|
|
Manually Migrating Application Instances
|
|
----------------------------------------
|
|
|
|
On systems with the |prefix|-openstack application there may be some instances
|
|
that cannot be migrated automatically by orchestration. In these cases the
|
|
instance migration must be managed manually.
|
|
|
|
Do the following to manage the instance re-location manually:
|
|
|
|
|
|
.. _rbp1590431075472-ul-mgr-kvs-tlb:
|
|
|
|
- Manually perform Kubernetes version upgrade at least one openstack-compute worker host. This
|
|
assumes that at least one openstack-compute worker host does not have any
|
|
instances, or has instances that can be migrated. For more information on
|
|
manually updating a host, see :ref:`Manual Kubernetes Version Upgrade
|
|
<manual-kubernetes-components-upgrade>`.
|
|
|
|
- If the migration is prevented by limitations in the VNF or virtual
|
|
application, perform the following:
|
|
|
|
|
|
- Create new instances on an already upgraded openstack-compute worker
|
|
host.
|
|
|
|
- Manually migrate the data from the old instances to the new instances.
|
|
|
|
.. note::
|
|
This is specific to your environment and depends on the virtual
|
|
application running in the instance.
|
|
|
|
- Terminate the old instances.
|
|
|
|
|
|
- If the migration is prevented by the size of the instances local disks:
|
|
|
|
|
|
- For each openstack-compute worker host that has instances that cannot
|
|
be migrated, manually move the instances using the CLI.
|
|
|
|
Once all openstack-compute worker hosts containing instances that cannot be
|
|
migrated have been Kubernetes version upgraded, Kubernetes version upgrade
|
|
orchestration can then be used to upgrade the remaining worker hosts.
|