Verkkoyhteydet

Ipv4

Kaikki verkkoyhteydet Rahdissa käyttävät IPv4:ää. Kaikki tässä dokumentissa ja Rahdin 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 Rahdin 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 Rahdin 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 Rahdissa oletusarvoisesti.

Edistynyt verkkokonfiguraatio

Rahdin 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 ajamiseen 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 muut Podit muissa nimiavaruuksissa 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. Mikä tahansa imagen julkaisema ei-etuoikeutettu portti (>=1024), esimerkiksi 8081, on saavutettavissa tästä IP-osoitteesta. Podin käynnistys epäonnistuu, jos se yrittää julkaista etuoikeutetun portin ([0-1023]). Jos Pod tuhotaan, tavallisesti sen konfiguraation muutoksen vuoksi mutta mahdollisesti myös odottamattomista syistä, kuten laitteistoviasta, 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 tekee kyselyitä ensimmäiseen IP-osoitteeseen (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ää yllä ajantasaista 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. Kaikki seuraavista nimistä ovat kelvollisia ja ratkeavat 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, Rahdin 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ä Rahdissa, 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 julkaisevat portin 27017, voimme luoda palvelun nimeltä mongo, joka on liitetty näihin 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 datapyyntöä.

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

Re-encrypt

Jotta Re-encrypt toimisi, 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 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.

Rahdin tärkeä rajoitus on, että vain HTTP/80- ja HTTPS/443-portit ovat julkaistuina 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 Rahdin HAProxy-kuormantasaajiin tulevan liikenteen kesken. Nimipohjaisia virtuaali-isäntiä käytetään ohjaamaan liikenne 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 väliviivojen 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ää Rahdissa, mutta DNS-määritykset ja varmenteet asiakkaan on hallittava itse:

• 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 mahdollisuus sallia vain tietty IP-osoitejoukko pääsemään 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 lähtevän liikenteen IP-osoite on 86.50.229.150. Mikä tahansa Rahdissa toimiva Pod käyttää oletusarvoisesti tätä IP-osoitetta tavoittaakseen mitä tahansa Rahdin 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

Rahdin egress-IP voi muuttua tulevaisuudessa. Esimerkiksi jos useita Rahdin versioita ajetaan rinnakkain, kullakin on eri IP-osoite. Tai jos taustalla olevassa verkkoinfrastruktuurissa tapahtuu merkittävä muutos.

LoadBalancer-palvelutyypin käyttäminen 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 LoadBalancer-palvelut käyttöön Rahdin projektissasi ja käyttää niitä, sinun on lähetettävä pyyntö palvelupisteeseen (servicedesk@csc.fi). Pyynnön on sisällettävä seuraavat tiedot:

• Projektin nimi: Anna sen Rahdin projektin tarkka nimi, jossa haluat ottaa LoadBalancer-palvelut käyttöön.

• CSC-projektinumero: csc_project-numero, jota käytetään Rahdin projektissa.

• 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 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 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ä palvelutyypiksi on asetettu LoadBalancer ja että kentän allocateLoadBalancerNodePorts arvoksi on asetettu false (oletusarvo on true), koska NodePortit eivät ole käytössä Rahdissa. Jos tätä kenttää ei aseteta oikein, varattu node-portti jää käyttökelvottomaksi, 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.

Kuinka hakea selector

Komentoriviä käyttäen

Aja komentorivilläsi oc describe pod <pod-name> -n <namespace>. Kun olet suorittanut oc-komennon, näet tulosteen, joka sisältää osion nimeltä Labels. Kopioi mikä tahansa labeleista ja liitä se yaml-tiedostoon kohdan selector alle. Varmista, että noudatat yaml-syntaksia ja vaihdat merkin = 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ää käyttäen

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. Varmista, että noudatat yaml-syntaksia ja vaihdat merkin = merkiksi :.

Kuinka varmistat, että palvelusi osoittaa oikeaan podiin

Komentoriviä käyttäen

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 parhaillaan kohdistuu. Esimerkiksi:

NAME       ENDPOINTS           AGE
mysqllb   10.0.0.1:3306        10m

Selainkäyttöliittymää käyttäen

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

IP-eston lisääminen palomuurissa LoadBalancer-palveluun käyttämällä NetworkPolicya

LoadBalancer-palveluun on mahdollista lisätä palomuurin IP-esto. 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 viestintäprotokollat, 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. 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 julkaista 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 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 rajataan matchLabels-osiolla. Labelin on oltava sama kuin LoadBalancer-palvelussa käytetty.

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

   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

Rahdissa Routet ja LoadBalancer-palvelut hallitsevat 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, ja samalla lopettamaan reitityksen vanhoihin tai päättyviin podeihin, mikä 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 jaksottaisiin 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 tulisi 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 omaksua blue-green deploymentin periaatteen

Onko tämä sivu hyödyllinen?

Kyllä

Kiitos palautteestasi!

Ei

Kiitos! Arvostamme palautettasi.

Kerro meille miten voisimme parantaa tätä sivua ottamalla meihin yhteyttä.