Add docs for instantiated systemd services #172
Conversation
jrauh01
force-pushed
the
systemd-instantiated-service
branch
4 times, most recently
from
a31bee6 to
33f861d
Compare
jrauh01
force-pushed
the
systemd-instantiated-service
branch
from
33f861d to
e930954
Compare
jrauh01
changed the title
There was a problem hiding this comment.
As stated in the change requests, please also adjust https://github.com/Icinga/icinga-kubernetes/blob/main/doc/02-Installation.md#running-icinga-for-kubernetes. README.md also needs to be adjusted, but we will do that after the changes to 01-About.md are fine.
doc/01-About.md
Outdated
| @@ -29,6 +29,8 @@ each connecting to a different cluster but writing data into the same database. | |||
| The web interface accesses this database to display resource information and state, | |||
| offering the flexibility to view aggregated data from all clusters or focus on a specific cluster. | |||
| This setup ensures scalable monitoring and a unified view of resources across multiple Kubernetes environments. | |||
| To monitor multiple clusters you have to | |||
There was a problem hiding this comment.
I would rewrite the whole paragraph to better describe the two options for multi-cluster support:
- The Icinga for Kubernetes daemon is installed in different clusters and all daemons connect to a database outside the clusters via an external service. The web interface is also located outside the clusters.
- All components run outside the Kubernetes clusters and multi-cluster support is provided via instantiated systemd services.
(this text is not intended for copy and paste)
doc/03-Configuration.md
Outdated
|
|
||
| ## Multiple Clusters | ||
|
|
||
| ### Systemd |
There was a problem hiding this comment.
There is no need to have this as a subheading as there is no other option that needs to be described here. I would simply use Multi-Cluster Support using systemd Instantiated Services.
doc/03-Configuration.md
Outdated
|
|
||
| ### Systemd | ||
|
|
||
| If you are running Icinga for Kubernetes with systemd, you have to follow these steps. |
There was a problem hiding this comment.
I would replace this with an introduction, e.g. that since version 0.3 we use systemd-instantiated services for multi-cluster support and that it is possible to connect to multiple Kubernetes clusters when running Icinga for Kubernetes components outside of Kubernetes clusters. I would explain that we manage instances with env files and how these files/instances work in general, also that it is intended to put KUBECONFIG there but that it is also possible to override any other configuration, that the cluster name is derived from the env filename but can also be overridden with ICINGA_FOR_KUBERNETES_CLUSTER_NAME and that the cluster name is used in the frontend.
Then I would explain the purpose of the default.env in a subheading as it needs to be linked to our installation docs which also need to be adjusted.
Then I would explain how to add a new instance like you did with test-cluster.
doc/03-Configuration.md
Outdated
| 2. Reload the systemd daemon with `systemctl daemon-reload` to make sure the daemon forgets the file. | ||
| 3. Stop the service instance manually. For `test-cluster` it would be `systemctl stop icinga-kubernetes@test-cluster`. | ||
|
|
||
| !!! Warning |
doc/03-Configuration.md
Outdated
|
|
||
| #### Remove Instance | ||
|
|
||
| 1. Remove the corresponding file from `/etc/icinga-kubernetes`. |
There was a problem hiding this comment.
The order does not seem logical to me. I would first stop the service, then remove the file and then reload the systemd daemon.
jrauh01
force-pushed
the
systemd-instantiated-service
branch
8 times, most recently
from
2707cc5 to
aef4ca1
Compare
jrauh01
force-pushed
the
systemd-instantiated-service
branch
from
aef4ca1 to
9fe0599
Compare
This PR documents how to run multiple service instances to monitor multiple clusters.
Closes #164