文章目录

• 一、资源限制
• • 1、资源限制的使用
  • 2、reuqest资源（请求）和limit资源（约束）
  • 3、Pod和容器的资源请求和限制
  • 4、了解拓展 CPU 的资源单位
  • 5、了解拓展 内存资源单位
  • 6、资源限制示例
• 二、健康检查
• • 1、健康检查的定义
  • 2、探针的三种规则
  • • 1.livenessProbe（存活探针）
    • 2.readinessProbe（就绪探针）
    • 3.startupProbe启动探针（1.17版本新增）
    • 4.同时定义
  • 3、Probe支持的三种检测方法
  • • 1.exec
    • 2.tcpSocket
    • 3.httpGet
  • 4、探测结果
  • 5、exec方式
  • 6、httpGet方式
  • 7、tcpSocket方式
• 三、总结
• • 1、探针
  • 2、检查方式
  • 3、用的探针可选参数
  • 2、检查方式
  • 3、用的探针可选参数

一、资源限制

1、资源限制的使用

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

2、reuqest资源（请求）和limit资源（约束）

• 1.当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量，供该容器使用
• 2.如果 Pod 所在的节点具有足够的可用资源，容器可以使用超过所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量
• 3.如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值，并使之与CPU 的 limit 值匹配

3、Pod和容器的资源请求和限制

#定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.cpu

#定义创建容器时预分配的内存资源
spec.containers[].resources.requests.memory

#定义创建容器时预分配的巨页资源
spec.containers[].resources.requests.hugepages-<size>

#定义cpu的资源上限
spec.containers[].resources.limits.cpu

#定义内存的资源上限
spec.containers[].resources.limits.memory

#定义巨页的资源上限
spec.containers[].resources.limits.hugepages-<size>

4、了解拓展 CPU 的资源单位

• CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes中的一个 cpu 相当于一个 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 资源

5、了解拓展 内存资源单位

内存的 request 和 limit 以字节为单位。可以以整数表示，或者以 10 为底数的指数的单位(E、P、T、G、M、K)来表示，或者以2为底数的指数的单位(Ei、Pi、Ti、G1、Mi、Ki)米表示

如：1KB=10^{3=1000,1MB=10}6=1000000=1000KB,1GB=10^9=1000000000=1000MB
1K1B=2^{10=1024,1M1B=2}20=1048576=1024K1B

PS:在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以MB、GB为单位的，1GB就是1,000,000,000Byte,而操作系统是以 2 进制为处理单位的，因此检查驶盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824,相比较而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741，824Byte,所以检测实际结果要比标出的少一些

6、资源限制示例

编写yaml资源配置清单

mkdir /opt/test
vim test1.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: test1
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: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

释放内存node节点，以node1为例

由于mysql对于内存的使用要求比较高，因此需要先检查内存的可用空间是否能够满足mysql的正常运行，若剩余内存不够，可对其进行释放操作

#查看内存
free -mh


#手动释放缓存
echo 3 > /proc/sys/vm/drop_caches
free -mh

#解释
0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理
1：释放页缓存
2：释放dentries和inodes
3：释放所有缓存

#注意：
如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它
一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不足、应用获取不到可用内存、OOM错误等问题时，还是更应该去分析应用方面的原因，如用户量太大导致内存不足、发生应用内存溢出等情况，否则，清空buffer，强制腾出free的大小，可能只是把问题给暂时屏蔽了

创建资源

kubectl apply -f q.yaml

跟踪查看pod状态

kubectl get pod -o wide -w

OOM（OverOfMemory）表示服务的运行超过了我们所设定的约束值
Ready:2/2，status:Running说明该pod已成功创建并运行，但运行过程中发生OOM问题被kubelet杀死并重新拉起新的pod

查看容器日志与详细信息

kubectl logs test1 -c web
kubectl logs test1 -c mysql

kubectl describe pod test1 
#nginx启动正常，mysql报错

删除pod

kubectl delete -f q.yaml

修改yaml配置资源清单，提高mysql资源限制

vim  q.yaml

再次创建资源

kubectl apply -f q.yaml

#跟踪查看pod状态
kubectl get pod -o wide -w

查看pod详细信息

kubectl describe pod test1

查看node资源使用

kubectl describe node node2

二、健康检查

1、健康检查的定义

健康检查又称为探针（Probe），是由kubelet对容器执行的定期诊断。

2、探针的三种规则

1.livenessProbe（存活探针）

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

2.readinessProbe（就绪探针）

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

3.startupProbe启动探针（1.17版本新增）

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

4.同时定义

以上三种规则可同时定义。在 rbeadinessProbe 检测成功之前，Pod 的 running 状态是不会变成 ready 状态的

3、Probe支持的三种检测方法

1.exec

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

2.tcpSocket

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

3.httpGet

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

4、探测结果

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

• 成功：容器通过了诊断
• 失败：容器未通过诊断
• 未知：诊断失败，因此不会采取任何行动

5、exec方式

vim exec.yaml
 
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness				#为了健康检查定义的标签
  name: liveness-exec
spec:						#定义了Pod中containers的属性
  containers:
  - name: liveness
    image: busybox
    args:						#传入的命令
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5			#表示pod中容器启动成功后，多少秒后进行健康检查 
      periodSeconds: 5				#在首次健康检查后，下一次健康检查的间隔时间 5s

常用的探针可选参数

initialDelaySeconds:

• 指定 kubelet 在执行第一次深测前应该等待5秒，即第一次探测是在容器启动后的第6秒才开始执行。默认是0秒，最小值是0

periodSeconds:

• 指定了 kubelet 应该每5秒执行一次存活探测。默认是10秒。最小值是1

failureThreshold:

• 当探测失败时，Kubernetes 将在放弃之前重试的次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是3。最小值是1

timeoutSeconds:

• 探测的超时后等待多少秒。默认值是1秒。最小直是1。（在Kubernetes 1.20版木之前，exec 探针会忽略 timeoutSeconds 探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止）

上述命令解释

在配置文件中，可以看到Pod具有单个Container。该perioSeconds字段指定kubelet应该每5秒执行一次活动性探测。该initiaDelaySeconds字段告诉kubelet在执行第一个探测之前应该等待5秒。为了执行探测，kubelet cat /tmp/healthy在容器中执行命令。如果命令成功执行，则返回0，并且kubelet认为Container仍然重要。如果命令返回非0值，则kubelet将杀死Container并重启它

1.在这个配置文件中，可以看到Pod只有一个容

2.容器中的command字段表示创建一个/tmp/live文件后休眠30秒，休眠结束后删除该文件，并休眠10分钟

3.仅使用livenessProbe存活探针，并使用exec检查方式，对/tmp/live文件进行存活检测

4.initialDelaySeconds字段表示kubelet在执行第一次探测前应该等待5秒

5.periodSeconds字段表示kubelet每隔5秒执行一次存活探测

示例2

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
	  
kubectl create -f exec.yaml

kubectl describe pods liveness-exec

kubectl get pods -w

6、httpGet方式

vim httpget.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

在配置文件中，可以看到Pod具有单个Container。该periodSeconds字段指定kubectl应该每3秒执行一次活动性探测。该initiaDelaySeconds字段告诉kubelet在执行第一个探测之前应等待3秒。为了执行探测，kubectl将HTTP GET请求发送到Container中运行并在端口8080上侦听的服务器。如果服务器/healthz路径的处理程序返回成功代码，则kubectl会认为任何大于或等于400的代码均表示成功，其他代码都表示失败

示例2：

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
	  
kubectl create -f httpget.yaml
kubectl get pods


kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html

kubectl get pods

7、tcpSocket方式

定义TCP活动度探针

第三种类型的活动性探针使用TCP套接字，使用此配置，kubelet将尝试在指定端口上打开容器的套接字。如果可以建立连接，则认为该让其运行状况良好，如果不能，则认为该容器是故障容器

vim tcpsocket.yaml

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

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

TCP检查的配置与HTTP检查非常相似，此示例同时使用就绪和活跃度探针，容器启动5秒后，kubelet将发送第一个就绪探测器。这些尝试连接到goproxy端口8080上的容器。如果探测成功，则容器将标记为就绪，kubelet将继续每10秒运行一次检查。

除了就绪探针之外，此配置还包括活动探针。容器启动后15秒钟，kubelet将运行第一个活动谈着，就像就绪探针一样，这些尝试goproxy在端口8080上连接到容器。如果活动探针失败，则容器将重新启动

示例2

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    livenessProbe:
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 10
      failureThreshold: 2
      initialDelaySeconds: 5

kubectl create -f tcpsocket.yaml

kubectl exec -it probe-tcp  -- netstat -natp

kubectl get pods -w
NAME        READY   STATUS    RESTARTS   AGE
probe-tcp   1/1     Running             0          1s
probe-tcp   1/1     Running             1          25s       #第一次是 init(5秒) + period(10秒) * 2
probe-tcp   1/1     Running             2          45s       #第二次是 period(10秒) + period(10秒)  重试了两次
probe-tcp   1/1     Running             3          65s

三、总结

1、探针

探针分为3种：

• livenessProbe（存活探针）∶判断容器是否正常运行，如果失败则杀掉容器（不是pod），再根据重启策略是否重启容器

• readinessProbe（就绪探针）∶判断容器是否能够进入ready状态，探针失败则进入noready状态，并从service的endpoints中剔除此容器

• startupProbe∶判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

2、检查方式

检查方式分为3种：

• exec∶使用 command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功

• httpget∶通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功

• tcpsocket∶通过tcp连接pod（IP）和指定端口，如果端口无误且tcp连接成功，则认为探测成功

3、用的探针可选参数

常用的探针可选参数有4个

• initialDelaySeconds∶ 容器启动多少秒后开始执行探测
• periodSeconds∶探测的周期频率，每多少秒执行一次探测
• failureThreshold∶探测失败后，允许再试几次
• timeoutSeconds ∶ 探测等待超时的时间

状态，并从service的endpoints中剔除此容器

• startupProbe∶判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态

2、检查方式

检查方式分为3种：

• exec∶使用 command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功

• httpget∶通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功

• tcpsocket∶通过tcp连接pod（IP）和指定端口，如果端口无误且tcp连接成功，则认为探测成功

3、用的探针可选参数

常用的探针可选参数有4个

• initialDelaySeconds∶ 容器启动多少秒后开始执行探测
• periodSeconds∶探测的周期频率，每多少秒执行一次探测
• failureThreshold∶探测失败后，允许再试几次
• timeoutSeconds ∶ 探测等待超时的时间