k8s调度，访问控制

Posted 2021-09-01 S4061222

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了k8s调度，访问控制相关的知识，希望对你有一定的参考价值。

一 . kubernetes调度

1. 简介

调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。

kube-scheduler 是 Kubernetes 集群的默认调度器，并且是集群控制面的一部分。如果你真的希望或者有这方面的需求，kube-scheduler
在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。

在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。

默认策略可以参考：https://kubernetes.io/docs/reference/scheduling/policies/

调度框架：https://kubernetes.io/zh/docs/concepts/scheduling-eviction/scheduling-framework/

实验环境：

2. nodeName节点选择约束

nodeName 是节点选择约束的最简单方法，但一般不推荐。如果 nodeName 在 PodSpec 中指定了，则它优先于其他的节点选择方法。

使用 nodeName 来选择节点的一些限制：

如果指定的节点不存在。
如果指定的节点没有资源来容纳 pod，则pod 调度失败。
云环境中的节点名称并非总是可预测或稳定的。

3. nodeSelector 节点选择约束

添加 nodeSelector 字段到 pod 配置中

给选择的节点server3添加标签

调度后不会不running，不影响（表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod）

亲和与反亲和（NodeSeletor）

nodeSelector 提供了一种非常简单的方法来将 pod 约束到具有特定标签的节点上。亲和/反亲和功能极大地扩展了你可以表达约束的类型。
你可以发现规则是“软”/“偏好”，而不是硬性要求，因此，如果调度器无法满足该要求，仍然调度该 pod
你可以使用节点上的 pod 的标签来约束，而不是使用节点本身的标签，来允许哪些 pod 可以或者不可以被放置在一起。

3.1 节点亲和

requiredDuringSchedulingIgnoredDuringExecution 必须满足

preferredDuringSchedulingIgnoredDuringExecution倾向满足
IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致亲和性策略不能满足，则继续运行当前的Pod。

nodeaffinity还支持多种规则匹配条件的配置如下：

In label 的值在列表内
NotIn label 的值不在列表内
Gt label 的值大于设置的值，不支持Pod亲和性
Lt label 的值小于设置的值，不支持pod亲和性
Exists 设置的label 存在
DoesNotExist 设置的 label不存在

apiVersion: v1
kind: Pod
metadata:
  name: node-affinity
spec:
  containers:
  - name: nginx
    image: nginx
  affinity:
    nodeAffinity:				%node亲和性
      requiredDuringSchedulingIgnoredDuringExecution:	%必须满足
           nodeSelectorTerms:
           - matchExpressions:
             - key: kubernetes.io/hostname
               operator: In		%以下条件在列表内，才可调度
               values:			%调度的节点必须是server3或server4
               - server3
               - server4
      preferredDuringSchedulingIgnoredDuringExecution:	%倾向满足，优先匹配满足该模块条件的节点
      - weight: 1				%权重为1
        preference:
          matchExpressions:
          - key: disktype		%匹配条件是disktype这个键，值为ssd
            operator: In
            values:
            - ssd

应用，创建pod，由于server3和server4都没有ssd这个标签，倾向满足失效，所以随机调度到了server4

删除上个pod，给server3添加disktype=ssd标签，再次创建pod，查看发现调度到了server3

查看pod的详细信息，该pod由于node的亲和性，调度到了server3

4.2.1 pod亲和

pod 亲和性和反亲和性

podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题（拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的cluster、zone等。）
podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。
Pod 间亲和与反亲和在与更高级别的集合（例如 ReplicaSets，StatefulSets，Deployments 等）一起使用时，它们可能更加有用。可以轻松配置一组应位于相同定义拓扑（例如，节点）中的工作负载。
Pod 间亲和与反亲和需要大量的处理，这可能会显著减慢大规模集群中的调度。

下载mysql5.7的tar包，上传至私有仓库

删除之前实验的pod，重新编辑pod的执行清单

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:			%nginx的pod的标签是app=nginx
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
  labels:			%mysql的pod的标签是app=mysql
    app: mysql
spec:
  containers:
  - name: mysql
    image: mysql:5.7
    env:			%环境变量
     - name: "MYSQL_ROOT_PASSWORD"
       value: "westos"
  affinity:
    podAffinity:		%pod亲和性
      requiredDuringSchedulingIgnoredDuringExecution:	%必须满足
      - labelSelector:
          matchExpressions:
          - key: app			%标签app=nginx
            operator: In
            values:
            - nginx
        topologyKey: kubernetes.io/hostname

执行清单，nginx和mysql的pod在同一个节点server4上！！！
因为mysql门匹配有nginx这个标签的pod，nginx去哪个节点，mysql就去哪个节点

4.2.2 pod反亲和

修改pod2.yaml 文件，由原来的pod亲和变为pod反亲和

应用pod2.yaml 文件，创建pod，mysql和nginx专门不在同一个节点上！！！

5 taint 污点

nodeAffinity节点亲和性，是Pod上定义的一种属性，使Pod能够按我们的要求调度到某个Node上，而Taints则恰恰相反，它可以让Node拒绝运行Pod，甚至驱逐Pod。

Taints(污点)是Node的一个属性，设置了Taints后，所以Kubernetes是不会将Pod调度到这个Node上的，于是Kubernetes就给Pod设置了个属性Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去。

Taint污点的创建，查询和删除命令

kubectl taint nodes node1 key=value:NoSchedule	#创建
kubectl describe nodes  server1 |grep Taints		#查询
kubectl taint nodes node1 key:NoSchedule-		#删除

其中[effect] 可取值： [ NoSchedule | PreferNoSchedule | NoExecute ]
NoSchedule：POD 不会被调度到标记为 taints 节点。
PreferNoSchedule：NoSchedule 的软策略版本。
NoExecute：该选项意味着一旦 Taint 生效，如该节点内正在运行的 POD 没有对应 Tolerate 设置，会直接被逐出。

5.1 Nodename可以无视任何污点

nodename调度方式无视污点，nodename的优先级最高，nodename说去哪里就去哪里

server2污点

[root@server2 schedu]# kubectl  describe  nodes server2 | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule

设置指定nodename： server2上部署，server2为集群master

[root@server2 schedu]# cat pod3.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: server2 %nodename调度方式无视污点

查看pod，已经部署在server2，说明nodename可以掩盖污点

[root@server2 schedu]# kubectl  get pod -o wide
NAME    READY   STATUS    RESTARTS   AGE   IP               NODE      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          94s   10.244.116.142   server2   <none>

5.2 标签方式选择node

server2是集群的master，默认不会work只会调度，原因就在与server2有污点，NoSchedule

[root@server2 schedu]# kubectl  describe  nodes server2 | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule

指定 server2 标签 roles=master
编辑pod.yaml清单，标签 roles=master节点创建pod

应用，查看pod，处于pending状态，说明污点优先级高于标签选择！！！

5.3 tolerations容忍标签

tolerations中定义的key、value、effect，要与node上设置的taint保持一直：

如果 operator 是 Exists ，value可以省略。
如果 operator 是 Equal ，则key与value之间的关系必须相等。
如果不指定operator属性，则默认值为Equal。

还有两个特殊值：

当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。
当不指定effect ，则匹配所有的effect。

5.3.1 NoSchedule

在PodSpec中为容器设定容忍标签：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    roles: master
  tolerations:			%容忍NoSchedule这个污点
  - operator: "Exists"
    effect: "NoSchedule"

  tolerations:			%不加 effect，容忍所有污点
  - operator: "Exists"

重新应用发现pod已running！！！

server2 有污点，不设置容忍

给Server3节点打上taint污点，NoSchedule。
此时server2和server3都有污点，且没有设置容忍，所以只能调度到server4！！

5.3.2 noexcute 驱离

server3添加了ssd这个标签。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd		%匹配标签disktype=ssd
  tolerations:
  - operator: "Exists"
    effect: "NoSchedule"	%容忍NoSchedule的污点

应用pod.yaml 文件，pod被调度到server3

给server3添加污点key=value:NoExecute，可以看到添加完成后，之前在server3上的pod立马被驱离了

server3的所有的ns中的docker，不设置容忍都被驱逐到server4上

6 cordon 停止调度

server3：停止调度（原有pod还在）
影响最小，只会将node调为SchedulingDisabled，新创建pod，不会被调度到该节点，节点原有pod不受影响，仍正常对外提供服务。

7 drain 驱逐节点

首先驱逐node上的pod，在其他节点重新创建，然后将节点调为SchedulingDisabled

停止调度，原有pod会被驱逐，设定参数 --ignore-demonset忽略demonset控制器创建的pod，其他的pod会被驱逐

8 delete 删除节点

最暴力的一个，首先驱逐node上的pod，在其他节点重新创建，然后，从master节点删除该node，master失去对其控制，如要恢复调度，需进入node节点，重启kubelet服务

systemctl restart kubelet

基于node的自注册功能,恢复使用

9 添加节点

二. kubernetes访问控制

1.访问控制原理

kubernetes API 访问控制

Authentication（认证）

(1)认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。

(2)Kubernetes集群有两类用户：由Kubernetes管理的Service Accounts （服务账户）和（Users
Accounts）普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。

Authorization（授权）

必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式现共有6种，AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node。默认集群强制开启RBAC。

Admission Control（准入控制）

用于拦截请求的一种方式，运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验。

访问k8s的API Server的客户端主要分为两类：
kubectl ：用户家目录中的 .kube/config 里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。
pod：Pod中的进程需要访问API Server，如果是人去访问或编写的脚本去访问，这类访问使用的账号为：UserAccount；而Pod自身去连接API Server时，使用的账号是：ServiceAccount，生产中后者使用居多。

pod方式下访问k8s的API Server

以nginx为例，配置中useraccount：nginx；Pod自身去连接API Server时，使用的账号是：ServiceAccount（ns）

kubectl向apiserver发起的命令,采用的是http方式,其实就是对URL发起增删改查的操作。
$ kubectl proxy --port=8888 &
$ curl http://localhost:8888/api/v1/namespaces/default
$ curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments

以上两种api的区别是：
api它是一个特殊链接,只有在核心v1群组中的对象才能使用。
apis 它是一般API访问的入口固定格式名。

UserAccount与serviceaccount：

用户账户是针对人而言的。服务账户是针对运行在 pod 中的进程而言的。用户账户是全局性的。其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离，服务账户是 namespace 隔离的。
通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。
服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。

2 创建serviceaccount

认证

创建serviceaccount

此时k8s为用户自动生成认证信息，但没有授权

之前都是在Pod指定imagePullSecrets，不安全！！！

添加secrets到serviceaccount中：
把serviceaccount和pod绑定起来,拉取私密仓库创建mypod
将认证信息添加到serviceAccount中，要比直接在Pod指定imagePullSecrets要安全很多。

kubectl get pod mypod -o yaml

3 创建UserAccount

密钥

证书请求，申请证书

查看

test加入集群配置

查看配置

绑定
切test后查看
admin和test权限不同

用户通过认证，但还没有权限操作集群资源，需要继续添加授权。

4 RBAC

（Role Based Access Control）：基于角色访问控制授权

授权

允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。
RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可。
RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

RBAC的三个基本概念：

Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount
Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
RoleBinding：定义了“被作用者”和“角色”的绑定关系。

Role 和 ClusterRole

Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限。
ClusterRole 跟 Role 类似，但是可以在集群中全局使用。

4.1 role

RoleBinding和ClusterRoleBinding

RoleBinding是将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users，groups ，service accounts)，并引用该Role。
RoleBinding是对某个namespace 内授权，ClusterRoleBinding适用在集群范围内使用。

4.2 RoleBinding

4.3 ClusterRole

pod和deployment

4.4 rolebinding绑定clusterRole

4.4.1 pod和deployment

cat clusterrole.yaml

4.4.2 pod，deployment，svc和endpoints

4.5 创建clusterrolebinding

5.服务账户的自动化

服务账户准入控制器（Service account admission controller）

如果该 pod 没有 ServiceAccount 设置，将其 ServiceAccount 设为 default。
保证 pod 所关联的 ServiceAccount 存在，否则拒绝该 pod。
如果 pod 不包含 ImagePullSecrets 设置，那么将 ServiceAccount 中的 ImagePullSecrets 信息添加到 pod 中。
将一个包含用于 API 访问的 token 的 volume 添加到 pod 中。
将挂载于 /var/run/secrets/kubernetes.io/serviceaccount 的 volumeSource 添加到 pod 下的每个容器中。

Token 控制器（Token controller）

检测服务账户的创建，并且创建相应的 Secret 以支持 API 访问。
检测服务账户的删除，并且删除所有相应的服务账户 Token Secret。
检测 Secret 的增加，保证相应的服务账户存在，如有需要，为 Secret 增加 token。
检测 Secret 的删除，如有需要，从相应的服务账户中移除引用。

服务账户控制器（Service account controller）

服务账户管理器管理各命名空间下的服务账户，并且保证每个活跃的命名空间下存在一个名为 “default” 的服务账户

5.1 ns下所有的sa和所有的sa

Kubernetes 还拥有“用户组”（Group）的概念：
- ServiceAccount对应内置“用户”的名字是：
  system:serviceaccount:<ServiceAccount名字 >
- 而用户组所对应的内置名字是：
  system:serviceaccounts:<Namespace名字 >

示例1：表示mynamespace中的所有ServiceAccount

subjects:
- kind: Group
  name: system:serviceaccounts:mynamespace
  apiGroup: rbac.authorization.k8s.io

示例2：表示整个系统中的所有ServiceAccount

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

5.2 四个预先定义的 ClusterRole

Kubernetes 还提供了四个预先定义好的 ClusterRole 来供用户直接使用：

cluster-amdin
admin
edit
view

view

edit

admin

cluster-amdin

6 准入控制 PSP

PodSecurityPolicy（简称PSP）： Kubernetes中Pod部署时重要的安全校验手段，能够有效地约束应用运行时行为安全。

使用PSP对象定义一组Pod在运行时必须遵循的条件及相关字段的默认值，只有Pod满足这些条件才会被K8s接受。（在部署的时候去校验的，在运行的时候是不管的，当你创建podd的时候会去校验）

查看psp

修改文件，激活准入控制，可自选准入控制器

添加PodSecurityPolicy的安全策略

创建不了pod，error

cat example.yaml

查看psp，会新建example的psp

cat roles-1.yaml

执行清单

权限太大

cat psp.yaml

执行清单，有新建restrictive的psp

cat roles.yaml

执行清单

使用deployment控制器创建pod

应用清单，查看pod

以上是关于k8s调度，访问控制的主要内容，如果未能解决你的问题，请参考以下文章

[k8s]k8s的控制层kubelet+docker配合调度机制(k8架构)