First, if you do not know what Volume types can be used, to how to do it?
1, if you do not know what Volume types can be used, to how to do it?
1, know nothing about
2, the risk of exposure to the infrastructure company secrets
For example, the following example is a statement of Pod Ceph RBD type Volume of:
apiVersion: v1
kind: Pod
metadata:
name: rbd
spec:
containers:
- image: kubernetes/pause
name: rbd-rw
volumeMounts:
- name: rbdpd
mountPath: /mnt/rbd
volumes:
- name: rbdpd
rbd:
monitors:
- '10.16.154.78:6789'
- '10.16.154.82:6789'
- '10.16.154.83:6789'
pool: kube
image: foo
fsType: ext4
readOnly: true
user: admin
keyring: /etc/ceph/keyring
imageformat: "2"
imagefeatures: "layering"
This is why, in the later evolution, Kubernetes project introduces a set called Persistent Volume Claim (PVC) and Persistent Volume (PV) API objects, greatly reducing the user to declare and use persistence Volume threshold.
Second, with the following PVC, a developer wants to use a Volume, requires only a simple two steps
1, the first step: the definition of a PVC, a statement intended Volume attributes:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
In this PVC objects, the field does not require any details on Volume, only descriptive attributes and definitions.
2. The second step: the Pod application, declare the use of this PVC:
apiVersion: v1
kind: Pod
metadata:
name: pv-pod
spec:
containers:
- name: pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: pv-storage
volumes:
- name: pv-storage
persistentVolumeClaim:
claimName: pv-claim
3, these qualifying Volume is come of it?
The answer is that they come from maintained by operation and maintenance personnel PV (Persistent Volume) object. Next, we look at YAML file with a common PV object:
kind: PersistentVolume
apiVersion: v1
metadata:
name: pv-volume
labels:
type: local
spec:
capacity:
storage: 10Gi
rbd:
monitors:
- '10.16.154.78:6789'
- '10.16.154.82:6789'
- '10.16.154.83:6789'
pool: kube
image: foo
fsType: ext4
readOnly: true
user: admin
keyring: /etc/ceph/keyring
imageformat: "2"
imagefeatures: "layering"
4, "Interface" and "realization
PVC and PV design
Avoid "wrangling"
5、volumeClaimTemplates
The PVC, PV design, but also makes storage management StatefulSet state as possible. We still used in the above article StatefulSet for example (you can also take another look at "in-depth understanding StatefulSet (a): Topology state" in the relevant content):
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.9.1
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Field
PVC POD consistent and number
PVC and PV bindings
So, after we have created StatefulSet use kubectl create, you will see Kubernetes cluster, there were two PVC:
$ kubectl create -f statefulset.yaml $ kubectl get pvc -l app=nginx NAME STATUS VOLUME CAPACITY ACCESSMODES AGE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
<PVC name> - <StatefulSet name> - <number>
Third, verify the above Volume of distribution:
We have already mentioned before, all Pod, a statement will be created out of the use of this StatefulSet number of PVC. For example, the field named volumes of web-0 Pod, it will declare the use of PVC called www-web-0, thereby to mount the PV PVC bound.
Therefore, we can use the following instruction, and writes a file in the Volume Pod's directory to verify the above Volume of distribution:
$ for i in 0 1; do kubectl exec web-$i -- sh -c 'echo hello $(hostname) > /usr/share/nginx/html/index.html'; done
As described above, by kubectl exec command, each directory we Volume Pod's, writing a file index.html. Contents of this file, it Pod's hostname. For example, what we write in a web-0 in the index.html is "hello web-0".
At this point, if you visit in the Pod container “http://localhost”, you actually have access to is the Pod in Nginx server process, and it will return /usr/share/nginx/html/index.html the contents for you. This method of operation is performed as follows:
As described above, by kubectl exec command, each directory we Volume Pod's, writing a file index.html. Contents of this file, it Pod's hostname. For example, what we write in a web-0 in the index.html is "hello web-0".
At this point, if you visit in the Pod container “http://localhost”, you actually have access to is the Pod in Nginx server process, and it will return /usr/share/nginx/html/index.html the contents for you. This method of operation is performed as follows:
$ for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done hello web-0 hello web-1
Now, the key here.
If you use kubectl delete command to remove both Pod, Volume in these files you will not lose it?
$ kubectl delete pod -l app=nginx pod "web-0" deleted pod "web-1" deleted
# Visit http being re-created out of the Pod containers: // localhost $ kubectl Exec -it Web-0 - curl localhost the Hello Web-0
This is how to do it?
1, the recovery process of the Pod
2. Note that
3, StatefulSet create standard processes of Pod.
In this way, Kubernetes of StatefulSet to achieve the management of application storage state.
Details comb
1, first
2, followed by
3, final
IV Summary
1, StatefulSet design ideas
2, No.
In fact, the "stateful application" Practice, as well as the subsequent explanation in the next article, you will come to realize, StatefulSet can be said Kubernetes job choreographed "synthesizer."
Because almost every Kubernetes orchestration, it can be used in the preparation of StatefulSet YAML file.