1.2 节点保护-指定node节点不可用
将ek8s-node-1节点设置为不可用,而后从新调度该节点上的所有Pod
执行etcdctl命令的证书寄存在: 并且不容许不是internal命令空间的下的Pod拜访 不容许拜访没有监听9000端口的Pod。
grep -i: 疏忽字符大小写的差异。
形式一Patch命令:
一个名为wk8s-node-0的节点状态为NotReady,让其余复原至失常状态,并确认所有的更改开机主动实现
主节点故障排查:–之前的考试题,当初考试应该没有这个题了。
https://kubernetes.io/zh/docs…
}
什么是RBAC(基于角色的访问控制)?
让一个用户(Users)扮演一个角色(Role),角色拥有权限,从而让用户拥有这样的权限,随后在授权机制当中,只需要将权限授予某个角色,此时用户将获取对应角色的权限,从而实现角色的访问控制。如图:
定义角色:在定义角色时会指定此角色对于资源的访问控制的规则;
绑定角色:将主体与角色进行绑定,对用户进行访问授权
在k8s的授权机制当中,采用RBAC的方式进行授权,其工作逻辑是,
- 把对对象的操作权限定义到一个角色当中,再将用户绑定到该角色,从而使用户得到对应角色的权限
-
如果通过rolebinding绑定role,只能对rolebinding所在的名称空间的资源有权限,上图user1这个用户绑定到role1上,只对role1这个名称空间的资源有权限,对其他名称空间资源没有权限,属于名称空间级别的;
-
另外,k8s为此还有一种集群级别的授权机制,就是定义一个集群角色(ClusterRole),对集群内的所有资源都有可操作的权限,从而将User2通过ClusterRoleBinding到ClusterRole,从而使User2拥有集群的操作权限
上面说了两个角色绑定:
假如有6个名称空间,每个名称空间的用户都需要对自己的名称空间有管理员权限,那么需要定义6个role和rolebinding,然后依次绑定
如果名称空间更多,我们需要定义更多的role,这个是很麻烦的,所以我们引入clusterrole,定义一个clusterrole,对clusterrole授予所有权限
然后用户通过rolebinding绑定到clusterrole,就会拥有自己名称空间的管理员权限
注:RoleBinding仅仅对当前名称空间有对应的权限
# 用私钥生成证书,CN 表示用户名,O 表示用户组 # 然后用 CA 证书来给刚才生成的证书来签名 # 设置私钥以及已签名证书
在dev
命名空间内,授予mysa
服务帐户view
集群角色
案例1) 限制不同用户访问不同名称空间的资源生成一个证书
(2)生成一个证书请求 #这个是集群用户,有任何权限 通过上面可以发现testlouis可以管理dev名称空间
}