[PSUPCLPL-14309] Maintenance guide update (#575)

* MG update

* Add notes about kubeadm reconfiguration and more about maintenance

* Update Maintenance.md

* fixes

---------

Co-authored-by: ilia1243 <[email protected]>
Co-authored-by: Shoaib Mohammed <[email protected]>
Co-authored-by: sergey kryazhev <[email protected]>

README.md

@@ -9,7 +9,7 @@ Kubemarine is an open source, lightweight and powerful management tool built for
 
 ## Highlights
 - Easy to use
-- Many procedures supported:
+- Many procedures supported following the [generic maintenance approach](documentation/Maintenance.md#basics):
   - [install](documentation/Installation.md#)
   - [add_node](documentation/Maintenance.md#add-node-procedure)
   - [remove_node](documentation/Maintenance.md#remove-node-procedure)

documentation/Installation.md

@@ -1138,6 +1138,8 @@ services:
 
 **Warning**: These kubeadm parameters are configurable only during installation, currently. 
 Kubemarine currently do not provide special procedure to change these parameters after installation.
+To reconfigure the parameters manually, refer to the official documentation at [https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure).
+For more information about generic approach of the cluster maintenance, refer to [Maintenance Basics](Maintenance.md#basics).
 
 During init, join, upgrade procedures kubeadm runs `preflight` procedure to do some preliminary checks. In case of any error kubeadm stops working. Sometimes it is necessary to ignore some preflight errors to deploy or upgrade successfully.
 

documentation/Maintenance.md

@@ -1,6 +1,7 @@
 This section describes the features and steps for performing maintenance procedures on the existing Kubernetes cluster.
 
 - [Prerequisites](#prerequisites)
+- [Basics](#basics)
 - [Provided Procedures](#provided-procedures)
     - [Kubemarine Migration Procedure](#kubemarine-migration-procedure)
       - [Software Upgrade Patches](#software-upgrade-patches)
@@ -42,10 +43,21 @@ Before you start any maintenance procedure, you must complete the following mand
 1. If using custom RPM repositories, make sure they are online, accessible from nodes, and you are able to perform repository updates.
 1. Prepare the latest actual **cluster.yaml** that should contain information about the current cluster state. For more information, refer to the [Kubemarine Inventory Preparation](Installation.md#inventory-preparation) section in _Kubemarine Installation Procedure_.
 
-   **Note**: If you provide an incorrect config file, it can cause unknown consequences.
+   **Note**: If you provide an incorrect config file, it can cause unknown consequences. For more information, refer to [Basics](#basics). 
 
 1. Prepare **procedure.yaml** file containing the configuration for the procedure that you are about to perform. Each procedure has its own configuration format. Read documentation below to fill procedure inventory data.
 
+# Basics
+
+According to the Kubemarine concept, `cluster.yaml` is a reflection of the Kubernetes cluster state.
+Therefore, any changes on the cluster must be reflected in `cluster.yaml` in the corresponding section to be consistent with the cluster state.
+This is an important practice even if the `cluster.yaml` section or option is applicable only for the installation procedure because the particular `cluster.yaml` can be used for the reinstallation or reproduction of some cases.
+For the changes that cannot be reflected in `cluster.yaml`, the appropriate comments can be used.
+
+The maintenance of the cluster can be done in two scenarios:
+
+- It can be performed using some Kubemarine procedure. In this case, Kubemarine does its best to keep `cluster.yaml` and the cluster consistent to each other.
+- The cluster can be reconfigured manually. In this case, the user should also manually reflect the changes in the `cluster.yaml`.
 
 # Provided Procedures
 
@@ -329,9 +341,6 @@ etcd:
 ...
 ```
 
-**Note**: All the custom settings for the system services should be properly reflected in the cluster.yaml (see [services.kubeadm parameters](Installation.md#kubeadm)) to be kept after upgrade.
-
-
 #### Thirdparties Upgrade Section and Task
 
 If the cluster is located in an isolated environment, it is possible to specify the custom paths to new thirdparties with the same syntax as in the `cluster.yaml` as shown in the following script: