K8s 1.34+面试题：我被问到的那些问题

最近换工作，面了几家公司，Kubernetes相关的问题被问了不少。趁着还记得，整理一下我被问到的那些问题，附上我的回答思路和要点。希望能帮到正在准备K8s面试的朋友。

这些问题覆盖了从基础到高级的各个层面，有些是概念题，有些是场景题，有些是生产实践题。我尽量按照难度从低到高排列，方便大家循序渐进地复习。

需要说明的是，这些问题是基于K8s 1.34及以上版本的，有些特性是新版本才有的，旧版本可能不支持。面试的时候也要注意版本差异，不要把已经废弃的特性当成标准答案。

基础概念题

先从基础概念开始，这些是必考题，答不上来就很危险了。

问题一：什么是Kubernetes？它解决了什么问题？

这是最基础的开场题。回答的时候不要只说"K8s是容器编排平台"，要说清楚它解决了什么问题。

我的回答思路：Kubernetes是一个开源的容器编排和管理平台，最初由Google开发。它解决的核心问题是容器化应用的部署、扩展和管理。在没有K8s之前，容器的部署和运维需要大量的人工操作，比如手动调度容器、处理容器故障、做负载均衡、滚动升级等。K8s把这些工作自动化了，让应用的部署和运维变得简单、可靠、可扩展。

可以举几个具体的例子，比如自动伸缩、滚动更新、服务发现、自愈能力等，说明K8s具体做了什么。

问题二：Pod是什么？和容器有什么区别？

Pod是K8s的最小调度单位，这个必须答清楚。

我的回答思路：Pod是K8s中最小的部署和调度单位，一个Pod可以包含一个或多个容器。这些容器共享网络命名空间、存储卷和生命周期，它们之间可以通过localhost直接通信。

和容器的区别：容器是Docker层面的概念，是一个独立的运行环境；Pod是K8s层面的概念，是一组容器的集合。一个Pod里的容器是紧密耦合的，它们被调度到同一个节点上，一起创建和销毁。通常一个Pod里只放一个容器，只有在容器之间需要紧密协作的时候才放多个容器，比如日志收集sidecar、代理sidecar等。

问题三：Deployment和StatefulSet有什么区别？分别用在什么场景？

这是很常见的对比题，必须答清楚。

我的回答思路：Deployment用于管理无状态应用，它管理的Pod是无状态的、可互换的。Pod的名字是随机的，重启之后名字和IP都会变。存储方面，Deployment管理的Pod如果用了持久化存储，多个Pod会共享同一个存储卷，或者每个Pod没有独立的存储。

StatefulSet用于管理有状态应用，它管理的Pod有稳定的网络标识和持久化存储。每个Pod都有固定的名字（比如web-0、web-1），重启之后名字不变。每个Pod有自己独立的持久化存储卷，Pod重启之后数据还在。StatefulSet还支持有序部署和有序终止，适合需要稳定身份和数据的应用。

使用场景：Deployment适合Web应用、API服务等无状态应用；StatefulSet适合数据库、分布式存储、消息队列等有状态应用，比如MySQL集群、Redis集群、Kafka等。

问题四：Service是什么？有哪几种类型？

Service是K8s服务发现的核心，必须答清楚。

我的回答思路：Service是K8s中用于暴露应用的抽象，它为一组Pod提供一个稳定的访问入口。因为Pod是动态的，IP会变化，Service通过标签选择器绑定一组Pod，提供一个固定的ClusterIP和DNS名称，其他应用可以通过这个固定地址访问Pod，不需要关心Pod的变化。

Service有四种主要类型：ClusterIP是默认类型，只在集群内部可访问；NodePort在每个节点上开放一个端口，可以通过节点IP加端口从外部访问；LoadBalancer使用云服务商的负载均衡器，提供一个外部可访问的IP；ExternalName将Service映射到一个外部DNS名称，相当于CNAME记录。

还可以提一下Headless Service，它没有ClusterIP，DNS解析直接返回Pod的IP，用于StatefulSet的服务发现。

核心组件题

接下来是核心组件相关的问题，考察对K8s架构的理解。

问题五：K8s的架构是怎样的？有哪些核心组件？

这是架构题，需要把控制面和数据面的组件都说清楚。

我的回答思路：K8s采用主从架构，分为控制面（Control Plane）和工作节点（Worker Node）两部分。

控制面组件包括：kube-apiserver，是集群的入口，所有操作都通过它，负责认证、授权和API服务；etcd，是分布式键值存储，保存集群的所有状态数据；kube-scheduler，负责调度Pod到合适的节点上；kube-controller-manager，运行各种控制器，比如节点控制器、副本控制器、端点控制器等；cloud-controller-manager，与云服务商的API交互，管理云资源。

工作节点组件包括：kubelet，管理节点上的Pod生命周期，确保Pod正常运行；kube-proxy，管理节点上的网络规则，实现Service的负载均衡；容器运行时，比如containerd，负责运行容器。

可以画一个简单的架构图来说明各个组件之间的关系，这样更清晰。

问题六：kube-scheduler是怎么调度Pod的？调度过程是怎样的？

调度是K8s的核心功能，这个问题考察对调度机制的理解。

我的回答思路：kube-scheduler的调度过程分为两个主要阶段：过滤（Filtering）和打分（Scoring）。

过滤阶段：scheduler遍历所有节点，根据Pod的调度约束（比如节点选择器、亲和性、污点容忍、资源需求等），过滤掉不满足条件的节点。比如Pod需要4核8G，只有满足资源要求的节点才会被保留。过滤之后得到一组可行节点。

打分阶段：对过滤后的可行节点进行打分，根据各种调度策略（比如资源利用率、节点亲和性、Pod间亲和性、拓扑分布约束等）给每个节点打分，分数最高的节点被选中。如果有多个节点分数相同，会随机选一个。

选中节点之后，scheduler通过apiserver将Pod绑定到该节点，然后该节点上的kubelet会创建和运行Pod。

还可以提一下调度框架（Scheduling Framework），它是可扩展的，允许自定义插件来扩展调度逻辑。

问题七：etcd在K8s中起什么作用？为什么重要？

etcd是K8s的数据库，这个问题考察对集群状态管理的理解。

我的回答思路：etcd是一个分布式的一致性键值存储，K8s用它来存储集群的所有状态数据，包括节点信息、Pod信息、Service信息、配置信息、Secret等。所有的集群状态都保存在etcd中，apiserver是唯一直接操作etcd的组件。

etcd之所以重要，是因为它是集群的"真理之源"。如果etcd出了问题，整个集群就会失控，因为所有组件都是通过读取etcd中的状态来做决策的。所以etcd的高可用和数据备份非常重要。

生产环境中，etcd通常部署为3节点或5节点的集群，使用Raft协议保证一致性。需要定期备份etcd数据，以便在灾难发生时恢复集群。还要注意etcd的性能，因为它是集群的瓶颈之一，大集群中etcd的性能会影响整个集群的响应速度。

网络和存储题

网络和存储是K8s中比较复杂的部分，也是面试的重点。

问题八：K8s的网络模型是怎样的？Pod之间怎么通信？

K8s网络是面试高频题，需要说清楚几种通信模式。

我的回答思路：K8s的网络模型有几个基本原则：每个Pod有独立的IP，Pod之间可以直接通信，不需要NAT；Pod内的容器共享网络命名空间，可以通过localhost通信；节点上的容器可以和所有Pod通信，不需要NAT。

Pod之间的通信有几种情况：同一节点内的Pod通信，通过docker0网桥直接转发；跨节点的Pod通信，需要CNI插件来实现，常见的CNI插件有Flannel、Calico、Cilium等。CNI插件负责给Pod分配IP，配置网络路由，实现跨节点通信。

Pod到Service的通信，通过kube-proxy实现。kube-proxy在每个节点上配置iptables或IPVS规则，将Service的ClusterIP负载均衡到后端的Pod。

外部到Service的通信，通过NodePort、LoadBalancer或Ingress来实现。Ingress是HTTP层的路由，可以根据域名和路径将请求转发到不同的Service。

问题九：Ingress和Service有什么区别？Ingress Controller是怎么工作的？

Ingress是K8s中暴露HTTP服务的标准方式，这个问题很常见。

我的回答思路：Service是四层（TCP/UDP）的负载均衡，它工作在传输层，基于IP和端口进行转发。Ingress是七层（HTTP/HTTPS）的负载均衡，它工作在应用层，可以根据域名、路径、请求头等进行路由。

Service通常用于集群内部的服务发现，或者通过NodePort/LoadBalancer暴露TCP服务。Ingress用于暴露HTTP和HTTPS服务，可以实现虚拟主机、路径路由、SSL终止、限流等功能，比Service更灵活。

Ingress Controller是实际执行Ingress规则的组件，常见的有Nginx Ingress Controller、Traefik、HAProxy等。Ingress Controller监听apiserver中的Ingress资源，根据Ingress规则配置反向代理。当外部请求到达时，Ingress Controller根据请求的域名和路径，将请求转发到对应的Service，再由Service转发到Pod。

可以提一下Gateway API，这是Ingress的下一代标准，功能更强大，支持TCP、UDP、TLS等更多协议，正在逐步取代Ingress。

问题十：PV、PVC、StorageClass是什么关系？动态供给是怎么实现的？

存储是K8s的重要部分，这个问题考察对持久化存储的理解。

我的回答思路：PV（PersistentVolume）是集群中的一块持久化存储，由管理员 provision 或者由StorageClass动态创建。PV是集群级别的资源，不属于任何命名空间。

PVC（PersistentVolumeClaim）是用户对存储的请求，用户通过PVC来申请存储资源。PVC是命名空间级别的资源，Pod通过挂载PVC来使用存储。

StorageClass定义了存储的类型和参数，用于动态供给PV。当用户创建了一个引用StorageClass的PVC时，集群会自动创建一个满足要求的PV，并绑定到这个PVC上。

三者的关系：StorageClass定义了存储的"模板"，PVC是用户的"申请单"，PV是实际分配的"存储资源"。动态供给的过程是：用户创建PVC，指定StorageClass和存储大小；provisioner监听到PVC，根据StorageClass的参数创建实际的存储（比如云盘、Ceph卷）；创建对应的PV对象，并绑定到PVC；Pod挂载PVC使用存储。

还可以提一下VolumeSnapshot，这是K8s 1.20之后稳定的特性，支持对PV做快照，用于数据备份和恢复。

高级特性题

接下来是高级特性相关的问题，考察对K8s深入的理解。

问题十一：HPA是怎么工作的？有哪些指标可以用来伸缩？

自动伸缩是K8s的重要特性，这个问题很常见。

我的回答思路：HPA（Horizontal Pod Autoscaler）是水平Pod自动伸缩器，它根据监控指标自动调整Deployment或StatefulSet的副本数。

HPA的工作原理：HPA控制器定期（默认每15秒）检查Pod的指标，比如CPU利用率、内存利用率，或者自定义指标（比如QPS、队列长度）。当指标超过设定的阈值时，HPA会增加副本数；当指标低于阈值时，HPA会减少副本数。HPA有冷却时间，避免频繁伸缩。

可以用来伸缩的指标：资源指标，比如CPU和内存利用率，这是最常用的；自定义指标，比如应用的QPS、请求延迟、队列长度等，通过Prometheus Adapter暴露；外部指标，比如消息队列的长度、云服务的指标等。

K8s 1.34中，HPA支持基于多个指标的伸缩，还支持伸缩行为的配置（scaleUp和scaleDown的策略），可以更精细地控制伸缩行为。

还可以提一下VPA（Vertical Pod Autoscaler），它自动调整Pod的资源请求和限制，和HPA配合使用。

问题十二：Pod的生命周期是怎样的？有哪些状态？

Pod生命周期是基础但重要的问题，考察对Pod管理的理解。

我的回答思路：Pod的生命周期从Pending开始，然后是Running，最后是Succeeded或Failed。

Pending：Pod已经被创建，但还没有被调度到节点上，或者镜像还在拉取中。这个阶段scheduler在找合适的节点，kubelet在拉取镜像。

Running：Pod已经被调度到节点上，所有容器都已经创建，至少有一个容器在运行。这个阶段Pod在正常运行。

Succeeded：Pod中的所有容器都成功终止，并且不会重启。这个状态通常出现在Job类型的Pod完成任务之后。

Failed：Pod中的所有容器都终止了，至少有一个容器异常退出（退出码非0）。

还有一个Unknown状态，当节点失联时，Pod的状态无法确定，会变成Unknown。

Pod在创建和销毁的过程中，还有一些钩子：init容器在主容器启动之前运行，用于初始化；postStart钩子在容器启动后执行；preStop钩子在容器终止前执行，用于优雅关闭。

还可以提一下容器的探针：livenessProbe检测容器是否存活，失败了会重启容器；readinessProbe检测容器是否就绪，失败了会把Pod从Service的端点中移除；startupProbe检测容器是否启动完成，用于慢启动应用。

问题十三：K8s的安全机制有哪些？怎么保障集群安全？

安全是K8s生产环境的重要话题，这个问题考察对安全机制的全面理解。

我的回答思路：K8s的安全机制可以从几个层面来说。

认证和授权：apiserver支持多种认证方式，比如客户端证书、Bearer Token、OIDC等。授权使用RBAC（基于角色的访问控制），通过Role和RoleBinding来控制用户或服务账户对资源的访问权限。

准入控制：准入控制器在请求被持久化之前拦截请求，进行校验和修改。常见的准入控制器有NamespaceLifecycle、LimitRanger、ResourceQuota、PodSecurity等。还可以用OPA/Gatekeeper或Kyverno来做自定义的策略校验。

Pod安全：Pod Security Standards定义了三种安全策略（privileged、baseline、restricted），通过标签应用到命名空间，限制Pod的特权操作。还可以用AppArmor、SELinux、seccomp来限制容器的系统调用。

网络安全：NetworkPolicy可以限制Pod之间的网络通信，实现微隔离。默认情况下Pod之间可以自由通信，配置NetworkPolicy之后可以只允许特定的流量。

密钥管理：Secret用于存储敏感信息，比如密码、证书、API密钥。Secret默认是base64编码的，不是加密的，生产环境中应该启用etcd加密，或者使用外部密钥管理系统（比如Vault）。

镜像安全：使用可信的镜像仓库，扫描镜像漏洞，使用镜像签名验证镜像的完整性。不要使用latest标签，使用固定的版本标签。

生产实践题

最后是生产实践相关的问题，考察实际经验。

问题十四：Pod一直处于Pending状态，怎么排查？

这是典型的排障题，考察实际操作能力。

我的回答思路：Pod处于Pending状态，说明Pod还没有被调度到节点上。排查步骤如下。

第一步，用kubectl describe pod查看Pod的事件（Events），通常事件里会有调度失败的原因，比如节点资源不足、污点不匹配、亲和性不满足等。

第二步，检查节点资源是否充足，用kubectl describe node查看节点的CPU和内存使用情况。如果所有节点的资源都不够，Pod就会一直Pending。

第三步，检查Pod的调度约束，比如nodeSelector、nodeAffinity、taint和toleration。如果Pod要求的标签没有节点满足，或者节点有污点而Pod没有对应的容忍，就会调度失败。

第四步，检查是否有足够的PV。如果Pod挂载了PVC，而PVC一直处于Pending状态（没有可用的PV），Pod也会一直Pending。

第五步，检查镜像是否能拉取。如果镜像仓库不可达，或者镜像不存在，Pod会卡在ImagePullBackOff，虽然不是Pending但也是常见问题。

根据排查到的原因，采取对应的解决措施，比如增加节点资源、调整调度约束、创建PV等。

问题十五：怎么做K8s集群的升级？升级过程中需要注意什么？

集群升级是生产环境的重要操作，这个问题考察运维经验。

我的回答思路：K8s集群升级需要按照一定的顺序来，先升级控制面，再升级工作节点，而且只能跨一个小版本升级（比如从1.33升到1.34，不能直接从1.32升到1.34）。

升级控制面：先升级kubeadm，然后用kubeadm upgrade plan检查升级计划，再用kubeadm upgrade apply升级控制面组件。控制面升级过程中，apiserver会短暂不可用，但已经运行的Pod不受影响。

升级工作节点：逐个节点升级，先驱逐节点上的Pod（kubectl drain），然后升级kubelet和kube-proxy，重启服务，最后把节点标记为可调度（kubectl uncordon）。一次只升级一个节点，确保应用有足够的副本在其他节点上运行。

注意事项：升级前备份etcd数据，以防升级失败需要回滚；确保应用有足够的副本数，避免驱逐节点时服务不可用；检查应用是否有本地存储，驱逐有本地存储的Pod需要加--delete-emptydir-data参数；注意API版本的变化，有些旧版本的API在新版本中可能被废弃，需要提前迁移；升级后验证集群状态，确保所有节点和Pod正常运行。

还可以提一下集群升级工具，比如kubeadm、kops、Rancher等，不同的工具有不同的升级方式。

问题十六：怎么监控K8s集群？常用的监控方案有哪些？

监控是生产环境必不可少的，这个问题考察对监控生态的了解。

我的回答思路：K8s监控分为几个层面：集群监控、节点监控、Pod监控、应用监控。

常用的监控方案：Prometheus + Grafana是最主流的组合。Prometheus通过指标采集（node-exporter采集节点指标，kube-state-metrics采集K8s资源状态指标，cAdvisor采集容器指标），Grafana做可视化展示。

日志方面，常用ELK Stack（Elasticsearch、Logstash、Kibana）或者Loki + Grafana。Loki更轻量，和Grafana集成更好，是现在比较流行的方案。

链路追踪方面，常用Jaeger或Zipkin，配合OpenTelemetry做埋点。现在OpenTelemetry已经成为标准，支持指标、日志、链路追踪三位一体。

告警方面，Prometheus配合Alertmanager做告警，告警可以发送到邮件、钉钉、企业微信、Slack等。

还有一些全栈的监控方案，比如Datadog、New Relic、云服务商的监控服务等，功能更全面，但需要付费。

K8s 1.34中，监控相关的特性也在不断增强，比如Pod的资源指标更丰富，支持更细粒度的监控。

写在最后

以上就是我最近面试中被问到的K8s相关问题，整理出来供大家参考。

K8s的知识点很多，面试的时候不可能全部覆盖到，但核心的概念、架构、网络、存储、安全、排障这些是重点。准备面试的时候，要把这些基础打牢，同时结合实际项目经验，能说出具体的场景和解决方案。

还要注意版本差异，K8s发展很快，每个版本都有新特性和废弃的API。面试的时候如果不确定，可以说"在1.34版本中是这样的"，体现出你对版本的关注。

最后，面试不仅是考察知识，也是考察思维方式和解决问题的能力。遇到不会的问题，不要慌，可以说说自己的思路，或者从类似的问题推导。面试官更看重的是你的思考过程，而不是标准答案。