1，什么是K8S？
Kubernetes是一个开源的容器编排平台，用于自动化容器化应用的部署，扩展和管理，其核心价值在于解决了容器化应用在分布式环境中的运维复杂性
2，pod和容器的关系是什么？
简单来说，Pod的状态由它的内部容器的状态决定，一个容器从启动到终止的历程，会驱动Pod状态的变化
3，kubenetes的master节点上都有什么平面组件？
Kube-apiserver
核心职责：提供了Kubernetes集群的Restful API接口，是所有资源操作的唯一入口，所有组件间的通信都要经过它
关键功能：认证预授权：验证请求者的身份并检查其是否有权限执行操作
准入控制：子啊资源持久化之前，进行校验或更改
数据桥梁：作为所有其他组件与etcd交互的中介，确保数据的一致性和安全性
kube-controller-manager
核心职责：运行着一系列控制器，这些控制器持续监控集群的状态，确保系统当前状态向用户定义的期望状态收敛
4，Deployment的意义和作用是什么？
定义：Deployment是Kubernetes之内用于管理Pod副本的控制器，它不是一个"服务"，而是一种工作负载资源
作用：你通过创建一个Deployment来描述"我希望这个应用始终有3个副本在运行"。Deployment控制器会保证集群中始终保持指定数量的，复合模版的Pod副本，它还负责实现滚动更新和回滚，简单说，Deployment是Pod的"管理员"。
5，Statefulset有什么作用是什么？
Statefulset专门为有状态应用设计，它提供了以下关键特性：
1，稳定的，唯一的网络标识：Statefulset创建的Pod拥有固定的名称和对应的DNS记录，无论Pod如何重新调度，另外应用都能通过这个固定的地址找到它，这对于构建数据库主从集群至关重要，因为从节点需要知道主节点的稳定地址
2，稳定的，持久的存储：Statefulset使用volumeClaimTemplates为每个Pod自动创建独立的PersistentVolumeClaim。即使·Pod被重新调度到另一个节点，它仍然会挂载到同一个数据卷，从而保证数据的持久化和一致性
3，有序的部署和扩缩容：Statefulset会按顺序创建Pod，并且会等待前一个Pod成功运行并就绪后，再创建下一个，这在部署数据库集群时非常有用，可以确保主节点先启动并完成初始化，再从再从节点依次加入
6，Deployment和Statefulset有什么差别？
|----------|-------------------------------|-----------------------------------|
| 特性 | Deployment | Statefulset |
| 设计目标 | 管理无状态应用，Pod是可互换的 | 管理有状态应用，Pod是唯一且有身份的 |
| Pod网络标识 | 不固定，Pod名称随机生成，重启后可能变化 | 稳定且唯一，Pod名称按固定顺序生成，重启后不变 |
| Pod存储 | 所有Pod实例通常共享存储或使用临时存储，不保证数据持久性 | 每个Pod拥有独立且稳定的持久化存储，Pod重建后仍能挂载原数据卷 |
| 部署/扩缩容顺序 | 并行创建或删除所有Pod，速度快 | 严格有序创建/扩容，按降序删除/缩容 |
8，Kubernetes出现故障的排查思路是什么？
|----------|----------------------------------|--------------------------------------|
| 排查层面 | 关键检查点 | 常用命令/工具 |
| Pod/容器层面 | Pod状态，容器资源限制 | kubectl get podskubectl describe pod |
| 控制平面 | kube-apiserver,etcd等组件的响应延迟和资源使用 | 集群监控 |
| 网络 | 服务发现，网络策略，Service/Ingress配置 | kubectl get svc,nslookup,网络监控工具 |
| 存储 | 持久卷的I/O性能，存储类配置 | kubectl get pv,kubectl get pvc |
kubernetes集群端排查
Ingress资源配置是否正确：kubectl get ingress
查看Ingres控制器记录：kubectl logs 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的targetPort是否一致
资源限制：检查Pod是否因CPU/内存不足而被限流
9，Configmap和Secret的差别是什么？
|------|-------------------|----------------------------------------------|
| 特性 | Configmap | Secret |
| 设计目的 | 存储和管理非敏感的，明文的配置数据 | 存储和管理敏感信息，如密码，令牌，密钥等 |
| 数据编码 | 数据可以是明文 | 数据默认以Base64 编码形式存储 |
| 典型内容 | 应用配置文件，环境变量，命令行参数 | 数据库密码，API密钥，TLS证书，镜像仓库认证信息 |
| 安全性 | 数据以明文形式存储在etcd中 | 同样以未加密方式存储在etcd中，但多了Base64编码层，需额外启用静态加密以确保安全 |
10，PV,PVC,StorageClass三者的关系是什么？
三者关系总结：PVC是用户对存储的需求声明，PV是实际的存储资源，StorageClass是自动创建PV的模板，Pod通过PVC申请存储，PVC根据StorageClass自动创建或匹配现有PV，最终实现存储资源的按需分配和自动化管理
11，PVC创建过程之内StorageClass的作用
用户提交PVC,未指定Storageclass，静态供给，管理员预先创建PV，系统匹配PVC与PV，绑定成功
用户提交PVC，指定Storageclass，动态供给，系统检测到PVC指定了
静态供给：集群管理员需要手动预先创建多个PV，当用户创建PVC后，kubernetes的控制平面会根据PVC中声明的需求来寻找匹配的PV进行绑定，如果抄不到匹配的PV，PVC一直处于pending状态
动态供给：这种方式更自动化，也是生产环境的推荐做法，管理员只需提前创建好Storageclass，当用户创建指定了storageclassname的PVC时，Kubernetes就会自动触发相应Storageclass所定义的存储插件，动态的创建出一个合适的PV与该PVC绑定，这大大减少了管理员的运维工作量、
打赏链接：
