Hyppää sisältöön

Welcome to our weekly research support coffee hour on Zoom! Click here for more information.

Warning!

Puhti scratch disk is becoming very full (80+ % ) resulting in performance degradation. Everybody is advised to only keep actively processed data on scratch, all other data should be deleted, transferred to host institute or stored in Lumi-O. No new quota will be granted. Click here for a tool for examining your disk usage.

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.

Rahti Networking

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ä.

nginx and Mongo

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.

Route Options

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 osoitteeseen router-default.apps.2.rahti.csc.fi, tai jos tämä ei ole mahdollista, vaihtoehtoisesti on määritettävä A-tietue, joka sisältää osoitteen router-default.apps.2.rahti.csc.fi IP-osoitteen. Tapa, jolla tämä on määritettävä, riippuu DNS-tietueen rekisteristä.

    $ host ?????.??
    ?????.?? is an alias for router-default.apps.2.rahti.csc.fi.
    router-default.apps.2.rahti.csc.fi has address 195.148.21.61
    
  • 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]):

    oc annotate route $route_name haproxy.router.openshift.io/ip_allowlist='193.166.0.0/16'
    
  • Tämä toinen esimerkki sallii vain tietyn IP-osoitteen:

    oc annotate route $route_name haproxy.router.openshift.io/ip_allowlist='188.184.9.236'
    
  • Ja tämä esimerkki yhdistää molemmat:

    oc annotate route $route_name haproxy.router.openshift.io/ip_allowlist='193.166.0.0/15 193.167.189.25'
    

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.

oc get ipaddresspools.metallb.io -n metallb-system <project_name> -o yaml
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 :.

rahti

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:

NAME       ENDPOINTS           AGE
mysqllb   10.0.0.1:3306        10m
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.

rahti

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:

  1. Aktivoi palvelussa Local-ulkoinen liikennekäytäntö. Tee tämä lisäämällä externalTrafficPolicy: Local kohdan spec alle 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: mysql
    

    Local Traffic Policy Limitations

    Rahti käyttää metallb:ssä L2Advertisement-tilaa. Lisätietoja on kohdassa 'Layer 2'.

    Huomaa myös, että kun externalTrafficPolicy on asetettu arvoon Local, 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: local and Source IP Preservation

  2. 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:
      - Ingress
    

    Yllä oleva NetworkPolicy-esimerkki sallii saapuvan liikenteen CIDR-alueelta 188.184.0.0/16, joka vastaa aluetta [188.184.0.0 - 188.184.255.255], sekä yksittäisestä IP-osoitteesta 137.138.6.31. Liikenteen kohde on rajattu matchLabels-osion avulla. Labelin on oltava sama kuin LoadBalancer-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.

Suomenkielinen tekoälykäännös

Sisällössä voi esiintyä virheellistä tietoa tekoälykäännöksestä johtuen.

Klikkaa tästä antaaksesi palautetta