Hyppää sisältöön

Docs CSC now features an automatic Finnish translation. Click here for more information.

Warning!

Puhti and Mahti will be decommissioned after Roihu becomes available. Users should clean up unnecessary files and move any required data by the end of August 2026. See the Roihu data preparation instructions for details.

Puhti scratch is very full: keep only active data there and move or delete everything else. No new Puhti scratch quota will be granted.

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, mikä toimii niiden sisällä, 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ä paitsi muiden nimiavaruuksien muut Podit voivat jakaa saman yksityisen IP-osoitteen, 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. Kaikki imagen avaamat ei-etuoikeutetut portit (>=1024), kuten esimerkiksi 8081, ovat saavutettavissa tästä IP-osoitteesta. Podin käynnistys epäonnistuu, jos se yrittää avata etuoikeutetun portin ([0-1023]). Jos Pod poistetaan, 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 huolehtii siitä, että sillä on ajan tasalla oleva lista IP-osoitteista, jotta pyynnöt lähetetään vain kelvollisiin osoitteisiin.

Palvelut on rakennettu avaamaan yksi tai useampi portti, ja ne tarjoavat myös sisäisen DNS-nimen. Mikä tahansa näistä nimistä on kelvollinen ja ratkeaa 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. Mikä 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 avaavat 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 palveluun yritetään muodostaa yhteys, yksi mongo-Podeista valitaan palvelemaan datapyyntöä.

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 liitettyjen Podien tulee käyttää salaamatonta HTTP-liikennettä. Jos route on määritetty tarjoamaan suojattua TLS/HTTPS-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 sitä, että salaus delegoidaan Podille, jonka täytyy kuunnella TLS/HTTPS-liikennettä ja tarjota varmenne, jonka asiakas vastaanottaa.
  • Re-encrypt on yhdistelmä kahdesta edellisestä vaihtoehdosta: 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 toimisi, sinun on toimitettava oma varmenteesi. Vaiheita on 3: (1) Sinulla täytyy olla 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 täytyy olla erillinen kohde-CA-varmenne PEM-koodatussa tiedostossa. Jos jotakin näistä vaiheista ei tehdä 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 sisääntulevalle 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 sisääntuleva virtuaalinen IP-osoite on jaettu kaiken Rahtin HAProxy-kuormantasaajien kautta tulevan liikenteen kesken. Liikenteen ohjaamiseen oikeaan Routeen käytetään nimipohjaisia virtuaali-isäntiä. 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 verkkotunnus voidaan periaatteessa käyttää Rahtissa, mutta asiakas vastaa DNS-konfiguraatiosta ja varmenteiden hallinnasta:

  • DNS-konfiguraatiota varten sinun täytyy määrittää CNAME, joka osoittaa osoitteeseen router-default.apps.2.rahti.csc.fi, tai jos tämä ei ole mahdollista, vaihtoehtoisesti täytyy määrittää A-tietue, joka sisältää osoitteen router-default.apps.2.rahti.csc.fi IP-osoitteen. Tapa, jolla tämä täytyy määrittää, 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 mahdollisuus sallia vain tiettyjen IP-osoitteiden pääsy routeen. 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]):

    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 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 määrä virtuaalisia IP-osoitteita.

Egress-IP voi muuttua

Rahtin egress-IP saattaa 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 suuri 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 sisääntulevaa 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 täytyy lähettää pyyntö palvelupisteeseen (servicedesk@csc.fi). Pyynnön tulee sisältää 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)

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 jatkaa LoadBalancer-palvelun luomista. 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 Service-objektista 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 port on käyttökelvoton, ja palvelun luonti voi epäonnistua, jos koko oletusarvoinen node port -alue (30000-32767) on jo varattu.

Lisäksi palvelumäärityksen porttikentän (esim. 33306 edellisessä esimerkissä) täytyy olla alueella 30000-35000.

Selectorin hakeminen

Komentorivillä

Aja komentorivilläsi oc describe pod <pod-name> -n <namespace>. Kun olet suorittanut oc-komennon, näet tulosteessa osion 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ä palvelun nimi sekä niiden Podien IP-osoitteet ja portit, joihin palvelu 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 NetworkPolicylla

LoadBalancer-palveluun on mahdollista lisätä palomuurin IP-estoja. Tämän avulla voit määrittää sallintalistan tietyille IP-osoitteille (esimerkiksi 188.184.77.250) ja/tai IP-alueille (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.

Menettely tämän toteuttamiseksi on seuraava:

  1. Ota käyttöön palvelun 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 usean palvelun 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 sisääntulevan 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 täytyy olla sama kuin LoadBalancer-palvelussa käytetty.

  3. Kun käytät palvelussasi asetusta externalTrafficPolicy: Local, Podiesi täytyy sijaita noodeilla, jotka voivat välittää liikenteen niihin suoraan (eli paikallisesti). Tämän toteuttamiseksi sinun täytyy lisätä node selector rahti.csc.fi/local-load-balancer: '' Podeihisi (tai Deploymentiin tai StatefulSetiin, jos soveltuu):

    apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
      labels:
        env: test
    spec:
      nodeSelector:
        rahti.csc.fi/local-load-balancer: ''
      .....
      .....
    

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 mukauttamaan ja ohjaamaan liikennettä nopeasti heti, kun uusi podi käynnistyy, ja samalla 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 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

Suomenkielinen tekoälykäännös

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

Klikkaa tästä antaaksesi palautetta