1、pv 持久化数据卷：远程共享存储—运维来管理
accessModes:
- ReadWriteOnce # 只有一个pod可以读写这个pv，改成ReadWriteMany就很多Pod都能
2、pvc 开发人员负责管理
描述了pod对共享存储的需求或者期望
3、kubectl create pv和pvc后，pv和pvc要建立好绑定关系，才能使用起来
pv要满足pvc的需求，想存储大小啊，读写权限啊
把pvc的资源描述对象里把pv添加进去，就是绑定在一起了
pod就可以像使用volumes一样使用pvc了
volumes:
persistentVolumeClaim:
claimName: nfs
pod里面包含了pvc的名字，pvc里面描述了pv的需求，pv描述了具体的后端的地址，如何访问啊，都有哪些参数啊，
pod所有的volume都会对应本地的一个目录，把本地目录挂载到nfs server 上pv指定的位置
docker run -v 命令将目录映射到容器里面，这样就实现了共享存储
4、StorageClass 自动管理pv
如果有很多pod需要共享存储，每建一个就要让运维给我们创建一个pv,不用了还要回收，麻烦死了，所以StorageClass出现了
让k8s 根据StorageClass 这个模板自动创建pv
yaml关键词 provisioner:
创建pv都是k8s 自己搞定的
综述，就是docker run -v 挂远程存储啦
5、实践共享存储ClusterFS
需要三台虚拟机，并且每个虚拟机有两个磁盘，其中一块裸磁盘，供ClusterFS完全接管
在每一个work节点装上clusterfs的客户端
yum install -y glusterfs glusterfs-fuse
在master节点上的apiserver和每个节点的kubelet要加上 allow-privileged=true
ps -ef|grep apiserver|grep allow-pri
vi /etc/systemd/system/kubelet.service
1）在三台虚机上配置好ClusterFs,也就是上图最底层，存储服务的提供者，给三台加tag 才能确保部署在了正确位置
2）初始化磁盘，让ClusterFs管理起来，用heketi工具来做
3）结果就是运行两个pod副本，在一个副本里写如文件，在另一个也能看到
1、deployment 不能胜任所有的编排工作
只能胜任 无状态，pod无差别， 没有顺序性
2、StatefulSet 抽象了两种有状态场景，就是解决了两个问题
1）多个pod之间的顺序性，需要按一定的顺序启动，实例之间互相访问，互相通信的情况
注意下yaml下的serviceName：service的名字 表示告诉statefulset用哪个headless service 去保证每个pod的解析
这样弄下来，每个pod都有具体的编号，就有了顺序性
2）持久存储区分，就是每个pod私有存储空间（当然在有共享存储的前提下，没有，本来就是隔离的）
**volumeClaimTemplates:**创建pvc的模板,下面写上路径，这个路径就是私有存储
kubectl get pvc
pod删了，重建，存储依旧有
将statefulset删掉，pod不在了，pvc 和 pv 还在,需要自己手动处理
就是yaml文件里的内容，官网有具体介绍
还可以用resfulAPI 搞，操作apiserver,github上提供了各种语言的client
里面有很多examples，什么logs,WebSockets等等
最后搞出来就是容器管理平台工具，不就是kubesphere嘛？
为了不太熟悉k8s的同学更简单地使用复杂的东西
k8s中的日志处理
1、将日志打到远端，Kafka or es,最后汇总到日志服务器
2、阿里的LogPilot在每个节点上做agent（没有对pod和服务侵入，占用资源也少），采集日志，发给es做存储，Kibana做展示
LogPilot专门针对docker的。
3、LogPilot 是容器日志采集工具，发送到后端，比如es,kafka ,redis等等
4、环境搭建ES，LogPilot，Kibana这些都是通过yaml文件
es 9200 http端口是与外部通信用的，9300 tcp是es之间通信用的
es的三个副本分别放在了三个节点上，用到了statefulset
LogPilot 部署用 DaemonSet,保证每个节点上都有一个实例来搜集日志
volumeMounts: mountPath: /var/run/docker.sock 这样就可以获取docker 信息，日志存储位置，docker 事件，通过挂载目录形式，拿到权限
需要在被采集的yaml设置env和volumeMounts,在里面填上要采集目录的位置
五、监控报警1、监控的目的
及时发现已经出现的问题，提前预警可能发生的问题
2、监控什么
系统基础指标，cpu 内存 网络 IO load负载，否则主机出问题，服务不能幸免
服务基础信息，cpu、内存占用情况，内存是否溢出，占用的网络带宽，磁盘IO，监听的端口在不在
服务个性化信息，有些服务提供特定的端口，比如web服务，请求的排队情况呀，每秒的请求次数，错误次数，请求的处理时间啊
日志，根据日志的异常数，和异常发生的频率来做预警
3、如何监控？
数据采集，每隔多长时间采集一次
数据存储，时间序列数据库来存储
定义报警规则，一旦触发条件，就报警
配置报警方式，邮件，短信，企业钉钉
4、常见的工具
Zabbix — 主要是系统基础信息的监控
5、Kubernetes的监控
每个节点，容器的基础指标，k8s集群组件的监控，比如ApiServer,controllerManager，etcd
6、Prometheus
它是一系列服务的组合，系统和服务的监控报警平台
1）特征
由metric 名称和 kv 标识的多维数据模型
每一条名字和kv组合都是一条单独的时间序列
metric名称{ kv标识 }
灵活的查询语言（PromQL）,比如 http_response_total{method=“GET”} 将metric是 h…t method是GET的都给查询出来
2) 架构
就是 Prometheus Server 从各个地方pull数据，即为 Retrieval，数据保存在Storage ，通过PromQL查询
Jobs / Exporters 暴露指标，让Retrieval 来抓取的
Pushgateway 用push 的方式将数据推送到网关, 比如一些定时任务和一次性执行任务
Service Discovery 是 Prometheus 支持的服务发现
够报警条件，就将消息push 给 Alertmanager
3) Prometheus 常见的数据类型
Counter 累积增大，不会减小，比如请求的次数，异常发生的次数
Gauge可大可小，内存的变化，磁盘的变化，
Histogram && Summary 统计和分析样本的分布情况, 我们会使用量化指标的平均值，cpu的平均使用率，页面的平均响应时间，但是有时候个别请求远远超出平均水平，这样平均水平就不能体现出问题，为了分析这种情况，分时间段，比如0-100ms，请求有几个；100-500ms呢，通过这种方式就能快速找到系统慢的原因，即为这项数据类型的作用
Histogram 类型于直方图，就是之前定义好区间
Summary 分位数，排序后，第几个的样本的值是多少
4）数据是如何采集来的
通过ds的方式将NodeExporter运行在每个worker 上。抓取节点的信息，内置http服务，供 Prometheus pull 数据
针对 docker容器指标
每个kubelet内置 cAdvisor，采集容器的信息，cpu，内存，网络文件系统等，也会启动http服务，供 Promethues pull 数据
针对K8s组件的监控
