在之前的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

在前面的笔记中记载了flannel，flannel是做不了网络策略，但是flannel的vxlan隧道模式和directrouting，以及host-gw都非常简单好用。但是缺陷在某些场景也是不适应的，本篇笔记中简单介绍projectcalio，简称calico。 calico并且支持BGP协议的方式构建pod网络，通过BGP的路由学习生成节点到节点直接pod路由表信息，并且在变动时候自动修改，并

在kubernets中运行pod资源的节点中，master节点运行控制组件，主要控制组件如： apiserver controller-manager scheduler 除此之外，master还依赖ETCD存储节点，或者是一个有冗余能力的存储集群。在使用kubeadm部署时候，这些组件会被运行成pod应用程序，并且是静态pod。简单的讲，就是运行在master本地的一个守护进程。从这个方面讲，m

之前的scheduler，默认的default scheduler分三部实现调度过程，首先是预选，从所有节点当中选择基本符合选择条件的节点，而后在众多基本符合选择条件的节点中通过优选函数，对这些节点加以比较。并且从最高得分当中随机选择一个作为运行pod的节点。这就是scheduler负责的功用。 高级调度机制 节点调度 在某些调度参加中，可通过自己的预设来影响预选，优选的过程，从而使得调度的操作符

Pod自身的亲和性调度分为两种表示形式，第一种podinity(亲和性)，第二张podAffinity(反亲和性) pod亲和性 pod与pod更倾向运行在一起。一般出于高效通讯的需求把pod对象组织在相近的位置，同一个节点，同一个机架，同一个机房，甚至于同一个区域或者地区，便于pod通讯。但是有些时候在部署两套系统的时候，出于一些安全或者其他的考虑，不能够部署在一起的时候，就需要反亲和性。 po

在前面的两种方式中，都是由pod去选择的，节点被动选择运行。而污点调度方式就给了节点的选择权。让节点可以选择让那些pod运行在节点上。总的来说，污点就是定义在节点上的键值属性数据。 此前，我们知道，键值属性有三类，第一类叫标签，第二类叫注解，第三类便是污点。污点用在节点之上，而前两类所有资源对象都可以使用。 pod亲和性和node亲和性都是pod的属性，而污点是节点的属性 污点也是一种键值属性，主

之前介绍的pod资源调度，此篇主要记录的是kubernetes上运行pod的对象的时，如何去监控系统级的一些资源指标，业务指标的获取，以及监控。 容器在启动的时候，可以根据资源需求，配置资源限额的，如CPU，内存。而CPU资源属于可压缩资源，一个容器在本应该获取指定的资源获取不到的时候，进行等待即可，而内存则不一样。内存属于非可压缩资源，如果内存资源因为指定的大小而不够的时候会因为内存资源耗尽而被

在docker中可以使用那个stats查看容器的资源使用，而在Kubernetes中可以使用top查看。但是一般都会报错，如下： [root@linuxea metrics]# kubectl top pod Error from server (NotFound): the server could not find the requested resource (get services ht