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. Asiayhteydestä 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 namespace:n ulkopuolelta Podiin tai Palveluun tuleva liikenne (myös muista Rahtin nimiavaruuksista) estetään. Ainoa liikenne, joka pääsee namespace:n 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 suositella käytettäväksi suoraan sovelluksissa, vaan ne on tarkoitettu Palveluiden käyttöön. Tämä johtuu siitä, että paitsi muiden nimiavaruuksien Podit voivat käyttää samaa yksityistä IP-osoitetta, myös siitä, 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ää avata etuoikeutetun portin ([0-1023]). Jos Pod tuhoutuu, tavallisesti sen konfiguraation muutoksen vuoksi, mutta mahdollisesti myös odottamattomista syistä kuten laitteistovian takia, luodaan uusi Pod eri IP-osoitteella, esimerkiksi 10.1.1.140. Nämä IP-osoitteet vastaavat liikenteeseen vain nimiavaruuden sisältä. Jos määritämme Podin, joka kyselyi ensimmäistä IP-osoitetta (10.1.1.200), se lakkaa luonnollisesti toimimasta sillä hetkellä, kun siihen liittyvä Pod 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 pitää ajan tasalla olevaa listaa IP-osoitteista, jotta pyynnöt lähetetään vain kelvollisiin osoitteisiin.
Palvelut on rakennettu julkaisemaan yksi tai useampi portti, ja ne tarjoavat myös sisäisen DNS-nimen. Mikä tahansa näistä nimistä on kelvollinen ja osoittaa 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 tavoin kuin Podit, Rahtin palvelut ovat saavutettavissa vain sen nimiavaruuden sisältä, jossa ne toimivat. Mistä tahansa toisesta nimiavaruudesta tuleva pyyntö pystyy selvittämään 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-tietokantareplika käynnissä fenic-nimiavaruudessa, kukin eri Podissa, ja ne julkaisevat 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 jotka käyttävät URL-osoitetta <mongo:27017 yhteyden muodostamiseen tietokantaan. Kun palveluun yritetään muodostaa yhteys, yksi mongo-Podeista valitaan palvelemaan datakyselyä.
Routet
Routet ovat OpenShiftin vastine tavallisen Kubernetesin Ingressille. Ne julkaisevat 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 suhteen:
- 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 solmujen välistä sisäverkkoa ei pidetä riittävän turvallisena ja haluamme silti, että Route hallitsee asiakkaalle annettavia varmenteita. Joissakin harvinaisissa sovelluksissa TLS:ää ei myöskään ole mahdollista poistaa käytöstä Podeissa.
Re-encrypt
Jotta Re-encrypt toimisi, sinun on toimitettava oma varmenne. Vaiheita on 3: (1) Sinulla on oltava varmenne-/avainpari PEM-koodatuissa tiedostoissa, joissa varmenne on kelvollinen route-hostille. (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 jotakin näistä vaiheista ei tehdä oikein, route ei toimi.
Route voidaan myös määrittää (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 julkaistaan saapuvalle liikenteelle, ja ne voivat palvella vain HTTPD-protokollan pyyntöjä. Nimiavaruuden sisällä mikä tahansa portti ja protokolla on tuettu, mikä tarkoittaa, että voimme yhdistää sovelluksen tietokantaan ilman ongelmia, mutta emme koskaan voi julkaista kyseistä tietokantaa ulkoiselle liikenteelle. Tämä johtuu siitä, että sama saapuvan liikenteen virtuaalinen IP on jaettu kaiken Rahtiin tulevan liikenteen kesken HAProxy-kuormantasaajissa. Liikenne ohjataan oikeaan Routeen nimipohjaisten virtuaali-isäntien avulla. 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 väliviivojen yhdistelmä. Näihin valmiiksi luotuihin verkkotunnuksiin sisältyy myös kelvollinen TLS-varmenne.
Jokainen valmiiksi luotu verkkotunnus on määritetty osoittamaan HAProxy-kuormantasaajiin.
Omat verkkotunnukset
Mikä tahansa olemassa oleva 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 routeen pääsyyn. 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-alueen (
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 ulospäin suuntautuvan liikenteen IP-osoite on 86.50.229.150. Mikä tahansa Rahtissa toimiva Pod käyttää oletusarvoisesti tätä IP-osoitetta tavoittaakseen kaiken, mikä sijaitsee Rahtin tai Routen ulkopuolella. Valituille nimiavaruuksille, jotka sitä tarvitsevat, on mahdollista määrittää oma erillinen IP-osoite. Jokainen pyyntö arvioidaan erikseen, koska käytettävissä on rajallinen joukko 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. Tai jos taustalla olevassa verkkoinfrastruktuurissa tapahtuu merkittävä muutos.
LoadBalancer-palvelutyypin käyttö erillisillä IP-osoitteilla
Toisin kuin routet, LoadBalancer-palvelutyyppi mahdollistaa palveluiden julkaisemisen internetiin ilman HTTP/HTTPS-rajoitusta. Tämän ominaisuuden avulla voit julkaista 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 käyttöön ja käyttää LoadBalancer-palveluita Rahti-projektissasi, sinun on lähetettävä pyyntö palvelupisteeseen (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-projektille. -
Käyttötapaus: Kuvaa käyttötapaus selkeästi, mukaan lukien:
- niiden palveluiden tyyppi, jotka aiot julkaista (esim. verkkosovellukset, API:t).
- mahdolliset erityisvaatimukset tai huomioitavat asiat. (esim. kuinka monta IP-osoitetta)
Kun ylläpitäjät hyväksyvät 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 julkaisee 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ä palvelun tyypiksi 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 oletus-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ä
Suorita komentorivilläsi oc describe pod <pod-name> -n <namespace>. Kun olet suorittanut oc-komennon, näet tulosteen, jossa on Labels-niminen osio. 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ä
Suorita 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 julkaista useita LoadBalancer-palveluita samassa julkisessa IP-osoitteessa mutta eri porteissa. 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 NetworkPolicylla
LoadBalancer-palveluun on mahdollista lisätä palomuurin IP-estoja. Tämän avulla voit määrittää sallintalistan tietyistä IP-osoitteista (esimerkiksi 188.184.77.250) ja/tai IP-alueista (esimerkiksi 188.184.0.0/16). Vain näistä sallituista osoitteista tuleva liikenne pääsee palveluun.
Vinkki
Pelkkä IP-palomuuraus ei riitä suojaamaan LoadBalancer-palvelun takana toimivaa sovellusta. Noudata aina tietoturvan parhaita käytäntöjä ja käytä IP-suodatusta osana kerroksellista tietoturvaa. Yhdistä siihen turvalliset tiedonsiirtoprotokollat, kuten TLS, sekä vahvat tunnistautumismekanismit, mukaan lukien turvalliset salasanakäytännöt, jotta sovelluksesi ovat asianmukaisesti suojattuja.
Tämän toteuttamiseksi menettely on seuraava:
-
Aktivoi palvelussa
Local-ulkoinen liikennekäytäntö. Tee tämä lisäämälläexternalTrafficPolicy: Localkohtaanspecseuraavasti: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 julkaista ulkoisella IP-osoitteella; eli kuormantasaajan IP-osoitetta ei voi jakaa usean palvelun 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:stä188.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 rajataanmatchLabels-osion avulla. Labelin on oltava sama kuinLoadBalancer-palvelussa käytetty. -
Kun käytät palvelussasi asetusta
externalTrafficPolicy: Local, Podiesi on sijaittava solmuilla, jotka voivat välittää liikenteen niille suoraan (eli paikallisesti). Tämän saavuttamiseksi sinun on lisättävä Podeihisi (tai Deploymentsiin tai Statefulsetiin, jos soveltuu) nodes selectorrahti.csc.fi/local-load-balancer: '':
Routen ja LoadBalancer-palvelun erot käyttöönoton rolloutien aikana
Rahtissa Routet ja LoadBalancer-palvelut käsittelevät liikennettä eri tavoin käyttöönoton rolloutien aikana.
OpenShiftin HAProxyyn integroidun kuormantasaajan hallinnoimat Routet on suunniteltu mukautumaan nopeasti ja ohjaamaan liikenne heti, kun uusi podi käynnistyy, sekä samanaikaisesti lopettamaan reitityksen vanhoihin tai päättyviin podeihin. Tämä varmistaa nopean reagoinnin muutoksiin ja minimoi palvelukatkokset.
Sen sijaan LoadBalancer-palvelut jakavat liikennettä uusien podien lisäksi edelleen myös vanhoihin tai päättyviin podeihin. 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äyttäessäsi ulkoisia kuormantasaajapalveluita, voit soveltaa blue-green deploymentin periaatetta.