简体   繁体   English

Kubernetes 中 /var/logs/ 中缺少的 pod 日志

[英]Logs of pods missing from /var/logs/ in Kubernetes

I have a cluster that has numerous services running as pods from which I want to pull logs with fluentd.我有一个集群,它有许多作为 pod 运行的服务,我想用 fluentd 从中提取日志。 All services show logs when doing kubectl logs service .所有服务在执行kubectl logs service时都会显示日志。 However, some logs don't show up in those folders:但是,某些日志不会显示在这些文件夹中:

  • /var/log /var/日志
  • /var/log/containers /var/log/容器
  • /var/log/pods /var/log/pods

although the other containers are there.尽管其他容器在那里。 The containers that ARE there are created as a Cronjob, or as a Helm chart, like a MongoDB installation.那里的容器被创建为 Cronjob 或 Helm 图表,如 MongoDB 安装。

The containers that aren't logging are created by me with a Deployment file like so:未记录的容器是由我使用 Deployment 文件创建的,如下所示:

kind: Deployment
metadata:
    namespace: {{.Values.global.namespace | quote}}
    name: {{.Values.serviceName}}-deployment
spec:
    replicas: {{.Values.replicaCount}}
    selector:
        matchLabels:
            app: {{.Values.serviceName}}
    template:
        metadata:
            labels:
                app: {{.Values.serviceName}}
            annotations:
                releaseTime: {{ dateInZone "2006-01-02 15:04:05Z" (now) "UTC"| quote }}
        spec:
            containers:
                  - name: {{.Values.serviceName}}
                    # local: use skaffold, dev: use passed tag, test: use released version
                    image: {{ .Values.image }}
                        {{- if (eq .Values.global.env "dev") }}:{{ .Values.imageConfig.tag}}{{ end }}
                    imagePullPolicy: {{ .Values.global.imagePullPolicy }}
                    envFrom:
                        - configMapRef:
                            name: {{.Values.serviceName}}-config
                    {{- if .Values.resources }}
                    resources:
                        {{- if .Values.resources.requests }}
                        requests:
                            memory: {{.Values.resources.requests.memory}}
                            cpu: {{.Values.resources.requests.cpu}}
                        {{- end }}
                        {{- if .Values.resources.limits }}
                        limits:
                            memory: {{.Values.resources.limits.memory}}
                            cpu: {{.Values.resources.limits.cpu}}
                        {{- end }}
                    {{- end }}
            imagePullSecrets:
                - name: {{ .Values.global.imagePullSecret }}  
            restartPolicy: {{ .Values.global.restartPolicy }}
{{- end }}

and a Dockerfile CMD like so: CMD ["node", "./bin/www"]和一个 Dockerfile CMD 像这样: CMD ["node", "./bin/www"]

One assumption might be that the CMD doesn't pipe to STDOUT, but why would the logs show up in kubectl logs then?一种假设可能是 CMD 不会 pipe 到 STDOUT,但是为什么日志会出现在kubectl logs中呢?

This is how I would proceed to find out where a container is logging:这就是我将如何继续找出容器正在记录的位置:

  1. Identify the node on which the Pod is running with:识别运行 Pod 的节点:

     kubectl get pod pod-name -owide
  2. SSH on that node, you can check which logging driver is being used by the node with: SSH 在该节点上,您可以检查该节点正在使用哪个日志记录驱动程序:

     docker info | grep -i logging

    if the output is json-file , then the logs are being written to file as expected.如果 output 是json-file ,那么日志将按预期写入文件。 If there is something different, then it may depends on what the driver do (there are many drivers, they could write to journald for example, or other options)如果有什么不同,那么它可能取决于驱动程序做什么(有很多驱动程序,他们可以写入journald ,例如,或其他选项)

  3. If the logging driver writes to file, you can check the current output for a specific Pod by knowing the container id of that Pod, to do so, on a control-plane node:如果日志记录驱动程序写入文件,您可以通过了解特定 Pod 的容器 id 来检查特定 Pod 的当前 output,在控制平面节点上执行此操作:

     kubectl get pod pod-name -ojsonpath='{.status.containerStatuses[0].containerID}'

    (if there are more containers in the same pod, the index to use may vary, depending on which container you want to inspect) (如果同一个 pod 中有多个容器,使用的索引可能会有所不同,具体取决于您要检查的容器)

  4. With the id extracted, which will be something like docker://f834508490bd2b248a2bbc1efc4c395d0b8086aac4b6ff03b3cc8fd16d10ce2c , you can inspect the container with docker, on the node on which the container is running. With the id extracted, which will be something like docker://f834508490bd2b248a2bbc1efc4c395d0b8086aac4b6ff03b3cc8fd16d10ce2c , you can inspect the container with docker, on the node on which the container is running. Just remove the docker:// part from the id, SSH again on the node you identified before, then do a:只需在您之前确定的节点上再次从 id SSH 中删除docker://部分,然后执行以下操作:

     docker inspect container-id | grep -i logpath

Which should output where the container is actively writing its logs to file. output 应该是容器主动将其日志写入文件的位置。


In my case, the particular container I tried this procedure on, is currently logging into:就我而言,我尝试此过程的特定容器当前正在登录:

/var/lib/docker/containers/289271086d977dc4e2e0b80cc28a7a6aca32c888b7ea5e1b5f24b28f7601ff63/289271086d977dc4e2e0b80cc28a7a6aca32c888b7ea5e1b5f24b28f7601ff63-json.log

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM