Verkkoyhteydet
IPv4
Kaikki Rahtin verkkoyhteydet käyttävät IPv4:ää. Kaikki tässä dokumentissa ja itse Rahtin järjestelmässä käytetyt IP-osoitteet ovat vain IPv4-osoitteita, IPv6-osoitteita ei käytetä.
Nimiavaruudet
Rahti on jaettu nimiavaruuksiin. Kontekstista riippuen nimiavaruuksiin voidaan viitata myös nimellä projektit. Jokaisen Rahtissa olevan objektin on kuuluttava nimiavaruuteen ja toimittava sen sisällä.
NetworkPolicy
Verkkojen näkökulmasta nimiavaruudet on oletusarvoisesti määritetty tarjoamaan eristetty VLAN kaikelle niiden sisällä toimivalle, erityisesti Podeille ja Palveluille. Kaikki Podiin tai Palveluun kohdistuva liikenne, joka tulee nimiavaruuden ulkopuolelta (myös muista Rahtin nimiavaruuksista), estetään. Ainoa liikenne, joka pääsee nimiavaruuden ulkopuolelta läpi, on Routen kautta kulkeva liikenne. Tämä eristys toteutetaan Network Policyilla. Tätä on mahdollista muuttaa muokkaamalla kahta NetworkPolicy-objektia, jotka luodaan oletuksena Rahtissa.
Edistynyt verkkokonfiguraatio
Rahtin konsolin valikossa kohdassa Networking > NetworkPolicies on mahdollista selata ja muokata oletusverkkokäytäntöjä, mutta vain YAML-muodossa. Muuta NetworkPolicyja vain, jos olet todella varma siitä, mitä olet tekemässä.
Podit
Podit ovat Kubernetesin perusyksikkö. Ne sisältävät yhden tai useamman kontin, joissa on sovelluksen suorittamiseen tarvittavat ohjelmistot ja ympäristö. Jokaisella Podilla on yksityinen IP-osoite, joka on saavutettavissa vain nimiavaruuden/VLANin sisältä. Näitä Podien IP-osoitteita ei ole suositeltavaa käyttää suoraan sovelluksissa, vaan ne on tarkoitettu Palveluiden käyttöön. Tämä johtuu siitä, että muiden nimiavaruuksien muut Podit voivat käyttää samaa yksityistä IP-osoitetta, mutta vielä tärkeämpää on se, että Podin uudelleenluonnin yhteydessä se saa uuden IP-osoitteen.
Jos esimerkiksi otamme käyttöön nginx-imagen Podissa, tämä Pod saa satunnaisen yksityisen IP-osoitteen, kuten 10.1.1.200. Mikä tahansa imagen tarjoama ei-etuoikeutettu portti (>=1024), esimerkiksi 8081, on saavutettavissa tästä osoitteesta. Podin käynnistys epäonnistuu, jos se yrittää tarjota etuoikeutetun portin ([0-1023]). Jos Podi poistetaan käytöstä, yleensä sen konfiguraation muutoksen vuoksi, mutta mahdollisesti myös odottamattomista syistä kuten laitteistovian takia, luodaan uusi Podi eri IP-osoitteella, esimerkiksi 10.1.1.140. Nämä IP-osoitteet vastaavat liikenteeseen vain nimiavaruuden sisältä. Jos määritämme Podin, joka tekee kyselyitä ensimmäiseen IP-osoitteeseen (10.1.1.200), se lakkaa luonnollisesti toimimasta sillä hetkellä, kun siihen liittyvä Podi luodaan uudelleen. Siksi käytämme palveluita.
Palvelut
Palvelut (lyhennettynä myös svc) tarjoavat vakaan yksityisen IP-osoitteen yhdelle tai useammalle Podille. Tämä IP-osoite toimii kuormantasaajana ja jakaa liikennekuorman sen takana olevien Podien kesken. Tätä varten palvelu huolehtii siitä, että IP-osoitteiden lista pysyy ajan tasalla, jotta pyynnöt lähetetään vain kelvollisiin osoitteisiin.
Palvelut on rakennettu tarjoamaan yksi tai useampi portti, ja ne tarjoavat myös sisäisen DNS-nimen. Kaikki seuraavat nimet ovat kelvollisia ja osoittavat samaan palvelun IP-osoitteeseen:
<service_name>, esimerkiksi nginx.<service_name>.<namespace>, esimerkiksi ngin.fenic- ja
<service_name>.<namespace>.svc.cluster.local, esimerkiksi nginx.fenic.svc.cluster.local.
Samalla tavalla kuin Podit, Rahtin palvelut ovat saavutettavissa vain sen nimiavaruuden sisältä, jossa ne toimivat. Mistä tahansa toisesta nimiavaruudesta tuleva pyyntö pystyy ratkaisemaan DNS-nimen IP-osoitteeksi, mutta yhteyttä ei koskaan muodosteta. Toinen palveluiden ominaisuus on, että ne voivat välittää pyyntöjä yhdestä portista toiseen kohdeporttiin (esim. 80 porttiin 8080). Tämä on hyödyllistä Rahtissa, koska Podit eivät voi kuunnella etuoikeutettuja portteja (<1024).
Palveluita voidaan käyttää sisäisiin yhteyksiin. Jos meillä on esimerkiksi yksi tai useampi MongoDB-tietokannan replika käynnissä fenic-nimiavaruudessa, kukin eri Podissa, ja ne tarjoavat portin 27017, voimme luoda palvelun nimeltä mongo, joka on liitetty Podeihin samalla nimellä. Tämän jälkeen voimme käynnistää nginx-Podeja, joissa ajetaan Python-sovellusta ja joka käyttää URL-osoitetta <mongo:27017 yhteyden muodostamiseen tietokantaan. Kun yhteyksiä palveluun yritetään muodostaa, yksi mongo-Podeista valitaan palvelemaan datakyselyä.
Routet
Routet ovat OpenShiftin vastine tavallisen Kubernetesin Ingressille. Ne avaavat yhden yksittäisen Service-objektin yhden portin nimiavaruuden ulkopuolelta ja internetistä tulevalle liikenteelle, mutta vain HTTP/HTTPS-liikenteelle. Jos route on määritetty tarjoamaan salaamatonta HTTP-liikennettä, siihen liittyvien Podien tulee käyttää salaamatonta HTTP-liikennettä. Jos route on määritetty tarjoamaan TLS/HTTPS-suojattua liikennettä, käytettävissä on useita vaihtoehtoja Routen salauksen osalta:
- Edge, tämä on oletus ja helpoin määrittää. Route tarjoaa varmenteen, joka tallennetaan itse Route-objektiin. Liikenne puretaan salauksesta, ja Podiin otetaan yhteys selväkielisellä salaamattomalla HTTPD-liikenteellä.
- Passthrough tarkoittaa, että salaus delegoidaan Podille, jonka on kuunneltava TLS/HTTPS-liikennettä ja tarjottava varmenne, jonka asiakas vastaanottaa.
- Re-encrypt, tämä on kahden edellisen vaihtoehdon yhdistelmä. Route tarjoaa varmenteen, mutta muodostaa yhteyden Podiin TLS/HTTPS-yhteydellä ja odottaa kelvollista varmennetta palvelun verkkotunnukselle. Asiakas saa silti Routen tallentaman varmenteen. Tätä käytetään esimerkiksi silloin, kun klusterin noodien välistä sisäverkkoa ei pidetä riittävän turvallisena ja haluamme silti, että Route hallitsee asiakkaalle toimitettavia varmenteita. Joissakin harvinaisissa sovelluksissa TLS:ää ei myöskään ole mahdollista poistaa käytöstä Podeissa.
Re-encrypt
Jotta Re-encrypt toimii, sinun on toimitettava oma varmenteesi. Vaiheita on 3: (1) Sinulla on oltava varmenne-/avainpari PEM-koodatuissa tiedostoissa, joissa varmenne on kelvollinen routen host-nimelle. (2) Sinulla voi olla erillinen CA-varmenne PEM-koodatussa tiedostossa, joka täydentää varmenneketjun. (3) Sinulla on oltava erillinen kohde-CA-varmenne PEM-koodatussa tiedostossa. Jos jokin näistä vaiheista ei toteudu oikein, route ei toimi.
Route voidaan määrittää myös (1) tarjoamaan HTTP/302-uudelleenohjaus portista 80 porttiin 443. On myös mahdollista (2) tarjota sama sisältö molemmissa porteissa tai (3) olla tarjoamatta mitään suojaamattomassa 80-portissa.
Rahtin tärkeä rajoitus on, että vain HTTP/80- ja HTTPS/443-portit ovat avoinna saapuvalle liikenteelle, ja ne voivat palvella vain HTTPD-protokollan pyyntöjä. Nimiavaruuden sisällä mikä tahansa portti ja protokolla on tuettu. Tämä tarkoittaa, että voimme yhdistää sovelluksen tietokantaan ilman ongelmia, mutta emme koskaan voi avata kyseistä tietokantaa ulkoiselle liikenteelle. Tämä johtuu siitä, että sama saapuvan liikenteen virtuaalinen IP on jaettu kaiken Rahtin HAProxy-kuormantasaajiin tulevan liikenteen kesken. Nimeen perustuvia virtuaalipalvelimia käytetään liikenteen ohjaamiseen oikeaan Routeen. Muilla kuin HTTPD-protokollilla tätä ominaisuutta ei ole, ja ne tarvitsevat toimiakseen oman IP-/porttiparin.
Rahti tarjoaa joukon valmiiksi luotuja verkkotunnuksia muodossa XXXX.2.rahtiapp.fi, jossa XXXX voi olla mikä tahansa kirjainten, numeroiden ja yhdysmerkkien yhdistelmä. Näihin valmiiksi luotuihin verkkotunnuksiin kuuluu myös kelvollinen TLS-varmenne.
Jokainen valmiiksi luotu verkkotunnus on määritetty osoittamaan HAProxy-kuormantasaajiin.
Omat verkkotunnukset
Mikä tahansa olemassa oleva mahdollinen verkkotunnus voidaan periaatteessa käyttää Rahtissa, mutta asiakkaan on hallittava DNS-määritykset ja varmenteet:
-
DNS-määritystä varten sinun on määritettävä
CNAME, joka osoittaa osoitteeseenrouter-default.apps.2.rahti.csc.fi, tai jos tämä ei ole mahdollista, vaihtoehtoisesti on määritettäväA-tietue, joka sisältää osoitteenrouter-default.apps.2.rahti.csc.fiIP-osoitteen. Tapa, jolla tämä on määritettävä, riippuu DNS-tietueen rekisteristä. -
Voit käyttää mitä tahansa varmenteiden tarjoajaa, esimerkiksi Let's Encrypt controllerin tarjoamia ilmaisia varmenteita.
Toinen routeihin liittyvä ominaisuus on IP-sallintalistaus, eli vain tietyn IP-osoitejoukon salliminen routelle. Tätä hallitaan luomalla Route-objektiin annotaatio avaimella haproxy.router.openshift.io/ip_allowlist ja asettamalla arvoksi välilyönneillä erotettu lista IP-osoitteista ja/tai IP-alueista. Oletetaan, että muuttuja route_name sisältää routen nimen.
-
Tämä ensimmäinen esimerkki sallii IP-osoitealueen (
193.166.[0-255].[1-254]): -
Tämä toinen esimerkki sallii vain tietyn IP-osoitteen:
-
Ja tämä esimerkki yhdistää molemmat:
Warning
Vanha haproxy.router.openshift.io/ip_whitelist-annotaatio on vanhentunut, mutta sitä tuetaan edelleen yhteensopivuuden vuoksi.
Se poistetaan tulevassa versiossa.
Egress-IP-osoitteet
Kaiken asiakkaan lähtevän liikenteen IP-osoite on 86.50.229.150. Mikä tahansa Rahtissa toimiva Podi käyttää oletusarvoisesti tätä IP-osoitetta tavoittaakseen mitä tahansa Rahtin tai Routen ulkopuolella sijaitsevaa kohdetta. Valituille nimiavaruuksille, jotka sitä tarvitsevat, on mahdollista määrittää oma erillinen IP-osoite. Jokainen pyyntö arvioidaan erikseen, koska käytettävissä on rajallinen määrä virtuaalisia IP-osoitteita.
Egress-IP voi muuttua
Rahtin egress-IP voi muuttua tulevaisuudessa. Esimerkiksi jos useita Rahtin versioita ajetaan rinnakkain, kullakin on eri IP-osoite. Sama voi tapahtua myös, jos taustalla olevassa verkkoinfrastruktuurissa tehdään merkittävä muutos.
LoadBalancer-palvelutyypin käyttäminen erillisillä IP-osoitteilla
Toisin kuin routet, LoadBalancer-palvelutyyppi mahdollistaa palveluiden avaamisen internetiin ilman HTTP/HTTPS-rajoitusta. Tämän ominaisuuden avulla voit avata palveluita vastaanottamaan ulkoista saapuvaa liikennettä erillisessä julkisessa IP-osoitteessa, jolloin ulkoiset käyttäjät tai palvelut voivat olla vuorovaikutuksessa sovellustesi kanssa. Jotta voit ottaa LoadBalancer-palvelut käyttöön Rahti-projektissasi, sinun on lähetettävä pyyntö asiakastukeen (servicedesk@csc.fi). Pyynnön on sisällettävä seuraavat tiedot:
-
Projektin nimi: Anna sen Rahti-projektin tarkka nimi, jossa haluat ottaa LoadBalancer-palvelut käyttöön.
-
CSC-projektinumero:
csc_project-numero, jota käytetään Rahti-projektissa. -
Käyttötapaus: Kuvaa käyttötapaus selkeästi, mukaan lukien:
- niiden palveluiden tyyppi, jotka aiot avata (esim. verkkosovellukset, API:t).
- mahdolliset erityisvaatimukset tai huomioitavat asiat (esim. kuinka monta IP-osoitetta tarvitaan).
Kun ylläpitäjät ovat hyväksyneet pyyntösi, saat julkisen IP-osoitteen, jota voidaan käyttää palveluidesi käyttämiseen, ja voit sen jälkeen luoda LoadBalancer-palvelun.
Vaihtoehtoisesti voit käyttää seuraavaa komentoa tarkistaaksesi projektiisi määritetyt IP-osoitteet. Tiedot näkyvät kentässä annotations.ip_pairs.
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
annotations:
ip_pairs: |
192.168.191.X - 86.50.228.M
192.168.192.Y - 195.148.30.N
creationTimestamp: "XXXX-XX-XXTXX:XX:XXZ"
generation: 1
name: <project_name>
namespace: metallb-system
resourceVersion: "XXXXXX"
uid: XXXXXXX
spec:
addresses:
- 192.168.191.X/32
- 192.168.192.Y/32
autoAssign: true
avoidBuggyIPs: false
serviceAllocation:
namespaces:
- <project_name>
priority: 1
Esimerkiksi seuraava palvelumääritys avaa MySQL-palvelun määritetyssä julkisessa IP-osoitteessa portissa 33306.
kind: Service
apiVersion: v1
metadata:
name: mysqllb
namespace: my-namespace
spec:
ports:
- protocol: TCP
port: 33306
targetPort: 3306
allocateLoadBalancerNodePorts: false
type: LoadBalancer
selector:
app: mysql
Löydät yksityiskohtaisen selityksen Servicestä täältä
Varmista, että palvelutyypiksi on asetettu LoadBalancer ja että kentän allocateLoadBalancerNodePorts arvoksi on asetettu false (oletusarvo on true), koska NodePortit eivät ole käytössä Rahtissa. Jos tätä kenttää ei aseteta oikein, varattu node-portti on käyttökelvoton, ja palvelun luonti voi epäonnistua, jos koko oletusarvoinen node-porttialue (30000-32767) on jo varattu.
Lisäksi palvelumäärityksen porttikentän (esim. 33306 edellisessä esimerkissä) on oltava alueella 30000-35000.
Selectorin hakeminen
Komentorivillä
aja komentorivilläsi oc describe pod <pod-name> -n <namespace>. Kun olet suorittanut oc-komennon, näet tulosteen, jossa on osio nimeltä Labels. Kopioi mikä tahansa labeleista ja liitä se yaml-tiedostoon kohdan selector alle. Muista noudattaa yaml-syntaksia ja vaihtaa = merkiksi :. Esimerkiksi kohdassa Labels käytämme ensimmäistä:
Name: mysql-pod
Namespace: my-namespace
Priority: 0
Node: worker-node-1/10.0.0.1
Start Time: Mon, 23 Oct 2024 10:00:00 +0000
Labels: app=mysql
environment=production
app.kubernetes.io/name=postgresql
(...)
Selainkäyttöliittymässä
Selainkäyttöliittymässä kohdassa Workloads paina pods ja valitse sitten haluamasi podi. Näet kaikki labelit kohdassa Labels. Kopioi mikä tahansa labeleista ja liitä se yaml-tiedostoon kohdan selector alle. Muista noudattaa yaml-syntaksia ja vaihtaa = merkiksi :.

Kuinka varmistat, että palvelusi osoittaa oikeaan podiin
Komentorivillä
Aja komentorivilläsi oc get endpoints <service-name> -n <namespace>. Sinun pitäisi nähdä Servicen nimi sekä niiden Podien IP-osoitteet ja portit, joihin Service tällä hetkellä kohdistuu. Esimerkiksi:
Selainkäyttöliittymässä
Selainkäyttöliittymässä kohdassa Networking paina Services ja valitse juuri luomasi LoadBalancer-palvelu. Välilehdellä Pods sinun pitäisi nähdä kohdepodi.

Saman LoadBalancer-IP-osoitteen jakaminen palveluiden kesken
On myös mahdollista avata useita LoadBalancer-palveluita samaan julkiseen IP-osoitteeseen mutta eri portteihin. Voit ottaa IP-jaon käyttöön lisäämällä palveluihin annotaation metallb.universe.tf/allow-shared-ip. Annotation arvo on valitsemasi label. Palvelut, joihin on lisätty sama label, jakavat saman IP-osoitteen. Tässä on esimerkkimääritys kahdesta palvelusta, jotka jakavat saman IP-osoitteen:
kind: Service
apiVersion: v1
metadata:
name: mysqllb
namespace: my-namespace
annotations:
metallb.universe.tf/allow-shared-ip: "label-to-share-1.2.3.4"
spec:
ports:
- protocol: TCP
port: 33306
targetPort: 3306
allocateLoadBalancerNodePorts: false
type: LoadBalancer
selector:
app: mysql
kind: Service
apiVersion: v1
metadata:
name: httplb
namespace: my-namespace
annotations:
metallb.universe.tf/allow-shared-ip: "label-to-share-1.2.3.4"
spec:
ports:
- protocol: TCP
port: 30080
targetPort: 80
allocateLoadBalancerNodePorts: false
type: LoadBalancer
selector:
app: httpd
Palomuurin IP-estojen lisääminen LoadBalancer-palveluun
LoadBalancer-palveluun on mahdollista lisätä palomuurin IP-estoja. Tämä tarkoittaa, että voimme lisätä sallintalistan IP-osoitteista (188.184.77.250) ja/tai IP-peitteistä (188.184.0.0/16), jotka ovat ainoita, joilla on pääsy palveluun. Yhdessä turvallisten protokollien ja turvallisten salasanojen käytäntöjen kanssa tämä voi parantaa tietoturvaa merkittävästi.
Menettely tämän toteuttamiseksi on seuraava:
-
Aktivoi palvelussa
Local-ulkoinen liikennekäytäntö. Tee tämä lisäämälläexternalTrafficPolicy: Localkohdanspecalle seuraavasti:kind: Service kind: Service apiVersion: v1 apiVersion: v1 metadata: metadata: name: mysqllb name: mysqllb spec: spec: ports: ports: - protocol: TCP - protocol: TCP port: 33306 port: 33306 targetPort: 3306 targetPort: 3306 name: http name: http allocateLoadBalancerNodePorts: false allocateLoadBalancerNodePorts: false > externalTrafficPolicy: Local type: LoadBalancer type: LoadBalancer selector: selector: app: mysql app: mysqlLocal Traffic Policy Limitations
Rahti käyttää metallb:ssä
L2Advertisement-tilaa. Lisätietoja on kohdassa 'Layer 2'.Huomaa myös, että kun
externalTrafficPolicyon asetettu arvoonLocal, vain yksi palvelu voidaan avata ulkoisella IP-osoitteella; eli kuormantasaajan IP-osoitetta ei voi jakaa useiden palveluiden kesken.Lisätietoja on virallisessa artikkelissa: Understanding Openshift
externalTrafficPolicy: localand Source IP Preservation -
Lisää
NetworkPolicy, joka avaa pääsyn valituille IP-osoitteille:apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: firewall spec: ingress: - from: - ipBlock: cidr: 188.184.0.0/16 - ipBlock: cidr: 137.138.6.31/32 - from: - namespaceSelector: matchLabels: policy-group.network.openshift.io/ingress: "" podSelector: matchLabels: app: mysql policyTypes: - IngressYllä oleva
NetworkPolicy-esimerkki sallii saapuvan liikenteen CIDR-alueelta188.184.0.0/16, joka vastaa aluetta [188.184.0.0-188.184.255.255], sekä yksittäisestä IP-osoitteesta137.138.6.31. Liikenteen kohde on rajattumatchLabels-osion avulla. Labelin on oltava sama kuinLoadBalancer-palvelussa käytetty.
Routen ja LoadBalancer-palvelun erot käyttöönoton rolloutien aikana
Rahtissa Routejen ja LoadBalancer-palveluiden tapa hallita liikennettä käyttöönoton rolloutien aikana toimii eri tavalla.
OpenShiftin HAProxyyn integroidun kuormantasaajan hallinnoimat Routet on suunniteltu mukautumaan nopeasti ja ohjaamaan liikenne heti, kun uusi podi käynnistyy, sekä samanaikaisesti lopettamaan liikenteen ohjaamisen vanhoihin tai päättyviin podeihin. Tämä varmistaa nopean reagoinnin muutoksiin ja minimoi palvelukatkokset.
Sen sijaan LoadBalancer-palvelut jakavat liikennettä uusien podien lisäksi myös vanhoille tai päättyville podeille. Tämä johtuu siitä, että nämä palvelut tukeutuvat EndpointSlicejen säännöllisiin päivityksiin, mikä voi viivästyttää päättyvien podien poistamista liikenteenjaosta. Tämä ero liikenteen käsittelyssä on hyödyllinen ymmärtää, koska se vaikuttaa siihen, miten käyttöönottojen strategiat kannattaa toteuttaa sovelluspäivityksissä.
Lisätietoja on OpenShiftin dokumentaatiossa route-pohjaisista käyttöönottostrategioista. Jotta vältät häiriöt käytettäessä ulkoisia kuormantasaajapalveluita, voit hyödyntää blue-green deployment -periaatetta.