k8s部署资源服务的注意事项

前言

为了k8s的资源服务能够高效、稳定、健康的运转，需要对其进行相应的设置

资源类别

声明每个Pod的resource

在使用k8s集群时，经常会遇到：在一个节点上调度了太多的Pod，导致节点负载太高，没法正常对外提供服务的问题
为了避免上述问题，在k8s中部署Pod时，可以指定这个Pod需要Request及Limit的资源，k8s在部署这个Pod的时候，就会根据Pod的需求找一个具有充足空闲资源的节点部署这个Pod。如下示例，声明Nginx这个Pod需要1核CPU、1024M的内存，运行中实际使用不能超过2核CPU和4096内存

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    resources: # 资源声明
      requests:
        memory: "1024Mi"
        cpu: "1000m"
      limits:
        memory: "4096Mi"
        cpu: "2000m"

k8s采用静态资源调度方式，杜宇每个节点上的剩余资源，是这样计算的：节点剩余资源=节点总资源-已经分配出去的资源，并不是实际使用的资源。如果手动运行一个很耗资源的程序，k8s并不能感知到
另外所有的Pod都要声明resources，对于没有声明resources的Pod，它被调度到某个节点后，k8s也不会在对应节点上扣掉这个Pod使用的资源，可能会导致上调度过去太多的Pod

配置restart policy

Pod运行过程中进程退出是个很常见的问题，无论是代码里的一个bug，还是占用内存太多，都会导致应用进程退出，Pod退出。可以Pod上配置restartPolicy，就能实现Pod挂掉之后自动启动，示例如下所示

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    restartPolicy: OnFailure

restartPolicy有三个可选值

• Always：总是自动重启
• OnFailure：异常退出才自动重启（进程退出状态非0）
• Never：从不重启

配置Liveness Probe和Readiness Probe

Pod处于Running状态和Pod能正常提供服务时完全不同的概念，一个Running状态的Pod，里面的进程可能发生了死锁二无法提供服务。但因为Pod还是Running的，k8s也不会自动重启这个Pod，所以要在所有Pod上配置Liveness Probe，探测Pod是否真的存活，是否还能提供服务，如果Liveness Probe发现了问题，k8s会重启Pod
Readiness Probe用于探测Pod是不是可以对外提供服务，应用启动过程中需要一些时间完成初始化，在这个过程中时没法对外提供服务的，通过Readiness Probe，可以告诉Ingress或者Service能不能把流量转发到这个Pod上，当Pod出现问题的时候，Readiness Probe能避免新流量继续转发到这个Pod，示例如下

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    restartPolicy: OnFailure

结语

k8s部署资源服务的注意事项