一.pod资源限制：

对pod资源限制原因：高并发占用所有的cpu资源、内存资源、会造成雪崩

当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

方式：

• 对pod做限制
• 对k8s做限制

1.pod资源限制方式：

• 当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。
• 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

 2.pod资源限制指定时指定的参数：

• request 资源：

当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。

• limit 资源：

当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。

如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。

• 两种资源匹配方式：

如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。

3.资源限制的示例：

3.1官网示例：

Resource Management for Pods and Containers | Kubernetes

3.2Pod和容器的资源请求和限制格式：

#Pod 和 容器 的资源请求和限制：
spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu			//定义 cpu 的资源上限 
spec.containers[].resources.limits.memory		//定义内存的资源上限

3.3CPU 资源单位介绍：

• CPU 资源的 request 和 limit 以 cpu 为单位。
• Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）
• Kubernetes 也支持带小数 CPU 的请求。
• spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。
• Kubernetes 不允许设置精度小于 1m 的 CPU 资源。

4.案例一：OOMKilled：资源不足被杀死：

apiVersion: v1
kind: Pod
metadata:
  name: ky-web-db
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:
      requests:
        memory: "64Mi"
        cpu: "0.25"
      limits:
        memory: "128Mi"
        cpu: "500m"

5.案例二 ：给足资源：

apiVersion: v1
kind: Pod
metadata:
  name: ky-web-db
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:
      requests:
        memory: "64Mi"
        cpu: "0.5"
      limits:
        memory: "1Gi"
        cpu: "1"

二、健康检查，又称为探针（Probe）：

探针是由kubelet对容器执行的定期诊断

1.探针的三种规则：

livenessProbe ：

判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。

readinessProbe ：

判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service 址endpoints 中剔除删除该Pod的IP地。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。

startupProbe（这个1.17版本增加的）：

判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，在则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。 #注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。

2.Probe支持三种检查方法（探测）：

exec：

在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。

tcpSocket：

对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。

httpGet：

对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的。

3.每次探测都将获得以下三种结果之一：

●成功：容器通过了诊断。

●失败：容器未通过诊断。

●未知：诊断失败，因此不会采取任何行动。

官网示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

4.探针三种方式示例：

 4.1.exec方式：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    imagePullPolicy: IfNotPresent
    args:             ###启动容器参数
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
    livenessProbe:     #定义了容器的就绪探针
      exec:            #在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
        command:       #指定了执行的命令
        - cat
        - /tmp/healthy
      failureThreshold: 1            #就绪探针在连续失败一次后被视为失败
      initialDelaySeconds: 5         #延迟5秒启动容器
      periodSeconds: 5               #每隔5秒探测一次


//  - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
创建一个名为 /tmp/healthy 的文件，暂停执行脚本，等待 30 秒钟，删除后，再次暂停执行脚本，等待额外的 60 秒钟

因为/tmp/healthy文件不存在，所以探测失败

4.2.httpGet方式：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: soscscs/myapp:v1           #soscscs：nginx1.12
    imagePullPolicy: IfNotPresent      #拉取策略
    ports:
    - name: http
      containerPort: 80
    livenessProbe:              #探针
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1     #延迟1秒开始探测
      periodSeconds: 3          #每3秒探测一次
      timeoutSeconds: 10         #超时时间10秒

删除index.html：

 查看：

当我们删除页面后，会报错404;然后就会探测失败，最后会重启

  4.3tcpSocket方式：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: soscscs/myapp:v1           #soscscs：nginx1.12
    imagePullPolicy: IfNotPresent      #拉取策略
    ports:
    - name: http
      containerPort: 80
    livenessProbe:              #探针
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1     #延迟1秒开始探测
      periodSeconds: 3          #每3秒探测一次
      timeoutSeconds: 10         #超时时间10秒

这个例子同时使用 readinessProbe 和 livenessProbe 探测。kubelet 会在容器启动 5 秒后发送第一个 readinessProbe 探测。这会尝试连接 goproxy 容器的 8080 端口。如果探测成功，kubelet 将继续每隔 10 秒运行一次检测。除了 readinessProbe 探测，这个配置包括了一个 livenessProbe 探测。kubelet 会在容器启动 15 秒后进行第一次 livenessProbe 探测。就像 readinessProbe 探测一样，会尝试连接 goproxy 容器的 8080 端口。如果 livenessProbe 探测失败，这个容器会被重新启动。

4.4.就绪探针readinessProbe1：

vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: soscscs/myapp:v1                               #指定了容器使用的镜像
    imagePullPolicy: IfNotPresent                         #指定了镜像拉取策略为仅在本地不存在时才拉取
    ports:                                                              #定义了容器暴露的端口，这里使用的是 80 端口
    - name: http
      containerPort: 80
    readinessProbe:                                            #就绪探测配置，用于检查容器是否准备好接受请求
      httpGet:                                                      #指定了进行 HTTP GET 请求的方式进行探
        port: 80                                                    #探测请求将发送到容器的 80 端口
        path: /index1.html                                    #探测请求发送的路径为 "/index1.html"
      initialDelaySeconds: 1                               #容器启动后等待 1 秒后开始进行就绪探测
      periodSeconds: 3                                     #进行就绪探测的间隔为 3 秒
    livenessProbe:                                           #存活探测配置，用于检查容器是否存活
      httpGet:                                                   #指定了进行 HTTP GET 请求的方式进行探测
        port: http                                               #探测请求将发送到容器的 "http" 端口（实际上可能是 "http" 端口的映射，比如 8080）
        path: /index.html                                  #探测请求发送的路径为 "/index.html"
      initialDelaySeconds: 1                           #器启动后等待 1 秒后开始进行存活探测
      periodSeconds: 3                                  #进行存活探测的间隔为 3 秒
      timeoutSeconds: 10                              #探测请求的超时时间为 10 秒

kubectl create -f readiness-httpget.yaml

#readiness探测失败，无法进入READY状态
kubectl get pods 

kubectl exec -it readiness-httpget sh
cd /usr/share/nginx/html/
ls
50x.html    index.html
echo 123 > index1.html 
exit

kubectl get pods 

4.5.就绪探针readinessProbe2：

vim readiness-myapp.yaml
---
apiVersion: v1
kind: Pod
metadata:
apiVersion: v1
kind: Pod
metadata:
  name: myapp1
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp3
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  type: ClusterIP
  ports:
  - name: http
    port: 80
    targetPort: 80

kubectl create -f readiness-myapp.yaml

kubectl get pods,svc,endpoints -o wide

kubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html

#readiness探测失败，Pod 无法进入READY状态，且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址
kubectl get pods,svc,endpoints -o wide

4.6.启动、退出动作 ：

#启动、退出动作
vim post.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: soscscs/myapp:v1
    lifecycle:   #此为关键字段
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]      
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  initContainers:
  - name: init-myservice
    image: soscscs/myapp:v1
    command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  volumes:
  - name: message-log
    hostPath:
      path: /data/volumes/nginx/log/
      type: DirectoryOrCreate

kubectl create -f post.yaml

kubectl get pods -o wide

kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message

#在 node01 节点上查看
[root@node01 ~]# cd /data/volumes/nginx/log/
[root@node01 log]# ls
access.log  error.log  message
[root@node01 log]# cat message 
Hello initContainers
Hello from the postStart handler
#由上可知，init Container先执行，然后当一个主容器启动后，Kubernetes 将立即发送 postStart 事件。

#在master删除 pod 后，再在 node01 节点上查看
kubectl delete pod lifecycle-demo
 
[root@node01 log]# cat message 
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，当在容器被终结之前， Kubernetes 将发送一个 preStop 事件。

三、总结：

1.pod容器探针三种方式：

存活探针：

判断容器是否运行正常，如果探测失败则杀死容器（不是pod），容器根据容器策略决定是否重启

就绪探针：

判断pod是否能进入ready状态，做好接受请求的准备，如果探测失败会进入notready状态，并且从serivce资源的endpointis中的提出，service将不会再把访问请求转发给这个pod

启动探针：

判断容器内的应用是否启动成功，在探测成功状态为success之前，其他探针都会处于失效状态

2.三种探测方式：

exec：

通过command设置，执行在容器内执行的Linux命令来进行探测，如果返回码为0，则为探测成功；非0则为探测失败

httpget：

通过http get 请求访问指定容器端口和url路径，如果访问状态码为>=200且<400(2xx  300),则认为探测成功，否则失败

tcpsocket：

通过指定的端口发送tcp连接，如果端口无误且三次握手成功（tcp连接成功），则认为探测成功

3.数据流向：