kube-system下实例了两个deployment，核心资源，一个是coredns，一个是dashboard
traefik在daemonset里，两个pod控制器需要掌握，daemonset，deployment
这里使用json格式来展示的yaml
spec就是真正定义pod控制器的属性，selector就是标签选择器，
下面就是定义一个template模版，实际上是pod的模版，pod的一些特性就被定义到了pod控制器里，pod资源本身是一组对象，启动参数，内容，挂载，存活性探针都可以定义到pod控制器里
里面有一堆启动参数
一个是暴露81端口，一个是用nat的网络8080
resource是限制你pod的资源的
从spec到这都是pod特性，可以用explain来看显示的意思
serviceaccount服务账号，牵扯到了k8s的核心理念，rbac
基于角色的访问控制，RBAC（role basic access control）
对一些资源有一些权限（读get，写wirte，更新update，列出list，监视watch），用户就有用户账户，在k8s里有两种账户（用户账户user accoun UA，服务账户 service account SA）。
之前启动kubelet的时候做了一个kubeconfig配置文件，这个kubeconfig配置文件就是用户的配置文件
这个名字就是k8s集群里的一个用户账户，用户账户的名字就叫k8s的node
什么样的账户什么样的权限，这个就是授权的过程，k8s基于角色的访问控制下，无法直接给账户赋予权限，只能通过中间的一个角色，先给用户账户和服务账号先去绑定响应的角色，然后给相应的角色赋予相应的权限，也就是等于中间收个过路费
角色就完美充当了，账户要想获得集群里相应权限的中间人，无法给账户赋予直接的权限。
在k8s里有两种角色（role普通角色（只能应用在某一个特定的名称空间下，比如kube-system名称空间，就可以给kube-system里创建相应的角色，如果create一个role资源指定了-n namespace=kube-system，name这个角色只对本名称空间有效），clusterRole集群角色，对集群整个有效）
所以绑定角色操作就有2种，role binding，clusterrolebinding，把账户绑定角色，就称为绑定角色，也是一种资源，也有对应的yaml文件
服务账户是所有在k8s里面运行的pod，是k8s最小的运行单元，所有的pod都必须有一个服务用户service account
default名称空间，有两个起来的pod
对应的镜像是nginx;curl
只要运行在k8s集群里的pod，就一定有一个服务账户，如果没有显示指定的服务账户，就给你一个默认的服务账户
traefik的rbac的yaml文件最好看
第一段配置声明了一个叫service account的服务用户，这个服务用户的名字叫traefik-ingress-controller。名称空间在kube-system。
实际上这段就创建了服务用户
这一段其实在做clusterRole，相当于去声明一个集群角色，名字叫traefik-ingress-controller。然后定义了一组规则rules：定义角色的同时赋予权限
clusterRolebinding集群角色绑定，说白了就是把之前定义的角色和traefik-ingress-controller服务账号关联起来
metadata是name是集群角色绑定的名字，roleref是参考哪个集群角色是traefik-ingress-controller。
subjects就是集群角色给哪个用户使用，类型是服务用户，和集群角色通过clusterrolebinding这种资源，关联起来了
所有的rbac文件，无外乎这几步，创建账户，比如traefik是以pod身份在k8s集群工作，所以只能用服务账号。kubelet就不是工作在k8s里的，是在宿主机上二进制部署的，就不能用服务账户，而是用户账户，只能给kubelete做kubeconfig，kubecetl 4部，setuser，set creditals，seyt context ，use context，创建用户账户就需要这四步，实际上就是去创建一个用户账户的配置文件
traefik是通过pod的方式，交付在k8s里，pod要去取得一定的权限，必须给它创建一个服务账户，第二步就是定义角色去赋予角色相应的权限，就是创建一个clusterRole，就是traefike-ingress-clusterRole。
第三步是绑定角色（账户和角色绑定起来）
这就是RBAC的本质
traefik里的daemonset一定就指定你的service accountname就是你刚才创建的serviceaccount。既然有RBAC，就是让pod具有能够调度k8s里相应资源的能力，相当于创建一个serviceaccount账户，然后给这个账户赋予相应的权限，然后要对这个账户做角色绑定。
在声明traefik控制器 的时候，要显示的指令，serviceaccountname就是traefik-ingress-controller
dashboard比traefik稍微复杂点
声明了一个服务账户，叫做kubernetes-dashboard-admin
下面做了角色绑定，没有做定义角色并赋予权限。做了一个clutserRolbinding的name是kubernetes-dashboard-admin。
roleRef是参考哪个角色，这里参考了默认集群里带有的集群角色cluster-admin，集群管理员
默认带有一堆集群角色，有一个默认的集群角色叫cluster-admin
这个yaml就是定义角色并赋予权限
名字是cluster-admin
权限是对所有api组，所有资源，所有权限，也就是具有k8s集群的最高权限
在dashboard的rbac.yaml里，只做了两件事情，
1.创建了一个新的服务账户service account
2.把创建好的账号和集群中默认的clsuterRole角色，绑定起来
默认的集群角色，名字是system:node
对api组里的哪些资源有哪些权限，对哪个资源组里的什么资源有什么权限
这个用户是k8s-node，给这个用户账户，去绑定一个集群角色，叫system:node（集群角色）。
真正绑定的时候cluter-node和user之间 关系
这个dashboard的pod，它的用户账户就是k8s的最高权限
看一下官方的rbac文件
声明了一种role资源，这个role资源称为kubernetes-dashboard。名字是kubernetes-dashboard-minimal，说明我们要给dashboard最小化权限
给了一堆角色的权限
做了一个roleBinding
官方的service account写在deployment里了
官方也是三步，1.定义service account，2.定义一个普通角色并授予最小化权限，3.把普通角色和最小化权限做了绑定
其实告诉我们dashboard，可以不用集群管理员的形式运行
kubenetes dashboard可以接受两种配置文件，kubeconfig是普通用户的配置文件（把普通用户做出来，然后把普通用户绑定一个集群角色，这个集群角色可以是自定义的具有某些权限的角色或者集群角色，也可能是用默认的集群角色）
dashboard就要看你登录上来 人具有什么权限
第二种方法就是用token方式，一个服务账户service account默认会产生一个资源serect
在default名称空间里可以看secrect
这就是默认service account的secret
这就是默认default service的令牌
如果到kube-system名称空间去，serect其实有很多，有default，有coredns（也声明了serviceaccount，对应一个secret，这个serect里有自己的一个令牌）
在dashboard-admin这个serviceaccount用户里也有令牌