Kubernetes prakticky: finty pro ovládaní aneb kdy CLI a kdy GUI a jaké

Ovládání Kubernetes je velmi milé a přirozené a osobně toho hodně dělám přímo z příkazové řádky s použitíme kubectl. Podívejme se dnes na pár fintiček, které mám rád. A co GUI? Kubernetes nabízí svůj dashboard, ale AKS cluster má krásnou monitorovací záložku a je tu také plug-in do Visual Studio Code. Kdy co použít a co bych preferoval já?

Kouzla s kubectl

Příkazová „rádka“ Kubernetes je opravdu velmi mocná a nabízí mnoho zajímavostí pro troubleshooting a monitoring. Pojďme si ukázat pár mých oblíbených.

Kontexty

Kubectl používá konfigurační soubor defaultně uložený v ~/.kube/config a v něm jsou informace o clusterech a kontextech. Můžete v něm sdružovat přístupové informace hned k několika clusterům. Po instalaci AKS jej můžete naplnit příkazem az aks get-credantials -n jmenoaks -g resourcegroup, což vám stáhne potřebné klíče a založí přístup pro AAD login, ve kterém jste přihlášeni (protože AKS má defaultně zapnoutou integraci RBAC s Azure Active Directory). Můžete také použít přepínač –admin a to vám stáhne administrátorský univerzální login (s tím opatrně, používejte raději AAD). Zajímavým konceptem jsou právě kontexty, tedy schopnost přepnout se na jiný cluster, jiného uživatele nebo jiný namespace.

Podívejme se jaké mám kontexty já.

$ kubectl config get-contexts
CURRENT   NAME               CLUSTER      AUTHINFO                           NAMESPACE
          akscluster         akscluster   clusterUser_aksgroup_akscluster
*         akscluster-admin   akscluster   clusterAdmin_aksgroup_akscluster

Mám tedy AAD login a admin login. Pracuji v default namespace a jako admin mám právo přistupovat i do jiných namespaců, ale musím to vždy explicitně říct.

Tak například v namespace default nemám nic a chci pracovat s Pody v namespace tomas. Abych to mohl udělat (práva na to mám) musím ale vždy používat přepínač definující namespace, když chci mimo defaultní.

$ kubectl get pods
No resources found.
$ kubectl get pods -n tomas
NAME      READY     STATUS    RESTARTS   AGE
mujpod    1/1       Running   0          49s

To je ale někdy otrava. Často zapomenu přepínač napsat a jsem jinde, než potřebuji. Pojďme tedy vytvořit kontext, který mě namíří rovnou do namespace tomas. Následně se do kontextu přepnu a nemusím dokola zadávat, že chci pracovat se zdroji v namespace tomas.

$ kubectl config set-context tomas --cluster akscluster --user clusterAdmin_aksgroup_akscluster --namespace tomas
Context "tomas" created.
$ kubectl config get-contexts
CURRENT   NAME               CLUSTER      AUTHINFO                           NAMESPACE
          akscluster         akscluster   clusterUser_aksgroup_akscluster
*         akscluster-admin   akscluster   clusterAdmin_aksgroup_akscluster
          tomas              akscluster   clusterAdmin_aksgroup_akscluster   tomas
$ kubectl config use-context tomas
Switched to context "tomas".
$ kubectl get pods
NAME      READY     STATUS    RESTARTS   AGE
mujpod    1/1       Running   0          3m

Streaming

Často potřebuji sledovat co se děje, třeba jak se přidávají nebo odebírají Pody. Mohl bych dokola opakovat příkaz kubectl get pods (třeba watchem), ale to se mi moc nelíbí. Kubectl má možnost streamovat změny na obrazovku. Nevýhodou je, že se při tom rozpadne formátování, takže je to méně přehledné, nicméně vidím v reálném čase jaké změny se dějí. Na to je výborný přepínač -w

$ kubectl get pods -w
NAME                            READY     STATUS              RESTARTS   AGE
mujdeployment-896f9ffbc-5czr4   0/1       ContainerCreating   0          1s
mujdeployment-896f9ffbc-5ht46   0/1       ContainerCreating   0          1s
mujdeployment-896f9ffbc-bbz7z   0/1       ContainerCreating   0          1s
mujdeployment-896f9ffbc-fdb5q   0/1       ContainerCreating   0          2s
mujdeployment-896f9ffbc-whkwb   0/1       ContainerCreating   0          1s
mujpod                          1/1       Running             0          7m
mujdeployment-896f9ffbc-5ht46   1/1       Running   0         6s
mujdeployment-896f9ffbc-fdb5q   1/1       Running   0         7s
mujdeployment-896f9ffbc-whkwb   1/1       Running   0         23s
mujdeployment-896f9ffbc-5czr4   1/1       Running   0         23s
mujdeployment-896f9ffbc-bbz7z   1/1       Running   0         25s

Wide

Nezapomínejte, že existuje přepínač -o wide, který přidá víc informací. Například u výpisu Podů vám ukáže, na kterém nodu běží.

$ kubectl get pods -o wide
NAME                            READY     STATUS    RESTARTS   AGE       IP              NODE
mujdeployment-896f9ffbc-5czr4   1/1       Running   0          1m        192.168.0.242   aks-nodepool1-38238592-2
mujdeployment-896f9ffbc-5ht46   1/1       Running   0          1m        192.168.0.160   aks-nodepool1-38238592-1
mujdeployment-896f9ffbc-bbz7z   1/1       Running   0          1m        192.168.0.233   aks-nodepool1-38238592-2
mujdeployment-896f9ffbc-fdb5q   1/1       Running   0          1m        192.168.0.240   aks-nodepool1-38238592-2
mujdeployment-896f9ffbc-whkwb   1/1       Running   0          1m        192.168.0.147   aks-nodepool1-38238592-1
mujpod                          1/1       Running   0          8m        192.168.0.117   aks-nodepool1-38238592-1

Labely

Jak už určitě víte objektům lze dávat labely a můžeme si je zobrazit na výpisu.

$ kubectl get pods --show-labels
NAME                            READY     STATUS    RESTARTS   AGE       LABELS
dalsipod                        1/1       Running   0          38s       app=tomas
mujdeployment-896f9ffbc-5czr4   1/1       Running   0          3m        pod-template-hash=452959967,run=mujdeployment
mujdeployment-896f9ffbc-5ht46   1/1       Running   0          3m        pod-template-hash=452959967,run=mujdeployment
mujdeployment-896f9ffbc-bbz7z   1/1       Running   0          3m        pod-template-hash=452959967,run=mujdeployment
mujdeployment-896f9ffbc-fdb5q   1/1       Running   0          3m        pod-template-hash=452959967,run=mujdeployment
mujdeployment-896f9ffbc-whkwb   1/1       Running   0          3m        pod-template-hash=452959967,run=mujdeployment
mujpod                          1/1       Running   0          11m       run=mujpod

Konkrétní label (jeho key) můžeme také vypsat jako samostatný sloupeček.

$ kubectl get pods -L run
NAME                            READY     STATUS    RESTARTS   AGE       RUN
dalsipod                        1/1       Running   0          1m
mujdeployment-896f9ffbc-5czr4   1/1       Running   0          4m        mujdeployment
mujdeployment-896f9ffbc-5ht46   1/1       Running   0          4m        mujdeployment
mujdeployment-896f9ffbc-bbz7z   1/1       Running   0          4m        mujdeployment
mujdeployment-896f9ffbc-fdb5q   1/1       Running   0          4m        mujdeployment
mujdeployment-896f9ffbc-whkwb   1/1       Running   0          4m        mujdeployment
mujpod                          1/1       Running   0          11m       mujpod

Podle labelů se dá také vhodně filtrovat. Takhle třeba vypíšeme pouze Pody obsahující label run.

$ kubectl get pods -l run
NAME                            READY     STATUS    RESTARTS   AGE
mujdeployment-896f9ffbc-5czr4   1/1       Running   0          5m
mujdeployment-896f9ffbc-5ht46   1/1       Running   0          5m
mujdeployment-896f9ffbc-bbz7z   1/1       Running   0          5m
mujdeployment-896f9ffbc-fdb5q   1/1       Running   0          5m
mujdeployment-896f9ffbc-whkwb   1/1       Running   0          5m
mujpod                          1/1       Running   0          12m

Nebo Pody obsahující label run s hodnotou mujpod.

$ kubectl get pods -l run=mujpod
NAME      READY     STATUS    RESTARTS   AGE
mujpod    1/1       Running   0          12m

Describe

Pokud chcete zjistit co se s kontejnerem děje, jak je nastaven a jaké události se ho týkají, použijte describe.

$ kubectl describe pod web-577694c698-5d6zh
Name:               web-577694c698-5d6zh
Namespace:          tomas
Priority:           0
PriorityClassName:  <none>
Node:               aks-nodepool1-38238592-1/192.168.0.105
Start Time:         Fri, 17 Aug 2018 08:38:36 +0200
Labels:             pod-template-hash=1332507254
                    run=web
Annotations:        <none>
Status:             Running
IP:                 192.168.0.177
Controlled By:      ReplicaSet/web-577694c698
Containers:
  web:
    Container ID:   docker://a28dc998bbd3de3f9b57c601478ec80c81a922db4672d47cdfbfbed7a2b7b763
    Image:          nginx:alpine
    Image ID:       docker-pullable://nginx@sha256:23e4dacbc60479fa7f23b3b8e18aad41bd8445706d0538b25ba1d575a6e2410b
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Fri, 17 Aug 2018 08:38:42 +0200
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wnj67 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  default-token-wnj67:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-wnj67
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type    Reason     Age   From                               Message
  ----    ------     ----  ----                               -------
  Normal  Scheduled  49s   default-scheduler                  Successfully assigned tomas/web-577694c698-5d6zh to aks-nodepool1-38238592-1
  Normal  Pulled     44s   kubelet, aks-nodepool1-38238592-1  Container image "nginx:alpine" already present on machine
  Normal  Created    43s   kubelet, aks-nodepool1-38238592-1  Created container
  Normal  Started    43s   kubelet, aks-nodepool1-38238592-1  Started container

Port-forwarding

Výborná věc je schopnost vytvořit síťový šifrovaný tunel mezi vašim počítačem a Podem nebo Service. Díky tomu můžete snadno ověřit co váš web server vlastně píše aniž by bylo nutné to dělat z jiného Podu nebo vystrčit službu ven. Lokálně přes 127.0.0.1 a přidělený port můžete s Pod nebo Service komunikovat.

$ kubectl get service,pod
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/web   ClusterIP   192.168.6.236   <none>        80/TCP    2m

NAME                       READY     STATUS    RESTARTS   AGE
pod/web-577694c698-5d6zh   1/1       Running   0          2m
pod/web-577694c698-pvlrd   1/1       Running   0          2m
pod/web-577694c698-rhnns   1/1       Running   0          2m
$ kubectl port-forward pod/web-577694c698-5d6zh :80
Forwarding from 127.0.0.1:3902 -> 80
Forwarding from [::1]:3902 -> 80
Handling connection for 3902
Handling connection for 3902
^C$ kubectl port-forward service/web :80
Forwarding from 127.0.0.1:3914 -> 80
Forwarding from [::1]:3914 -> 80

Edit

Někdy potřebuji rychle změnit nějaký parametr. Za normálních okolností bych byl zásadně pro úpravu YAML souboru, commit nové verze ve version control systému jako je GitHub nebo VSTS a pak ho do Kubernetes poslal. Ale pro vývoj či testování chce člověk občas něco rychlejšího. Kubectl edit otevře aktuální desired state objektu v editoru, vy uděláte změnu, vyskočíte a on ji aplikuje.

$ export EDITOR=nano
$ kubectl edit pod/web-577694c698-5d6zh

Imperativní příkazy

Zásadně doporučuji používat deklarativní model konfigurace, tedy všechny objekty dávat do YAML souborů a ty posílat do Kubernetes příkazem kubectl apply -f. Někdy ale potřebujete velmi rychle něco spustit jen tak na zkoušení a na to jsou dobré imperativní příkazy. Navíc pokud se chystáte na zkoušku CKA, tak tam nebudete mít možnost kopírovat rozsáhlé YAML soubory do prostředí. Vypisovat je ručně je fakt na dlouho a času není nekonečně, takže na CKA zkoušku je velmi dobré znát i imperativní příkazy.

Takhle se například spustí jednoduchý Pod. Musíte dát –restart Never (tedy říkáte, že váš Pod nevyžaduje žádnou další péči typu, že by ho někdo restartoval nebo přesouval když umře Node).

$ kubectl run mujpod --restart Never --image nginx:alpine
pod "mujpod" created
$ kubectl get pod
NAME      READY     STATUS              RESTARTS   AGE
mujpod    0/1       ContainerCreating   0          4s

Přes kubectl run můžeme také vytvořit Deployment ve výchozím stavu s jednou replikou, ale můžeme specifikovat víc.

$ kubectl run mojepody --image nginx:alpine --replicas 3
deployment.apps "mojepody" created
$ kubectl get pods
NAME                        READY     STATUS              RESTARTS   AGE
mojepody-845bc575df-6jsln   0/1       ContainerCreating   0          5s
mojepody-845bc575df-9qbpf   0/1       ContainerCreating   0          5s
mojepody-845bc575df-g2l8r   0/1       ContainerCreating   0          5s
mujpod                      1/1       Running             0          1m

Přímo s kubectl run můžeme také definovat port, který má být v Podu otevřený. A nejen to. Pokud použijeme navíc přepínač expose, kubectl nám rovnou vytvoří Service.

$ kubectl run web1 --image nginx:alpine --port 80 --expose
service "web1" created
deployment.apps "web1" created

$ kubectl get pod,service
NAME                            READY     STATUS    RESTARTS   AGE
pod/mojepody-845bc575df-6jsln   1/1       Running   0          3m
pod/mojepody-845bc575df-9qbpf   1/1       Running   0          3m
pod/mojepody-845bc575df-g2l8r   1/1       Running   0          3m
pod/mujpod                      1/1       Running   0          5m
pod/web1-7dfd7b9658-mrkzl       1/1       Running   0          9s

NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/web1   ClusterIP   192.168.4.135   <none>        80/TCP    9s

Pokud chceme mít Service trochu víc pod kontrolou, například chceme ji definovat jako typ LoadBalancer (dát ji public IP například) nebo ji dát jiné jméno, můžeme to rozdělit a využít kubectl expose.

$ kubectl run web2 --image nginx:alpine --port 80
deployment.apps "web2" created

$ kubectl expose deploy/web2 --port 80 --target-port 80 --type LoadBalancer --name mywebservice
service "mywebservice" exposed

$ kubectl get pod,service
NAME                            READY     STATUS    RESTARTS   AGE
pod/mojepody-845bc575df-6jsln   1/1       Running   0          6m
pod/mojepody-845bc575df-9qbpf   1/1       Running   0          6m
pod/mojepody-845bc575df-g2l8r   1/1       Running   0          6m
pod/mujpod                      1/1       Running   0          7m
pod/web1-7dfd7b9658-mrkzl       1/1       Running   0          2m
pod/web2-8f75d4946-44256        1/1       Running   0          1m

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/mywebservice   LoadBalancer   192.168.5.241   <pending>     80:32479/TCP   19s
service/web1           ClusterIP      192.168.4.135   <none>        80/TCP         2m

Output do yaml

U CKA zkoušky mi moc nevyhovalo probírat se všemi přepínači v imperativních příkazech, běžně používám spíše YAML. Velmi dobré tedy pro mě bylo využít imperativních příkazů pouze k vybudování potřebného skeletonu, který jsem si pak upravil. Využívám na to přepínač –dry-run (věci se nepošlou do Kubernetes) a -o yaml. Ten obsahuje víc věcí, než je potřeba (třeba creationTimeStamp), ale ty si vymažu.

$ kubectl run mypod2 --replicas 3 --image nginx:alpine --dry-run -o yaml > file.yaml
$ cat file.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: mypod2
  name: mypod2
spec:
  replicas: 3
  selector:
    matchLabels:
      run: mypod2
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: mypod2
    spec:
      containers:
      - image: nginx:alpine
        name: mypod2
        resources: {}
status: {}

Podobně je občas fajn se kouknout na běžící věci v YAML formátu. Kubectl describe je fajn, ale je jinak formátovaný a jakmile si na YAML zvyknete, může to být pro vás jednodušší.

$ kubectl get pod mujpod -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: 2018-08-17T06:49:18Z
  labels:
    run: mujpod
  name: mujpod
  namespace: tomas
  resourceVersion: "2530414"
  selfLink: /api/v1/namespaces/tomas/pods/mujpod
  uid: a9aff891-a1e9-11e8-a783-f6acfd690be3
spec:
  containers:
  - image: nginx:alpine
    imagePullPolicy: IfNotPresent
    name: mujpod
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-wnj67
      readOnly: true
...

Logy

Z kubectl můžete koukat na logy v Podech (stderr a stdout). Můžeme použít tail a navíc si zobrazit logy ne starší než jednu hodinu.

kubectl logs mujpod --tail 100 --since 1h -n kube-system

Nabízí se i další zajímavé filtrace. Například přes -l si můžete vypsat logy ze všech Podů vyhovujících nějakému labelu. Můžete také koukat ne na pod, ale třeba deploy/mujdeployment a také streamovat logy s přepínačem -f.

Skok do kontejneru

Jeden z nejčastějších úkonů při ladění aplikací je možnost vlézt dovnitř do kontejneru a odtamtud něco zkusit. Rozjíždět kvůli tomu SSH v kontejneru je zbytečně složité a není to dobrá bezpečností praktika. Do produkce to nepatří a když si na to zvyknete v Dev/Testu znamená to, že budete muset mít jiný obraz pro test a produkci, což popírá jednu z hlavních výhod kontejnerů (tedy že jsou stejné od testu až do produkce). Lepší je tedy odskočit si do Podu přes kubectl exec.

$ kubectl exec -it mujpod -- sh
/ #

Autocomplete v Bash

Pokud si nevezmete na pomoc nějaké GUI je vypisování názvu například Podů docela nepříjemné zejména pokud jsou součástí deploymentu a tím pádem je jejich jméno lidsky složité. Kubectl ale umí vygenerovat autocomplete skripty pro bash. Stačí je načíst do vaší session (nebo to udělat pokaždé v bashrc). Pak napíšu kubectl get pod mojep a zmáčknu tabulátor. Bash mi doplní co se doplnit dá (je unikátní). Velmi dobrá pomůcka.

$ source <(kubectl completion bash)
$ kubectl get pod mojepody-845bc575df-

Nápověda

Kubectl explain obsahuje v zásadě dokumentaci Kubernetes API, kterou máte k dispozici i bez brouzdání Internetem.

$ kubectl explain pod
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#resources

   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata

   spec <Object>
     Specification of the desired behavior of the pod. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status

   status       <Object>
     Most recently observed status of the pod. This data may not be up to date.
     Populated by the system. Read-only. More info:
     https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status

$ kubectl explain pod.spec.volumes.azureDisk
KIND:     Pod
VERSION:  v1

RESOURCE: azureDisk <Object>

DESCRIPTION:
     AzureDisk represents an Azure Data Disk mount on the host and bind mount to
     the pod.

     AzureDisk represents an Azure Data Disk mount on the host and bind mount to
     the pod.

FIELDS:
   cachingMode  <string>
     Host Caching mode: None, Read Only, Read Write.

   diskName     <string> -required-
     The Name of the data disk in the blob storage

   diskURI      <string> -required-
     The URI the data disk in the blob storage

   fsType       <string>
     Filesystem type to mount. Must be a filesystem type supported by the host
     operating system. Ex. "ext4", "xfs", "ntfs". Implicitly inferred to be
     "ext4" if unspecified.

   kind <string>
     Expected values Shared: multiple blob disks per storage account Dedicated:
     single blob disk per storage account Managed: azure managed data disk (only
     in managed availability set). defaults to shared

   readOnly     <boolean>
     Defaults to false (read/write). ReadOnly here will force the ReadOnly
     setting in VolumeMounts.

Kubernetes Dashboard

Řeknu vám to rovnou. Kubernetes Dashboard mě nanadchnul. Není tam nic převratně užitečného, není zabezpečený (autentizace, šifrování) a já ho moc nepoužívám. V clusteru ovšem běží jako interní service (ale nepublikujte si ho ven na public adresu z bezpečnostních důvodů, leda třeba přes zabezpečený Ingress a na něm si vyřeště nějakou rozumnou autentizaci třeba integrací ingress na AAD, což najdete na mém GitHubu).

Pokud máte v clusteru zapnutý RBAC (což je v AKS default) musíte pro Dashboard zařídit nejdřív práva.

kubectl create clusterrolebinding kubernetes-dashboard --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

Připojit se do něj můžete před port-forward na service případně použít příkaz az aks browse.

$ kubectl port-forward service/kubernetes-dashboard 12345:80 -n kube-system
Forwarding from 127.0.0.1:12345 -> 9090
Forwarding from [::1]:12345 -> 9090

Když ale pominu děravou bezpečnost dělá GUI to co má a dá se s ním v pohodě pracovat.

Azure Kubernetes Service health a logování

AKS jako přidanou hodnotu nabízí monitoring a logování přímo do Azure, což si při vytváření clusteru můžete zapnout.

Takhle vypadá přehledová obrazovka vašeho clusteru.

Můžeme kouknout na Nody a co na nich běží (mc znamená milicore a 1000 mc je tedy jeden core).

Sledovat můžeme minimum, maximum, průměr nebo percentily.

Totéž lze sledovat z pohledu paměti.

Zkoumat můžeme samozřejmě i jednotlivé Pody.

Všimněte si tlačítka nahoře, které nás přesune do Log Analytics a předformuluje vyhledávací dotaz, abychom viděli logy z tohoto Podu.

Podívat se ale můžeme klidně i na všechny logy najednou.

Je to nesmírně mocný engine Log Analytics, který můžete využít i pro logování z VM, platformních služeb a je i pod kapotou aplikačního monitoringu Application Insights. Povídání o něm do tohoto článku nepatří, ale můžete si ho například vyzkoušet zdarma na adrese https://docs.loganalytics.io/

Protože jsou všechny metriky v Azure Log Analytics, můžete je snadno navázat na alertovací schopnosti Azure. Díky tomu můžete při nějaké události odeslat email, SMS, zavolat webhook do jiného systému, automaticky založit ticket v některých ITSM nástrojích jako je Service Now nebo dokonce vyvolat spuštění Logic Apps – orchestrátoru, ve kterém můžete dělat složitá flow a využít jeho integrace na Microsoft svět (například nasadit ChatOps s Microsoft Teams) a třetí strany (SFDC, Service Now, SAP, WordPress, Twillio, Slack a hromada dalších).

Kubernetes plugin pro Visual Studio Code

Tím se dostáváme k nástrojům blíže vývojářům. Tam je jedna zásadní věc a to Azure DevSpaces, což je obrovské téma na samostatný článek. Dnes se v přehledu monitorovacích možností omezme na monitoring (spíše než automatické nasazování a debugging v AKS clusteru) a to s využitím extension pro open sourcové Visual Studio Code.

Plugin naleznete přímo v katalogu a instalace je záležitostí několika vteřin.

Plugin se pak podívá do vašeho konfiguračního souboru pro kubectl a hned bude fungovat.

Můžeme se podívat na namespace a přepínat se mezi nimi (a nepotřebujeme ani vytvářet kontexty).

Takhle se třeba podíváme na Nody a co na nich běží. Přes pravé tlačítko se dostaneme k dalším možnostem.

Tak například Desribe jednoduše vyvolá příkaz kubectl describe ve vašem okně, takže se s ním nemusíte vypisovat (zejména ladit správná jména a tak).

Pokud se třeba podíváme na Pody a dvakrát ťukneme na nějaký z nich, otevře se nám v okně ve formě YAML souboru (tohle mám strašně rád).

Podívejte se co všechno vám nabízí pravé tlačítko.

Můžete Pod vymazat a nebo třeba vypsat či streamovat jeho logy. To plugin udělá zase v okně příkazové řádky, takže formát výstupu vám bude důvěrně známý.

Můžete jednoduše zahájit port forwarding nebo skočit do terminálu přímo v Podu. Použije se kubectl exec, ale to zase nemusíte řešit a vypisovat – vám se jednoduše otevře terminálové okno a jste přímo uvnitř Podu.

Všimněte si ještě jedné zásadní věci – tento plugin na rozdíl od Dashboardu pracuje i s Helm šablonami, což jak si řekneme někdy později je zásadní nástroj pro reálnou práci s Kubernetes.

To ale stále není všechno. Tento pluginy přináší i porozumění struktuře Kubernetes YAML souborů. Podívejme se na to. Napsal jsem spec: a zmáčknul CTRL+mezerník.

Přesně tak. Intellisense pro Kubernetes, který vám radí co můžete použít a kontroluje pro vás syntaktickou správnost vašich YAML souborů.

 

Co tedy kdy používat? Myslím, že je rozhodně dobré naučit se efektivně pracovat s kubectl. Bude se vám to hodit jak v praxi tak třeba při CKA zkoušce, kde nic jiného nedostanete. A co GUI? Pro operations věci (mám cluster a v něm běží aplikace), kdy chci sledovat jaké je zatížení, jestli je všechno v pořádku a prohrabávat se logy, když dělám troubleshooting, tak tam doporučuji Azure portál. Pro práci na vytváření Kubernetes či Helm šablon a na ladění (vývojové a testovací prostředí), tak tam preferuji plugin do Visual Studio Code. Souvisí to i se schopností řešit tam další věci jako je buildování kontejnerů či práce s Azure Container Registry. Ostatně Azure DevSpaces pro AKS, což je výborná integrace pro vývojáře včetně remote debuggingu, na kterou se podíváme někdy příště, se používá právě Visual Studio Code nebo velké Visual Studio.

Podobné příspěvky: