K8s 面试大挑战：结合实战场景的深度问题

引言

在我面试的这一段时间里，一些面试官会问到像 k8s 中的各个探针都在什么场景下使用，或者 QoS 中的各个策略都在什么场景下使用，等等……

所以我这边就稍微总结下我最近在面试过程中的一些致命要点。

开始

存活探针（Liveness Probe）、就绪探针（Readiness Probe）、启动探针（Startup Probe）的区别及适用场景？

1. 存活探针（Liveness Probe）

• 目的：检测容器是否处于运行状态，若失败则重启容器。

• 适用场景：

a.应用程序因死锁或死循环无法响应请求时自动恢复。

b.例如：Web 服务长时间无响应需强制重启。

• 配置示例

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

2. 就绪探针（Readiness Probe）

• 目的：检测容器是否准备好接收流量，若失败则从 Service 的 Endpoints 中移除。

• 适用场景：

a.应用启动时需要加载大量数据（如缓存预热）。

b.依赖外部服务（如数据库）初始化完成后才可提供服务。

• 配置示例

readinessProbe:
  exec:
    command: ["/bin/check-db-connection.sh"]
  initialDelaySeconds: 10
  periodSeconds: 5

3. 启动探针（Startup Probe）

• 目的：延迟其他探针的启动，直到容器成功启动。

• 适用场景：

a.旧应用启动时间较长（如 Java 应用需数分钟初始化）。

b.避免存活/就绪探针在启动阶段误判导致容器重启。

• 配置示例

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30  # 最长等待 30*5=150 秒
  periodSeconds: 5

2: Kubernetes 的 QoS 分类（Guaranteed、Burstable、BestEffort）及其资源管理策略？

1. Guaranteed

• 条件：所有容器的 CPU/Memory 均设置 limits=requests。

• 资源保障：

a.严格保证资源分配，适用于核心服务（如数据库）。

b.OOM 优先级最低，不易被杀死。

2. Burstable

• 条件：至少一个容器设置了 requests 但未满足 limits=requests。

• 资源弹性：

a.允许突发使用资源，适用于多数应用（如 Web 服务）。

b.OOM 优先级高于 Guaranteed。

3. BestEffort

• 条件：所有容器均未设置 requests 和 limits。

• 资源竞争：

a.资源不足时优先被终止，适用于非关键任务（如批处理作业）。

b.OOM 优先级最高。

3: 如何为 Pod 配置 QoS 策略？举例说明不同场景的选择。

• 配置方法：通过 resources.requests 和 resources.limits 定义资源需求。

场景示例：

1. Guaranteed

containers:
- name: redis
  resources:
    requests:
      cpu: "1"
      memory: "2Gi"
    limits:
      cpu: "1"
      memory: "2Gi"

适用场景：MySQL、Redis 等需要稳定资源的服务。

2. Burstable

containers:
- name: web
  resources:
    requests:
      cpu: "0.5"
      memory: "1Gi"
    limits:
      cpu: "2"
      memory: "4Gi"

适用场景：Web 应用需应对流量高峰。

3. BestEffort

containers:
- name: batch-job
  resources: {}

适用场景：日志清理、临时数据分析任务。

四、 如果一个 Pod 频繁重启，如何通过探针和 QoS 策略排查问题？

1. 检查探针配置

• 确认存活探针是否过于敏感（如检测间隔 periodSeconds 过短）。

• 查看日志确认探针失败原因（如 /healthz 接口超时）。

2. 分析资源限制

• 检查 Pod 的 QoS 类别是否为 BestEffort，导致资源不足被 OOMKill。

• 调整 requests/limits 为 Burstable 或 Guaranteed。

3. 查看事件日志

kubectl describe pod <pod-name>

确认是否因资源不足（OutOfMemory）或探针失败（Liveness probe failed）触发重启。

五、如何通过 QoS 和探针优化高密度集群的资源利用率？

策略：

1. 优先级调度：核心服务设为 Guaranteed，抢占资源能力低但稳定性高。

2. 动态调整：使用 Vertical Pod Autoscaler（VPA）自动优化 requests/limits。

3. 探针精细化：

• 启动探针避免过早检测导致重启。

• 就绪探针确保依赖服务就绪后再接收流量。

6. 在 Kubernetes 中，如何配置资源请求和限制？

资源请求和限制可以在 Pod 的定义文件中通过 resources 字段进行配置。它包括两部分：

• 请求（request）：容器启动时所需的最低资源。Kubernetes 使用请求来决定 Pod 调度到哪个节点。

• 限制（limit）：容器能够使用的最大资源。当容器超过这个限制时，Kubernetes 会限制其资源使用，避免影响其他容器的运行。

例如：

apiVersion: v1
kind:Pod
metadata:
name:mypod
spec:
containers:
-name:mycontainer
    image:myimage
    resources:
      requests:
        memory:"64Mi"
        cpu:"250m"
      limits:
        memory:"128Mi"
        cpu: "500m"

七、Kubernetes 中的 Horizontal Pod Autoscaler（HPA）是如何工作的？

Horizontal Pod Autoscaler（HPA）根据 Pod 的 CPU 使用率或其他自定义指标，自动调整 Pod 的副本数。HPA 通过持续监控指标，并根据设定的阈值（如 CPU 或内存）来自动扩展或缩减 Pod 数量。配置 HPA 时，需要指定最小副本数、最大副本数和目标指标。

例如，下面是一个基于 CPU 使用率的 HPA 配置示例：

apiVersion: autoscaling/v2
kind:HorizontalPodAutoscaler
metadata:
name:myapp-hpa
spec:
scaleTargetRef:
    apiVersion:apps/v1
    kind:Deployment
    name:myapp
minReplicas:1
maxReplicas:10
metrics:
type:Resource
resource:
name:cpu
target:
    type:Utilization
    averageUtilization: 50

8. Kubernetes 中如何进行 Pod 弹性伸缩？

Pod 弹性伸缩可以通过以下几种方式实现：

• Horizontal Pod Autoscaler（HPA）：根据 CPU、内存或自定义指标来动态增加或减少 Pod 的副本数。

• Vertical Pod Autoscaler（VPA）：根据 Pod 使用的资源自动调整其 CPU 和内存的请求和限制。

• Cluster Autoscaler：自动调整集群的规模，根据节点的资源需求自动增加或减少节点的数量。

9. Kubernetes 中的资源限制和请求设置为什么重要？

设置资源请求和限制对于确保集群资源合理分配非常重要：

• 资源请求：确保每个容器在节点上获得足够的资源，可以保证应用的正常运行。

• 资源限制：防止容器使用过多资源，影响其他容器的正常运行。特别是在高负载场景中，合理设置资源限制可以避免资源竞争，保证整个系统的稳定性。

十、如何使用 Kubernetes 进行资源隔离？

Kubernetes 提供了多种方式来实现资源隔离：

• Namespace：用于将集群中的资源划分为不同的虚拟集群，不同的团队或应用可以在不同的命名空间中工作，互不干扰。

• Resource Requests and Limits：通过资源请求和限制来确保每个容器有足够的资源，并防止资源争夺。

• Node Affinity and Taints/Tolerations：通过节点亲和性、污点和容忍度来限制某些 Pod 只能在特定节点上运行，从而实现更细粒度的资源隔离。

十一、Kubernetes 中如何实现 Pod 的高可用性？

Kubernetes 提供了多种方式来确保 Pod 的高可用性：

• 副本集（ReplicaSet）：通过 ReplicaSet 来确保某个 Pod 的副本数始终保持在指定数量。ReplicaSet 可以自动创建和删除 Pod，以确保所需数量的 Pod 始终运行。

• 部署（Deployment）：Deployment 是一种管理 Pod 副本集的控制器，支持滚动更新和回滚，确保服务可用。

• Pod Disruption Budgets（PDB）：通过 Pod Disruption Budgets 来限制可以同时被中断的 Pod 数量，确保在升级或维护时，至少有一定数量的 Pod 在运行。

• • 多节点调度：通过分布式调度和 Affinity 策略，将 Pod 调度到多个物理节点上，避免单点故障。

十二、Kubernetes 如何处理网络通信？

Kubernetes 使用 CNI（容器网络接口） 来处理网络通信。以下是 Kubernetes 网络的关键概念：

• Pod 网络：每个 Pod 在集群中都有自己的 IP 地址，所有 Pod 都可以直接相互通信，无需 NAT。Kubernetes 通过 CNI 插件（如 Calico、Flannel、Weave）实现 Pod 网络。

• 服务（Service）：Kubernetes 中的服务提供了对外暴露应用的方式，使用服务的 ClusterIP、NodePort 或 LoadBalancer 类型，可以使 Pod 对外可访问。

• DNS：Kubernetes 集群内自动为每个服务分配一个 DNS 名称，使得 Pod 通过 DNS 进行服务发现和通信。

十三、Kubernetes 中如何进行资源的限额管理（Resource Quota）？

资源配额（ResourceQuota）用于限制一个命名空间中可以使用的资源量，避免单个团队或应用消耗过多资源，影响集群的稳定性。通过定义资源配额来管理 CPU、内存、Pod 数量等。

例如：

apiVersion: v1
kind:ResourceQuota
metadata:
name:example-quota
spec:
hard:
    cpu:"10"
    memory:50Gi
    pods: "10"

十四、Kubernetes 中的 Taints 和 Tolerations 如何工作？

Taints 和 Tolerations 是 Kubernetes 用来控制 Pod 调度的机制：

• • Taints：是节点上设置的标记，表示某些 Pod 不应该调度到该节点，除非它们能够容忍这个 taint。Taints 定义了节点的“污点”。
• • Tolerations：是 Pod 上设置的标记，表示该 Pod 可以容忍某些节点上的 Taints。只有当 Pod 能够容忍节点上的 Taints 时，才能调度到该节点。

通过 Taints 和 Tolerations，可以实现对特定节点的调度控制，如避免将某些 Pod 调度到资源紧张或不合适的节点上。

十五、Kubernetes 中如何实现服务发现（Service Discovery）？

Kubernetes 内建的服务发现机制使得集群内的 Pod 和服务能够轻松相互发现和通信。Kubernetes 使用 DNS 来实现服务发现，每个服务都会自动分配一个 DNS 名称，其他 Pod 可以通过该名称访问该服务。例如，如果创建了一个名为 myapp 的服务，它会自动在 DNS 中分配一个 myapp.default.svc.cluster.local 的地址，集群内的其他 Pod 可以通过这个地址访问该服务。

十六、 Kubernetes 的 Pod 生命周期是如何管理的？

Kubernetes Pod 的生命周期包括以下几个阶段：

• Pending：Pod 已被调度到节点，但容器还没有启动。

• Running：Pod 的容器已经启动并正在运行。

• Succeeded：Pod 中的所有容器都成功终止并完成任务。

• Failed：Pod 中的容器已终止且失败，无法重新启动。

• • Unknown：Kubernetes 无法确定 Pod 的状态，通常是由于与节点的通信失败。

Kubernetes 通过控制器（如 Deployment、StatefulSet 等）来管理 Pod 的生命周期，确保在 Pod 失败或被删除时，可以自动恢复或创建新的 Pod。

十七、Kubernetes 中如何实现网络策略（NetworkPolicy）？

NetworkPolicy 用于控制 Pod 之间的通信，通过定义规则来限制或允许流量。前提是你的 CNI 支持 NetworkPolicy，比如 Calico 就支持。

它可以基于 Pod 标签、命名空间、IP 地址等进行访问控制。它支持 Ingress（流入）和 Egress（流出）规则。 例如，允许只有标签为 role=frontend 的 Pod 可以访问标签为 role=backend 的 Pod：

apiVersion: networking.k8s.io/v1
kind:NetworkPolicy
metadata:
name:allow-frontend-to-backend
spec:
podSelector:
    matchLabels:
      role:backend
ingress:
-from:
    -podSelector:
        matchLabels:
          role: frontend

十八、Kubernetes 中如何处理节点故障？

Kubernetes 使用节点监控和调度策略来处理节点故障：

• 节点监控：Kubernetes 的 kubelet 组件定期向 master 节点报告节点状态，如果某个节点长时间无法与 master 节点通信，Kubernetes 会标记该节点为不可用（NotReady）。

• Pod 重新调度：当节点发生故障，调度器会重新将 Pod 调度到其他健康节点上。为了保证 Pod 高可用，可以配置 PodDisruptionBudget 和 ReplicaSet，确保 Pod 可以在其他节点上运行。

十九、Kubernetes 中的 StatefulSet 与 Deployment 有什么区别？

StatefulSet 和 Deployment 都是用于管理 Pod 的控制器，但它们适用于不同类型的应用：

• Deployment：适用于无状态应用，Pod 的副本可以相互替换，Pod 的名字和顺序没有重要意义。

• StatefulSet：适用于有状态应用，需要保持 Pod 的唯一标识和顺序。StatefulSet 会为每个 Pod 提供一个稳定的持久存储和网络标识。

二十、 Kubernetes 中的 PersistentVolume（PV）和 PersistentVolumeClaim（PVC）是什么？它们如何工作？

Kubernetes 中的 PersistentVolume（PV） 和 PersistentVolumeClaim（PVC） 是用于管理持久存储的资源：

• PersistentVolume（PV）：是集群中的一个存储资源，它表示一个具体的存储设备，可能是一个 NFS 存储、云存储（如 AWS EBS）或本地磁盘等。

• PersistentVolumeClaim（PVC）：是用户向 Kubernetes 申请持久存储的一种方式，它定义了所需存储的大小、访问模式等要求。Kubernetes 根据 PVC 自动绑定适当的 PV。

这种机制支持存储资源的动态分配，确保存储的生命周期与 Pod 分离，Pod 可以访问到持久存储。

二十一、 Kubernetes 中的监控和日志如何结合使用？

Kubernetes 的监控和日志结合使用可以帮助开发和运维人员更好地掌握集群状态和故障排查：

• 监控：使用 Prometheus 来收集集群和应用的指标（如 CPU、内存、网络流量等），通过 Grafana 可视化展示。

• 日志管理：使用 ELK Stack（Elasticsearch、Logstash、Kibana）来集中管理和查询 Kubernetes 的日志。

• 集成：将 Prometheus 和 Grafana 与日志管理工具（如 Fluentd 或 Filebeat）集成，通过统一的面板和报警系统，提高监控和日志的响应效率。

二十二、Kubernetes 中如何处理存储资源的动态供给？

Kubernetes 通过 StorageClass 和 动态存储供给（Dynamic Provisioning） 实现存储资源的自动化管理。通过定义 StorageClass，用户可以自动为 PVC 申请合适的存储类型（如 SSD、HDD 或云存储）。

• 使用 StorageClass，可以定义不同存储类型的参数，并在 PVC 中指定该 StorageClass，Kubernetes 会根据该配置自动创建和绑定 PV。

二十三、Kubernetes 中的 Affinity 和 Anti-Affinity 是如何工作的？

Kubernetes 中的 Affinity 和 Anti-Affinity 是控制 Pod 调度策略的机制，用于指定 Pod 在节点上的调度规则：

• Affinity：允许指定 Pod 在相同节点上调度，或在特定条件下与其他 Pod 调度在一起。例如，可以使用 nodeAffinity 让 Pod 只调度到特定标签的节点上。

• Anti-Affinity：用于确保 Pod 不与其他指定的 Pod 调度在同一节点或同一可用区。例如，可以确保某些 Pod 在不同节点上运行，以避免单点故障。

二十四、 Kubernetes 中如何处理 Pod 的优先级和抢占？

Kubernetes 支持通过 PodPriority 和 PriorityClass 来设置 Pod 的优先级。高优先级的 Pod 可以抢占低优先级的 Pod 资源，确保关键服务优先运行。

• PriorityClass：通过为 Pod 设置不同的优先级，控制 Pod 在资源争夺时的调度顺序。

• Pod抢占：如果集群资源紧张，Kubernetes 会终止优先级较低的 Pod 来为高优先级的 Pod 提供资源。

二十五、 Kubernetes 中的 Ingress 和 Egress 是如何控制流量的？

Kubernetes 提供了 Ingress 和 Egress 控制流量进出集群的方式：

• Ingress：是一种 API 资源，允许外部流量通过 HTTP/HTTPS 访问 Kubernetes 内部服务。Ingress 通常由 Ingress Controller 实现（如 Nginx Ingress Controller）。

• Egress：是集群内的 Pod 发起的流量访问外部网络。可以通过配置 NetworkPolicy 来控制 Pod 的出站流量，限制哪些 Pod 可以访问外部服务。

二十六、Kubernetes 中的 RBAC（Role-Based Access Control）如何控制权限？

RBAC 是 Kubernetes 中的权限管理系统，用于控制用户或服务账户在集群中的操作权限。RBAC 通过定义 Role 和 RoleBinding 来授予权限：

• Role：定义在某个命名空间内的权限，如访问资源的权限（Pods、Services 等）。

• ClusterRole：定义集群范围内的权限。

• RoleBinding 和 ClusterRoleBinding：将 Role 或 ClusterRole 绑定到特定的用户或服务账户。

二十七、Kubernetes 中如何处理事件日志？

Kubernetes 中的事件日志用于记录集群状态和各类事件，如 Pod 启动、容器重启、资源限制等。可以使用 kubectl get events 命令查看事件日志。

• Kubernetes 中的事件是由 Kubelet、Controller Manager 等组件生成的。

• 集成日志管理：可以使用 Fluentd、Elasticsearch 和 Kibana（ELK Stack） 等工具来集中管理和分析 Kubernetes 事件日志。

二十八、 Kubernetes 中的 PodDisruptionBudget（PDB）是什么？如何使用？

PodDisruptionBudget（PDB）用于控制 Pod 的可中断性，确保在升级或维护时至少有一定数量的 Pod 处于运行状态。PDB 通过定义 maxUnavailable 或 minAvailable 来保证在允许的范围内，Pod 可以被中断。

例如，设置一个 PDB，确保最多只能有一个 Pod 被中断：

apiVersion: policy/v1
kind:PodDisruptionBudget
metadata:
name:myapp-pdb
spec:
minAvailable:2
selector:
    matchLabels:
      app: myapp

二十九、Kubernetes 中的资源管理器（Resource Manager）如何确保集群资源的公平分配？

Kubernetes 的资源管理器（Scheduler） 通过以下方式确保资源的公平分配：

• 资源请求和限制：每个 Pod 在调度时，Kubernetes 会根据资源请求和限制来选择最合适的节点。

• QoS 策略：通过 QoS 类别（Guaranteed、Burstable、BestEffort）来管理 Pod 的优先级和资源分配。

• 调度策略：如资源亲和性、节点亲和性等，帮助在资源有限的情况下，做出最合适的资源调度决策。