k8s (三) 副本机制和其他控制器:部署托管的 pod

一、存活探针

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

  • HTTP GET 探针:对容器的 IP 地址执行 HTTP GET 请求。如果探测器收到响应,并且响应状态码不代表错误(响应状态码是2xx或3xx),则认为探测成功。如果服务器返回错误响应状态码或者根本没有响应,那么探测就被认为是失败的,容器将被重新启动。
  • TCP套接字探针:尝试与容器指定端口建立 TCP 连接。如果连接成功建立,则探测成功。否则,容器重新启动。
  • Exec探针:在容器内执行任意命令,并检查命令的退出状态码。如果状态码是 0 则探测成功。所有其他状态码都被认为失败。

1.1. 创建基于 HTTP 的存活探针

将存活探针添加到 pod (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 # 等待 15 秒后才进行第一次探测

luksa/kubia-unhealthy 这个镜像是为了演示存活探针:在第五个请求之后,返回 HTTP 状态码 500:

const http = require('http');
const os = require('os');

console.log("Kubia server starting...");

var requestCount = 0;

var handler = function(request, response) {
  console.log("Received request from " + request.connection.remoteAddress);
  requestCount++;
  if (requestCount > 5) {
    response.writeHead(500);
    response.end("I'm not well. Please restart me!");
    return;
  }
  response.writeHead(200);
  response.end("You've hit " + os.hostname() + "
");
};

var www = http.createServer(handler);
www.listen(8080);

1.2. 使用存活探针

创建 pod:

kubectl create -f kubia-liveness-probe.yaml

查看 pod:

kubectl get pod kubia-liveness

容器启动后,多次执行查看命令,可以看到 RESTARTS > 1

查看 pod 重启原因:

kubectl describe pod kubia-liveness

二、 ReplicaSet

我们在前面创建的基本都是未托管的 pod,可以使用控制器创建托管的 pod,可以保证 pod 不管因任何原因消失,都会自动创建替代 pod。最初 ReplicationController 是用于复制和在异常时重新调度节点的唯一组件, 后来又引入了 ReplicaSet, 而 ReplicationController 最终也将被弃用。

注:通常我们不会直接创建 ReplicaSet 或 ReplicationController,而是在创建更高层级的 Deployment 资源时自动创建他们。

2.1. 创建 RelicaSet

kubia-replicaset.yaml:

apiVersion: apps/v1 # 不是 v1 版本 API 的一部分,属于 apps API 组的 v1 版本
kind: ReplicaSet
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia # matchLabels 选择器
  template:
    metadata:
      labels:
        app: kubia # 标签
    spec:
      containers:
      - name: kubia
        image: luksa/kubia

创建:

kubectl create -f kubia-replicaset.yaml

查看:

kubectl get rs # rs 是 replicaset 的简写

删除:

kubectl delete rs kubia

2.2. ReplicaSet 的标签选择器

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

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

示例:

... ...
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
         - kubia
... ...

三、DaemonSet

Replicationcontroller 和 ReplicaSet 都用于在 Kubernetes 集群上运行部署特定数量的 pod(随机分布在集群上)。DaemonSet 则可以实现在每个节点或者指定的节点上运行一个 pod。适用于比如 pod 执行系统级别的与基础结构相关的操作,例如,希望在每个节点上运行日志收集器和资源监控器;另一个典型的例子是 Kubernetes 自己的 kube-proxy 进程,它需要运行在所有节点上才能使服务工作。

DaemonSet 配置示例:

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 # 选择标签 disk=ssd 的 node
      containers:
      - name: main
        image: luksa/ssd-monitor

四、执行单个任务的 pod

4.1. 创建 job

apiVersion: batch/v1 # Job 属于 batch API 组
kind: Job
metadata:
  name: batch-job
spec:
  template:
    metadata:
      labels:
        app: batch-job
    spec:
      restartPolicy: OnFailure # Job 不能使用 Always 为默认的重启启动策略,应该为 OnFailure 或 Never
      containers:
      - name: main
        image: luksa/batch-job

查看:

kubectl get jobs

kubectl get pods

4.2. 在 Job 中运行多个 pod 实例

顺序运行:

... ...
metadata:
  name: multi-completion-batch-job
spec:
  completions: 5 # 此作业顺序运行 5 个 pod
... ...

并行运行:

... ...
metadata:
  name: multi-completion-batch-job
spec:
  completions: 5 # 这项任务必须确保 5 个 pod 成功完成
  parallelism: 2 # 最多 2 个 pod 可以并行运行
... ...

可以在 job 运行的时候 更改 parallelism 属性,缩放 job:

kubectl scale job multi-completion-batch-job --replicas 3

其他属性:

  • activeDeadlineSeconds:限制 pod的时间,如果 pod 运行时间超过此时间,系统将尝试终止 pod, 并将 Job 标记为失败。
  • spec.backoffLimit:Job 在被标记为失败之前重试的次数,默认值为 6

4.3. CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: batch-job-every-fifteen-minutes
spec:
  schedule: "0,15,30,45 * * * *" # cron 表达式
  jobTemplate:
    spec:
      template:
        metadata:
          labels:
            app: periodic-batch-job
        spec:
          restartPolicy: OnFailure
          containers:
          - name: main
            image: luksa/batch-job
原文地址:https://www.cnblogs.com/victorbu/p/14296251.html