Unlike emptyDir volumes, persistent volumes require additional api objects to correctly associate themselves with a given, targeted pod. Storing essential data that must be available for the application to run.
Cloud Provider-Specific Volume Examples: undefinedundefined.NFS: Network filesystem a NFS server in your cluster’s network.However, when working with your actual Orka cluster, you will only need to create the persistent volume claim, and to mount that claim onto your targeted pod(s), as shown in the example YAML below. We have included an example PV definition below for illustration’s sake. NOTE: If you require a persistent volume in your Orka cluster, you’ll want to contact MacStadium support to request that one be created according to your specific needs. starting – and it would exit when finished. Without the sleep command, the container would immediately complete the only process it was given – i.e.
We pass it a command at startup that will keep the container alive for an hour, so we can inspect our work. Here, we are spinning up a single pod with an Alpine linux container image. apiVersion: v1 kind: Pod metadata: name: myvolumes-pod spec: containers: - image: alpine:latest imagePullPolicy: Never name: myvolumes-container command: volumeMounts: - mountPath: /tmp name: example-volume volumes: - name: example-volume emptyDir: The emptyDir volume type can be created within a pod’s definition, as shown below. Sharing non-essential data between containers in a pod.configMap: provides a means of injecting configuration data into a given pod at runtime.emptyDir: an empty directory that is mounted at a user-specified path at pod creation.Ephemeral Volumes Common Ephemeral Volume Types Ephemeral datastores, on the other hand, only exist for the duration that their associated pods live. A persistent datastore is designed to outlive a given pod that is reading from it. Volumes in K8s are datastores that can be separated into two fundamental classes – persistent and ephemeral. However, there are use cases in which you will want data to persist and be available to the various resources in your cluster – either for the duration of a given resource’s lifespan, like, that of a given pod, or indefinitely, so that regardless of the number of times a new pod is created, that same data will be available to each in turn.įor this, we’ll turn to Kubernetes volumes. This means that any data that lives in a given pod cannot be trusted to be accurate and complete, because at any point, it could have been torn down and replaced from scratch. That is, they have to be able to be created or deleted as needed without relying on any information not contained in the user-supplied definition. In order to facilitate this high availability requirement, each user-defined API object must be self-contained so that it can be ephemeral. If they are somehow misaligned, the system will work to regain the user’s desired state.Ī simple example of this behavior is Kubernetes' ability to create and delete replicas of a given pod on the fly, such that there are always the same number of replicas available as are called for in the defined desired state of the system. If all is well, the actual state and the user-defined, desired state will be aligned. Rather, the system maintains an awareness of its current state and continuously compares that state with the user-supplied state definition stored in etcd. This is possible, because user-created elements of the larger system – such as pods, replica sets and deployments – are designed such that they can break, or be deleted or become unhealthy in some way, and this won’t cause the system to go down.
Kubernetes, by default, is designed to be a high-availability system, or one that won’t break easily.