pod日志到node？ pod日志持久化？
k8s将pod调度到指定节点的几种方式
1、方式二：通过指定nodeName。在POD中配置NodeName字段，直接指派对应节点。示例如下：查看node名称。列出节点名称，例如k8s-master。在Pod中使用nodeName指定此节点。通过kubectl APPly创建Pod后，检查Pod是否调度至指定节点。使用nodeName选择节点方式存在局限性。方式三：亲和性和反亲和性。
2、Node Selector是kubernetes中用于将Pod调度到指定节点的一种机制。以下是关于Node Selector的详细解基本工作原理：Node Selector通过Pod定义中的nodeSelector属性直接指定目标节点。它使用键值对进行匹配，仅需一对匹配即可将Pod调度到目标节点。
3、在实际操作中，假设集群中有两个节点：k8s-0001和k8s-0002。已有工作负载nginx调度至节点k8s-0002，而用户希望工作负载test也调度至k8s-0002。通过调整插件权重，可以实现这一目标。具体步骤包括查看调度日志以了解权重调整后的评分结果，以及通过调整权重实现Pod调度至预期节点。
4、调度流程包括过滤和打分两个步骤。过滤阶段，调度器筛选出满足条件的节点；打分阶段，对筛选出的节点进行评分，最终选择得分最高的节点部署 Pod。节点选择器（nodeSelector）允许用户基于特定标签选择节点。例如，确保某些 Pod 落实在具有特定属性（如 SSD 硬盘）的节点上。
Pods和Nodes
Kubernetes Pods 当你在模块 2 中创建一个Deployment的时候，kubernetes创建了一个 Pod 来放置你的应用实例。Pod是Kubernetes中的一个抽象概念，一个Pod包含了一组应用容器（比如Docker或者rkt）和这些容器共用的资源。
Persistent Volume和Persistent Volume Claim类似Pods和Nodes的关系，创建Pods需要消耗一定的Nodes的资源。而Persistent Volume则是提供了各种存储资源，而Persistent Volume Claim提出需要的存储标准，然后从现有存储资源中匹配或者动态建立新的资源，最后将两者进行绑定。上面已经提到了创建PV的配置文件。
以下是一些关键步骤和技巧： **检查集群状态**：首先，使用`kubectl get nodes`和`kubectl get pods --all-namespaces`等命令来查看节点和Pod的状态，确保所有组件都在正常运行。 **日志检索**：使用`kubectl logs`命令来检索Pod的日志，以了解应用程序的行为和可能的问题。
下载kubectl并将其添加到系统路径：curl Lo kubectl kubectlurl。进行版本验证和所有命名空间pods的检查。在集群运行期间，可以通过以下命令检查和管理：命令行辅助：使用minikube help查看帮助信息。使用minikube status检查集群状态。使用kubectl get nodes查看节点信息。
使用 kubectl get nodes 命令列出集群中的所有节点。使用 kubectl drain node name 命令驱逐指定的节点。该命令会标记节点为不可调度，并安全地删除节点上的所有 Pods。一旦 kubectl drain 命令返回且没有报错，就可以下线该节点（或在云平台上删除支持该节点的虚拟机）。
Node工作负载异常,一部分pod状态为Terminating
总结：当Node工作负载异常，一部分Pod状态为Terminating时，应首先检查节点状态和集群资源情况，然后尝试使用自动或手动方法删除Terminating状态的Pod。同时，考虑优化发布策略以减少服务中断的风险。
Pod删除过程中，如果节点异常，Kubernetes会通过kube-controller-manager和kubelet的驱逐机制调整工作负载。kube-controller-manager负责大范围驱逐，而kubelet则处理细粒度的资源管理。Terminating状态的Pod，可以通过kubectl命令删除，或在资源压力下，kubelet直接驱逐。
K8S线上集群排查,实测排查Node节点NotReady异常状态
1、在项目中遇到的线上集群问题，特别是Kubernetes （K8S）集群中Node节点状态变为NotReady，导致服务停止的问题，我们进行了一次深入的排查与解决。文章将聚焦于如何有效识别和解决这类问题。首先，让我们了解一下在K8S中Pod的状态。Pod状态多样，从创建到终止，每一个状态都清晰地显示了当前Pod的生命周期阶段。
2、在搭建Kubernetes（k8s）集群过程中，若遇到节点一直处于NotReady状态问题，通过执行命令查看日志，发现提示信息为[failed to find plugin flannel in path [/opt/cni/bin]]。执行排查步骤，进入指定目录检查，确认flannel插件是否缺失。
3、一次K8S集群中遇到的Too Many Open Files问题排查，起因是一个运行机器学习推理服务的节点出现Node NotReady异常，通过查看日志发现是因为dockerd进程打开的文件数过多导致。初步怀疑是由于root用户文件限制较小，将限制调整为655360后重启docker进程，但问题并未解决，而是陆续在其他节点上重复出现。
4、常见错误状态：ImagePullBackOff 在Pod调度到目标节点后，节点需要拉取Pod所需镜像。
聊聊kube-scheduler如何完成调度和调整调度权重
1、首先，当用户通过api或kubectl创建Pod时，kube-apiServer将请求信息存储于etcd中。Kube-scheduler通过watch机制监听apiserver，获取待调度的Pod列表。接着，Kube-scheduler逐个尝试为每个Pod分配Node。
2、调度器（kube-scheduler）的任务是将未调度的 Pod 分配到合适的节点。它通过监测机制发现新创建但未调度的 Pod，然后基于一系列规则进行选择。调度流程包括过滤和打分两个步骤。过滤阶段，调度器筛选出满足条件的节点；打分阶段，对筛选出的节点进行评分，最终选择得分最高的节点部署 Pod。
3、在Kubernetes 项目中，默认调度器（default scheduler）的主要职责，就是为一个新创建出来的 Pod，寻找一个最合适的节点（Node）。 而这里“最合适”的含义，包括三层： 所以在具体的调度流程中，默认调度器会首先调用一组叫作 Predicate 的调度算法，来检查每个 Node。
4、首先，karmada-scheduler 是核心调度器，它负责将 K8S 的原生 API 资源（包括自定义资源 CRD）调度到各个集群。与传统的 kube-scheduler 相比，karmada-scheduler 采用插件机制，通过 filter 和 score 扩展点，筛选并打分各集群，最终根据评分决定资源的分配。
5、kube-scheduler 是 Kubernetes 集群的默认调度器，并且是集群控制面（master）的一部分。对每一个新创建的Pod或者是未被调度的Pod， kube-scheduler 会选择一个最优的Node去运行这个Pod。然而， Pod 内的每一个容器对资源都有不同的需求，而且Pod本身也有不同的资源需求。
简述Kubernetes中,如何使用EFK实现日志的统一管理?
在Kubernetes集群环境中，通常一个完整的应用或服务涉及组件过多，建议对日志系统进行集中化管理，通常采用EFK实现。
查看单个容器日志：Kubernetes提供kubectl工具用于直接访问容器日志。使用命令获取指定容器日志，或配合`-f`选项实现实时追踪。 多个容器日志查看：一个Pod内多个容器时，此操作将输出Pod内所有容器的日志。 标签选择器过滤日志：通过标签选择器筛选特定标签的Pod或容器日志，仅显示所需信息。
应用直接输出到标准输出：在K8s中，Pod内的应用可以直接将日志输出到标准输出或标准错误输出。Kubernetes会将这些输出自动收集并存储到节点的日志文件中，通常可以通过kubectl logs命令查看。应用输出到容器指定目录，通过filebeat收集：应用可以将日志输出到容器内的指定目录。
功能：作为轻量级日志收集工具，适用于容器内的自定义日志收集。部署方式：通常通过DaemonSet部署在Kubernetes集群中。特点：能减轻Elasticsearch的压力，但同样依赖Elasticsearch进行日志存储。Loki：开发背景：由Grafana Labs开发。功能：轻量级日志聚合系统，用于收集和存储日志数据。
