初学者怎么做php网站,临安农家乐做网站,社交网站开发技术岗,国家建设部网站查询前言 本篇主要分享一些处理故障和问题绝招#xff0c;比如听诊三板斧#xff1a;1#xff09;查看日志2#xff09;查看资源详情和事件3#xff09;查看资源配置#xff08;YAML#xff09;如果还是不太好分析#xff0c;那就祭出神器——kubectl-debug。最后比如听诊三板斧1查看日志2查看资源详情和事件3查看资源配置YAML如果还是不太好分析那就祭出神器——kubectl-debug。最后仅需根据问题对症下药即可。目录进一步诊断分析——听诊三板斧容器调测 对症下药 进一步诊断分析——听诊三板斧在初诊阶段我们往往只能获得一些表面的信息比如节点挂了Pod崩溃了网络不通等等这时我们需要根据我们初诊的方向和范围使用一些工具以及结合日志进行具体的诊断。这里笔者推崇听诊三板斧查看日志查看资源详情和事件查看资源配置查看日志大部分情况下想要获得具体的病因查看日志是最为直接的方式因此我们需要学会如何查看日志。1.使用journalctl查看服务日志主流的Linux系统基本上都采用Systemd来集中管理和配置系统如果使用的是Systemd机制我们可以使用journalctl命令来查看服务日志比如dockerjournalctl -u docker查看并追踪kubelet的日志journalctl -u kubelet -f2.使用“kubectl logs”查看容器日志我们的应用运行在Pod之中以及k8s的一些组件例如kube-apiserver、coredns、etcd、kube-controller-manager、kube-proxy、kube-scheduler等也都运行在Pod之中静态Pod那么如何查看这些组件以及应用的日志呢这里就要用到前面提到的“kubectl logs”命令。语法如下所示kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] [options]主要的参数说明如下表所示参数说明-f, --follow是否持续追踪日志默认为false指定了之后会持续输出日志。-p, --previous输出Pod中曾经运行过但目前已终止的容器的日志。-c, --container容器名称。--since仅返回相对时间范围如5s、2m或3h内的日志。默认返回所有日志。--since-time仅返回指定时间之后的日志默认返回所有。只能同时使用since和since-time中的一种。--tail要显示的最新的日志条数默认为-1显示所有。--timestamps输出的日志中包含时间戳。-l, --selector使用Label选择器过滤了解了主要的参数和说明我们查看几个示例查看Pod“mssql-58b6bff865-xdxx8”的日志kubectl logs mssql-58b6bff865-xdxx8查看24小时内的日志kubectl logs mssql-58b6bff865-xdxx8 --since 24h根据Pod标签查看日志kubectl logs -lappmssql查看指定命名空间下的Pod日志注意系统组件的命名空间为“kube-system”kubectl logs kube-apiserver-k8s-master -f -n kube-system查看资源实例详情除了查看日志之外有时候我们需要查看资源实例详情以帮助我们解决问题。这就需要用到我们上面提到过的“kubectl describe”命令。“kubectl describe”命令用于查看一个或多个资源的详细情况包括相关资源和事件。语法如下所示kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)主要的参数说明如下表所示参数说明-A,--all-namespaces查看所有命名空间下的资源-f, --filename根据资源描述文件、目录、Url来查看-R, --recursive以递归方式查看-f指定的所有资源-l, --selector使用Label选择器过滤--show-events 显示事件了解了主要的参数和说明我们通过示例来进行解说1.查看节点查看指定节点kubectl describe nodes k8s-node1查看所有节点kubectl describe nodes查看指定节点以及事件kubectl describe nodes k8s-node1--show-events注意如果Node状态为NotReady通过查看节点事件可以有助于我们排查问题。2.查看Pod查看指定Podkubectl describe pods gitlab-84754bd77f-7tqcb查看指定文件描述的所有资源kubectl describe -f teamcity.yaml查看资源以及配置很多应用的出错往往都是我们的配置导致的那么如何查看已部署资源的配置呢这就需要用到强大的“kubectl get”命令了。“kubectl get”命令我们经常使用在这之前我们经常用其来查询资源那么如何使用它来查看资源配置呢我们先来看其语法kubectl get [(-o|--output)json|yaml|wide|custom-columns...|custom-columns-file...|go-template...|go-template-file...|jsonpath...|jsonpath-file...] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags] [options]如上述语法所示“kubectl get”拥有强大的格式化输出能力支持“json”、“yaml”等在上面的kubectl一节中我们已经讲解过了这里我们就主要用到“-o”来查看资源配置具体如以下实例所示查看指定Pod配置kubectl get pods mssql-58b6bff865-xdxx8 -o yamlyaml奴家看不惯想看JSON版的想看所有的kubectl get pods -o json查看服务配置kubectl get svc mssql -o yaml查看部署deployment配置kubectl get deployments mssql -o yaml注意“-o”用得好再也不用担心yaml不会写了。容器调测有时候光看日志还没发给出具体诊断可能得动刀子或者进行进一步检查调测才能论证我们的猜想。笔者推荐使用以下方案使用“kubectl exec”进入运行中的容器进行调测我们可以使用“kubectl exec”进入运行中的容器进行调测。这个命令和“docker exec”很类似具体语法如下所示kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...] [options]主要的参数说明如下表所示参数说明-c, --container指定容器名称-i, --stdin启用标准输入--tty , -t分配伪TTY终端设备接下来我们结合示例说明进入容器查看配置kubectl exec mssql-58b6bff865-xdxx8 -- cat /etc/resolv.conf进入容器分配终端并将标准输入流转到bashkubectl exec mssql-58b6bff865-xdxx8 -it bash如上图所示我们进入MSSQL数据库的容器之后使用sqlcmd工具执行了一个查询。这块操作如有疑问请参阅数据库容器化一节。使用kubectl-debug工具调测容器kubectl-debug 是一个简单的开源的kubectl 插件, 可以帮助我们便捷地进行 Kubernetes 上的 Pod 排障诊断背后做的事情很简单: 在运行中的 Pod 上额外起一个新容器, 并将新容器加入到目标容器的 pid, network, user以及 ipc namespace中, 这时我们就可以在新容器中直接用 netstat, tcpdump 这些熟悉的工具来诊断和解决问题了, 而旧容器可以保持最小化, 不需要预装任何额外的排障工具.GitHub地址https://github.com/aylei/kubectl-debug安装脚本如下CentOS 7export PLUGIN_VERSION0.1.1
# linux x86_64下载文件
curl -Lo kubectl-debug.tar.gz https://github.com/aylei/kubectl-debug/releases/download/v${PLUGIN_VERSION}/kubectl-debug_${PLUGIN_VERSION}_linux_amd64.tar.gz
#解压
tar -zxvf kubectl-debug.tar.gz kubectl-debug
#移动到用户的可执行文件目录
sudo mv kubectl-debug /usr/local/bin/为了调试更快更方便我们还需安装debug-agent DaemonSet安装命令如下kubectl apply -f https://raw.githubusercontent.com/aylei/kubectl-debug/master/scripts/agent_daemonset.yml使用起来非常简单以下是常用的使用示例# 输出帮助命令
kubectl debug -h
# 启动Debug
kubectl debug (POD | NAME)
# 假如 Pod 处于 CrashLookBackoff 状态无法连接, 可以复制一个完全相同的 Pod 来进行诊断
kubectl debug (POD | NAME) --fork
# 假如 Node 没有公网 IP 或无法直接访问(防火墙等原因), 请使用 port-forward 模式
kubectl debug (POD | NAME) --port-forward --daemonset-nskube-system --daemonset-namedebug-agent接下来我们使用该工具调试一个已有Pod如下所示kubectl debug teamcity-5997d4fc7f-ldt8w执行该命令后会自动拉取相关镜像并创建容器开启tty并进入容器内部并且自带一些常用工具。这里我们使用nslookup命令来测试Pod内的外网域名比如xin-lai.com解析如上图所示这样就不用每次为了调测网络问题、应用问题而且安装各种工具了费时费力不说有时候网络不通就比较伤了。对症下药根据“听诊”步骤我们需要获得具体的情报才能对症下药。比如Pod为啥没有调度是资源CPU、内存等不足还是所有节点均不满足调度要求比如指定了“nodeName”要求Pod强制调度到某个节点而该节点宕机。只有知道了具体原因我们才能针对情况进行调整和处理直到解决问题。一般来说大家遇到的Pod问题比较多这里笔者做个经验总结。Pod一直处于Pending状态经诊断为资源不足Pending一般情况下表示这个pod没有被调度到一个节点上。通常这是因为资源不足引起的。解决方案有添加工作节点移除部分Pod以释放资源降低当前Pod的资源限制Pod一直处于Waiting状态经诊断为镜像拉取失败如果一个pod卡在Waiting状态则表示这个pod已经调试到节点上但是没有运行起来。解决方案有检查网络问题如果是网络问题则保障网络通畅可以考虑使用代理或国际网络部分域名在国内网络无法访问比如“k8s.gcr.io”如果是拉取超时可以考虑使用镜像加速器比如使用阿里云或腾讯云提供的镜像加速地址也可以考虑适当调整超时时间尝试使用docker pull image来验证镜像是否可以正常拉取Pod一直处于CrashLoopBackOff状态经检查为健康检查启动超时而退出CrashLoopBackOff 状态说明容器曾经启动了但又异常退出了。通常此Pod的重启次数是大于0的。解决方案有重试设置合适的健康检查阈值优化容器性能提高启动速度关闭健康检查往期内容Docker Kubernetes已成为云计算的主流二十六容器化之后如何节省云端成本二十七了解Kubernetes主体架构二十八使用Minikube部署本地Kubernetes集群二十九使用kubectl管理k8s集群三十使用Kubeadm创建k8s集群之部署规划三十一使用Kubeadm创建k8s集群之节点部署三十二集群故障处理之处理思路以及健康状态检查三十三转载是一种动力 分享是一种美德如果喜欢作者的文章请关注【麦扣聊技术】订阅号以便第一时间获得最新内容。本文版权归作者和湖南心莱信息科技有限公司共有欢迎转载但未经作者同意必须保留此段声明且在文章页面明显位置给出原文连接否则保留追究法律责任的权利。文档官网docs.xin-lai.comQQ群编程交流群85318032 产品交流群897857351
