Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Tworzenie podów z linii komend w Kubernetesie 1.18

Luc Juggery Freelance Docker & Kubernetes trainer
Sprawdź, jak zmieniło się polecenie kubectl run w najnowszej wersji Kubernetesa oraz jak tworzyć tam pody z linii komend.
Tworzenie podów z linii komend w Kubernetesie 1.18

Kubernetes 1.18 został wydany pod koniec marca 2020 roku. Spośród wszystkich ulepszeń, które pojawiły się w tym wydaniu, tutaj skupimy się na poleceniu kubectl run, którego dosyć ciężko się do tej pory używało.


Imperatywny vs. deklaratywny

Istnieją dwa sposoby tworzenia zasobów w klastrze Kubernetes: imperatywny i deklaratywny. Podejście deklaratywne służy do tworzenia zasobów z plików manifestu (zwykle w YAML) przy użyciu polecenia kubectl apply. Takie podejście stosuje się w środowisku produkcyjnym. Tryb imperatywny służy do zarządzania zasobami za pomocą kilku różnych poleceń i nie wymaga żadnych plików manifestu.

Nie należy używać tego podejścia na produkcji, ale przydaje się to do szybkiego testowania rzeczy. Może to także pomóc w generowaniu plików manifestów (używając kombinacji flag --dry-run i -o yaml).


Przed 1.18

W wersji starszej niż 1.18 możliwe było uruchomienie podów i innych zasobów za pomocą polecenia kubectl run. Aby to pokazać, używamy kubectl 1.17.0 i klastra K3s w wersji 1.17.2.

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"17",
GitVersion:"v1.17.0",
GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf",
GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z",
GoVersion:"go1.13.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17",
GitVersion:"v1.17.2+k3s1",
GitCommit:"cdab19b09a84389ffbf57bebd33871c60b1d6b28",
GitTreeState:"clean", BuildDate:"2020-01-27T18:09:26Z",
GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}


Widzimy, że polecenie kubectl run pozwala nam uruchomić określony obraz (czytaj: stworzyć pod), ale także utworzyć inne zasoby (deployment, job):

$ kubectl run --helpCreate and run a particular image, possibly replicated.
Creates a deployment or job to manage the created container(s).


To proste polecenie pozwala nam stworzyć deployment:

$ kubectl run www --image=nginx:1.16
kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be
removed in a future version. Use kubectl run --generator=run-pod/v1
or kubectl create instead.
deployment.apps/www created


Otrzymujemy komunikat z ostrzeżeniem, ponieważ flaga --generator=deployment/apps.v1 (domyślnie używana, ponieważ nie udostępniamy żadnych innych flag) jest przestarzała. Zaleca się użycie flagi --generator=run-pod/v1, jeśli chcemy utworzyć pod zamiast deploymentu.

$ kubectl run --generator=run-pod/v1 www-1 --image=nginx:1.16
pod/www-1 created


Działa to dobrze, ale nie jest zbyt wygodne (trudno zapamiętać dokładną składnię i prawidłowe ustawienie opcji za pierwszym razem). Innym sposobem na wyciągnięcie podu z komendy kubectl run jest użycie flagi --restart=Never:

$ kubectl run www-2 --image=nginx:1.16 --restart=Never
pod/www-2 created


Czy zamiast tego chcesz stworzyć zasób typu job? Wystarczy użyć flagi --restart=OnFailure lub --generator= job/v1.

$ kubectl run hello --image=hello-world --restart=OnFailure
kubectl run --generator=job/v1 is DEPRECATED and will be removed in a
future version. Use kubectl run --generator=run-pod/v1 or kubectl
create instead.
job.batch/hello created


Jak możemy zobaczyć wyżej, --generator=job/v1 (wynikające z użycia flagi --restart=OnFailure) również jest przestarzałą opcją. Komunikaty o wycofaniu określonych opcji, które otrzymaliśmy w powyższych poleceniach, były tam od bardzo dawna. Jak widać, możliwość użycia różnych generatorów, a także różnych wartości dla flagi --restart skomplikowało to polecenie.


Nowości w Kubernetes 1.18

Wraz z wydaniem 1.18 wszystko stało się znacznie prostsze, ponieważ kubectl run jest teraz używane tylko do tworzenia podu; nie ma już dwuznacznych flag. Aby to pokazać, używamy kubectl 1.18.0 dla tego samego klastra K3s 1.17.2.

$ kubectl version
Client Version: version.Info{Major:”1", Minor:”18",
GitVersion:”v1.18.0",
GitCommit:”9e991415386e4cf155a24b1da15becaa390438d8",
GitTreeState:”clean”, BuildDate:”2020–03–25T14:58:59Z”,
GoVersion:”go1.13.8", Compiler:”gc”, Platform:”linux/amd64"}
Server Version: version.Info{Major:”1", Minor:”17",
GitVersion:”v1.17.2+k3s1",
GitCommit:”cdab19b09a84389ffbf57bebd33871c60b1d6b28",
GitTreeState:”clean”, BuildDate:”2020–01–27T18:09:26Z”,
GoVersion:”go1.13.6", Compiler:”gc”, Platform:”linux/amd64"}


Uwaga
: Jeśli nie masz jeszcze zainstalowanego programu kubectl 1.18, możesz uruchomić kontener z obrazu lucj/k8stools:1.18.0. Musisz tylko podać plik kubeconfig, a będziesz mógł współpracować ze swoim klastrem w wersji wcześniejszej niż 1.18 za pomocą kubectl 1.18. Ten obraz również zawiera wiele przydatnych narzędzi, takich jak kubectx/kubens, kube-ps1, kubectl-aliasses, klienty Helm w wersji 2 i 3 oraz świetny interfejs K9s.

$ docker run -ti -v $PATH_TO_KUBECONFIG:/kubeconfig 
lucj/k8stools:1.18.0


Strona pomocy komendy kubectl run się nieco zmieniła w wersji 1.18:

$ kubectl run --helpCreate and run a particular image in a pod.


Utwórz i uruchom konkretny obraz w podzie. Teraz jest to o wiele bardziej przejrzyste, ponieważ polecenie służy tylko do tworzenia podu. Uruchommy prosty NGINX.

$ kubectl run www --image=nginx:1.16
pod/www created


Nie ma więcej komunikatów o przestarzałej wartości flagi, czy żadnych bardziej skomplikowanych flag do wyboru rodzaju zasobów do utworzenia. Wszystko jest o wiele bardziej zrozumiałe. Celem była tu zmiana kubectl run, by bardziej przypominało to dobrze znaną komendę docker run. Podczas gdy komenda Dockera tworzy kontener, to komenda Kubernetesa tworzy pod.


A co z innymi zasobami?

Jeśli musimy utworzyć inne zasoby w sposób imperatywny, możemy użyć polecenia kubectl create. Nie wprowadzono jednak żadnych zmian dotyczących tych poleceń w wersji 1.18.

Zasoby, które można utworzyć za pomocą kubectl create


Na przykład utworzenie delpoymentu na podstawie nginx:1.16 można wykonać za pomocą następującego polecenia — każdy zasób ma swój własny zestaw parametrów:

$ kubectl create deployment w3 --image=nginx:1.16
deployment.apps/w3 created


W przypadku, gdy musimy wygenerować podstawowy plik manifestu do deploymentu, użycie zarówno opcji --dry-run, jak i flagi -o yaml jest bardzo przydatne, ponieważ pokazuje, jak zasób zostałby utworzony bez faktycznego wykonywania procesu:

$ kubectl create deployment w3 --image=nginx:1.16 --dry-run -o yaml
apiVersion: apps/v1
kind: Deployment
metadata:
     creationTimestamp: null
     labels:
        app: w3
     name: w3
spec:
    replicas: 1
    selector:
       matchLabels:
            app: w3
    strategy: {}
    template:
       metadata:
            creationTimestamp: null
            labels:
               app: w3
            spec:
            containers:
            - image: nginx:1.16
              name: nginx
              resources: {}
status: {}


Możemy następnie zmodyfikować specyfikację i usunąć niepotrzebne pola, aby pasowały do naszych potrzeb.


Podsumowanie

Bardzo się cieszę, że w nowej wersji ulepszono kubectl run. Wiadomości o przestarzałych parametrach istniały już od dawna i naprawdę trudno było zrozumieć logikę różnych flag i generatorów.


Oryginał tekstu w języku angielskim przeczytasz tutaj.

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej