@jfvilas/plugin-kwirth-log 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 -6
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -28,7 +28,9 @@ Let's explain this by following a user working sequence:
|
|
|
28
28
|
1. A Backstage user searchs for an entity in the Backstage.
|
|
29
29
|
2. In the entity page there will be a new tab named 'KWIRTHLOG'.
|
|
30
30
|
3. When the user clicks on KWIRTHLOG the frontend plugin sends a request to the backend Kiwrth plugin asking for logging information on all Kubernetes clusters available.
|
|
31
|
-
4.
|
|
31
|
+
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:
|
|
32
|
+
- 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 added to Backstage. 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.
|
|
33
|
+
- 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 added to Backstage. 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.
|
|
32
34
|
5. The Kwirth backend plugin checks then the permissions of the connected user and prunes the pods list removing the ones that the user has not access to.
|
|
33
35
|
6. With the final pod list, the backend plugin sends requests to the Kwirth instances on the clusters asking for API Keys specific for streaming pod logs.
|
|
34
36
|
7. With all this information, the backend builds a unique response containing all the pods the user have access to, and all the API keys needed to access those logs.
|
|
@@ -43,6 +45,7 @@ Following table shows version compatibility between this Kwirth Backstage plugin
|
|
|
43
45
|
|-|-|
|
|
44
46
|
|0.11.3|0.3.160|
|
|
45
47
|
|0.12.5|0.4.20|
|
|
48
|
+
|0.12.8|0.4.45|
|
|
46
49
|
|
|
47
50
|
|
|
48
51
|
## Installation
|
|
@@ -87,15 +90,30 @@ For Kwirth plugin to be usable on the frontend, you must tailor your Entity Page
|
|
|
87
90
|
)
|
|
88
91
|
```
|
|
89
92
|
|
|
90
|
-
2.
|
|
93
|
+
2. Label your catalog-info according to one of these two startegies:
|
|
94
|
+
|
|
95
|
+
- **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:
|
|
91
96
|
|
|
92
97
|
```yaml
|
|
93
98
|
metadata:
|
|
94
99
|
annotaations:
|
|
95
|
-
backstage.io/kubernetes-id:
|
|
100
|
+
backstage.io/kubernetes-id: entity001
|
|
96
101
|
```
|
|
97
102
|
|
|
98
|
-
|
|
103
|
+
- **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:
|
|
104
|
+
|
|
105
|
+
```yaml
|
|
106
|
+
metadata:
|
|
107
|
+
annotaations:
|
|
108
|
+
backstage.io/kubernetes-id: 'app=core,artifact=backend'
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
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**).
|
|
112
|
+
|
|
113
|
+
- ***VERY IMPORTANT NOTE:*** If you opted for using label selectors **you have nothing new to add to your pods**.
|
|
114
|
+
|
|
115
|
+
- 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:
|
|
116
|
+
|
|
99
117
|
|
|
100
118
|
```yaml
|
|
101
119
|
apiVersion: apps/v1
|
|
@@ -121,8 +139,6 @@ For Kwirth plugin to be usable on the frontend, you must tailor your Entity Page
|
|
|
121
139
|
...
|
|
122
140
|
```
|
|
123
141
|
|
|
124
|
-
Please note that the kubernetes-id label is **on the deployment** and on the **spec pod template** also.
|
|
125
|
-
|
|
126
142
|
## Ready, set, go!
|
|
127
143
|
If you followed all these steps and our work is well done (not sure on this), you would see a 'KwirthLog' tab in your **Entity Page**, like this one:
|
|
128
144
|
|