《Kubernetes in action》副本机制和其他控制器

最新推荐文章于 2024-08-12 21:09:21 发布

cloud_ether

最新推荐文章于 2024-08-12 21:09:21 发布

阅读量187

点赞数

分类专栏： Kubernetes 文章标签： kubernetes

本文链接：https://blog.csdn.net/qq_36652517/article/details/105324283

版权

Kubernetes 专栏收录该内容

11 篇文章 1 订阅

订阅专栏

Kubernetes 副本机制和其他控制器

Kubernetes 副本机制和其他控制器

Kubernetes 副本机制和其他控制器

控制器如何创建新的pod

当ReplicationController收到删除pod的通知(API服务器允许客户端监听资源和资源列表的更改），但这不是它创建替代pod的原因。该通知会触发控、制器检查实际的pod数量并采取适当的措施。
replicationController控制pod
应对节点故障

Kubemetes会自动执行此操作。在ReplicationController检测到它的pod己关闭后不久，它将启动新的pod以替换它们。

将 pod 移入或移出 ReplicationController 的作用域

在将pod 的标签从 app=kubia 更改为 app=foo 之后, ReplicationController 就不管这
pod 由于控制器的副本个数设置为，并且只有两个 pod 与标签选择器匹配，所以ReplicationController 启动 kubia-2qneh pod 使总数回到了三。 kubia-dmdck pod 在完全独的，并且会一直运行直到你手动删除它
delete pod by change labels
after remove pod

水平缩放pod

ReplicationController扩/缩容

kubectl scale rc kubia --replicas=10
kubectl edit rc kubia, spec.replicas: 3
kubectl scale rc kubia --replicas=1

删除—个 ReplicationController

当你通过 kubectl delete 删除 ReplicationController 时， pod也会被删除。但是由于由 ReplicationController 创建的 pod不是 ReplicationController 的组成部分，只是由其进行管理，因此可以只删除 ReplicationController 并保待 pod 运行
kubectl delete re kubia --cascade=false

delete rc

比较ReplicaSet和ReplicationController

ReplicaSet 的行为与ReplicationController 完全相同，但pod 选择器的表达能力更强。虽然 ReplicationController 的标签选择器只允许包含某个标签的匹配 pod, 但ReplicaSet 的选择器还允许匹配缺少某个标签的 pod, 或包含特定标签名的 pod, 不管其值如何。
另外，举个例子，单个Repli氓ionController 无法将 pod与标签 env=production和 env=devel 同时匹配。它只能匹配带有 env=devel 标签的 pod 或带有env=devel 标签的 pod。但是一个ReplicaSet 可以匹配两组 pod 并将它们视为一个大组。

apiVersion: apps/vlbeta2 
kind: ReplicaSet 
metadata: 
  name: kubia 
spec: 
  replicas: 3 
  selector: 
    #matchLabels: 
    #app: kubia
    matchExpressions:
      - key: app
        operator: In
        values:
          - kubia
  template: 
    metadata:
    labels: 
      app: kubia 
    spec: 
      containers: 
      - name: kubia
        image: luksa/kubia

有效运算符

In: Label的值必须与其中一个指定的values匹配
NotIn: Label的值与任何指定的values不匹配
Exists: pod必须包含一个指定名称的标签。使用运算符时, 不应指定values字段
DoesNotExist: pod不得包含有指定名称的标签。value属性不得指定

如果你指定了多个表达式，则所有这些表达式都必须为true才能使选择器与pod匹配。如果同时指定matchLabels和matchExpressions, 则所有标签都必须匹配，并且所有表达式必须计算为true以使该pod与选择器匹配。

使用 DaemonSet在每个节点上运行一个pod

当你希望pod在集群中的每个节点上运行时（并且每个节点都需要正好一个运行的pod实例，如图4.8所示），就会出现某些清况。
这些情况包括pod执行系统级别的与基础结构相关的操作。例如，希望在每个节点上运行日志收集器和资源监控器。另一个典型的例子是Kubemetes 自己的kube-proxy进程, 它需要运行在所有节点上才能使服务工作
daemnSet and Rc

要在所有集群节点上运行一个pod, 需要创建一个DaemonSet对象
DaemonSet 创建的pod, 已经有一个指定的目标节点并跳过Kubernetes调度程序。 它们不是随机分布在集群上的。
Daemon Set 确保创建足够的pod,并在自己的节点上部署每个pod
DaemonSet 并没有期望的副本数的概念。 它不需要， 因为它的工作是确保一个pod匹配它的选择器并在每个节点上运行 。
如果节点下线， DaemonSet不会在其他地方重新创建pod。 但是, 当将 一个新节点添加到集群中时，DaemonSet会立刻部署一个新的pod实例 。 如果有人无意中删除了一个pod，那么它也会重新创建一个新的pod。与ReplicaSet一样，DaemonSet从置的pod模板创建Pod

集群管理员已经向所有此类节点添加了 disk ssd 的标签, 因此你将使用节点选择器创建 DaemonSet 该选择器只选择具有该标签的节点，
daemonSet manage pod

apiVersion: apps/vlbeta2 
kind: DaernonSet 
metadata: 
  name: ssd-monitor
spec:
  selector:
    matchLabels:
      app: ssd-monitor
  template:
    metadata:
      labels:
        app: ssd-monitor
    spec:
      nodeSelector:
        dish: ssd
      containers:
      - name: main
        image: luksa/ssd-monitor

创建 kubectl apply -f ssd-monitor-daemonset.yaml
查看 kubectl get ds
获取 kubectl get pod
给节点添加标签 kubectl label node kmaster disk=ssd
从节点修改标签 kubectl label node kmaster disk=hdd --overwrite 即可删除deamonset管理下的pod

Job资源

它允许你运行一种 pod, 该 pod 在内部进程成功结束时，不重启容器。一旦任务完成， pod 就被认为处于完成状态。在发生节点故障时，该节点上由 Job管理的 pod将按照 ReplicaSet 的 pod 的方式，重新安排到其他节点。如果进程本身异常退出（进程返回错误退出代码时），可以将 Job 配置为重新启动容器。

如果一个Job 所创建的 pod, 在最初被调度节点上异常退出后，被重新安排到一个新节点上的情况。该图还显示了托管的 pod (未重新安排）和由ReplicaSet 管理的 pod (被重新安排）。
job manager
例如， Job 对于临时任务很有用，关键是任务要以正确的方式结束。可以在未托管的 pod 中运行任务并等待它完成，但是如果发生节点异常或 pod 在执行任务时被从节点中逐出，则需要手动重新创建该任务。

如果有数据存储在某个地方，需要转换并将其导出到某个地方。你将通过运行构建在 busybox 镜像上的容器镜像来模拟此操作，该容器将调用 sleep 命令两分钟。

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-job
spec:
  completions: 5 # 完成5个job后退出
  parallelism: 2 # 并行数2个
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

Job的缩放

kubectl scale job multi-completion-batch-job --replicas 3
通过在pod配置中设置 activeDeadlineSeconds 属性，可以限制 pod的时间。如果 pod 运行时间超过此时间，系统将尝试终止 pod, 并将 Job 标记为失败。
通过指定 Job manifest 中的 spec.backoffLimit字段，可以配置 Job
在被标记为失败之前可以重试的次数。如果你没有明确指定它，则默认为6。

job定期运行cronJob

job 资源在创建时会立即运行pod。但是许多批处理任务需要在特定的时间运行，或者在指定的时间间隔内重复运行。在 Linux 和类 UNIX 操作系统中，这些任务通常被称为 cron 任务。

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cron-batch-job
spec:
  schedule: "0,15,30,30,45 * * * *" #分,时, 日, 月, 周
  #completions: 5
  #parallelism: 2
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: periodic-batch-job
        spec:
          restartPolicy: OnFailure
          containers:
          - name: main
            image: luksa/batch-job

你可能对这项工作有很高的要求，任务开始不能落后于预定的时间过多
pod最迟必须再预定时间后15秒开始运行: startingDeadlineSeconds: 15