Kubernetes组件日志输出位置及AzureDisk挂载超时排障日志查询

我来帮你理清这些日志相关的问题，分两部分给你详细解释：

Kubernetes组件的日志输出位置主要取决于部署方式，常见情况如下：

• 控制平面组件（kube-apiserver、kube-controller-manager、kube-scheduler、etcd）：

  • 如果是通过systemd部署（比如多数Linux发行版的默认方式），日志会被收集到journald中，对应系统journal存储的二进制文件（通常在/var/log/journal/下，需用工具查看）。
  • 如果是二进制手动部署，一般会配置输出到指定文件，常见路径比如/var/log/kubernetes/下的对应组件文件（如kube-apiserver.log）。
  • 如果是容器化部署（比如kubeadm搭建的集群），这些组件以Pod形式运行在kube-system命名空间，日志直接是容器日志，通过kubectl logs查看。

• 节点组件（kubelet、kube-proxy）：

  • kubelet几乎都是通过systemd管理，日志同样在journald中；部分场景下也会输出到文件，比如/var/log/kubelet.log。
  • kube-proxy如果是systemd部署则在journald，容器化部署的话也是kube-system命名空间下的Pod日志。

• 容器应用日志：Pod里的业务容器日志默认输出到容器的标准输出/标准错误，通过kubectl logs <pod-name>查看，也会被集群日志采集工具（如ELK、Loki）收集到对应存储。

你提到的azure_managedDiskController.go里的glog调用，属于kube-controller-manager的一部分——因为Azure托管磁盘的控制器是kube-controller-manager中的一个控制器实例，所以这些glog日志会跟着kube-controller-manager的日志输出走，具体查看方式分部署场景：

• systemd部署的kube-controller-manager：
  直接用journalctl查看实时日志，命令示例：

  journalctl -u kube-controller-manager.service -f --grep="azure"
  

  其中-f用于实时跟踪日志，--grep="azure"可以过滤出Azure相关内容，方便定位问题。

• 容器化部署（kubeadm或云厂商托管集群）：
  kube-controller-manager以Pod形式运行在kube-system命名空间，用kubectl查看日志：

  kubectl logs -n kube-system kube-controller-manager-<你的节点名称> -f --container=kube-controller-manager
  

  还可以加--grep="managedDisk"这类过滤条件，快速找到和Azure磁盘控制器相关的日志，排查超时问题的具体原因。

• 二进制部署场景：
  日志会输出到预先配置的文件，比如/var/log/kubernetes/kube-controller-manager.log，用tail -f实时查看：

  tail -f /var/log/kubernetes/kube-controller-manager.log | grep "azure_managedDiskController"
  

另外要注意，glog日志包含不同级别（INFO/WARNING/ERROR），超时问题重点关注ERROR或WARNING级别的日志，里面会有更详细的错误堆栈或超时原因说明。

内容的提问来源于stack exchange，提问作者Highway of Life