zoukankan      html  css  js  c++  java
  • 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
    
  • 相关阅读:
    使用 VBRichClient 库
    提取文件夹目录的办法
    编程语言转换
    解决linux服务器上matplotlib中文显示乱码问题
    动态规划 53:Maximum Subarray,152:Maximum Subarray,266. Palindrome Permutation 回文全排列
    动态规划:494,576
    ResourceExhaustedError 解决方案
    周赛138场
    leetcode 115
    leetcode 372
  • 原文地址:https://www.cnblogs.com/victorbu/p/14296251.html
Copyright © 2011-2022 走看看