Tööpõhimõte

Allikas: Imre kasutab arvutit
Mine navigeerimisribaleMine otsikasti

Sissejuhatus

Multisite kubernetes lahendus koosneb mitmest kubernetes klastrist

  • kogu komplekti peale kasutatakse ühte rancher rakendust (ja seda teenindavat k8s klastrit)
  • erinevates asukohtades töötavad iseseisvad kubernetes klastrid
  • kõik kubernetes klastrid on ühe rancher rakenduse kontrolli all
  • kõik asukohad on võrgunduse tasemel iseseisvad ja andmevahetuse toimub üle tavaliste ruutingute ja selle peal töötavate tls võrguühenduste (st ei moodustata L2 kihis vpn ühendusi vms)
  • iga asukohaga on seostatud oma avalikud ip aadressid, mingit hulka neist kasutatakse ingresside juures ja sinna juhatatakse lõppkasutajad (tõenäoliselt dns abil)

Käesolev labor matkib kahe asukoha Tartu ja Tallinn pidamist kusjuures Rancher rakendus ja teda teenindav klaster asub Tartu asukohas lisaks.

  • rnr sõne node nimes tähistab, et tegu on Rancher rakendust teenindavate node'idega
  • ds sõne node nimes tähistab, et tegu on downstream ehk user klastriga (kus töötavad lõppkasutajat teenindavad teenused)
  • kõik labori node'id on kõigi rollidega (st kubernetes workerid ja masterid samaaegselt)
  • reaalselt on paigutatud labori tingimustes kõik arvutid proxmox virtualiseerimise platvormile virtuaalsete arvutitena
  • virtuaalselt tekitatud võrgutopoloogia koosneb kahest subnetist 192.168.50.0/24 ja 192.168.60.0/24, nende vahele on paigutatud nö iptables-ruuter
  • k8s klaster vajab mingit sorti andmesalvestust: 1. nö tavaline lokaalne node failisüsteem; 2. node'ide peale moodustatud Longhorn storage lahendus
  • lahenduse tekitamisel on oluline enne läbi mõelda ip aadresside kasutus ja võrgutopoloogia ning asjade nimetamine (nt dns nimede kasutus)

K8s klastritest koosnev klaster

  • fleet tarkvara abil kontrollitakse samaaegselt mitut k8s klastrit - moodustatakse k8s klastritest koosnev klaster
  • fleet tarkvara kasutamise eelduseks on gitlab repo - seal hoitakse fleet töötamist juhtivaid ja kontrollivad nö yaml faile
  • harbor registry ei ole tingimata vajalik, aga tõenäoliselt on abiks k8s lahenduse pidamiseks omada nö isiklikku docker tõmmiste registry't

Üldised tugiteenused (kõneks on node'ide endi teenindamine, st mitte k8s klaster sisemiste vajaduste teenindamine st k8s sisemiselt haldab ise oma nimesid jms)

  • dns nimelahenduse server
  • ntp server
  • dhcp server - antud juhul dhcp serverit ei kasutata node'ide ip aadresside jaoks, st eelistatakse staatilist seadistust