K8S问题集锦

经过在内网自建K8S环境及使用华为云CCE对现网平台进行一轮容器化改造测试后，积累一些k8s的常见问题和应对方案，整理以下。

问题1、POD时间同步问题

容器内部时间和node节点的系统时间不一致，这个问题其实不是k8s问题，单纯使用docker也存在相似问题。

解决方案，将物理机的时区文件以hostpath方式只读挂载，这样只要保证物理机的系统时间是正确的便可。

问题2、POD内部hosts文件问题

默认状况下，k8s会将pod的hostname和ip地址添加到hosts文件里面，实际应用场景下会有手工去追加hosts文件记录的需求，而pod的生存周期是不固定的，所以官方提供了hostalias的解决方案。
https://kubernetes.io/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/

经过配置pod内部hosts文件的初衷有两个。
一、有些微服务之间的调用走的是公网解析，效率低且DNS有可能响应超时。
二、目前开发、测试和现网环境，本质上代码是同一套。
咱们经过配置hosts记录，能够将程序链接mysql、mongodb、mq这些公共服务的名称固定。不一样的环境对应的公共服务的IP地址经过hostalias方式注入（须要保证三套环境的公共服务用户名、密码、端口这些信息是一致的）能够有效避免因为配置的缘由致使的问题。

问题3、滚动更新问题

在只配置一个POD副本且为配置滚动升级的状况下，当咱们须要对POD进行升级重启的时候，会立刻把仅有的一个正常POD关闭掉，同时启动一个新的POD，这个过程当中，服务将会短暂不可用。

解决方案，配置滚动更新策略

问题4、存活检测和工做负载检测

当POD内的进程不工做或者OOM了，须要进行自我重启工做。未配置liveness状况下是没法检测和处理相似状况的。

解决方案，配置liveness和readiness探针


这里须要说明一下liveness探针主要用来判断POD内的进程是否存活，readiness探针用来判断pod内的进程是否已准备就绪，在未就绪以前，对应service的流量不会转发到pod内。

问题5、java应用时区同步问题

JVM启动时候的时区。若是不指定，则默认取系统时区，这就会致使java应用的时间和容器时间差8个小时。

解决方案，经过配置JAVA_OPTS设置java时区（一样JVM的内存参数也能够经过这种方式配置）
-Duser.timezone=GMT+08 或者 -Duser.timezone=Asia/Shanghai

问题6、集群内外网络互通问题

K8s集群不一样node上的pod网络通讯是经过cni网络插件（例如flannel、calico等）实现的，路由信息保存在etcd中，pod网络访问互联网经过node的iptables nat实现。

但在实际应用环境中，需求老是多样的，当在k8s集群外部的主机须要直接访问pod网络的时候，就须要经过配置路由手段才能实现。对应的解决方案就是添加路由。

和node节点在同一个网段内的主机，将对应网络的下一跳地址指向相应的node节点便可。

和node节点不在同一个网段内的主机，须要在上层路由上进行配置。

问题7、POD间网络隔离

默认 Pod 是未隔离的，POD之间的网络畅通无阻。实际应用中，会有配置网络隔离的需求。
好比须要在pod间作流量的精细控制。

解决方案，使用networkpolicy (要求集群的CNI插件能支持networkpolicy)

后记

还有一些例如elb、Ingress关联进行服务发布、APM应用性能监控、AOM容器监控和日志收集、容器镜像仓库、CI\CD流水线的集成，目前国内公有云三巨头（阿里云、华为云、腾讯云）都有详尽的解决方案和文档，就不在一一介绍了，感兴趣的同窗能够看看三巨头的官方文档。