K8S安全问题
第 1 套：K8s 安全（RBAC/ServiceAccount/ 准入控制）口述面试题
Q1：RBAC 是什么？
A：Role-Based Access Control，基于角色访问控制。用来控制用户 / ServiceAccount 对 K8s 资源的增删改查权限。核心四组件：Role、ClusterRole、RoleBinding、ClusterRoleBinding。
- Role：命名空间内权限；ClusterRole：集群全局权限。
- RoleBinding：命名空间内绑定；ClusterRoleBinding：集群级别绑定。
Q2：ServiceAccount 是什么？和 User 账号区别
A：ServiceAccount 是Pod 内部使用的账号，属于命名空间资源，自动生成 secret 存放 token。
User 是给人使用；ServiceAccount 给 Pod 程序调用 apiserver。默认 default SA。
Q3：为什么不建议用 default ServiceAccount？
A：default SA 默认有基础权限，生产建议新建最小权限 SA，遵循最小权限原则。不需要访问 apiserver 的 Pod 直接禁用自动挂载 SA token。
Q4：什么是准入控制器 Admission Controller？
A：apiserver 在认证鉴权之后、写入 etcd 之前执行的拦截逻辑，分两类：
- 变更准入（Mutating）：修改请求内容，比如自动注入 sidecar
- 校验准入（Validating）：校验配置，不符合直接拒绝，比如 Pod 安全策略校验
Q5：PodSecurity（PS）介绍，替代旧的 PodSecurityPolicy
A：K8s 原生 Pod 安全标准，三个级别：
- Privileged：无限制，最高权限
- Baseline：禁止高危特权配置，生产基础推荐
- Restricted：严格限制，最小权限，安全要求高业务
通过命名空间打标签启用，替代废弃的 PSP。
Q6：Pod 安全常见风险点
A：特权容器 privileged、挂载宿主机路径 hostPath、使用 root 用户运行容器、capabilities 权限过多。
Q7：证书体系在 K8s 作用？
A：集群组件间 TLS 通信加密。apiserver 证书、kubelet 证书、etcd 证书；证书过期会导致集群组件通信失败。
Q8：RBAC 排查思路，权限不足报错
A：
- 确认账号：用户 / Pod 的 ServiceAccount
- 查 Role/ClusterRole，确认资源 verb 权限（get/list/watch/create 等）
- 检查 Binding 绑定是否正确，命名空间是否匹配
第 2 套：K8s 资源管理、Limit/Request、HPA、VPA
Q1：requests、limits 作用，OOM 行为
A：
requests：调度器判断节点资源是否充足的依据；
limits：资源硬上限。
CPU 超限：容器被限流；内存超限：容器直接 OOM kill。
Q2：QoS 三种类别，驱逐顺序（回顾 + 深化）
A：
- Guaranteed：requests=limits，优先级最高，最后驱逐
- Burstable：仅配置 requests，中间
- BestEffort：无 requests/limits，最先被驱逐
Q3：HPA 是什么？
A：Horizontal Pod Autoscaler，水平扩缩容，增减 Pod 副本数。基于指标（CPU / 内存 / 自定义 metrics）自动扩缩。
HPA 控制器循环查询 metrics-server 获取指标，调整 Deployment 副本。
Q4：HPA 稳定窗口（stabilizationWindowSeconds）作用
A：防止指标瞬间抖动导致频繁扩缩容，缩容有冷却窗口，避免震荡。
Q5：VPA 是什么？和 HPA 区别
A：Vertical Pod Autoscaler，垂直扩缩容，调整 Pod 内容器的 CPU、内存 requests/limits，不改变副本数量。
HPA：变 Pod 数量；VPA：改单个 Pod 资源规格。
Q6：LimitRange 资源限制
A：命名空间级别，给 Pod / 容器设置默认 requests/limits，限制单 Pod 最大最小资源。
Q7：ResourceQuota 资源配额
A：命名空间级资源总量限制，限制该 ns 下 Pod、PVC、CPU 内存总使用量，防止资源耗尽。
Q8：HPA 不触发扩容排查
A：metrics-server 是否正常；指标是否采集成功；HPA 目标阈值配置；最小 / 最大副本限制。
第 3 套：K8s 日志、监控、事件、Metrics Server
Q1：K8s 日志采集方案，容器日志原理
A：容器日志输出到 stdout/stderr，kubelet 写入宿主机日志文件。
采集方案：
- Node 级采集：fluentd/filebeat daemonset，采集宿主机容器日志
- Sidecar 采集：Pod 内边车读取 emptyDir 日志文件
日志建议输出 stdout，避免日志落盘到容器内。
Q2：Metrics Server 作用
A：集群内置指标采集组件，收集节点、Pod 的 CPU / 内存指标；kubectl top依赖它，HPA 也依赖。只采集核心资源指标，不是完整监控。
Q3：Prometheus + K8s 监控方案
A：Prometheus 主动拉取指标。
采集目标：kube-state-metrics（K8s 资源状态指标）、node-exporter（宿主机硬件）、业务容器指标。
服务发现：Prometheus 基于 K8s SD 自动发现 Pod/Service。
Q4：Event 事件是什么？
A：集群事件，记录资源变更、警告，如 Pod 调度失败、镜像拉取失败。kubectl get events。事件有保存期限，不做长期存储，生产需要持久存储。
Q5：日志级别：容器日志轮转怎么处理？
A：kubelet 自带日志轮转，限制日志文件大小和数量，防止宿主机磁盘被日志打满。
Q6：kube-state-metrics 作用
A：不采集监控指标，把 K8s 资源对象状态转换成 Prometheus 指标（副本数、Pod 状态、PVC 状态等）。
Q7：监控排查：kubectl top pod 无数据
A：检查 metrics-server pod 是否 running；证书；网络；metrics-server 访问 kubelet 权限。
Q8：日志常见问题：日志丢失
A：容器频繁重启日志轮转；stdout 输出缓冲；磁盘满；日志采集程序崩溃。
第 4 套：K8s 升级、备份恢复、集群维护
Q1：K8s 集群升级思路，控制面优先还是节点优先？
A：先升级控制平面组件，再逐台升级 worker 节点，滚动升级，业务不中断。版本只能小版本递进升级，不能跨大版本直接跳。
Q2：etcd 备份和恢复怎么做？
A：备份：etcdctl snapshot save；恢复：停止 etcd，清空数据目录，用快照恢复。
要点：定期备份；备份时建议集群只读；恢复会覆盖数据。etcd 是集群唯一数据源。
Q3：节点维护，驱逐节点业务（ cordon /drain ）
A：
kubectl cordon node：标记节点不可调度，禁止新 Pod 调度上来，已有 Pod 继续运行。
kubectl drain node：驱逐节点上 Pod，Pod 调度到其他可用节点；维护 / 升级节点使用。
Q4：集群故障分级
A：
- 单 master 故障：HA 集群自动选主，业务不受影响
- etcd 集群半数节点宕机：集群不可写，只读，严重故障
- 多 worker 节点宕机：Pod 漂移，依赖副本策略
Q5：什么是 kubeadm？
A：官方集群部署工具，简化 K8s 安装，生成证书、静态 pod 部署控制平面组件。
Q6：集群备份除了 etcd 还有什么？
A：etcd 包含全部集群资源。如果业务有持久数据，还需要单独备份存储 PV 数据，etcd 不保存业务数据。
Q7：节点恢复流程
A：cordon → drain → 维护操作 → uncordon。
Q8：升级风险
A：API 废弃字段、CRD 版本不兼容、存储插件、CNI 插件版本不匹配。升级前备份 etcd，环境预演。
第 5 套：K8s 自定义资源 CRD、Operator、Helm
Q1：CRD 是什么？
A：CustomResourceDefinition，自定义资源定义。扩展 K8s API，让你可以新增自定义资源类型，原生 K8s 不提供的资源。CRD 是集群级别资源。
Q2：Operator 是什么？
A：基于 CRD + 自定义控制器。把运维逻辑写进控制器，自动管理复杂有状态应用（数据库、消息队列）。
原理：控制器持续调谐自定义资源的期望状态。把人工运维自动化。
Q3：Helm 是什么？
A：K8s 包管理工具。Helm Chart 是 yaml 模板包，一键部署应用，支持参数渲染、版本管理、回滚。
Helm3 移除了 Tiller，客户端直接调用 apiserver。
Q4：Helm 核心概念：Chart / Release / Repository
A：
Chart：应用模板包；Release：Chart 安装到集群的实例；Repo：Chart 仓库。
Q5：Operator vs Helm 区别
A：
Helm：模板渲染工具，一次性部署 / 升级 yaml，没有持续运维能力。
Operator：持续运行控制器，自动处理故障、备份、扩缩容、版本迁移，适合有状态服务。
Q6：CRD 使用场景
A：封装业务、中间件资源定义；监控、存储、服务网格插件大量使用 CRD。
Q7：Helm 模板注意事项
A：避免硬编码；使用 values.yaml 传参；注意 yaml 缩进；版本管理。
Q8：Helm 升级失败怎么处理
A：查看 release 状态，helm rollback 回滚；检查模板渲染后的 yaml 是否合法；RBAC 权限、资源冲突。
第 6 套：K8s 服务网格 Istio（补充，你说再出 5 套，前面 5 套，这是第 5 套后续额外一套，总共 5+1）
Q1：Istio 是什么？
A：服务网格，在应用侧注入 Sidecar 代理（envoy），接管 Pod 进出流量。不用改业务代码，提供流量治理、可观测、安全。
Q2：Sidecar 模式原理
A：业务 Pod + Envoy 边车，所有流量经过 envoy 代理。控制平面 istiod 下发配置给 envoy。
Q3：Istio 核心能力
A：流量路由、灰度发布、熔断、重试、超时、mTLS 加密、遥测监控、限流。
Q4：Istio 控制面 istiod
A：新版 Istio 合并为 istiod 单体，包含 pilot、citadel、galley 等组件，下发配置给数据面 envoy。
Q5：mTLS 是什么？
A：Pod 之间双向 TLS 加密通信，istio 自动管理证书，业务无感知。
Q6：VirtualService 和 DestinationRule
A：
VirtualService：流量路由规则（域名、路径、版本分流）
DestinationRule：目标服务策略，如负载均衡、mTLS、熔断
Q7：注入 Sidecar 两种方式
A：命名空间自动注入（webhook 准入控制器）；手动注入 yaml。
Q8：Istio 优缺点
A：优点：无侵入流量治理；缺点：增加网络延迟，资源开销，架构复杂度上升。
浙公网安备 33010602011771号