副本机制和其他控制器

kubectl delete rc kubia --cascade=false
kubectl lables pod --overwite
kubectl logs mypod --previous 想看到的是重启前容器的日志

存活探针livenessProbe

Kubemetes 可以通过存活探针 (liveness probe) 检查容器是否还在运行。可以为 pod 中的每个容器单独指定存活探针。 如果探测失败，Kubemetes将定期执行探针并重新启动容器。

有以下三种探测容器的机制：

• HTTP GET探针对容器的 IP 地址（你指定的端口和路径）执行 HTTP GET 请求。
• TCP套接字探针尝试与容器指定端口建立TCP连接。如果连接成功建立，则探测成功。否则，容器重新启动。
• Exec探针在容器内执行任意命令，并检查命令的退出状态码。如果状态码是0, 则探测成功。所有其他状态码都被认为失败。

kubia-liveness-probe.yaml
apiVersion: v1
kind: Pod
metadata:
  name: kubia-liveness
spec:
  containers:
  - image: luksa/kubia-unhealthy
    name: kubia
    livenessProbe:
      httpGet:
        path: /
        port: 8080
      initialDelaySeconds: 15      

创建pod后describe
Liveness:   http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3
除了明确指定的存活探针选项，还可以看到其他属性，例如delay(延迟）、timeout(超时）、period(周期）等。
delay=0s部分显示在容器启动后立即开始探测。 timeout仅设置为1秒，因此容器必须在1秒内进行响应， 不然这次探测记作失败。 每10秒探测一次容器(period=10s), 并在探测连续三次失败(failure=3)后重启容器。
initialDelaySeconds: 15 Kubernetes会在第—次探测前等待15秒

保持探针轻量

存活探针不应消耗太多的计算资源， 并且运行不应该花太长时间 。 默认情况下，探测器执行的频率相对较高， 必须在一秒之内执行完毕。 一个过重探针会大大减慢你的容器运行。

无须在探针中实现重试循环

探针的失败阙值是可配置的， 并且通常在容器被终止之前探针必须失败多次。 但即使你将失败阙值设置为1 , Kubemetes为了确认一次探测的失败，会尝试若干次 。 因此 在探针中自己实现重试循环是浪费精力。
由承载pod的节点上的Kubelet 执行

根据yml文件创建的RC，通过edit修改标签（pod，select）后，delete -f yml 可删除关联的RC。

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: nginx
        ports:
        - containerPort: 8080

比较ReplicaSet和ReplicationController

ReplicaSet 的行为与ReplicationController 完全相同， 但pod 选择器的表达能力更强。 虽然 ReplicationController 的标签选择器只允许包含某个标签的匹配 pod，但ReplicaSet 的选择器还允许匹配缺少某个标签的 pod，或包含特定标签名的 pod，不管其值如何。
另外，举个例子，单个ReplicationController无法将 pod与标签 env=production和env=devel同时匹配。它只能匹配带有env=devel标签或带有env=devel标签的pod。但是一个ReplicaSet可以匹配两组pod并将它们视为一个大组。
同样，无论ReplicationController 的值如何，ReplicationController都无法仅基于标签名的存在来匹配pod，而ReplicaSet 则可以。 例如，ReplicaSet 可匹配所有包含名为 env 的标签的 pod, 无论ReplicaSet 的实际值是什么（可以理解为 env= *)。

使用ReplicaSet的更富表达力的标签选择器

ReplicaSet 相对于 ReplicationController的主要改进是它更具表达力的标签选择器。 之前我们故意在第 一个 ReplicaSet 示例中， 用较简单的 matchLabels 选择器来确认 ReplicaSet 与 ReplicationController 没有区别。 现在，你将用更强大的matchExpressions 属性来重写选择器， 如下面的代码清单所示。
注意仅显示了选择器。你会在本书的代码档案中找到整个ReplicaSet定义。
可以给选择器添加额外的表达式。如示例，每个表达式都必须 包含一个key、
一个operator (运算符），并且可能还有一个values的列表（取决于 运算符）。
你会看到四个有效的运算符：
• In : Label的值 必须与其中 一个指定的values 匹配。
• Notln : Label的值与任何指定的values 不匹配。
• Exists : pod 必须包含一个指定名称的标签（值不重要）。使用此运算符时，
不应指定 values字段。
• DoesNotExist : pod不得包含有指定名称的标签。values属性不得指定 。

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

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

ReplicationController 和 ReplicaSet 都用于在 Kubernetes 集群上运行部署特定数量的 pod。但是，当你希望 pod 在集群中的每个节点上运行时（并且 每个节点都需要正好一个运行的 pod 实例)，就会出现某些情况，包括 pod 执行系统级别的与基础结构相关的操作。
例如， 希望在每个节点上运行日志收集器和资源监控器。 另 一个典型的例子是 Kubernetes 自己的 kube-proxy 进程， 它需要运行在所有节点上才能使服务工作。

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

DaemonSet 确保创建足够的 pod , 并在自己的节点上部署每个pod。 尽管ReplicaSet (或ReplicationController)确保集群中存在期望数量的pod副本， 但 DaemonSet 并没有期望的副本数的概念。 它不需要， 因为它的工作是确保一个 pod 匹配它的选择器并在每个节点上运行。如果节点下线， DaemonSet 不会在其他地方重新创建pod。 但是， 当将 一个新节点添加到集群中时， DaemonSet 会立刻部署一个新的 pod 实例 。 如果有人无意中删除了 pod 那么它也会重新一个新的 pod 。与 ReplicaSet 样，DaemonSet 从配 pod 模板创建 pod。

DaemonSet 只在特定的节点上运行 pod

DaemonSet pod 部署到集群中的所有节点上，除非指定这些 pod 在部分节点上运行。 这是通过 pod 模板中的 nodeSelector 属性指定的，这是 DaemonSet 定义的一部分，似于 ReplicaSet ReplicationController 中的 pod 模板。
注意：节点可以被设置为不可调度 ，防止 pod 被部署到节点上。 DaemonSet 甚至会将 pod 部署到这些节点上，因为无法调度的属性只会被调度器使用，而 DaemonSet 管理 pod 完全绕过调度器。这是预期的，因为DaemonSet 的目的是运行系统服务，即使是在不可调度的节点上，系统服务通常也需要运行。

用一个例子来解释 DaemonSet

假设有一个名为 ssd-monitor 的守护进程，它需要在包含固态驱动器(SSD的所有节点上运行。 创建 一个DaemonSet ，它在标记为具有 SSD 的所节点上运行这个守护进程。集群管理员已经向所有此类节点添加了 disk=ssd 的标签，因此你将使用节点选择器创建 DaemonSet， 该选择器只选择具有该标签的节点。

cat ssd-monitor-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: ssd-monitor
spec:
  selector:
    matchLabels:
      app: ssd-monitor
  template:
    metadata:
      labels:
        app: ssd-monitor
    spec:
      nodeSelector:
        disk: ssd
      containers:
      - name: main
        image: luksa/ssd-monitor

在Job中运行多个pod实例

作业可以配置为创建多个pod实例， 并以并行或串行方式运行它们 。 这是通过在Job配置中设置 completions和parallelism属性来完成的。

顺序运行Job pod

如果你需要 一个Job运行多次，则可以将completions设为你希望作业的pod运行多少次。

apiVersion: batch/v1
kind: Job
metadata:
  name: multi-completion-batch-job
spec:
  completions: 5
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

Job将一个接一个地运行五个pod。它最初创建一个pod, 当pod的容器运行完成时，它创建第二个pod，以此类推，直到五个pod成功完成。如果其中 一个pod
发生故障，工作会创建一个新的pod，所以Job总共可以创建五个以上的pod。

并行运行Job pod

不必一个接一个地运行单个Jobpod, 也可以让该Job并行运行多个pod。可以通过parallelism Job配置属性，指定允许多少个pod并行执行，如下面的代码清单所示。

apiVersion: batch/v1
kind: Job
metadata:
  name: multi-completion-batch-job
spec:
  completions: 5
  parallelism: 2
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure
      containers:
      - name: main
        image: luksa/batch-job

只要其中 一个pod完成任务，工作将运行下 一个pod, 直到五个pod都成功完成任务

Job的缩放

你甚至可以在 Job 运行时更改 Job 的 paralllism 属性。 这与缩放 ReplicaSet或 ReplicationController 类似， 可以使用 kubectl scale 命令完成：
kubectl scale job multi-completion-batch-job --replicsa 3
由于你将 parallelism 从 2 增加到 3, 另一个 pod 立即启动， 因此现在有三个 pod 在运行

限制Job pod完成任务的时间

关于 Job 我们需要讨论最后 一件事。 Job 要等待一个 pod 多久来完成任务？如果 pod 卡住并且根本无法完成（或者无法足够快完成），该怎么办？
通过在pod配置中设置 activeDeadlineSeconds 属性，可以限制 pod的时间。如果 pod 运行时间超过此时间， 系统将尝试终止 pod，并将 Job 标记为失败。
注意 通过指定 Job manifest 中的 spec.backoffLimt字段，可以配置 Job在被标记为失败之前可以重试的次数。 如果你没有明确指定它，则默认为6。

CronJob

startingDeadlineSeconds 指定截止时间

apiVersion: batch/v1beta1 
kind: CronJob
metadata:
  name: batch-job-every-fifteen-minutes
spec:
  schedule: "0,15,30,45 * * * *"
  startingDeadlineSeconds: 15
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: periodic-batch-job
        spec:
          restartPolicy: OnFailure
          containers:
          - name: main
            image: luksa/batch-job

__EOF__

本文作者：何时&明月
本文链接：https://www.cnblogs.com/kiyalone/p/15957135.html
关于博主：当你发现自己的才华支撑不起野心时，就请安静下来学习吧！
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！