‫Pozwól, że opowiem ci o suchych biegach i różnicach,
‫które są nowością.
‫Kilka ostatnich wersji Kubernetes zaczynających się od 1. 13 ma
‫tę nową opcję, która pozwala nam zobaczyć,
‫co zamierzamy zmienić, zanim to zmienimy.
‫Widzieliśmy to już wcześniej.
‫Wcześniej pokazałem kilka przykładów.
‫Ale ta metoda używania go
‫z poleceniem zastosowania jest nowa
‫i lepsza. W przeszłości mieliśmy
‫suchą jazdę, ale to było tylko
‫na kliencie. Klient tak naprawdę nie rozmawiał
‫z serwerem, żeby powiedzieć hej, czy te zasoby już tam są?
‫Czy muszę je ponownie utworzyć, czy będą one aktualizowane lub co
‫się stanie? Dobrze.
‫To się wcześniej nie zdarzyło.
‫Teraz dostępna jest opcja suchego uruchamiania serwera,
‫która wyśle nasz YAML na serwer i porówna, dowie
‫się, co naprawdę musi się wydarzyć, a następnie
‫zgłoś do wiersza poleceń, co
‫się zmieni. Zobaczmy to w akcji.
‫Jestem w katalogu YAML K8s, jak omówiłem wcześniej w
‫wykładzie, jeśli jesteś w repozytorium Docker Mastery i nie
‫masz tego katalogu, musisz
‫zrobić to, aby uzyskać najnowsze aktualizacje.
‫Jest to plik, który widzieliśmy w
‫poprzednim wykładzie, aplikacja. yml. Jest to usługa
‫plus wdrożenie w jednym pliku.
‫Technicznie są tworzone dwa zasoby za pomocą jednego
‫polecenia zastosowania i są one powiązane.
‫Serwis korzysta z selektora, o którym
‫jeszcze nie rozmawialiśmy. Selektory to sposób, w jaki
‫jeden obiekt znajduje zasoby, z którymi chce porozmawiać lub
‫coś zrobić.
‫Usługa musi rozmawiać z zasobnikami, więc musi znaleźć sposób, aby
‫się do nich dostać.
‫Wykorzystuje selektory jako zasadniczo dopasowanie
‫wzorca, aby dopasować etykiety do kluczy
‫i wartości. Gdybym zrobił tutaj tradycyjny
‫bieg na sucho, wtedy wszystko, co zrobiłby to klient spojrzałby na
‫aplikację i powiedział: tak, zamierzam stworzyć te obiekty.
‫W porządku. Zawsze będzie wracać i mówić, że został stworzony.
‫Jest tak, ponieważ zastosowanie nie jest
‫bardzo szczegółowe. Jeśli korzystasz z polecenia aktualizacji,
‫tworzenia lub usuwania, co znowu nie wydaje mi się,
‫że jest to bardzo oparty na DevOps przepływ pracy.
‫Te polecenia wykonałyby tylko próbę na sucho i
‫wiesz, że powiedzielibyście aktualizację, tak,
‫obie zostaną zaktualizowane. Ale tak naprawdę nie wie o
‫twoim klastrze, prawda. Nie rozmawiał z serwerem, aby to rozgryźć.
‫Chcemy wypróbować serwer na sucho, który jest domyślnie
‫włączony na dowolnym urządzeniu 1. 13 i nowsze.
‫Kiedy to zrobię, porozmawia z serwerem i da
‫mi właściwą odpowiedź.
‫Chodźmy i stwórzmy to.
‫Mam zamiar zdjąć serwer na sucho.
‫Spowoduje to utworzenie dwóch zasobów, wdrożenia
‫i usługi.
‫Teraz, jeśli uderzę strzałkę w górę i wrócę do próbnego uruchomienia serwera,
‫zobaczysz, że dla obu z nich jest napisane niezmienione.
‫Nie mówi mi, co się zmieniło lub czy było
‫coś, co miało zmienić to, co
‫by to było. Mówi mi tylko, że
‫zasób zostanie zmieniony lub nie. To rodzaj przełączania, tak lub nie.
‫Co z uzyskaniem faktycznej różnicy między tym, co chcemy
‫dać serwerowi, a tym, jaki jest
‫obecny stan naszych zasobów.
‫To jest polecenie kubectl diff.
‫Jeśli po prostu dam mu różnicę
‫zamiast aplikować, porównam posiadaną przeze mnie
‫YAML ze specyfikacją na serwerach, które są
‫teraz uruchomione. ten status powraca i na pewno
‫to zmieni. Zróbmy to.
‫Nic nie powie, bo nie ma różnicy.
‫Ale co, jeśli pójdziemy zmienić YAML?
‫Co jeśli zmienię repliki na dwie?
‫Następnie dodam etykietę do metadanych i dam jej coś
‫w rodzaju ... coś jak.
‫Serwery dmz.
‫Wymyśliłem to. To naprawdę nie ma znaczenia.
‫Następnie mamy repliki dwóch.
‫Jeśli zrobię tę samą różnicę, wróci z plusami
‫i minusami.
‫Jeśli jesteś przyzwyczajony do czytania różnic, ma to
‫dla ciebie idealny sens. Jeśli nie jesteś przyzwyczajony do
‫różnic, minus oznacza, że linia zniknie.
‫Następnie te linie zostaną dodane.
‫Następnie tutaj pokazuje, która linia i jaki znak
‫w linii, że jest ona
‫usuwana.
‫To jest dodawane.
‫Zachowuje formatowanie YAML, co jest miłe.
‫Informuje nas, że dzieje się wiele zmian.
‫Wspaniały. Oczywiście tak naprawdę to nie robi
‫czegoś takiego jak kanarek, testowe wdrożenie lub cokolwiek innego.
‫To nie jest próba zrobienia czegoś, a następnie zobaczenie,
‫jaki jest rezultat. Po prostu patrzy na
‫specyfikację, którą zapisał, oraz specyfikację, którą mamy na
‫dysku. Sprawdź więcej
‫informacji na ten temat w linkach do zasobów.
‫Jest to artykuł na blogu od zespołu Kubernetes na temat
‫ich przyszłości i tego, w jaki sposób będą grać, gdy
‫wyjdą z wersji beta. Pamiętaj, że te funkcje są obecnie w
‫wersji beta, przynajmniej w 1. 15 są.
‫Mamy nadzieję, że dzięki temu możesz stworzyć swój
‫własny przepływ pracy do tworzenia
‫YAML od podstaw, Zarządzania specyfikacjami w tych YAML, a następnie
‫za pomocą polecenia Apply, aby wprowadzić zmiany.
‫Jest to o wiele bardziej przyjazna dla DevOps infrastruktura
‫jako sposób na zrobienie tego.
‫Mam nadzieję, że wszystko, co robisz, jest udokumentowane w Git.
‫Mamy więc nadzieję, że dokonujesz git-commit dla każdej zmiany
‫dokonanej w YAML przed wdrożeniem go na serwerze.
‫Następnie masz tę dobrą dokumentację w Git, a także
‫dokumentację, gdy robisz coś w rodzaju porównania, aby zobaczyć, co
‫masz w porównaniu z tym, co faktycznie działa.