1.保持pod健康

1.存活探针

kubernetes 可以通过存活探针(liveness probe)检查容器是否还在运行。可以为pod中的容器单独制定存活探针，如果探测失败，kubernetes 将定期执行探针并重新启动容器,同时kubernetes还支持就绪探针，它们使用两种不同的场景

kubernetes有一下三种探测器的机制

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

2.创建一个基于HTTP的存活探针

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

3.创建有效的探针

1.为了更好的进行存活检查，需要将探针配置为请求特定的URL路径(例如/health),并让应用从内部运行的所有重要组件进行状态检查，以确保他们都没有终止或停止响应
注意: 请确保/health HTTP瑞点不需要认证, 否则探剧会一直失败, 导致你的容器无限重启
2.保持探针轻量
存活探针不应消耗太多的计算资源, 并且运行不应该花太长时间，默认情况下,探测器执行的频率相对较高, 必须在 一 秒之内执行完毕
3.无须在探针中实现重试循环

2.ReplicationController副本控制器(了解)

ReplicationController是 一 种Kubemetes资源,可确保它的pod始终保持运行状态。

ReplicationController会持续监控正在运行的pod列表, 并保证相应类型”(标签选择器)的pod的数目与期望相符。 如正在运行的pod太少, 它会根据pod模板创建新的副本如正在运行的pod太多, 它将删除多余的副本

1.ReplicationController的三部分

1.label selector ( 标签选择器), 用于确定ReplicationController作用域中有哪些pod
2.replica count (副本个数), 指定应运行的pod 数量
3.pod template (pod模板), 用于创建新的pod 副本

2.更改控制器的标签选择器或pod 模板的效果

更改标签选择器和 pod 模板对现有 pod 没有影响,更改标签选择器会使现有的pod脱离ReplicationController 的范围

3.定义ReplicationController YAML文件

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

其中第一个name是ReplicationController的名字，relicas为pod数量，selector为pod选择器决定了RC的操作对象template为创建pod的模板

4.如果向rc创建的pod中添加标签对rc控制pod过程没有影响

kubectl label pod kubia - dmdck type=specia

5.更改托管的pod标签会对rc控制pod产生影响,rc会新创建一个pod，此时会有4个pod

6.动态修改rc模板

ReplicationController 的 pod 模板可以随时修改,修改只会对后来的pod产生影响
kubectl edit rc kubia  # 会默认打开kubia模板文件，保存后即可对模板就行更新，后续的pod将会产生影响

7.水平扩缩容

kubectl scale rc kubia --replicas=10/2

8.删除rc

1.kubectl delete rc kubia   # 默认删除rc创建的资源
2.kubectl delete rc kubia --cascade=false  # 不会删除创建的pod

3.使用ReplicaSet代替RC

1.RS和RC的行为完全相同，但是RS的优点体现在pod管理上面,RS允许组合多个标签匹配pod，并且也可以匹配所有包含名为env标签的pod,无论RS的实际值是什么(可以理解为env=*),但是RC这两点都做不到，因此现在完全可以由RS代替RC

2.定义RS

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: luksa/kubia

其中apiVersion: apps/v1 实在k8s1.9之后使用，matchLabels为RS的选择器

3.删除RS清理集群

kubectl delete rs kubia