1. Startsida
  2. /
  3. Container platform
  4. /
  5. OpenShift container platform

OpenShift container platform

drift av OpenShift

Binero erbjuder en managerad OpenShift-lösning från vårt egna miljömärkta datacenter i Sverige, var vi garanterar säkerhetsklassad datalagring och tillgänglighet 24/7.

Binero cloud svensk molntjänst
  • beprövade och granskade mjukvaruval
  • integrerat stöd för CI/CD för modern applikationsdrift
  • stöd för automation applikationshantering via Operators

ni som söker drift av OpenShift- här är det! 

OpenShift är byggt för organisationer som vill fokusera på vidareutveckling av sina kärnprodukter, jämfört med att i nuvarande lösningar kanske sitta fast i långdragna uppdateringsprocesser av komplexa kluster med alla dess rörliga delar.

Vi tar hand om driften av er Openshift plattform oavsett om era kluster är hos er, hos oss eller i molnet. Vi tar ansvar för att era kunder kommer åt sina tjänster helt utan avbrott.

Nå ut till oss så berättar vi om hur vi jobbar med standardisering av arbetsflöden, arbetssätt enligt CI/CD, support och regelbundna driftsmöten så att ni kan fokusera på utveckling och njut av en fullt fungerande och automatiserad infrastruktur.

24/7 Support

SLA 99,95

säkert

visualisering av vad som ingår i en managerad tjänst av it infrastruktur

Inom OpenShift tar GitOps lärdomar från DevOps, genom att säkerställa att kluster endast går att förändras från en central konfigurationspunkt ("Single Source of Truth") som finns versionshanterad. Detta medför spårbarhet, vem som har gjort vilken förändring samtidigt som det möjliggör tillbakarullning av förändringar till ett tidigare känt fungerande tillstånd.

Underlättar arbetet för utvecklaren såväl som för driftteknikern

OpenShift är byggt och utformat för organisationer som är i behov av Kubernetes i form av en containerplattform. OpenShift erbjuds som en tjänst (PaaS), som är en enhetlig applikationsplattform med ett hundraprocentigt Kubernetes-kompatibelt API som underlättar arbetet för utvecklaren såväl som för driftteknikern, oavsett var i molnet resurserna befinner sig

vanliga frågor och svar

Ett antal år har gått sedan Binero först började arbeta med orkestrering av containers, och sedan dess har det hänt en hel del med teknologin.

Kubernetes finns i en uppsjö av distributioner och kreativa paketeringar, och OpenShift har landat speciellt bra framförallt hos lite större organisationer som till stor del sköter sin applikationsutveckling internt.

Genom de kunder vi fått hjälpa med allt från installation och konfiguration, till uppdateringar och drift, har vi stött på en del återkommande frågor.

för att underlätta för er som har eller utvärderar OpenShift har vi sammanställt några av de tekniska frågorna vi fått

 

Pod- och Service-nät får inte finnas i övriga nätverket, ska de routas till OpenShift? Var i så fall?

Det är interna nät som används i OpenShift. Dessa behöver vara reserverade för att inte användas till annat. Till exempel kan en Service i OpenShift med IP-address 10.0.0.2 som vill nå en databas på 10.0.0.3 misslyckas eftersom databasadressen kommer att tolkas som lokal.

Är *.apps.tld för applikationer i klustret?

(T.ex. helloworld.apps.interndomain.se eller för externt bruk t.ex. helloworld.apps.externdomain.se)

 *.apps.tld är ett wildcard-entry i DNS som publicerar alla tjänster. Härifrån kommer man bl.a. kunna nå webbgränssnittet Kibana för att kunna söka i applikationsloggar, och Grafana för att visualisera klustermetrik.

Om en tjänst i OpenShift publiceras utan ett namn, kommer den att skapas med följande namnkonvention: <service>-<namespace>.apps.interndomain.se

Vill man ta in trafik med namnet www.example.com, behöver man alltså bara se till att paketen med den Host header satt kommer in till OpenShift. Då kommer trafiken att landa i rätt projekt och dess poddar.

Är api.tld ett API för saker utanför OpenShift-miljön?

Ja, API-adressen används för kommunikation med OpenShift. Det kan vara för felsökning, att deploya nya projekt, använda extern automation o.s.v.

Ska api.tld publiceras på internet?

Den ska inte publiceras på internet.

Är api-int.tld för internt bruk i klustret?

api-int används för intern kommunikation i Kubernetes

Vad brukar prata med detta API?

Det används t.ex. när worker-noderna pratar mot kontrollplanet, d.v.s. master-noderna.

Hur fungerar Ingress- respektive Egress-trafiken i klustret? Vad blir det för nätverksadresser som används för det?

Egress-trafiken får default nodens IP-adress när den kommunicerar ut. Ingress sköts av router-poddar (HAProxy) i OpenShift. Dessa deployas normalt på infra-noderna och de lyssnar på port 80 och 443. Trafiken från Netscaler (*.apps) skickas ner till dessa noder som ser till att trafiken kommer till rätt projekt inne i OpenShift.

Vi har en central loglösning dit vi vill skicka en del loggar. Hur ser ni på det?

Inga konstigheter, en pipeline sätts upp till den lokala logglösningen.

Den persistenta storage-lösning som finns i OpenShift, vad används den för och vad ska man tänka på när den konfigureras?

Persistent storage används av OpenShift först och främst för lagring av diverse systemfiler. Konfigurering av storage i OpenShift/Kubernetes sker genom att skapa en backend som kan kommunicera med t.ex. NetApp, Ceph eller Isilon. Sedan skapas en storage class som presenterar konfigurerat storage mot OpenShift/Kubernetes.

Detta gör att OpenShift/Kubernetes kan göra en förfrågan efter storage på ett standardiserat sätt oberoende av vilket storage som är konfigurerat. När poddar deployas och begär storage kommunicerar poddarna enbart med OpenShift/Kubernetes som i sin tur ser till det skapas en disk via konfigurerad backend och att den monteras in i rätt pod.

Kan vi ha flera lagringslösningar? T.ex. en för komponenter till OpenShift och en för poddar? Eller olika för poddarna som är bättre ur säkerhetssynpunkt?

Det går utmärkt att konfigurera flera olika backends och storage classes. Skillnaden blir att vilken storage class som ska användas till vad måste anges.

Tillkommer någon licenskostnad för CoreOS?

Nej, den ingår i OpenShift baslicens.

Rekommendationen från Red Hat på /14-nät för pod- och service-nät låter väldigt mycket. Kan ni rekommendera en annan lösning?

Notera att om förändring av storleken på nätet behöver göras i efterhand krävs ominstallation av OpenShift-klustret. Med kunskap om det och om ni tror att ni inte behöver växa i klustret kan ni dela på ett /16-nät enligt nedanstående exempel.

Varje nod kräver ett /23-nät = 512 adresser. Om antalet noder är tre infranoder, tre masternoder och två workernoder  är det totalt 4K adresser. Delar ni på ett /16-nät för service- och klusternät blir det två /17-nät med 32K adresser på vardera. Drar vi av adresserna som går till infra-, master- och workernoder  blir det 28K adresser kvar att skala upp poddar på. Man skulle teoretiskt kunna lägga till 56 st workernoder. Det krävs inte en uppskalning av infra- och masternoder för att kunna skala upp antal workernoder. 

Exempel pod-nät

172.26.0.0 / 17

IP-adresser från 172.26.0.1 till 172.26.127.254.

Exempel service-nät

172.26.128.0 / 17

IP-adresser från 172.26.128.1 till 172.26.255.254

Vad är Rook-Ceph?

“It is a set of Operators focused on providing storage for containerized applications. Rook-Ceph is the Rook Operator focused on orchestrating Ceph, and OpenShift Container Storage brings Rook-Ceph to the enterprise in OpenShift.” 

Läs mer här och här.

Vi undrar om vi kan använda private network inom OpenShift-klustret. Kan vi t.ex. ta IP-adresser inom 10.0.0.0 - 10.255.255.255?

Ja, ni kan använda 10.0.0.0/8 men ska en pod prata med något utanför OpenShift på 10.0.0.0/8 måste ni segmentera nätet annars blir det routing-problem eftersom destinationen antas existera inom klustret.

Vilka behörigheter behövs i VMware?

Inga personliga adminkonton. Ett servicekonto med ”provisionerings”-behörighet till specifika resurser är det som krävs. Se dokumentation här.

Finns det IPv6-stöd?

Ja.

Kan man använda samma subnät för Ingress och Egress?

Nej, Egress är för utgående trafik från klustret för att applikationer ska nå t.ex. databaser som ligger utanför klustret. Ingress-nätet är till för att styra trafik mot specifika applikationer i klustret som inte exponeras på port 80 eller 443. Dessa nät behöver separation.

Vad är är en bootstrap node?

Bootstrap-noden är initialt en del av OpenShift klustret, och är den första master noden som blir installerad. När bootstrapen är färdigkonfigurerad kopierar den sitt etcd-data till de blivande master noderna som tar över. Bootstrap-noden avslutar därefter sin Bootstrap-process som gör att noden efter installationen kan tas bort.

Hur många CPU-licenser behövs för en OCS-lösning?

Minimum req 30 CPU med Hyperthreading 15CPUer, OpenShift skeppar 2CPU licenspaket så det behövs 2*8CPU licenser för detta. Mer info finns här.

NFS eller iSCSI för ElasticSearch?

Elasticsearch tenderar att skapa väldigt många små filer innehållandes metadata som ska behandlas på olika sätt. Detta gör att prestandan blir sämre om man använder remote filsystem (som NFS) jämfört med lokala filsystem (iSCSI).

Om det är en mindre installation av Elasticsearch skulle NFS fungera, men om det är mer omfattande eller förväntas bli det är det bättre att köra på iSCSI.

Kring interface på noderna: Kommer interface #1 användas för API anropen för Trident och interface #2 för NFS (trafiken mellan containers och persistent volumes)?

Interface #1 används för kommunikation mellan noderna och kommunikation med lastbalanserare osv.

Interface #2 behövs endast om Interface #1 inte kan routa trafik till NetApp SVM nätet genom sin default gateway. Om SVM nätet inte är routingsbart ska interface #2 tillhöra samma VLAN som NetApp SVM nätet ligger på.

Tekniskt går det att konfigurera SVM på ett nät med routing, och OpenShift kommer att hantera det. Risken är dock att det kommer bli dålig prestanda.

Går det att byta storage-lösning eller flytta mellan olika lösningar i efterhand?

Det går att byta storage-lösning i efterhand och det går att köra flera storage samtidigt. Det handlar om att sätta upp nya storage classes och att flytta över monitorering, registry och loggning. Hur detta ska utföras i praktiken och hur datan ska migreras kan vi, om det blir aktuellt, hjälpa till att reda ut och utföra.

Kommer testmiljön för OpenShift att finnas på samma nät som prod-miljön (dvs. samma /16-nät som vi skapar/reserverar för POD/SERVICE) eller behövs det reserveras nytt POD/SERVICE-nät för testmiljön?

Vi ser ingen anledning att ha olika nät för TEST och PROD. Det är ett mjukvarudefinierat nät som kommer användas internt i klustret. Tvärtom blir det enklare eftersom adresserna i klustret kommer vara samma.

Vad gäller angående Ingress-CIDR, är det något skall redas ut/diskuteras?

Om tjänster ska publiceras i OpenShift-klustret som inte ska gå via lastbalanseraren tas IP-adresser från Ingress-CIDR. Då ska de routas till den noden som hostar den tjänsten/podden. Om ni inte kommer att köra sådana tjänster så finns inte behovet för Ingress-CIDR. Vi brukar rekommendera att ta höjd och reserverar ett /24 för varje kluster.

Gällande hostname och IP så var det väl snack om 8st (?) servrar fördelade på master, infra och worker som ligger på VM CIDR (ett /24-nät). Där misstänker jag test-miljön placeras på samma nät och det skapas upp ytterligare servrar för just test, stämmer det?

Nej det kan inte vara samma subnät. Under installationen av noderna så tilldelas IP-adresser från en tillfällig DHCP-server som vi sätter upp och vi vill inte ha en DHCP-server igång i ett nät där det körs andra tjänster. VM CIDR måste bestå av adresser routade i er miljö och det kommer gå bra med ett /24-nät. Ni kan såklart dela ett /24-nät i två /25-nät.

Skulle ni kunna förtydliga kring VMware DRS (Distributed Resource Scheduler)?

Vi rekommenderar er som mottagare att konfigurera den underliggande miljön enligt följande princip: Site affinity - Node anti-affinity. I praktiken: låt ett OpenShift kluster endast leva i en hall (Site affinity) samt håll de olika OpenShift-nodtyperna (master/infra/worker/ocs) på skiljd fysisk hårdvara (Node anti-affinity). Med speglad lagring mellan hallar, administrativa rutiner samt konfigurationer i er plattform, bör ni uppnå goda förutsättningar för lyckad disaster recovery vid händelse av ett katastrof (hallbortfall).

Stödjer er installation vSAN?

Det går om vSAN kör File Services. Se länk här.

När vSAN med File Services sätts upp säger VMware "wizard-"guiden att man behöver tre IP adresser. En primär och två sekundära. Det VLAN som de IP-adresserna ligger på behöver kunna tillåta Port 111 (TCP and UDP) och 2049 (TCP and UDP) för att vSphere CSI poddarna ska kunna mounta vSAN volymen. Podden mountar vSAN-volymen som NFS.

Notera även att File Services inte stödjer stretched cluster.

Vilka behörigheter behöver Bineros användare i VMware?

Se här.

Hur ska vi tänka kring säkerhet?

Om ni öppnar till adresserna vi har specificerat i OpenShift_Prerequisites-arket kommer vi kunna installera klustret men för att OpenShift ska kunna byggas ut med mer funktionalitet, t.ex. genom operators, krävs access till externa ekosystem. Var dessa finns styrs av hur en leverantör väljer att publicera dem.

Sedan finns det bättre skydd än perimeterbrandväggar om man vill begränsa utgående trafik. Det går enkelt att konfigurera cluster-wide proxy. Man kan även definiera Egress-brandväggar i klustret på väldigt granulär nivå.

Externa artefakter som publiceras ligger ofta i ett CDN. Det betyder i praktiken att en brandväggs- eller proxy-öppning inte är tillräcklig. Oftast vet man inte exakt vilken IP-adress som levererar artefakter i slutändan. Eventuella brandväggsöppningar behöver ha kännedom om alla IP-adresser i CDN:et.

För att säkra upp en OCP-miljö (OpenShift Container Platform) behöver man införa nya säkerhetsrutiner. Här finns mer att läsa om container security.

Vad menas med Cluster CIDR och Service CIDR?

Cluster CIDR och Service CIDR är två stora default-nät som används internt i OpenShift.

Dessa interna nät behöver reserveras och inte användas för något annat syfte. De kan dock återanvändas för varje OpenShift/Kubernetes installation som görs. Näten routas inte ut från OpenShift utan används bara internt.

Var installeras certifikaten?

All certifikatshantering sker i klustret.

Hur länge går det att vänta med att skapa AD-gruppstrukturen?

Tills dess att AD ska konfigureras/integreras.

Hur ser specifikationen för hårdvara ut?
exempel på storlek av openshift kluster

kontakta oss

Har du frågor om vår OpenShift plattform? Rådfråga vår specialist eller fyll i formuläret så återkommer vi till dig direkt. 

Fråga vår specialist om drift av OpenShift

One of our cloud experts, ready to assist our clients

Johan Wedin

COO

johan.wedin@binero.com

kontakta oss via formulär

fyll i formuläret nedan och vi kontaktar dig