K8S生产环境中实践高可靠的配置和技巧都有哪些？ (2)

配置restart policy
pod运行过程中进程退出是个很常见的问题，无论是代码里面的一个BUG，还是占用内存还多，都会导致应用进程退出，pod退出。您可以在pod上配置restart Policy，都能实现pod挂掉之后在自动重启。

apiVersion: v1 kind: Pod metadata: name: tomcat spec: containers: - name: tomcat image: tomcat restartPolicy: OnFailure # restart Policy有三个可选值

Always：总是自动重启

OnFailure：异常退出才自动重启(进程退出状态非0)

Never：从不重启

配置Liveness Probe和Readiness Probe
Pod处于running状态和pod能正常提供服务是完全不同的概念，一个running状态的pod，里面的进程可能发生了死锁而无法提供服务。但是因为pod还是running的，kubernetes也不会自动重启这个pod。所有我们要在所有pod上配置liveness probe，探测pod是否真的存活，是否还能提供服务。如果liveness probe发现了问题，kubernetes会自动重启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 livenessProbe: httpGet: path: /index.jsp port: 8080 initialDelaySeconds: 3 periodSeconds: 3 readinessProbe: httpGet: path: /index.jsp port: 8080

每个进程一个容器
很多刚刚接触容器的人按照旧习惯把容器当做虚拟机(VM)使用，在一个容器里面放置多个进程：监控进程、日志进程、sshd进程、甚至整个systemd。这样操作存在两个问题：

判断pod整体的资源占用会变复杂，不方便实施前面提到resource limit。

容器内只有一个进程的情况，进程挂了，外面的容器引擎可以清楚的感知到，然后重启容器。如果容器内有多个进程，某个进程挂了，容器未必受影响，外部的容器引擎感知不到容器内有进程退出，也不会对容器做任何的操作，但是实际上容器已经不能正常工作了。
如果有好几个进程需要进行协同工作，在kubernetes里也可以实现，例如nginx和php-fpm，通过unix domain socket通信，我们可以用一个包含两个容器的pod，unix socker放在两个容器的共享volume中。

确保不存在SPOF(Single Point of Failure)
如果应用只有一个示例，当实例失败的时候，虽然kubernetes能够重启实例，但是中间不可避免的存在一段时间的不可用。甚至更新应用，发布一个新版本的时候，也会出现这种情况。在kubernetes里，尽量避免直接使用pod，尽可能的使用deployment/Statefulset,并且让应用至少有两个pod以上。