Sveiki visiem! Pirms dažiem mēnešiem mēs uzsākām mūsu jauno atvērtā koda projektu ražošanā - Grafana spraudni kubernetes uzraudzībai, ko nosaucām . Spraudņa pirmkods ir pieejams vietnē . Un šajā rakstā mēs vēlamies dalīties ar jums stāstā par to, kā mēs izveidojām spraudni, kādus rīkus izmantojām un ar kādām nepilnībām mēs saskārāmies izstrādes procesā. Ejam!
0. daļa — ievads: kā mēs nonācām līdz šim punktam?
Ideja uzrakstīt savu Grafan spraudni mums radās pavisam nejauši. Mūsu uzņēmums jau vairāk nekā 10 gadus uzrauga dažādas sarežģītības pakāpes tīmekļa projektus. Šajā laikā esam uzkrājuši lielu pieredzi, interesantus gadījumus un pieredzi dažādu uzraudzības sistēmu izmantošanā. Un kādā brīdī mēs sev jautājām: "Vai ir kāds maģisks rīks Kubernetes uzraudzībai, lai, kā saka, "noteiktu un aizmirstu"?".. Nozares standarts k8s uzraudzībai, protams, jau sen ir bijis Prometejs + Grafana kombinācija. Un kā gatavi risinājumi šai kaudzei ir liels dažādu veidu rīku komplekts: prometheus-operator, kubernetes-mixin informācijas paneļu komplekts, grafana-kubernetes-app.
Spraudnis grafana-kubernetes-app mums šķita visinteresantākais variants, taču tas netiek atbalstīts vairāk nekā gadu un turklāt nevar darboties ar jaunajām node-exporter un kube-state-metrics versijām. Un kādā brīdī mēs nolēmām: "Vai mums nevajadzētu pieņemt savu lēmumu?"
Kādas idejas mēs nolēmām ieviest savā spraudnī:
- “Aplikāciju kartes” vizualizācija: ērta lietojumprogrammu prezentācija klasterī, sagrupētas pēc nosaukumvietām, izvietošanas...;
- savienojumu vizualizācija, piemēram, "izvietošana - pakalpojums (+porti)".
- klasteru lietojumprogrammu sadalījuma vizualizācija klasteru mezglos.
- metrikas un informācijas kolekcija no vairākiem avotiem: Prometheus un k8s api serveri.
- gan infrastruktūras daļas (CPU laika, atmiņas, diska apakšsistēmas, tīkla izmantošana), gan lietojumprogrammu loģikas uzraudzība - veselības stāvokļa podi, pieejamo repliku skaits, informācija par dzīvīguma/gatavības testu nokārtošanu.
1. daļa. Kas ir “Grafana spraudnis”?
No tehniskā viedokļa Grafana spraudnis ir leņķiskais kontrolleris, kas tiek glabāts Grafana datu direktorijā (/var/grafana/plugins/ /dist/module.js) un to var ielādēt kā SystemJS moduli. Arī šajā direktorijā ir jābūt failam plugin.json, kurā ir visa metainformācija par jūsu spraudni: nosaukums, versija, spraudņa veids, saites uz repozitoriju/vietni/licenci, atkarības utt.
modulis.ts
plugin.json
Kā redzat ekrānuzņēmumā, mēs norādījām plugin.type = app. Tā kā Grafana spraudņi var būt trīs veidu:
panelis: visizplatītākais spraudņa veids - tas ir panelis jebkuras metrikas vizualizācijai, ko izmanto dažādu informācijas paneļu izveidošanai.
datu avots: spraudņa savienotājs kādam datu avotam (piemēram, Prometheus-datasource, ClickHouse-datasource, ElasticSearch-datasource).
app: spraudnis, kas ļauj Grafana izveidot savu priekšgala lietojumprogrammu, izveidot savas html lapas un manuāli piekļūt datu avotam, lai vizualizētu dažādus datus. Kā atkarības var izmantot arī cita veida spraudņus (datu avots, panelis) un dažādus informācijas paneļus.
Spraudņa atkarību piemēri ar type=app.
Kā programmēšanas valodu varat izmantot gan JavaScript, gan TypeScript (mēs to izvēlējāmies). Sagatavošanās jebkura veida hello-world spraudņiem : šajā krātuvē ir liels skaits sākuma pakotņu (react ir pat eksperimentāls spraudņa piemērs) ar iepriekš instalētiem un konfigurētiem veidotājiem.
2. daļa: vietējās vides sagatavošana
Lai strādātu ar spraudni, mums, protams, ir nepieciešams kubernetes klasteris ar visiem iepriekš instalētajiem rīkiem: prometheus, node-exporter, kube-state-metrics, grafana. Vide ir jāiestata ātri, vienkārši un dabiski, un, lai nodrošinātu atkārtotu ielādi, Grafana datu direktorijs ir jāmontē tieši no izstrādātāja iekārtas.
Ērtākais veids, mūsuprāt, lokāli strādāt ar kubernetes ir . Nākamais solis ir Prometheus + Grafana kombinācijas instalēšana, izmantojot prometheus-operatoru. IN Prometheus-operatora instalēšanas process minikube ir detalizēti aprakstīts. Lai iespējotu noturību, ir jāiestata parametrs noturība: taisnība failā charts/grafana/values.yaml pievienojiet savu PV un PVC un norādiet tos parametrā persistence.existingClaim
Mūsu pēdējais minikube palaišanas skripts izskatās šādi:
minikube start --kubernetes-version=v1.13.4 --memory=4096 --bootstrapper=kubeadm --extra-config=scheduler.address=0.0.0.0 --extra-config=controller-manager.address=0.0.0.0
minikube mount
/home/sergeisporyshev/Projects/Grafana:/var/grafana --gid=472 --uid=472 --9p-version=9p2000.L3. daļa: faktiskā attīstība
Objekta modelis
Gatavojoties spraudņa ieviešanai, mēs nolēmām aprakstīt visas galvenās Kubernetes entītijas, ar kurām strādāsim TypeScript klašu veidā: pod, deployment, daemonset, statefulset, job, cronjob, service, node, namespace. Katra no šīm klasēm ir mantota no kopējās BaseModel klases, kas apraksta konstruktoru, destruktoru, redzamības atjaunināšanas un pārslēgšanas metodes. Katra no klasēm apraksta ligzdotas attiecības ar citām entītijām, piemēram, izvietošanas veida entītijas bloku sarakstu.
import {Pod} from "./pod";
import {Service} from "./service";
import {BaseModel} from './traits/baseModel';
export class Deployment extends BaseModel{
pods: Array<Pod>;
services: Array<Service>;
constructor(data: any){
super(data);
this.pods = [];
this.services = [];
}
}Ar ieguvēju un iestatītāju palīdzību mēs varam parādīt vai iestatīt mums nepieciešamo entītiju metriku ērtā un lasāmā formā. Piemēram, piešķiramo CPU mezglu formatēta izvade:
get cpuAllocatableFormatted(){
let cpu = this.data.status.allocatable.cpu;
if(cpu.indexOf('m') > -1){
cpu = parseInt(cpu)/1000;
}
return cpu;
}lapas
Visu mūsu spraudņu lapu saraksts sākotnēji ir aprakstīts failā pluing.json atkarību sadaļā:
Katras lapas blokā jānorāda LAPAS NOSAUKUMS (pēc tam tas tiks pārveidots par sliņķi, ar kuru šī lapa būs pieejama); par šīs lapas darbību atbildīgās komponentes nosaukums (komponentu saraksts tiek eksportēts uz module.ts); norādot lietotāja lomu, kurai ir pieejams darbs ar šo lapu, un sānjoslas navigācijas iestatījumus.
Komponentā, kas atbild par lapas darbību, mums jāiestata templateUrl, nododot tur ceļu uz html failu ar marķējumu. Kontrollerī, izmantojot atkarības injekciju, mēs varam piekļūt līdz 2 svarīgiem leņķa pakalpojumiem:
- backendSrv - pakalpojums, kas nodrošina mijiedarbību ar Grafana API serveri;
- datasourceSrv — pakalpojums, kas nodrošina lokālu mijiedarbību ar visiem jūsu Grafana instalētajiem datu avotiem (piemēram, metode .getAll() — atgriež visu instalēto datu avotu sarakstu; .get( ) - atgriež konkrēta datu avota instances objektu.
4. daļa: datu avots
No Grafana viedokļa datu avots ir tieši tāds pats spraudnis kā visi pārējie: tam ir savs ieejas punkts module.js, ir fails ar metainformāciju plugin.json. Izstrādājot spraudni ar type = app, mēs varam mijiedarboties gan ar esošajiem datu avotiem (piemēram, prometheus-datasource), gan ar saviem, kurus varam glabāt tieši spraudņa direktorijā (dist/datasource/*) vai instalēt kā atkarību. Mūsu gadījumā datu avotam ir pievienots spraudņa kods. Ir nepieciešama arī veidne config.html un kontrolieris ConfigCtrl, kas tiks izmantots datu avota instances konfigurācijas lapai, un datu avota kontrolleris, kas īsteno jūsu datu avota loģiku.
KubeGraf spraudnī no lietotāja interfeisa viedokļa datu avots ir kubernetes klastera gadījums, kas ievieš šādas iespējas (ir pieejams avota kods ):
- datu apkopošana no k8s api-servera (nosaukumvietu saraksta iegūšana, izvietošana...)
- starpniekservera pieprasījumi uz prometheus-datasource (kas tiek atlasīti katra konkrētā klastera spraudņa iestatījumos) un atbilžu formatēšana, lai izmantotu datus gan statiskās lapās, gan informācijas paneļos.
- datu atjaunināšana statisko spraudņu lapās (ar iestatītu atsvaidzes intensitāti).
- vaicājumu apstrāde, lai ģenerētu veidnes lapu grafana informācijas paneļos (metode metriFindQuery())
- savienojuma pārbaude ar galīgo k8s klasteru.
testDatasource(){
let url = '/api/v1/namespaces';
let _url = this.url;
if(this.accessViaToken)
_url += '/__proxy';
_url += url;
return this.backendSrv.datasourceRequest({
url: _url,
method: "GET",
headers: {"Content-Type": 'application/json'}
})
.then(response => {
if (response.status === 200) {
return {status: "success", message: "Data source is OK", title: "Success"};
}else{
return {status: "error", message: "Data source is not OK", title: "Error"};
}
}, error => {
return {status: "error", message: "Data source is not OK", title: "Error"};
})
}Atsevišķs interesants punkts, mūsuprāt, ir datu avota autentifikācijas un autorizācijas mehānisma ieviešana. Parasti mēs varam izmantot iebūvēto Grafana komponentu datasourceHttpSettings, lai konfigurētu piekļuvi gala datu avotam. Izmantojot šo komponentu, mēs varam konfigurēt piekļuvi http datu avotam, norādot URL un pamata autentifikācijas/autorizācijas iestatījumus: login-password vai client-cert/client-key. Lai ieviestu iespēju konfigurēt piekļuvi, izmantojot nesēja marķieri (de facto standarts k8s), mums bija jāveic neliela pielāgošana.
Lai atrisinātu šo problēmu, varat izmantot iebūvēto Grafana “Plugin Routes” mehānismu (sīkāka informācija ). Mūsu datu avota iestatījumos mēs varam deklarēt maršrutēšanas noteikumu kopu, ko apstrādās grafana starpniekserveris. Piemēram, katram atsevišķam galapunktam ir iespējams iestatīt galvenes vai urls ar veidņu iespēju, par kuriem datus var ņemt no laukiem jsonData un secureJsonData (paroļu vai marķieru glabāšanai šifrētā veidā). Mūsu piemērā tādi vaicājumi kā /__proxy/api/v1/namespaces tiks nosūtīts uz veidlapas URL
/api/v8/namespaces ar autorizācijas: nesēja galveni.
Protams, lai strādātu ar k8s api serveri, mums ir nepieciešams lietotājs ar tikai lasīšanas piekļuvi, kuru izveidei varat atrast arī .
5. daļa: atbrīvošana
Kad esat uzrakstījis savu Grafana spraudni, jūs, protams, vēlēsities to padarīt publiski pieejamu. Programmā Grafana šī ir šeit pieejamo spraudņu bibliotēka
Lai jūsu spraudnis būtu pieejams oficiālajā veikalā, jums ir jāveic PR pievienojot failu repo.json šādu saturu:
kur versija ir jūsu spraudņa versija, url ir saite uz krātuvi, un commit ir apstiprinājuma jaucējvārds, kuram būs pieejama konkrēta spraudņa versija.
Un izejā jūs redzēsit brīnišķīgu attēlu, piemēram:
Tam nepieciešamie dati tiks automātiski iegūti no jūsu Readme.md, Changelog.md un faila plugin.json ar spraudņa aprakstu.
6. daļa: secinājumu vietā
Mēs nepārstājām izstrādāt mūsu spraudni pēc izlaišanas. Un tagad mēs strādājam pie tā, lai pareizi uzraudzītu klasteru mezglu resursu izmantošanu, ieviestu jaunas funkcijas UX uzlabošanai, kā arī apkopotu lielu daudzumu atsauksmju, kas saņemtas pēc spraudņa instalēšanas gan no mūsu klientiem, gan no GitHub lietotājiem (ja pametīsiet Jūsu problēma vai izvilkšanas pieprasījums, es būšu ļoti priecīgs :)
Mēs ceram, ka šis raksts palīdzēs jums izprast tik brīnišķīgu rīku kā Grafana un, iespējams, uzrakstīt savu spraudni.
Paldies!)
Avots: www.habr.com
