Kubernetes vs. CloudFoundry [zamknięte]

Następna wersja CloudFoundry / Diego będzie oferować natywne wsparcie dla kontenerów Docker, które będą organizowane na wielu hostach [ link ]. Brzmi to bardzo podobnie do Kubernetes.

Oczywiście problem, który Kubernetes próbuje rozwiązać, jest bardziej ogólny, podczas gdy CloudFoundry bardziej koncentruje się na tworzeniu aplikacji. Jednak wydaje mi się, że oba zmierzają w podobnym kierunku, a CloudFoundry dodaje o wiele więcej funkcji do zwykłej orkiestracji.

Zastanawiam się więc nad przypadkami użycia, w których Kubernetes dodałby więcej wartości niż CloudFoundry?

Jako komisarz CloudFoundry (w przeszłości) i Kubernetes (obecnie), prawdopodobnie mam wyjątkowe kwalifikacje, aby odpowiedzieć na to pytanie.

Podobne do PaaS

Lubię nazywać CloudFoundry „Application PaaS”, a Kubernetes „Container PaaS”, ale różnica jest dość subtelna i płynna, biorąc pod uwagę, że oba projekty zmieniają się z czasem, aby konkurować na tych samych rynkach.

Różnica między nimi polega na tym, że CF ma warstwę przejściową, która pobiera (12-czynnikową) aplikację użytkownika (np. Jar lub klejnot) i pakiet budowania w stylu Heroku (np. Java + Tomcat lub Ruby) i tworzy kroplę (analogicznie do Obraz platformy Docker). CF nie udostępnia użytkownikowi interfejsu konteneryzacji, ale Kubernetes to robi.

Publiczność

Głównymi odbiorcami CloudFoundry są programiści aplikacji dla przedsiębiorstw, którzy chcą wdrażać bezstanowe aplikacje 12-czynnikowe przy użyciu pakietów konstrukcyjnych w stylu Heroku.

Grupa odbiorców Kubernetes jest nieco szersza i obejmuje zarówno programistów aplikacji bezstanowych, jak i programistów usług stanowych, którzy udostępniają własne kontenery.

To rozróżnienie może się zmienić w przyszłości:

• CloudFoundry może zacząć akceptować obrazy dockera ( Lattice akceptuje obrazy Docker ).
• Kubernetes może dodać warstwę generowania obrazu ( OpenShift robi coś takiego ).

Porównanie funkcji

W miarę dojrzewania i rywalizacji obu projektów podobieństwa i różnice ulegną zmianie. Z przymrużeniem oka weźmy więc poniższe porównanie funkcji.

Zarówno CF, jak i K8 mają wiele podobnych funkcji, takich jak konteneryzacja, przestrzeń nazw, uwierzytelnianie,

Przewagi konkurencyjne Kubernetes:

• Grupuj i skaluj zasobniki kontenerów, które współużytkują stos sieciowy, zamiast tylko skalować niezależnie
• Przywieź własny pojemnik
• Stanowa warstwa trwałości
• Większa, bardziej aktywna społeczność OSS
• Bardziej rozszerzalna architektura z wymiennymi komponentami i wtyczkami innych firm
• Darmowy graficzny interfejs użytkownika

Przewagi konkurencyjne CloudFoundry:

• Dojrzałe uwierzytelnianie, grupowanie użytkowników i obsługa wielu dzierżawców [x]
• Przynieś własną aplikację
• Dołączony system równoważenia obciążenia
• Wdrożony, skalowany i utrzymywany przy życiu przez BOSH [x]
• Solidne rejestrowanie i agregacja danych [x]
• Firmowy internetowy interfejs graficzny [x]

[x] Te funkcje nie są częścią Diego ani nie są zawarte w Lattice.

Rozlokowanie

Jedną z przewag konkurencyjnych CloudFoundry jest posiadanie dojrzałego silnika wdrażania BOSH, który umożliwia takie funkcje, jak skalowanie, wskrzeszanie i monitorowanie podstawowych komponentów CF. BOSH obsługuje również wiele warstw IaaS z podłączalną abstrakcją dostawcy chmury. Niestety, krzywa uczenia się BOSH i zarządzanie konfiguracją wdrażania są koszmarem. (Jako osoba zatwierdzająca BOSH myślę, że mogę to powiedzieć z dużą dokładnością.)

Abstrakcja wdrażania Kubernetes jest wciąż w powijakach. W głównym repozytorium dostępnych jest wiele środowisk docelowych, ale nie wszystkie działają, są dobrze przetestowane lub obsługiwane przez głównych programistów. Jest to głównie kwestia dojrzałości. Można by się spodziewać, że z czasem poprawi się i zwiększy abstrakcji. Na przykład Kubernetes na DCOS umożliwia wdrażanie Kubernetes w istniejącym klastrze DCOS za pomocą jednego polecenia.

Kontekst historyczny

Diego jest przeróbką agenta CF Droplet Execution Agent. Został pierwotnie opracowany przed ogłoszeniem Kubernetes i zyskał szerszy zakres funkcji wraz z ewolucją konkurencyjnego krajobrazu. Jego pierwotnym celem było generowanie kropelek (aplikacja użytkownika + pakiet kompilacji CF) i uruchamianie ich w kontenerach Warden (przemianowanych na Ogród po przepisaniu w Go). Od samego początku został również przepakowany jako Lattice , który jest nieco CloudFoundry-lite (chociaż ta nazwa została przyjęta przez istniejący projekt). Z tego powodu Lattice przypomina nieco zabawkę, ponieważ celowo ograniczył odbiorców i zakres użytkowników, wyraźnie brakuje funkcji, które uczyniłyby ją „gotową do użycia w przedsiębiorstwach”. Funkcje, które już zapewnia CF. Dzieje się tak częściowo dlatego, że Lattice jest używany do testowania podstawowych komponentów, bez niektórych narzutów z bardziej złożonego CF, ale można również używać Lattice w wewnętrznych środowiskach o wysokim zaufaniu, w których bezpieczeństwo i wielodostępność nie są tak dużym problemem .

Warto również wspomnieć, że CloudFoundry i Warden (jego silnik kontenerowy) również wyprzedzają Dockera o kilka lat.

Z drugiej strony Kubernetes to stosunkowo nowy projekt, który został opracowany przez Google w oparciu o lata używania kontenerów z BORG i Omega. Kubernetes można traktować jako orkiestrację kontenerów trzeciej generacji w Google, tak samo jak Diego jest orkiestracją kontenerów trzeciej generacji w Pivotal / VMware (wersja 1 napisana w VMware; wersja 2 w VMware z pomocą Pivotal Labs; wersja 3 w Pivotal po przejęciu projektu) .

Cloud Foundry to świetne narzędzie, zakładając, że zawsze chcesz pracować w ramach ograniczeń oferty, ponieważ jest ona bardzo uparta / zalecana. Interfejs użytkownika sieci Web jest fajny do obejrzenia pierwszego dnia, ale jest rzadko używany po rozpoczęciu pracy z klientem i skonfigurowaniu potoku CI / CD. Odkryłem, że Cloud Foundry jest świetny, dopóki nie pojawią się przypadki użycia, które nie są łatwo obsługiwane w pełni w Cloud Foundry. Dostarczenie tych przypadków użycia może opóźnić projekty, gdy próbujesz rozwiązać te problemy, w wyniku czego tracisz widoczność infrastruktury i wspierasz korzyści z tych komponentów, które następnie działają głównie poza Cloud Foundry (pomyśl o wielu bazach danych, kafka, hadoop, cassandra itp.) Podejrzewam, że z biegiem czasu rozmach wokół Dockera i nieelastyczność Cloud Foundry doprowadzą użytkowników do Kubernetes, Mesos lub Docker Swarm / Datacenter. Możliwe, że Cloud Foundry może dogonić te trzy, ale wydaje się mało prawdopodobne ze względu na popularność tych projektów open source.

Trudno odpowiedzieć, dlaczego firma miałaby stworzyć produkt, który jest zasadniczo podobny do innego produktu. Jest wiele powodów. Może już zaczęli go używać i zainwestowali w to. Może oni (CF) uważają, że Kubernetes jest źle zrobiony lub źle pobiera API / model / szczegóły. Może myślą, że mogą działać szybciej, jeśli kontrolują cały produkt, a nie wnoszą wkład.

To prawda, mówię to jako programista Kubernetes - można zadać te same pytania dotyczące Kubernetes vs Mesos, Amazon ECS vs Kubernetes lub Docker Swarm vs Kubernetes.

Mam nadzieję, że z biegiem czasu wszyscy podążamy w tym samym kierunku i będziemy mogli więcej współpracować i spędzać mniej czasu na wymyślaniu swojej pracy na nowo.

Jeśli chodzi o Kubernetes - nacisk kładziony jest na programistów aplikacji: proste i potężne prymitywy, które pozwalają bardzo szybko tworzyć i wdrażać aplikacje na dużą skalę. Opieramy się na naszym doświadczeniu (no cóż, Google) z podobnymi technologiami, aby wytyczyć nasz kurs. Inni ludzie będą mieli różne doświadczenia lub opinie.

Moim zdaniem istotną różnicą jest podejście, które przyjmują:

CF automatycznie buduje środowisko wykonawcze z 3 komponentów: pliku binarnego aplikacji dostarczonego przez użytkownika, pakietu kompilacji zawierającego oprogramowanie pośrednie potrzebne do uruchomienia aplikacji oraz obrazu systemu operacyjnego (komórki macierzystej). Użytkownik CF (programista) musi dostarczyć tylko plik binarny aplikacji (np. Wykonywalny plik jar). CF zajmuje się resztą, czyli pakowaniem i uruchamianiem aplikacji.

Kubernetes oczekuje od dewelopera obrazów Dockera, które zawierają oprogramowanie pośredniczące i system operacyjny już wbudowane i gotowe do uruchomienia. W tym celu „manifest wdrożenia” Kubernetes (np. Wykres Helm) opisuje nie tylko pojedynczą aplikację lub usługę, ale wszystkie [mikro] usługi, które składają się na Twoje rozwiązanie w czasie wykonywania. Przesyłasz jeden deklaratywny opis swojego środowiska uruchomieniowego, a Kubernetes dba o to, aby rzeczywisty stan środowiska wykonawczego był zgodny z podanym opisem.

Podejście CF pozwala więc zająć się takimi przypadkami użycia, jak „zastąpienie systemu operacyjnego poprawioną luką w zabezpieczeniach w całej chmurze bez przestojów dla usług”. Ale koncentruje się również na wdrożeniu usługi na usługę zamiast deklaratywnego opisu docelowego „idealnego” środowiska wykonawczego systemu.

Cloud Foundry to system przetwarzania w chmurze typu open source typu platforma jako usługa. Cloud Foundry umożliwia wdrażanie projektów w różnych przestrzeniach, a także wiąże dowolną usługę w chmurze z Twoją aplikacją.

Kubernete bardziej przypomina narzędzie do ozdabiania kontenerów (podów), które automatyzuje wdrażanie, skalowanie i zarządzanie aplikacjami kontenerowymi. Używa terminu strąki do zdefiniowania kontenera lub grupy kontenerów.

Każde wdrożenie Kubernetes wymaga co najmniej dwóch zasobów:

1) deployment.yaml: Ten zasób określa, którą wersję obrazu musi pobrać z rejestru kontenerów, replik (replik pod), strategii wdrażania, skalowania i sond itp.

2) service.yaml: Jest to interfejs między wewnętrznymi zasobami a światem zewnętrznym, cały ruch zewnętrzny będzie nasłuchiwał portu zdefiniowanego w tym zasobie, skąd rozprowadza obciążenie do wewnętrznych zasobników.

Im więcej zasobów jest przychodzących, które Kubernetes zapewniają, które zarządzają zewnętrznym dostępem do usług w klastrze, zazwyczaj http. Dzięki Ingress możesz zapewnić równoważenie obciążenia, zakończenie SSL i hosting wirtualny oparty na nazwach.

Więcej o kubernetes można znaleźć poniżej: https://kubernetes.io/docs/

[pcf vs kubernetes] [1] Różnica między pcf a kubernetes

                                PCF

(abstrakcja platformy na poziomie aplikacji) • Pivotal Cloud Foundry to wysokopoziomowa abstrakcja tworzenia aplikacji natywnych dla chmury.

• Mamy abstrakcję platformy na poziomie aplikacji, budując i wdrażając w pełni skonfigurowaną aplikację

• PCF jest jednym z przykładów „aplikacji” PaaS (zwanej także Cloud Foundry Application Runtime)

• Deweloper utrzymuje aplikację w przyszłości

• Idealny dla nowych aplikacji, aplikacji natywnych dla chmury. Dla zespołów pracujących z krótkimi cyklami życia i częstymi wydaniami, PCF oferuje doskonały produkt.

                       Kubernetes 

(abstrakcja platformy na poziomie kontenera) • Kubernetes to planista lub koordynator kontenerów.

• Mamy abstrakcję platformy na poziomie kontenera, budując i wdrażając kontenery jako część kompletnej aplikacji.

• Kubernetes to „kontenerowy” PaaS (czasami nazywany CaaS).

• Dzięki narzędziom do orkiestracji kontenerów programista tworzy, a następnie utrzymuje kontener w przyszłości.

• W przypadku nowej aplikacji więcej pracy dla zespołów inżynierów i zmniejszona produktywność

Po 4 latach trendy wyglądają tak:

Klastry Kubernetes stają się obecnie naprawdę tanie, a środowisko narzędziowe Kubernetes jest lepsze.

Również większość konkurencyjnych funkcji wymienionych na innych plakatach jest obecnie bardzo łatwa do skopiowania w kubernetes.