volume configuration of kubernetes

Labels (space separated): kubernetes series

  • 1: volume configuration of kuberentes

1: volume configuration of kuberentes

1.1 background

Explain:

The life cycle of files on the container disk is short, which causes some problems when running important applications in the container. First, when the container crashes
 kubelet will restart it, but the files in the container will be lost -- the container will restart in a clean state (mirroring the original state). Secondly, in
 When multiple containers are running in Pod at the same time, they usually need to share files. The Volume abstraction in Kubernetes is a good solution
 These problems

The volume in Kubernetes has a definite lifetime - the same Pod that encapsulates it. So, the life of a volume is longer than that of all the containers in a Pod
 Data is still saved when containers are restarted. Of course, when the Pod no longer exists, the volume no longer exists. Perhaps more importantly, Kubernetes
 Support multiple types of volumes, Pod can use any number of volumes at the same time

1.2 type of volume

Kubernetes The following types of volumes are supported:

1. awsElasticBlockStore azureDisk azureFile cephfs csi downwardAPI emptyDir
2. fc flocker gcePersistentDisk gitRepo glusterfs hostPath iscsi local nfs
3. persistentVolumeClaim projected portworxVolume quobyte rbd scaleIO secret
4. storageos vsphereVolume

1.3 emptyDir

When a Pod is assigned to a node, the emptyDir volume is created first, and exists as long as the Pod is running on the node. Just like the name of the volume
 As the word says, it is initially empty. Containers in the Pod can read and write to the same files in the emptyDir volume, although the volume can be mounted to each container
 On the same or different path in the. When the Pod is removed from the node for any reason, the data in emptyDir is permanently deleted

The usage of emptyDir is as follows:

Staging space, such as for disk based merge sorting

Use as a checkpoint when calculating crash recovery for a long time

When the Web server container provides data, save the files extracted by the content manager container
vim emp.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: wangyanglinux/myapp:v1
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

----

kubectl apply -f emp.yaml

vim emp1.yaml

---
apiVersion: v1
kind: Pod
metadata:
  name: test-pd1
spec:
  containers:
  - image: wangyanglinux/myapp:v1
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c", "sleep 6000s"]
    volumeMounts:
    - mountPath: /test
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}
----

kubectl apply -f emp1.yml

1.4 hostpath

The hostPath volume mounts files or directories from the file system of the host node to the cluster

The purpose of hostPath is as follows:

1.1 to run, you need to access the container inside the Docker; use the hostPath of / var/lib/docker
 1.2 run the C advisor in the container; use the hostPath of / dev / cggroups
 1.3 allow pod to specify whether the given hostPath should exist before the pod runs, whether it should be created, and in what form it should exist
 1.4 in addition to the required path attribute, the user can also specify the type for the hostPath volume

Note that you use this volume type because:

1.1 since the files on each node are different, the behavior of a pod with the same configuration (for example, created from a podTemplate) may be different on different nodes

1.2 when Kubernetes adds resource aware scheduling according to the plan, the resources used by hostPath cannot be considered

1.3 files or directories created on the underlying host can only be written by root. You need to run the process as root in the privilege container or modify the file permissions on the host to write 
vim host.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: wangyanglinux/myapp:v1
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /data
      type: Directory
---
kubectl apply -f host.yaml

Tags: Linux Kubernetes vim Docker kubelet

Posted on Tue, 24 Mar 2020 00:38:58 -0400 by Niruth