paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 42 Packages Projects Releases Wiki Activity

Point to main docs site

Browse Source
This commit is contained in:
Adam Harvey
2021-01-25 14:42:33 -05:00
parent 8abed46a1f
commit 975fe1ad38
2 changed files with 31 additions and 112 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/kubernetes-backend/README.md
+9 -73
View File
@@ -1,83 +1,19 @@
# Kubernetes Backend
WORK IN PROGRESS
This is the backend part of the Kubernetes plugin for Backstage. It is called by and responds to requests from the frontend [`@backstage/plugin-kubernetes`](https://github.com/backstage/backstage/tree/master/plugins/kubernetes) plugin.
This is the backend part of the Kubernetes plugin.
It directly interfaces with the Kubernetes API control plane to obtain information about objects that will then be presented at the front end.
It responds to Kubernetes requests from the frontend.
## Introduction
## Configuration
See our announcement blog post [New Backstage feature: Kubernetes for Service Owners](https://backstage.io/blog/2021/01/12/new-backstage-feature-kubernetes-for-service-owners) to learn more about the motivation behind developing the plugin.
### serviceLocatorMethod
## Setup & Configuration
This configures how to determine which clusters a component is running in.
This plugin must be explicitly added to a Backstage app, along with it's peer frontend plugin.
Currently, the only valid serviceLocatorMethod is:
The plugin requires configuration in the Backstage `app-config.yaml` to connect to a Kubernetes API control plane.
#### multiTenant
In addition, configuration of an entity's `catalog-info.yaml` helps identify which specific Kubernetes object(s) should be presented on a specific entity catalog page.
This configuration assumes that all components run on all the provided clusters.
### clusterLocatorMethods
This is used to determine where to retrieve cluster configuration from.
Currently, the only valid serviceLocatorMethod is:
#### config
This clusterLocatorMethod will read cluster information in from config
Example:
```yaml
kubernetes:
serviceLocatorMethod: 'multiTenant'
clusterLocatorMethods:
- 'config'
clusters:
- url: http://127.0.0.1:9999
name: minikube
serviceAccountToken: <TOKEN FROM STEP 4>
authProvider: 'serviceAccount'
- url: http://127.0.0.2:9999
name: gke-cluster-1
authProvider: 'google'
```
##### clusters
Used by the `config` `clusterLocatorMethods` to construct Kubernetes clients.
###### url
The base url to the Kubernetes control plane. Can be found by using the `Kubernetes master` result from running the `kubectl cluster-info` command.
###### name
A name to represent this cluster, this must be unique within the `clusters` array. Users will see this value in the Service Catalog Kubernetes plugin.
###### authProvider
This determines how the Kubernetes client authenticate with the Kubernetes cluster. Valid values are:
| Value | Description |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `serviceAccount` | This will use a Kubernetes [service account](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/) to access the Kubernetes API. When this is used the `serviceAccountToken` field should also be set. |
| `google` | This will use a user's google auth token from the [google auth plugin](https://backstage.io/docs/auth/) to access the Kubernetes API. |
###### serviceAccount (optional)
The service account token to be used when using the `authProvider`, `serviceAccount`.
## RBAC
The current RBAC permissions required are read-only cluster wide, for the following objects:
- pods
- services
- configmaps
- deployments
- replicasets
- horizontalpodautoscalers
- ingresses
For more information, see the [formal documentation about the Kubernetes feature in Backstage](https://backstage.io/docs/features/kubernetes/overview).
plugins/kubernetes/README.md
+22 -39
View File
@@ -1,9 +1,29 @@
# kubernetes
# Kubernetes
Welcome to the kubernetes plugin!
Welcome to the Backstage Kubernetes frontend plugin!
This plugin exposes information about your entity-specific Kubernetes objects with a desire to provide value to the service owner, rather than just a Kubernetes cluster administrator.
It will elevate the visibility of errors where identified, and provide drill down about the deployments, pods, and other objects for a service.
It directly interfaces with the [Kubernetes Backend Plugin (`@backstage-plugin-kubernetes-backend`)](https://github.com/backstage/backstage/tree/master/plugins/kubernetes-backend).
_This plugin was created through the Backstage CLI_
## Introduction
See our announcement blog post [New Backstage feature: Kubernetes for Service Owners](https://backstage.io/blog/2021/01/12/new-backstage-feature-kubernetes-for-service-owners) to learn more about the motivation behind developing the plugin.
## Setup & Configuration
This plugin must be explicitly added to a Backstage app, along with it's peer backend plugin.
It requires configuration in the Backstage `app-config.yaml` to connect to a Kubernetes API control plane.
In addition, configuration of an entity's `catalog-info.yaml` helps identify which specific Kubernetes object(s) should be presented on a specific entity catalog page.
For more information, see the [formal documentation about the Kubernetes feature in Backstage](https://backstage.io/docs/features/kubernetes/overview).
## Getting started
Your plugin has been added to the example app in this repository, meaning you'll be able to access it by running `yarn start` in the root directory, and then navigating to [/kubernetes](http://localhost:3000/kubernetes).
@@ -11,40 +31,3 @@ Your plugin has been added to the example app in this repository, meaning you'll
You can also serve the plugin in isolation by running `yarn start` in the plugin directory.
This method of serving the plugin provides quicker iteration speed and a faster startup and hot reloads.
It is only meant for local development, and the setup for it can be found inside the [/dev](./dev) directory.
## Surfacing your Kubernetes components as part of an entity
There are two ways to surface your kubernetes components as part of an entity.
The label selector takes precedence over the annotation/service id.
### Common `backstage.io/kubernetes-id` label
#### Adding the entity annotation
In order for Backstage to detect that an entity has Kubernetes components,
the following annotation should be added to the entity.
```yaml
annotations:
'backstage.io/kubernetes-id': dice-roller
```
#### Labeling Kubernetes components
In order for Kubernetes components to show up in the service catalog
as a part of an entity, Kubernetes components must be labeled with the following label:
```yaml
'backstage.io/kubernetes-id': <ENTITY_NAME>
```
### label selector query annotation
#### Adding a label selector query annotation
You can write your own custom label selector query that backstage will use to lookup the objects (similar to `kubectl --selector="your query here"`)
review the documentation [here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) for more info
```yaml
'backstage.io/kubernetes-label-selector': 'app=my-app,component=front-end'
```