2026 年最全 48 道 Kubernetes 面试题与答案

Kubernetes 基础面试题

下面从基础面试题开始。这些问题涵盖理解与使用 Kubernetes 所需的基础知识。

1. 什么是 Kubernetes 中的 Pod？

Pod 是 Kubernetes 中最小的可部署 单元，表示在共享环境中运行的一个或多个容器。Pod 内的容器共享网络与存储资源。

以下是一个简单的 Pod 定义 YAML 文件：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80技术支持

2. kubectl 的作用是什么？

Kubectl 是管理 Kubernetes 资源并与集群交互的主要 CLI 工具。以下是一些您应熟悉的常用命令：

kubectl get pods 				 # list all Pods
kubectl get services 			 # list all Services
kubectl logs <pod-name> 	  	 # view logs of a Pod
kubectl exec -it <pod-name> -- /bin/sh # open a shell inside a Pod技术支持

3. 什么是 Kubernetes 中的 Deployment？

Deployment 是管理 Pod 生命周期的更高层抽象。它确保期望数量的副本运行，并提供滚动更新、回滚、自愈等功能。

下面是一个简单 Deployment 定义的 YAML 示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
        ports:
        - containerPort: 80技术支持

4. 什么是 Kubernetes Service，为什么需要它？

Kubernetes 中的 Service 用于暴露一组 Pods，并允许与这些 Pods 的相互通信以及对外通信。

由于 Pods 是短暂的，它们的 IP 会变化，这意味着与其通信的应用也得不断更换 IP。Service 因此提供一个具有固定 IP 的稳定网络端点。

一个简单的 Service YAML 定义：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP技术支持

上述 Service 会将流量转发到带有 app: my-app 标签的 Pods。

5. Kubernetes Services 支持哪些服务类型？

Kubernetes 提供四种主要 Service 类型，分别满足不同的网络需求：

• ClusterIP（默认）：用于 Pods 的内部通信，仅集群内部可访问。
• NodePort：在每个节点的静态端口上暴露 Service，使其可被集群外部访问。
• LoadBalancer：使用云厂商的外部负载均衡器，Service 将通过公有 IP 对外提供服务。
• ExternalName：将 Kubernetes Service 映射到外部主机名。

6. ConfigMaps 和 Secrets 在 Kubernetes 中的作用是什么？

ConfigMaps 存储非敏感配置数据，而 Secrets 存储诸如 API 密钥与密码等敏感数据。

通过 Secrets，您可以避免将敏感信息写入应用代码。相对地，ConfigMaps 让应用更易配置，因为这些值可轻松编辑，无需持久化在应用代码中。

ConfigMap YAML 定义示例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_url: "postgres://db.example.com"技术支持

Secret YAML 定义示例（使用 base64 编码［非加密］的数据）：

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  password: cGFzc3dvcmQ=  # "password" encoded in Base64技术支持

7. 什么是 Kubernetes 中的 Namespaces？

Namespace 是 Kubernetes 集群中的虚拟集群。它通过在集群内隔离资源来帮助在多租户环境中组织工作负载。

下面的简短代码段展示如何用 kubectl 创建一个 Namespace，以及如何在该 Namespace 中创建与获取 Pods：

# create a namespace called "dev"
kubectl create namespace dev

# create a Pod in that namespace
kubectl run nginx --image=nginx --namespace=dev

# get Pods in that namespace
kubectl get pods --namespace=dev技术支持

8. 什么是 Kubernetes 中的 Labels 与 Selectors？

Labels 是附加到对象（如 Pods）上的键/值对，用于组织 Kubernetes 对象。Selectors 根据 Labels 过滤资源。

以下示例 Pod 带有 environment: production 与 app: nginx 标签：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:1.21
    ports:
    - containerPort: 80技术支持

您可以用以下标签选择器获取所有带有 environment: production 标签的 Pods：

kubectl get pods -l environment=production技术支持

9. 什么是 Persistent Volumes（PVs）与 Persistent Volume Claims（PVCs）？

Persistent Volumes（PVs）提供在 Pod 生命周期之外仍可持久化的存储。PV 是由集群管理员预先配置，或通过存储类（StorageClass）动态创建的集群存储单元。

Persistent Volume Claim（PVC）是用户对存储的请求。

下面是 PV 与 PVC 的 YAML 定义示例：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"技术支持

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi技术支持

Kubernetes 中级面试题

掌握了基础之后，我们进入中级问题。在此层级，理解网络、安全、资源管理与故障排查等概念至关重要。

10. 什么是 Kubernetes 网络，如何工作？

Kubernetes 网络支持 Pods、Services 与外部客户端之间的通信。它遵循扁平网络结构，默认情况下所有 Pods 彼此可通信。

Kubernetes 的关键网络概念包括：

• Pod 间通信：每个 Pod 拥有唯一 IP，并可在集群内通信。
• Service 与 Pod 通信：因 Pods 是短暂的，Service 为一组 Pods 提供稳定网络端点。每次创建 Pod 都会分配新 IP。
• Ingress 控制器：管理外部 HTTP/HTTPS 流量。
• 网络策略（NetworkPolicy）：定义允许或限制 Pod 间通信的规则。

11. 什么是 Kubernetes 中的基于角色的访问控制（RBAC）？

RBAC 是一种基于权限约束用户和服务的安全机制。它由以下部分组成：

• Roles 与 ClusterRoles：定义对资源允许执行的操作。
• RoleBindings 与 ClusterRoleBindings：将角色分配给用户或服务账号。

下面的 YAML 展示了一个仅允许对 Pods 进行只读访问的 role 示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]技术支持

现在可以使用 RoleBinding 将该 pod-reader 角色绑定到某个用户：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: User
    name: dummy
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io技术支持

12. Kubernetes 的自动伸缩如何工作？

Kubernetes 提供三种自动伸缩以优化资源使用：

1. HPA（Horizontal Pod Autoscaler）：基于 CPU、内存或自定义指标调整 Pod 数量。
2. VPA（Vertical Pod Autoscaler）：为单个 Pod 调整 CPU 与内存请求值。
3. Cluster Autoscaler：根据资源需求调整集群工作节点数量。

您可以使用 kubectl 创建一个 HPA：

kubectl autoscale deployment nginx --cpu-percent=50 --min=1 --max=10技术支持

上述命令为名为 nginx 的 Deployment 创建 HPA，尝试将所有 Pods 的平均 CPU 利用率维持在 50%，最少 1 个副本，最多 10 个副本。

13. 您如何调试 Kubernetes Pods？

当 Pods 出现故障时，Kubernetes 提供多种调试方式：

• 使用 kubectl logs 查看容器日志中的错误。
• 使用 kubectl describe pod 检查事件与近期状态变化。
• 使用 kubectl exec 打开交互式 Shell，从容器内部排查。
• 使用 kubectl get pods --field-selector=status.phase=Failed 列出所有失败的 Pods。

# get logs of a specific Pod
kubectl logs <pod-name>

# describe the Pod and check events
kubectl describe pod <pod-name>

# open an interactive shell inside the Pod
kubectl exec -it <pod-name> -- /bin/sh

# check all failing pods
kubectl get pods --field-selector=status.phase=Failed技术支持

这些命令有助于识别配置错误、资源约束或应用错误。

14. liveness 与 readiness 探针有何区别？

两者都是 Kubernetes 针对容器运行的健康检查，但用途不同：

• Liveness 探针：检测容器是否存活但卡死（如死锁）。探针失败时，Kubernetes 会重启容器。用于崩溃与死锁恢复。
• Readiness 探针：检测容器是否已准备好接收流量。若失败，Kubernetes 会将 Pod 从 Service 的端点列表中暂时移除，而不会重启。用于避免将流量导向尚未完全启动的 Pod。

同时包含两种探针的 Pod 规范示例：

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app
    image: my-app:v2
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 3技术支持

常见错误是该用 readiness 探针时用了 liveness 探针。如果应用启动较慢，配置不当的 liveness 探针会在其启动前将其杀死并重启——导致与应用崩溃看起来相同的重启循环。

15. 如何在 Kubernetes 中执行滚动更新与回滚？

Kubernetes 的 Deployment 支持滚动更新以避免停机。您可以通过编辑 Deployment，或明确将其镜像更新为新版本来执行滚动更新：

kubectl set image deployment/my-deployment nginx=nginx:1.21技术支持

随后可以检查 Deployment 状态：

kubectl rollout status deployment my-deployment技术支持

若需回滚到上一版本，可运行：

kubectl rollout undo deployment my-deployment技术支持

16. 什么是 Kubernetes 中的 Ingress，它如何工作？

Ingress 是一个 API 对象，用于管理对 Kubernetes 集群内 Services 的外部 HTTP/HTTPS 访问。它可根据主机名与路径路由请求，充当多个应用的反向代理。

Ingress YAML 定义示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80技术支持

17. 什么是 Kubernetes Gateway API，它与 Ingress 有何不同？

Gateway API 是 Kubernetes 网络的现代化演进，旨在取代标准 Ingress。Ingress 设计之初只面向简单的 HTTP 路由，随着集群复杂度提升，它逐渐显得受限且碎片化。

Gateway API 的改进体现在：

• 面向角色的设计： 将由基础设施工程师管理的 Gateway 定义，与由应用开发者管理的 Routes 分离。
• 更佳的特性支持： 原生支持高级流量功能，如流量拆分（A/B 测试）、Header 匹配与多集群网络，而无需复杂的自定义注解。

18. Kubernetes 如何处理资源 requests 与 limits？

Kubernetes 允许为 Pods 设置资源请求与限制，以保持资源分配平衡并避免过度使用集群资源。

• Requests 是 Pod 所需的最小 CPU 与内存，会被长期分配给该 Pod。
• Limits 是 Pod 可使用的最大值。并不会预先分配给 Pod，但当 Pod 需要更多资源时，可增长直至达到上限。

设置资源请求与限制的 Pod YAML 示例：

apiVersion: v1
kind: Pod
metadata:
  name: resource-limited-pod
spec:
  containers:
    - name: my-container
      image: nginx
      resources:
        requests:
          memory: "256Mi"
          cpu: "250m"
        limits:
          memory: "512Mi"
          cpu: "500m"技术支持

19. 如果 Pod 需要的资源超过分配的 limits 会发生什么？

如果 Pod 的内存使用超过其内存限制，Kubernetes 会立即杀死容器，并报 out of memory（OOM）错误。若定义了重启策略，容器将被重启。

与内存不同，若 Pod 超过其 CPU 限制，容器不会被杀死，而是会被限流，从而导致应用变慢。

20. 什么是 init containers，何时应使用？

Init 容器是在主容器启动之前运行的特殊容器。它们通过检查依赖、加载配置文件或准备数据来为环境做准备。

例如，一个 init 容器可在数据库就绪前进行等待：

apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  initContainers:
    - name: wait-for-db
      image: busybox
      command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done']
  containers:
    - name: my-app
      image: my-app-image技术支持

21. Kubernetes 如何处理 Pod 中断与高可用？

Kubernetes 通过 Pod Disruption Budget（PDB）、反亲和规则与自愈机制来保证高可用。其工作方式如下：

• Pod Disruption Budget（PDB）： 在自愿性中断（如集群升级需要缩容节点）期间，确保有最少数量的 Pod 保持可用。
• Pod 亲和与反亲和： 控制哪些 Pods 可以（或不可以）被调度在一起。
• 节点选择器与污点/容忍（Taints/Tolerations）： 控制工作负载在节点间的分布。

以下 PDB YAML 示例确保在中断期间至少有两个 Pod 仍在运行：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app技术支持

Kubernetes 高级面试题

本节涵盖高级 Kubernetes 面试题，聚焦有状态应用、多集群管理、安全、性能优化与故障排查。若您应聘高级岗位，请务必查看。

22. 什么是 StatefulSets，它与 Deployments 有何不同？

StatefulSet 用于有状态应用，需要稳定网络标识、持久化存储与有序部署。与 Deployment 不同，StatefulSet 确保：

• Pods 具有稳定且唯一的网络标识，命名如 pod-0、pod-1 等。
• Pods 按顺序创建、更新与删除。
• 每个 Pod 在重启间保留持久化存储。持久化存储在 StatefulSet 的 YAML 中定义。

23. 什么是服务网格（service mesh），为何在 Kubernetes 中使用？

服务网格负责服务与服务之间的通信，提供：

• 流量管理（负载均衡、金丝雀发布）。
• 安全性（服务间 mTLS 加密）。
• 可观测性（追踪、指标、日志）。

这些能力位于基础设施层，无需修改应用代码。

常见的 Kubernetes 服务网格方案包括：Istio、Linkerd 与 Consul。

24. 如何保障 Kubernetes 集群安全？

遵循 4C 安全模型来保护 Kubernetes 集群：

1. 云提供商安全： 使用 IAM 角色与防火墙规则。
2. 集群安全： 启用 RBAC、审计日志与 API 服务器安全。
3. 容器安全： 扫描镜像并使用非 root 用户。
4. 代码安全： 实施 Secrets 管理并使用网络策略。

25. Kubernetes 中的 Taints 与 Tolerations 是什么？

Taints 与 Tolerations 用于控制 Pods 的运行位置：

• Taints： 标记节点以拒绝 Pods 调度。
• Tolerations： 允许 Pods 忽略特定 Taints。

下面是给节点打污点，仅接收特定工作负载的示例：

kubectl taint nodes node1 key1=value1:NoSchedule技术支持

这意味着在具有所需容忍度之前，任何 Pod 都无法被调度到 node1 上。

在 PodSpec 中如下添加 Toleration：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"技术支持

该 Pod 可被调度到 node1。

26. 什么是 Kubernetes 边车（sidecar）容器，如何使用？

边车容器与主应用容器在同一 Pod 内并行运行。常见用途包括：

• 日志与监控（如使用 Fluentd 收集日志）。
• 安全代理（如运行 Istio 的 Envoy 代理以构建服务网格）。
• 配置管理（如同步应用设置）。

日志处理的边车容器示例：

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
    - name: main-app
      image: my-app
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
    - name: log-collector
      image: fluentd
      volumeMounts:
        - mountPath: /var/log
          name: shared-logs
  volumes:
    - name: shared-logs
      emptyDir: {}技术支持

边车容器运行 Fluentd，通过共享卷收集主容器的日志。

27. 什么是原生 Sidecars（SidecarContainers），它解决了什么问题？

在 Kubernetes v1.28/1.29 之前，边车容器只是与应用并行运行的普通容器。这会造成“竞态条件”：如果应用在边车（如安全代理或日志转发器）之前启动，应用可能因辅佐组件未就绪而崩溃或丢失数据。

原生 Sidecars 通过允许您在 initContainers 部分定义带有 restartPolicy: Always 的边车来解决这一问题。

• 工作原理： Kubernetes 将它们视为 init 容器，这意味着它们必须成功启动，主应用才会启动。
• 好处： 确保安全代理或日志组件在应用处理首个请求之前已完全就绪。

28. 列举三种常见的 Pod 错误原因及修复方法。

Pods 可能卡在Pending、CrashLoopBackOff 或ImagePullBackOff 状态：

• Pod 卡在 Pending： 检查节点可用性与资源限制。可查看 Pod 事件获取更多信息。
• CrashLoopBackOff： 排查应用日志并检查配置错误。
• ImagePullBackOff： 确认镜像名称与拉取凭据正确。同样检查 Pod 事件以获取更多信息。

可使用 describe 命令查看 Pod 的事件：

kubectl describe pod <pod-name>技术支持

29. 什么是 Kubernetes 的“可变更准入 Webhook”（mutating admission webhook），它如何工作？

可变更准入 Webhook 允许在对象被应用到集群并持久化之前，实时修改 Kubernetes 对象。它在 Kubernetes 中运行一个动态准入控制器，拦截对象持久化到 etcd 前的 API 请求。它可以在放行请求前，通过注入、修改或删除字段来更改请求负载。

常见用途包括：

• 注入边车容器。
• 为 Pods、Deployments 或其他资源设置默认值。
• 强制最佳实践（如自动分配资源限制）。
• 添加安全配置（如要求用于审计追踪的标签）。

30. 如何在 Kubernetes 中实现零停机部署？

零停机部署确保更新不打断在线流量。Kubernetes 通过以下方式实现：

• 滚动更新（默认，逐步以新 Pods 替换旧 Pods）。
• 金丝雀发布（先对部分用户进行测试）。
• 蓝绿部署（在生产与测试环境之间切换）。

Readiness 探针帮助 Kubernetes 避免将流量导向未就绪的 Pods。

31. 什么是自定义资源定义（CRDs），何时应使用？

自定义资源定义（CRD）可扩展 Kubernetes API，允许用户定义并管理自定义资源。适用于需要用 Kubernetes API 管理的特定场景，例如：

• 管理自定义应用（如机器学习模型）。
• 启用 Kubernetes Operators 以实现应用自愈。

CRD YAML 定义示例：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: shirts.stable.example.com
spec:
  group: stable.example.com
  scope: Namespaced
  names:
    plural: shirts
    singular: shirt
    kind: Shirt
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              color:
                type: string
              size:
                type: string
    selectableFields:
    - jsonPath: .spec.color
    - jsonPath: .spec.size
    additionalPrinterColumns:
    - jsonPath: .spec.color
      name: Color
      type: string
    - jsonPath: .spec.size
      name: Size
      type: string技术支持

例如，您现在可以使用 kubectl 检索 shirt 对象：

kubectl get shirts技术支持

了解如何将 Docker 与 Kubernetes 用于机器学习工作流，参见这篇实践教程容器化。

32. 什么是 Kubernetes Operators，它如何工作？

Kubernetes Operator 通过自动化复杂应用的部署、伸缩与管理来扩展 Kubernetes 的功能。它基于 CRDs 与自定义控制器，来处理特定于应用的逻辑。

Operators 的工作方式是定义自定义资源，并监听集群中的变化以自动执行特定任务。

Operator 的关键组成包括：

• 自定义资源定义（CRD）： 定义新的 Kubernetes API 资源。
• 自定义控制器： 监听 CRD，并根据期望状态应用自动化逻辑。
• 协调循环（Reconciliation loop）： 持续确保应用状态与期望状态一致。

33. 什么是 DaemonSet，何时使用？

DaemonSet 确保在集群的每个节点（或部分节点）上都运行某个 Pod 的一份副本。当有新节点加入时，DaemonSet 会自动在其上调度一个 Pod；当节点移除时，该 Pod 会被回收。

DaemonSet 的常见用例：

• 日志采集代理 —— 在每个节点上运行 Fluentd 或 Logstash，以集中采集容器日志。
• 监控代理 —— 如 Prometheus Node Exporter 或 Datadog Agent，需要查看每个节点的指标。
• 网络插件 —— 如 Calico 或 Flannel 等 CNI 插件，需要在每个节点上驻留以管理网络。

最小化的 DaemonSet YAML 定义：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-collector
spec:
  selector:
    matchLabels:
      app: log-collector
  template:
    metadata:
      labels:
        app: log-collector
    spec:
      containers:
      - name: fluentd
        image: fluentd:v1.16
        resources:
          limits:
            memory: "200Mi"
            cpu: "100m"技术支持

面向管理员的 Kubernetes 面试题

Kubernetes 管理员负责为生产工作负载维护、安全与优化集群。本节聚焦集群管理相关的面试问题。

34. 如何备份与恢复 Kubernetes 中的 etcd 集群？

Etcd 是保存整个集群状态的键值存储。定期备份对于避免数据丢失至关重要。

您可以使用以下命令创建备份：

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
  snapshot save <backup-file-location>技术支持

若需从备份恢复，可以运行：

etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db技术支持

35. 如何安全地升级 Kubernetes 集群？

升级 Kubernetes 集群是一个多步骤流程，需要尽量减少停机并保持集群稳定。管理员应遵循结构化流程，以防升级期间出现问题：

1. 在升级前对节点进行 drain，并备份 etcd，确保在失败时可恢复。
2. 先升级控制平面节点。
3. 在控制平面节点上升级 kubelet 与 kubectl。
4. 逐个升级工作节点。升级前必须对每个工作节点执行 drain 以避免干扰工作负载。
5. 升级集群附加组件（如 Ingress 控制器、监控工具等）。

36. 如何监控 Kubernetes 集群？

Kubernetes 管理员需要监控 CPU、内存、磁盘、网络以及应用健康状况。推荐使用以下工具：

• Prometheus + Grafana： 采集与可视化集群指标。创建实时告警，及时发现问题。
• Loki + Fluentd： 日志采集与分析。
• Kubernetes Dashboard： 基于 UI 的集群监控。
• Jaeger/OpenTelemetry： 分布式追踪。

37. 如何保障 Kubernetes 集群的安全？

安全是关键，每位管理员都应遵循最佳实践来保护 Kubernetes 集群：

• 启用 RBAC： 使用 Roles 与 RoleBindings 限制用户权限。
• Pod 安全准入： 使用准入控制器来强制执行 Pod 安全标准。
• 强制执行 NetworkPolicies： 限制 Pod 通信，因为默认所有 Pods 可互通。
• 定期轮换 API 令牌与证书。
• 使用 Secrets 管理： 使用 Vault、AWS Secrets Manager 等工具。

了解 Kubernetes 在云中的实现方式，请参阅我们的使用 AWS Elastic Kubernetes Service（EKS）进行容器编排指南。若您在红帽环境中工作，我们的OpenShift vs. Kubernetes 对比介绍了该托管发行版的差异。

38. 如何设置 Kubernetes 日志？

集中式日志对于调试与审计必不可少。两种不同的日志方案：

• Loki + Fluentd + Grafana（轻量且快速）。
• ELK 堆栈（Elastic、Logstash、Kibana）（可扩展、企业级）。

39. 如何在 Kubernetes 中实现高可用？

高可用对于避免集群中运行的应用停机至关重要。您可以通过以下方式确保高可用：

• 使用多个控制平面节点。 多个 API 服务器可在其中一个故障时避免停机。
• 启用集群自动伸缩器（cluster autoscaler）。 它会根据需求自动增加/移除节点。

40. 如何实现 Kubernetes 集群的多租户？

在企业环境中，多租户至关重要。它允许多个团队或应用安全地共享一个 Kubernetes 集群，且互不干扰。

多租户有两种类型：

1. 软多租户： 使用 Namespaces、RBAC 与 NetworkPolicies 在命名空间层面进行隔离。
2. 硬多租户： 使用虚拟集群或独立控制平面来隔离物理集群（如 KCP）。

41. 如何对存储在 etcd 中的 Kubernetes Secrets 进行加密？

Etcd 存储完整的集群状态，这意味着敏感信息也保存在其中。

默认情况下，Kubernetes 会以未加密形式将 Secrets 存储在 etcd 中，容易受攻击。因此，启用静态加密（encryption at REST）非常重要，以便对存储的 Secrets 进行加密。

第一步，需要创建加密配置文件，并在其中存储加解密密钥：

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <BASE64_ENCODED_SECRET>
      - identity: {}技术支持

上述配置指定 Kubernetes 使用 aescbc 提供程序加密 Secret 资源，并在遇到未加密数据时回退到 identity。

接着需要修改 kube-apiserver 配置文件，通常位于控制平面节点的 /etc/kubernetes/manifests/kube-apiserver.yaml，加入指向您创建的加密配置文件的 -- encryption-provider-config 参数：

command:
  - kube-apiserver
  ...
  - --encryption-provider-config=/path/to/encryption-config.yaml技术支持

保存更改并重启 kube-apiserver 以应用新配置。

42. 如何在多租户环境中管理 Kubernetes 资源配额？

资源配额可防止单一租户（命名空间）过度消耗集群资源，影响其他租户的工作。

您可以为命名空间定义 ResourceQuota，以分配给该命名空间一定量的资源。该命名空间的用户随后可创建资源，直至消耗达到 ResourceQuota 的上限。

ResourceQuota YAML 定义示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: namespace-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"技术支持

您可以使用以下命令查看命名空间的 ResourceQuota：

kubectl describe resourcequota namespace-quota -n team-a技术支持

43. 什么是 CoreDNS？如何配置与使用？

CoreDNS 是 Kubernetes 集群的默认 DNS 提供程序。它提供服务发现，使 Pods 能使用内部 DNS 名称而非 IP 地址进行通信。

CoreDNS 的特性：

• 处理内部 DNS 解析（my-service.default.svc.cluster.local）。
• 支持自定义 DNS 配置。
• 在多个 Pods 之间对 DNS 查询进行负载均衡。
• 支持缓存以提升性能。

您可以使用 kube-system 命名空间中的 ConfigMap 配置 CoreDNS。通过下面的命令查看当前设置：

kubectl get configmap coredns -n kube-system -o yaml技术支持

直接更新该 ConfigMap 并应用更改，即可调整 CoreDNS 配置。

基于场景与问题求解的 Kubernetes 面试题

工程师在真实的 Kubernetes 环境中经常会遇到复杂的可扩展性、网络、安全、性能与故障排查挑战，面试官对此心知肚明。本节给出基于场景的面试题，考察您解决实际 Kubernetes 问题的能力。

44. 调试一个变慢的 Kubernetes 应用

“您的团队报告某个运行在 Kubernetes 上的应用变慢，用户体验到高响应时间。您如何解决？”

可以按以下步骤处理：

1. 检查 Pod 资源利用情况。如接近上限则提升资源。

kubectl top pods --sort-by=cpu
kubectl top pods --sort-by=memory技术支持

2. 描述变慢的 Pod 获取更多信息。关注资源限流、重启次数或 liveness 失败。

kubectl describe pod <pod-name>技术支持

3. 查看容器日志中的报错。查找超时、错误或连接失败。

kubectl logs <pod-name>技术支持

4. 测试网络时延，因为它可能拖慢应用。

kubectl exec -it <pod-name> -- ping my-database
kubectl exec -it <pod-name> -- curl http://my-service技术支持

5. 验证 Kubernetes 节点健康，检查节点资源是否耗尽。

kubectl get nodes
kubectl describe node <node-name>技术支持

45. Nginx Web 服务器在运行，但暴露的 URL 无法连接

“您在 Kubernetes 中部署了 Nginx Web 服务器，Pod 运行正常，但应用无法通过暴露的 URL 访问。怎么办？”

可按以下步骤处理：

1. 验证 Nginx Pod 正在运行且健康。

kubectl get pods -o wide
kubectl describe pod nginx-web技术支持

2. 检查 Service 与端口映射。确保暴露的端口与 Pod 的容器端口匹配，并检查 Service 是否找到正确的 Pods。

kubectl describe service nginx-service技术支持

3. 检查网络策略。若有网络策略阻止入站流量，Service 将不可访问。

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>技术支持

4. 验证 Ingress 与外部 DNS 配置。

kubectl describe ingress nginx-ingress技术支持

46. 升级后 Kubernetes Deployment 失败

“您部署了应用新版本，但无法启动，导致用户停机。如何修复？”

处理思路：

1. 回滚到上一可用版本。

kubectl rollout undo deployment my-app技术支持

2. 查看 Deployment 历史，找出新版本的变更点。

kubectl rollout history deployment my-app技术支持

3. 检查新 Pod 的日志。

kubectl logs -l app=my-app技术支持

4. 检查 readiness 与 liveness 探针。

5. 验证镜像拉取问题。有时新镜像错误或不可用。

47. 应用无法连接外部数据库

“一个运行在 Kubernetes 的微服务无法连接到外部数据库，该数据库托管在集群外。如何修复？”

处理步骤：

1. 在 Pod 内验证外部连通性。检查数据库是否可从 Kubernetes 网络访问。

kubectl exec -it <pod-name> -- curl http://my-database.example.com:5432技术支持

2. 在 Pod 内检查 DNS 解析。若失败，可能是 CoreDNS 配置错误。

kubectl exec -it <pod-name> -- nslookup my-database.example.com技术支持

3. 检查是否存在阻止外部访问的网络策略，因为它们可能会拦截出站流量。

kubectl get networkpolicies
kubectl describe networkpolicy <policy-name>技术支持

48. 集群资源耗尽，致使新 Pods 处于 Pending 状态

“新 Pod 一直处于Pending 状态。进一步查看，提示‘0/3 个节点可用：CPU 与内存不足’。您如何调试并解决？”

处理步骤：

1. 检查集群资源可用性。关注高 CPU/内存使用是否阻止了调度。

kubectl describe node <node-name>
kubectl top nodes技术支持

2. 查找资源消耗最高的 Pods。为 Pods 设置 requests 与 limits，避免过度消耗。也可在全集群范围强制执行。

kubectl top pods --all-namespaces技术支持

3. 缩容非关键工作负载以释放资源。

kubectl scale deployment <deployment-name> --replicas=0技术支持

4. 增加可用节点以提升集群资源。若使用了集群自动伸缩器，也可提高其节点上限。

Kubernetes 面试备考技巧

通过我自己的 Kubernetes 面试经历，我体会到成功不仅仅依赖记忆概念。您需要能在真实场景中应用所学，高效排障，并清晰阐述解决方案。

若想在 Kubernetes 面试中脱颖而出，请遵循以下建议：

1. 掌握 Kubernetes 核心概念。确保理解 Pods、Deployments、Services、Persistent Volumes、ConfigMaps、Secrets 等。
2. 积累 Kubernetes 实操经验。我在备考时发现，自己搭建 Minikube 集群并部署微服务最能加深理解。您也可以使用云厂商的托管 Kubernetes 服务，在更大规模上练习。
3. 学习如何调试 Kubernetes 问题，因为在真实世界中，故障排查是使用 Kubernetes 的重要组成部分。工作中您很可能把大量时间花在应用的排障上。典型问题包括 Pods 卡住、网络故障、持久卷挂载失败与节点故障。
4. 理解 Kubernetes 网络与负载均衡。重点掌握网络实现、Pods 间通信、Service 类型与应用暴露方式。
5. 掌握在 Kubernetes 上扩展与优化工作负载的方法。面试官常问扩展策略与成本优化。熟练掌握 HPA、集群自动伸缩器、资源请求与限制。
6. 理解 Kubernetes 安全最佳实践。熟悉 RBAC、Pod 安全上下文、网络策略与 Secrets 管理。
7. 学习 Kubernetes 架构与内部原理。熟悉控制平面组件，以及 kubelet 与容器运行时如何交互。

在真实集群中动手实践最能将这些知识融会贯通。若能在压力下调试故障 Pod，您基本能应对面试中抛给您的任何问题。

结语

Kubernetes 是一个复杂的容器编排系统，其被几乎所有主要云服务商采纳，足见其在生产基础设施中的核心地位。应聘 Kubernetes 岗位既需要深厚的理论，也需要解决真实问题的能力。无论您是寻求第一份工作的初级工程师，还是谋求更高级别岗位的资深工程师，充分准备始终是关键。

我无法过分强调练习的重要性。它能帮助您更快发现应用问题，并增强信心。

如果您想夯实基础，我强烈推荐我们的容器化与虚拟化概念课程打牢根基，随后学习Kubernetes 入门课程获取实践经验。若您需要系统化的学习路径，可以选择使用 Docker 与 Kubernetes 的容器化与虚拟化技能路径，覆盖完整学习旅程。准备就绪后，不妨考虑Kubernetes 认证来向面试官展示您的能力。

祝您面试顺利！