@jfvilas/plugin-kwirth-metrics 0.12.7 → 0.12.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +22 -8
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -8,6 +8,7 @@ This very first version of KwirthMetrics is compatible with Kwirth core server v
|
|
|
8
8
|
| Plugin Kwirth version | Kwirth version |
|
|
9
9
|
|-|-|
|
|
10
10
|
|0.12.5|0.4.20|
|
|
11
|
+
|0.12.8|0.4.45|
|
|
11
12
|
|
|
12
13
|
|
|
13
14
|
|
|
@@ -45,7 +46,9 @@ Let's explain this by following a user working sequence:
|
|
|
45
46
|
1. A Backstage user searchs for an entity in the Backstage.
|
|
46
47
|
2. In the entity page there will be a new tab named 'KWIRTHMETRICS'.
|
|
47
48
|
3. When the user clicks on KWIRTHMETRICS the frontend plugin sends a request to the backend plugin asking for metrics information on several Kubernetes clusters.
|
|
48
|
-
4.
|
|
49
|
+
4. Next step is to identify the Kubernetes objects that match requested entity. As well as it occurs with other Backstage Kwirth plugins, Kwirth implements two strategies for getting the listo of kubernetes objects that match:
|
|
50
|
+
- *Option 1*. Your catalog-info contains an annotation of this type: **backstage.io/kubernetes-id**. In this case, the Backstage Kwirth backend plugin sends requests to the Kwirth instances that are running inside all the clusters previously added to Backstage (via app-config YAML). These requests ask for the following: *'Tell me all the pods that are labeled with the kubernetes-id label and do correspond with the entity I'm looking for'*. In response to this query, each Kwirth instance answers with a list of pods and the namespaces where they are running.
|
|
51
|
+
- *Option 2*. Your catalog-info contains an annotation of this type: **backstage.io/kubernetes-label-selector**. In this case, the Backstage Kwirth backend plugin sends requests to the Kwirth instances that are running inside all the clusters previously added to Backstage (via app-config YAML). These requests ask for the following: *'Tell me all the pods whose labels match with the kubernetes-label-selector label selector*. In response to this query, each Kwirth instance answers with a list of pods and the namespaces where they are running.
|
|
49
52
|
5. The backend plugin checks the permissions of the connected user and prunes the pods list removing the ones that the user has not access to.
|
|
50
53
|
6. With the final pod list, the backend plugin sends requests to the Kwirth instances on the clusters asking for specific API Keys for streaming metrics and/or restarting Kubernetes objects.
|
|
51
54
|
7. The backend plugin then asks for a metrics list, that is, a list of the metrics the Kubernetes cluster can offer (the ones managed by the kubelet)
|
|
@@ -93,15 +96,29 @@ If everyting is correctly configured and tagged, the user should see a list of c
|
|
|
93
96
|
)
|
|
94
97
|
```
|
|
95
98
|
|
|
96
|
-
2.
|
|
99
|
+
2. Label your catalog-info according to one of these two startegies:
|
|
100
|
+
|
|
101
|
+
- **Strategy 1: one-to-one**. Add `backstage.io/kubernetes-id` annotation to your `catalog-info.yaml` for the entities deployed to Kubernetes you want to work with on Backstage. This is the same annotation that the Kubernetes core plugin uses, so, maybe you already have added it to your components. Exmaple:
|
|
102
|
+
|
|
103
|
+
```yaml
|
|
104
|
+
metadata:
|
|
105
|
+
annotaations:
|
|
106
|
+
backstage.io/kubernetes-id: entity001
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
- **Strategy 2: use selectors**. Add `backstage.io/kubernetes-label-selector` annotation to your `catalog-info.yaml` for the entities you want to work with. This is the same annotation that the Kubernetes core plugin uses, so, maybe you already have added it to your components. The label selector value follows Kubernetes [label selector semantics](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/). Example:
|
|
97
110
|
|
|
98
111
|
```yaml
|
|
99
112
|
metadata:
|
|
100
|
-
|
|
101
|
-
backstage.io/kubernetes-id:
|
|
113
|
+
annotaations:
|
|
114
|
+
backstage.io/kubernetes-id: 'app=core,artifact=backend'
|
|
102
115
|
```
|
|
103
116
|
|
|
104
|
-
3. Add proper **labels** to your Kubernetes objects so Backstage can *link*
|
|
117
|
+
3. Add proper **labels** to your Kubernetes objects so Backstage can *link* forward and backward the Backstage entities with the Kubernetes objects. To do this, you need to add `labels` to your Kubernetes YAML objects (please, don't get confused: **annotations in Backstage YAML, labels in Kubernetes YAML**).
|
|
118
|
+
|
|
119
|
+
- ***VERY IMPORTANT NOTE:*** If you opted for using label selectors **you have nothing new to add to your pods**.
|
|
120
|
+
|
|
121
|
+
- If you use labels (no label selectors), please note that the kubernetes-id label is **on the deployment** and on the **spec pod template** also. This is an example of a typical Kubernetes deployment with the required label:
|
|
105
122
|
|
|
106
123
|
```yaml
|
|
107
124
|
apiVersion: apps/v1
|
|
@@ -127,9 +144,6 @@ If everyting is correctly configured and tagged, the user should see a list of c
|
|
|
127
144
|
...
|
|
128
145
|
```
|
|
129
146
|
|
|
130
|
-
Please note that the kubernetes-id label is **on the deployment** and on the **spec pod template** also.
|
|
131
|
-
|
|
132
|
-
|
|
133
147
|
## Ready, set, go!
|
|
134
148
|
If you performed all these steps you would see a 'KwirthMetrics' tab in your **Entity Page**, like this one:
|
|
135
149
|
|