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 :

.. code:: block

    annotations:
        podpreset.admission.kubernetes.io/exclude: "true"

**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 

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



Utilisation
===========

Commandes utiles
----------------


kubectl port-forward
~~~~~~~~~~~~~~~~~~~~

Exemple avec Redis :
- run déploy
- svc 

.. code:: console

    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

.. code:: console 

    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

.. code:: console

    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