„Jaka jest różnica między Kubernetesem a OpenShift?” – to pytanie pojawia się z godną pozazdroszczenia konsekwencją. Chociaż w rzeczywistości jest to jak pytanie, czym samochód różni się od silnika. Jeśli będziemy kontynuować analogię, to samochód jest produktem gotowym, można z niego korzystać od razu, dosłownie: wsiadać i jechać. Natomiast żeby silnik gdzieś zabrał, trzeba go najpierw uzupełnić o mnóstwo innych rzeczy, żeby ostatecznie otrzymać to samo auto.
Dlatego Kubernetes jest silnikiem, wokół którego montowany jest samochód (platforma) marki OpenShift, który doprowadzi Cię do celu.
W tym artykule chcemy przypomnieć i zbadać następujące kluczowe punkty nieco bardziej szczegółowo:
- Kubernetes jest sercem platformy OpenShift i jest w 100% certyfikowanym Kubernetesem, całkowicie open source i bez najmniejszego zastrzeżonego charakteru. Krótko:
- Interfejs API klastra OpenShift to w XNUMX% Kubernetes.
- Jeśli kontener działa na innym systemie Kubernetes, będzie działał na OpenShift bez żadnych zmian. Nie ma potrzeby wprowadzania zmian w aplikacjach.
- OpenShift nie tylko dodaje przydatne funkcje i funkcjonalność do Kubernetes. Podobnie jak samochód, OpenShift jest gotowy do użycia od razu po wyjęciu z pudełka, można go natychmiast wprowadzić do produkcji i, jak pokażemy poniżej, znacznie ułatwia życie programisty. Dlatego OpenShift łączy się w dwie osoby. Jest to zarówno udana, jak i znana z perspektywy dewelopera platforma PaaS klasy Enterprise. Jednocześnie jest to superniezawodne rozwiązanie typu Container-as-a-Service z punktu widzenia operacji przemysłowych.
OpenShift to Kubernetes ze 100% certyfikatem CNCF
Na czym opiera się OpenShift . Dlatego po odpowiednim przeszkoleniu użytkownicy są zdumieni mocą kubectl. A ci, którzy przeszli na OpenShift z Kubernetes Cluster, często mówią, jak bardzo im się podoba, że po przekierowaniu kubeconfig do klastra OpenShift wszystkie istniejące skrypty działają bez zarzutu.
Prawdopodobnie słyszałeś o narzędziu wiersza poleceń OpenShift o nazwie OC. Jest w pełni kompatybilny z poleceniami kubectl, a ponadto oferuje kilka przydatnych pomocników, które przydadzą się podczas wykonywania wielu zadań. Ale najpierw trochę więcej o kompatybilności OC i kubectl:
polecenia kubectl
Zespoły OC
kubectl dostać strąki
oc, zdobądź strąki
kubectl pobierz przestrzenie nazw
oc pobierz przestrzenie nazw
kubectl utwórz -f wdrożenie.yaml
oc utwórz -f wdrożenie.yaml
Oto jak wyglądają wyniki użycia kubectl w API OpenShift:
• kubectl get pods – zwraca pody zgodnie z oczekiwaniami.
• kubectl get namespaces – zwraca przestrzenie nazw zgodnie z oczekiwaniami.
Komenda kubectl create -f mydeployment.yaml tworzy zasoby Kubernetes tak samo jak na każdej innej platformie Kubernetes, jak pokazano na poniższym filmie:
Innymi słowy, wszystkie API Kubernetesa są w pełni dostępne w OpenShift przy zachowaniu 100% kompatybilności. Dlatego .
OpenShift dodaje przydatne funkcje do Kubernetes
Interfejsy API Kubernetesa są w 100% dostępne w OpenShift, ale standardowemu narzędziu Kubernetes kubectl wyraźnie brakuje funkcjonalności i wygody. Dlatego Red Hat dodał przydatne funkcje i narzędzia wiersza poleceń do Kubernetesa, takie jak OC (skrót od klienta OpenShift) i ODO (OpenShift DO, to narzędzie jest przeznaczone dla programistów).
1. Narzędzie OC - wydajniejsza i wygodniejsza wersja Kubectl
Przykładowo, w przeciwieństwie do kubectl, umożliwia tworzenie nowych przestrzeni nazw i łatwe przełączanie kontekstów, a także oferuje szereg przydatnych poleceń dla programistów, takich jak budowanie obrazów kontenerów i wdrażanie aplikacji bezpośrednio z kodu źródłowego lub plików binarnych (Source-to-image, s2i).
Przyjrzyjmy się przykładom, jak wbudowane pomocniki i zaawansowana funkcjonalność narzędzia OC pomagają uprościć codzienną pracę.
Pierwszym przykładem jest zarządzanie przestrzenią nazw. Każdy klaster Kubernetes zawsze ma wiele przestrzeni nazw. Zwykle służą do tworzenia środowisk programistycznych i produkcyjnych, ale można je również wykorzystać, aby na przykład zapewnić każdemu programiście osobistą piaskownicę. W praktyce powoduje to, że programista musi często przełączać się między przestrzeniami nazw, ponieważ kubectl działa w kontekście bieżącej przestrzeni. Dlatego w przypadku kubectl ludzie aktywnie wykorzystują do tego skrypty pomocnicze. Ale podczas korzystania z OC, aby przełączyć się do żądanej przestrzeni, po prostu powiedz „oc Project Namespace”.
Nie pamiętasz, jak nazywa się przestrzeń nazw, której potrzebujesz? Nie ma problemu, po prostu wpisz „oc get projekty”, aby wyświetlić pełną listę. Sceptycznie zastanawiasz się, jak to będzie działać, jeśli masz dostęp tylko do ograniczonego podzbioru przestrzeni nazw w klastrze? Ano dlatego, że kubectl robi to poprawnie tylko wtedy, gdy RBAC pozwala zobaczyć wszystkie przestrzenie w klastrze, a w dużych klastrach nie każdy ma takie uprawnienia. Odpowiadamy więc: dla OC nie stanowi to żadnego problemu i w takiej sytuacji bez problemu stworzy pełną listę. To właśnie te małe rzeczy składają się na korporacyjną orientację Openshift i dobrą skalowalność tej platformy pod względem użytkowników i aplikacji
2. ODO - ulepszona wersja kubectl dla programistów
Innym przykładem ulepszeń Red Hat OpenShift w porównaniu z Kubernetesem jest narzędzie wiersza poleceń ODO. Jest przeznaczony dla programistów i umożliwia szybkie wdrożenie lokalnego kodu w zdalnym klastrze OpenShift. Może także usprawnić procesy wewnętrzne, aby natychmiast synchronizować wszystkie zmiany w kodzie z kontenerami w zdalnym klastrze OpenShift bez konieczności ponownego budowania, rejestrowania i ponownego wdrażania obrazów.
Przyjrzyjmy się, jak OC i ODO ułatwiają pracę z kontenerami i Kubernetesem.
Wystarczy porównać kilka przepływów pracy, gdy są zbudowane w oparciu o kubectl i gdy używane są OC lub ODO.
• Wdrożenie kodu na OpenShift dla tych, którzy nie mówią w YAML:
Kubernetes/kubectl
$> klon gita
1. Utwórz plik Dockerfile, który buduje obraz z kodu
-----
Z węzła
KATALOG ROBOCZY /usr/src/app
KOPIUJ pakiet*.json ./
KOPIUJ indeks.js ./
KOPIUJ ./aplikacja ./aplikacja
Uruchom instalację npm
EKSPOZYCJA 3000
CMD [ „npm”, „start” ] ————–
2- Budujemy wizerunek
$> kompilacja podmana...
3- Zaloguj się do rejestru
logowanie podmana...
4- Umieść obraz w rejestrze
pchnięcie podmana
5- Utwórz pliki YAML do wdrożenia aplikacji (deployment.yaml, service.yaml, ingress.yaml) - to absolutne minimum
6- Wdróż pliki manifestu:
Kubectl zastosuj -f.
OpenShift/ok
$> oc nowa aplikacja – nazwa_naszej_aplikacji
OpenShift/od
$> klon gita
$> odo utwórz komponent nodejs myapp
$>to pchnięcie
• Zmiana kontekstu: zmiana roboczej przestrzeni nazw lub klastra roboczego.
Kubernetes/kubectl
1- Utwórz kontekst w kubeconfig dla projektu „myproject”
2- kontekst zestawu kubectl…
OpenShift/ok
projekt oc „mój projekt”
Kontrola jakości: „Pojawiła się tu jedna interesująca funkcja, jeszcze w wersji alfa. Może uda nam się wprowadzić to do produkcji?”
Wyobraź sobie, że siedzisz w samochodzie wyścigowym i słyszysz: „Zamontowaliśmy nowy typ hamulców i szczerze mówiąc, ich niezawodność nie jest jeszcze w porządku… Ale nie martw się, w trakcie kursu będziemy je aktywnie udoskonalać mistrzostw.” Jak podoba Ci się ta perspektywa? W Red Hat nie jesteśmy zbyt szczęśliwi. 🙂
Dlatego staramy się wstrzymać z wersjami alfa do czasu, aż będą wystarczająco dojrzałe, dokładnie je przetestowaliśmy w boju i uznamy, że można z nich bezpiecznie korzystać. Zwykle wszystko najpierw przechodzi przez etap Dev Preview, a potem przez etap Dev Preview i dopiero wtedy ukazuje się jako publikacja publiczna (GA), który jest już na tyle stabilny, że nadaje się do produkcji.
Dlaczego? Ponieważ, jak przy tworzeniu każdego innego oprogramowania, nie wszystkie początkowe pomysły w Kubernetesie trafiają do ostatecznej wersji. Albo osiągają go i nawet zachowują zamierzoną funkcjonalność, ale ich implementacja diametralnie różni się od tej w wersji alfa. Ponieważ tysiące klientów Red Hat korzysta z OpenShift do obsługi obciążeń o znaczeniu krytycznym, kładziemy szczególny nacisk na stabilność naszej platformy i długoterminowe wsparcie.
Firma Red Hat stara się często wypuszczać OpenShift i aktualizować dołączoną wersję Kubernetes. Na przykład bieżąca wersja GA OpenShift 4.3 w chwili pisania tego tekstu zawiera Kubernetes 1.16, który tylko ustępuje wcześniejszej wersji Kubernetes o numerze 1.17. Tym samym staramy się zapewnić klientowi Kubernetes klasy Enterprise oraz zapewnić dodatkową kontrolę jakości przy wypuszczaniu nowych wersji OpenShift.
Poprawki oprogramowania: „W wersji Kubernetes, którą mamy w produkcji, wystąpiła luka. I możesz to zamknąć tylko poprzez aktualizację trzech wersji. Czy są jakieś opcje?
W projekcie open source Kubernetes poprawki oprogramowania są zwykle wydawane w ramach następnego wydania, czasami obejmując jedno lub dwa poprzednie wydania kluczowe, co zapewnia gwarancję zaledwie 6 miesięcy.
Red Hat szczyci się tym, że udostępnia krytyczne poprawki wcześniej niż inne i zapewnia wsparcie znacznie dłużej. Weźmy na przykład lukę w zabezpieczeniach Kubernetes umożliwiającą eskalację uprawnień (): zostało to odkryte w Kubernetes 1.11, a poprawki do poprzednich wydań zostały wydane tylko do wersji 1.10.11, pozostawiając tę lukę we wszystkich poprzednich wydaniach Kubernetes, od 1.x do 1.9.
Z kolei, (jest tam Kubernetes 1.2), przechwytując dziewięć wydań OpenShift i wyraźnie demonstrując dbałość o klientów (więcej szczegółów ).
Jak OpenShift i Red Hat popychają Kubernetes do przodu
Red Hat jest drugim co do wielkości dostawcą oprogramowania do projektu Kubernetes o otwartym kodzie źródłowym, zaraz za Google, a 3 z 5 najbardziej płodnych programistów pochodzi z Red Hat. Kolejny mało znany fakt: wiele funkcji krytycznych pojawiło się w Kubernetesie właśnie z inicjatywy Red Hata, w szczególności takich jak:
- RBAC. Kubernetes nie posiadał funkcji RBAC (ClusterRole, ClusterRoleBinding) do czasu, aż inżynierowie Red Hata zdecydowali się zaimplementować je jako część samej platformy, a nie jako dodatkową funkcjonalność OpenShift. Czy Red Hat boi się ulepszać Kubernetes? Oczywiście, że nie, ponieważ Red Hat ściśle przestrzega zasad open source i nie gra w gry Open Core. Ulepszenia i innowacje wprowadzane przez społeczności programistów, a nie zastrzeżone, są bardziej opłacalne i szerzej stosowane, co dobrze wpisuje się w nasz główny cel, jakim jest zwiększanie użyteczności oprogramowania open source dla naszych klientów.
- Zasady bezpieczeństwa dla podów (Zasady bezpieczeństwa podów). Ta koncepcja bezpiecznego uruchamiania aplikacji w zasobnikach została pierwotnie zaimplementowana w OpenShift pod nazwą SCC (Security Context Constraints). I podobnie jak w poprzednim przykładzie Red Hat postanowił wprowadzić te rozwiązania do otwartego projektu Kubernetes, aby każdy mógł z nich skorzystać.
Tę serię przykładów można kontynuować, ale chcieliśmy tylko pokazać, że firma Red Hat naprawdę angażuje się w rozwój Kubernetes i ulepszanie go dla wszystkich.
Jasne jest, że OpenShift to Kubernetes. Jakie są różnice? 🙂
Mamy nadzieję, że czytając do tego momentu zdałeś sobie sprawę, że Kubernetes jest głównym komponentem OpenShift. Główny, ale bynajmniej nie jedyny. Innymi słowy, zwykła instalacja Kubernetesa nie zapewni platformy klasy korporacyjnej. Będziesz musiał dodać uwierzytelnianie, sieć, bezpieczeństwo, monitorowanie, zarządzanie logami i inne. Ponadto będziesz musiał dokonać trudnych wyborów spośród dużej liczby dostępnych narzędzi (aby docenić różnorodność ekosystemu, po prostu spójrz ) i w jakiś sposób zapewnić spójność i spójność, aby działały jako jedność. Ponadto będziesz musiał regularnie przeprowadzać aktualizacje i testy regresyjne za każdym razem, gdy zostanie wydana nowa wersja któregokolwiek z używanych komponentów. Oznacza to, że oprócz tworzenia i utrzymywania samej platformy będziesz musiał także zająć się całym tym oprogramowaniem. Jest mało prawdopodobne, że pozostanie dużo czasu na rozwiązanie problemów biznesowych i osiągnięcie przewagi konkurencyjnej.
Ale w przypadku OpenShift Red Hat bierze na siebie wszystkie te zawiłości i po prostu daje funkcjonalnie kompletną platformę, która obejmuje nie tylko sam Kubernetes, ale także cały zestaw niezbędnych narzędzi open source, które zamieniają Kubernetes w prawdziwą klasę korporacyjną rozwiązanie, które możesz od razu i całkowicie spokojnie uruchomić do produkcji. I oczywiście, jeśli masz własne stosy technologii, możesz zintegrować OpenShift z istniejącymi rozwiązaniami.
Spójrz na obrazek powyżej: wszystko, co znajduje się poza prostokątem Kubernetesa, to miejsce, w którym Red Hat dodaje funkcjonalność, której Kubernetes nie ma, jak mówią, z założenia. A teraz przyjrzymy się głównym z tych obszarów.
1. Solidny system operacyjny jako baza: RHEL CoreOS lub RHEL
Red Hat jest od ponad 20 lat wiodącym dostawcą dystrybucji Linuksa dla aplikacji o znaczeniu krytycznym dla biznesu. Nasze zgromadzone i stale aktualizowane doświadczenie w tym obszarze pozwala nam zaoferować naprawdę niezawodną i godną zaufania podstawę do przemysłowej eksploatacji kontenerów. RHEL CoreOS wykorzystuje to samo jądro co RHEL, ale jest zoptymalizowany przede wszystkim do zadań takich jak uruchamianie kontenerów i klastrów Kubernetes: jego zmniejszony rozmiar i niezmienność ułatwiają konfigurowanie klastrów, automatyczne skalowanie, wdrażanie poprawek itp. Wszystkie te funkcje sprawiają, że jest to idealna podstawa do zapewnienia tego samego doświadczenia użytkownika dzięki OpenShift w szerokiej gamie środowisk komputerowych, od bare metal po chmurę prywatną i publiczną.
2. Automatyzacja operacji IT
Automatyzacja procesów instalacyjnych i operacji dnia drugiego (czyli codziennych operacji) to mocna strona OpenShift, znacznie ułatwiająca administrowanie, aktualizację i utrzymanie wydajności platformy kontenerowej na najwyższym poziomie. Osiąga się to poprzez obsługę operatorów Kubernetes na poziomie jądra OpenShift 4.
OpenShift 4 to także cały ekosystem rozwiązań oparty na operatorach Kubernetes, rozwijany zarówno przez samego Red Hata, jak i przez partnerów zewnętrznych (patrz. Red Hat, czyli sklep operatora , stworzony przez Red Hat dla zewnętrznych programistów).
Zintegrowany katalog OpenShift 4 obejmuje ponad 180 operatorów Kubernetes
3. Narzędzia programistyczne
Od 2011 roku OpenShift dostępny jest jako platforma PaaS (Platform-as-a-Service), która znacznie ułatwia życie programistom, pomaga im skupić się na kodowaniu i oferuje natywne wsparcie dla języków programowania takich jak Java, Node.js , PHP, Ruby, Python, Go, a także usługi ciągłej integracji i dostarczania CI/CD, bazy danych itp. OpenShift 4 oferuje , który obejmuje ponad 100 usług opartych na operatorach Kubernetes opracowanych przez firmę Red Hat i naszych partnerów.
W przeciwieństwie do Kubernetesa, OpenShift 4 ma dedykowany interfejs GUI (), co pomaga programistom bez wysiłku wdrażać aplikacje z różnych źródeł (git, rejestry zewnętrzne, Dockerfile itp.) w ich przestrzeniach nazw i przejrzyście wizualizuje relacje między komponentami aplikacji.
Ponadto OpenShift oferuje zestaw narzędzi programistycznych Codeready, który w szczególności obejmuje , w pełni konteneryzowane IDE z interfejsem internetowym, które działa bezpośrednio na OpenShift i implementuje podejście IDE jako usługa. Z drugiej strony dla tych, którzy chcą pracować wyłącznie w trybie lokalnym, przygotowaliśmy Codeready Containers, w pełni funkcjonalną wersję OpenShift 4, którą można wdrożyć na laptopie.
Zintegrowane IDE jako usługa umożliwiająca efektywny rozwój na platformie Kubernetes/OpenShift
OpenShift oferuje pełny system CI/CD od razu po wyjęciu z pudełka, oparty na kontenerowym Jenkinsie i wtyczce do pracy z potokami lub systemem CI/CD zorientowanym na Kubernetes (obecnie w wersji Tech Preview). Obydwa rozwiązania w pełni integrują się z konsolą OpenShift, umożliwiając uruchamianie wyzwalaczy potoków, przeglądanie wdrożeń, dzienników i nie tylko.
4. Narzędzia aplikacyjne
OpenShift umożliwia wdrażanie zarówno tradycyjnych aplikacji stanowych, jak i rozwiązań chmurowych opartych na nowych architekturach, takich jak mikroserwisy czy bezserwerowe. Rozwiązanie OpenShift Service Mesh jest dostępne od razu po wyjęciu z pudełka i zawiera kluczowe narzędzia do utrzymywania mikrousług, takie jak Istio, Kiali i Jaeger. Z kolei rozwiązanie OpenShift Serverless obejmuje nie tylko Knative, ale także narzędzia takie jak Keda stworzone w ramach wspólnej inicjatywy z Microsoftem, mającej na celu udostępnienie funkcji Azure na platformie OpenShift.
Zintegrowane rozwiązanie OpenShift ServiceMesh (Istio, Kiali, Jaeger) przyda się przy tworzeniu mikroserwisów
Aby wypełnić lukę między starszymi aplikacjami i kontenerami, OpenShift umożliwia teraz migrację maszyn wirtualnych na platformę OpenShift przy użyciu Natywnej wirtualizacji kontenerów (obecnie w TechPreview), dzięki czemu aplikacje hybrydowe stają się rzeczywistością i ułatwiają ich migrację między różnymi chmurami, zarówno prywatnymi, jak i publicznymi.
Wirtualna maszyna Windows 2019 działająca na OpenShift poprzez natywną wirtualizację kontenera (obecnie w wersji Tech Preview)
5. Narzędzia dla klastrów
Każda platforma klasy korporacyjnej musi posiadać usługi monitorowania i scentralizowanego logowania, mechanizmy bezpieczeństwa, uwierzytelnianie i autoryzację oraz narzędzia do zarządzania siecią. OpenShift zapewnia to wszystko od razu po wyjęciu z pudełka i jest w 100% open source, w tym rozwiązaniami takimi jak ElasticSearch, Prometheus, Grafana. Wszystkie te rozwiązania obejmują pulpity nawigacyjne, metryki i alerty, które zostały już zbudowane i skonfigurowane przy użyciu obszernej wiedzy firmy Red Hat w zakresie monitorowania klastrów, co pozwala na skuteczną kontrolę i monitorowanie środowiska produkcyjnego od samego początku.
OpenShift jest również standardowo wyposażony w tak ważne rzeczy dla klientów korporacyjnych, jak uwierzytelnianie za pomocą wbudowanego dostawcy OAuth, integracja z dostawcami poświadczeń, w tym LDAP, ActiveDirectory, OpenID Connect i wiele więcej.
Wstępnie skonfigurowany pulpit Grafana do monitorowania klastra OpenShift
Ponad 150 wstępnie skonfigurowanych wskaźników i alertów Prometheus do monitorowania klastrów OpenShift
Aby być kontynuowane
Bogata funkcjonalność rozwiązania oraz duże doświadczenie Red Hata w zakresie Kubernetesa sprawiły, że OpenShift osiągnął dominującą pozycję na rynku, co widać na poniższym rysunku (czytaj więcej ).
„Red Hat jest obecnie liderem rynku z 44% udziałem.
Firma czerpie korzyści ze swojej strategii sprzedaży skoncentrowanej na kliencie, w ramach której najpierw konsultuje i szkoli programistów dla przedsiębiorstw, a następnie przechodzi do monetyzacji, gdy przedsiębiorstwo zaczyna wdrażać kontenery do produkcji”.
(Źródło: )
Mamy nadzieję, że podobał Ci się ten artykuł. W przyszłych postach z tej serii przyjrzymy się bliżej przewadze OpenShift nad Kubernetesem w każdej z omawianych tutaj kategorii.
Źródło: www.habr.com