Kubernetes指南
Linux性能优化实战eBPF 核心技术与实战SDN指南个人博客
EN
EN
  • Overview
  • Introduction
    • Kubernetes Introduction
    • Kubernetes Concepts
    • Kubernetes 101
    • Kubernetes 201
    • Kubernetes Cluster
  • Concepts
    • Concepts
    • Architecture
    • Design Principles
    • Components
      • etcd
      • kube-apiserver
      • kube-scheduler
      • kube-controller-manager
      • kubelet
      • kube-proxy
      • kube-dns
      • Federation
      • kubeadm
      • hyperkube
      • kubectl
    • Objects
      • Autoscaling
      • ConfigMap
      • CronJob
      • CustomResourceDefinition
      • DaemonSet
      • Deployment
      • Ingress
      • Job
      • LocalVolume
      • Namespace
      • NetworkPolicy
      • Node
      • PersistentVolume
      • Pod
      • PodPreset
      • ReplicaSet
      • Resource Quota
      • Secret
      • SecurityContext
      • Service
      • ServiceAccount
      • StatefulSet
      • Volume
  • Setup
    • Setup Guidance
    • kubectl Install
    • Single Machine
    • Feature Gates
    • Best Practice
    • Version Support
    • Setup Cluster
      • kubeadm
      • kops
      • Kubespray
      • Azure
      • Windows
      • LinuxKit
      • kubeasz
    • Setup Addons
      • Addon-manager
      • DNS
      • Dashboard
      • Monitoring
      • Logging
      • Metrics
      • GPU
      • Cluster Autoscaler
      • ip-masq-agent
  • Extension
    • API Extension
      • Aggregation
      • CustomResourceDefinition
    • Access Control
      • Authentication
      • RBAC Authz
      • Admission
    • Scheduler Extension
    • Network Plugin
      • CNI
      • Flannel
      • Calico
      • Weave
      • Cilium
      • OVN
      • Contiv
      • SR-IOV
      • Romana
      • OpenContrail
      • Kuryr
    • Container Runtime
      • CRI-tools
      • Frakti
    • Storage Driver
      • CSI
      • FlexVolume
      • glusterfs
    • Network Policy
    • Ingress Controller
      • Ingress + Letsencrypt
      • minikube Ingress
      • Traefik Ingress
      • Keepalived-VIP
    • Cloud Provider
    • Device Plugin
  • Cloud Native Apps
    • Apps Management
      • Patterns
      • Rolling Update
      • Helm
      • Operator
      • Service Mesh
      • Linkerd
      • Linkerd2
    • Istio
      • Deploy
      • Traffic Management
      • Security
      • Policy
      • Metrics
      • Troubleshooting
      • Community
    • Devops
      • Draft
      • Jenkins X
      • Spinnaker
      • Kompose
      • Skaffold
      • Argo
      • Flux GitOps
  • Practices
    • Overview
    • Resource Management
    • Cluster HA
    • Workload HA
    • Debugging
    • Portmap
    • Portforward
    • User Management
    • GPU
    • HugePage
    • Security
    • Audit
    • Backup
    • Cert Rotation
    • Large Cluster
    • Big Data
      • Spark
      • Tensorflow
    • Serverless
  • Troubleshooting
    • Overview
    • Cluster Troubleshooting
    • Pod Troubleshooting
    • Network Troubleshooting
    • PV Troubleshooting
      • AzureDisk
      • AzureFile
    • Windows Troubleshooting
    • Cloud Platform Troubleshooting
      • Azure
    • Troubleshooting Tools
  • Community
    • Development Guide
    • Unit Test and Integration Test
    • Community Contribution
  • Appendix
    • Ecosystem
    • Learning Resources
    • Domestic Mirrors
    • How to Contribute
    • Reference Documents
由 GitBook 提供支持
在本页
  • Different Flavors of Kubernetes Volumes
  • API Version Compatibility Chart
  • Getting into the Nuances of Different Volume Types
  • emptyDir
  • hostPath
  • NFS
  • The Art of Volume Snapshotting
  • Volume Mount Propagation
  • Byte-Sized Guides to Other Volume Types
  1. Concepts
  2. Objects

Volume

Just as we know that our apps and data aren't destined to last forever, in the Docker universe, the lifecycle of container data is fundamentally ephemeral. Once a container bites the dust, so does its data. Recognizing the importance of data permanence, Docker created a clever system called 'Volumes' to persist container data.

Similarly, Kubernetes has embraced and even improved upon Docker's concept, offering its own robust version of volumes. Kubernetes volumes, accompanied by a plethora of plugins, help tremendously in ensuring data permanence and sharing data between containers.

However, a critical distinction lies between Docker and Kubernetes volumes. Unlike Docker, Kubernetes volumes are intrinsically tied to the lifecycle of a pod.

  • Regardless of whether a container is brought back from the verge of oblivion by Kubelet, the volume's data will always remain unharmed.

  • It's only when a Pod is deleted that the volume is cleaned up. Whether the data is also deleted depends on the type of volume being used. For an emptyDir volume, the data gets lost, but for a Persistent Volume (PV), it's preserved.

Different Flavors of Kubernetes Volumes

As of now, Kubernetes offers the following types of volumes:

  • emptyDir

  • hostPath

  • gcePersistentDisk

  • awsElasticBlockStore

  • nfs

  • iscsi

  • flocker

  • glusterfs

  • rbd

  • cephfs

  • gitRepo

  • secret

  • persistentVolumeClaim

  • downwardAPI

  • azureFileVolume

  • azureDisk

  • vsphereVolume

  • Quobyte

  • PortworxVolume

  • ScaleIO

  • FlexVolume

  • StorageOS

  • local

Remember, not all volume types are 'persistent'. For instance, emptyDir, secret, gitRepo volumes disppear along with the pod.

API Version Compatibility Chart

Kubernetes Version
Core API Version

v1.5+

core/v1

Getting into the Nuances of Different Volume Types

emptyDir

When a Pod is assigned an emptyDir type volume, the emptyDir is created as soon as the Pod is scheduled on the node. As long as the Pod runs on the node, the emptyDir remains. However, if the Pod is removed from the node, the emptyDir is also removed, causing the data to be lost permanently.

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

hostPath

The hostPath volume allows mounting of the node's filesystem within the pod – perfectly suited when a pod needs to use files on the node.

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data

NFS

Short for Network File System, NFS provides a way to easily mount its system to a Pod in Kubernetes. Notably, NFS ensures permanent data storage and supports concurrent write operations.

volumes:
- name: nfs
  nfs:
    # FIXME: use the right hostname
    server: 10.254.234.223
    path: "/"

[...]

For the details and examples of all the other volume types, please visit the Kubernetes examples page at [https://github.com/kubernetes/examples/tree/master/staging/volumes/].

The Art of Volume Snapshotting

Stay tuned for a detailed discussion and examples of volume snapshotting on our upcoming posts!

Volume Mount Propagation

Introduced with version v1.9, Mount Propagation is quickly scaling its way through the beta version in Kubernetes v1.10. Mount Propagation is used to handle the mounting issues of the same volume across different containers or even Pods. By adjusting the Container.volumeMounts.mountPropagation setting, you can assign different types of propagation to the volume.

It provides three options:

  • None: private mount

  • HostToContainer: Where new mounts made inside the host directory are visible inside the container, equivalent to Linux kernel's rslave.

  • Bidirectional: Where new mounts made inside the host or container's directory are visible in the opposite party, equivalent to Linux kernel's rshared. The privileged containers can only use the bi-directional type.

Note:

  • The enabling of the Mount Propagation feature is required first.

  • If not set, the default is 'private' for v1.9 and v1.10, whereas for v1.11, it defaults to 'HostToContainer'.

  • Docker's systemd configuration file must be set to MountFlags=shared.

Byte-Sized Guides to Other Volume Types

上一页StatefulSet下一页Setup Guidance

最后更新于1年前

Although in a pre-alpha state, the concept of volume snapshots was introduced to Kubernetes in version 1.8. However, its implementation is not in the core Kubernetes but rests in .

kubernetes-incubator/external-storage
iSCSI Volume Example
cephfs Volume Example
Flocker Volume Example
GlusterFS Volume Example
RBD Volume Example
Secret Volume Example
downwardAPI Volume Example
AzureFile Volume Example
AzureDisk Volume Example
Quobyte Volume Example
Portworx Volume Example
ScaleIO Volume Example
StorageOS Volume Example