Merge "Added warning for K8 Root CA update impact on services"
This commit is contained in:
commit
a24d9d27f2
@ -4,22 +4,29 @@
|
||||
Kubernetes Root CA Certificate Update for Distributed Cloud Orchestration
|
||||
=========================================================================
|
||||
|
||||
.. warning::
|
||||
During the Kubernetes Root |CA| update, ``deployments``, ``daemonsets``, and
|
||||
``statefulsets`` present in the cluster are rolling restarted. This impacts
|
||||
services provided by the application. It is highly recommended to schedule
|
||||
a Kubernetes Root |CA| update during planned maintenance windows.
|
||||
|
||||
You can use the :command:`dcmanager` command to orchestrate the update of the
|
||||
Kubernetes Root |CA| certificate(s) for one or more subclouds in a Distributed
|
||||
Cloud Environment.
|
||||
|
||||
The Kubernetes Root |CA| Update Distributed Cloud Orchestration commands for
|
||||
The Kubernetes Root |CA| update Distributed Cloud Orchestration commands for
|
||||
DCManager use the keyword ``kube-rootca-update-strategy`` and provide the same
|
||||
five subcommands as the other orchestrations: :command:`create, delete, apply,
|
||||
abort, show`.
|
||||
|
||||
DCManager Kubernetes Root |CA| update orchestration considers a subcloud to be
|
||||
'out of sync' and needing to be orchestrated based on the
|
||||
``kube-rootca_sync_status`` field, which is updated based on the presence of
|
||||
alarms in the subcloud related to the Kubernetes Root |CA| certificate expiring
|
||||
soon (or expired).
|
||||
'out of sync' that needs to be orchestrated based on the ``kube-rootca_sync_status``
|
||||
field, which is updated based on the presence of alarms in the subcloud
|
||||
related to the Kubernetes Root |CA| certificate expiring soon (or expired)
|
||||
status.
|
||||
|
||||
- To see synchronization details for a subcloud.
|
||||
- Use the :command:`dcmanager subcloud show subcloud1` command to
|
||||
see synchronization details for a subcloud.
|
||||
|
||||
.. code-block::
|
||||
|
||||
@ -54,7 +61,7 @@ soon (or expired).
|
||||
| platform_sync_status | in-sync |
|
||||
+-----------------------------+----------------------------+
|
||||
|
||||
- A user can pass "help" to see all the arguments for the strategy create
|
||||
- A user can pass ``help`` to see all the arguments for the :command:`strategy create`
|
||||
command.
|
||||
|
||||
.. code-block::
|
||||
@ -77,7 +84,8 @@ soon (or expired).
|
||||
[--cert-file CERT_FILE]
|
||||
[cloud_name]
|
||||
|
||||
Create a kube rootca update strategy. This strategy supports: expiry-date, subject and cert-file.
|
||||
Create a Kubernetes Root |CA| update strategy. This strategy supports
|
||||
expiry-date, subject and cert-file parameters.
|
||||
|
||||
positional arguments:
|
||||
cloud_name Name of a single subcloud to update.
|
||||
@ -112,7 +120,7 @@ used with other arguments to orchestrate just one subcloud or subcloud group.
|
||||
This is an example of how to orchestrate a new certificate for all subclouds,
|
||||
including those that are in-sync that will expire in one year.
|
||||
|
||||
#. Create a Root |CA| update strategy.
|
||||
#. Create a Kubernetes Root |CA| update strategy.
|
||||
|
||||
.. code-block::
|
||||
|
||||
@ -160,7 +168,7 @@ including those that are in-sync that will expire in one year.
|
||||
| updated_at | 2021-10-26T14:37:36.865776 |
|
||||
+-----------------------------+----------------------------+
|
||||
|
||||
#. You can view the status of the strategy.
|
||||
#. You can view the status of the strategy using the following command.
|
||||
|
||||
.. code-block::
|
||||
|
||||
@ -178,10 +186,10 @@ including those that are in-sync that will expire in one year.
|
||||
| updated_at | 2021-10-26 14:37:36.865776 |
|
||||
+-----------------------------+----------------------------+
|
||||
|
||||
It is typically more useful to monitor the progress of the strategy as it runs
|
||||
in the subclouds.
|
||||
It is typically more useful to monitor the progress of the strategy as it
|
||||
runs in the subclouds.
|
||||
|
||||
In this example, the |DC| strategy is running the VIM strategy in the subcloud.
|
||||
In example below, the |DC| strategy runs the VIM strategy in the subcloud.
|
||||
|
||||
.. code-block::
|
||||
|
||||
@ -194,7 +202,7 @@ including those that are in-sync that will expire in one year.
|
||||
+-----------+-------+------------------------------------------+----------------------------+----------------------------+-------------+
|
||||
|
||||
#. Wait for the strategy to complete. If there are failures, the
|
||||
:command:`show` command in the previous step can indicate where the failure
|
||||
:command:`show` command in the previous step indicates where the failure
|
||||
occurred.
|
||||
|
||||
#. Only one type of DCManager strategy can exist at a time. Once completed,
|
||||
|
@ -18,6 +18,12 @@ either an uploaded certificate or an auto generated certificate.
|
||||
|
||||
Special care should be taken when updating the Root |CA| certificate.
|
||||
|
||||
.. warning::
|
||||
During the Kubernetes Root |CA| update, ``deployments``, ``daemonsets``, and
|
||||
``statefulsets`` present in the cluster are rolling restarted. This impacts
|
||||
services provided by the application. It is highly recommended to schedule
|
||||
a Kubernetes Root |CA| update during planned maintenance windows.
|
||||
|
||||
.. rubric:: |prereq|
|
||||
|
||||
- The system is clear of alarms \(with the exception of alarms for locked
|
||||
|
@ -15,7 +15,6 @@ certain order and phases, with most of the commands to be executed host by
|
||||
host.
|
||||
|
||||
.. warning::
|
||||
|
||||
Do **not** let the Kubernetes Root |CA| certificate expire on your system
|
||||
and ensure that certificates with valid/adequate expiry dates are used
|
||||
during renewal as there is no easy way to recover a system if the
|
||||
@ -23,6 +22,12 @@ host.
|
||||
|
||||
Special care should be taken when updating the Root |CA| certificate.
|
||||
|
||||
.. warning::
|
||||
During the Kubernetes Root |CA| update, ``deployments``, ``daemonsets``, and
|
||||
``statefulsets`` present in the cluster are rolling restarted. This impacts
|
||||
services provided by the application. It is highly recommended to schedule
|
||||
a Kubernetes Root |CA| update during planned maintenance windows.
|
||||
|
||||
.. rubric:: |prereq|
|
||||
|
||||
- The system must be clear of alarms \(with the exception of alarms for locked
|
||||
|
Loading…
Reference in New Issue
Block a user