1 puan yazan GN⁺ 2024-12-02 | 1 yorum | WhatsApp'ta paylaş

Hetzner

  • Hetzner'a geçişin ana amacı maliyetleri düşürmekti. Hetzner'ın fiyatları küresel ölçekte rekabetçi.
  • Hetzner, sanal makineler ve bare metal makineler sunuyor; AWS'ye kıyasla daha sınırlı olsa da bunu fiyat avantajıyla telafi ediyor.
  • Hetzner'a geçişle birlikte altyapı maliyetleri %75'in üzerinde azaltıldı.

Kubernetes on Hetzner

Self-managed Kubernetes

  • Kubernetes, DigitalOcean üzerinde çalıştırılıyordu ve Hetzner'da da self-managed yaklaşımla işletiliyor.
  • Hetzner, yönetilen bir Kubernetes control plane sunmadığı için bunun doğrudan yönetilmesi gerekiyor.
  • Düğümleri yönetmek ve yapılandırmak için Terraform ve Puppet kullanılıyor.

Düğüm rolleri

  • Küme içindeki rolleri basit tutmak için düğüm adlandırma kuralı olarak control-plane, worker, database kullanılıyor.
  • Yeni rol eklemek kolay olsa da kaynak kullanım verimliliğini düşürebilir.

Düğüm kurulumları

  • Küme, Terraform kullanılarak bootstrap ediliyor.
  • Hetzner, yönetilen firewall ve ağ özellikleri sunuyor; bunlar Terraform ile kolayca yapılandırılabiliyor.
  • Sunucular tamamen Terraform ile yönetiliyor ve rol bazlı modüller yazılarak yeni sunucu eklemek kolaylaştırılıyor.

  • Düğümlere yönetim bağlantısı için Tailscale VPN kullanılıyor.
  • Tailscale, NAT hole punching sağladığı için portlar kapalı olsa bile güvenli bağlantı kurulabiliyor.
  • Portlar, Hetzner'ın yönetilen firewall'u ve Ubuntu'nun UFW'si ile kapatılıyor.
  • Container networking interface yapılandırması için Calico kullanılıyor.

Depolama

  • Hetzner, nVME SSD ve SSD tabanlı block storage sunuyor.
  • Hetzner volume'larında snapshot özelliği olmadığı için veri yedekleri manuel olarak alınmalı.
  • Veritabanı düğümlerinde yerel volume'leri önceden provision etmek için Local Persistence Volume Static Provisioner kullanılıyor.

Yedekleme

  • Hetzner, volume yedeği sunmuyor ancak tüm sunucu için yedekleme sağlıyor.
  • Namespace ve PVC yedekleri için VMware'in Velero aracı kullanılıyor.
  • Postgres için pgBackRest kullanılıyor.

Ek özellikler

  • Gizli bilgileri yönetmek için SealedSecrets kullanılıyor.
  • Küme izleme için Node Exporter, Prometheus, Grafana ve Loki kullanılıyor.
  • Slack ile bildirim entegrasyonu için Alertmanager kullanılıyor.

Hetzner'da Kubernetes işletmeye dair düşünceler

  • Hetzner'a geçiş yaklaşık 1 hafta sürdü; ek test ve ince ayar için 4 hafta daha gerekti.
  • Hetzner'ın fiyatları makul ve diğer sağlayıcılara göre düşük kalmaya devam edeceğine inanılıyor.
  • Hetzner'da IP kalitesiyle ilgili sorunlar ve müşteri hizmetleri tarafında bazı sınırlamalar bulunuyor.
  • Hetzner yeni özellikleri hızlıca sunuyor, ancak kârlılığı düşük hizmetleri de hızlı biçimde sonlandırabiliyor.
  • Orta Avrupa veri merkezleri Almanya'da Falkenstein, Nuremberg ve Finlandiya'da Helsinki'de bulunuyor.

Özet

  • Bu geçiş sorunsuz ilerledi; altyapı maliyetleri %75'in üzerinde azaltılırken kümenin hesaplama kaynakları iki katına çıkarıldı.
  • Maliyet düşürmenin gerekli olduğu durumlarda Hetzner çok avantajlı bir seçenek.
  • Hetzner'ın açık kaynak denetleyicileri, load balancer yönetimini ve kalıcı volume bağlamayı kolaylaştırıyor.

1 yorum

 
GN⁺ 2024-12-02
Hacker News yorumları
  • Birkaç yıldır Hetzner dedicated server’ları üzerinde müşterilere Kubernetes cluster’ları sunuyoruz; performans kesinlikle çok iyi görünüyor, genelde istek süreleri yaklaşık yarıya düşüyor.
    Donanım ucuz olduğu için her müşteri için özel DevOps mühendislik zamanı da ayırabiliyoruz; ancak bazı ön koşullar var. Güncelleme testleri için bir staging cluster’ı fiilen şart ve production güncellemelerini pazar günü içgüdüyle zorlayarak yapmak kimsenin isteyeceği bir şey değil. En önemlisi uygulama seviyesinde replikasyon, ardından blok seviyesinde replikasyon geliyor; bunun için OpenEBS/Mayastor kullanıyoruz. Birkaç Postgres operatörü denedikten sonra şu anda StackGres’in en iyisi olduğunu düşünüyorum.
    Ansible playbook’ları bir varlıktır; belirli bir hizmet için iyi düzenlenip yorum satırlarıyla açıklanırsa ileride aynı hizmeti başka bir yere yeniden dağıtmak kolaylaşır. Mümkünse sunucuları bağlamak için özel bir 10G ağ öneririm. 1G, production trafiği, image pull’ları ve servisler arası trafik birleştiğinde yetersiz kalıyor; AWS gibi yerlerdeki availability zone içi iletişime göre gecikme süresi 10 kat iyileşiyor.
    Ağ yedekliliği gerekiyorsa 1G port üzerinde dahili kullanım için 1G vSwitch (VLAN) oluşturup her sunucuya loopback IP vererek rotaları BGP ile dağıtabilirsiniz (bird). MinIO cluster’ı operatör üzerinden usulüne uygun işletildiğinde çok zor değil ve yerel, yüksek bant genişlikli/düşük gecikmeli object storage sağlıyor. İlk yatırım için kesintiye uğramayan 2–4 ay kadar deneyimli mühendislik zamanı gerekiyor; HTTP load balancing gibi yardımcı ve can sıkıcı işleri ise hâlâ CloudFlare gibi cloud sağlayıcılarına devredebilirsiniz.

    • “Sunucuları bağlamak için özel 10G ağ”ın Hetzner’den ayrıca talep edilmesi gerekip gerekmediğini merak ediyorum.
      Açık dokümantasyonda 10G uplink seçeneği var ama bu dış ağ için ve 20 TB sınırı epey sıkı görünüyor. Dahili cluster I/O’su söz konusuysa 20 TB kolayca sorun olabilir.
    • 1G vSwitch, loopback IP ve BGP (bird) ile ağ yedekliliği kurma kısmı için örnek yapılandırma paylaşabilir misiniz, merak ediyorum.
    • 2–4 aylık ilk mühendislik yatırımı gerekiyorsa https://syself.com da bakmaya değer.
      O şirkette çalışıyorum ve dakikalar içinde production’a hazır cluster sağlayan bir platform geliştirdik.
    • Kesintisiz 2–4 aylık deneyimli mühendislik zamanının şirket veya müşteri için ne kadar değerli olduğunu, önümüzdeki 5 yıl boyunca daha yüksek aylık faturalar ödemekle karşılaştırmak gerekir.
      Bir danışmanlık şirketiyseniz bu işi satmak isteyebilirsiniz; ama müşteri açısından aylık AWS maliyetinin 10 bin dolar civarında olması beklenmiyorsa hiç de değerli görünmüyor. Aklıma xkcd geliyor: https://xkcd.com/1319/.
  • Hetzner dedicated server’larında Kubernetes cluster’ı işlettim; Aurora, S3, ECS Fargate gibi tamamen veya yüksek ölçüde yönetilen servislerle de çalıştım.
    Deneyimime göre Hetzner’ın cloud faturası eşdeğer AWS’ye kıyasla bazen %20 seviyesine kadar düşebiliyor; ancak bu maliyet avantajı büyük tavizlerle geliyor.
    Hetzner Kubernetes üzerinde NVMe depolama tabanlı Ceph cluster’ı, MariaDB operatörü, networking için Cilium ve Helm chart dağıtımı için ArgoCD yönettim. Kubernetes cluster güncellemelerini de kendimiz yapmak zorundaydık ve bir kez tüm cluster’ın devre dışı kaldığı bir arıza yaşadık. Hem Kubernetes hem de Ceph tarafında birkaç bug ile karşılaştık; bunların çoğu GitHub issue’larında ve Ceph tracker’da kayıtlıydı. Yönetilmesi ve izlenmesi gereken iş listesi bitmek bilmiyordu; workload sayısı ve ortamın karmaşıklığına bağlı olarak böyle bir kurulumu sürdürmek bir DevOps ekibinin tam zamanlı işi hâline gelebilir.
    Buna karşılık AWS veya diğer büyük cloud sağlayıcıları kullanıldığında çok daha az müdahale gerektiren bir kurulum mümkün. Yönetilen servisler bakım çabasını ciddi biçimde azaltır ve ekibin operasyon yükünü düşürür. Sonuçta AWS, DevOps iş yükünü büyük ölçüde azaltır; Hetzner ise cloud faturasını ciddi biçimde düşürür. Hangisinin daha maliyet etkin olduğunu anlamak için toplam sahip olma maliyeti (TCO) analizi gerekir; Hetzner başlangıçta ucuz görünse de ek DevOps zamanı tasarrufları ortadan kaldırabilir.

    • Bu epey ChatGPT çıktısı gibi görünüyor; önceki yazım geçmişinde de “X iken Y de Z yapar. Y zaten X ile örtüşür” gibi cümleler çok.
      Örnek olarak 2 vCPU, 4 GB yapılandırmayı AWS’deki benzer bir yapılandırmayla karşılaştırınca AWS çok daha pahalı; maliyet analizini görmek isterim. Operasyon yükünü azaltmaya yönelik araç olarak https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner de var.
    • Destek sorunlarını yeniden üretmek için kullandığım oyuncak geliştirme cluster’ı dışında Kubernetes cluster’ı işletmişliğim yok; ama bir gün sertifika sorunu yüzünden bozuldu.
      Kök nedeni bulmak da kolay değildi; internette kurtarma için gereken büyü gibi komutlar çoktu ama ben hepsini silip cluster’ı yeniden oluşturdum. Sonrasında bunu birkaç haftada bir yapmaya başladım. Gerçek bir Kubernetes operatöründe sertifika otomatik yükseltme ve başka birçok araç olurdu; bir şirketin de böyle bir operatöre para ödemesi gerekir gibi geliyor.
    • Ceph işletmek gerçekten eziyetli. Pahalı, yavaş ve hâlâ tam hazır hissettirmiyor.
      Kullanan yerler olduğunu biliyorum ama Lustre veya GPFS gibi olgun sistemlerle karşılaştırınca muazzam bir zaman kaybı oluyor. Bunun yerine birkaç küçük dosya sistemini NFS olarak dışa açıp blok seviyesinde replikasyonu garanti etmek daha iyi. Tek adres alanlı dosya sistemi kullanışlıdır; ancak büyük ölçekte güvenilir hâle getirmek için gereken yönetim maliyetine çoğu zaman değmez. Veritabanı sharding’i gibi dosya sistemlerini de shard’layın; Kubernetes’te doğru image’a doğru storage’ın bağlanmasını sağlayacak eşleme mantığını kolayca ekleyebilirsiniz.
    • Genel olarak katılıyorum ama OpenShift gibi orta yol çözümlerin sıkça değerlendirilmemesi şaşırtıcı.
      DevOps yükünü çok azaltırken bare metal’in hem performansını hem esnekliğini elde edebilirsiniz. Tam yönetilen pahalı servislerle tamamen kendi kurduğunuz yapı arasında harika bir hibrit. Maliyeti epey olduğundan startup’lar için iyi bir seçenek olmayabilir; ancak 72 GB RAM veya 36 CPU ve üzeri, yaklaşık 9 orta boy node’luk bir cluster için OpenShift gibi bir şey mutlaka değerlendirmeye değer.
    • Kubernetes cluster’ını elle güncellemek çok büyük bir taviz. Birkaç kuruş tasarruf etmek için bunu yapmak, çaresiz bir durumda değilseniz hayal etmesi zor bir şey.
  • Hetzner volume'lerinin üretim veritabanları için fazla yavaş olması sorunu şaşırtıcı derecede kolay çözülebilir. Çok ucuz Hetzner bare-metal makineleri node olarak kullanmak yeterli
    NVMe depolamalı makinelerde veritabanı performansı harikadır ve çoğu zaman RAM de bol olur. Hatta Kubernetes üzerinde veritabanı çalıştırmak yerine, master-replica yapılandırması için iki veya daha fazla sağlam bare-metal makine bulundurmak daha iyi olabilir. Kurulum zahmetliyse Pigsty gibi modern paketler kullanılabilir: https://pigsty.cc/

    • Kubernetes'te yerel NVMe depolama kullanarak veritabanı işletmek için de çok seçenek var
      Veritabanı pod'larını belirli node'lara sabitleyip LocalPathProvisioner kullanabilir ya da JuiceFS, OpenEBS gibi dağıtık çözümlerden yararlanabilirsiniz
    • Bare-metal sunucuların yerel depolamasını kullanarak iyi deneyimlerim oldu
      Bir müşteri için yazdığım rehber burada: https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal
  • 10 yılı aşkın süredir Hetzner'i memnuniyetle kullanıyorum; eskiden Almanya veri merkezlerindeki dedicated server'ları kullanıyordum, sonra ABD gecikmesini azaltmak için Cloud US VM'lere geçtim
    Yakın zamanda cömert 20 TB ücretsiz trafik hakkının 3 TB'a düşürülmesi ve ek TB başına €1,19 olması biraz hayal kırıklığı yarattı; ancak değerlendirdiğim diğer ABD bulut sağlayıcılarına kıyasla hâlâ çok daha iyi fiyat/performans sunuyor gibi görünüyor
    Kubernetes'i özellikle seçmezdim ama mevcut SSH/Docker Compose dağıtımlarını GitHub Actions ve kamal-deploy.org'a taşıdım ve başarıyla kullanıyorum. Kurulumu kolay, uzaktaki dağıtılmış uygulamaları izlemek için UX araçları da iyi: https://servicestack.net/posts/kamal-deployments

    • Bu ABD tarafına özgü bir sorun gibi görünüyor; muhtemelen peering partner'ları fiyat artışı için baskı yapıyor olabilir
      Almanya veri merkezleri hâlâ 20 TB bant genişliği sunuyor: https://www.hetzner.com/cloud/
      Ancak ABD'de aynı fiyata tek haneli TB seviyesinde, yani çok daha az veriliyor
  • Eskiden para tasarrufu sağladığı ve eğlenceli olduğu için araba bakımını kendim yapardım; ama sandığımdan daha karmaşıktı ve zamanla orası burası bozuldu ya da kırıldı
    “Yeniden düzeltmeye” çok zaman harcadım ve birkaç yıl içinde aletlere muhtemelen binlerce dolar harcadım. Ucuz aletlerin kırılması veya hızla paslanıp değiştirilmesi de maliyetti; araba da sık sık krikoların üzerinde dururdu. Yine de çok iyi dersler çıkardım; en büyük ders, bazı işleri kendin yapmaya değmediğiydi. Geçiminiz buna bağlıysa bir tamirciye bırakmak ya da arabayı leasing ile almak daha iyi
    Yağ değişimi gibi basit işler bile çoğu zaman kendin yapmaya pek değmez. Yağ toplama kabı, filtre anahtarı, huni, servis tahtası gibi aletler almak; zaman ayırmak; kirli iş kıyafetlerini bulmak; mağazaya gidip yeni yağ ve filtre almak; eve dönüp değişimi yapmak; sonra aynı gün ya da başka bir gün atık yağı kabul eden bir dükkâna gitmek gerekir. Oysa serviste, yağ ve filtre maliyetinin yaklaşık 15 dolar fazlasını ödeyip 20 dakikada işinizi bitirirsiniz
    Kubernetes komple bir araba gibidir, üstelik karmaşık bir araba. Bunu eğlence için yapmıyorsanız, kendi başınıza bakımını yapmaya gerçekten değmez

    • Emin değilim. Servis fren değişimi için 1800 dolar istedi, ama parçaları 300 dolara alıp ilk kez yapmama rağmen bir günde bitirdim
      Oldukça iyi bir karşılık ve öğrenmeye değer bir beceri. Komşumda araç lifti olması kesinlikle yardımcı oldu
    • Her şey için AA'yı aramak ve her seferinde tanınmış bir servise gitmek bütçenin büyük bir kısmını oluşturuyorsa durum değişir
      Asıl mesele, hangi işleri kendiniz yapacağınız ile hangilerini dışarı vereceğiniz arasında denge bulmak; bu da burada anlatıldığı kadar kolay veya tertemiz değil
    • Sonuçta iki şeye bağlı: Şu anda ve gelecekte ne kadar ilgi ve motivasyonunuz olduğu, bir de üçüncü taraf bağımlılıklarının uzun vadede sizi ne kadar yavaşlatma ihtimali bulunduğu
      Kubernetes'le sık sık çalışan bir danışman açısından, başlangıçta yardım ve devam eden destek için bir kanal oluşturmak; ama içeride de yeterince ilgili birinin birlikte öğrenmesi daha iyi
      Danışmanlar ve uzmanlar başlangıçta kötü kararlardan kaçınmanızı sağlayabilir ve aylarca duvara kafa vurmanızı azaltabilir. Aynı zamanda ana işe de odaklanmanız gereken bir durumda, teknolojinin veya ekosistemin yaygın karanlık köşelerini ve tuzaklarını makul sürede öğrenmek kolay değildir. Yardım alın; ama balık tutmayı ve ateş yakmayı da öğrenin
  • İlginç bir yazı, ancak küme ve üzerinde çalışan iş yüklerinin açıklaması eksik gibi
    Kaç node var, ne kadar trafik alıyor, çalışma süresi ve gecikme gereksinimleri neler merak ediyorum. Ayrıca mutlak maliyet tasarrufu da önemli. Aylık 100 bin doların %75'ini tasarruf etmek ile aylık 100 doların %75'ini tasarruf etmek tamamen farklı şeyler

    • Deneyimime göre GPU kullanmıyorsanız ya da zaten aylık 100 bin dolar harcamıyorsanız kimse umursamıyor
      Gerçekten de aylık 100 bin doların eşik olduğunu düşünüyorum. Yıllık 1,2 milyon dolar eder
      Gelişmiş bir bare-metal dağıtımı düzgün desteklemek için mühendis maaşı olarak yılda yaklaşık 400 bin dolar gerekir; veri merkezi taahhütleri, donanım amortismanı ve bant genişliği için de kabaca yılda 100 bin dolar gider. Bu tür kişiler genellikle bu işi yaparken işletmenin diğer bölümlerine de ciddi değer sağladığından gerçek maliyet daha düşük olabilir. Böylece yılda 700 bin dolar tasarruf edersiniz; bu harika, eşdeğer bulut harcaması bunun üzerine çıktıkça avantaj çok daha büyür
  • 10 yılı aşkın süre önce web hosting alanında çalışırken, kötüye kullanım nedeniyle Hetzner IP’lerini sürekli blackhole ederdik.
    Diğer düşük maliyetli VM sağlayıcıları için de durum aynıydı; coğrafi veritabanlarıyla ilgisi yoktu, tamamen davranış kaynaklıydı. Ucuz olmasının bir nedeni var.

    • Birkaç yıl önce Mailgun’ın ücretsiz katmanını kullanmaya çalıştığımda aynı sorunu yaşamıştım.
      Ürün özellikleri hoşuma gitmişti ama ücretsiz katman IP’lerinin itibarı berbattı; özellikle Hotmail veya Yahoo tarafında e-postalar neredeyse hiç kabul edilmiyordu. Ücretsiz hosting hizmetleri spam gönderenler ve dolandırıcılar tarafından istila ediliyor; düşük maliyetli hizmetler de sadece biraz daha az olmak üzere benzer. Fiyat yükseldikçe dolandırıcılık ve spam için daha az kullanılıyor.
    • Durum sürekli değişiyor ama bugünlerde barındırdığım sitelere en çok saldırı gelen platformlar büyük bulut sağlayıcıları, özellikle de Azure.
      AWS, Google, DigitalOcean, Linode, Contabo vb. de çok sayıda oturum açma brute-force denemesi ve yaygın açık tarama saldırısına ev sahipliği yapıyor.
    • AWS, herkese açık IP’lerinin engelleme listelerine girmemesi için ciddi biçimde uğraşıyor.
    • Mantıklıysa backend’i Hetzner’da tutabilirsiniz. Örneğin kuyruklar veya batch işleyiciler buna girer.
    • hcloud üzerinde k8s depolarında kara listeye alınmamış bir floating IP elde edene kadar birkaç tane denemem gerekti.
  • Şirketlerin altyapı kurulumu ve güvenliğine yardımcı olan bir danışmanlık şirketinde çalışıyorum; Hetzner gibi düşük maliyetli sağlayıcılarda, bölgesel orta seviye sağlayıcılarda ve AWS/GCP/Azure gibi ilk üç bulutta Kubernetes çalıştıran çok müşterimiz var.
    Kamu bulutunda çalışamayan veya çalışmak istemeyen kamu, finans ve sağlık şirketleri de var; bunlar genelde on-premise barındırılıyor.
    Hetzner’da ayda bir sorun ya da arıza görüyorsak, orta seviye sağlayıcılarda bu 2-3 ayda bir, AWS gibi yerlerde ise 5-6 ayda bir oluyor. Ancak fiyatlar da bu gözleme benzer şekilde hareket ettiğinden, ek donanım, yedekleme ve arıza senaryoları eklemenin daha iyi bir anlaşma olup olmadığını her vaka için dikkatle değerlendirmek gerekiyor.
    Temel hosting hizmetleri kullanmanın büyük avantajı, fiyat öngörülebilirliğinin çok daha yüksek olması. Donanım maliyetini ödeyip ihtiyaç duyduğunuz kadar ölçeklersiniz. AWS gibi sağlayıcıların ek hizmetlerine bağlanırsanız beklenmedik derecede büyük faturalarla karşılaşabilir ve çıkmanız da çok daha zor olabilir. Küçük bir şirketseniz, başta kolay çözümlere veya “ücretsiz kredilere” kapılıp uzun vadeli hayatta kalma kabiliyetinizi tehlikeye atan kısa vadeli kararlar vermemek iyi olur.
    Burada doğru cevap yok, yalnızca ödünleşimler var.

  • Kendim kullanmadım ama https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner Hetzner’da Kubernetes kurup yönetmek için harika bir yol gibi görünüyor.
    Şu anda Oracle ücretsiz katmanını kullanıyorum ama Oracle’dan uzaklaşmak için sürekli buraya geçmeyi düşünüyorum.

    • Bununla iki cluster çalıştırıyorum; biri production, biri geliştirme için.
      Gayet iyi çalışıyor. SuSE MicroOS üzerinde otomatik güvenlik güncellemeleri için makineleri her pazar yeniden başlatacak şekilde zamanlama da koydum. Workload artışına göre makine ölçeklemeyi de denedim. Terraform’ın yapmak istediği tüm değişiklikleri mutlaka gözden geçirmek gerekiyor; bunu yaparsanız oldukça güvenli.
      Tek dezavantajı, tüm node’lar firewall arkasında olsa bile public IP gerektirmesi; bunun üzerinde çalışılıyor.
    • Bunu kullanarak kendi kullandığım günlük tutma sitesi için bir cluster kurdum.
      Bir gecede cluster çalışır hale geldi ve oldukça iyi işliyor. Küçük bir sorun, arm node’da otomatik güncellemenin çalışmamasıydı; o sırada yalnızca tek node çalışıyordu ve control plane taint’i yüzünden update pod’u çalışamadığı için takılı kaldı.
    • Cluster API ve Cluster API Provider Hetzner da kullanıyorum.
      https://github.com/syself/cluster-api-provider-hetzner
      Çok kararlı çalışıyor.
    • Geçenlerde Oracle ücretsiz katmanında k8s çalıştırmakla ilgili bir yazı okudum ve denemeyi düşünmüştüm.
      Taşınmak istemenize yol açan somut bir rahatsızlık olup olmadığını merak ediyorum.
  • DigitalOcean’ın diğer sağlayıcılar gibi ücretsiz managed control plane sunduğu, ancak managed cluster node’larına genellikle %100 markup koyduğu sözüne katılmıyorum.
    DigitalOcean’da worker node maliyeti normal Droplet ile aynı ve ek ücret yok. Bu yüzden DigitalOcean’ın sunduğu model oldukça cazip. Dert etmeniz gerekmeyen ücretsiz control plane, ücretsiz yükseltmeler, load balancer ve storage gibi ek entegrasyonlar var. Bunu kendi kendine yönetilen bir seçeneğe tercih etmemek için pek bir neden aklıma gelmiyor.

    • Gerçek node’lar yine de DigitalOcean’da Hetzner’a göre çok daha pahalı. Ana sebep muhtemelen bu.
      Hetzner’ın 8 GB RAM paylaşımlı CPU’su yaklaşık 10 dolar, DigitalOcean’daki muadili ise 48 dolar.
    • czhu12’nin söylediklerine ek olarak, DOKS’un yüksek erişilebilirlikli control plane için ek ücret alması platformu production sınıfı değilmiş gibi hissettiriyor.
      Hetzner’da managed deneyim istiyorsanız https://syself.com adresine bakabilirsiniz. O şirketin çalışanıyım.