目录
ConfigMap配置管理
Configmap用于保存配置数据，以键值对形式存储。
configMap 资源提供了向 Pod 注入配置数据的方法。 旨在让镜像和配置文件解耦，以便实现镜像的可移植性和可复用性。 典型的使用场景：
填充环境变量的值
设置容器内的命令行参数
填充卷的配置文件创建ConfigMap的方式有4种： 使用字面值创建 使用文件创建 使用目录创建 编写configmap的yaml文件创建
使用configmap设置环境变量
通过数据卷使用configmap
configmap热更新
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解码获得原始数据，因此安全性弱。
kubernetes.io/dockerconfigjson：用于存储docker registry的认证信息。
在harbor仓库中新建用户
将用户加入到私有仓库中
Volumes配置管理
容器中的文件在磁盘上是临时存放的，这给容器中运行的特殊应用程序带来一些问题。首先，当容器崩溃时，kubelet 将重新启动容器，容器中的文件将会丢失,因为容器会以干净的状态重建。其次，当在一个 Pod 中同时运行多个容器时，常常需要在这些容器之间共享文件。 Kubernetes 抽象出 Volume 对象来解决这两个问题。
Kubernetes 卷具有明确的生命周期,与包裹它的 Pod 相同。 因此，卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 当然，当一个 Pod 不再存在时，卷也将不再存在。也许更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。
卷不能挂载到其他卷，也不能与其他卷有硬链接。 Pod 中的每个容器必须独立地指定每个卷的挂载位置emptyDir卷(临时卷)
同一pod内容器之间的网络栈是共享的
重新打开一个终端，成功访问
使用dd命令生成200M的文件，可以看到提示报错，因为限制物理内存使用100M
emptydir缺点：
不能及时禁止用户使用内存。虽然过1-2分钟kubelet会将Pod挤出，但是这个时间内，其实对node还是有风险的；
影响kubernetes调度，因为empty dir并不涉及node的resources，这样会造成Pod“偷偷”使用了node的内存，但是调度器并不知晓；
用户不能及时感知到内存不可用hostPath 卷
能将主机节点文件系统上的文件或目录挂载到 Pod 中。 虽然这不是大多数 Pod 需要的，但是它为一些应用程序提供了强大的逃生舱
在server3上自动创建/data，写入数据
在server2上可以成功访问 
查看server4自动创建/data。写入数据
可以成功访问
实现不同节点之间文件共享
server3和server4node节点安装nfs，并且挂到server1的/nfsshare
在/nfsshare目录下写入数据
pod 可以成功访问
PersistentVolume（持久卷） PV
PersistentVolume（持久卷，简称PV）是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。
PersistentVolumeClaim（持久卷声明，简称PVC）是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）
有两种PV提供的方式：静态和动态。
PVC与PV的绑定是一对一的映射。没找到匹配的PV，那么PVC会无限期得处于unbound未绑定状态。
静态PV创建
server1中创建两个目录
在server1的/nfsshare/pv1写入数据
可以成功访问
NFS动态分配PV
StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。
每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。
StorageClass的属性
删除之前创建的pv目录,动态pv会自动创建
上传所需镜像到本地仓库
vim pvc.yaml
kubectl apply -f pvc.yaml
kubectl get pvc #获取pvc处于绑定状态
kubectl get pv
kubectl get pod
kubectl get pod -o wide
curl 10.244.141.236 #访问失败，因为没有默认发布页面
kubectl delete -f pvc.yaml #在删除pvc时会连pv一起删掉
kubectl get pod
kubectl get pvc
kubectl get pv
可以看到动态创建的目录，在目录地下写入数据
访问成功
看到挂接的目录中变为回收打包状态
创建三个pvc之后目录动态更新
删除之后变为回收打包，手动删除
可以看到自动创建
删除pvc之后，目录自动清除
默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims配置存储：（只能有一个默认StorageClass） 如果没有默认StorageClass，PVC 也没有指定storageClassName 的值，那么意味着它只能够跟 storageClassName的 PV 进行绑定。
StatefulSet如何通过Headless Service维持Pod的拓扑状态
打开server1上nfs
StatefulSet将应用状态抽象成了两种情况：
拓扑状态：应用实例必须按照某种顺序启动。新创建的Pod必须和原来Pod的网络标识一样
存储状态：应用的多个实例分别绑定了不同存储数据。
StatefulSet给所有的Pod进行了编号，编号规则是：$(statefulset名称)-$(序号)，从0开始。
删除过程
PV和PVC的设计，使得StatefulSet对存储状态的管理
自动创建了三个存储目录
在目录中写入测试页，便于查看
唯一的标识
使用statefullset部署mysql主从集群:
部署 MySQL
MySQL 示例部署包含一个 ConfigMap、两个 Service 与一个 StatefulSet
这个无头服务给 StatefulSet 控制器为集合中每个 Pod 创建的 DNS 条目提供了一个宿主。 因为无头服务名为 mysql，所以可以通过在同一 Kubernetes 集群和命名空间中的任何其他 Pod 内解析 <Pod 名称>.mysql 来访问 Pod。
客户端服务称为 mysql-read，是一种常规服务，具有其自己的集群 IP。 该集群 IP 在报告就绪的所有MySQL Pod 之间分配连接。 可能的端点集合包括 MySQL 主节点和所有副本节点。
StatefulSet
同时在共享的目录下生成mysql目录
vim mysql.yaml #加入clone-mysql 的 Init 容器
kubectl apply -f mysql.yaml
第二个名为 clone-mysql 的 Init 容器，第一次在带有空 PersistentVolume 的副本 Pod 上启动时，会在从属 Pod 上执行克隆操作。 这意味着它将从另一个运行中的 Pod 复制所有现有数据，使此其本地状态足够一致， 从而可以开始从主服务器复制。
MySQL 本身不提供执行此操作的机制，因此本示例使用了一种流行的开源工具 Percona XtraBackup。 在克隆期间，源 MySQL 服务器性能可能会受到影响。 为了最大程度地减少对 MySQL 主服务器的影响，该脚本指示每个 Pod 从序号较低的 Pod 中克隆。 可以这样做的原因是 StatefulSet 控制器始终确保在启动 Pod N + 1 之前 Pod N 已准备就绪
kubectl get pod #看到pod已经running
kubectl describe pod mysql-0 #查看详细信息
kubectl logs mysql-0 -c init-mysql #查看init-mysql的日志通过从 Pod 名称的末尾提取索引来确定自己的序号索引，而 Pod 名称由 hostname 命令返回。 然后将序数（带有数字偏移量以避免保留值）保存到 MySQL conf.d 目录中的文件 server-id.cnf
kubectl logs mysql-0 -c clone-mysql #查看clone-mysql,将从另一个运行中的 Pod 复制所有现有数据，使此其本地状态足够一致， 从而可以开始从主服务器复制。
kubectl logs mysql-0 -c xtrabackup#
kubectl run demo --image=mysql:5.7 --restart=Never -it bash执行
mysql -h mysql-0.mysql#运行带有 mysql:5.7 镜像的临时容器并运行 mysql 客户端二进制文件， 将测试查询发送到 MySQL 主服务器（主机名 mysql-0.mysql）创建数据库，写入数据
在server1上可以看到数据已经同步过来
创建的westos数据库信息已经复制到从服务器
