大多数有状态的应用都是需要持续存储数据的。容器本身有生命周期，容器终结后，或者编排到其他节点运行，那就意味着数据不能存放在容器内，否则在删除或者容器损坏时数据会丢失 引言 在k8s中，pod一直运行在机器上，除非机器宕机pod才会被调度到其他机器，顶多重启。一旦这个pod被删除(故障)，或者机器宕机(被编排到其他节点)，这个pod就会重构。如果数据存放在pod的名称空间中，数据随着pod的终结而消

此前，在的存储卷类型介绍中，emptyDir只在节点本地使用。创建一个pod，一个存储卷，pod被删除，存储卷也会被删除.empryDir数据随着pod的创建而创建，随着删除而删除empryDir可以当临时目录，或者缓存使用(关联宿主机的目录可以是宿主机的内存，将内存放到pod存储卷)。没有持久化。本次将详细实验一下emptyDir的用法 emptyDir存储卷 1，pod上定义volume,vo

此前在存储卷类型中提到，hostPath位于主机路径，在宿主机创建目录挂载。一定意义的持久性。pod所在宿主机之上的，脱离pod容器名称空间之外的，宿主机的文件系统某一个目录与pod建立关系。当pod被删除，存储卷不会被删除。只要同一个pod调度到同一个节点，数据依然可被正常使用。 volumes： hostPath: path: type type字段支持为了测试效果，在三台node上都创建这个

共享存储特性是不管node是否挂掉，pod中容器是否在同一个节点，数据都不丢失，数据不存放在某一个单独的node之上。这和之前的主机存储卷hostPath，empryDir在持久化存储上效果更好。在yml配置文件中定义，且被volumeMounts挂载即可，如下： - name: linuxea-image nfs: path: PATH server: Server 以nfs为例做共享存储测试

此前在存储卷类型中介绍过pvc，以及其他的存储卷类型，本节笔记介绍pvc和nfs的使用 PVC 在pod中只需要定义存储卷，定义时只需要说明需要用到的大小，这个类型就是pvcl类型存储卷而pvc存储卷必须与当前名称空间中的pvc，建立直接绑定关系，而pvc必须与pv建立绑定关系，而pv则是某个真正存储设备的存储空间，如下：pv与pvs是kubernetes上抽象的，且标准的资源，与创建其他的pod

在之前的描述中，我们知道pv和pvc在使用中存在一种问题。pvc申请的的大小并不意味着就有符合pvc申请条件的pv。之前有意设定了符合pvc条件的pv，并成功的被pod绑定所使用。 StorageClass k8s也考虑到这种情况，于是有意的设计了一种工作逻辑，能够让pvc在申请pv时候，借助存储类--->中间层(StorageClass)完成资源分配 首先，将众多存储归类，将相同的存储分为

在之前ConfigMap介绍中，我们知道ConfigMap存在的目的并不是为pod提供存储空间来用的，而是给用户提供从集群外部向pod内部应用注入配置信息，本篇笔记简单介绍如何注入一些配置信息，发分别是环境变量和文件的方式。在configMap中，会用到configMapKeyRef和secretKeyRef.configMap也属于名称空间资源。在创建时，没有spec，而有data，结构相对简单

在之前的ingress的tomcat https中已经使用过secret，secret适用于密钥文件，密码等。secret也有很多类型 generic：通用的，保存密码 tls：保存私钥和证书 docker-registry：docker的认证信息：当up一个容器的时候，首选会检查本地是否有这个镜象，如果没有就会到registry拉取。如果是私有的仓库，则需要输入账号信息登录，而后拉取。这些过程通

在之前，我们知道应用程序分为两类，一种是有状态，一种无状态。无状态的有nginx等。有状态的居多。 如：redis,mysql,zook集群等，其中一些不单单有主从状态，更有启动顺序等的区分。这时候可使用statefulse，但是statefulse在完成一些配置的时候仍然是非常麻烦的，很多时候需要手动编写脚本，或者依赖于地第三方的一些工具来做。statefulse在处理，特别是在一些运维逻辑非常

在前面的一节中了解过SatefulSet控制器. 在看看如何创建satefulset，在创建之前，先准备好pv以便于使用VolumeClaimTemplate 创建PV 尽管使用VolumeClaimTemplate会自动创建pvc并且绑定pv，但是pv在这里仍然需要自己手动创建(如果你有动态供给的话另说)。仍然使用之前的nfs [root@linuxea volume]# cat pv-demo

kubernetes上运行着众多的应用，特别是无状态的应用，更甚有一些核心的数据。对于这些数据的访问或者管理，并不是任何人可以随意的管理使用的。因此，kubernetes对于整个系统的认证，授权，以及后续的访问控制做了非常紧密和精心的设计。 通常，客户端通过客户端工具kubectl来访问kubernetes， 对于管理员或者kubectl来讲api server是作为管理的唯一入口。 这联想起了i

在kubernets上有一些服务和客户端需要与api server交涉，并且集群内部会运行类似的pod资源，这些资源是需要访问api server的 ，如: CoreDNS,以及dashboard dashboard提供一个web界面来管理kubernetes，通过service暴漏到外部，通过浏览器打开使用。当然会有通过dashboard来进行增删改查资源，那意味着dashboard这个pod就

RBAC是基于角色的访问控制。Api server的客户端在认证时，如果要基于配置文件来保存配置信息，而并不是使用serviceAccount使用token认证，就应该配置为一个配置文件。 事实上，kubenetes中大大多数组件要连接api server都需要认证，这些都可以算作客户端。这些组件能够链接入正确的集群，就需要提供正确的证书，私钥等信息，这些信息保存在配置文件，这个配置文件有个专用的

之前我们知道kubernetes的授权是用插件来实现，并且支持很多插件，并且支持很多插件同时使用，且只要通过其中一个授权检查通过则不会在进行其他插件进行检查，而后由准入控制插件后续检查。 授权插件常用有四个：节点Node，ABAC属性访问控制，RBAC，Webhook回掉机制实现授权、 RBAC RBAC的全称是Role-based AC，在kubernetes中RBAC就是定义标准的资源： Ro

不管是role，rolebinding还是clusterRole，clusterRolebinding都是资源清单中的标准资源 我们创建linuxea-readpod和linuxea-cluster-read分别示例RBAC对权限的控制，图示如下： 可以使用kubectl create role --help查看帮助信息 创建ROLE 创建role，对pods有get,list权限，使用-dry-

延续上一篇Role和Cluster Role示例,其中绑定都是role绑定rolebinding，clusterrole绑定clusterrolebinding，现在使用rolebinding绑定clusterrole，这样以来权限就会降级到rolebinding所在的权限 我们先切换到kubernetes-admin用户下 [root@linuxea role]# kubectl config

dashboard也是做为kubernetes核心附件存在，这种附件还有就是作为名称解析和服务发现的coredns，通常系统部署后会自动安装。Dashboard在新的版本里面有这复杂的权限检查机制 在使用kubeadm安装的RBAC默认强制启用的，而Dashboard接口是管理整个集群的接口，认证管理的方式类似于“自我认证”。 它类似于kubernetes集群UI前段，认证也是kubernetes

此刻如果不希望使用token认证，而是希望通过config文件认证，就需要创建一个config文件 但是仍然需要创建serviceaccount，并且创建rolebinding或者clusterrole绑定，并且配置，在配置中还需要将此前的token字段解码放进去，也就是说使用config文件认证就需要先创建token认证，在token认证之上做的config认证。而后完成通过提交一个配置文件来完

我们知道docker有四种网络模型，bridge(桥接)，joincd(联盟式)，open(开发式)，none(不适用任何网络模式)，那么，不管使用那种网络模式，在跨节点访问的时候都需要NAT机制来实现。 docker网络通信 任何一个pod(pod的ip是私有地址)在离开本机时候都需要做源地址转换，确保能够携物理地址向外转发，如下： containerA具有虚拟的eth0网卡，另外veth一边关

定义的配置也是json格式，我们可以使用directorouting，能够路由则进行路由，不能路由则使用隧道转发 flannel运行在configmap的kube-system名称空间中 [root@linuxea flannel]# kubectl get configmap -n kube-system NAME DATA AGE coredns 1 25d extension-apiserv