Začínáme s Kubernetes: příkazy kubectl, Pod Logs a CronJobs
Úvod
Orientace v Kubernetes může být zpočátku komplikovaná. Tento návod vás proto provede příkazy kubectl pro základní operace, představí možnosti řízení kontejnerů a nastíní práci s CronJobs, pomocí nichž naplánujete opakující se úlohy.
Instalace kubectl
Kubectl je příkazová řádka pro práci s Kubernetes clustery. Funguje na úrovni orchestrační vrstvy, která komunikuje prostřednictvím Kubernetes API a slouží pro definování, nasazování a komplexní správu aplikací běžících v kontejnerech. Kubectl umožňuje provádět celou plejádu akcí, například vytváření nových podů, spouštění imagů nebo škálování ovladačů. Přesný postup instalace kubectl pro Linux, Windows i macOS najdete v oficiální dokumentaci Kubernetes.
Struktura kubectl příkazu
Než si základní kubectl příkazy ukážeme, je dobré se zorientovat v jejich syntaxi. V příkazové řádce má posloupnost jednotlivých částí kubectl příkazu jasně daná pravidla. Struktura příkazu je následující: kubectl [command] [TYPE] [NAME] [flags]
.
- Command: určuje, co se má stát s určitým zdrojem, nabývá hodnot např.
create
,get
,describe
,apply
,delete
. - Type: udává typ prostředku (zdroje), na který příkaz směřuje. Může jím být pod, Daemonset, Replicasets a další.
- Name: obsahuje název prostředku. Pokud není uveden, získáme zpět informace o všech prostředcích. V této části je nezbytné rozlišovat velká a malá písmena.
- Flags: tato část příkazu je volitelná a rozhoduje o speciálních modifikátorech, které umožňují potlačit proměnlivost prostředí.
Kubectl pro práci s objekty
Nyní si představíme několik příkazů, které umožňují základní práci s objekty.
Získat objekt: kubectl get
Kubectl get
patří k nejběžnějším příkazům a vrací informace o objektech v Kubernetes. Může být aplikován na pody, servicy nebo třeba configmapy, např.:
Kubectl get pods
– vypíše seznam aktivních podůKubectl get services
– zobrazí všechny dostupné službyKubectl get configmaps
– ukáže seznam konfiguračních map
Informace o objektu: kubectl describe
Veškeré podrobnosti o konkrétním objektu získáte použitím příkazu kubectl describe
. V těchto případech je vhodné dotaz blíže specifikovat a uvést do něj také jméno objektu, např. kubectl describe pod Pod1
. Příkaz vypíše informace o podu s názvem Pod1, tj. metadata, konfigurace podu a nastavení kontejnerů, historie událostí spojených s tímto podem nebo datum a čas vytvoření podu. Výstup může vypadat takto:
Namespace: default
Priority: 0
Node: my-node/111.222.3.400
Start Time: Mon, 04 Sep 2023 08:00:00 +0000
Labels: app=my-app
environment=production
Annotations:
Status: Running
IP: 11.222.3.4
IPs:
IP: 10.244.1.2
Containers:
my-container:
Container ID: container-id-12345
Image: my-app-image:v1.0.0
Image ID: image-id-abcdef123456
State: Running
Started: Mon, 04 Sep 2023 08:00:10 +0000
Ready: True
Restart Count: 0
Environment:
ENV_VAR1: value1
ENV_VAR2: value2
Mounts:
/data from my-volume (rw)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
my-volume:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: my-pvc
ReadOnly: false
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 10m defaultscheduler Successfully assigned default/my-pod to my-node
Normal Pulled 10m kubelet, my-node Container image "my-app-image:v1.0.0" already present on machine
Normal Created 10m kubelet, my-node Created container my-container
Normal Started 10m kubelet, my-node Started container my-container
Ve výstupu jsou uvedeny také informace o stavu jednotlivých kontejnerů běžících v podu (v jednom podu může běžet i více kontejnerů). Můžeme se setkat s následujícími stavy:
- Waiting: kontejner se v tomto stavu připravuje na spuštění. U tohoto stavu se vždy objeví i pole „Reason“, v němž najdeme odůvodnění, proč je kontejner v tomto stavu.
- Running: kontejner je v tomto stavu plně v provozu, u stavu se nachází také poznámka o tom, kdy kontejner do tohoto stavu přešel.
- Terminated: jedná se o stav kontejneru, který dokončil úlohy, nebo z nějakého důvodu selhal. Také u tohoto stavu se zobrazí důvod a čas ukončení.
Vytvoření objektu: kubectl create
Pro tvorbu objektů se typicky využívá příkaz kubectl create
. Objekt se vytváří na základě některého z dostupných konfiguračních souborů, nebo přímou specifikací v příkazu, např. kubectl create namespace
. Pokud máme například soubor „deployment.yaml“, vytvoříme nový objekt podle tohoto souboru následujícím způsobem:
kubectl create -f deployment.yaml
-f
v tomto případě značí „file“, tedy soubor. Část deployment.yaml
obsahuje definice pro objekt deployment.
Aktualizace objektu: kubectl apply
Pokud už objekt v Kubernetes clusteru existuje, stačí jej pouze aktualizovat a upravit tak jeho konfiguraci bez nutnosti deaktivace a vytváření nového objektu. Právě k tomu slouží příkaz kubectl apply
. V praxi může vypadat takto:
kubectl apply -f updated-deployment.yaml
Pokud by metadata souboru updated-deployment.yaml
obsahovala název objektu, který v daném namespace (mechanismus izolující skupiny prostředků v clusteru) neexistuje, došlo by k vytvoření zcela nového objektu.
Odstranění objektu: kubectl delete
Objekty v Kubernetes lze odstanit prostřednictvím kubectl delete
, např. kubectl delete pod Pod1
, kubectl delete service Service1
atd. Zadáním kubectl delete service -n default
se odstraní služby v namespace „default“. Přidáním flagu --all
za kubectl delete service
dojde ke smazání všech objektů ve všech namespaces.
Restartování objektu: kubectl rollout restart
V kubernetes neexistuje příkaz kubectl restart. Restart objektu lze provést například pomocí kubectl rollout restart
. Tento příkaz umožňuje postupnou deaktivaci a vytváření objektů, což oceníte zejména, pokud aplikace běží v několika replikách – pak je možné provést restart bez výpadku. Při běhu aplikace v jedné replice dojde k výpadku, jelikož neexistuje žádný pod, který by dostupnost zajistil.
Celý příkaz může vypadat takto: kubectl rollout restart deployment Aplikace1
. Tímto způsobem spustíme postupné ukončování a vytváření podů. Dalším příkladem může být kubectl rollout restart statefulset Databáze1
, který spustí postupný update objektu StatefulSet pro databázi Databáze1.
Kubernetes logy: kubectl logs
Nejběžnějším nástrojem pro zobrazení a prohlížení logů v Kubernetes je kubectl logs
. Konkrétní příkaz může vypadat následovně:
kubectl logs Pod1 –c Kontejner1
Kubelet poskytuje klientovi logy přes API typicky pomocí příkazu kubectl logs
. Tyto logy obsahují kombinované stdout
a stderr
výstupy na úrovni kontejnerů běžících v podu, tj. informace o tom, co se uvnitř kontejnerů děje.
Logy pomáhají s diagnostikou problémů a chyb, monitoringem výkonu i v rámci bezpečnostních auditů. Pro systematickou práci s logy doporučujeme využít nástroje pro log management a SIEM.
Opakující se úlohy: CronJob
CronJob je funkcionalita určená pro plánování opakujících se událostí. Nejčastěji se používá k nastavení zálohování, generování reportů atp. Nejjednodušší bude ukázat si využití CronJobu na příkladu. Představme si, že chceme nastavit zálohování databáze. K pravidelné záloze má dojít každý den ve 2:30 v noci.
Nejprve vytvoříme soubor s následujícím obsahem, pojmenovat jej můžeme třeba „db-backup-cronjob.yaml“.
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: database-backup
spec:
schedule: "30 2 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: backup-container
image: your-database-backup-image:latest
# Zde lze doplnit případnou další konfiguraci pro zálohování daného kontejneru.
restartPolicy: OnFailure
Nyní vytvoříme CronJob pomocí následujícího příkazu:
kubectl apply -f db-backup-cronjob.yaml
Ověříme, že CronJob byl skutečně vytvořen:
kubectl get cronjob database-backup
Nově nastavené zálohy můžeme otestovat:
kubectl create job --from=cronjob/database-backup database-backup-manual-001
V rámci CronJob se využívá specifická syntax pro zápis doby, kdy má k pravidelně se opakující události docházet.
# ┌───────────── minuty (0–59)
# │ ┌───────────── hodiny (0–23)
# │ │ ┌───────────── dny v měsíci (1–31)
# │ │ │ ┌───────────── měsíc (1–12)
# │ │ │ │ ┌───────────── dny v týdnu (0–6) (neděle–sobota;
# │ │ │ │ │ v některých systémech najdeme i 7, která označuje neděli)
# │ │ │ │ │ nebo sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# * * * * *
Zdroj: kubernetes.io
Pokud se vrátíme k našemu příkladu u bodu 1, vidíme, že zápis pro denní zálohování ve 2:30 v noci je 30 2 * * *
.