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() + "\n");
};

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

posted @ 2021-01-19 09:18 VictorBu 阅读(773) 评论(0) 编辑收藏举报

刷新页面返回顶部