1，Node节点不可达的原因
检查节点基础状态，节点不可达，排查网络连通性，检查网络插件或检查防火墙/安全组规则或检查节点主机名/IP变化
节点可达，检查Kubelet服务状态，服务异常，重启kubelet，验证服务状态
服务正常，检查系统资源与组件，资源不足/组件异常，针对性释放资源或修复组件，验证节点状态回复
资源与组件正常，深入分析Kubelet日志，根据具体错误信息修复
2，Pod处于CrashLoopBackOff状态
第一步：快速信息收集kubectl describe pod kubectl logs --previous，日志是否明确指出错误原因？是，根据日志直接修复
否/日之为空，分层系统检查，镜像与构建层，镜像拉取失败ErrImagePull/ImagePullBackOff，验证镜像与启动命令docker run <img>,容器运行时层，资源限制过小OOMKilled，调整资源限制检查PVC挂载
应用与配置层，环境变量/ConfigMap错误，应用依赖未就绪，校验配备，检查网络连通性，添加Init Container，健康检查层，探针配置不当，误判容器状态，优化探针参数，如initialDelaySeconds
网络解决
3，存活探针和就绪探针的差别
| 特性 | 存活探针 | 就绪探针 |
| 核心目标 | 检查容器应用是否正在运行 | 检查容器应用是否已准备好接受请求 |
| 探测失败后果 | 重启容器 | 将Pod从Service的Endpoint列表中移除，暂停向其发送流量 |
| 关键问题 | 否存活？就是应用 | 应用是否准备好处理外部请求？ |
| 适用场景 | 检测应用死锁，进程僵死但未退出等无法继续提供服务的情况 | 应用启动缓慢，依赖服务暂时不可用，处理临时高负载 |
4，资源限额requests和limits的差别
| 参数 | 核心作用 | 影响的组件 | 关键后果 |
| requests | 定义容器需要保障的最小资源量，及其“基本工具” | kube-scheduler | 决定Pod是否被调度到某个节点，调度器只考虑节点上已分配的资源之和，而非实时使用量 |
| imits | 定义容器允许使用的最大资源量 | kubelet | 限制容器在运行时对资源的使用，防止其耗尽节点资源，影响其他Pod |
5，Ingress和Service的差别
| 特性 | Ingress | Service |
| 网络层级 | 应用层，重要处理HTTTP/HTTPS流量 | 传输层，主导处理TCP/UDP流量 |
| 核心功能 | 基于域名和路径的复杂路由，SSL/TLS终止，统一入口 | 服务发现，负载均衡，提供稳定的网络段点 |
| 工作抽象 | 定义路由规则，需Ingress控制器实现 | 定义服务访问点，由Kube-Proxy组件达成 |
| 典型场景 | 为多个Web服务提供统一的域名入口，例如路由到不同后端 | 暴露数据库等非HTTP服务，或应用于集群内布微服务间的通信 |
选择Service的情况：需要暴露一个非HTTP协议的服务。在测试或开发环境中，需要快速简单的暴露服务。应用程序不需基于域名或路径的艰难路由
生产环境的标准做法。需要配备HTTPS和SSL/TLS终止。需要高级路由特性，如重写，认证，限流等就是选择Ingress的情况：需要为多个HTTP/HTTPS服务提供统一的入口，并希望通过域名和路径区分它们。这
6，StorageClass在PVC创建后配备的作用？
开发者无需关心底层存储的具体实现细节。它们只要求声明“我需要一个10Gi大小，许可读写的存储空间。这提升了应用配置的可移植性，同一份应用配置可以在不同基础设施的Kubernetes集群上运行
管理员无需为每个应用需求手动创建和配置PV。动态制备实现了按需分配，极大地减少了管理开销，是存储资源能够像计算资源一样被灵活，弹性地调度和回收
8，StorageClass的作用在哪里？
StorageClass定义了创建PV的模板和方式。它就像一个“菜单”，描述了可以提供何种类型和质量的存储
provisioner字段，它指定了用于创建PV的存储插件就是其核心
依据StorageClass，管理员可以定义不同特性的存储“类别”，用户只需在PVC中指定得的类别即可
用户建PVC指定StorageClass与需求，PV控制器监听到PVC，PVC是否指定StorageClass，否，进入静态供给模式，在现有PV池中查找匹配的PV，找到匹配PV，否，PVC保持Pending状态
是，进入动态供给模式，PV控制器调用相应存储插件，Provisioner自动创建对应的PV对象，绑定PVC与PV，Pod调度到某节点并引用该PVC，AD控制器/Volume Manager将存储卷挂载到节点，kubecl将卷挂载到Pod内容其指定路径
9，角色控制的核心思想是？
定义角色，继而将角色绑定给主题
10，Role，Clusterrole，Rolebinding，Clusterrolebinding的异同
| Role | 定义在特定命名空间内的权限规则，例如授予对default命名空间中Pod的读写权限 |
| Clusterrole | 定义集群范围内的权限规则。其权限可以作用于：1，集群资源2，非资源端点3，跨所有命名空间的资源 |
| Rolebinding | 将权限授予特定的主体。它可以在一个命名空间内绑定两种角色：1，Role：此时权限范围被限定在该Role所在的命名空间。ClusterRole：此时会将ClusterRole的权限限制在RoleBinding所在的命名空间内生效。这是一种重点的权限复用机制 |
| ClusterRoleBinding | 将集群级别的权限授予主体，它只能引用 |
11，灰度发布的实现方法
在K8s中实现灰度发布有多种方法，复杂度和灵活性不同：
基础方法：可以创建两个具有相同标签选择器的Deployment，分别管理新版本和旧版本的Pod。然后，通过手动调节这两个Deployment的副本数来粗略的控制流向新版本Pod的流量比例。同时，也可以结合Service Mesh或Ingress控制器提供更精细地按流量比例或按内容的路由规则，将特定比例的流量分发到带有特定标签的新版本Pod上
打赏链接：
