Concepts de base¶

SRC-fr: https://kubernetes.io/fr/docs/concepts/

API kube fournit des objets (ressources) pour décrire l’état souhaité du cluster. Interaction avec API : le plus simple c’est de passer par kubectl

=> control plane : assure que l’état souhaité est l’état réelle du cluster correspond

Control plane¶

Actor¶

master les 3 processus présents:
- kube-apiserver
- kube-controler-manager
- kube-scheduler
worker : 2 processus qui vont interagir avec le master
- kubelet (port 10250) : communique avec le master ;
- kube-proxy : gérer la partie réseau au sein du cluster, travaille sur plusieurs ports les loopback ou open

Actions:

conservation de l’état des ressources demandées (stocker dans etcd, ou autres solution de stockage)
boucle de contrôle régulière pour comparer l’état des ressources dans le cluster et l’état souhaité soit les mêmes.

POD connecter sur la pile réseau de l’hôte:

calico-kube-controllers
calico-nodes (un pod par nodes)
kube-apiserver-master
kube-controler-manager-master
kube-proxy (un pod par nodes)
kube-scheduler-master
nginx-proxy-worker (un pod par worker)

Ressources¶

On distingue :

objet de base :
- pod
- service
- volume
- namespaces
controleur, avec niveau d’abstraction supérieur qui vont gérer des objets pour nous :
- replicaset
- deployment
- statefullset
- daemonset
- job

Manage ressources¶

Pod Preset¶

SRC https://kubernetes.io/docs/concepts/workloads/pods/podpreset/ SRC use https://kubernetes.io/docs/tasks/inject-data-application/podpreset/

=> object qui injecte des informations de configuration dans un pod au moment de la création: secrets, volumes, volumes mount (token), environment variabel.

utilisation des label-selector pour un pod-preset sur un ensemble de pod

Principe :

recherche de tous les pod-preset et sélection en fonction label-selector ;
- identification de 0 ou plusieurs pod-preset à appliquer pour la création du pod
à la création du pod merge de la définition du pod-preset avec la définition du yaml ;
ajout d’une annotation dans le pod pour donner le nom du pod-preset utilisé ;

Il est possible d’ignorer les pod-preset défini, grâce à une annotation :

IMP : en cas d’erreur : message dans les évents et création d’un pod sans les informations du pod-preset.

Cluster: configuration pour utiliser les pod-preset

ajouter une configuration pour y avoir accès :
- pour API : pour settings.k8s.io/v1alpha1/podpreset , configure le runtime-config avec settings.k8s.io/v1alpha1=true

In minikube add this flag

--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true

Utilisation¶

Commandes utiles¶

kubectl port-forward¶

Exemple avec Redis : - run déploy - svc

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml

Connaitre le port d’écoute dans le pod

kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'

Forwarder le port d’écoute du pod vers un port de l’hote Possibilité d’utiliser plusieurs resources comme source : pod, deploy, rs, svc

kubectl port-forward redis-master-765d459796-258hz 7000:6379
kubectl port-forward deployment/redis-master 7000:6379
kubectl port-forward rs/redis-master 7000:6379
kubectl port-forward svc/redis-master 7000:6379