Prism provides API Extensions to the core KubeVela. It works as a Kubernetes Aggregated API Server.
Add the chart repository
helm repo add prism https://charts.kubevela.net/prism
helm repo updateInstall helm chart
helm install vela-prism prism/vela-prism -n vela-systemClone this repo and run helm install vela-prism charts/ --namespace vela-system.
The vela-prism is an apiserver which leverages the Kubernetes Aggregated API capability to provide native interface for users.
The original ResourceTracker in KubeVela is one kind of cluster-scoped resource (for some history reasons), which makes it hard for cluster administrator to assign privilege. The ApplicationResourceTracker is a kind of namespace-scoped resource, which works as a delegator to the original ResourceTracker. It does not need extra storages but can project requests to ApplicationResourceTracker to underlying ResourceTrackers. Therefore, it is possible for cluster administrator to assign ApplicationResourceTracker permissions to users.
After installing vela-prism in your cluster, you can run kubectl get apprt to view ResourceTrackers.
In vela-prism, Cluster API is also introduced which works as a delegator to the ClusterGateway object. The original ClusterGateway object contains the credential information. This makes the exposure of ClusterGateway access can be dangerous. The Cluster object provided in prism, on the other hand, only expose metadata of clusters to accessor. Therefore, the credential information will be secured and the user can also use the API to access the cluster list.
After installing vela-prism in your cluster, you can run kubectl get vela-clusters to view all the installed clusters.
Notice that the vela-prism bootstrap parameter contains
--storage-namespace, which identifies the underlying namespace for storing cluster secrets and the OCM managed cluster.
In vela-prism, you can store grafana access into Grafana object. The Grafana object is projected into secrets in o11y-system (this can be configured through --observability-namespace parameter).
The secret embeds the access endpoint and credential (either username/password for BasicAuth or token for BearerToken) for grafana. These will be used for communicating with Grafana APIs. Example of Grafana object is shown below.
apiVersion: o11y.prism.oam.dev/v1alpha1
kind: Grafana
metadata:
name: example
spec:
access:
username: admin
password: kubevela
endpoint: https://grafana.o11y-system:3000/After creating the Grafana object into the control plane, you are now able to manipulate Grafana resources through Kubernetes APIs now. Currently, vela-prism provides proxies for GrafanaDatasource and GrafanaDashboard. Their names are constructed by two parts, its original name and the backend grafana name.
For example, you can create a new GrafanaDashboard by applying the following YAML file. This will use the Grafana object above as the access credential, and call the Grafana APIs to create a new dashboard.
You can also update or delete dashboards or datasources. The spec part of GrafanaDashboard and GrafanaDatasource are directly projected into API request body.
apiVersion: o11y.prism.oam.dev/v1alpha1
kind: GrafanaDashboard
metadata:
name: dashboard-test@example
spec:
title: New dashboard
tags: []
style: dark
timezone: browser
editable: true
hideControls: false
graphTooltip: 1
panels: []
time:
from: now-6h
to: now
timepicker:
time_options: []
refresh_intervals: []
templating:
list: []
annotations:
list: []
refresh: 5s
schemaVersion: 17
version: 0
links: []Another example for GrafanaDatasource.
apiVersion: o11y.prism.oam.dev/v1alpha1
kind: GrafanaDatasource
metadata:
name: prom-test@example
spec:
access: proxy
basicAuth: false
isDefault: false
name: ExamplePrometheus
readOnly: true
type: prometheus
url: https://prometheus-server.o11y-system:9090To operate Grafana instances in Kubernetes, there are also Grafana operators to help manage Grafana configurations.
Compared to operator pattern, the aggregator pattern has pros and cons.
- There is no data consistency problem between the CustomResource and the Grafana underlying storage.
- API requests are made in time. The response is also immediate. No need for checking CustomResource status repeatedly.
- No reconciles. No need to hold CPUs and memories as controller does.
- Easy to connect with third-party Grafana instance. For example, Grafana from cloud providers.
- Cannot persist data outside Grafana storage. Once grafana is broken, the CustomResource will be unavailable as well.
The main drawback for vela-prism compared to operator pattern is that it cannot persist configurations. However, this can be solved through using KubeVela application to manage those configurations. For example, you can write KubeVela applications to hold the dashboard configurations, instead of create another separate CustomResource. With KubeVela application, leverage GitOps is also possible.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent