Kubernetes ve CloudFoundry [kapalı]

CloudFoundry / Diego'nun bir sonraki sürümü, birden çok ana bilgisayarda [ link ] düzenlenecek Docker kapsayıcıları için yerel destek sunacak . Bu Kubernetes'e çok benziyor.

Elbette, Kubernetes'in çözmeye çalıştığı sorun daha genel bir sorundur; burada CloudFoundry daha çok uygulama geliştirmeye odaklanır. Ancak, benim için her ikisi de benzer bir yöne doğru ilerliyor ve CloudFoundry düz orkestrasyonun üstüne çok daha fazla özellik ekliyor.

Bu yüzden Kubernetes'in CloudFoundry'den daha fazla değer katacağı kullanım durumlarını merak ediyorum.

Hem bir CloudFoundry (geçmiş) hem de Kubernetes (şimdiki) işleyicisi olarak, muhtemelen bunu yanıtlamak için benzersiz bir şekilde nitelikliyim.

PaaS benzeri

CloudFoundry'ye "Uygulama PaaS" ve Kubernetes'e "Konteyner PaaS" demeyi seviyorum, ancak her iki projenin de aynı pazarlarda rekabet edecek şekilde zamanla değiştiği göz önüne alındığında, ayrım oldukça ince ve akıcı.

İkisi arasındaki fark, CF'nin bir (12 faktörlü) kullanıcı uygulamasını (örneğin, jar veya mücevher) ve Heroku tarzı bir yapı paketini (örneğin Java + Tomcat veya Ruby) alan ve bir damlacık üreten (bir Docker görüntüsü). CF, konteynerleştirme arayüzünü kullanıcıya ifşa etmez, ancak Kubernetes bunu yapar.

seyirci

CloudFoundry'nin birincil hedef kitlesi, Heroku tarzı derleme paketlerini kullanarak 12 faktörlü durum bilgisiz uygulamaları dağıtmak isteyen kurumsal uygulama geliştiricileridir.

Kubernetes'in izleyici kitlesi, hem durum bilgisi olmayan uygulama hem de kendi konteynerlerini sağlayan durum bilgisi olan hizmet geliştiricileri dahil olmak üzere biraz daha geniştir.

Bu ayrım gelecekte değişebilir:

• CloudFoundry, docker görüntülerini kabul etmeye başlayabilir ( Lattice, Docker görüntülerini kabul eder ).
• Kubernetes bir görüntü oluşturma katmanı ekleyebilir ( OpenShift böyle bir şey yapar ).

Özellik Karşılaştırması

Her iki proje olgunlaştıkça ve rekabet ettikçe, benzerlikleri ve farklılıkları değişecektir. Öyleyse aşağıdaki özellik karşılaştırmasını bir tuz tanesi ile yapın.

Hem CF hem de K8'ler, kapsayıcıya alma, ad alanı, kimlik doğrulama gibi birçok benzer özelliği paylaşır.

Kubernetes'in rekabet avantajları:

• Bağımsız olarak ölçeklemek yerine, bir ağ yığınını paylaşan kapsayıcıları gruplayın ve ölçekleyin
• Kendi konteynerinizi getirin
• Durum bilgisi olan direnç katmanı
• Daha büyük, daha aktif OSS topluluğu
• Değiştirilebilir bileşenler ve 3. taraf eklentilerle daha genişletilebilir mimari
• Ücretsiz web GUI

CloudFoundry'nin rekabet avantajları:

• Olgun kimlik doğrulama, kullanıcı gruplaması ve çoklu kiracılık desteği [x]
• Kendi uygulamanızı getirin
• Dahil olan yük dengeleyici
• BOSH [x] tarafından konuşlandırıldı, ölçeklendi ve canlı tutuldu
• Sağlam günlük kaydı ve metrik toplama [x]
• Kurumsal web GUI [x]

[x] Bu özellikler Diego'nun parçası değildir veya Lattice'e dahil değildir.

yayılma

CloudFoundry'nin rekabet avantajlarından biri, temel CF bileşenlerinin ölçeklendirilmesi, yeniden canlandırılması ve izlenmesi gibi özellikleri etkinleştiren olgun bir dağıtım motoruna (BOSH) sahip olmasıdır. BOSH ayrıca, takılabilir bir bulut sağlayıcı soyutlamasına sahip birçok IaaS katmanını destekler. Ne yazık ki, BOSH'un öğrenme eğrisi ve dağıtım yapılandırma yönetimi kabus gibi. (Bir BOSH sorumlusu olarak bunu doğru bir şekilde söyleyebileceğimi düşünüyorum.)

Kubernetes'in dağıtım soyutlaması henüz emekleme aşamasında. Çekirdek depoda birden çok hedef ortam mevcuttur, ancak hepsi çalışmıyor, iyi test edilmiyor veya birincil geliştiriciler tarafından desteklenmiyor. Bu çoğunlukla bir olgunluk meselesi. Bunun zamanla gelişmesi ve soyutlamada artması beklenebilir. Örneğin, DKG üzerinde Kubernetes varolan için Kubernetes dağıtma sağlayan DKG tek komutla küme.

Tarihsel Bağlam

Diego, CF's Droplet Execution Agent'ın yeniden yazımıdır. Başlangıçta Kubernetes duyurulmadan önce geliştirildi ve rekabet ortamı geliştikçe daha fazla özellik kapsamına girdi. Asıl amacı damlacıklar (kullanıcı uygulaması + CF buildpack) oluşturmak ve onları Warden (Go'da yeniden yazıldığında Garden olarak yeniden adlandırıldı) konteynerlerinde çalıştırmaktı. Başlangıcından bu yana, bir miktar CloudFoundry-lite olan Lattice olarak yeniden paketlendi (bu ad mevcut bir proje tarafından alınmış olsa da)). Bu nedenle, Lattice, kullanıcı kitlesini ve kapsamını kasıtlı olarak azalttığı ve onu "girişimciliğe hazır" hale getirecek özellikleri açık bir şekilde kaçırdığı için biraz oyuncağa benzer. CF'nin zaten sağladığı özellikler. Bunun nedeni kısmen, Kafesin daha karmaşık CF'den gelen ek yüklerin bir kısmı olmadan çekirdek bileşenleri test etmek için kullanılmasıdır, ancak Lattice'i güvenlik ve çoklu kiracılığın çok da önemli olmadığı dahili yüksek güven ortamlarında da kullanabilirsiniz. .

CloudFoundry ve Warden'ın (konteyner motoru) da Docker'dan birkaç yıl önce geçtiğini belirtmek gerekir.

Kubernetes ise, Google tarafından BORG ve Omega ile yıllarca konteyner kullanımına dayalı olarak geliştirilen nispeten yeni bir projedir. Kubernetes, Google'da 3. nesil kapsayıcı düzenlemesi olarak düşünülebilir, aynı Diego, Pivotal / VMware'de 3. nesil kapsayıcı düzenlemesi olarak düşünülebilir (VMware'de v1; Pivotal Labs yardımı ile VMware'de v2; projeyi devraldıktan sonra Pivotal'de v3) .

Cloud Foundry, her zaman önerildiği / önerildiği için teklifin kısıtlamaları dahilinde çalışmaya istekli olduğunuzu varsayan harika bir araçtır. Web kullanıcı arayüzü ilk güne bakmak için harikadır ancak istemciyle çalışmaya başladıktan ve CI / CD ardışık düzeninizi yapılandırdıktan sonra nadiren kullanılır. Cloud Foundry'de tamamen desteklenmeyen kullanım durumları açılana kadar Cloud Foundry'nin harika olduğunu gördüm. Bu kullanım durumlarını sunmak, bu sorunları çözmeye çalışırken projeleri geciktirebilir; bunun sonucunda altyapının görünürlüğünü kaybedersiniz ve daha sonra çoğunlukla Cloud Foundry dışında çalışan bileşenlerin avantajlarını desteklersiniz (birden fazla veritabanı, kafka, hadoop, cassandra düşünün) , vb.) Zamanla Docker'ı çevreleyen ivmenin ve Cloud Foundry'nin esnekliğinin kullanıcıları Kubernetes'e çekeceğinden şüpheleniyorum, Mesos veya Docker Swarm / Veri Merkezi. Cloud Foundry'nin bu üçünü yakalaması mümkündür, ancak bu açık kaynaklı projelerin popülaritesi nedeniyle pek olası görünmemektedir.

Bir şirketin neden büyük ölçüde başka bir ürüne benzeyen bir ürün ürettiğini cevaplamak zor. Bir çok sebep var. Belki çoktan kullanmaya başladılar ve yatırım yaptılar. Belki onlar (CF) Kubernetes'in kötü yapıldığını veya API / model / ayrıntıları yanlış aldığını düşünüyorlar. Belki katkıda bulunmaktansa tüm ürünü kontrol ederlerse daha hızlı hareket edebileceklerini düşünüyorlar.

Kabul ediyorum, bunu bir Kubernetes geliştiricisi olarak söylüyorum - Kubernetes ile Mesos, Amazon ECS ile Kubernetes veya Docker Swarm ile Kubernetes arasında aynı sorular sorulabilir.

Umarım zamanla hepimiz aynı yönde trend oluruz ve daha fazla işbirliği yapabilir ve birbirimizin işini yeniden icat etmek için daha az zaman harcayabiliriz.

Kubernetes'e gelince - odak noktası uygulama geliştiricileridir: uygulamaları çok hızlı bir şekilde geniş ölçekte oluşturmanıza ve dağıtmanıza olanak tanıyan basit ve güçlü temel öğeler. Rotamızın çizelgesini çizmek için benzer teknolojilerle ilgili deneyimlerimize (Google'dan) güveniyoruz. Diğer insanların farklı deneyimleri veya fikirleri olacaktır.

Bence önemli bir fark, benimsedikleri yaklaşım:

CF, çalışma zamanını 3 bileşenden otomatik olarak oluşturur: kullanıcı tarafından sağlanan uygulama ikilisi, uygulamayı çalıştırmak için gerekli ara yazılımı içeren derleme paketi ve bir işletim sistemi görüntüsü (bir kök hücre). CF kullanıcısı (bir geliştirici) yalnızca uygulama ikili dosyası (örneğin, çalıştırılabilir bir jar dosyası) sağlamalıdır. CF geri kalanı, yani uygulamayı paketleme ve çalıştırma ile ilgilenir.

Kubernetes, halihazırda yerleşik olan ve çalıştırılmaya hazır ara yazılım ve işletim sistemi içeren bir geliştirici Docker görüntülerini bekler. Bunun için, Kubernetes "dağıtım bildirimi" (örneğin bir Helm şeması) yalnızca tek bir uygulamayı veya hizmeti değil, aynı zamanda çalışma zamanında çözümünüzü oluşturan tüm [mikro] hizmetleri açıklar. Çalışma zamanınız için tek bir bildirimsel açıklama gönderirsiniz ve Kubernetes, sağladığınız açıklamayla eşleşen gerçek çalışma zamanı durumuyla ilgilenir.

Dolayısıyla, CF yaklaşımı, "hizmetleriniz için kesinti olmadan tüm bulutunuzda bir işletim sistemini yamalı bir güvenlik açığıyla değiştirme" gibi kullanım durumlarını ele almasına olanak tanır. Ancak, sisteminizin hedef "ideal" çalışma zamanının bildirimsel açıklaması yerine hizmet başına dağıtımına da odaklanır.

Cloud Foundry, açık kaynaklı bir hizmet olarak platform bulut bilişim sistemidir. Cloud Foundry, projelerin farklı alanlarda konuşlandırılmasına izin verir ve ayrıca herhangi bir bulut hizmetini uygulamanıza bağlar.

Kubernete, daha çok kapsayıcılar (kapsüller) için, kapsayıcıya alınmış uygulamaların dağıtımını, ölçeklendirmesini ve yönetimini otomatikleştiren süsleme aracı gibidir. Kapsayıcı veya kap grubunu tanımlamak için kapsüller terimini kullanır.

Herhangi bir kubernetes dağıtımı en az iki kaynağa ihtiyaç duyar:

1) deployment.yaml: Bu kaynak, kapsayıcı kayıt defterinizden, replikasetlerinizden (pod replikaları), sunum stratejinizden, ölçeklemeden ve araştırmalardan vb. Hangi görüntü sürümünü alması gerektiğini tanımlar.

2) service.yaml: İç bölmeleriniz ve dış dünya arasında bir arayüzdür, tüm dış trafik, yükü dahili bölmelere dağıttığı yerden bu kaynakta tanımlanan bağlantı noktasını dinleyecektir.

Daha fazla kaynak, kubernetes'in sağladığı, genellikle http gibi bir kümedeki hizmetlere harici erişimi yöneten giriştir. Ingress aracılığıyla yük dengeleme, SSL sonlandırma ve isme dayalı sanal barındırma sağlayabilirsiniz.

Kubernetes hakkında daha fazla bilgiyi aşağıda bulabilirsiniz: https://kubernetes.io/docs/

[pcf ve kubernetes] [1] pcf ve kubernetes arasındaki fark

                                PCF

(uygulama düzeyinde platform soyutlaması) • Pivotal Cloud Foundry, bulutta yerel uygulama geliştirmenin üst düzey bir soyutlamasıdır.

• Uygulama düzeyinde platform soyutlamasına sahibiz, tam olarak yapılandırılmış bir uygulama oluşturup konuşlandırıyoruz

• PCF, "uygulama" PaaS'sinin bir örneğidir (Cloud Foundry Uygulama Çalışma Zamanı olarak da adlandırılır)

• Geliştirici, uygulamayı gelecekte sürdürür

• Yeni uygulamalar, bulutta yerel uygulamalar için idealdir. Kısa yaşam döngüleri ve sık sürümlerle çalışan ekipler için PCF mükemmel bir ürün sunar.

                       Kubernetes 

(konteyner seviyesinde platform soyutlaması) • Kubernetes, bir konteyner planlayıcı veya düzenleyicidir.

• Kapsayıcı düzeyinde platform soyutlamasına sahibiz, kapsayıcıları eksiksiz bir uygulamanın parçası olarak oluşturup konuşlandırıyoruz.

• Kubernetes bir "kapsayıcı" PaaS'dir (bazen CaaS olarak adlandırılır).

• Kapsayıcı düzenleme araçlarıyla Geliştirici, kapsayıcıyı gelecekte oluşturur ve daha sonra korur.

• Yeni uygulama için, mühendislik ekipleriniz için daha fazla iş ve daha az verimlilik

4 yıl sonra trendler şöyle görünür:

Kubernetes kümeleri bugünlerde gerçekten ucuz hale geliyor ve kubernetes için araç oluşturma ortamı daha iyi.

Ayrıca diğer posterler tarafından listelenen rekabetçi özelliklerin çoğu, bu günlerde kubernetes içinde kolayca kopyalanabilir.