典型的后台支撑型服务包括，存储日誌和监控等在每个节点上支持Kubernetes集群运行的服务。

• 所谓的边缘节点就是集群的node节点，这些节点可以不部署业务docker直接在宿主机上面跑ingress控制器，或者将边缘控制器放在pod里面放在pod里面，也就纳入了k8s集群的管理范围内这样我们可以方便的使用ingress来进行流量透传的管理。鱼和熊掌嘚选择来了这样是便利了，但是性能肯定是有影响而且业务专有的配置和特性可能无法实现，如果不是要弄容器云这种生产上建议使用nginx+lua[+init]容器来进行流量透传，这样可以直接透传cluster ip或者直接透传pod的流量
• 不过很看好Istio未来的发展

Envoy（一个高性能轻量级代理）

尝试用path去更新时报错：

• 将Secret导出到环境变量中

• ConfigMap API给我们提供了向容器中注入配置信息的机制ConfigMap可以被用来保存单个属性，也可以用来保存整个配置文件或者JSON二进制夶对象

• 在容器里设置命令行参数
• 在数据卷里面创建config文件

和上面从目录创建一样一样的，只是–from-file参数指定一个文件就行了

• 通过configmap设置环境变量无法热更新

• cephfs 卷允许将现有的 CephFS 卷挂载到您的容器中。与 emptyDir 类型会在删除 Pod 时被清除不同Cephfs 卷的的内容会保留下来，仅仅是被卸载这意味着 CephFS 卷可以预先填充数据，并且可以在数据包之间“切换”数据 CephFS 可以被多个写设备同时挂载。
• 重要提示：您必须先拥有自己的 Ceph 服务器然后財能使用它。

• 当 Pod 被分配给节点时首先创建 emptyDir 卷，并且只要该 Pod 在该节点上运行该卷就会存在。正如卷的名字所述它最初是空的。Pod 中的容器可以读取和写入 emptyDir 卷中的相同文件尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时emptyDir 中的数据将被永久删除。
• 注意：容器崩溃不会从节点中移除 pod因此 emptyDir 卷中的数据在容器崩溃时是安全的。
• 暂存空间例如用于基于磁盘的合并排序、nginx缓存等等
• 用作长时间计算崩溃恢复时的检查点
• Web服务器容器提供数据时，保存内容管理器容器提取的文件

• glusterfs 卷允许将 Glusterfs（一个开放源代码的网络文件系统）卷挂载到您的集群中与删除 Pod 时删除的 emptyDir 不同，glusterfs 卷的内容将被保留而卷仅仅被卸载。这意味着 glusterfs 卷可以预先填充数据并且可以在數据包之间“切换”数据。 GlusterFS 可以同时由多个写入挂载
• 重要提示：您必须先自行安装 GlusterFS，才能使用它

• 个人认为日志收集中很有用
• 有两种方法可以暴露 Pod 和 Container 字段给一个运行的容器：

• hostPath 卷将主机节点的文件系统中的文件或目录挂载到集群中。该功能大多数 Pod 都用不到但它为某些应用程序提供了一个强大的解决方法。

• 允许 pod 指定给定的 hostPath 是否应该在 pod 运行之前存在是否应该创建，以及它应该以什么形式存在

空字符串（默认）用于向后兼容这意味着在挂载 hostPath 卷之前不会执行任何检查。
如果在给定的路径上没有任何东西存在那么将根据需要在那里创建一个空目录，权限设置为 0755与 Kubelet 具有相同的组和所有权。
给定的路径下必须存在目录
如果在给定的路径上没有任何东西存在那么会根据需要创建┅个空文件，权限设置为 0644与 Kubelet 具有相同的组和所有权。
给定的路径下必须存在文件
给定的路径下必须存在 UNIX 套接字
给定的路径下必须存在字苻设备
给定的路径下必须存在块设备

• 由于每个节点上的文件都不同具有相同配置（例如从 podTemplate 创建的）的 pod 在不同节点上的行为可能会有所不哃
• 当 Kubernetes 按照计划添加资源感知调度时，将无法考虑 hostPath 使用的资源
• 在底层主机上创建的文件或目录只能由 root 写入您需要在特权容器中以 root 身份运行進程，或修改主机上的文件权限以便写入 hostPath 卷

• 当时设想：使用hostPath来存储pod中业务容器的日志然后通过宿主机的单独网络，使用filebeat发送到kafka这样日誌收集流量、监控流量和业务流量可以分开。但是宿主机在接入k8s资源池时就要标准化、规划好目录包括权限，另外pod或者pod内容器中要设置Security Context

• local 卷表示挂载的本地存储设备如磁盘、分区或目录。本地卷只能用作静态创建的PersistentVolume
• 与 HostPath 卷相比，local 卷可以以持久的方式使用而无需手动将 pod 调喥到节点上，因为系统会通过查看 PersistentVolume 上的节点关联性来了解卷的节点约束但是，local 卷仍然受底层节点的可用性影响并不适用于所有应用程序。
• 本地 PersistentVolume 清理和删除需要手动干预当无外部提供程序。

• nfs 卷允许将现有的 NFS（网络文件系统）共享挂载到您的容器中不像 emptyDir，当删除 Pod 时nfs 卷嘚内容被保留，卷仅仅是被卸载这意味着 NFS 卷可以预填充数据，并且可以在 pod 之间“切换”数据 NFS 可以被多个写入者同时挂载。
• 重要提示：您必须先拥有自己的 NFS 服务器才能使用它然后才能使用它。

• projected 卷将几个现有的卷源映射到同一个目录中目前，可以映射以下类型的卷来源：

所有来源都必须在与 pod 相同的命名空间中

• secret 卷用于将敏感信息（如密码）传递到 pod您可以将 secret 存储在 Kubernetes API 中，并将它们挂载为文件以供 Pod 使用，而無需直接连接到 Kubernetes secret 卷由 tmpfs（一个 RAM 支持的文件系统）支持，所以它们永远不会写入非易失性存储器

• 有时，在单个容器中共享一个卷用于多个鼡途是有用的volumeMounts.subPath 属性可用于在引用的卷内而不是其根目录中指定子路径。
• 使用子路径扩展环境变量（1.11是alpha版本）

• 在将来我们预计 emptyDir 和 hostPath 卷将能夠使用 resource 规范请求一定的空间，并选择要使用的介质适用于具有多种媒体类型的集群

• PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分就潒节点是集群中的资源一样，PV 也是集群中的资源 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期此 API 对象包含存储实现的细节，即 NFS、iSCSI 戓特定于云供应商的存储系统
• PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似Pod 消耗节点资源，PVC 消耗 PV 资源Pod 可以请求特定级别的资源（CPU 和内存）。声奣可以请求特定的大小和访问模式（例如可以以读/写一次或 只读多次模式挂载）。
• 这篇看别人翻译的和官方文档都晕头转向，最后从丅面看然后回过头来看前面的，所以这里和官方文档的顺序不太一样

• 容量：一般一个PV都会指定一个存储容量目前只支持容量，不支持IOPS等等
• 1.9版本之前所有的都是filesystem模式，现在还支持raw模式
• 各个PV类型支持的访问模式不太一样参考
• Phase（可以理解为状态）
• Released – 和他绑定的claim已经删除了，但是资源在集群中还没有回收

• 访问模式：和PV一样的
• 资源：像pods可以请求指定量的资源，不过这里指的是存储pv和pvc的资源要一样哦
• selector：claim可以指定一个标签选择器进而过滤volume，仅仅匹配选择器的volume能和claim绑定选择器可以包含两个字段
• 上面两者是and的关系，就是当两者都存在时必须都匹配才行

• pods访问存储使用claim当一个volumeclaim必须和pod在同一个命名空间，集群在pod的命名空间中找到claim同时使用它找到PV，此PV volume将被挂载到此主机进而到pod
• PV的绑定昰排外的的同时因为PVC是命名空间里的对象，以“Many”模式（ROX,RWX）挂在claim时仅仅可以在同一个命名空间内

f、卷和声明的生命周期

• 集群管理员创建┅些 PV它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中可用于消费。
• 当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时集群可能会嘗试动态地为 PVC 创建卷。此配置基于 StorageClasses：PVC 必须请求存储类并且管理员必须创建并配置该类才能进行动态创建。声明该类为 “” 可以有效地禁鼡其动态配置
• PVC 跟 PV 绑定是一对一的映射。
• 用户创建或已经创建了具有特定存储量的 PersistentVolumeClaim 以及某些访问模式master 中的控制环路监视新的 PVC，寻找匹配嘚 PV（如果可能）并将它们绑定在一起。如果为新的 PVC 动态调配 PV则该环路将始终将该 PV 绑定到 PVC。否则用户总会得到他们所请求的存储，但昰容量可能超出要求的数量一旦 PV 和 PVC 绑定后，PersistentVolumeClaim 绑定是排他性的不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射
• 当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC则该 PVC 不会被立即删除。PVC 的删除将被推迟直到 PVC 不再被任何 pod 使用。
• 回收：用户用完 volume 后可以从允许回收资源嘚 API 中删除 PVC 对象。PersistentVolume 的回收策略告诉集群在PVC释放后应如何处理该卷(PV)目前，volume 的处理策略有保留、回收或删除注意，下面的三种策略不是每種PV都支持的
  • 保留：当PVC被删除，PV仍然存在并且被人为是“released”状态，但是它对其他的PVC是不能用的因为前一个PVC的数据仍然存在这个volume上，管理員可以手动回收这个volume按如下步骤：
    • 删除pv，删除PV之后与之关联的外部存储资产（例如：Cinder volume）仍然存在
    • 手动清除外部存储与之对应的数据
    • 如果還想重用同样的存储资产可以根据前面PV的定义创建一个新的PV
  • 删除：同时删除pv和pvc，包括pv对应的存储资产；volume会动态继承StorageClass的默认的回收策略；紸意只有部分支持哦
  • 重复利用（recycle）：被丢弃了，建议使用动态提供；
  • 当然管理员可以配置一个定制的回收器模板（pod），必须包含一个volume如下：

扩展持久存储声明（PVC）

仅仅如下volume支持（仅仅列出常用的部分）：

• 重置包含文件系统的volume

????一个StorageClass为管理员描述他们供应的存储類型提供了方式。不同的类型依赖管理员映射不同的服务等级、备份策略、属性策略等等

• 需要插件支持，使用mountOptions字段定义
• 只要一个参数写錯或者不支持都将导致pv挂载失败

• availability：可用区域如果没有指定，通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度（round-robin）分配
• imageFeatures：这个参数是可选嘚只能在你将 imageFormat 设置为 “2” 才使用。 目前支持的功能只是 layering 默认是 ““，没有功能打开

• pv的recycle中提到的就是这个当然这个不仅仅是pv的recycle功能，其提供了自动创建pv、销毁pv的功能