Kubernetes'e göre PaaS nasıl seçilir?
Yazar | Bram Dingelstad
Çevirmen | Crescent Moon, sorumlu editör | Guo Rui
Baş resmi | Visual China'dan CSDN indirmesi
Üretildi | CSDN (ID: CSDNnews)
Aşağıdaki çeviridir:
Hepimiz bu durumla karşılaştık: Birisi bir hata buldu, ancak bu genel bir yazılım hatası değil, hatta her zamanki anlamda bir hata değil Aslında bir personel sorunu: körü körüne davayı takip eden geliştiriciler.
Başlangıçta hata çok küçüktü. Ekibi yeni bir teknolojiyi benimsemeye veya projede yeni bir modül benimsemeye ikna ediyordu, ancak bunu bilmeden önce her yerde tuhaf projeler ve vahşi belgeler vardı ve sadece gerekli olduğunu iddia ediyordu. İş sorunlarınızı üç adımda çözün! Ancak, sorunu gerçekten çözmek için daha fazla çalışmaya ihtiyaç var gibi görünüyor.
Hepimiz bu durumla karşılaştık ve geçen yıl benzer durumlardan biri Kubernetes adlı bir projeydi. Bazı şirketler ve ekipler Kubernetes tarafından ezildi ve bazı şirketler henüz çukura girmedi. Orta zemindeyim, çukura girmeye hazır süper karmaşık bir sistem kurmaya yeni başlıyorum. Ancak ondan önce, basit, PaaS benzeri bir platformun Kubernetes üzerinde nasıl konuşlandırılacağını tanıtmak istiyorum.
Mükemmel PaaS benzeri platform arıyor
Nereden başlıyorsun Mükemmel bir yol olmalı, değil mi? Belki önce bir arama yapalım:
Hmm ... Açıkçası, k8s PaaS değildir. PaaS'ı PaaS olarak k8'leri kullanmak yerine PaaS'ın üzerine kurmak istiyorum.
Sonra ne yapmalıyım? Önce HackerNews'te inceleyin! Sonunda iyi bir makale buldum (https://hn.algolia.com/?dateRange=allpage=0prefix=falsequery=paas%20kubernetessort=byPopularitytype=story) ve ayrıca GitHub'da harika bir liste buldum ( https://github.com/ramitsurana/awesome-kubernetes).
Dikkatli bir araştırmadan sonra, bazı aday projeleri listeledim:
-
Knative
-
OpenFaas Bulut
-
Convox
-
Bahçe
-
Rio
Başka birçok alternatif proje var, denediğim bazı projeler, bazı projeler çok aktif değil, bazı projeler tabii ki büyük işletmeler için.
benim durumum
Durumum ne Basit bir Wordpress ile basit bir DigitalOcean damlacığı üzerinde bir e-ticaret web sitesi çalıştırmamız gerekiyor. Bir web sitesi oluşturmak için yalnızca basit bir bash betiği kullanılabilmesine ve yerel olarak bir test sunucusu oluşturulabilmesine rağmen, basit bir betik değil, endüstri standardı bir platform oluşturmak istiyorum. Komut dosyaları yazmak eğlencelidir ve kendi dağıtım yığınınızı oluşturmak çok uygundur, ancak standartları takip eden ve araçlar hakkında tek başına düşünmeniz gerekmeyen şeyler gerçekten istediğim şeydir.
Benim ihtiyaçlarım
Bu öğeleri bir k3s çöp sunucusunda test etmek istiyorum. k3s, İnternette doğrudan açığa çıkmak yerine DigitalOcean üzerindeki damlacığa işaret eden bir ters proxy'ye sahiptir. Başka bir deyişle, bu projelerin şirket içi dağıtımı desteklemesi gerekir.
Diğer bir gereklilik, projenin tamamen k8'lerden soyutlanması gerektiğidir. Başka bir deyişle, her zaman çok sayıda yaml dosyasıyla uğraşmak veya dümen çizelgeleri dağıtmak istemiyorum.Kendi uygulamam açısından düşünmek istiyorum ve her şey komut satırı üzerinden yapılabilir.
Tek bir cümleyle özetlemek gerekirse: Umarım her şey bir düğmeye basılarak yapılabilir.
Uygulamamızın birçok hareketli parçası vardır, bir kısmı sadece basit bir betiktir ve diğer kısmı oyun istemcisi için iletişim fonksiyonları sağlayan büyük ölçekli bir uygulamadır. Uygulamadan bağımsız olarak, platformumuzun çok sayıda farklı türde uygulamayı desteklemesi gerekir. Genellikle bu, Dockerfile aracılığıyla dağıtımı desteklemek anlamına gelir.
Çalıştırmayı planladığımız uygulamaların büyük çoğunluğu durum bilgisidir. Örneğin, Wordpress'in resimleri kaydetmek için bir yere ihtiyacı vardır. Uygulamadaki birçok resmin de saklanması gerekir. Bu nedenle, uygulama bir tür kalıcı depolama gerektirir.
Pek çok proje iyidir, ancak iyi bir proje ile harika bir proje arasındaki fark, toplum ve endüstri tarafından kabul edilmesidir. GitHub'da yalnızca üç kullanıcılı bir proje kullanmak, kendiniz bir bash betiği yazmaktan farklı değildir. Bir şeyi kırmanız veya herhangi bir yardıma ihtiyacınız olması durumunda, aktif bir topluluk desteğiniz olacaktır.
Eşyaların listesi
Knative
Knative bana başlangıçta harika bir deneyim yaşattı! Knative'i izledikten sonra Google'ın kendi PaaS'ı gibi bir platformu çalıştırabileceğimi öğrendim. K8'lerin Google tarafından yapıldığını düşünürsek, Knative projesi kesinlikle mükemmel! Ancak kurulum beklenenden biraz daha zor. Görünüşe göre kurmanın kolay bir yolu yok ve gelecekte bir risk olabilecek basitçe denemek imkansız. Belki de öyle düşünen sadece benim, belki Knative'i daha derinlemesine çalışmalıyım ama bu nedenle dikkatimi bir sonraki adaya çevirdim.
OpenFaaS Bulut
Kurulum çok kolaydır! Bu platformu yakında çalıştırabileceğim. Gereksinimlerimin çoğunu karşılayabilir, ancak görünen o ki, tam bir PaaS'ın kendisine değil, OpenFaaS'yi uygulamaya odaklanmış durumda. Sorunlarımızı çözmek için bu platformu nasıl kullanacağımı tam olarak anlamıyorum. Daha az bağlantılı bir proje kullanıyorsanız veya birçok küçük özelliğe sahipseniz, OpenFaaS kesinlikle en iyi seçimdir! Belki daha sonra bakabilirim ama şimdi bir sonraki adaya bakmaya karar verdim.
Convox
Convox çok iyi görünüyor! Birkaç eski Heroku mühendisi tarafından k8'ler temelinde inşa edildi. Hızla DigitalOpen'in k8s kümesine yerleştirdim. Geliştirici deneyimi harika! Ancak, projenin yerel dağıtımı desteklemediği görülüyor. Dahası, projenin topluluğu, yalnızca bazı ilk kullanıcılarla büyük görünmüyor. Proje iyi bilinmediğinden başka projeler seçtim.
Bahçe
Bu proje çok güzel. Küçük bağımsız bir şirket tarafından geliştirilen çok yaratıcı bir çözüm olduğu için hoşuma gidiyor. Kurulum çok basittir ve metodolojisi de k8'lerden türetilen çok iyi bir soyutlamadır, ancak proje ayrıca k8'leri yaml dosyaları gibi geleneksel bir şekilde kontrol etmenize de izin verebilir. Bu uygulamayı çok beğendim ve çok iyi çalışıyor! Komut satırı arayüzünün biraz kaba olduğunu fark etsem de, sonuçta küçük bir sorun ve sonunda çözülebilir.
Ama bir sonraki (ve son) projeye bakmaya karar verdim.
Rio
Bu proje tüm ihtiyaçlarımı karşılayabilir. Kullanımı kolay komut satırı arayüzü, k8s ile etkileşime gerek yok, dağıtım için Dockerfile kullanın. Ayrıca, diğer platformların uygulanmadığı veya uygulanmadığı uzun bir özellik listesi vardır. Rio, Rancher'dan türetilmiştir ve Rancher'in aktif topluluğundan çok fazla destek almış gibi görünüyor.
Rio'yu spam sunucumda kur
K3s örneğim için hızlı bir şekilde ters proxy'yi ve ardından Rio'yu kurdum.
GitHub'daki hızlı başlangıç kılavuzlarına göre kurulum çok basittir:
# Ters proxy'yi k3sssh -nNTL 6443'e ayarlama: localhost: 6443 damlacık # Riocurl -sfL'yi Yükleme https://get.rio.io | sh- # Örnek projectrio'yu çalıştırmak https://github.com/rancher/rio-demo çalıştırınBu kadar! Mevcut altyapımızın bu platforma bu kadar kolay taşınıp taşınamayacağını görmek için sabırsızlanıyorum.
Rio'nun varsayılan kurulumu onların rDNS servisini (on-rio.io'da bulunan) kullanmanıza izin veriyor, bu oldukça güzel, ancak ters proxy'nin arkasına koyduğum spam sunucusunun buna ihtiyacı yok. Linkerd'i hiç kullanmadım, bu yüzden bu özelliği geçici olarak devre dışı bıraktım. Yeniden yüklemek ve ihtiyacım olan sonucu almak için rio install --disable-feature rdns, letsencrypt, linkerd ifadesini kullanın.
Ardından, on-rio.io dışındaki alan adlarını kullanabilmem için özel bir ClusterDomain yüklemek için kubectl'i kullanın. Sonunda dnsmasq'ı kurdum ve uygulama kullanımı için sahte bir alan adı app.rio kurdum. Spam sunucusunda uygulamanın bağlantısını kolayca test edebilir.
apiVersion: admin.rio.cattle.io/v1kind: ClusterDomainmetadata: name: app.riospec: httpPort: 80Ayrıca bu kümeye DigitalOcean droplotumdan bağlanmanın bir yolunu bulmak istiyorum. Yöntemim, proxy sunucusunu istenmeyen posta sunucusunun 80 numaralı bağlantı noktasından damlacığın 8080 numaralı bağlantı noktasına ters çevirmektir. Rio, Gloo'nun ağ geçidi proxy'sini kurmak için 80 numaralı bağlantı noktasını kullanır.
Son adım, nginx yapılandırmasını Gloo ağ geçidini gösterecek şekilde ayarlamaktır:
server {listen 80; server_name alanınız.adınız; konum / {proxy_http_version 1.1; proxy_set_header Ana Bilgisayar $ ana bilgisayar; proxy_pass http: // localhost: 8080;}}Buradaki iki önemli nokta proxy_http_version 1.1 ve proxy_set_header Host'dur.
proxy_http_version çok önemlidir, çünkü Envoy tabanlı Gloo http__version 1.0'da ağ yönetim hizmetlerini desteklemez, sadece 1.1. Aksi takdirde 426 Yükseltme Gerekli hatası verir.
Host başlığı çok önemlidir çünkü PublicDomain uygulamasına ihtiyaç duyar. PublicDomain eklerken kilit nokta, ajanın server_name veya host başlığıyla eşleşmektir, aksi takdirde Gloo hangi hizmete bağlanacağını belirleyemez.
rio alan adınızı kaydedin. rio-demoYukarıdakiler, Kubernetes'e dayalı en uygun PaaS'ı keşfetme yolculuğum.
Okuduğunuz için teşekkürler!
Orijinal: https://bram.dingelstad.xyz/blog/finding-the-right-paas-for-k8s/
Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.
30 yıllık açık kaynak kargaşası: özgür bir topluluktan multi-milyar dolarlık bir şirkete
Yapay zekanın en büyük başarılarından birini anlayın: evrişimli sinir ağlarının sınırlamaları
GitHub, en iyi Apache projesi olan ShardingSphere'in açık kaynak yolu olan 10.000'den fazla yıldıza sahiptir
KongHong Kong Bilim ve Teknoloji Üniversitesi Akademisyeni Zheng Guangting geleceği sordu ve en son AI uygulamalarını ve uygulamalarını ortaya çıkardı
Büyük promosyon altında akıllı operasyon ve bakım zorluğu: Ali "çifte 11 kedi gecesine" nasıl direniyor?
Ethereum 2.0'da Saklama Oyunu ve MPC uygulaması
Sizler için çok dikkatli bir şekilde 9 MySQL mülakat sorusu yazdım, toplamanız tavsiye edilir!
