TransIP voegt nieuwe performancenodes voor Kubernetes toe

TransIP heeft nieuwe performancenodes voor Kubernetes-clusters toegevoegd. De nodes zijn volgens de webhoster geschikt voor containerapplicaties die veel rekenkracht nodig hebben, zoals grote e-commerceapplicaties en drukbezochte websites.

De performancenodes beschikken over dedicated vcpu's, bandbreedte tot 2,5Gbps en gedistribueerde NVMe-opslag, schrijft TransIP in een aankondiging. Verder draaien de nodes op hardware gebaseerd op de tweede en vierde generatie AMD Epyc-processorfamilie.

De nodes komen in drie soorten beschikbaar: P2-nodes, P4-nodes en P8-nodes. De P2-nodes zijn de goedkoopste optie en komen met twee vcpu's en 4GB aan ramgeheugen. Hiervoor wordt 0,0372 euro per uur gerekend. De P4-nodes krijgen vier vcpu's en 8GB ramgeheugen en hebben een prijs van 0,0744 euro per uur. De P8-nodes zijn de duurste optie, met een prijs van 0,1488 euro per uur. Deze nodes hebben acht vcpu's en 16GB aan ramgeheugen.

Soort node	Specificaties	Prijs per uur
P2	2 dedicated vcpu, 4GB ramgeheugen, 50GB opslag	€ 0,0372
P4	4 dedicated vcpu, 8GB ramgeheugen, 50GB opslag	€ 0,0744
P8	8 dedicated vcpu, 16GB ramgeheugen, 50GB opslag	€ 0,1488

Reacties (67)

[Zebby]

Wij zijn een maand of 2 geleden gemigreerd naar de managed Kubernetes oplossing van TransIP.
Qua prijsstelling zijn ze heel scherp, een cluster met dezelfde hardware als een VPS kost hetzelfde, maar wel per node.

Echter zijn we niet te spreken over de stabiliteit en volwassenheid van het platform. We hebben al meerdere bugs gevonden, die icm trage respons vanuit support hebben geleid tot significante downtime aan onze zijde. De omgeving is ook een stuk minder stabiel en te beheren, en de logging in het paneel is heel apart geregeld.
Oh en ze noemen het nergens, maar er is een 10 volume per node limiet. Leuk voor onze testomgeving, moeten we extra nodes aanschaffen door een ongenoemde beperking.

Ter referentie, wij kwamen van een k3s installatie op CentOS waar alles draaide als een zonnetje. We overwegen sterk terug te gaan naar een AlmaLinux setup met dezelfde opzet.

Misschien is het een 'you get what you pay for', maar ik had meer verwacht.

Edit: Er is mij gevraagd nogmaals mijn ervaring te delen met de klantenservice, dus dat heb ik zojuist gedaan. In zoverre zal ik het bijwerken mocht er wat gebeuren, in positieve of negatieve zin.

[Reactie gewijzigd door Zebby op 20 september 2024 16:22]

[Anonymoussaurus]

Waarom niet gewoon EKS van AWS? Met Terraform/OpenTofu ook nog eens makkelijker versiebeheer. Er zijn genoeg modules voor EKS in ieder geval.

[Reactie gewijzigd door Anonymoussaurus op 19 september 2024 10:11]

[jaenster]

Om dezelfde reden waarom deze zelfde community vraag tekens stelt bij SIDN die wil verhuizen naar AWS. Prima cloud provider maar niet alles is altijd maar geschikt om te hosten bij een niet EU partij

[Anonymoussaurus]

Probleem is een beetje dat je dan alles handmatig moet doen, en dat is vervelend als je iets opnieuw moet optuigen. Sowieso kwam ik er achter dat ik Kubernetes op zichzelf super omslachtig vind, en dan voornamelijk vanaf de grond tot aan iets werkends krijgen. Daarbij wordt je met de documentatie ook 10x doorgestuurd naar een nieuwe pagina.

[Anonymoussaurus]

I guess? k3s vond ik zelf al minder omslachtig en duidelijker qua documentatie. Maar ach, die keer was ook de eerste keer, dus wellicht dat dat het was. Het is in ieder geval qua documentatie (vanaf installeren tot iets up-and-running krijgen) stukken slechter dan dat van bijvoorbeeld Docker, maar tegelijkertijd zijn dat natuurlijk twee verschillende soorten tooling.

[Reactie gewijzigd door Anonymoussaurus op 19 september 2024 11:14]

[MainframeX]

Klinkt alsof je met losse VM's en Kubadm bezig bent geweest. Dat is initieel wel wat meer werk om op te zetten als je alles met de hand doet. Bij de oplossing van AWS, AKS, GCP, TransIP, Previder etc. kan je gewoon in een portaal een omgeving in elkaar klikken en krijg je daarna een managed Kubernetes omgeving die je direct kan gebruiken.

Docker is wel een heel stuk eenvoudiger dan k8s. Dat is in de basis eigenlijk niets meer dan een image runtime en een set met tools om images te bouwen en beheren.

[Anonymoussaurus]

Klopt, dat was inderdaad op een losse VM met Kubernetes en kubectl e.d. Dat was een kriem. Dingen in elkaar klikken kan ik ook wel haha, maar voor de eerste keer alles met de hand opzetten is toch niet per se een skill-issue? Ik moest een repo clonen, vervolgens Kubernetes opzetten, configs aanpassen, in een bepaalde volgorde applies doen, en toen werkte het. En nee, dat stond nergens in de documentatie, en de documentatie van Ansible AWX was ook kut, dus kon daar ook niks mee. Dan ben je al gauw een paar uur zoet.

[MainframeX]

Ik heb nog nooit een repo hoeven clonen om een kubeadm cluster op te tuigen. Ik moest op Ubuntu gewoon kubeadm, kubectl, containerd en kubelet installeren, swap uitzetten, wat modules blacklisten met modprobe en kubeadm init draaien. Daarna heb je een controlplane en kan je de workernodes opzetten. Ik zou zeggen; gun jezelf nog een 2e of 3e poging. Het hoeft niet gelijk in 1x goed te gaan

Trouwens als je AWX kent, dan ken je Ansible vast ook. In dat geval kan je eens naar Kubespray kijken. Dat is een grote verzamelijk Ansible scripts om productie waardige clusters op te zetten. Lekker automatisch en geen geklooi met kubeadm (want dat is toch al geen IaC dus yuck hehe).

[ari3]

Ansible en AWX moeten dood wat mij betreft. Ik zie teveel klanten die Ansible combineren met Kubernetes wat gewoon erg slecht matcht omdat ze doorgaans niet dezelfde backend hebben voor secrets waardoor er een dubbele vault administratie ontstaat. Ansible wordt sowieso gebruikt omdat inframensen dat nu eenmaal kennen uit het verleden, maar met Helm/OpenShift tooling is er eigenlijk geen noodzaak om AWX meuk te gebruiken.

[MainframeX]

Klinkt eerder dat je klanten iets fundamenteel fout doen. Ik zou sowieso geen Ansible vault gebruiken voor secrets maar iets als external secrets operator i.c.m. Openbao o.i.d.

[Martink]

Ik denk dat je internet decentraal moet houden. Naar mijn mening staat er al te veel bij die mega bedrijven. Werk zelf met de Kubernetes cluster van DigitalOcean. Gewoon paar keer klikken en je cluster draait.
Ik zie het voordeel niet om bij EKS/AWS de boel te draaien als het ook bij een partij in Nederland kan. (ok DO is niet Nederlands, maat transip bood het nog niet aan toen ik overstapte)

[Zebby]

Concrete afspraken met klanten om bij niet-Amerikaanse partijen te hosten. En ja, ik weet dat TransIP (nu Team Blue) draait in datacenters van o.a. Equinox, dus in zoverre realistisch haalbaar.
Wij versleutelen zelf alle gevoelige data, dus het is in theorie geen bezwaar om bij AWS te draaien, maar afspraak is afspraak. Men betaalt ook voor dit voorrecht, dus prima. En op een VPS draaide het dus probleemloos.

[Q]

Bedankt voor het delen van je ervaring.

Als ik een licht kritische noot mag plaatsen, hoe kan het dat je er pas in productie achter komt dat er problemen zijn?

[jaenster]

Je kan toch ook een auto kopen van een merk die normaal goede toffe autos maakt, maar deze keer net niet? Als je een van de eerste koopt staat het internet nog niet vol met ervaringen van dat model

[Cybje]

Een auto is denk ik niet een goed voorbeeld, je hebt meestal niet een auto in test waarna je exact dezelfde auto in prod koopt.

Je test omgeving hoort gewoon representatief te zijn voor productie. Dat het aantal volumes afwijkt is dus al raar. Hoe kun je anders goed testen, bijvoorbeeld om onbekende beperkingen of bugs tegen te komen?

[gimbal]

"raar". Het is 100% herkenbaar en te verwachten dat een test omgeving totaal niet representatief is. Want kosten drukken.

Het zou raar moeten zijn, maar wat zou moeten en de realiteit daar zit echt een gapend gat tussen.

[Cybje]

Misschien is "raar" niet het goede woord dan, want herkenbaar is het zeker. En ik snap ook dat de reden vaak de kosten is. Maar het is simpelweg een domme bezuiniging. Het gaat ook bijna zonder uitzondering mis. Vroeg of laat loop je tegen een probleem in prod aan wat je ook in test had opgemerkt als die omgeving gelijk was geweest. Ik accepteer het in elk geval niet als klanten die wens hebben, maar ik werk ook meer in 100% omgevingen.

[EnigmA-X]

Een "DTAP"-strategie draait niet primair om "kosten drukken", maar efficient en doelgericht gebruik maken van iedere omgeving daarin. Dat een aantal individuele omgevingen dan relatief minder kosten dan de P wordt meestal gezien als "bijvangst".

Dat een testomgeving totaal niet representatief zou zijn, zou niet moeten kloppen. Functioneel zou hij hetzelfde en/of meer moeten kunnen dan de A en P omgevingen, uitzondering daargelaten.

De hoofdreden van het splitsen van omgevingen is plat gezegd dat je niet iedere keer je productie omgeving sloopt omdat je iets wilt ontwikkelen/testen.

[moonlander]

Dat is wel heel makkelijk redeneren. Een productie omgeving is heel anders dan een test omgeving. Op een productie omgeving heb je te maken met load, wat je op een test niet hebt. Uiteraard kun je ook dat testen.. Het is maar net wat het budget is om dat allemaal te ontwikkelen. Maar praktijk is altijd anders dan een omgeving wat niet actief gebruikt wordt.

En een auto is wel een mooi voorbeeld, je koopt de auto op basis van wat de fabrikant aangeeft qua range bijvoorbeeld. In de praktijk heb je die range bijna nooit.

[Cybje]

Ik vind het makkelijk om te zeggen dat een productie omgeving anders is dan een test omgeving. Het is in de huidige tijd echt niet moeilijk om 'm helemaal gelijk te maken, met alle IaC tooling, CI/CD, et cetera. En zoals je zelf aangeeft, load kun je inderdaad ook testen. Je moet sowieso al load tests doen, om te kijken of je omgeving voldoet aan de eisen die er zijn gedefinieerd qua load. Anders krijg je weer van die crisis.nl gevalletjes, dat als er een crisis is het hele spul op z'n gat gaat.

Ik vind dat teveel mensen zich erachter verschuilen dat het te moeilijk is, maar ondertussen wel incidenten accepteren.

[Q]

Ik zie het zo: bij onwijs veel tokos is operations nog op het niveau van de jaren 90 en dat is baangarantie voor de moderne professionals die hebben leren automatiseren, clickops hebben verbannen en meegegroeid zijn in hun vak.

[jorde]

Ik kan me voorstellen dat het onderanderen gebeurd door updates aan het platform zelf, updates aan de clusters. Features die op papier compatible zouden moeten zijn, maar in realiteit afwijken.

Zou inderdaad top zijn om dit uit directe hand te horen.

[Zebby]

Twee opeenvolgende redenen vooral. De eerste was een communicatiestoornis tussen ons, een partner, en de eindklant. Dit zorgde er voor dat we veel te weinig tijd hadden om fatsoenlijk te kunnen testen.
En de tweede is dat deze klant qua grootte en verbruik aanzienlijk groter is, wat dus niet fatsoenlijk getest is . Het is primair dat wat fout ging, en ook een stuk bij TransIP op het vlak van node beheer waar wij niks aan konden doen.

[Q]

Bedankt voor je openheid, dat waardeer ik.

Ik snap dat de keuze om op een ongetest platform te deployen deels is gedaan door een comms issue, het zal deels politiek zijn om dan niet poot stijf te houden en tests af te ronden, dat is een bedrijfskeuze.

Ook valt het mij op - ook in mijn eigen omgeving - dat representatieve load tests - toch vaak worden overgeslagen, in deze context met tijdsdruk begrijp ik het wel.

Dit is uiteindelijk voor mij wel meer een les in risico management 🤷‍♀️👍

[rvt1]

Zelfde hier, bij ons blijft het klooien… ik beheer het niet zelf en alle tooling er omheen ben ik alleen gebruiker van. Maar het systeem blijft aanklooien en de performance is een beetje ver te zoeken.

[Tubby]

Goed om te weten, het liefste heb je je workload minder direct afhankelijk van volumes maar dat is niet iets wat je “ff” wegpoetst.

Wij draaien zelf op Azure AKS en hebben onze persistent storage alleen als managed services (db; postgres en mariadb en s3 buckets). Dat maakt ons een stuk flexibeler enerzijds maar ook dat we minder “keuze” hebben in leveranciers die omdat ze die managed services (nog)niet aanbieden.

Ik ben vooral blij dat we ons cluster niet meer zelf hoeven te beheren (of iig minder)

[Reactie gewijzigd door Tubby op 19 september 2024 12:34]

[Buitenaerts]

Wij gebruiken ook AKS voor ons platform werkt helemaal top, maar de grote partijen lopen gewoon voor op dit soort dingen. Ik zou zelf dan ook nooit onze productie naar TransIP, Leaseweb etc. durven te verplaatsen. We verwerken 24/7 orders en op piekmomenten meerdere per seconden. Denk niet dat onze klanten gelukkig gaan worden als het even niet werkt en de support niet bereikbaar is

[EnigmA-X]

Azure heeft geen "S3 buckets"

[Tubby]

i know, for the sake van onafhankelijkheid gebruiken we daar ook een andere leverancier voor.

Je zou t in je AKS cluster kunnen fixen door zelf MinIO te draaien en dat tegen hun Azure Blob storage praat, maar dat is weer werk en kan omvallen enzo

[Verwijderd]

Weet iemand waarom dit zoveel meer kost dan bijvoorbeeld deze arm vps ? https://www.netcup.com/en/server/arm-server

Ik kom bij de duurste optie van transip op 100 / maand terwijl die vps bij netcup (Duitsland) nog geen 7 euro per maand kost en je meer hardware krijgt.

[boba-fett]

Je krijgt andere hardware met nogal een cruciaal verschil, ARM of x86. Niet alle containers / applicaties draaien fatsoenlijk of performant onder ARM.

[Verwijderd]

10x zo'n ding is nog goedkoper, dus 60 cores, 80 GB ram en 2,5 TB ssd voor 70 euro ten opzichte van 1 van deze en 50 GB en hier staan de x86 servers, ook veel goedkoper: https://www.netcup.com/en/server/vps

[Reactie gewijzigd door Verwijderd op 19 september 2024 16:57]

[Tubby]

Er is een verschil tussen een VPS afnemen en een managed kubernetes cluster afnemen.

Als je het verschil niet nodig hebt dan zou ik zeker gewoon een VPSje doen bij hertzner oid

[magician2000]

Mijn ervaring met TransIP is dat support en stabiliteit al jarenlang achteruit gaan. De prijsstijgingen zijn ook nog eens niet mals te noemen tegenwoordig.

[yatogami28]

Wat wordt er precies bedoeld met nodes

[Zebby]

Ik mag niet meer wijzigen van Tweakers, maar we zijn een paar stappen verder.

Er is n.a.v. van mijn post contact opgenomen, waarna ik contact heb opgenomen via het TransIP contactformulier. Hierna is een meeting opgezet met 3 man vanuit Team Blue, waar onze problemen ook inhoudelijk zijn besproken. Hierna zijn er actiepunten opgezet voor fixes:
- Ophogen aantal volumes per node van 10 tot 15
- Fix omtrent geheugen op de nodes
We hebben een gratis upgrade gekregen voor de node tot bevestigt is dat dit het probleem verhelpt. Ook is er een compensatie gevraagd en goedgekeurd voor geleden schade.

Het is dus spijtig dat het lang heeft moeten duren, maar het contact en gedrag sindsdien zijn goed en worden gewaardeerd.

[Koen Hendriks]

Zijn er in nederland nog meer partijen die op deze manier Kubernetes aanbieden?

[Mellow Jack]

Kan ze nu even niet opnoemen maar er zijn steeds meer partijen die dit aanbieden. Incl storage wat het S3 protocol ondersteund.

[timselier]

Storage wat S3 protocol ondersteunt kan je ook zelf hosten (in Kubernetes) met b.v. MinIO (optioneel is er ook een Kubernetes operator beschikbaar).

[eborn]

Je bent dan alleen wel zelf verantwoordelijk voor die omgeving. Het voordeel van managed S3 storage (zoals DigitalOcean bijvoorbeeld met Spaces doet) is toch wel een stukje ontzorgen. Natuurlijk moet je backups aanhouden (mits het geen vluchtige data betreft), maar ik laat liever een leverancier S3 issues met nodes uitvogelen dan dat ik zelf problemen met Minio krijg in een productie omgeving en al mijn data weg is of langere tijd niet beschikbaar.

[servicedb]

Er zijn zat partijen die het aanbieden, maar eentje die gelijk naar boven schiet is Fuga (www.fuga.cloud).

[mobrockers]

Waar zie jij managed kubernetes staan in hun aanbod?

[Lord_Gaav]

Hier: https://fuga.cloud/services/emk/

[Tubby]

Ja, maar fuga heeft helaas geen managed database servers.

En ja die kun je in je eigen cluster runnen met een operator maar daar “win” je niet zo heel veel mee als je zoekt naar minder onderhoud

[samtoxie]

Gelukkig zijn die wel WIP! (Note: ik ben zelf een van de Engineers die dat aan het implementeren is)

[Tubby]

Fijn om te horen; voor de ondertiteling, vanuit mijn perspectief (software dev) bouw ik mijn app's als docker images en wil met met zo min mogelijk gedoe de ondersteunende services draaien. Vroeger draaide ik die dingen zelf (rancher, pg zalando operator, minio) maar dat is echt een functie op zichzelf op het goed bij te onderhouden.

De S3 buckets is al wel een service bij jullie en postgres heb ik jullie ook al wel over gehoord (stand op een software conf), als die er is wil ik het wel weer proberen. Heb een lichte voorkeur voor een Nederlandse leverancier

[bazzi]

Volgens mij oa leaseweb

[moonlander]

Managed Kubernetes in de Nederlandse Cloud https://directvps.nl

[Reactie gewijzigd door moonlander op 19 september 2024 09:30]

[bartcoppelmans]

Leaseweb beid vergelijkbare oplossingen aan. Maar je komt al snel uit bij AWS, Digital ocean, Google cloud en degelijke buitenlandse partije.

[ctrl-tab]

Azure AKS, west europe.

Mooie van AKS is dat ze een mooi ecosysteem.aan het bouwen zijn rondom AKS zodat je dat zelf niet hoeft te beheren (bv basis faciliteiten zoals external-dns, cilium networking, ArgoCD komt eraan).

[cornedor]

Biedt OVH niet zoiets aan? Of zitten hier nog belangrijke verschillen in?

https://us.ovhcloud.com/public-cloud/orchestration/

[Safihre]

Intermax / Guida

[kcRogue]

Alle grote partijen. Mijn werkgever beheert clusters in AWS, Azure & Google. Die zijn uiteraard rockstable.

[IceEyz]

De Nederlandse tak van Equinix biedt het zelfs op basis van Talos.

[RambOe]

Shock Media heeft zo'n dienst.

[octoheid]

Previder heeft KaaS (Kubernetes as a Service).

[Kun]

Scaleway

[BCC]

Google Nederland

[Barryke]

Ik heb geen vertrouwen in TransIp VPS performance, ik verwacht dat de kubernetes performance (als die er al is) snel oversold wordt en dus verdwijnt.

Ik beheer al lange tijd servers gehost bij TransIP , en ook bij CloudVPS en anderen voordat deze opgeslokt werden) door TransIP/TeamBlue.

Hetgeen mij blijft verbazen is dat er steeds minder service is, er steeds meer mis gaat, de customer panel steeds minder functioneert, de systemen en backups steeds trager werken, en dat de prijzen steeds sneller stijgen.

Een voorbeeldje:
Als ik in de TransIP customer panel op snapshot of backup klik, duurt het 30+ minuten, voorheen was dat enkele minuten. Het lijkt er op alsof ze nieuwe VPSen op alsmaar oudere visors en oudere hardware zetten.

[_Erikje_]

Hoe kan je een 4GB virtual machine now Performance noemen...

[BRAINLESS01]

De nodes zijn volgens de webhoster geschikt voor containerapplicaties die veel rekenkracht nodig hebben

Wat heeft geheugen met rekenkracht te maken?

[_JGC_]

Ze noemen het performance omdat de CPU cores fysiek uitgedeeld worden ipv shared. Ze hebben ook reguliere VPS'en, dan heb je het over BladeVPS met forse overcommit of PerformanceVPS met dedicated cores.
Het grote verschil in performance zit overigens op dit moment in de opslag, die is met NVME opslag fors sneller bij de PerformanceVPS.

[blorf]

Als het systeem full load haalt met alleen maar remote storage is het ook goed. Zelfs swappen op een netwerklocatie is wel te doen als je een 10Gbit lijn hebt.

[Microwilly]

Even serieus transip is toch veel te duur.

[impactftw]

Heeft Kubernetes nou zoveel voordeel voor een Agency bedrijf die voornamelijk corporate en e-commerce website's bouwen?

[xvilo]

Het hangt af van de schaal en complexiteit van de projecten. Kubernetes biedt voordelen als je veel microservices of complexe infrastructuur hebt die schaalbaar en automatisch beheerd moeten worden. Voor een agency dat voornamelijk websites bouwt, is het misschien overkill. Simpelere oplossingen zoals een traditionele VPS of platform-as-a-service (PaaS) zoals Heroku of Vercel kunnen vaak al voldoende zijn. Kubernetes wordt vooral nuttig als je behoefte hebt aan geavanceerd beheer van containers, hoge beschikbaarheid en schaalbaarheid.

Daarnaast hangt het er ook vanaf hoe flexibel je wilt zijn in je infrastructuur. Bij TransIP kun je Kubernetes nodes per uur afnemen, wat handig is als je tijdelijk extra capaciteit nodig hebt. Dit is bij hun VPS-product niet mogelijk, waarbij VPS per maand gaat. Kubernetes kan dus ook aantrekkelijk zijn als je veel fluctuerende workloads hebt en je alleen wilt betalen voor wat je gebruikt.

[Reactie gewijzigd door xvilo op 19 september 2024 21:53]