集群中的pod是什么意思
1、Pod是Kubernetes中一个节点可以运行多少pod的最小调度单位。它可以包含一个或多个容器一个节点可以运行多少pod，并在同一个节点上运行。每个Pod都有一个独立的IP地址，该地址由Kubernetes集群自动分配和管理。Pod在Kubernetes中的作用类似于Docker容器在单机中的作用，是Kubernetes部署和管理微服务的基本单位。Pod在Kubernetes中有着非常重要的作用。
2、Pod是Kubernetes的基本计算单元，它将一个或多个容器封装在一起，并共享相同的名称空间和本地网络。Pod中的容器可以互相通信，仿佛它们在同一台机器上，同时保持一定程度的隔离。Pod被用作Kubernetes的复制单元，确保负载均衡和故障恢复。Pod应保持较小的规模，通常只包含一个主进程和紧密耦合的辅助容器。
3、官方解释一个节点可以运行多少pod：在Kubernetes集群中，Pod是所有业务类型的基础，它是一个或多个容器的组合。这些容器共享存储、网络和命名空间，以及如何运行的规范。在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。
4、Pod一个节点可以运行多少pod：定义：Pod 是 Kubernetes 中最小的可部署计算单元，用于管理一组相关的服务。功能：通过复制多个 Pod 的副本，Kubernetes 实现一个节点可以运行多少pod了服务集群的弹性管理，能够自动扩展或缩减服务实例数量以适应负载变化。通信：Pod 内部的容器通过自己的 IP 和端口进行通信，提高了内部容器间的访问性能。
5、首先，Pod是一个基本的运行单元或组件。在云计算和容器化技术快速发展的背景下，Pod被用作一种运行应用的容器。这种容器不仅包含应用本身，还包含应用运行所需的全部环境。这使得Pod具有可移植性强的特点，可以在不同的计算环境中无缝迁移和运行。其次，Pod也被用作管理大规模应用集群的重要工具。
Kubernetes入门:Pod、节点、容器和集群都是什么?
1、Pod是Kubernetes的基本计算单元，它将一个或多个容器封装在一起，并共享相同的名称空间和本地网络。Pod中的容器可以互相通信，仿佛它们在同一台机器上，同时保持一定程度的隔离。Pod被用作Kubernetes的复制单元，确保负载均衡和故障恢复。Pod应保持较小的规模，通常只包含一个主进程和紧密耦合的辅助容器。
2、在 Kubernetes 中，Pod 是核心概念之一，对于容器和 Pod 之间的关系，我们需要明确理解。首先，Pod 并非实体，而是一个逻辑概念，它在集群上承载和协调容器的执行。Pod 是容器的容器，可以看作是云平台中的虚拟机，而容器则是虚拟机中的用户程序，共享网络、存储和资源，确保内部容器间的高效交互。
3、kubectl：与Kubernetes集群交互的客户端工具。kubeapiserver：提供API服务，管理集群资源和认证。kubecontrollermanager：负责集群资源的自动管理和配置。kubescheduler：动态调度Pod以优化资源分配。etcd：分布式存储系统，用于服务发现和配置共享。kubeproxy：维护Pod与外部网络的连接。
4、容器解耦应用与底层基础设施，简化跨云或OS环境部署。本质上是隔离进程、共享资源的进程集合，通过资源限制与独立文件系统，如内存、CPU与通信隔离，实现Linux研发环境的资源管理。Kubernetes集群中的Pod则由容器构成，形成部署单位，在同一节点上运行。通过Dockerfile脚本构建镜像，本地环境部署。
5、在介绍资源对象之前，了解kubernetes集群的两种管理角色：master和node。master负责整个集群的管理和控制，node是真正的业务工作负载节点。每个node运行的关键进程确保了集群的稳定运行。Pod是kubernetes的核心概念，它包含一个或多个容器，每个容器共享Pod IP。
6、面对容器改造后的进程协作需求，Kubernetes引入了Pod概念，作为容器的集合体，共享IPC、Network、UTS等命名空间，是Kubernetes的基本单位。为解决容器间的协作问题，Kubernetes采用特殊容器（Infra Container）作为PID 1进程，负责申请命名空间并管理子进程，实现容器共享资源和数据。
K8S线上集群排查,实测排查Node节点NotReady异常状态
K8S线上集群Node节点NotReady异常状态的排查方法主要包括以下几点：检查硬件资源：使用df m命令检查磁盘空间，确保有足够的空间供Node节点和Pod使用。使用free命令检查CPU使用率，确保CPU资源未被过度占用。使用top c命令查看CPU使用情况，确保无异常。
在项目中遇到的线上集群问题，特别是Kubernetes （K8S）集群中Node节点状态变为NotReady，导致服务停止的问题，我们进行了一次深入的排查与解决。文章将聚焦于如何有效识别和解决这类问题。首先，让我们了解一下在K8S中Pod的状态。
在搭建Kubernetes（k8s）集群过程中，若遇到节点一直处于NotReady状态问题，通过执行命令查看日志，发现提示信息为[failed to find plugin flannel in path [/opt/cni/bin]]。执行排查步骤，进入指定目录检查，确认flannel插件是否缺失。
一次K8S集群中遇到的Too Many Open Files问题排查，起因是一个运行机器学习推理服务的节点出现Node NotReady异常，通过查看日志发现是因为dockerd进程打开的文件数过多导致。初步怀疑是由于root用户文件限制较小，将限制调整为655360后重启docker进程，但问题并未解决，而是陆续在其他节点上重复出现。
Kubernetes 13 OS： CentOS 2009 Kernel： 94-elelrepo.x86_64 Docker： 6 线上告警提示集群中存在 2-3 个 K8s 节点处于 NotReady 的状态，并且 NotReady 状态一直持续。问题的解决可以通过两种方法，我们先来看看 A 方案。
对k8s控制器DaemonSet的理解
DaemonSet是Kubernetes中用于在每个节点上运行一个Pod副本的控制器。以下是关于DaemonSet的详细理解：主要功能：节点级Pod管理：DaemonSet确保在每个节点上仅运行一个特定的Pod实例。自动部署与回收：当新节点加入集群时，DaemonSet会自动在新节点上创建Pod；当节点被删除时，其上的Pod也会被相应回收。
DaemonSet的运行机制是管理Kubernetes集群中运行的Daemon Pod。其主要功能是在每个节点上仅运行一个特定的Pod实例。当节点加入集群时，该Pod会自动在新节点上创建。相反，当节点被删除时，其上的Pod也相应地被回收。DaemonSet的副本数依赖于工作节点数，无需显式指定。
DaemonSet是Kubernetes提供的一种控制器，其核心职责是在集群中的每个节点或特定节点上确保始终运行着一个Pod的副本。这类控制器常用于部署诸如日志收集器、监控代理或存储守护进程等系统服务，以保持集群的正常运行。
使用Kubernetes管理Kubernetes集群
1、使用token的方式进行访问控制。创建名为adminuser的管理员服务账号，并将其置于kubernetesdashboard名称空间下。绑定集群管理员角色，创建管理员token并登录控制台。创建名为devuser的开发用户账号，为其分配适当的ClusterRole权限，并绑定集群角色。为该用户创建token，并使用此token登录控制台。
2、Kubernetes现在已经可以支持超大规模的集群，单集群可以支撑5000个节点，15万个POD。
3、kubectl是管理Kubernetes集群的命令行工具，它在$HOME/.kube目录下查找名为config的配置文件。若要指定其他kubeconfig文件，可以通过设置KUBECONFIG环境变量或使用--kubeconfig参数。本文将深入探讨Kubernetes中kubectl run的常用命令。kubectl run命令用于创建新的Pod。
4、问题一：在执行kubeadm config images pull时，报错“pulling image： rpc error： cng dial unix /var/run/containerd/containerd.sock： connect： permission denied”。原因可能是kubernetes使用了crictl命令管理CRI，但在配置文件/etc/crictl.yaml中未添加相应的配置，导致无法正常拉取镜像。
5、kubectl是Kubernetes集群的命令行工具，通过它能进行集群管理与容器应用部署。运行kubectl命令的语法示例如下：kubectl命令支持操作包括资源对象的创建、删除、查看等，这些操作的语法和描述信息如下表所示。kubernetes提供多种资源对象，通过这些对象编排容器。下表列出了kubectl支持的资源对象类型与缩略别名。
6、玩转K8s权限控制，通过RBAC和kubeconfig搞定kubectl权限管理的方法如下：理解RBAC机制：核心作用：RBAC是Kubernetes权限控制的核心，允许管理员精确控制用户、ServiceAccount或实体对集群资源的操作权限。实现方式：通过角色、角色绑定和权限规则来实现。优势：提高集群的安全性和管理灵活性。
如何指定pod的运行节点?
方式二：通过指定NodeName。在Pod中配置nodeName字段一个节点可以运行多少pod，直接指派对应节点。示例如下：查看node名称。列出节点名称一个节点可以运行多少pod，例如k8s-master。在Pod中使用nodeName指定此节点。通过kubectl apply创建Pod后，检查Pod是否调度至指定节点。使用nodeName选择节点方式存在局限性。方式三：亲和性和反亲和性。
假设以下场景：有三个Node，分别为1010109，创建Deployments来部署Tomcat应用，指定在107节点上创建Pod。解决方案 nodeName Pod.spec.nodeName将Pod直接调度到指定的Node节点上，会跳过Scheduler的调度策略，该匹配规则是强制匹配。
实战步骤如下： 在集群中为节点添加标签。例如，设置app： goweb-node。 编写goweb应用的Deployment文件。设置Pod的定义，确保与应用需求相匹配。 为Deployment添加nodeSelector字段，指定Pod应部署在具有特定标签的节点上，如app=goweb-node。 验证Pod是否成功调度到具有所需标签的节点。
在实践中，可以通过以下步骤查看特定 pod 的日志。首先，前往运行该 pod 的节点，查找 kubelet 存放的日志文件。这些文件通过数字表示重启次数，例如 2393 和 2394，分别代表第 2393 次和第 2394 次重启后的日志。这些日志文件实际上是链接文件，指向 docker 容器的日志文件。
通过实战操作，可以更直观地理解这些概念。以nodeName调度为例，指定Pod必须运行在特定的节点上。nodeSelector调度则是基于特定的标签选择节点。Node亲和调度则更进一步，通过标签选择特定的Node进行Pod部署。同样，Pod亲和调度则关注Pod之间的关系。
