Afin de limiter l'usage des ressources par les pod, et de faciliter le travail du scheduler, il est fortement conseillé de spécifier des [Resources](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/).
Afin de limiter l'usage des ressources par les pods, et de faciliter le travail du scheduler, il est fortement conseillé de spécifier des [Resources](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/).
Vous pouvez par exemple configurer le pod nginx avec 2Mo/10Mo, et le pod vapormap avec 40Mo/80Mo.
#### Secrets ####
Dans le TP, les secrets sont dans le dépôt, ce qui est évidemment un mauvaise pratique. En pratique, l'API Kubernetes comporte un objet (que l'on a utilisé pour configurer la registry docker) qui permet de séparer les secrets des déploiements : l'objet [Secret](https://kubernetes.io/docs/concepts/configuration/secret/).
Ajouter un secret avec les différentes variables d'environnement nécessaire, et modifier les déploiements mariadb et vapormap afin qu'ils utilisent le [secret comme variable d'environnement](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables).
Par la suite, on peut utiliser [sops](https://github.com/mozilla/sops) pour chiffrer les secrets yaml et les ajouter au dépôt en tout confiance...
Par la suite, on peut utiliser [sops](https://github.com/mozilla/sops) pour chiffrer les secrets yaml et les ajouter au dépôt en toute confiance...
#### Volume ####
Vous aurez remarqué que nous n'abordons pas la problématique de la persistance, par manque de temps. Cet problématique est résolue par Kubernetes grâce aux [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/).
L'API est capable de communiquer avec le cloud sous-jacent (par exemple cinder, dans le cas d'Openstack), mais aussi de tailler des volumes iSCSI, nfs, etc...
Vous aurez remarqué que les données ne sont pas persitantes. En effet, à chaque redémarrage du pod MariaDB, les données sont perdues. Cette problématique est résolue par Kubernetes grâce aux [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/).
Notez que Kubernetes est capable de communiquer avec le cloud sous-jacent (par exemple cinder, dans le cas d'Openstack), mais aussi de tailler des volumes iSCSI, nfs, etc...
Pour MicroK8s, il faut activer le composant qui gère le stockage persitant :
Pour MicroK8s, il s'agit par défaut d'un simple stockage fichier dans un répertoire de la machine hôte. Il faut tout d'abord activer le composant qui gère le stockage persitant :
```bash
microk8s.enable storage
microk8s.enable storage
```
Puis, ajoutez une [PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) attachez-le au pod du déploiement MariaDB. Vérifiez ensuite qu'un redémarrage du pod préserve les données.
#### NetworkPolicy ####
Par défaut, la base mariadb est accessible à tous les pods du cluster. Vous pouvez limiter les pods qui y ont accès à l'aide d'une [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/). Utilisez le namespaceSelector qui correspond à votre namespace, et le label `app: vapormap`.
