Gestione di Pods

Creare un Pod in Modo Imperativo

Se non eseguito:

minikube start

Creare un pod db col database mongo:

kubectl run db --image mongo:3.3

Controllo:

kubectl get pods

NAME   READY   STATUS              RESTARTS   AGE
db     0/1     ContainerCreating   0          64s

Ci vuole del tempo perchè venga scaricata l’immagine di mongo.

Controllare a intervalli regolari con:

kubectl get events | grep -i db

Conferma che c’è un contenitore attivo col database mongo:

eval $(minikube docker-env)

Ora le variabili d’ambiente del docker dello host puntano a minikube.

docker container ls -f ancestor=mongo:3.3

Imperpod

Risettare l’ambiente:

eval $(minikube docker-env -u)

Le variabili d’ambiente del docker dello host puntano di nuovo allo host.

Rimuovere il pod:

kubectl delete pod db

Verificare:

kubectl get pods

Non lo trova.

Possibile problema

Lo scarico di qualche immagine troppo grossa può andare in timeout. L’evento dice:

Failed to pull image "mongo:3.3": rpc error: code = Unknown desc = context deadline exceeded

In tal caso viene ritentato più volte con un tempo di timeout via via crescente. Può impiegare comunque molto tempo.

Workaround, scaricare l’immagine a mano:

minikube ssh docker pull mongo:3.3

Attendere lo scarico dell’immagine.

L’immagine è scaricata nel contesto di Minikube, non nello host a monte.

Poi proseguire con:

kubectl run db --image mongo:3.3

Creare un Pod in Modo Dichiarativo

Creare una directory e il file di specifiche YAML:

mkdir pod
vim pod/db.yml

apiVersion: v1
kind: Pod
metadata:
  name: db
  labels:
    type: db
    vendor: MongoLabs
spec:
  containers:
  - name: db
    image: mongo:3.3
    command: ["mongod"]
    args: ["--rest", "--httpinterface"]

Sottomettere la richiesta:

kubectl create -f pod/db.yml

Verificare e attendere il pull dell’immagine:

kubectl get pods
kubectl get events

Con più informazioni:

kubectl get pods -o wide

In altri formati:

kubectl get pods -o json
kubectl get pods -o yaml

Dettagli su un singolo pod:

kubectl describe pod db

Qualora vi fossero più pods attivi nel cluster, si può limitare la visualizzazione a pods aventi certe etichette, per esempio:

kubectl get pods -l vendor=MongoLabs

Si possono mostrare tutti i pods con le loro etichette con:

kubectl get pods --show-labels

Interazione col Pod

Aprire una shell nel contenitore del pod:

kubectl exec -it db -- sh

Se il contenitore abbia una shell, e quale sia il suo nome, dipende dall’immagine usata

Lanciare un comando nel contenitore del pod:

kubectl exec -it db -- ps wax

Per pod multicontainer indicare il nome del container:

kubectl exec -it --container=nomecontainer nomepod-- sh

I container ausiliari sono nel rapporto ottenuto con:

kubectl describe podnomepod

Vedere il log:

kubectl logs db [-f]

Kill e Rimozione di Pod

Kill del container in un pod:

kubectl exec db -- pkill mongod

e dare immediatamente:

kubectl get pods

NAME   READY   STATUS      RESTARTS      AGE 
db     0/1     Completed   1 (31s ago)   2m57s

Ma dopo qualche secondo:

kubectl get pods -o wide

NAME   READY   STATUS    RESTARTS      AGE
db     1/1     Running   1 (21s ago)   3m18s

Quando il container di un pod è distrutto, immediatamente viene ricreato un altro container.

Podkill

Rimuovere definitivamente il pod:

kubectl delete -f pod/db.yml

Rimuove tutte le risorse descritte dal file di specifiche

Note

Ambiente del Cluster e di Default

Nell’ambiente di default:

docker images

Nell’ambiente del cluster:

eval $(minikube docker-env)
docker images

Ci sono più immagini nel cluster che nell’ambiente di default.
- Verranno rimosse alla rimozione del cluster
Alcune immagini sono visibili in entrambi gli ambienti
Non verranno rimosse alla rimozione del cluster

Tornare all’ambiente di default:

eval $(minikube docker-env -u)

Sequenza di Eventi

Durante la creazione del pod:

Il client Kubernetes (kubectl) invia una richiesta allo API Server di creazione di un pod come definito nel file di specifica pod/db.yml
Lo Scheduler monitorizza lo API Server e scopre che vi è un pod non assegnato
Lo Scheduler decide quale nodo assegnare al pod ed invia tale informazione allo API Server
Anche Kubelet del nodo assegnato monitorizza lo API Server e scopre che gli è stato assegnato il pod
Kubelet invia una richiesta a Docker per la creazione dei container che formano il pod. In questo caso è un container singolo con l’immagine mongo
Kubelet notifica lo API Server che il pod è stato creato con successo

Umlseq

Pod con Container Multipli

Il file di specifiche è pod/go-demo-2.yml:

apiVersion: v1
kind: Pod
metadata:
  name: go-demo-2
  labels:
    type: stack
spec:
  containers:
  - name: db
    image: mongo:3.3
  - name: api
    image: vfarcic/go-demo-2
    env:
    - name: DB
      value: localhost

Creazione del pod:

kubectl create -f pod/go-demo-2.yml

e dopo qualche secondo:

kubectl get -f pod/go-demo-2.yml

NAME        READY   STATUS    RESTARTS   AGE
go-demo-2   2/2     Running   0          104s

Dall’output di:

kubectl get -f pod/go-demo-2.yml -o json

si vedono i nomi dei container: db, api

Output con filtro:

kubectl get -f pod/go-demo-2.yml \
  -o jsonpath="{.spec.containers[*].name}"; \
  echo

Comando in un container specifico:

kubectl exec -c db go-demo-2 -- ps aux

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mongodb        1  1.0  1.5 273132 61004 ?        Ssl  10:59   0:07 mongod
root          33  0.0  0.0  17504  2064 ?        Rs   11:12   0:00 ps aux

kubectl exec -c api go-demo-2 -- ps aux

PID   USER     TIME   COMMAND
    1 root       0:00 go-demo
   12 root       0:00 ps aux

L’output dipende dal sistema operativo del container.

Logs di un container specifico:

kubectl logs go-demo-2 -c db

Rimuovere il pod:

kubectl delete -f pod/go-demo-2.yml

Kubernetes Base