目录

一、Kubernetes卷的介绍和使用：

1、kubernetes支持的卷类型：

2、emptyDir卷：

3、hostPath卷：

4、NFS卷：

5、持久卷(PV)与持久卷声明(PVC)：

二、Kubernetes中服务依赖启动顺序：

三、Kubernetes中pod之间的访问：

---

一、Kubernetes卷的介绍和使用：

1、kubernetes支持的卷类型：

Kubernetes 支持下列类型的卷:

awsElasticBlockStore 、azureDisk、azureFile、cephfs、cinder、configMap、csi、downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker、gcePersistentDisk、gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、nfs、persistentVolumeClaim、projected、portworxVolume、quobyte、rbd、scaleIO、secret、storageos、vsphereVolume

2、emptyDir卷：

当Pod指定到某个节点上时,首先创建的是一个emptyDir卷，并且只要Pod在该节点上运行，卷就一直存在。就像它的名称表示的那样，卷最初是空的。尽管Pod中的容器挂载emptyDir卷的路径可能相同也可能不同,但是这些容器都可以读写emptyDir卷中相同的文件。

当Pod因为某些原因被从节点上删除时，emptyDir卷中的数据也会永久删除。

3、hostPath卷：

hostPath卷能将主机节点文件系统上的文件或目录挂载到Pod中。 虽然这不是大多数Pod需要的，但是它为一些应用程序提供了强大的逃生舱。

4、NFS卷：

NFS卷将NFS(网络文件系统)挂载到Pod中，和emptyDir卷不同的是NFS卷的内容在删除Pod时会被保存，卷只是被卸载掉了。这意味着NFS卷可以被预先填充数据，并且这些数据可以在Pod之间“传递”。

5、持久卷(PV)与持久卷声明(PVC)：

PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。

PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。

有两种PV提供的方式：静态和动态

静态PV：集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用。

动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。

实质关系：就是通过集群管理员创建PV，在PV的yaml文件中通过一定的语法来配置，PV的存储来源可以是NFS、ISCSI、或其他云存储系统，实质上是通过PV来统一管理集群中的持久化存储文件系统。

然后通过在PVC的yaml中通过一定的语法来配置信息，并选择对应的PV。

最后在容器的yaml文件中来选择对应的PVC名称来完成容器最终绑定到PV上。

二、Kubernetes中服务依赖启动顺序：

在K8S部署中，有时候容器启动顺序因为我们业务需要是有要求的，比如业务服务可能需要在配置中心、注册的中心启动后才启动，我们在yaml中通过initContainer来阻塞启动，如下以业务服务需要在apollo配置中心启动后才启动需求为例：

initContainers:

  - command:

      - sh

      - -c

      - until curl -m5 -s apollo-configservice-fat.my-namespace.svc.cluster.local:6166/info; do echo waiting for config; sleep 5; done;

    image: harbor.shanhy.com:443/dockerhub_proxy/yauritux/busybox-curl:latest

name: wait-for-config

示例说明：

apollo-configservice-fat：为配置中心的container-name，如果你依赖的服务在一个命名空间，直接使用apollo-configservice-fat:6166/info 即可，如上写法是同集群不同命名空间之间的写法。

my-namespace：为配置中心所在命名空间的名称

svc.cluster.local：为固定写法

6166：为配置中心的端口号

/info：为配置中心启动后可以正常访问的一个URL地址，这个根据自己实际需求填写，比如 /actuator/metrics等等，建议写一个测试接口，该接口就是用来验证服务启动正确。

initContainer在yaml中位置如下：

三、Kubernetes中pod之间的访问：

k8s集群内pod用外网地址去访问时走的是外网的流量。k8s的pod之间相互访问，最好使用servicename的方式去访问。

访问服务书写方式：servicename.namespace:port/api或servicename:port/api。在配置文件中配置的时候，需要在前面添加上http://，否则会找不多对应的地址。

例如：

api {

      sample_info = "http://stats-service:8080/api/samples"

      family_match = "http://api-service:8080/api/match"

  }