这篇文章主要介绍了kubernetesk8s常用问题如何排查的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇kubernetesk8s常用问题如何排查文章都会有所收获，下面我们一起来看看吧。使用 K8s 部署我们的服务之后，为了观察 Pod 是否成功，我们都会使用下面这个命令查询 Pod 的状态。这里的 STATUS 代表了 Pod 的状态，可能会遇到的状态有下面几个：ContainerCreating：代表容器正在创建，这是一个中间状态，随着容器创建成功会切换，但是也有可能一直卡在这里，具体问题下面会分析。ImagePullBackOff：容器镜像拉取失败，具体原因需要结合 describe 命令再去查看。CrashLoopBackOff：容器崩溃，一般容器崩溃，Deployment 会重新创建一个 Pod，维持副本数量，但是大概率新创建的Pod 还是会崩溃，它不会无限尝试，崩溃超过设置次数就不会再尝试重建Pod，此时Pod的状态就维持在了 CrashLoopBackOff。Evicted: 因为节点资源不足（CPU/Mem/Storage都有可能），Pod 被驱逐会显示 Evicted 状态，K8s 会按照策略选择认为可驱逐的Pod从节点上 Kill 掉。Running 这个代表 Pod 正常运行。下面我们来看一下 Pod 的几个错误状态的原因，以及怎么排查解决它们。镜像拉取失败后 Pod 的状态字段表示为 ImagePullBackOff，这个发生的情况还是很多的，原因除了我们不小心写错镜像名字之外，还有就是常用软件的一些官方镜像都在国外，比如在docker.io 或者 quay.io 的镜像仓库上，有的时候访问速度会很慢。下面我们自己故意制造一个镜像名字写错的场景，看怎么使用 kubectl 命令进行排查。比如我在 K8s 教程里一直用的 Deployment 定义：我们把镜像的名字故意改错，改成 v0.5，这个镜像是我自己打的，确实还没有 0.5 版本。执行kubectl apply 后，来观察一下 Pod 的状态。上面我们更新了 deployment 之后，观察到 Pod 的状态变化过程是：首先 deployment 更新 Pod 时是滚动更新，要先把新 Pod 创建出来后能对旧版本 Pod 完成替换。接下来由于镜像拉取错误会反馈一个中间状态 ErrImagePull，此时会再次尝试拉取，如果确定镜像拉取不下来后，最后反馈一个失败的终态 ImagePullBackOff。怎么排查是什么导致的拉取失败呢？通过 kubectl describe pod {pod-name} 查看它的事件记录Pod 事件记录里，清楚记录了 Pod 从开始到最后经历的状态变化，以及是什么导致状态变化的，其中失败事件里清楚的给出了我们原因，就是镜像找不到。还有一种是网络原因，或者镜像仓库没有权限拒绝拉取请求，导致无法拉取成功。因为我这里网络环境、加速器之类的好不容易都配好了，就不给大家演示这两种情况了。不过排查方式也是一样，使用kubectl describe 命令查看 Pod 的事件，并且使用 docker pull 尝试主动的拉取一下镜像试试，如果确实网络问题拉取不下来的，可以考虑翻墙，或者使用国内的加速节点。配置加速器，可以考虑使用阿里云的免费加速器，配置文档在下面，需要注册阿里云账号才能使用加速器https://help.aliyun.com/product/60716.html再来看这种错误，这种一般是容器里运行的程序内部出问题导致的容器连续崩溃出现的问题。最后反馈到 Pod 状态上是 CrashLoopBackOff 状态。演示容器运行中崩溃的情况有点难，不过好在我之前介绍 Go 服务自动采样的时候，做过一个镜像以下内容引用我之前的文章：Go 服务进行自动采样性能分析的方案设计与实现我做了个docker 镜像方便进行试验，镜像已经上传到了Docker Hub上，大家感兴趣的可以Down下来自己在电脑上快速试验一下。通过以下命令即可快速体验。容器里Go服务提供的路由如下所以我们把上面的 deployment Pod 模版里的镜像换成这个 kevinyan001/go-profiling，再通过提供的路由手动制造 OOM，来故意制造容器崩溃的情况。修改Pod 使用的容器镜像创建个 SVC 让Pod能接受外部流量程序中提供的路由如下：访问 http://127.0.0.1:30080/1gb-slice 让容器内存溢出，因为 Deployment 会重启崩溃的 Pod，所以这里非常考验手速：） 估计狂点一分钟，Deployment 就放弃治疗休息会儿再重启 Pod，这时 Pod 的状态成功变成了：这个时候我们使用 kubectl describe pod 看崩溃 Pod 的详细信息，会看到容器内程序返回的错误码不过要深入排查 Pod 内容器的问题，需要另一个命令 kubectl logs {pod-name} 的协助。如果恰巧这个 Pod 被重启了，查不出来任何东西，可以通过增加 — previous 参数选项，查看之前容器的日志。首先声明，这个问题研发解决不了，但是你发挥一下自己YY的能力：当群里报警、运维@你赶紧看的时候，你来个反杀，告诉他资源不够了赶紧扩容，是不是能装到^_^…扯远了，现在回正题。集群里资源紧张的时候，K8s 会优先驱逐优先级低的 Pod，被驱逐的 Pod 的状态会是 Evicted，这个情况没办法在本地模拟，贴一个在公司K8s集群遇到这种情况的截图。kubectl get pod 查看Pod状态上图可以看到有一个Pod 的状态变成了 Evicted。再来用describe 看下详细信息kubectl describe pod 查看Pod 的详细信息和事件记录不好意思，历史久远，上面的图太模糊了，图中的Message 一栏里有给出如下信息：一般来说，大多数常见的部署失败都可以使用这些命令进行排查和调试：kubectl get podskubectl describe pod
这篇文章主要介绍“vue怎么配置多个代理”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“vue怎么配置多个代理”文章能帮助大家解决问题。在Vue项目的开发过程中,为了本地调试方便，我们通常会在 vue.config.js…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
