k8s面试题100道，你能回答几道？(七)

---

前言

工作多年，最近面试一直被问k8s相关的知识。k8s几年前搞过，最近几年一直在做开源项目相关的工作，又不是专业运维，好多知识点早已经模糊了。但是面试又喜欢问，叫什么，是什么，如何实现的，有没有这样的功能，原理是什么，原理的原理是什么，等等吧。
下面准备100道k8s面试题，不知道有没有人能顶得住。

---

1. 在实际项目中，哪些类型的应用最适合用Kubernetes来管理？

最适合Kubernetes的应用类型：
微服务架构：自动伸缩、服务发现和滚动更新特性完美契合动态微服务环境
云原生应用：容器化应用、Serverless工作负载
批处理任务：CronJob资源管理定时任务
CI/CD流水线：配合Argo CD等工具实现GitOps
不适合的应用类型：
传统单体应用（改造成本高）、对存储I/O要求极高的有状态应用

2. 为何k8s不适合存储I/O要求极高的有状态应用？

存储性能瓶瓶颈问题

1. 动态存储分配限制
   k8s默认的存储卷动态分配难以满足高频I/O场景的稳定性需求。频繁的存储读写可能导致卷性能抖动，且无法直接控制底层存储介质的物理特性（如SSD的NVMe队列深度）
2. 本地存储劣势
   高I/O场景通常依赖本地存储，但k8s的Pod迁移机制可能导致存储和计算节点解耦。即使使用local类型PersistentVolume，也难以保证存储和计算资源的长期绑定关系。
   分布式
3. 分布式存储延迟
   采用Ceph、GlusterFS等分布式存储方案时， 网络传输和协议转换会引入额外延迟，无法达到本地直通存储的性能水平

网络架构限制

1. 虚拟网络层开销
   k8s的CNI网络插件（如Flannel、Calico）在Pod间通信时需经过多次封包/解包操作，对于需要低延迟、高吞吐的I/O密集型应用（如数据库事务处理），会显著增加网络延迟。
2. 服务发现机制不足
   有状态服务需要稳定的网络标识，但k8s的Service机制基于动态负载均衡，无法为单个Pod提供永久性访问节点。

调度机制缺陷

1. 存储感知调度缺失
   原生调度器无法重复感知存储性能指标（如磁盘IOPS、吞吐量），可能导致高I/O Pod被分配到存储性能不足的节点
2. 反亲和性实时成本高
   为确保数据可靠性，有状态应用需跨故障域部署副本。但k8s的饭亲和性规则配置复杂，且难以与底层拓扑（如RAID组、存储池）深度协同。

资源隔离不足

1. I/O资源配额限制
   k8s仅支持CPU/内存的资源隔离，无法对磁盘I/O带宽、网络带宽进行精细化控制。高I/O应用可能因资源争抢导致性能骤降。
2. 内核级优化缺失
   容器化环境难以实施内核参数调优（如调整I/O调度算法、块设备队列参数），而这些优化对数据库类应用至关重要。

3. 对于有状态的应用程序，如何确保数据的一致性和可靠性？

# StatefulSet 示例
kind: StatefulSet
spec:
  serviceName: "mysql"
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      storageClassName: ssd
      resources:
        requests:
          storage: 100Gi

数据一致性保障：使用支持分布式存储的解决方案。
可靠性策略：Pod反亲和性 + 持久卷自动备份

4. 你遇到过哪些常见的Kubernetes问题？你是如何解决的？

问题类型	典型表现	排查工具	解决方案
Pod 启动失败	CrashLoopBackOff	kubectl describe pod	检查镜像/资源限制
网络异常	Service 不可达	kubectl get endpoints	验证网络策略配置
存储问题	PVC pending	kubectl get pv	检查 StorageClass 可用性

5. 如何优化Kubernetes集群性能？

‌资源调度优化‌：设置合理的 requests/limits，使用节点亲和性
‌网络优化‌：选择适合的 CNI 插件（Calico/Cilium）
‌存储优化‌：本地临时卷（Local Ephemeral Volumes）加速IO
‌集群扩展‌：Horizontal Pod Autoscaler + Cluster Autoscaler 联动

6. Kubernetes如何支持多云环境？

# 使用 Karmada 实现多集群管理
karmadactl join cluster --name=cluster1 --cluster-kubeconfig=/path/to/kubeconfig

7. Istio服务网格及其集成方式是什么？

# Istio 流量镜像配置示例
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - mirror:
      host: reviews-v2
    route:
    - destination:
        host: reviews-v1

8. Knative是什么？它为Kubernetes带来了什么？

定义：Knative是基于k8s的开源Serverless平台，旨在简化无状态应用的构建、部署和管理。
核心组件：
Serving：支持请求驱动的自动扩缩容和流量管理（蓝绿/金丝雀发布）
Eventing：提供事件驱动架构，通过CloudEvents标准实现时间源与应用的解耦
Build（已由Tekton替代）：实现从源码到容器镜像的自动化构建流程

核心价值：
无服务器能力：开发者无需关注底层基础设施，专注于业务逻辑实现
资源优化：通过缩容至零，降低空闲资源消耗成本
标准化扩展：基于k8s原生API扩展，与Istion深度集成提供网络治理能力。

9. Kubernetes调度策略是怎样的？

过滤阶段：排除不满足资源请求、节点亲和性/反亲和性、容忍性的节点
打分阶段：根据优先级策略（如资源均衡、数据局限性）选择最优节点
关键策略：
节点选择器（nodeSelector）
亲和性/反亲和性（affinity/anti-affinity）
污点和容忍（Taints and Tolerations）

10. 如何在Kubernetes中实施CI/CD管道？

graph LR  
A[代码提交] --> B(镜像构建-Tekton)  
B --> C[镜像扫描-Trivy]  
C --> D[部署测试环境-Argo Rollouts]  
D --> E[自动化测试]  
E --> F[生产环境发布]  

核心工具链：
Tekton：声明式流水线引擎，替代Knative Build
Argo CD：GitOps实现持续部署
金丝雀发布：通过Istio流量拆分实现渐进式交付

11. 如何实现Kubernetes的安全加固？

安全维度	实时措施
认证鉴权	RBAC最小权限原则+ServiceAccount令牌轮换
网络隔离	NetworkPolicy限制Pod间通信
传输安全	启用mTLS（如Istio自动加密）
镜像安全	Trivy漏洞扫描+cosign签名验证

12. Kubernetes中的网络策略是如何工作的？

网络策略定义了Pod之间的访问规则，限制了进出Pod的流量。

apiVersion: networking.k8s.io/v1  
kind: NetworkPolicy  
spec:  
  podSelector:  
    matchLabels: app: db  
  ingress:  
  - from:  
    - podSelector:  
        matchLabels: app: web  
    ports:  
    - protocol: TCP  
      port: 3306  

13. 什么是Service Mesh，它对Kubernetes的意义是什么？

Service Mesh（如Istio）通过Sideca代理实现
流量治理：熔断、重试、流量镜像
安全通信：自动mTLS加密和身份认证
可观测性：分布式追踪和指标监控
核心价值在于解耦业务逻辑与基础设施功能

14. 什么是Kubernetes Federation？

Kubernetes Federation是多集群管理方案，主要用于：
统一服务发现：跨集群Service同步
全局负载均衡：基于地理位置的路由策略
策略同步：跨集群试试统一的NetworkPolicy/RBAC

15. 如何使用Kubernetes进行边缘计算？

轻量级发行版：k3s适用于资源受限设备
边缘自治：KubeEdge实现离线节点资管理
分层部署：中心集群管理编排，边缘节点运行关键业务

16. Kubernetes中的Custom Resource Definitions (CRDs) 是什么？

CRD：允许用户扩展Kubernetes API，定义自定义资源类型

apiVersion: apiextensions.k8s.io/v1  
kind: CustomResourceDefinition  
metadata:  
  name: databases.example.com  
spec:  
  group: example.com  
  versions:  
    - name: v1  
      served: true  
      storage: true  
  scope: Namespaced  
  names:  
    plural: databases  
    singular: database  
    kind: Database  

17. 如何在Kubernetes中实现服务发现？

Service DNS：通过 ..svc.cluster.local 解析到 ClusterIP
EndPoints：动态维护Pod IP列表，支持Headless Service 直连Pod
Ingress控制器：对外包暴露服务并实现L7路由

18. Kubernetes未来的发展方向有哪些？

智能化调度：基于实施指标的AI驱动调度决策
边缘计算优化：轻量化发行版（k3s）和边缘框架（如KubeEdge）
Wasm集成：通过Kwasm支持WebAssembly工作负载
机密计算：整合Intel TDX/AMD SEV实现数据运行时保护

19. 什么是Horizontal Pod Autoscaler (HPA)?

HPA是Kubernetes实现弹性计算你的核心工具，通过自动扩缩容优化资源利用率与服务。实际使用中需配合目标阈值、指标采集频率，自定义指标等，避免过度响应或资源浪费。

20. HPA支持那些自定义指标类型？怎么实现？

应用级指标
HTTP请求速率、请求延迟、消息队列堆积量
外部系统指标
数据库连接数、云服务指标、Prometheus自定义指标

示例：

## 定义指标规则
rules:
  - seriesQuery: 'http_requests_total{kubernetes_namespace!="",kubernetes_pod_name!=""}' 
    seriesFilters: []  # 不过滤指标
    resources:
      overrides:  # 将 Prometheus 标签映射到 Kubernetes 资源
        kubernetes_namespace: { resource: "namespace" }
        kubernetes_pod_name: { resource: "pod" }
    name:
      matches: "^(.*)_total"  # 指标重命名（自动转为每秒速率）
      as: "${1}_per_second"
    metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)' 

## 典型示例场景
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second  # Adapter 转换后的指标名:ml-citation{ref="3,5" data="citationList"}
      target:
        type: AverageValue
        averageValue: 100  # 目标 QPS 阈值

21. 如何确保Kubernetes集群的高可用性？

控制平面高可用：多Master节点、etcd集群、组件冗余。
工作节点高可用：节点跨区分布、自愈机制、存储高可用。

22. Kubernetes集群的数据备份策略是什么？

Etcd数据库备份：

# 使用 etcdctl 备份
ETCDCTL_API=3 etcdctl --endpoints=<etcd-endpoints> \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  snapshot save /backup/etcd-snapshot.db

# 定期备份（通过 CronJob）
kubectl create cronjob etcd-backup --image=etcdctl \
  --schedule="0 2 * * *" -- /bin/sh -c "etcdctl snapshot save ..."

应用数据备份：
Velero：备份Kubernetes资源和持久卷

velero backup create <backup-name> --include-namespaces=<namespace>

云原生快照：通过CSI驱动触发存储快照（如AWS EBS Snapshot）

23. 如何限制容器运行时的安全风险？

应用最小权限原则，启用Seccomp和AppArmor等Linux安全模块，限制容器内的权限。

安全机制	实现方式	示例
Seccomp	限制容器系统调用	在Pod中配置securityContext.seccompProfile
AppArmor	定义容器访问控制规则	加载AppArmo配置文件并指定注解container.apparmor.security.beta.kubernetes.io/: localhost/
非Root运行	禁止特权容器	securityContext.runAsRoot:true
只读文件系统	防止文件篡改	securityContext.readOnlyRootFilesystem:true

24. 什么是Network Policy？

# 示例：仅允许前端 Pod 访问数据库
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access
spec:
  podSelector:
    matchLabels:
      app: mysql
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 3306

集群必须使用支持NetworkPolicy的CNI插件（如Calico、Cilium）

25. 如何调试运行在Kubernetes中的应用程序？

kubectl describe pod <pod-name>    # 查看 Pod 事件
kubectl logs <pod-name> -c <container>  # 查看容器日志
kubectl exec -it <pod-name> -- /bin/sh  # 进入容器

26. GitOps是什么？它如何在Kubernetes中应用？

GitOps是一种通过Git仓库管理集群配置和应用部署的方法，使用工具如Argo CD或Flux来同步Git中的声明性配置到Kubernetes集群。

graph LR
  A[Git 仓库] --> B(声明式配置 YAML)
  B --> C{Argo CD/Flux}
  C --> D[同步到集群]
  D --> E[自动修复漂移]

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  project: default
  source:
    repoURL: https://github.com/user/repo
    targetRevision: HEAD
    path: k8s/
  destination:
    server: https://kubernetes.default.svc
    namespace: default

27. Spinnaker与Jenkins相比有何不同？

Spinnaker专注于多云环境下的持续交付，提供更强大的部署策略（如蓝绿部署、金丝雀发布），而Jenkins是一个通用的CI工具，需要额外插件支持Kubernetes。

28. 如何使用Skaffold简化开发流程？

Skaffold自动化了从代码更新到构建、推送镜像再到重新部署应用的过程，特别适合开发阶段频繁迭代的应用。

apiVersion: skaffold/v2
kind: Config
build:
  artifacts:
  - image: my-app
    context: .
    docker: {}
deploy:
  kubectl:
    manifests:
      paths: ["k8s/*.yaml"]

skaffold dev  # 自动监视代码变更并重新部署
skaffold build --push  # 构建并推送镜像

29. Linkerd与Istio之间有什么区别？

Linkerd是轻量级的服务网格解决方案，易于安装和维护；Istio提供了更为全面的功能集，包括流量管理、安全性和可观测性等高级特性。

特性	Linkerd	istio
资源消耗	轻量（~10MB/代理）	较高（~100MB/代理）
安装复杂度	简单（单命令）	复杂（需配置CRD）
核心功能	基础流量管理+指标	流量治理+安全+可观测性
适用场景	中小规模集群	企业级微服务架构

30. Envoy Proxy在服务网格中的角色是什么？

Envoy作为Sidecar代理，处理服务间的通信，提供负载均衡、服务发现等功能，并收集遥测数据供监控使用。

31. 如何在Kubernetes上运行批处理任务？

可以使用Job或CronJob资源类型来定义一次性或周期性的批处理作业。

32. 如何利用Kubernetes进行大数据处理？

部署Apache Spark等大数据框架到Kubernetes上，利用其弹性伸缩能力处理大规模数据集。

33. 如何使用DaemonSet部署系统组件？

DaemonSet‌ 适用于节点级系统组件的部署，需结合 hostPath 和容忍机制适配节点特性。使用在日志收集、网络插件、监控代理等。

apiVersion: apps/v1  
kind: DaemonSet  
metadata:  
  name: node-log-collector  
spec:  
  selector:  
    matchLabels:  
      app: fluentd  
  template:  
    metadata:  
      labels:  
        app: fluentd  
    spec:  
      tolerations:  
      - key: node-role.kubernetes.io/control-plane  
        operator: Exists  
        effect: NoSchedule  
      containers:  
      - name: fluentd  
        image: fluentd:latest  
        volumeMounts:  
        - name: varlog  
          mountPath: /var/log  
      volumes:  
      - name: varlog  
        hostPath:  
          path: /var/log  

34. 什么是Helm Chart？

核心功能：
‌Helm Chart‌ 通过模板化和参数化实现 Kubernetes 应用的快速交付与版本管理，是复杂运维场景的标准化解决方案.
核心组件：
模版引擎：使用Go Template动态生成资源文件（如Deployment、Service）
参数配置：通过values.yaml文件定义可覆盖的变量（如副本数、镜像版本）
依赖管理：可声明其他Helm Chart作为依赖项（如Redis作为应用数据库）
典型结构：

my-chart/  
├── Chart.yaml          # Chart 元数据（名称、版本）  
├── values.yaml         # 默认配置参数  
├── charts/             # 子 Chart 依赖项  
└── templates/          # Kubernetes 资源模板  
    ├── deployment.yaml  
    ├── service.yaml  
    └── daemonset.yaml  

35. Kubernetes API Server的性能调优方法有哪些？

包括调整API Server的并发连接数、启用缓存机制、优化etcd数据库性能等措施。

36. 如何在Kubernetes中实现跨命名空间的资源共享？

利用ResourceQuotas和LimitRanges设置命名空间级别的资源配额，或者通过Network Policies控制跨命名空间的网络访问。

37. 什么是CSI (Container Storage Interface)？

CSI是一个标准化接口，使第三方存储提供商能够开发插件，以便Kubernetes可以动态供应存储卷。

38. Kubernetes中的Custom Scheduler是如何工作的？

用户可以编写自定义调度器来替代默认调度器，根据特定业务逻辑决定Pod的放置位置。

39. 如何评估Kubernetes集群的安全状态？

• 定期进行安全审计，检查RBAC权限设置、网络策略、容器运行时安全配置等，同时使用工具如kube-bench检测是否符合CIS Kubernetes基准。

---

总结

Kubernetes ‌核心优势‌在于管理云原生微服务、批处理任务及CI/CD流水线，通过Deployment/StatefulSet实现弹性伸缩与滚动更新，结合HPA支持CPU/内存及‌自定义指标‌（如HTTP QPS、队列堆积量）扩缩容。

‌关键限制‌：
‌存储性能瓶颈‌：本地存储与Pod迁移解耦、分布式存储延迟高，难以满足高频I/O场景（如数据库）；
‌网络开销‌：CNI插件导致通信延迟，不适配低延迟事务；
‌调度缺陷‌：缺乏存储感知与精细化I/O隔离。

‌扩展方案‌：
‌有状态服务‌：使用StatefulSet + 持久卷（如SSD StorageClass）保障数据一致性；
‌多云/边缘‌：通过Karmada/K3s实现跨集群管理与边缘自治；
‌安全加固‌：RBAC、NetworkPolicy及mTLS加密。
‌HPA自定义指标‌：通过Prometheus Adapter将应用/外部指标（如数据库连接数）转换为K8s Metrics API格式，结合多指标混合策略实现精准扩缩容。