一、Kubernetes 资源查询与层级概念
1.1 Pod 基础查询操作
-
基础查询命令：
kubectl get pod，用于获取Pod资源，默认查询当前默认命名空间（default）下的Pod -
命名空间指定：通过
-n <命名空间名>参数指定查询目标命名空间，比如kubectl get pod -n kube-system查询kube-system命名空间下的Pod，默认不加-n等同于-n default -
输出字段含义：
-
名称列：Pod的资源名称
-
就绪状态列：格式为
就绪容器数/总容器数，如0/2表示Pod内共2个容器，0个处于就绪状态 -
状态列：如
Running表示运行中、ContainerCreating表示容器正在创建中 -
后续字段：重启次数、运行时长、所在节点、Pod IP等
1.2 资源层级特性
Kubernetes资源分为命名空间级别和集群级别，两类资源的查询特性完全不同：
命名空间级别资源
-
典型代表：Pod、Deployment、Service、ConfigMap等
-
特性：不同命名空间下的资源相互隔离，同一类资源在不同命名空间下查询结果不同
-
特殊命名空间：
kube-system是Kubernetes集群系统组件的专属命名空间，存放调度器、kube-controller-manager、kube-apiserver、etcd、coredns、kube-proxy、calico（CNI网络插件）等核心组件，禁止在该命名空间下执行随意操作
集群级别资源
-
典型代表：Node（节点）、ClusterRole、PersistentVolume等
-
特性：不受命名空间限制，在任何命名空间下查询同一集群级别资源，返回结果完全相同
-
类比：如同查询不同院系的所属学校，无论哪个命名空间下的集群级别资源都属于集群本身，结果一致
二、常用 kubectl 核心命令详解
2.1 kubectl get 扩展选项
-
-A/--all-namespaces：查看所有命名空间下的指定资源，-A是--all-namespaces的缩写，执行后会额外输出「命名空间」列，标识资源所属命名空间 -
-o wide：展示资源的扩展信息，额外输出Pod的IP地址、调度节点等字段 -
--show-labels：展示资源关联的标签信息 -
-l <标签选择器>：根据标签筛选资源，支持key（筛选含该key的所有资源）、key=value（筛选key对应值为value的资源）格式，比如-l app=myapp筛选标签app值为myapp的Pod
2.2 进入容器执行命令：kubectl exec
-
基础语法：
kubectl exec -it <Pod名称> [-c <容器名称>] -- <执行的命令> -
参数说明：
-
-i：保持标准输入打开，开启交互模式 -
-t：分配伪TTY终端，支持交互式命令 -
-c <容器名称>：指定要进入的目标容器名称，当Pod内仅有一个业务容器（排除pause容器）时可省略该参数 -
--：命令分隔符，后面跟容器内要执行的操作，比如bash进入容器终端、ls查看目录等
2.3 查看资源详细信息：kubectl describe
-
基础语法：
kubectl describe <资源类型> <资源名称> -
作用：输出资源的全量描述信息，包含元数据、状态、事件等板块，排错时优先查看「Events（事件）」板块的报错内容
2.4 查看容器日志：kubectl logs
-
基础语法：
kubectl logs <Pod名称> [-c <容器名称>] -
作用：获取指定容器的标准输出日志，等同于Docker的
docker logs命令，用于排查容器运行异常
三、Pod 核心特性与容器交互
3.1 Pod 的本质
Pod是Kubernetes中最小的调度单元，本质是多个容器的集合，集合内的容器共享网络、IPC、PID命名空间：
-
每个Pod默认会携带一个
pause（infra）容器，用于初始化网络命名空间、共享网络栈，其他业务容器均与pause容器共享网络资源 -
同一Pod内的容器可以通过
localhost互相访问，共享端口、存储等资源
3.2 容器交互验证
-
通过
kubectl get pod -o wide获取Pod的IP地址，直接通过curl <Pod IP>即可访问Pod内的业务服务 -
进入Pod内的业务容器修改文件后，再次访问服务可以看到修改生效，验证Pod内容器共享存储与网络
四、资源清单创建与排错实战
4.1 资源清单创建
-
基于之前编写的Pod资源清单，可快速创建新的Pod实例：修改资源名称、业务容器镜像、容器名称等字段后，执行
kubectl create -f <资源清单文件路径>即可完成创建 -
示例：修改后的资源清单包含两个业务容器
myapp-1（基于nginx 1.0镜像）、myapp-2（基于自定义nginx 2.0镜像）
4.2 Pod 重启机制说明
-
若业务容器前台进程退出（比如
sleep 3600休眠结束后进程终止），Kubernetes会按照资源清单的期望状态，创建新的容器实例替换已终止的容器，因此会出现重启计数，该过程本质是容器重建而非原有容器重启 -
若Pod被手动删除，无额外控制器守护时无法自动恢复，后续学习的控制器可实现Pod的自动恢复
4.3 排错实战：端口冲突问题
-
问题现象：创建修改后的Pod后状态变为
Error，重启次数持续增加 -
排错步骤：
-
优先执行
kubectl describe pod <Pod名称>查看「Events」板块，若无明确集群级报错则进入下一步 -
执行
kubectl logs <Pod名称> -c <容器名称>查看容器日志，定位到报错信息为地址已被占用 -
根因分析：同一Pod内的容器共享网络命名空间，
myapp-1默认绑定80端口，myapp-2同样绑定80端口，同一网络命名空间下不允许存在两个相同端口的监听，因此myapp-2启动失败，Pod持续重启
- 排错思路总结：优先查看describe的事件报错→其次查看容器日志→最后排查端口、存储等资源冲突问题
AI 总结
本小节围绕Kubernetes Pod资源的操作与特性展开，首先讲解了Pod查询的命名空间逻辑、命名空间/集群级别资源的差异，其次详解了kubectl get/exec/describe/logs等核心常用命令的使用方法，然后明确了Pod作为多容器集合的核心特性与交互逻辑，最后通过资源清单创建、重启机制说明、端口冲突排错三个实战场景，帮助学习者掌握Kubernetes基础资源操作的完整流程与排错思路。