云原生DevOps运维【免费下载链接】devtronThe only Kubernetes dashboard you need项目地址https://gitcode.com/gh_mirrors/dev/devtron点击查看免费下载部署失败或应用运行异常时排障的第一步是快速定位错误根源。Devtron 将 Kubernetes 原生的排障手段——事件Events、日志Logs、资源清单Manifest、Pod 管理、应用对象视图与性能监控——统一收敛到每个应用的App Details页面无需切换到 kubectl 或额外工具即可完成从发现状态异常到定位根因并修复的完整闭环。读完本文你将掌握在 Devtron 中系统化调试部署问题的完整流程并理解每个功能背后的 Kubernetes API 实现原理。进入 App Details部署状态的第一现场当应用的部署未成功时需要进入App Details页面检查错误原因。在 Devtron 中的访问路径为Applications → AppName → App Details进入该页面后首先应关注应用的整体状态标识。若部署正常应用状态会显示为Healthy只要部署过程中出现任何错误状态就不会处于 Healthy 状态——例如Degraded、Progressing、Suspended或Missing等异常状态。状态异常时可按本文后续的事件 → 日志 → 清单 → 对象 → 监控顺序逐层排查。从源码结构看该页面承载的数据由AppDetailsReadService.FetchAppDetailpkg/app/appDetails/read/AppDetailsReadService.go等接口聚合应用级别的健康状态AppStatus与各环境的部署信息在 api/bean/AppView/AppView.go 的Environment结构中建模。Events部署期间发生了什么应用的事件Events可以从App Details页面左下角进入。Events 区域展示的是应用部署过程中发生的全部 Kubernetes 事件——包括 Pod 调度失败如资源不足、镜像拉取失败、探针未通过、容器启动失败、驱逐等典型问题都会以事件形式记录在这里。注意这些事件仅在应用部署后的 15 分钟内可用因此排查部署问题时应尽快查看。后端实现上事件列表通过POST /api/v1/applications/events路由api/k8s/application/k8sApplicationRouter.go由K8sCommonServiceImpl.ListEvents提供pkg/k8s/K8sCommonService.go最终委托 K8sUtil 调用 Kubernetes Events API 返回指定命名空间与资源的事件。请求会经过基于 casbin 的 RBAC 校验只有具备资源get权限的用户才能读取事件。Logs查看 Pod 与容器日志Logs 区域展示已部署 Pod 和容器的运行日志是定位运行时错误的直接证据。你可以选择指定 Pod、指定容器含 init 容器与临时容器查看日志也可查看某个容器的历史上一实例日志。从请求解析逻辑ValidatePodLogsRequestQuerypkg/k8s/application/k8sApplicationService.go可以看到日志功能支持以下实用参数参数说明containerName指定查看的容器名支持主容器、init 容器、临时容器follow是否实时跟随流式输出用于观察滚动日志tailLines只读取日志末尾的 N 行快速定位最新错误sinceSeconds只读取最近 N 秒内的日志sinceTime只读取指定 Unix 时间戳之后的日志previous是否读取容器上一个实例崩溃前的日志排查 CrashLoopBackOff 时非常关键日志获取通过GetPodLogs调用 Kubernetes 的 Pod Logs API 实现pkg/k8s/application/k8sApplicationService.go流式传输由Pump.StartK8sStreamWithHeartBeat处理支持断线重连通过Last-Event-Id头定位续传点。此外GET /pods/logs/download/{podName}路由api/k8s/application/k8sApplicationRouter.go支持将日志导出为本地.log文件下载时会强制关闭follow标志并将时间戳转换为可读格式。Manifest查看 Pod 关键元数据Manifest 区域展示的是 Pod 及关联资源的详细清单YAML其中包含排障最关键的字段container-image当前运行的容器镜像可确认是否部署了预期版本restartCount容器重启次数重启次数持续增长通常意味着应用崩溃或探针失败state / phasePod 当前所处的状态与阶段Pending / Running / Succeeded / Failed / Unknown 等podIPPod 的 IP 地址用于网络连通性排查startTimePod 启动时间可结合重启次数判断是否为滚动重建。该视图背后的实现是K8sCommonServiceImpl.GetResource它根据ResourceRequestBean中的集群、命名空间与资源标识通过 K8sUtil 读取资源的实时 manifestpkg/k8s/K8sCommonService.go 附近的实现。为保障安全读取操作会先做 RBAC 校验若用户只有只读权限返回的 manifest 中Secret 类的敏感值会被自动隐藏脱敏只有具备编辑权限的用户才能看到明文见 api/k8s/application/k8sApplicationRestHandler.go 中GetResource的处理逻辑。删除与重启 Pod触发自动重建在实际排障过程中你可能会遇到需要删除 Pod 的场景——例如 Pod 状态异常卡在 CrashLoopBackOff、OOM 或探针失败需要弹一下bounce/restart让应用重新调度。在App Details页面点击Delete Pod即可删除指定 Pod。删除 Pod 并不是一件麻烦事当 Pod 被删除后Deployment/ReplicaSet 控制器会根据副本数replica count自动创建新 Pod。例如当你搭建一个新环境并希望应用以干净状态启动时删除旧 Pod 即可让控制器用最新镜像与配置重建实例。后端对应两条路径api/k8s/application/k8sApplicationRouter.goPOST /resource/delete→DeleteResourceWithAudit删除资源并写入 Kubernetes 资源操作审计日志pkg/k8s/application/k8sApplicationService.go底层调用K8sUtil.DeleteResource支持ForceDelete强制删除标志pkg/k8s/K8sCommonService.goPOST /resource/create→RecreateResource先获取资源的期望 manifestdesired manifest再按该 manifest 重新创建资源实现删除并重建的效果pkg/k8s/application/k8sApplicationService.go。除删除外Devtron 还提供了滚动重启Rotate能力POST /resource/rotate接口api/k8s/application/k8sApplicationRouter.go支持对Deployment、StatefulSet、DaemonSet、Rollout四类工作负载进行原地重启通过向工作负载打上devtron.ai/restartedAt与devtron.ai/activity注解触发滚动更新其中 Rollout 使用 MergePatch其余使用 StrategicMergePatchpkg/k8s/K8sCommonService.go。对于不支持重启的 Kind接口会返回明确的错误提示。Application Objects应用对象全景在App Details的 Application Objects 区域你可以查看该应用在集群中创建的 Kubernetes 对象按类别划分如下类别对象说明WorkloadsReplicaSet确保指定数量的 Pod 副本正在运行其下还可查看Pod 状态NetworkingService定义一组 Pod 的逻辑抽象与访问入口Endpoints记录实现该 Service 的后端地址Ingress管理集群外部访问服务的 API 对象Config StorageConfigMap以键值对形式存储非机密配置数据的 API 对象Custom ResourceRollout新 Pod 会被调度到资源充足的节点上支持渐进式发布ServiceMonitor定义一组服务应如何被 Prometheus 监控这些对象共同构成了应用在集群中的完整资源拓扑。Ingress 对象的访问 URL 可通过GET /resource/urls接口批量获取GetHostUrlsByBatch它会从资源树中过滤出 Service 与 Ingress 类型并批量拉取 manifest最终解析出对外访问地址api/k8s/application/k8sApplicationRestHandler.go 中GetHostUrlsByBatch、getUrls。MonitoringCPU、内存、吞吐与延迟App Details页面同时承担监控职能可直接查看应用的核心性能指标指标说明CPU Usage应用消耗的 CPU 周期百分比Memory Usage应用使用的内存量Throughput应用的处理性能吞吐量Latency数据传输造成的延迟监控数据既覆盖单实例粒度也覆盖新旧副本对比在 api/bean/AppView/AppView.go 中InstanceDetail定义了单 Pod 级别的cpuUsage、memoryUsage、cpuUsagePercent、memoryUsagePercent等字段PodDetailStat则提供新旧 Pod 集合的cpuUsagePercent与memoryUsagePercent用于滚动发布期间的资源对比。此外Environment结构中的AppMetrics与InfraMetrics布尔字段分别控制应用级与基础设施级监控的开关。从后端架构看指标数据经由 Grafana/Prometheus 链路采集与展示GrafanaClientConfigclient/grafana/GrafanaClient.go定义了GRAFANA_USERNAME默认admin、GRAFANA_PASSWORD默认prom-operator、GRAFANA_ORG_ID默认2、GRAFANA_URL等配置并通过/api/datasources系列接口管理 Prometheus 数据源。也就是说想要在 App Details 中看到这些指标需要确保集群已接入 Prometheus 并正确配置 Grafana 数据源。实战排障路线一个完整的调试流程综合上述功能一次典型的部署失败排查可以按如下路线推进看状态进入App Details确认应用状态不是Healthy看事件立即打开左下角 Events15 分钟内有效查找调度失败、镜像拉取失败、探针失败等事件看日志进入 Logs选择对应 Pod 与容器查看输出若容器反复崩溃勾选previous查看崩溃前日志或配合tailLines/sinceSeconds缩小范围必要时下载日志归档分析看清单在 Manifest 中核对镜像版本、restartCount、phase、podIP、startTime判断是配置错误还是资源异常看对象在 Application Objects 中核对 ReplicaSet、Service、Endpoints、Ingress 等对象是否按预期创建检查网络与配置链路看监控通过 CPU、内存、吞吐、延迟指标判断是否为资源瓶颈或性能问题处置根据根因选择删除 Pod 触发重建、滚动重启Rotate或在修复配置后重新触发部署。通过这一闭环流程即使不熟悉 kubectl 操作也能高效定位并解决绝大多数 Kubernetes 应用部署与运行问题。赞分享云原生DevOps运维【免费下载链接】devtronThe only Kubernetes dashboard you need项目地址https://gitcode.com/gh_mirrors/dev/devtron点击查看免费下载相关推荐civitai 生产部署状态全链路排查基于 kubectl 的 Tekton → Flux → Flagger 只读监控指南civitai 生产部署状态全链路排查基于 kubectl 的 Tekton → Flux → Flagger 只读监控指南 导读 本文基于 civitai后端前端AI 应用Dask 调试实战指南从本地打印到分布式异常排查与调度状态检查Dask 调试实战指南从本地打印到分布式异常排查与调度状态检查 调试并行程序比调试串行程序困难得多。当异常发生在远程机器、独立进程或后台线程中时常规的 lo大数据数据分析任务调度LXC容器监控和调试实时监控容器状态和排查问题LXC容器监控和调试实时监控容器状态和排查问题 LXCLinux Containers是一个功能强大的操作系统级虚拟化解决方案让您可以在单个Linux主容器运行时云原生运维上一篇cann/sip BLAS公共接口下一篇Nacos在SW64架构与麒麟V10系统的兼容性分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考