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.