工作负载推荐配置

声明Pod的资源（Request和Limit）

容器的Request及Limit需要根据实际的业务场景进行灵活的配置，Request的值会用于提供给调度器，调度器会检测每个节点可用于分配的资源（节点可分配资源=节点资源总量-节点已分配资源），同时记录每个节点已经被分配的资源（节点上所有Pod中定义的容器Request之和）。如发现节点剩余的可分配资源已小于当前需被调度的Pod的Request，则该Pod就不会被调度到此节点。

如果不配置Request值，调度器就无法感知节点上资源的使用情况，进而无法将每个Pod调度到合适的节点上，可能会导致某个节点上调度了大量的Pod，资源使用过高导致节点故障，进而影响到实际业务。建议给所有容器设置Request，使调度器可以感知到节点资源使用情况，以便做出合理的调度策略。

下面是一个Nginx Pod设置Request和Limit的例子，Request声明这个Pod会占用0.5核CPU、128MB的内存，并且在实际运行中允许Pod使用超过Request值的资源，但是不能超过1核CPU和256MB内存的Limit值。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test
spec:
  containers:
  - name: container-1
    image: nginx
    resources: # 资源声明
      resources:
        limits:
          cpu: 1000m
          memory: 256Mi
        requests:
          cpu: 500m
          memory: 128Mi
  imagePullSecrets:
    - name: default-secret

配置优雅退出时间（terminationGracePeriodSeconds）

优雅退出时间（terminationGracePeriodSeconds）是指失败的容器触发终止操作到强制容器运行时停止该容器之前等待的宽限时长，如果不设置则为30秒，最小值为 1。在Pod被终止之前，容器可以在这个宽限时间中完成优雅关闭，例如保存状态、完成当前处理的任务、关闭网络连接等操作。因此，正确设置terminationGracePeriodSeconds对于确保应用程序能够优雅地关闭非常重要。

如果您希望Pod在终止之前等待60秒，以便容器可以完成清理工作，您可以在Pod的定义中这样设置：

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
      version: v1
  template:
    metadata:
      labels:
        app: nginx
        version: v1
    spec:
      containers:
        - name: container-1
          image: nginx
      imagePullSecrets:
        - name: default-secret
      terminationGracePeriodSeconds: 60

配置容忍度（Toleration）

容忍度可以允许Pod在某些条件下被调度到节点上，即使这些节点上有污点（Taints）存在。比如，对于一个与节点本地状态有着深度绑定的应用而言， 您可能希望在出现网络分裂事件时仍然停留在当前节点上运行一段较长的时间，以等待网络恢复以避免被驱逐。

某些情况下，Kubernetes节点控制器会自动给节点添加一个污点，建议给node.kubernetes.io/not-ready（表示节点未准备好）和node.kubernetes.io/unreachable（表示节点控制器访问不到节点）这两个内置的污点添加容忍度。例如，以下示例表示如果节点被标记为not-ready或unreachable，Pod将在节点上保持运行300秒，然后才会被驱逐。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test
spec:
  containers:
    - name: container-1
      image: nginx
  imagePullSecrets:
    - name: default-secret
  tolerations:
    - key: node.kubernetes.io/not-ready
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300
    - key: node.kubernetes.io/unreachable
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300

配置滚动升级参数

在Kubernetes中，工作负载中的strategy字段定义了如何对Deployment、StatefulSet或DaemonSet等资源进行更新。如果您需要在升级工作负载过程中实现业务不中断，可以设置更新策略为逐步更新，在控制更新过程中存在可用的Pod数量，确保服务的连续性和减少停机时间。例如，对于一个有多个Pod的Deployment，您在滚动更新时可以控制最多可以有多少老Pod处于不可用状态、最多有多少新Pod启动并运行，直到更新完成。逐步更新的方法有助于确保服务的稳定性和可用性，同时允许应用程序的平滑过渡到新版本。

例如，以下配置中定义了一个滚动更新策略，其中maxUnavailable和maxSurge都设置为25%，意味着在更新过程中，可以有最多25%的Pod副本数处于不可用状态，同时可以额外启动最多25%的Pod副本数。

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
      version: v1
  template:
    metadata:
      labels:
        app: nginx
        version: v1
    spec:
      containers:
        - name: container-1
          image: nginx
      imagePullSecrets:
        - name: default-secret
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%

配置restartPolicy

容器的restartPolicy配置用于设置Pod退出后的策略，您可以根据实际业务场景配置不同的策略，实现Pod退出后的自动重启等功能。

下面是一个Nginx Pod设置总是自动重启的例子。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test
spec:
  containers:
  - name: nginx
    image: nginx
    restartPolicy: Always 
  imagePullSecrets:
    - name: default-secret

配置Liveness Probe和Readiness Probe

存活探针（Liveness Probe）可以很好的检查Pod的实际状态是否正常，在Kubernetes中，Pod的状态为Running并不代表可以正常的提供服务，Pod内部进程可能已经发生了死锁等问题而无法提供服务。配置存活探针可以很好的规避类似情况，及时重启Pod，恢复服务。

就绪探针（Readiness Probe）可以通过检测Pod是否已经就绪，来告知Service是否可以将请求转发到Pod上。当Pod出现问题时，Readiness Probe可以避免新流量继续转发到这个Pod。

apiVersion: v1
kind: Pod
metadata:
  name: tomcat
spec:
  containers:
  - name: tomcat
    image: tomcat
    livenessProbe:
      httpGet:
        path: /index.jsp
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 3
    readinessProbe:
      httpGet:
        path: /index.jsp
        port: 8080
  imagePullSecrets:
    - name: default-secret