Kubernetes 无状态应用的一般特征
以 12 要素为代表的微服务标准，很好地给微服务的特征做出了指导。然而具体到以容器形式在 Kubernetes 上运行的无状态业务应用上，这个标准是有些高层的——它看重的是方法和架构。如果仅从外在视角来对一个“顺眼”的 Kubernetes 应用进行观察，这个应用应该有什么特征呢？
依赖关系清晰
微服务应用通常会有各种外部依赖，例如数据库、缓存、队列等平台能力，或者业务上的依赖服务等，因此一个健康的微服务组合而成的应用，必须能处理好依赖关系。
微服务的启动顺序不是固定的，并且存在独立更新、重启的可能。而很多应用仅在启动时进行连接，这就要求在 Kubernetes 上运行的应用，首先在启动时，不会因为暂时无法连接依赖服务直接崩溃；同时在运行期间，也有处理这种随时重连的能力。
具备自检能力
存活检测关注的是进程是否活跃，是否应该重新启动；就绪检测代表的是服务能力，是否应该保存在 Service 的负载均衡池中。
在没有设置就绪检测的情况下，Pod 一旦启动成功，K8s 就会把相关服务的请求发给该实例，如果这个实例启动较慢，就有可能对业务造成损失。同理，存活和就绪检测应该分别进行，例如业务阻塞时，暂时将实例摘除，但是无需重启，即可逐步恢复服务能力。
联系到前面的依赖关系问题，在微服务环境中，一个服务的就绪检测应该仅仅关注本应用的情况，检测过程中不应包含对依赖服务的调用——否则所有依赖故障服务的其它服务的就绪检查失败，造成大面积故障。
日志采集和处理
应用不应继续把日志输出到本地文件，而应该输出到
stdout和stderr；集群应该针对容器的
stdout、stderr提供统一的日志采集，建议使用 Daemonset 而非 Sidecar；进行日志采集的同时，集群应提供 ES、Loki 或其它类似机制来对日志进行处理，并且其处理和存储能力应该有初步预案；
应用日志应提供分级开关，保证同一镜像在不同环境中可以输出不同数量和级别的日志信息。
尽量优雅关停
容器命令入口应该有能力接收
SIGTERM，并在需要的情况下传递给业务主进程；应用进程接收到
SIGTERM信号之后，不应立刻关停，而是处理好剩余的在途业务；使用
preStop等 Pod 生命周期手段来完成特定任务；避免使用长连接，保持简单负载均衡的有效性。
故障预防和应对
避免运行单 Pod 的 Deployment；
使用 Pod 软亲和避免同 Deployment 中的不同 Pod 分布在同一节点上；
遭遇不可恢复的故障，应该允许应用崩溃，由 K8s 重新启动；
定义 PDB（Pod disruption budgets），告知 K8s 为应用提供最低 Pod 数量保障。
资源使用
必须定义 CPU 和内存的 Requests；
必须定义内存的 Limits；
同一集群中的不同微服务，如果有不同 QoS 要求，应该定义不同的
qosClass，避免被无差别驱逐。
安全相关
应清晰掌握并声明应用运行所需的 Linux Capabiltiy；
避免使用 Root 身份运行容器；
使用只读的 RootFS，所有写入需求应该使用存储卷来完成；
避免特权逃逸。