1，ServiceAccount是怎样工作的？
自动挂载：当创建一个pod时，没有指定serviceAccountName，它会自动使用所在命名空间的default服务账号。盖章好的令牌会被自动挂载到pod内的/var/run/secrets/kubernetes.io/serviceaccount/token路径下。
为pod指定ServiceAccountL:为了提高安全性，最佳实践是为每个不同的应用创建专属的ServiceAccount，并在Pod定义中明确指定。
bash
apiVersion： v1
kind: Pod
metadata:
name: my-app-pod
spec:
serviceAccountName: my-app-sa
containers:
- name: my-app
image:my-app:latest权限最小化原则：创建专属的ServiceAccount后，需要通过RBAC为其授予完成工作所必需的最小权限。例，已告知需要读取pod信息的应用，就只应该被授予get，listPod的权限，而不是所有权限。
2，不同资源对象之间的通信方式
同一节点Pod间通信
依赖：Linux网桥
不同节点Pod间通信
依赖：CNI网络插件（如Flannel，Calico）
Pod与Service通信
依赖：kube-proxy（iptables/IPVS模式）
Kubernetes网络模型的核心可以概括为三条基本"铁律"，所有网络方案都必须满足这些要求：
每个Pod都必须拥有一个独立的IP地址，并且所有Pod都处在同一个扁平的，可以直接连通的网络空间中
任意两个Pod之间都可以直接通信，无论它们是否运行在同一个节点上，都无需网络地址转换
节点与它上面的所有Pod之间可以直接通信，反之亦然
3，pod的常见故障
pending：资源不足，调度约束
running：检查就绪状态：1，就绪探针失败；2，检查Service与网络策略
CrashLoopBackOff：应用崩溃，启动命令错误
ImagePullBackOff：镜像下载失败
unknown
4，不同探针的典型应用场景
存活探针：
用于检测应用运行时出现的死锁或"假死"状态。容器进程仍在，但已无法提供服务，此时需要重启容器来恢复
就绪探针：
应用启动初期：避免在应用完全启动前就介入流量
临时性依赖失效：当容器依赖的后端服务暂时不可用时，可主动标记为"未就绪"，暂时移出流量池，实现自保
启动探针：
专门用于保护启动时间很长的应用。给予应用充足的启动时间，避免因其启动慢而被Liveness Probe误判为失败而陷入无限重启循环
5，ClusterIP无法访问的故障排查
检查Service状态，不正常，检查Service配置，确认Type是否为ClusterIP,确认port和targerPort正确
Service状态正常，检查Endpoints是否正常，Endpoints为空，排查Label Selector匹配，核对Pod Labels与Service selector是否匹配
Endpoints正常，检查网络策略，有策略限制，调整NetworkPolicy
无策略限制，在Pod内测时nslookup；curl ClusterIP,DNS解析失败，排查CoreDNS，连接被拒绝/超时，排查kube-proxy和节点网络
6，Service三种模式的典型应用场景和优缺点
|--------|----------------------------------------------|-------------------------------------|-------------------------------------------------|
| | ClusterIP | NodePort | LoadBalancer |
| 最佳适用场景 | 微服务间内部通信，如前端调用后端API，应用连接数据库。这是最常用，最安全的内部通信方式 | 开发测试环境，临时演示或不支持云负载均衡器的本地环境，用于快速暴露服务 | 公有云环境下的生产系统，需要高可用，高性能和高安全性的外部访问，例如对公网用户开放的Web服务 |
| 优点 | 安全性高，性能好，无额外成本 | 部署简单，无需额外组件；兼容性强，适用于任何环境 | 全自动管理，提供云级的高可用和负载均衡；支持高级功能如SSL终止，健康检查 |
| 限制 | 无法直接从集群外部访问 | 安全性较低；端口管理复杂；不适合大规模生产 | 以来云提供商，在非云环境无法直接使用；会产生额外费用 |
8，流量怎么从Ingress和Service到达Pod
Ingress是一个Kubernetes API对象，它充当的是七层流量的智能路由器和统一入口。它的核心是定义路由规则，而不是直接提供负载均衡器。实际处理流量的是Ingress Controller,它是一个独立的，实现了这些规则的应用程序
Service的核心确实是提供一个稳定的网络端点和服务发现机制，从而抽象和屏蔽后端Pod的动态变化。它在四层主要实现的是对同一服务内多个Pod的负载均衡
它们的关系通常是：外部流量，Ingress，Ingress Controller,Service,Pod
常见的Ingress Controller包括：
Nginx Ingress Controller：最常用的一种，基于Nginx，功能丰富，社区活跃
Traefik：以易用性和动态配置著称
HAProxy Ingress：以高性能和稳定性闻名
云厂商提供的控制器：如阿里云的ALB Ingress，MSE Ingress，华为云的ELB Ingress等，深度集成各自的云负载均衡产品
9，Deployment和Statefulset的应用场景
|--------|------------------------------|---------------------------------|
| | Deployment | Statefulset |
| 典型应用场景 | Web服务器，API服务，无状态微服务，消息队列消费者等 | 数据库集群，分布或协调服务，消息队列等需要稳定网络和存储的应用 |
10，Statefulset的高可用怎么实现？
主从复制：部署一个两副本的Statefulset，并利用初始容器或配置工具，让mysql-1自动向mysql-0同步数据
有序部署/伸缩：Statefulset会按顺序创建Pod，只有前一个Pod完全就绪后才会启动下一个，这避免了集群脑裂
稳定的存储：每个Pod通过VolumeClaimTemplates拥有自己独立的PV/PVC。即使Pod被重新调度到其他节点，也会自动挂载原有的数据卷，保证数据不丢失。
11，Helm是什么？Helm解决了什么问题？
Helm时Kubernetes的包管理工具，类似于Linux系统中的yum或apt。它的核心打包格式叫Chart，一个Chart就是将部署一个应用所需的所有Kubernetes YAML文件进行模板化，参数化后形成的打包文件。
解决的问题：
管理复杂的应用：一个微服务应用可能包含几十个Kubernetes资源文件。Helm将它们组织成一个统一的，可版本化的Cart，实现"一条命令"部署整个复杂应用。
配置漂移与环境差异：通过模板引擎和Values.yaml文件，Helm实现了配置与部署清单的分离。你可以为开发，测试，生产环境准备不同的Vlues文件，使用同一个Chart，通过不同配置轻松部署到不同环境，解决了环境不一致的难题
应用生命周期管理：Helm支持对应用的安装，升级，回滚和删除等全生命周期操作，并保留每次发布的版本历史，是的运维操作清晰可控
打赏链接：
