Page History

...

In the "parametrization" paragraph of the Storage chapter, countless customization possibilities are listed, surmounted, however, by a warning: not all the parameters presented are supported by the various plugins. The limitations in the implementations presented here are multiple:

• ACCESS MODESACCESSMODES: behaves like RWX, regardless of the chosen mode;

• RECLAIM POLICYRECLAIMPOLICY: uses the Retain policy, even if you have chosen Delete;

• VOLUMEBINDINGMODE: regardless of the choice, it waits for the creation of the first Pod to create a PV (option exists only in the dynamic case);

• ALLOWVOLUMEEXPANSION: it does not allow volume expansion, even if you set it to true (only in the dynamic case).

These limitations are the result of poor integration between the parties, due to the lack of a real Storage provider. Here, in practice, the cluster was scraping data directly from the machines hard drive. In the next sub-chapter we will put into practice a procedure that will allow us to get around the problem, without the need to pay a Storage provider. We will introduce a layer, between the VM hard drive and Kubernetes, which will act as a mediator. In this way we will be able to access a wider range of parameters, able to better meet our storage needs, but still using the volume of the VMs.