应用编排与管理

[root@k8s-master01 yaml]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
replicaset-demo-frz7j   1/1     Running   1          5m46s   10.244.2.11   k8s-node02   <none>           <none>
replicaset-demo-gws5n   1/1     Running   0          5m46s   10.244.1.9    k8s-node01   <none>           <none>
replicaset-demo-mm6dw   1/1     Running   0          5m46s   10.244.3.2    k8s-node03   <none>           <none>
replicaset-demo-wtmkr   1/1     Running   5          5m46s   10.244.4.2    k8s-node04   <none>           <none>
[root@k8s-master01 yaml]# ct replicaset-demo.yaml 
-bash: ct: command not found
[root@k8s-master01 yaml]# cat replicaset-demo.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-demo
spec:
  minReadySeconds: 3
  replicas: 4
  selector:
    matchLabels:
      app: demoapp
      release: stable
  template:
    metadata:
      labels:
        app: demoapp
        release: stable
    spec:
      containers:
      - name: demoapp
        image: ikubernetes/demoapp:v1.0
        ports:
        - name: http
          containerPort: 80
        livenessProbe:
          httpGet:
            path: '/livez'
            port: 80
          initialDelaySeconds: 5
        readinessProbe:
          httpGet:
            path: '/readyz'
            port: 80
          initialDelaySeconds: 15

 在 Kubernetes 中，更为推荐的做法是使用 Controller 来管理 Pod，而不是直接创建 Pod。

用户应该始终使用控制器来创建 Pod，而不是直接创建 Pod，控制器可以提供如下特性：

• 水平扩展（运行 Pod 的多个副本）
• rollout（版本更新）
• self-healing（故障恢复）

例如：当一个节点出现故障，控制器可以自动地在另一个节点调度一个配置完全一样的 Pod，以替换故障节点上的 Pod。

控制器通过其中配置的 Pod Template 信息来创建 Pod

 

initialDelaySeconds: 10 #延迟检测时间

滚动升级Deployment  

• minReadySeconds:
• Kubernetes在等待设置的时间后才进行升级
• 如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
• 如果没有设置该值，在某些极端情况下可能会造成服务服务正常运行

Pod 两种探针简介
LivenessProbe（存活探针）： 存活探针主要作用是，用指定的方式进入容器检测容器中的应用是否正常运行，如果检测失败，则认为容器不健康，那么 Kubelet 将根据 Pod 中设置的 restartPolicy （重启策略）来判断，Pod 是否要进行重启操作，如果容器配置中没有配置 livenessProbe 存活探针，Kubelet 将认为存活探针探测一直为成功状态。

ReadinessProbe（就绪探针）： 用于判断容器中应用是否启动完成，当探测成功后才使 Pod 对外提供网络访问，设置容器 Ready 状态为 true，如果探测失败，则设置容器的 Ready 状态为 false。对于被 Service 管理的 Pod，Service 与 Pod、EndPoint 的关联关系也将基于 Pod 是否为 Ready 状态进行设置，如果 Pod 运行过程中 Ready 状态变为 false，则系统自动从 Service 关联的 EndPoint 列表中移除，如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。通过这种机制就能防止将流量转发到不可用的 Pod 上。

目前 LivenessProbe 和 ReadinessProbe 两种探针都支持下面三种探测方法：

ExecAction： 在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。
HTTPGetAction： 通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康。
TCPSocketAction： 通过容器的 IP 地址和端口号执行 TCP 检 查，如果能够建立 TCP 连接，则表明容器健康。
探针探测结果有以下值：

Success：表示通过检测。
Failure：表示未通过检测。
Unknown：表示检测没有正常进行。
4、Pod 探针的相关属性
探针(Probe)有许多可选字段，可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe)：

initialDelaySeconds： Pod 启动后首次进行检查的等待时间，单位“秒”。
periodSeconds： 检查的间隔时间，默认为 10s，单位“秒”。
timeoutSeconds： 探针执行检测请求后，等待响应的超时时间，默认为 1s，单位“秒”。
successThreshold： 探针检测失败后认为成功的最小连接成功次数，默认为 1s，在 Liveness 探针中必须为 1s，最小值为 1s。
failureThreshold： 探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3s，最小值为 1s。
5、两种探针的区别
ReadinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同：

readinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。
livenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。