k8s卷管理

k8s和docker默认使用本地的主机磁盘

容器卷生命周期

在资源短缺下，k8s可能会停止容器，在相同或另一个k8s节点上重新启动容器

Pod内共享卷

k8s中通一个Pod的多个容器可以共享相同IP地址、网络端口和IPC，程序间可以通过localhost网络相互通信，但文件系统是相互隔离的

示例：同个Pod中Tomcat和Nginx容器，可以通过localhost互相通信，但不能访问彼此的配置文件

无状态和有状态程序

无状态应用程序中使用临时卷，容器上应用程序不需要保留数据

示例：通过k8s中的emptydir卷共享日志文件

有状态应用会使用持久卷，如ES，即使容器重新启动也必须保留数据

不需要在相同pod中配置ES容器，ES可独立扩展

Kubernetes持久卷和动态配置

Persistent Volumne(PV)，如AWS EBS、Google Persisten Disk

支持网络（分布式）文件系统，如NFS、ClusterFS、Ceph

还支持块设备，如iSCSI和FC

持久卷抽象层声明

直接将持久卷指定到配置文件中，与特定基础设施构成紧耦合

从容器角度，pod定义不应锁定到特定环境，基础设施因环境而异，理想pod应该是灵活的抽象的，仅指定卷名和挂载点

k8s提供抽象层，在pod和持久卷之间关联，称为持久卷声明 persistent volume claim，PVC，使基础设施被分离出来，k8s管理员只需预先分配所需容量的持久卷，然后k8s将绑定持久卷和PVC

动态配置和存储类型

PVC为持久卷管理提供灵活性，但是预分配持久卷池不具备成本效益，尤其公有云

k8s通过支持持久卷的动态配置dynamics provision来改善这种情况

k8s管理员定义持久卷provisioner，称为存储类storageClass，持久卷声明要求storageClass动态分配持久卷，后将其与PVC关联

使用状态集（StatefulSet）管理具有持有卷的Pod

状态集和持久卷组合功能强大，可以使应用程序变得更灵活，从而更方便进行扩展

状态集涵盖了Pod和持久卷之间的绑定，当Pod扩展或收缩时，将同时创建或删除Pod和持久卷

Pod的创建过程是串行的，如当请求k8s扩展另外两个StatefulSet时，k8s先创建持久卷声明1和po1，再创建持久卷声明2和pod2

即使一个pod已销毁，状态集也会保留pod的位置（名称、IP、相关metadata）及持久卷，然后尝试重新创建一个容器，重新分配到同一个pod并挂载相同的持久卷

可帮助控制Pod、持久卷的数量，同时通过Scheduler保证应用程序始终在线

具有持久卷的状态集需要动态配置和存储类，状态集时刻扩展的，添加pod时，k8s需要知道如何配置持久卷

持久卷示例

ES集群

ES使用多个节点来构建集群，有不同类型的节点，如master、data、coordinate，每个节点在集群中有不同的角色和职责，相应的k8s配置和持久卷应与之保持一致

示例：ES节点组件和角色

ES主节点：唯一，其他节点需要指向它进行注册，使用statefulSet分配固定的DNS名称

ES备份节点：主节点的备用节点，扩展StatefulSet来分配，无需另外创建k8s对象

ES数据节点：负责存储数据，如有更大的数据量或更多查询请求，使用StatefulSet和持久卷进行横向扩展，不需要DNS名称，不需要为ES数据节点创建服务

ES协调节点：负责负载均衡，需要水平扩展以处理更多来自外部的HTTP流量，并不需要对数据持久保存，可以将复制集ReplicaSet与服务结合使用，对外暴露HTTP接口

Kubernetes资源管理

资源服务质量（QoS）

可以关注管理员按不同优先级分配和管理容器

根据Pod设置，按优先级将pod分为三类：Guaranteed Pod->Burstable Pod->BestEffort Pod

配置BestEffort Pod

QoS中最低优先级，资源短缺下，该类Pod将首先被终止（资源限制设置为0或不指定）

BestEffort Pod常用于无状态和可恢复的应用程序，如worker进程、代理或缓存节点

配置Guaranteed Pod

QoS中最高优先级，资源短缺下，k8s调度器会长期保障该类容器到最后

用来运行关键任务，如带持久卷的后端数据库、主节点

需要将资源限制和资源请求显示设置为相同值，或仅设置资源限制

如不确定应用程序所需CPU和内存资源，可先试用Burstable类型观察一段时间

配置Burstable Pod

资源限制配置不是强制性的，当节点资源充足时，pod可以尽可能的消耗CPU和内存

任何类型的应用都可以使用

如已知道应用程序最小内存大小，可指定请求资源，有助于k8s调度器分配正确的节点

QoS颗粒度是Pod级别而不是容器级别，如具有两个容器的Pod，容器A容器GB配置B，则选B

资源使用监控

如资源不足，Pod可能无法由k8s调度器进行部署

kubectl describe nodes可以查看分配资源

如节点已运行了Burstable Pod配置，但没资源分配，则不用执行该pod，需要k8s节点提供更多资源