企业大部分容器化后如何快速定位问题，分析故障？

问题的定位
（1）容器频繁restart：日志， kubectl logs -f 永远是首选；
（2）状态error： kubectl describe pod 可以描述容器当前什么状态卡住了；
（3）Terminaling： kubectl get pod/svc -owide 看到容器在哪个节点
（4）业务性能问题：接口问题看skywalking；
（5）没有日志: 流量根本没进pod，查看容器云外面的应用；
（6）容器表面正常，内部日志报错： 可能core-dns或kube-dns，解析错误。

容器化后的故障定位和分析，一般都是通过log来进行的。常用的命令是kubectl logs 和 kubectl describe

如果对于常见故障，通常是有FAQ，可以根据现象快速地查找可能原因。不在此回答讨论范围内。
对于新问题故障，建议采用“分层分段”的逻辑来考虑问题。
1）物理层：所在服务器是否有告警，是否硬件层面有故障。
2）网络层：不同应用或不同模块之间是否网络可以通信？
3）传输层: tcp/udp层面，中间是否有防火墙阻断了访问，可能与网络仍然相关，但按协议栈是TCP层；
4）应用层：看部署的应用模块是否可以正常运行，检查日志是常见办法。
对于容器化应用，与普通应用不同。但首先应该保证的是基础设施要能够正常工作，无故障。在基础设施一切正常的前提下，需要保障
1）容器的网络是否正常，pod与pod间互访，pod与集群外互访，这里面会涉及到flannel\calico这样的
cni组件的工作原理。但目前常见cni开源组件未提供troubleshooting的工具，只能手工排查。（打个小广告，博云自研的fabric是带了troubleshooting 工具的）。
2）k8s平台是否正常运行，可以通过查看pod状态做基本判断。如果是集成了prometheus/grafana, 可以较好地监控资源层面
3）容器内应用的运行状态，如其他回答类似，可以通过查看容器内日志，或者集成skywalking工具进行应用层监控。
4）其他的还涉及到负载均衡器到各实例的分发，根据用的负载均衡器类型（可能是ingress）进行问题定位。

分段定位的意思与非容器化应用问题定位没有差异，如 a,b,c,d四个模块组成共同完成一个功能的处理。在定位过程中可以分段进行，例如先看a->b是否正常, 再看b->c是否正常。

我们目前也有在线上使用docker，遇到问题都是先从日志下手，进行一些简单的分析，有些是配置上的问题也有些是性能问题，使用微服务的架构确实增加了运维的复杂度，大部分问题也是需要和开发一起分析

如果是平台方面的问题较多，需要多看些k8s相关的资料。如果是应用出问题，问题很难定位，需要对应用提出一些改造建议，如日志管理平台+链路跟踪