From daa5a0f1fccea87d43f7a5a29135db8cadec4113 Mon Sep 17 00:00:00 2001 From: Aleksandr Arefev <39635005+alexarefev@users.noreply.github.com> Date: Thu, 14 Dec 2023 09:10:46 +0300 Subject: [PATCH 1/4] MG update --- documentation/Maintenance.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/Maintenance.md b/documentation/Maintenance.md index cbd3f4ca7..36319c8f2 100644 --- a/documentation/Maintenance.md +++ b/documentation/Maintenance.md @@ -46,6 +46,9 @@ Before you start any maintenance procedure, you must complete the following mand 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 `KubeMarine` concept the `cluster.yaml` is a reflection of a Kubernetes cluster state. Therefore, any changes on cluster must be reflected in `cluster.yaml` in the corresponding section to be consistent with the cluster state. That is important practice even if the `cluster.yaml` section or option is applicable only for installation procedure, because the particular `cluster.yaml` could be used for reinstallation or reproduction some cases. For the changes that can't be reflected in `cluster.yaml` appropriate comments could be used. # Provided Procedures @@ -329,9 +332,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: From e3f8697264e3f2202b752264d1461eb5b5ab879f Mon Sep 17 00:00:00 2001 From: ilia1243 <8808144+ilia1243@users.noreply.github.com> Date: Tue, 9 Jan 2024 16:51:10 +0300 Subject: [PATCH 2/4] Add notes about kubeadm reconfiguration and more about maintenance --- README.md | 2 +- documentation/Installation.md | 2 ++ documentation/Maintenance.md | 11 +++++++++-- 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 536a8baa7..d79f47afd 100644 --- a/README.md +++ b/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) diff --git a/documentation/Installation.md b/documentation/Installation.md index 9ee66e69a..2f2f9b241 100644 --- a/documentation/Installation.md +++ b/documentation/Installation.md @@ -1136,6 +1136,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. diff --git a/documentation/Maintenance.md b/documentation/Maintenance.md index 36319c8f2..b1f0c3df2 100644 --- a/documentation/Maintenance.md +++ b/documentation/Maintenance.md @@ -42,13 +42,20 @@ 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 `KubeMarine` concept the `cluster.yaml` is a reflection of a Kubernetes cluster state. Therefore, any changes on cluster must be reflected in `cluster.yaml` in the corresponding section to be consistent with the cluster state. That is important practice even if the `cluster.yaml` section or option is applicable only for installation procedure, because the particular `cluster.yaml` could be used for reinstallation or reproduction some cases. For the changes that can't be reflected in `cluster.yaml` appropriate comments could be used. +According to `KubeMarine` concept the `cluster.yaml` is a reflection of a Kubernetes cluster state. +Therefore, any changes on cluster must be reflected in `cluster.yaml` in the corresponding section to be consistent with the cluster state. +That is important practice even if the `cluster.yaml` section or option is applicable only for installation procedure, because the particular `cluster.yaml` could be used for reinstallation or reproduction some cases. +For the changes that can't be reflected in `cluster.yaml` appropriate comments could be used. + +Maintenance of the cluster can be done in two scenarios: +1. It can be performed using some Kubemarine procedure. In this case Kubemarine does its best to keep `cluster.yaml` and the cluster constistent to each other. +2. Cluster can be reconfigured manually. In this case the user should also manually reflect the changes in the `cluster.yaml`. # Provided Procedures From 7d0bf95146620c8949559ffe5b0fbf417ffaf412 Mon Sep 17 00:00:00 2001 From: Shoaib Mohammed <94443646+shmo1218@users.noreply.github.com> Date: Tue, 9 Jan 2024 22:53:45 +0530 Subject: [PATCH 3/4] Update Maintenance.md --- documentation/Maintenance.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/documentation/Maintenance.md b/documentation/Maintenance.md index b1f0c3df2..97523da4f 100644 --- a/documentation/Maintenance.md +++ b/documentation/Maintenance.md @@ -48,14 +48,14 @@ Before you start any maintenance procedure, you must complete the following mand # Basics -According to `KubeMarine` concept the `cluster.yaml` is a reflection of a Kubernetes cluster state. -Therefore, any changes on cluster must be reflected in `cluster.yaml` in the corresponding section to be consistent with the cluster state. -That is important practice even if the `cluster.yaml` section or option is applicable only for installation procedure, because the particular `cluster.yaml` could be used for reinstallation or reproduction some cases. -For the changes that can't be reflected in `cluster.yaml` appropriate comments could be used. - -Maintenance of the cluster can be done in two scenarios: -1. It can be performed using some Kubemarine procedure. In this case Kubemarine does its best to keep `cluster.yaml` and the cluster constistent to each other. -2. Cluster can be reconfigured manually. In this case the user should also manually reflect the changes in the `cluster.yaml`. +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 From ccdeca7eca58aed97e3f497ff27f2b7b0cf18e8e Mon Sep 17 00:00:00 2001 From: sergey kryazhev Date: Thu, 11 Jan 2024 13:03:34 +0300 Subject: [PATCH 4/4] fixes --- documentation/Maintenance.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/documentation/Maintenance.md b/documentation/Maintenance.md index 97523da4f..1278ae333 100644 --- a/documentation/Maintenance.md +++ b/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) @@ -48,14 +49,15 @@ Before you start any maintenance procedure, you must complete the following mand # Basics -According to the `KubeMarine` concept, `cluster.yaml` is a reflection of the Kubernetes cluster state. +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`. + +- 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