K8s学习十（高级调度）

最新推荐文章于 2024-09-07 21:23:37 发布

biubiu17

最新推荐文章于 2024-09-07 21:23:37 发布

阅读量797

点赞数 21

分类专栏： K8s 文章标签： kubernetes 学习容器

本文链接：https://blog.csdn.net/m0_62033985/article/details/137480771

版权

K8s 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

本文详细介绍了在Kubernetes中如何使用CronJob定期执行任务，包括cron表达式的配置，以及如何利用InitContainer进行初始化操作。还涵盖了污点、容忍、亲和性和反亲和性的调度策略，以及基于RBAC的认证与权限管理机制。

摘要由CSDN通过智能技术生成

高级调度

CronJob计划任务

在 k8s 中周期性运行计划任务，与 linux 中的 crontab 相同
注意点：CronJob 执行的时间是 controller-manager 的时间，所以一定要确保 controller-manager 时间是准确的
cron表达式如下：

在这里插入图片描述

配置如下：


apiVersion: batch/v1
kind: CronJob
metadata:
  name: cron-job
spec:
  concurrencyPolicy: Allow # 并发调度策略：Allow 允许并发调度，Forbid：不允许并发执行，Replace：如果之前的任务还没执行完，就直接执行新的，放弃上一个任务
  failedJobsHistoryLimit: 1 # 保留多少个失败的任务
  successfulJobHistoryLimit: 3 # 保留多少个成功的任务
  suspend: false # 是否挂起任务，若为 true 则该任务不会执行
#  startingDeadlineSeconds: 30 # 间隔多长时间检测失败的任务并重新执行，时间不能小于 10
  schedule: "* * * * *" # 调度策略，因为都是*，所以是每分钟执行一次
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: busybox
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

初始化容器 initcontainer

在真正的容器启动之前，先启动 InitContainer，在初始化容器中完成真实容器所需的初始化操作，完成后再启动真实的容器。参考上面有一张图就是容器初始化还有钩子函数
相对于 postStart 来说，首先 InitController 能够保证一定在 EntryPoint 之前执行，而 postStart 不能，其次 postStart 更适合去执行一些命令操作，而 InitController 实际就是一个容器，可以在其他基础容器环境下执行更复杂的初始化功能。
在 pod 创建的模板中配置 initContainers 参数：

spec:
  initContainers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    command: ["sh", "-c", "sleep 10;echo 'inited' >> /.init"]
    name: init-test

污点和容忍

比如一般不在主节点master上派任务，所以在master节点上有一个污点，容忍是对pod而言，在pod上打上可以容忍xx污点，就可以部署到节点上。

污点

污点：是标注在节点上的，当我们在一个节点上打上污点以后，k8s 会认为尽量不要将 pod 调度到该节点上，除非该 pod 上面表示可以容忍该污点，且一个节点可以打多个污点，此时则需要 pod 容忍所有污点才会被调度该节点。
为节点打上污点kubectl taint node k8s-master key=value:NoSchedule
移除污点kubectl taint node k8s-master key=value:NoSchedule-
查看污点kubectl describe no k8s-master
污点的影响
NoSchedule：不能容忍的 pod 不能被调度到该节点，但是已经存在的节点不会被驱逐
NoExecute：不能容忍的节点会被立即清除，能容忍且没有配置 tolerationSeconds 属性，则可以一直运行，设置了 tolerationSeconds: 3600 属性，则该 pod 还能继续在该节点运行 3600 秒

NoSchedule

如果不能容忍该污点，那么 Pod 就无法调度到该节点上

NoExecute

如果 Pod 不能忍受这类污点，Pod 会马上被驱逐。
如果 Pod 能够忍受这类污点，但是在容忍度定义中没有指定 tolerationSeconds，则 Pod 还会一直在这个节点上运行。
如果 Pod 能够忍受这类污点，而且指定了 tolerationSeconds，则 Pod 还能在这个节点上继续运行这个指定的时间长度。

操作

可以执行kubectl taint node master node-role.kubernetes.io/master:NoSchedule-去掉污点
给node-2打上污点，执行kubectl taint node node-2 memory=low:NoSchedule就打上了相应的污点，然后执行kubectl describe no node-2，就可以找到污点标签，是不能调度，原有的pod也没被驱逐

在这里插入图片描述

容忍

容忍：是标注在 pod 上的，当 pod 被调度时，如果没有配置容忍，则该 pod 不会被调度到有污点的节点上，只有该 pod 上标注了满足某个节点的所有污点，则会被调度到这些节点
pod 的 spec 下面配置容忍

tolerations:
- key: "污点的 key"
  value: "污点的 value"
  effect: "NoSchedule" # 污点产生的影响
  operator: "Equal" # 表是 value 与污点的 value 要相等，也可以设置为 Exists 表示存在 key 即可，此时可以不用配置 value

Equal

比较操作类型为 Equal，则意味着必须与污点值做匹配，key/value都必须相同，才表示能够容忍该污点

Exists

容忍与污点的比较只比较 key，不比较 value，不关心 value 是什么东西，只要 key 存在，就表示可以容忍。

亲和力

跟上面的污点相对，表示希望什么过来

NodeAffinity

节点亲和力：进行 pod 调度时，优先调度到符合条件的亲和力节点上
这里分为 RequiredDuringSchedulingIgnoredDuringExecution和PreferredDuringSchedulingIgnoredDuringExecution两种，分别是硬亲和力和软亲和力
RequiredDuringSchedulingIgnoredDuringExecution：硬亲和力，即支持必须部署在指定的节点上，也支持必须不部署在指定的节点上
PreferredDuringSchedulingIgnoredDuringExecution：软亲和力，尽量部署在满足条件的节点上，或尽量不要部署在被匹配的节点上
匹配类型如下：

In:部署在满足条件的节点上
NotIn:匹配不在条件中的节点，实现节点反亲和性，这里是匹配key的值
Exists:只要存在 label 名字就可以，不关心值是什么
DoesNotExist:匹配指定 label 名不存在的节点，实现节点反亲和性
Gt:value 为数值，且节点上的值小于指定的条件
Lt:value 为数值，且节点上的值大于指定条件

配置：

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity: # 亲和力配置
    nodeAffinity: # 节点亲和力
      requiredDuringSchedulingIgnoredDuringExecution: # 节点必须匹配下方配置
        nodeSelectorTerms: # 选择器
        - matchExpressions: # 匹配表达式
          - key: topology.kubernetes.io/zone # 匹配节点 label 的 key
            operator: In # 匹配方式，只要匹配成功下方的一个 value 即可
            values:
            - antarctica-east1 # 匹配的 value
            - antarctica-west1 # 匹配的 value
      preferredDuringSchedulingIgnoredDuringExecution: # 节点尽量匹配下方配置
      - weight: 1 # 权重[1,100]，按照匹配规则对所有节点累加权重，最终之和会加入优先级评分，优先级越高被调度的可能性越高
        preference:
          matchExpressions: # 匹配表达式
          - key: another-node-label-key # label 的 key
            operator: In # 匹配方式，满足一个即可
            values:
            - another-node-label-value # 匹配的 value
#      - weight: 20
        ......
  containers:
  - name: with-node-affinity
    image: pause:2.0

PodAffinity和PodAntiAffinity

跟上面一样，也是具有RequiredDuringSchedulingIgnoredDuringExecution和PreferredDuringSchedulingIgnoredDuringExecution两种
对于PodAffinity，分别是必须将应用部署到一起和尽量部署到一起
对于PodAntiAffinity是必须不部署到一起和尽量不部署到一起
配置：


apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity: # 亲和力配置
    podAffinity: # pod 亲和力配置
      requiredDuringSchedulingIgnoredDuringExecution: # 当前 pod 必须匹配到对应条件 pod 所在的 node 上
      - labelSelector: # 标签选择器
          matchExpressions: # 匹配表达式
          - key: security # 匹配的 key
            operator: In # 匹配方式
            values: # 匹配其中的一个 value
            - S1
        topologyKey: topology.kubernetes.io/zone #这里是匹配节点上的，节点上必须要有这个标签，也就是有两个匹配条件
    podAntiAffinity: # pod 反亲和力配置
      preferredDuringSchedulingIgnoredDuringExecution: # 尽量不要将当前节点部署到匹配下列参数的 pod 所在的 node 上
      - weight: 100 # 权重
        podAffinityTerm: # pod 亲和力配置条件
          labelSelector: # 标签选择器
            matchExpressions: # 匹配表达式
            - key: security # 匹配的 key
              operator: In # 匹配的方式
              values:
              - S2 # 匹配的 value
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: pause:2.0

身份认证与权限

Kubernetes 中提供了良好的多租户认证管理机制，如 RBAC、ServiceAccount 还有各种策略等。
通过该文件可以看到已经配置了 RBAC 访问控制/usr/lib/systemd/system/kube-apiserver.service

认证

所有 Kubernetes 集群有两类用户：由 Kubernetes 管理的Service Accounts （服务账户）和（Users Accounts）普通账户。

User Accounts

普通账户是假定被外部或独立服务管理的，由管理员分配 keys，用户像使用 Keystone 或 google 账号一样，被存储在包含 usernames 和 passwords 的 list 的文件里。
需要注意：在 Kubernetes 中不能通过 API 调用将普通用户添加到集群中。
- 普通帐户是针对（人）用户的，服务账户针对 Pod 进程。
- 普通帐户是全局性。在集群所有namespaces中，名称具有惟一性。
- 通常，群集的普通帐户可以与企业数据库同步，新的普通帐户创建需要特殊权限。服务账户创建目的是更轻量化，允许集群用户为特定任务创建服务账户。
- 普通帐户和服务账户的审核注意事项不同。
- 对于复杂系统的配置包，可以包括对该系统的各种组件的服务账户的定义。

Service Accounts

Service Account自动化

Service Account Admission Controller

通过 Admission Controller 插件来实现对 pod 修改，它是 apiserver 的一部分。创建或更新 pod 时会同步进行修改 pod。当插件处于激活状态（在大多数发行版中都默认情况）创建或修改 pod 时，会按以下操作执行：
- 如果 pod 没有设置 ServiceAccount，则将 ServiceAccount 设置为 default。
- 确保 pod 引用的 ServiceAccount 存在，否则将会拒绝请求。
- 如果 pod 不包含任何 ImagePullSecrets，则将ServiceAccount 的 ImagePullSecrets 会添加到 pod 中。
- 为包含 API 访问的 Token 的 pod 添加了一个 volume。
- 把 volumeSource 添加到安装在 pod 的每个容器中，挂载在 /var/run/secrets/kubernetes.io/serviceaccount。它包含了 Pod 的 ServiceAccount 令牌和服务证书。

Token Controller

TokenController 作为 controller-manager 的一部分运行。异步行为:
- 观察 serviceAccount 的创建，并创建一个相应的 Secret 来允许 API 访问。
- 观察 serviceAccount 的删除，并删除所有相应的ServiceAccountToken Secret
- 观察 secret 添加，并确保关联的 ServiceAccount 存在，并在需要时向 secret 中添加一个 Token。
- 观察 secret 删除，并在需要时对应 ServiceAccount 的关联

Service Account Controller

Service Account Controller 在 namespaces 里管理ServiceAccount，并确保每个有效的 namespaces 中都存在一个名为 “default” 的 ServiceAccount。

授权（RBAC:基于角色的访问控制）

下面的role只是定义了权限，没有绑定起来，后两个binding是实现绑定的操作

Role

代表一个角色，会包含一组权限，没有拒绝规则，只是附加允许。它是 Namespace 级别的资源，只能作用与 Namespace 之内。
查看已有的角色信息kubectl get role -n ingress-nginx -o yaml
配置文件：


apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
  name: nginx-ingress
  namespace: ingress-nginx
roles:
- apiGroups:
  - ""
  resources:
  - configmaps
  - pods
  - secrets
  - namespaces
  verbs:
  - get
- apiGroups:
  - ""
  resourceNames:
  - ingress-controller-label-nginx
  resources:
  - configmaps
  verbs:
  - get
  - update
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create

ClusterRole

功能与 Role 一样，区别是资源类型为集群类型，而 Role 只在 Namespace
查看某个集群角色的信息kubectl get clusterrole view -oyaml,因为是集群的，所以不用-n指定命名空间

RoleBinding

Role 或 ClusterRole 只是用于制定权限集合，具体作用与什么对象上，需要使用 RoleBinding 来进行绑定。
作用于 Namespace 内，可以将 Role 或 ClusterRole 绑定到 User、Group、Service Account 上。
查看 rolebinding 信息kubectl get rolebinding --all-namespaces
查看指定 rolebinding 的配置信息kubectl get rolebinding <role_binding_name> --all-namespaces -oyaml
配置：


apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  ......
roleRef: #跟角色绑定
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name nginx-ingress-role
subjects: # 主体是sa
- kind: ServiceAccount
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx

ClusterRoleBinding