容器技术---（三）kubernetes存储

Configmap配置管理

Configmap用于保存配置数据，以键值对形式存储；ConfigMap资源提供了向Pod注入配置数据的方法，旨在让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性；典型的使用场景有：填充环境变量的值、设置容器内的命令行参数、填充卷的配置文件

创建ConfigMap的方式有4种：使用字面值创建、使用文件创建、使用目录创建、编写configmap的yaml文件创建

##使用字面值创建，键值对的方式

##使用文件创建，文件名为key，文件内容为值

##使用目录创建，文件名为key，文件内容为值

##使用yml文件创建

如何使用ConfigMap：通过环境变量的方式直接传递给pod、通过在pod的命令行下运行的方式、作为volume的方式挂载到pod内

##使用configmap设置环境变量

##直接传递configmap中的变量，不在yml文件中指定键值

##使用conigmap设置命令行参数

##kubectl describe pod pod4

##通过数据卷使用configmap

configmap的热更新

##创建nginxconf的configmap并将其挂载到nginx的默认include目录下

##此时只能通过nginxconf这个configmap中定义的端口访问

##编辑nginxconf这个configmap将其端口修改为8080

##此时虽然容器内的文件内容会更新（有一定延迟），但是更新的设定并没有生效；需要手动触发Pod滚动更新, 这样才能再次加载nginx.conf配置文件

##configmap热更新后，并不会触发相关Pod的滚动更新，需要手动触发；通过修改“version/config”来手动触发Pod滚动更新，更新后的pod也会获取到新的IP；此种方式下使用configmap挂载的env环境变量是不会更新的

##也可以在更改了configmap配置内容后通过删除控制下的pod以达到pod的热更新（此种更新方式延迟最低）

Secret配置管理

Secret对象类型用来保存敏感信息，例如密码、OAuth令牌和ssh key；敏感信息放在secret中比放在Pod的定义或者容器镜像中来说更加安全和灵活

Pod可以用两种方式使用secret：作为volume中的文件被挂载到pod中的一个或者多个容器里；当 kubelet为pod拉取镜像时使用

Secret的类型：

Service Account：Kubernetes自动创建包含访问API凭据的secret，并自动修改pod以使用此类型的secret

Opaque：使用base64编码存储信息，可以通过base64 --decode解码获得原始数据，因此安全性弱，Opaque类型的Secret其value为base64编码后的值

kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息

##serviceaccout创建时Kubernetes会默认创建对应的secret，对应的secret会自动挂载到Pod的 /var/run/secrets/kubernetes.io/serviceaccount目录中

##每个namespace下有一个名为default的默认的ServiceAccount对象

##ServiceAccount里有一个名为Tokens的可以作为Volume一样被Mount到Pod里的Secret，当Pod启动时这个Secret会被自动Mount到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权过程

##从文件中创建secret

##从字面值创建secret，密码具有特殊字符时需要使用 \ 字符对其进行转义

##从yaml文件创建secret

##默认情况下kubectl describe secret为了安全不会显示密码的内容

##可以通过以上方式查看

##将secrect通过volume挂载到pod中

##向指定路径映射secret的键值

##将Secret设置为环境变量

##环境变量读取Secret很方便，但无法支撑Secret动态更新

##kubernetes.io/dockerconfigjson用于存储docker registry的认证信息

##在集群节点都成功登陆镜像仓库并拥有认证时，在yml文件中的pod未指定镜像拉取secret，此pod依然显示镜像拉取失败

##在集群节点都登出镜像仓库并移除认证时，在yml文件中的pod指定镜像拉取secret，此pod则能成功运行

Volumes配置管理

容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题，首先，当容器崩溃时，kubelet将重新启动容器，容器中的文件将会丢失，因为容器会以干净的状态重建；其次，当在一个Pod中同时运行多个容器时，常常需要在这些容器之间共享文件；Kubernetes抽象出 Volume对象来解决这两个问题

Kubernetes卷具有明确的生命周期，与包裹它的Pod相同；因此，卷比Pod中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留；当一个Pod不再存在时，卷也将不再存在；也许更重要的是，Kubernetes可以支持许多类型的卷，Pod也能同时使用任意数量的卷

<