- K8s存储卷抽象Volume
- 容器重启数据丢失的问题
- Petclinic微服务配置Volume
- Volume存储的必要性
- 什么是Volume存储卷？
- mysql pod 挂载本地hostpath存储卷
- k8s存储解藕PVC和PV
- k8s存储解藕机制
- pv和pvc yaml配置
- pvc/pv小结
- K8s资源请求和限额（Request/Limit）
- Request/limit
- limit /request yaml配置
- K8s的Metrics Server组件
- Metrics Server实现流程
- K8s就绪探针和存活探针
- 就绪探针和存活探针区别
- petclinic微服务应用就绪探针/存活探针
- 微服务网关 Vs K8s Ingress
- 微服务网关演变
- 使用K8s Ingress暴露PetClinic微服务
mysql pod重启数据文件丢失： 如果mysql没有配置存储机制，默认情况下mysql启动时会使用容器中的临时存储来存储数据文件， 如果mysql pod重启，对应的mysql容器也会重启，那么mysql就会重新初始化数据文件，原因的数据文件就会丢失。 实际的生成的k8s集群中，worker接口会有很多，mysql pod重启后，可能会被调度到另外一个worker节点中，所以即使mysql数据文件存在worker节点的某个地方，换了一个worker节点后，mysql数据也会无法访问。Petclinic微服务配置Volume
在环境变量中有个参数 DataSource_INIT_MODE,他的配置时always，服务起来后，会连接后台的mysql，会用种子数据来初始化mysql，所以mysql中就会有服务相关的表和数据
Volume存储的必要性docker容器当中的数据存储是临时性的(Ephemeral),这个存储只在容器存活期间可以访问，k8s当中的容器或者pod可能会被重启，这种重启包括预期的，比方说重新发布，也可能是非预期的，比方说容器或者por自己宕机，k8s重新调度，这个时候容器内的数据存储就会丢失，在生产环境，像mysql数据文件之类的存储是严格要求长期持久化的，即使容器或者pod重启，数据库重启也觉得不能丢失，为了解决数据持久化的问题，k8s就引入了存储卷Volume的概念。
什么是Volume存储卷？volume是和pod相关联的一个概念，引入volume后，一方面volume可以挂载到容器的文件系统当中，比方说:将一个volume挂载到mysql容器他的文件系统目录(/var/lib/mysql)，这个目录是默认的mysql数据文件的存储目录，运行时当mysql向这个目录写入数据文件，背后就会写到volume。另一方面一个pod可以关联一个甚至多个volume，一个pod当中的volume对于该pod当中的所有容器是可以访问的，一个pod当中可以有多个容器，如果有多个volume，这些volume对所有pod内的容器是可以访问的，可以根据需要这些容器挂载相应的volume。
引入volume后，另一方面volume只是一种抽象机制，他可以对接多种实际的底层存储，比如云存储，阿里云OSS，AWS EBS等。也可以是网络问卷系统，比如：NFS,Ceph。
mysql pod 挂载本地hostpath存储卷 k8s存储解藕PVC和PV k8s存储解藕机制PVC：持久卷申请 PV：持久卷 通过引入PVC，开发或者发布人员，在发布文件的Volume当中直接引用持久卷申请PVC，这是一个抽象概念，其中只规范了存储的需求，比如存储的大小，读写模式，并不规范存储实现的细节。 K8S的管理员可以预先为不同环境的K8S集群定制提供各种不同的存储卷PV，底层可以对接具体的持久化存储。运行时PVC和PV将通过存储类名StorageClassName或者label的形式绑定，让PVC和某种具体的持久化存储关联对接。 PVC既可以和持久化的PV绑定，也可以和存储类StorageClass进行绑定，StorageClass是一种高级的存储定制分类机制，一般由K8S集群管理员定制提供，一般的K8S集群都提供缺省的存储类，如果在PVC当中没有说明存储类名，那么他将绑定缺省的存储类。 PVC和PV的绑定叫做静态绑定，PVC和StorageClass的绑定时动态绑定，引入PVC一方面让Volume和具体的持久化存储的实现进行了解耦，提供了灵活性和可一致性，让应用发布很容易在不同的环境或者云提供商间进行迁移，另一方面PVC的引入还实现了职责分离，volume和PVC一般由pod的开发或者发布人员定义，只需要提出存储的需求，不关心存储的实现，而PV或者StorageClass一般由K8s的管理员定制提供，他并不需要指定具体的应用的发布形式。pv和pvc yaml配置
pvc定义：
spec：规范
storageClassName:standard存储类名
accessModes： readWriteOnce访问模式，只允许一个节点访问
resource request storage：250 存储容量
pv定义：
spec：规范
storageClassName:standard存储类名(和pvc中配置一致)
capacity storage:容量
accessModes： readWriteOnce访问模式，只允许一个节点访问
hostPath:本机路径，在本地为hostPath创建localPV
claimName引用pvc 和集群中的pv进行绑定，解耦
pvc/pv小结pod 可以关联Volume Pod当中的容器可以挂载Vomule,Volume可以对接引用PVC ，PVC可以绑定PV，PV可以对接具体的物理存储，PVC是比较重要的一环，他的引入让Volume和具体的持久化存储之间实现解耦合职责分离。
- PersistentVolumeClaim(PVC)是K8s支持的一种存储解藕机制，PVC在Volume和PV之间引入了一层斜街。
- PersistentVolume（PV）是K8s支持的持久化存储抽象，底层可以对接各种物理存储机制。
- Pod -> Volume -> PV -> 物理存储
K8S通过Request和limit来支持资源的申请和配额的管理，对于CPU和Memory这俩种主要的计算资源，K8s都支持在容器级别设置Request和Limit。 Request表示应用发布时，对容器的CPU或者Memory预估使用量提出的申请，K8s会根据目前集群内节点的资源空闲情况进行调度决策，如果申请的资源能够满足，那么K8S会将Pod调度到满足资源需求的节点上运行，保证给与容器所申请的资源，如果申请的资源暂时不能满足，那么对应的Pod发布会处于Pedding等待状态，除非后续有足够资源空闲出来，或者给集群新增资源。 limit标识容器运行时对资源的一种限制，limit可以限制应用申请过多内存，起到安全防护的作用，K8s对CPU和Memory限制的处理方式不同，如果容器的CPU使用量达到或者超过限制，那么K8S会限制该容器对CPU资源的额外使用，即throttling。如果容器的Memory使用量达到或者超过限制，那么K8s会直接kill掉 Pod里面的容器，并重启容器，即OOMKill。
对于Request和limit有三种常见的设置，K8s会根据不同的设置标记不同的QOS类别(quality of service )当集群资源不足时，K8S根据Pod上标记的QOS类别做踢出决策，以便腾出空闲资源。
- Guaranrteed: Request=Limit 保证型QOS类别，节点资源不足时，只有在内存使用量超限时才会被Kill
- Burstable: Request
- Best Effort： Request Limit 尽最大努力型QOS类别，节点资源不足时，这类pod首先会被Kill
kubectl get no 查看本机节点的信息 kubectl describe 查看创建本机节点的描述limit /request yaml配置
模拟内存申请超限设置：
始终有2个pod无法启动
模拟容器的CPU使用量达到或者超过限制 K8s会直接kill掉 Pod里面的容器
在k8s集群中启用metrics-server以后，可以通过cAdvisor via Kubelet等组件定期去抓取pod 还有node上的资源使用的metrics，并且通过metrics API 暴露metrics ，然后可以通过kubectl访问这些metrics，k8s支持的HPA(pod自动伸缩)也依赖metrics API 。除了metrics server以外，用于k8s监控的主流方案prometheus也是使用比较多的。
metrics-server 发布在kube-system命名空间下
