Kubernetes集群的学习笔记(5)

K8S集群的存储卷笔记。

整体的存储卷调用结构：

在k8s的集群中，Pod声明自己需要存储卷资源，同时创建自己的PVC，PVC绑定到集群中已经注册的PV资源，例如 已经建立的NFS网络空间。PV资源通过存储系统的分配，直接提供给Pod来使用。

PVC属于名称空间级别，PV属于集群资源。

存储卷的类型

1. EmptyDir：只在Node上存在的存储卷，Pod删除的时候存储卷也会被移除，无法持久存储，叫做EmptyDir，做临时存储和缓存使用，可以使用Node的内存。

2. HostPath： Docker的存储卷类型，Node节点上的目录。

3. 网络存储： SAN， NAS; 分布式存储(Glusterfs，Cephfs，rbd); 云存储(EBS， Azure Disk，特定的托管在云上的服务)

   kubectl explain pod.spec.volumes

   可以查看支持那些存储。

PVC

对于用户来说，无法掌握所有的存储系统的知识和技能，因此，创建了PVC的逻辑层，在定义需要使用存储卷的Pod中只需定义需要的空间以及存储的类型，不需要详细的考虑后端存储的信息和配置。

PVC被定义在Pods的配置中，一个 PVC可以被多个Pod同时访问。

PV

存储类： Gold Storage Class, Sliver Storage Class, Bronze Stroage Class.三个不同级别的存储类。存储类直接接受PVC的内容并对PVC定义的容量等信息进行分配。

PV与存储服务的提供者直接绑定且需要在存储服务提供方配置完成。PV与PVC具有一一对应的关系。

PersistentVolume

gitRepo仓库的使用：

gitRepo存储卷建立在EmptyDir的基础上，在Pod内建立空目录，同步Git的内容到空目录，Pod运行的过程中不会更改存储卷上的内容。也就是说，git同步是pod建立的时候同步的数据，不会对git项目的数据进行更改。Pod更改了存储卷中的数据不会自动推送到Git上（可以使用Sidecar进行推送和配置）。

PV资源的定义

---
apiVersion: v1
kind: PersistentVolume
metadata:
truename: pv001
truelabels:
truetruename: pv001
spec:
truenfs:
truetruepath: /data/volumes/v1
truetrueserver: storage1.liarlee.com
trueaccessModes: ["ReadWriteMany","ReadWriteOnce"]
truecapacity:
truetruestorage: 20Gi

使用apply命令进行应用即可。

查看所有的PV使用： kubectl get pv， 其中显示了PV的名称，大小，访问模式，回收策略，状态，建立时间等。

PersistentVolumeClaim

使用的过程中，在Pod中定义PVC；PVC和PV是一一对应的，但是PVC可以被多个Pod调用和挂载。一个PV会Binding一个PVC，PVC在Pod中被定义。

PVC以及PV的状态，未绑定的状态叫做Pending，绑定后叫做Bound。

PVC的定义

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
truename: pvc001
truenamespace: default
spec:
trueaccessModes: ["ReadWriteMany"]
trueresource:
truetruerequest:
truetruetruestorage: 6Gi

ConfigMap资源

configmap是明文资源，secret是base64的编码资源，因此安全程度提高了。configmap相当于外挂的配置文件，当Pods启动的时候直接挂载Configmap读取自己需要的配置内容。

配置应用容器化的方式

1. 自定义命令行参数
2. 配置文件直接放入镜像中
3. 通过环境变量进行配置
4. 存储卷
   1. Cloud Native应用通过环境变量直接配置
   2. 通过EntryPoint脚本预处理环境变量作为配置问文件中的信息
5. docker config命令行方式

configmap的创建

configmap为了将配置文件中镜像中解耦，configmap可以直接注入到容器中直接使用，注入的方式可以使用存储卷，或者使用EntryPoint来处理。

通过命令直接传递键值：

kubectl create configmap cm-nginx --from-literal=nginx_server_name=nginx.liarlee.com --from-literal=nginx_server_port=80
kubectl create configmap cm-nginx --from-file=./nginx.conf # 直接传递文件到ConfigMap
kubectl get cm cm-nginx -o yaml # 用YAML的格式查看ConfigMap

通过YAML文件：

---
apiVersion: v1
kind: ConfigMap
data: 
truenginx.conf................................
metadata:
truename: cm-nginx
truenamespace: default

创建Pod时ConfigMap使用环境变量方式：

---
apiVersion: v1
kind: Pod
metadata:
truename: pod-nginx
truenamespace: default
truelabels:
truetrueapp: pods-nginx
truetruetier: frontend
trueannotations:
truetrueliarlee.com/created-by: "cluster admin"
spec:
truecontainers:
true- name: pod-nginx
true  image: nginx:latest
true  ports:
true  - name: http
true    containerPort: 80
true  env:
true  - name: NGINX_SERVER_PORT
true    valueFrom:
true    	configMapKeyRef:
true    		name: cm-nginx
true    		key: nginx_port
true  env:
true  - name: NGINX_SERVER_NAME
true  	valueFrom:
true  		configMapKeyRef:
true  			name: cm-nginx
true  			key: nginx_server_name

创建Pod的时候使用挂载卷的方式：

通过挂载的方式可以通过修改configmap的方式，同步修改容器内部的配置。

---
apiVersion: v1
kind: Pod
metadata:
truename: pod-nginx
truenamespace: default
truelabels:
truetrueapp: pods-nginx
truetruetier: frontend
trueannotations:
truetrueliarlee.com/created-by: "cluster admin"
spec:
truecontainers:
 	- name: pod-nginx
   	  image: nginx:latest
      ports:
      - name: http
      	containerPort: 80
 	  volumeMounts:
 	  - name: nginxconf
 	  	mountPath: /etc/nginx/conf.d/
 	  	readOnly: true
 	Volumes:
 	- name: nginxconf
 	  configMap: 
 	  	name: cm-nginx

创建Secret的类型

kubectl create secret –help

• docker-registry – 连接到Docker私有仓库的密钥
• generic – 通用的服务密钥
• tls – 创建证书

StatefulSet的建立和使用

在一定程度上实现了有状态的管理，但是依旧需要写成管理脚本，注入到Pod中。

CoreOS – 提供了 Operator相关的功能用来完善有状态的应用的部署。

两类不同的Pod

1. Cattle

2. Pet

最早叫做PetSet， 后面改成StatefulSet。

StatefulSet一般用于管理以下特性的组件：

1. 稳定且有唯一的网络标识符；必须保持Pod的名称和地址稳定持久有效；

2. 稳定且持久的存储；

3. 有序平滑(Graceful)的部署及扩展；启动的时候Pod1 - Pod8；

4. 有序平滑(Graceful)的终止和删除；关闭的时候Pod8 - Pod1；

5. 有序的滚动更新；有顺序的进行Pod的更新；

有三个主要的部分；

1. Headless Service
   - 类似于Redis，提供一个headless的服务，来确保每一个请求直达后端的pod，可保持pod的接入点稳定且不发生变化。
2. StatefulSet Controller
   - 需要一个控制器来进行Pod的管理和控制，保持Pod的生命周期，即使Pod被终止也需要在启动后保持和之前一样的Pod信息。
3. Volume Claim Template
   - 由于有状态的服务不能同时使用同一个PV，所有的节点存储的数据各不相同，所以不能提供一个PVC&PV。因此提供了申请PV的模板，每个Pod提供一个独立的存储卷用来做独立存储。

对于StatefulSet来说，确保所有的Pod名称稳定有效不可变动。大多数有状态的副本都会使用持久存储，多个Pod能不能共用同一个存储？ 不能，每个Pod必须使用不同的存储。

所以，需要定义PV，定义PVC模板，定义Pod，定义Stateful控制器，定义headless服务这几种。

定义StatefulSet的YAML文件

---
apiVersion: v1
kind: Service 
metadata:
truename: sts-headless-svc
truelabels:
truetrueService: sts-headless-svc
spec:
trueports:
true- port: 80
true  name: sts-headless-svc
trueclusterIP: None
trueselector: 
true  service: sts-headless-svc

---
apiVersion: app/v1
kind: StatufulSet
metadata:
truename: sts
spec:
trueserviceName: sts
truereplicas: 3
trueselector:
truetruematchlabels:
truetruetrueservice: sts-headless-svc
truetemplate:
truetruemetadata:
truetruetruelabels:
truetruetruetrueservice: sts-headless-svc
true 	spec: 
true 		containers: 
true 		- name: sts-container
true 		  image: ikubernetes/SOMEIMAGE'SNAME
true 		  ports:
true 		  - containerPort: 80
true 		    name: sts-headless-svc
true 		  volumeMounts:
true 		  - name: sts-pv
true 		    mountPath: /usr/share/nginx/html
truevolumeClainTempates:
true- metadata:
truetruename: sts-vct
truespec:
truetrueaccessModes: [ "ReadWriteOnce" ]
truetrueresources:
truetruetruerequests:
truetruetruetruestorage: 5Gi

Pod的dns命名规则：

Pod_Name+Service_Name+NameSpace_Name.svc.cluster.local