k8s中Pod状态及问题排查方法
1、含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。
2、要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。
3、Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。
4、首先，要从容器输出和状态详情入手。通过运行`docker logs $container_id`，您可以直接查看容器内的应用程序输出，以获取实时运行信息。接着，`docker inspect $container_id`可提供容器的详细状态信息，其中特别要注意“OOMKilled”信息，该信息表示容器因内存不足而被Docker自动终止。
5、查看节点机docker中的容器ID，前后不一样，确定是POD被杀掉后重启。通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康 。
6、常见错误状态：Error Pod容器在创建过程中遇到错误。这可能是由于初始化失败、回调失败、就绪探针或存活探针执行失败、容器启动命令执行错误（如路径问题、文件不存在、权限问题、缺少依赖、后台运行问题）导致。排障工具与解决方案 为了应对这些异常场景，Kubernetes提供了丰富的工具和平台支持。
k8s里面kubectlogs-f查看的是实时日志吗?
1、在Kubernetes（K8s）环境中，kubectl logs 命令用于查看容器的日志。其中，kubectl logs -f 参数用于查看容器的实时日志输出，而不需要使用-f标志则会显示最后一次的日志条目。当使用kubectl logs -f命令时，实际上是在监控容器的日志输出，类似于实时日志查看。
2、使用kubectl命令，能够高效地在集群内检索特定pod的日志输出。在跳板机上配置好所有集群的kubeconfig文件，借助kubectl logs命令，结合-f参数持续获取日志，并通过操作符将日志内容保存至本地文件，实现日志的实时收集。若需处理多个容器的日志收集任务，可以通过循环结构简化流程。
3、这些日志文件实际上是链接文件，指向 docker 容器的日志文件。通过查看这些链接，可以看到分别指向当前运行容器的日志和 pod 上次运行但已退出的容器日志文件。使用 logs 命令时，读取的是当前容器的日志文件；而当使用 –previous 参数时，则读取的是上次退出容器的日志文件。
4、跟踪查看容器的日志，相当于 tail -f 命令的结果（kubectl logs -f pod-name）学习 kubectl 的命令和操作，可以极大地提高在 Kubernetes 集群上的开发和运维效率。掌握这些技巧，对于理解和管理 Kubernetes 集群将大有裨益。
5、kubelet在实现previous时，将pod日志存储在/var/log/pods/podname目录下，且以链接文件形式与docker容器的日志文件关联。同时，它还保留上一个崩溃的容器的日志文件，并通过链接文件指向该文件。使用kubectl previous参数时，系统会读取这个链接文件中记录的日志，即为上次容器崩溃前的记录。
Kubernetes日志查看指南:深入了解容器日志管理技术
查看单个容器日志：Kubernetes提供kubectl工具用于直接访问容器日志。使用命令获取指定容器日志，或配合`-f`选项实现实时追踪。 多个容器日志查看：一个Pod内多个容器时，此操作将输出Pod内所有容器的日志。 标签选择器过滤日志：通过标签选择器筛选特定标签的Pod或容器日志，仅显示所需信息。
docker logs -f my-container // 实时跟踪日志输出 使用Docker管理工具：如果你使用Docker管理工具（如Docker Compose、Kubernetes等），通常可以通过工具提供的命令或界面来查看容器的日志。
K8s 集群的准备步骤、生成mock数据的YAML文件、采集容器日志标准输出和文本文件、配置Logtail采集、设置字段索引与开启日志聚类、基本查询、日志聚类、上下文查询与LiveTail的使用等都进行了详细介绍。Ingress与审计方案的配置也包括了YAML文件示例与日志存储的说明。
如果日志信息不足以定位问题，可以尝试在Pod内部执行“sh”、“bash”或“ash”命令。进入容器内部进行详细检查，使用exit命令退出容器。查看集群级别事件：使用kubectl get events命令获取集群中事件的聚合视图。分析事件信息，了解Pod故障背后的资源状态变化，如节点故障、网络问题等。
日志库选择：考虑使用流行稳定版本的开源日志库，降低入坑风险。日志形态：在容器环境中，应将日志输出到 stdout 或 stderr，便于容器日志查看，但注意性能影响。日志落盘与传输：在 Kubernetes 中，考虑直接传输日志至后端系统，减少落盘与采集过程，提高性能。
Filebeat收集自定义文件日志
本文介绍Filebeat采集容器内部自定义文件日志流程： 部署Kafka和Logstash至Kubernetes集群，将Filebeat的输出指向外部Kafka集群。 创建模拟程序，输出日志至/opt/date.log，给k8s-node02节点打上标签fluentd=true，启动后查看日志内容。
启动Winlogbeat：执行winlogbeat.exe setup命令进行初始化设置，然后使用StartService winlogbeat命令启动Winlogbeat服务。收集CentOS 6系统日志 安装Filebeat：在CentOS 6上通过命令行安装Filebeat，并进行配置。配置输出：在Filebeat的配置文件中，设置输出到Elasticsearch。
Filebeat的主要功能 日志收集：能够监控指定目录或特定日志文件，实时收集日志数据。 数据转发：将收集的日志数据转发至Elasticsearch、Logstash或Kafka等系统，便于后续索引、分析和存储。 内置模块：提供auditd、Apache、Nginx、System和MySQL等多种模块，通过简单命令即可实现通用日志格式的收集、解析和可视化。
Filebeat支持多种输出方式，直接输出到Elasticsearch或通过Logstash格式化日志后传输。通过定义多个输入收集数据，使用不同的fields.tag对日志进行分割，并配置不同conf文件启动多个filebeat实例，实现多组日志的独立采集。
