1，pod出现问题需要怎么检查
|----------|-----------------------------|---------------------------------------|
| 排查层面 | 关键检查点 | 常用命令/工具 |
| Pod/容器层面 | Pod状态，容器资源限制 | kubectl get pods，kubectl describe pod |
| 控制平面 | kube-apiserver | 集群监控 |
| 网络 | 服务发现，网络策略，service/ingress配置 | kubectl get svc，nslookup，网络监控工具 |
| 存储 | 持久卷的I/O性能，存储类配置 | kubectl get pv，kubectl get pvc |
kubernetes集群端检查 ingress控制器
检查ingress资源是否配置正确 kubectl get ingress
查看ingress控制器日志： kubectl logs -n ingress-nginx
service类型：确认service类型为LoadBalancer或NodePort External IP:使用kubectl get svc检查External IP是否已分配且状态正常
端口映射：验证Service targetport是否正确映射到Pod的容器端口
Pod状态：使用kubectl get pods检查Pod是否处于Running状态且READY为1/1
Pod日志：查看应用日志： kubectl logs
Pod事件：使用kubectl describe pod <pod-name>查看Pod创建和运行过程中的事件
容器健康检查：检查LivenessProbe和readinessProbe配置是否正确
应用配置：确认应用监听的端口与Service的TargerPort一致
资源限制：检查Pod是否因CPU/内存不足而被限流
2，为什么需要Pod？
为什么需要Pod：Pod的设计解决了容器编排中的几个核心问题：
1，资源共享与通信：同一Pod内的容器可以通过localhost直接通信，共享存储卷，避免了复杂的网络配置
2，生命周期管理：Pod作为原子单元进行调度，扩展和故障恢复，简化了管理复杂度
3，应用组合：支持"边车模式"，可以在主应用容器旁运行辅助容器
4，资源隔离：Pod级别的资源限制和请求，确保应用间的资源隔离
3,简述kube-proxy的作用
1，监听与同步：kube-proxy持续监听kubernetes API Server，实时感知集群中Service和Pod的变化
2，配置数据平面：一旦有变化，kube-proxy就会在本机更新网络转发规则，确保发往Service的流量能被正确导向后端健康的Pod，目前主流通过两种模式实现：
iptables模式：kube-proxy在节点上设置iptables规则。当流量指向Service的ClusterIP和端口时，这些规则会以随机方式将数据包重写为后端某个Pod的IP和端口
IPVS模式:对于大规模集群，可以配置kube-proxy使用IPVS。IPVS是工作在内核态的负载均衡技术，支持更丰富的调度算法，并且有更高的网络吞吐量和更低的规则同步延迟
3，流量转发：最终，无论是来自集群内不还是外部通过NodePort或LoadBalancer的请求，到达节点后，都会根据上述规则被转发到实际提供服务的Pod
4，简述无状态服务包括什么
需要持续运行的服务，如web服务器，数据库，API服务等
批处理任务。定时作业等，希望任务失败后能自动重试，但成功完成后即结束
一次性任务，例如数据备份，测试任务等，希望任务执行后无论结果如何都不在重复运行
5，简单描述service资源对象的作用
服务发现:当你创建一个Service并指定标签选择器时，Kubernetes API Server会持续监控集群中匹配这些标签的Pod，这些Pod的IP地址和端口信息会被动态更新到与Service关联的Endpoints对象中
集群内的DNS服务会为Service分配一个DNS名称，格式为<service-name>.<namespace>.svc.cluster.local。集群内的应用可以通过这个域名解析到Service的ClusterIP.
负载均衡Lkube-proxy运行在每个节点上，监听API Server中Service和Endpoints的变化。
根据配置的模式，kube-proxy会在本节点上设置相应的网络规则。
当有流量发往Service的虚拟IP或NodePort时，这些网络规则会拦截请求，并根据负载均衡算法将其转发到后端某个健康的Pod的targetPort上
6，简述Service的不同模式
为了实现服务发现和内外访问，需要设计不同的Service类型。：
前端服务：使用LoadBalancer或NodePort类型的Service。LoadBalancer可与云提供商集成，自动分配一个外部IP地址，使公网用户能够访问前端应用，是实现外部访问的推荐方式
后端API服务：使用ClusterIP类型的Service，这是默认类型，为服务提供一个仅在集群内部可访问的虚拟IP，用于前端Pod与后端API Pod之间的内部通信
数据库/缓存服务：使用Headless Service。这种Service不会分配ClusterIP,而是通过DNS直接返回后端Pod的IP地址，这对于statefulset至关重要，它为每个Pod提供了唯一的，稳定的DNS域名，格式为<pod-name>.<service-name>.<namespace>.svc.cluster.local
8，简述Service的几种不同模式的意义
ClusterIP：这是集群内部服务间通信的首选，它分配一个仅在集群内可以访问的虚拟IP，例，您的后端API服务可以被前端服务通过ClusterIP稳定访问
NodePort：在ClusterIP基础上，在每个节点上开放一个静态端口，范围通常在30000-32767，这使得外部客户端可以通过任意节点IP:NodePort访问服务。它常作为开发测试或简单外部访问的方案
LoadBalancer：在NodePort基础上，集成云厂商的负载均衡器，提供一个外部IP地址，这是在生产环境中将服务直接暴露到公网的常见方式。云负载均衡器还能提供更高级的功能
9，简单介绍rolebing和clusterbing的差别
主体进行绑定，rolebinding，引用role，仅生效于命名空间；与引用clusterrole，权限生效于rolebinding所在命名空间
主体进行绑定，clusterrolebinding，引用clusterrole权限生效于整个集群范围
10，Pod处于Pending状态可能出现的原因和解决方案
查看Pod事件，分析事件信息
1，提示资源不足，检查节点资源解决方案 扩容节点/调整请求/清理资源
2，提示节点选择问题，检查节点污点与标签，解决方案 添加容忍/调整亲和性/添加标签
3，提示其他错误，根据具体错误深入排查，解决方案 检查PVC/Quota。镜像配置
问题解决
11，滚动更新如何保证服务可用性？
滚动更新的设计通过以下几种机制确保了在更新期间的高可用性：
1，渐进式替换：整个过程是"先创建，后删除"，确保了在任何时刻都有一定数量的Pod在处理请求。
2，就绪探针：Kubernetes依赖Pod的readinessProbe来判断一个新Pod是否已经准备好接受流量。只有当新Pod的就绪探针检测成功时，它才会被纳入Service的负载均衡池，同时旧Pod才会被终止。这避免了将流量导向尚未准备好的新Pod。
3，可控的更新节奏:maxSurge和maxUnavailable参数让管理员可以精细控制更新速度和对服务可用性的影响。例如，在生产环境中，可以设置maxUnavailable：0和maxSurge:1,以实现最平滑，影响最小的更新。
打赏链接：
