„Jaka jest różnica między Kubernetes a OpenShift?” – to pytanie pojawia się z niepokojącą regularnością. W rzeczywistości jest to tak, jakby zapytać, czym różni się samochód od silnika. Kontynuując tę analogię, samochód to gotowy produkt, z którego można korzystać od razu: wsiadasz i jedziesz. Z drugiej strony, aby silnik mogło gdzieś zabrać, należy go najpierw uzupełnić o wiele innych elementów, by ostatecznie otrzymać ten sam samochód.
Dlatego Kubernetes to silnik, wokół którego zbudowano samochód (platformę) marki OpenShift, który prowadzi cię do celu.
W tym artykule chcemy przypomnieć i nieco dokładniej omówić następujące kluczowe kwestie:
- Kubernetes to serce platformy OpenShift i to w 100% certyfikowany Kubernetes, z całkowicie otwartym kodem i bez najmniejszej własności. Krótko mówiąc:
- API dla klastra OpenShift to w pełni działający Kubernetes.
- Jeśli kontener działa w jakimkolwiek innym systemie Kubernetes, to bez żadnych zmian będzie działał także na OpenShift. Nie trzeba wprowadzać zmian w aplikacjach.
- OpenShift nie tylko wzbogaca Kubernetes o użyteczne funkcje i możliwości. Tak jak samochód, OpenShift jest gotowy do użycia od razu, można go natychmiast uruchomić w produkcji i, jak pokażemy poniżej, znacznie ułatwia życie programistom. Dlatego OpenShift ma dwa oblicza. Z perspektywy programisty jest to udana i powszechnie znana platforma PaaS klasy korporacyjnej. Z drugiej strony, z punktu widzenia przemysłowego, to super niezawodne rozwiązanie klasy Container-as-a-Service.
OpenShift to Kubernetes z 100% certyfikacją od fundacji CNCF.
Podstawą OpenShift jest Dlatego po odpowiednim szkoleniu użytkownicy są zachwyceni potęgą kubectl. Ci, którzy przeszli na OpenShift z klastra Kubernetes, często mówią, jak bardzo podoba im się, że po przekierowaniu kubeconfig na klaster OpenShift, wszystkie istniejące skrypty działają bez zarzutu.
Na pewno słyszałeś o narzędziu linii poleceń OpenShift o nazwie OC. Jest ono w pełni zgodne z poleceniami kubectl, a dodatkowo oferuje kilka przydatnych funkcji pomocniczych, które przydadzą się przy wykonywaniu wielu zadań. Ale na początku nieco więcej o zgodności OC i kubectl:
Polecenia kubectl
Polecenia OC
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Oto jak wyglądają wyniki użycia kubectl na OpenShift API:
• kubectl get pods – jak można się spodziewać, zwraca pod'y.
• kubectl get namespaces – jak można się spodziewać, zwraca przestrzenie nazw.
Polecenie kubectl create -f mydeployment.yaml tworzy zasoby Kubernetes dokładnie tak samo, jak na każdej innej platformie Kubernetes, co zostało pokazane w poniższym wideo:
Innymi słowy, wszystkie API Kubernetes są w pełni dostępne w OpenShift z zachowaniem 100% kompatybilności. Dlatego .
OpenShift uzupełnia Kubernetes o przydatne funkcje
API Kubernetes są w 100% dostępne w OpenShift, ale standardowe narzędzie Kubernetes – kubectl wyraźnie brakuje funkcjonalności i wygody. Dlatego Red Hat wzbogacił Kubernetes o przydatne funkcje i narzędzia wiersza poleceń, takie jak OC (skrócona forma OpenShift client) i ODO (OpenShift DO, to narzędzie przeznaczone dla deweloperów).
1. Narzędzie OC – bardziej zaawansowany i wygodny wybór dla Kubectl
Na przykład, w przeciwieństwie do kubectl, umożliwia tworzenie nowych przestrzeni nazw i łatwe przełączanie kontekstu oraz oferuje szereg przydatnych poleceń dla programistów, na przykład do budowy obrazów kontenerów i wdrażania aplikacji bezpośrednio z kodu źródłowego lub plików binarnych (Source-to-image, s2i).
Przyjrzyjmy się na przykładach, jak wbudowane funkcje pomocnicze i rozszerzona funkcjonalność narzędzia OC pomagają uprościć codzienną pracę.
Pierwszy przykład – zarządzanie przestrzeniami nazw. W każdym klastrze Kubernetes zawsze istnieje kilka przestrzeni nazw. Zazwyczaj służą one do tworzenia środowisk deweloperskich i produkcyjnych, ale mogą być również wykorzystywane, aby na przykład dać każdemu programiście osobistą „piaskownicę”. W praktyce prowadzi to do tego, że programiści muszą 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 używają do tego skryptów pomocniczych. Natomiast przy użyciu OC, aby przełączyć się na odpowiednią przestrzeń, wystarczy powiedzieć “oc project przestrzeń_nazw”.
Nie pamiętasz, jak nazywa się potrzebna przestrzeń nazw? Żaden problem, wystarczy wpisać „oc get projects”, aby wyświetlić pełną listę. Zastanawiasz się sceptycznie, jak to zadziała, jeśli masz dostęp tylko do ograniczonego podzbioru przestrzeni nazw w klastrze? Cóż, ponieważ kubectl działa poprawnie tylko wtedy, gdy RBAC pozwala ci widzieć wszystkie przestrzenie w klastrze, a w większych klastrach takie uprawnienia nie są przyznawane wszystkim. Odpowiadając na to: dla OC to w ogóle nie jest problem i w takiej sytuacji chętnie wyda pełną listę. Takie detale tworzą korporacyjną orientację Openshift i dobrą skalowalność tej platformy w obszarze użytkowników i aplikacji.
2. ODO – ulepszona wersja kubectl dla deweloperów.
Jako kolejny przykład ulepszeń Red Hat OpenShift w porównaniu do Kubernetes można podać narzędzie wiersza polecenia ODO. Jest ono przeznaczone dla deweloperów i umożliwia szybkie wdrażanie lokalnego kodu na zdalnym klastrze OpenShift. Ponadto, za jego pomocą można optymalizować wewnętrzne procesy, aby natychmiast synchronizować wszystkie zmiany kodu z kontenerami na zdalnym klastrze OpenShift bez ponownego budowania, publikowania w rejestrze i wdrażania obrazów.
Przyjrzyjmy się, jak OC i ODO ułatwiają pracę z kontenerami i Kubernetes.
Porównajmy kilka procesów roboczych, kiedy są zbudowane na podstawie kubectl, a kiedy stosowane są OC lub ODO.
• Wdrażanie kodu na OpenShift dla tych, którzy nie znają języka YAML:
Kubernetes / kubectl
$> git clone
1- Tworzymy Dockerfile, który buduje obraz z kodu
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ “npm”, “start” ]
————–
2- Budujemy obraz
$> podman build …
3- Logujemy się do rejestru
podman login …
4- Publikujemy obraz w rejestrze
podman push
5- Tworzymy pliki yaml do wdrażania aplikacji (deployment.yaml, service.yaml, ingress.yaml) – to absolutne minimum.
6- Wdrażamy pliki manifestu:
kubectl apply -f .
OpenShift / oc
$> oc new-app – nazwa_naszej_aplikacji
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Zmiana kontekstu: zmiana przestrzeni nazw roboczej lub roboczego klastra.
Kubernetes / kubectl
1- Tworzymy kontekst w kubeconfig dla projektu „myproject”
2- kubectl set-context …
OpenShift / oc
oc project „myproject”
Kontrola jakości: „Pojawiła się jedna interesująca funkcja, która jest w wersji alfa. Może wprowadzimy ją do produkcji?”
Wyobraź sobie, że sadzą cię w samochodzie wyścigowym i mówią: „Zainstalowaliśmy nowe hamulce, a szczerze mówiąc, nie wszystko jeszcze działa jak powinno... Ale nie martw się, będziemy je aktywnie udoskonalać w trakcie mistrzostw”. Jakie masz perspektywy? Dla nas w Red Hat to nie brzmi zbyt dobrze. 🙂
Dlatego staramy się unikać wersji alfa, dopóki nie osiągną one wystarczającego poziomu dojrzałości i nie przeprowadzimy dokładnego testowania w warunkach rzeczywistych, czując, że można je bezpiecznie używać. Zwykle wszystko przechodzi najpierw przez etap Dev Preview, a następnie przez i dopiero później wychodzi jako publiczna wersja (GA), która jest już wystarczająco stabilna, by mogła być używana w produkcji.
Dlaczego tak jest? Ponieważ, jak przy tworzeniu każdego innego oprogramowania, nie wszystkie początkowe założenia w Kubernetes dochodzą do finalnej wersji. Albo dochodzą, a nawet zachowują zamierzoną funkcjonalność, ale ich realizacja różni się diametralnie od tego, co było w wersji alfa. Ponieważ tysiące klientów Red Hat korzystają z OpenShift do wspierania krytycznych zadań, kładziemy szczególny nacisk na stabilność naszej platformy i długoterminowe wsparcie.
Red Hat celowo wydaje częste aktualizacje OpenShift i aktualizuje wersję Kubernetes, która wchodzi w jej skład. Na przykład, w aktualnej, w momencie pisania tego artykułu, wersji GA OpenShift 4.3 zintegrowano Kubernetes 1.16, który tylko o jeden krok odstaje od upstreamowej wersji Kubernetes o numerze 1.17. Tak więc staramy się dostarczyć klientowi klasowy Kubernetes i zapewnić dodatkową kontrolę jakości podczas wydawania nowych wersji OpenShift.
Poprawki oprogramowania: „W tej wersji Kubernetes, którą mamy w produkcji, znaleziono lukę. A można ją zamknąć tylko aktualizacją o trzy wersje wyżej. Czy są jakieś inne opcje?”
W ramach otwartego projektu Kubernetes poprawki oprogramowania zwykle są wydawane w składzie następnej wersji, czasami obejmują jedną lub dwie poprzednie wersje międzywynikowe, co daje pokrycie z ostatnich sześciu miesięcy.
Red Hat z dumą ogłasza, że wydaje krytyczne poprawki szybciej niż inni i zapewnia wsparcie przez znacznie dłuższy czas. Weźmy na przykład podatność na eskalację uprawnień w Kubernetes (): została wykryta w Kubernetes 1.11, a poprawki dla wcześniejszych wersji wydano jedynie do wersji 1.10.11, pozostawiając tę lukę we wszystkich wcześniejszych wersjach Kubernetes, od 1.x do 1.9.
Z kolei, (gdzie działa Kubernetes 1.2), obejmując dziewięć wydań OpenShift i w jasno sposób demonstrując dbałość o klientów (więcej szczegółów ).
Jak OpenShift i Red Hat rozwijają Kubernetes
Red Hat zajmuje drugie miejsce pod względem wkładu w otwarty projekt Kubernetes, ustępując jedynie Google, a 3 z 5 najbardziej płodnych programistów to pracownicy Red Hat. Jeszcze jeden mało znany fakt: wiele krytycznych funkcji pojawiło się w Kubernetes właśnie dzięki inicjatywie Red Hat, w szczególności takich jak:
- RBAC. W Kubernetes nie było funkcji RBAC (ClusterRole, ClusterRoleBinding), dopóki inżynierowie Red Hat nie zdecydowali się je zaimplementować w ramach samej platformy, a nie jako dodatkową funkcjonalność OpenShift. Czy Red Hat boi się ulepszać Kubernetes? Oczywiście, że nie, bo Red Hat ściśle przestrzega zasad otwartego kodu, a nie gra w gry Open Core. Ulepszenia i nowinki wdrażane na poziomie społeczności deweloperskich, a nie według zasad własności, stają się bardziej trwałe i zyskują szersze zastosowanie, co doskonale współczesne z naszym głównym celem – uczynić oprogramowanie z otwartym kodem bardziej przydatnym dla naszych klientów.
- Polityki bezpieczeństwa dla podów (Pod Security Policies). Początkowo ta koncepcja bezpiecznego uruchamiania aplikacji w ramach podów została wprowadzona w OpenShift pod nazwą SCC (Security Context Constraints). I tak jak w poprzednim przykładzie, Red Hat postanowił włączyć te osiągnięcia do składu otwartego projektu Kubernetes, aby mogły z nich korzystać wszyscy chętni.
Ten szereg przykładów można kontynuować, ale chcieliśmy jedynie pokazać, że Red Hat naprawdę dąży do rozwoju Kubernetes i uczynienia go lepszym dla wszystkich.
Oczywiście, OpenShift to Kubernetes. A jakie są różnice? 🙂
Mamy nadzieję, że docierając do tego miejsca, zrozumieliście, że Kubernetes jest kluczowym komponentem OpenShift. Kluczowym, ale nie jedynym. Innymi słowy, po prostu zainstalowanie Kubernetesa nie sprawi, że otrzymacie platformę klasy enterprise. Będziecie musieli dodać uwierzytelnianie, sieć, bezpieczeństwo, monitorowanie, zarządzanie logami i wiele więcej. Ponadto będziecie musieli dokonać trudnego wyboru spośród wielu dostępnych narzędzi (aby ocenić różnorodność ekosystemu, wystarczy spojrzeć na ) i jakoś zapewnić spójność i synchronizację, aby działały jako całość. Ponadto regularnie będziecie musieli przeprowadzać aktualizacje i testy regresyjne przy wydaniu nowej wersji któregokolwiek z używanych komponentów. Oznacza to, że oprócz budowy i wsparcia samej platformy, będziecie musieli zajmować się także tym całym oprogramowaniem. W mało prawdopodobne, że zostanie wiele czasu na rozwiązywanie problemów biznesowych i osiąganie przewag konkurencyjnych.
W przypadku OpenShift firma Red Hat przejmuje na siebie wszystkie te trudności i po prostu oferuje funkcjonalną platformę, która obejmuje nie tylko samego Kubernetesa, ale także cały zestaw niezbędnych narzędzi z otwartym kodem, które przekształcają Kubernetesa w prawdziwe rozwiązanie klasy enterprise, które można bezpośrednio i zupełnie spokojnie uruchomić w produkcji. Oczywiście, jeśli macie jakieś własne stosy technologiczne, możecie zintegrować OpenShift z istniejącymi rozwiązaniami.
Spójrzcie na rysunek powyżej: wszystko, co znajduje się poza prostokątem Kubernetesa, to obszary, w których Red Hat dodaje funkcjonalności, których brakuje w Kubernetes, mówiąc, że są one zaprojektowane. A teraz przyjrzymy się głównym z tych obszarów.
1. Niezawodny system operacyjny jako podstawa: RHEL CoreOS lub RHEL
Red Hat od ponad 20 lat jest wiodącym dostawcą dystrybucji Linux dla krytycznych aplikacji biznesowych. Zdobyte i stale aktualizowane doświadczenie w tej dziedzinie pozwala nam zaoferować naprawdę niezawodną i zaufaną podstawę do przemysłowej eksploatacji kontenerów. RHEL CoreOS wykorzystuje to samo jądro co RHEL, ale jest optymalizowane przede wszystkim do zadań takich jak uruchamianie kontenerów i praca w klastrach Kubernetes: jego zmniejszony rozmiar i niezmienność (immutability) upraszczają instalację klastrów, automatyczne skalowanie, wdrażanie poprawek itp. Wszystkie te funkcje sprawiają, że jest idealną podstawą do uzyskania jednolitego doświadczenia użytkownika podczas pracy z OpenShift w różnych środowiskach obliczeniowych, od „gołego sprzętu” po prywatne i publiczne chmury.
2. Automatyzacja operacji IT
Automatyzacja procesów instalacji i operacji drugiego dnia (czyli codziennej eksploatacji) to mocna strona OpenShift, która znacznie ułatwia administrację, aktualizację i utrzymanie pomyślnej pracy platformy kontenerowej. Osiąga się to dzięki wsparciu operatorów Kubernetes na poziomie jądra OpenShift 4.
OpenShift 4 to także cały ekosystem rozwiązań opartych na operatorach Kubernetes, opracowanych zarówno przez Red Hat, jak i partnerów zewnętrznych (zob. Red Hat, lub sklep operatorów , stworzony przez Red Hat dla zewnętrznych deweloperów).
Zintegrowany katalog OpenShift 4 zawiera ponad 180 operatorów Kubernetes
3. Narzędzia dla deweloperów
Od 2011 roku OpenShift dostępna jest jako platforma PaaS (Platform-as-a-Service), która znacznie ułatwia życie programistom, pomagając im skupić się na tworzeniu kodu i oferując wbudowane wsparcie dla takich języków programowania jak Java, Node.js, PHP, Ruby, Python, Go, oraz usługi ciągłej integracji i dostarczania CI/CD, bazy danych itd. OpenShift 4 oferuje , obejmujący ponad 100 usług opartych na operatorach Kubernetes opracowanych przez Red Hat i naszych partnerów.
W przeciwieństwie do Kubernetes, OpenShift 4 posiada specjalny interfejs graficzny (), pomagający programistom z łatwością wdrażać w swoich przestrzeniach nazw aplikacje z różnych źródeł (git, zewnętrzne rejestry, Dockerfile itd.) i wizualizujący relacje między komponentami aplikacji.
Co więcej, OpenShift oferuje zestaw narzędzi deweloperskich Codeready, w tym m.in. , w pełni konteneryzowane IDE z interfejsem webowym, działające bezpośrednio na OpenShift i realizujące model „IDE jako usługa”. Z drugiej strony, dla tych, którzy chcą pracować wyłącznie w trybie lokalnym, dostępne są Codeready Containers – pełnoprawna wersja OpenShift 4, którą można wdrożyć na laptopie.
Zintegrowane „IDE jako usługa” do efektywnego rozwoju na platformie Kubernetes/OpenShift.
Od razu po zainstalowaniu OpenShift oferuje pełny system CI/CD, zarówno oparty na konteneryzowanym Jenkinsie i wtyczce do pracy z pipeline'ami, jak i system CI/CD ukierunkowany na Kubernetes (aktualnie w wersji Tech preview). Oba te rozwiązania są w pełni zintegrowane z konsolą OpenShift, umożliwiając uruchamianie wyzwalaczy pipeline'ów, przeglądanie wdrożeń, logów itd.
4. Narzędzia dla aplikacji
OpenShift umożliwia wdrażanie zarówno tradycyjnych aplikacji stateful, jak i rozwiązań opartych na chmurze, wykorzystujących nowe architektury, takie jak mikroserwisy czy serverless. Rozwiązanie OpenShift Service Mesh od razu dostarcza kluczowe narzędzia do zarządzania mikroserwisami, takie jak Istio, Kiali i Jaeger. Z kolei rozwiązanie OpenShift Serverless obejmuje nie tylko Knative, ale także stworzone w ramach wspólnej inicjatywy z Microsoft narzędzia, takie jak Keda, do zapewniania funkcji Azure na platformie OpenShift.
Zintegrowane rozwiązanie OpenShift ServiceMesh (Istio, Kiali, Jaeger) będzie przydatne przy rozwijaniu mikroserwisów.
Aby zmniejszyć różnicę między aplikacjami dziedziczonymi a kontenerami, OpenShift teraz umożliwia migrację maszyn wirtualnych na platformę OpenShift za pomocą Container Native Virtualization (aktualnie w wersji Tech Preview), przekształcając hybrydowe aplikacje w rzeczywistość i ułatwiając ich przenoszenie między różnymi chmurami, zarówno prywatnymi, jak i publicznymi.
Maszyna wirtualna Windows 2019 Virtual uruchomiona na OpenShift za pośrednictwem Container Native Virtualization (aktualnie w wersji Tech preview).
5. Narzędzia dla klastrów
Każda platforma klasy enterprise powinna mieć usługi monitorowania i centralnego zarządzania logami, mechanizmy bezpieczeństwa, autoryzacji i uwierzytelnienia oraz narzędzia do zarządzania siecią. OpenShift dostarcza to wszystko w jednym pakiecie, przy czym całość oparta jest w 100% na otwartym kodzie, w tym rozwiązania takie jak ElasticSearch, Prometheus, Grafana. Wszystkie te rozwiązania są dostarczane z gotowymi panelami informacyjnymi, metrykami i powiadomieniami, które zostały skonfigurowane z uwzględnieniem ogromnego doświadczenia Red Hat w zakresie monitorowania klastrów, co pozwala na efektywne kontrolowanie i śledzenie pracy środowiska produkcyjnego od samego początku.
W OpenShift dostępne są również kluczowe dla klientów korporacyjnych funkcje, takie jak uwierzytelnianie z wbudowanym dostawcą OAuth, integracja z dostawcami danych, w tym LDAP, ActiveDirectory, OpenID Connect i wiele innych.
Wstępnie skonfigurowany panel informacyjny Grafana do monitorowania klastra OpenShift
Ponad 150 wstępnie skonfigurowanych metryk i powiadomień Prometheus do monitorowania klastra OpenShift
Ciąg dalszy nastąpi
Bogata funkcjonalność rozwiązania i szerokie doświadczenie Red Hat w zakresie Kubernetes – z tych powodów OpenShift zajął dominującą pozycję na rynku, co pokazano na rysunku poniżej (więcej informacji ).
„W tej chwili Red Hat prowadzi na rynku z udziałem wynoszącym 44%.
Firma zbiera korzyści ze swojej strategii sprzedaży z aktywnym udziałem w sprawach klienta, w ramach której najpierw doradza i szkoli korporacyjnych deweloperów, a następnie przechodzi do monetyzacji, gdy firma zaczyna wdrażać kontenery w produkcji.”
(Źródło: )
Mamy nadzieję, że podobał Ci się ten artykuł. W kolejnych postach z tej serii bliżej przyjrzymy się zaletom OpenShift w porównaniu do Kubernetes w każdej z omawianych tutaj kategorii.
Źródło: habr.com
