In order to facilitate this high availability requirement, each user-defined API object must be self-contained so that it can be ephemeral. 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. 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. 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. Volumes in K8s are datastores that can be separated into two fundamental classes – persistent and ephemeral. A persistent datastore is designed to outlive a given pod that is reading from it. 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. 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. Here, we are spinning up a single pod with an Alpine linux container image. We pass it a command at startup that will keep the container alive for an hour, so we can inspect our work. Without the sleep command, the container would immediately complete the only process it was given – i.e. starting – and it would exit when finished. 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. We have included an example PV definition below for illustration’s sake. Storing essential data that must be available for the application to run.Ĭloud 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. Unlike emptyDir volumes, persistent volumes require additional api objects to correctly associate themselves with a given, targeted pod.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |