Tööpõhimõte: erinevus redaktsioonide vahel

Allikas: Imre kasutab arvutit
Mine navigeerimisribaleMine otsikasti
Resümee puudub
 
(ei näidata sama kasutaja 11 vahepealset redaktsiooni)
12. rida: 12. rida:
   
 
* rnr sõne node nimes tähistab, et tegu on Rancher rakendust teenindavate node'idega
 
* 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 clusteriga (kus töötavad lõppkasutajat teenindavad teenused)
+
* 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)
 
* 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
 
* 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
+
* 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
===Võrguskeem===
 
   
  +
* fleet tarkvara abil kontrollitakse samaaegselt mitut k8s klastrit - moodustatakse k8s klastritest koosnev klaster
<pre>
 
  +
* fleet tarkvara kasutamise eelduseks on gitlab repo - seal hoitakse fleet töötamist juhtivaid ja kontrollivad nö yaml faile
asukoht - Tartu/ISP-A
 
  +
* 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)
 
k3s-rnr-tartu-node-1 k3s-rnr-tartu-node-2 k3s-rnr-tartu-node-3 k8s-ds-tartu-node-1 k8s-ds-tartu-node-2 k8s-ds-tartu-node-3
 
   
  +
* dns nimelahenduse server
https://rnr-mgmt-tartu.auul.pri.ee/ https://ds-teenus.auul.pri.ee/
 
  +
* ntp server
___________ ___________ ___________ ___________ ___________ ___________
 
  +
* dhcp server - antud juhul dhcp serverit ei kasutata node'ide ip aadresside jaoks, st eelistatakse staatilist seadistust
| | | | | | | | | | | |
 
| vmid 5011 | | vmid 5012 | | vmid 5013 | | vmid 5021 | | vmid 5022 | | vmid 5023 |
 
| .50.11 | | .50.12 | | .50.13 | | .50.21 | | .50.22 | | .50.23 |
 
|___________| |___________| |___________| |___________| |___________| |___________|
 
| | | | | |
 
vlan 50 | 192.168.50.0/24 | | | | |
 
-------------|-----|------------------|------------------------|------------------------------|-----------------------|-----------------------|----------
 
|
 
| <--- 0.235.106.x:443 (tartu rancher)
 
___|___ _______
 
| | vlan10 - 192.168.10.186 | |
 
ruuter | |-------------------|------------------------| |----- internet <--- 0.235.106.n:443 (ds teenus tartu)
 
|_______| | |_______| <--- 0.235.106.m:443 (ds teenus tallinn)
 
| ___|___
 
| | | labori tulemüür
 
| | |
 
| |_______|
 
|
 
| töökohaarvuti (kubectl jms)
 
|
 
vlan 60 | 192.168.60.0/24
 
-----------|-----|-------------------|-------------------------|-------------
 
| | |
 
| | |
 
_____|_____ _____|_____ _____|_____
 
| | | | | |
 
| vmid 5041 | | vmid 5042 | | vmid 5043 |
 
| .60.41 | | .60.42 | | .60.43 |
 
|___________| |___________| |___________|
 
 
https://ds-teenus.auul.pri.ee/
 
 
k8s-ds-tallinn-node-1 k8s-ds-tallinn-node-2 k8s-ds-tallinn-node-3
 
 
 
 
asukoht - Tallinn/ISP-B
 
</pre>
 

Viimane redaktsioon: 19. aprill 2023, kell 23:15

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