Kubernetes 面试：实战场景融合的深度问题揭秘

引言

在近期的面试历程中，不少面试官会抛出诸如“k8s中各类探针在何种场景下运用”“QoS里各个策略适用于哪些场景”等问题。鉴于此，我对面试过程中遭遇的关键要点进行了梳理总结，期望能为大家提供一些参考。

正文

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

存活探针（Liveness Probe）

• 目的：用于检测容器是否正在正常运行，若检测失败，系统将重启该容器，以此确保应用始终处于可工作状态。
• 适用场景：
  • 当应用程序出现死锁或陷入死循环，进而无法响应外部请求时，存活探针可自动触发恢复机制。
  • 比如，Web服务长时间没有响应客户端请求，此时存活探针可通过重启容器来恢复服务正常运行。
• 配置示例

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

就绪探针（Readiness Probe）

• 目的：判断容器是否已准备好接收流量。若就绪探针检测失败，该容器将从Service的Endpoints中移除，避免流量被发送到尚未就绪的容器上。
• 适用场景：
  • 应用启动时，若需要加载大量数据，如进行缓存预热操作，此时可利用就绪探针，确保数据加载完成后才接收流量。
  • 当应用依赖外部服务，如数据库，只有在数据库初始化完成后，应用才能对外提供服务，就绪探针可用于保障这一流程。
• 配置示例

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

启动探针（Startup Probe）

• 目的：启动探针的主要作用是延迟其他探针的启动时间，直至容器成功启动。这有助于避免在容器启动初期，由于存活探针或就绪探针过早介入检测，导致误判并重启容器。
• 适用场景：
  • 对于一些旧应用，其启动过程可能较为耗时，例如Java应用，初始化过程可能需要数分钟时间，此时启动探针可有效防止探针过早检测。
  • 防止存活/就绪探针在容器启动阶段因判断失误，而导致容器被不必要地重启。
• 配置示例

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

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

Guaranteed

• 条件：当Pod内所有容器的CPU和Memory资源设置均满足limits=requests时，该Pod将被赋予Guaranteed的QoS等级。
• 资源保障：
  • 系统会严格保证这类Pod的资源分配，非常适用于核心服务，如数据库服务，确保其稳定运行不受资源波动影响。
  • 在面临内存不足（OOM）等情况时，Guaranteed类别的Pod具有最低的被杀死优先级，最大程度保障其持续运行。

Burstable

• 条件：只要Pod内至少有一个容器设置了requests，但未满足limits=requests条件，该Pod就会被划分为Burstable类别。
• 资源弹性：
  • 此类Pod允许在一定范围内突发使用资源，能够较好地适应多数应用的运行特点，例如Web服务，在流量高峰时可临时获取更多资源。
  • 在OOM场景下，Burstable类别的Pod优先级高于Guaranteed，意味着在资源紧张时，它比Guaranteed类Pod更有可能被牺牲以保障系统整体稳定。

BestEffort

• 条件：当Pod内所有容器均未设置requests和limits时，该Pod将被归类为BestEffort。
• 资源竞争：
  • 在资源不足的情况下，BestEffort类Pod会被优先终止，适合运行非关键任务，比如批处理作业，即使被终止也不会对系统核心功能造成影响。
  • 在OOM优先级排序中，BestEffort类Pod处于最高级别，即最容易被系统杀死以释放资源。

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

• 配置方法：通过在Pod定义文件中的resources.requests和resources.limits字段，明确容器对资源的请求和限制，从而确定Pod的QoS策略。

场景示例

Guaranteed

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

适用场景：像MySQL、Redis等对资源稳定性要求极高的服务，采用Guaranteed策略可确保其稳定运行，不受资源波动干扰。

Burstable

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

适用场景：Web应用通常面临流量高峰低谷的波动，Burstable策略可让其在流量高峰时利用额外资源，低谷时又不浪费过多资源，实现资源的高效利用。

BestEffort

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

适用场景：日志清理、临时数据分析任务等非关键任务，即便在资源紧张时被终止，也不会对系统核心业务产生重大影响，适合采用BestEffort策略。

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

检查探针配置

• 首先需要确认存活探针的配置是否过于敏感。例如，检测间隔periodSeconds设置得过短，可能导致频繁检测，增加误判重启的概率。
• 通过查看相关日志，明确探针失败的具体原因，如/healthz接口超时等，以便针对性调整探针配置或修复应用问题。

分析资源限制

• 检查Pod的QoS类别是否为BestEffort。由于BestEffort类Pod在资源不足时极易被OOMKill，从而引发频繁重启。
• 根据实际情况，尝试调整Pod的requests/limits设置，将其QoS类别变更为Burstable或Guaranteed，以增强资源保障，观察是否解决重启问题。

查看事件日志

使用命令kubectl describe pod <pod-name>，查看Pod的详细事件日志。从中确认是否因资源不足（OutOfMemory）或探针失败（Liveness probe failed）等原因触发了重启操作，为进一步排查和解决问题提供线索。

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

策略

• 优先级调度：将核心服务的QoS类别设置为Guaranteed，虽然这类服务抢占资源能力较低，但能保证其运行的稳定性，避免因资源竞争而出现故障，确保集群核心功能正常运转。
• 动态调整：借助Vertical Pod Autoscaler（VPA）工具，自动对Pod的requests/limits进行优化。根据应用实际运行时的资源使用情况，动态调整资源请求和限制，提高资源利用效率，同时避免资源浪费或不足。
• 探针精细化：
  • 合理设置启动探针，确保其在容器启动初期发挥作用，避免其他探针过早检测，减少因误判导致的容器重启，保障容器顺利启动。
  • 优化就绪探针配置，精准判断应用依赖的服务是否已全部就绪，只有在依赖服务准备好后，才让容器接收流量，防止因依赖服务未就绪而导致的服务不可用或资源浪费。

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

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

• 请求（request）：代表容器启动时所需的最低资源量。Kubernetes依据这些请求信息，来决定将Pod调度到哪个节点上，以保障每个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"

7. Kubernetes中的Horizontal Pod Autoscaler（HPA）是如何工作的？

Horizontal Pod Autoscaler（HPA）能够依据Pod的CPU使用率或者其他自定义指标，自动对Pod的副本数量进行动态调整。它通过不间断地监控各项指标，并参照预先设定的阈值（例如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弹性伸缩？

在Kubernetes环境下，Pod弹性伸缩可以通过以下几种方式达成：

• Horizontal Pod Autoscaler（HPA）：依据CPU、内存使用情况或者自定义指标，动态地增加或者减少Pod的副本数量。在业务流量出现较大波动时，HPA能够自动调节Pod副本数，保障应用服务的性能与稳定性。例如，电商平台在促销活动期间，流量剧增，HPA可自动增加后端服务的Pod副本，提升处理能力；活动结束后，又能减少副本，避免资源浪费。
• Vertical Pod Autoscaler（VPA）：根据Pod实际运行过程中对资源的使用状况，自动对其CPU和内存的请求与限制进行合理调整。它能让Pod在不同负载阶段，精准获取所需资源，避免资源过度分配或者不足。比如，对于一些计算任务型的Pod，在任务高峰期可能需要更多CPU资源，VPA可自动调整；而在任务空闲期，又能降低资源占用。
• Cluster Autoscaler：自动对集群的规模进行灵活调整。它会根据节点的资源需求情况，智能地自动增加或者减少节点数量。当集群内Pod的资源需求持续增长，现有节点资源不足时，Cluster Autoscaler可添加新节点；若部分节点资源长期空闲，也能将其移除，从而优化集群资源配置，降低成本。

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

在Kubernetes集群中，设置资源请求和限制对于确保集群资源的合理分配与高效利用具有至关重要的意义：

• 资源请求：通过明确每个容器启动和运行所需的最低资源量，能保证应用在运行过程中获得足够的资源支持，从而正常、稳定地运行。例如，一个数据库容器，设置合理的CPU和内存请求，可确保数据库服务能够高效处理数据读写操作，避免因资源不足导致性能下降、服务中断等问题。
• 资源限制：为容器使用资源的上限设定边界，防止单个容器过度占用资源，进而影响其他容器的正常运行。特别是在高负载场景下，合理的资源限制可有效避免资源竞争，维持整个系统的稳定性。比如，在一个共享节点上运行多个不同服务的容器，如果没有资源限制，某个高负载容器可能会耗尽节点的CPU或内存资源，致使其他容器无法正常工作；而设置了资源限制，每个容器都只能在规定范围内使用资源，保障了各个容器的运行环境。

10. 如何使用Kubernetes进行资源隔离？

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

• Namespace：它就像是将集群资源划分为一个个独立的虚拟集群。不同的团队或者应用程序可以在各自独立的命名空间中开展工作，彼此之间互不干扰。例如，开发团队、测试团队和生产团队可以分别使用不同的命名空间，各自的资源、配置等相互隔离，开发测试过程不会影响生产环境的稳定性。
• Resource Requests and Limits：借助资源请求和限制机制，能够确保每个容器都能获取到满足其运行所需的足够资源，同时有效防止资源的过度争夺。比如，为每个容器设置明确的CPU和内存请求与限制，可保证多个容器在同一节点上运行时，不会因为资源竞争而导致部分容器运行异常。
• Node Affinity and Taints/Tolerations：通过节点亲和性、污点和容忍度等配置，可以精确限制某些Pod只能在特定节点上运行，从而实现更为细致的资源隔离。例如，对于一些对计算性能要求极高的Pod，可以设置节点亲和性，使其仅在配置了高性能CPU的节点上运行；而对于某些节点存在特殊硬件或软件限制时，可通过设置污点，只有具有相应容忍度的Pod才能被调度到该节点上。

11. Kubernetes中如何实现Pod的高可用性？

在Kubernetes中，为确保Pod具备高可用性，提供了多种行之有效的方式：

• 副本集（ReplicaSet）：借助ReplicaSet，可以确保指定Pod的副本数量始终维持在设定的数值。它具备自动创建和删除Pod的能力，无论在何种情况下，都能保证所需数量的Pod处于正常运行状态。例如，一个Web服务需要始终保持5个Pod副本提供服务，即使其中某个Pod因故障停止运行，ReplicaSet会立即创建新的Pod来补充，确保服务的连续性。
• 部署（Deployment）：Deployment作为一种用于管理Pod副本集的控制器，不仅支持滚动更新功能，可在不中断服务的情况下，逐步将新版本的Pod替换旧版本；还支持回滚操作，当更新出现问题时，能够快速回退到上一个稳定版本，全方位确保服务的可用性。比如，在对一个在线商城的后端服务进行版本更新时，Deployment可采用滚动更新方式，每次更新少量Pod，观察其运行状态，确保整个更新过程中商城服务不中断；若更新后发现新功能存在严重问题，可立即回滚到旧版本。
• Pod Disruption Budgets（PDB）：通过设置Pod Disruption Budgets，能够限制在同一时刻可以被中断的Pod数量。在进行集群升级、节点维护等操作时，PDB可确保至少有一定数量的Pod持续运行，保障关键业务不受影响。例如，对于一个分布式数据库系统，在对部分节点进行软件升级时，PDB可保证有足够数量的数据库Pod正常工作，维持数据库服务的读写功能。
• 多节点调度：利用分布式调度机制以及Affinity策略，Kubernetes会将Pod调度到多个不同的物理节点上运行。这样一来，即使某个节点出现故障，其他节点上的Pod依然能够继续提供服务，有效避免了单点故障问题。比如，将一个大型电商平台的多个后端服务Pod分散调度到不同地区的多个物理节点上，若某个地区的节点因网络故障或硬件问题无法工作，其他地区节点上的Pod可迅速承接流量，保证平台正常运营。

12. Kubernetes如何处理网络通信？

Kubernetes借助CNI（容器网络接口）来高效处理网络通信，以下是Kubernetes网络的几个关键概念：

• Pod网络：在Kubernetes集群中，每个Pod都被分配了独立的IP地址，所有Pod之间可以直接进行通信，无需经过网络地址转换（NAT）。Kubernetes通过各类CNI插件（如Calico、Flannel、Weave等）来构建和管理Pod网络。例如，Calico插件基于BGP协议，能够实现高效的网络路由和策略控制，保障Pod间网络通信的稳定与安全；Flannel则通过构建覆盖网络，为Pod提供简单、高效的网络连接。
• 服务（Service）：在Kubernetes体系中，服务为对外暴露应用提供了便捷方式。通过使用服务的ClusterIP、NodePort或LoadBalancer类型，可使Pod对外能够被访问。ClusterIP类型为服务分配一个集群内部的虚拟IP地址，用于集群内Pod之间的通信；NodePort类型在每个节点上开放一个特定端口，将外部流量转发到对应的服务；LoadBalancer类型则借助云提供商的负载均衡器，将外部流量引入集群内的服务，适用于面向公网的应用服务。
• DNS：Kubernetes集群会自动为每个服务分配一个DNS名称，这使得Pod可以通过DNS进行服务发现和相互通信。当创建一个名为myapp的服务时，它会在DNS中自动被分配一个myapp.default.svc.cluster.local的地址，集群内的其他Pod仅需通过这个地址，就能轻松访问该服务，极大地简化了服务间的通信配置与管理。

13. Kubernetes中如何进行资源的限额管理（Resource Quota）？

资源配额（ResourceQuota）的主要作用是对一个命名空间中能够使用的资源量加以限制，以此避免单个团队或者应用过度消耗资源，从而影响整个集群的稳定性。可以通过定义资源配额来对CPU、内存、Pod数量等资源进行管理。

例如：

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

在上述示例中，为名为example-quota的资源配额设定了限制：在对应的命名空间中，总的CPU使用量不能超过10核，内存使用量不能超过50Gi，同时Pod的总数不能超过10个。通过这种方式，能够有效控制命名空间内资源的使用上限，保障集群资源的合理分配与高效利用。

14. Kubernetes中的Taints和Tolerations如何工作？

Taints和Tolerations是Kubernetes用于精准控制Pod调度的重要机制：

• Taints：它是设置在节点上的一种标记，表明某些Pod不应该被调度到该节点，除非这些Pod能够容忍这个taint。Taints就像是给节点打上了“污点”标签，例如，某个节点正在进行硬件维护，可设置一个taint，使得正常业务的Pod不会被调度到该节点，避免对业务产生影响。
• Tolerations：这是设置在Pod上的标记，用于表示该Pod能够容忍某些节点上的Taints。只有当Pod具备与节点taint相匹配的容忍度时，它才能够被调度到该节点。比如，有一个专门用于处理临时任务的Pod，它可以设置相应的toleration，使其能够被调度到存在特定taint的节点上运行，充分利用节点资源。

通过Taints和Tolerations的协同工作，可以实现对特定节点的精细调度控制，例如，将某些对资源要求特殊、或者运行不稳定的Pod，合理地调度到合适的节点上，同时避免将关键业务Pod调度到资源紧张、存在故障隐患或不适合的节点上，提升集群整体的稳定性和资源利用效率。

15. Kubernetes中如何实现服务发现（Service Discovery）？

Kubernetes内置了功能强大的服务发现机制，这使得集群内的Pod和服务之间能够轻松实现相互发现与通信。Kubernetes主要通过DNS来实现服务发现功能，在创建服务时，每个服务都会被自动分配一个DNS名称。

例如，当创建了一个名为myapp的服务后，它会在DNS中自动被分配一个myapp.default.svc.cluster.local的地址。集群内的其他Pod在需要访问该服务时，只需通过这个DNS地址，就能够准确找到对应的服务并进行通信。这种基于DNS的服务发现方式，极大地简化了集群内服务之间的连接配置与管理流程，无需手动配置复杂的IP地址和端口信息，提高了应用的部署与维护效率，保障了服务间通信的稳定性和可靠性。

16. Kubernetes的Pod生命周期是如何管理的？

Kubernetes中Pod的生命周期涵盖以下几个重要阶段：

• Pending：此时Pod已经被调度到某个节点，但容器还未启动。可能是由于镜像拉取、资源准备等原因导致容器尚未开始运行。例如，当Pod所需要的镜像文件较大，网络下载速度较慢时，Pod会在Pending状态停留一段时间。
• Running：Pod内的容器已经成功启动，并且正在正常运行，能够对外提供服务。在这个阶段，Pod处于稳定工作状态，执行其既定的业务逻辑。
• Succeeded：Pod中的所有容器都已经成功完成任务并正常终止。通常用于表示一些一次性的任务，如数据处理脚本、备份任务等，当任务执行完毕且没有错误时，Pod进入Succeeded状态。
• Failed：Pod中的容器在运行过程中出现故障并终止，且无法通过重启策略重新启动。这可能是由于程序代码错误、资源不足、依赖服务不可用等多种原因导致。例如，容器内的应用程序发生空指针异常，导致进程崩溃，Pod就会进入Failed状态。
• Unknown：Kubernetes无法确切获取Pod的当前状态，这种情况通常是由于与节点的通信出现故障所致。比如，节点网络中断、kubelet服务异常等，使得Kubernetes无法从节点获取Pod的状态信息。

Kubernetes借助各种控制器（如Deployment、StatefulSet等）来全面管理Pod的生命周期。这些控制器能够实时监控Pod的运行状态，一旦发现Pod出现故障或者被意外删除，会自动依据预设的策略进行恢复或创建新的Pod，确保应用服务的持续稳定运行。例如，Deployment控制器在管理无状态应用的Pod时，会定期检查Pod副本数量是否符合预期，若有Pod失败，会立即创建新的Pod进行替换；StatefulSet控制器则针对有状态应用的Pod，在Pod故障恢复时，会确保Pod的顺序和唯一性，保障应用数据的一致性和完整性。

17. Kubernetes中如何实现网络策略（NetworkPolicy）？

NetworkPolicy是Kubernetes用于精细控制Pod之间通信的重要手段，它通过定义一系列规则，来实现对流量的限制或允许。需要注意的是，要使用NetworkPolicy，前提是所采用的CNI支持该功能，例如Calico就对其提供了良好的支持。

NetworkPolicy可以基于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

在上述配置中，通过podSelector指定了目标Pod为具有role=backend标签的Pod集合，ingress规则则定义了允许来自具有role=frontend标签的Pod的流量进入，从而实现了基于Pod标签的网络访问控制，有效保障了集群内网络通信的安全性和合理性。

18. Kubernetes中如何处理节点故障？

Kubernetes主要运用节点监控和调度策略来妥善处理节点故障问题：

• 节点监控：Kubernetes的kubelet组件承担着定期向master节点报告节点状态的重要职责。若某个节点在较长时间内无法与master节点进行通信，Kubernetes会敏锐地将该节点标记为不可用（NotReady）状态。例如，当节点的网络出现故障，导致无法向master节点发送心跳信息时，kubelet就会检测到异常，并将节点状态上报给master节点。
• Pod重新调度：一旦节点发生故障，Kubernetes的调度器会迅速做出反应，将原本运行在故障节点上的Pod重新调度到其他健康节点上。为了进一步保障Pod的高可用性，还可以通过配置PodDisruptionBudget和ReplicaSet来实现。PodDisruptionBudget能够限制在同一时刻可以被中断的Pod数量，确保在节点维护、升级等操作过程中，仍有足够数量的Pod正常运行；ReplicaSet则负责确保Pod的副本数量始终维持在设定的数值，当有Pod因节点故障而停止运行时，ReplicaSet会自动创建新的Pod，保障服务的连续性。例如，在一个包含多个节点的集群中，若某个节点突然断电，调度器会立即将该节点上运行的Pod重新分配到其他正常节点上，同时结合PodDisruptionBudget和ReplicaSet的配置，保证关键业务服务不受影响，用户体验不出现明显波动。

19. Kubernetes中的StatefulSet与Deployment有什么区别？

StatefulSet和Deployment均为Kubernetes中用于管理Pod的关键控制器，但它们各自适用于不同类型的应用场景：

• Deployment：主要适用于无状态应用。在无状态应用中，Pod的各个副本之间具有可互换性，Pod的名字和启动顺序通常不具有特殊意义。Deployment在管理这类应用时，能够高效地进行滚动更新、回滚等操作，确保应用的持续可用和版本管理。例如，一个普通的Web前端服务，多个前端Pod可以均匀地分担用户请求，每个Pod处理的业务逻辑和数据都是相同的，此时使用Deployment进行管理，能够方便地进行版本升级，在不中断服务的情况下逐步替换旧版本Pod为新版本。
• StatefulSet：专门适用于有状态应用。这类应用对Pod的唯一标识和顺序有严格要求。StatefulSet会为每个Pod提供稳定的持久存储和网络标识，确保在Pod重新调度、重启等过程中，其状态和数据的一致性得以维护。例如，一个分布式数据库系统，每个数据库实例都有自己独立的数据存储和特定的网络地址，需要保证在集群扩展、节点故障恢复等情况下，每个实例的状态和数据不丢失且能够正确恢复，此时StatefulSet就能发挥其优势，通过为每个Pod分配唯一的标识和稳定的存储，保障有状态应用的正常运行。

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

在Kubernetes中，PersistentVolume（PV）和PersistentVolumeClaim（PVC）是用于高效管理持久存储的核心资源：

• PersistentVolume（PV）：它代表着集群中的一个实际存储资源，这个资源可能是一个NFS 存储、云存储（如 AWS EBS）或本地磁盘等。PV 是由集群管理员预先创建和配置的，它独立于 Pod 的生命周期，为应用提供了持久化存储的基础。例如，在一个基于云服务的 Kubernetes 集群中，管理员可以创建一个使用 AWS EBS 作为存储后端的 PV，将其容量、访问模式等参数进行设定，以便后续被 Pod 使用。
• PersistentVolumeClaim（PVC）：这是用户向 Kubernetes 申请持久存储的一种方式。用户通过 PVC 定义所需存储的大小、访问模式等具体要求。Kubernetes 会根据 PVC 的请求，自动在可用的 PV 中寻找合适的对象进行绑定。例如，一个应用程序需要 10GB 的读写存储，用户可以创建一个请求 10GB 存储且读写模式为 ReadWriteOnce 的 PVC，Kubernetes 会在已有的 PV 中查找满足该条件的 PV 并完成绑定。

这种 PV 和 PVC 的机制支持存储资源的动态分配，将存储的生命周期与 Pod 分离，使得 Pod 可以方便地访问到持久存储。当 Pod 被删除时，PVC 可以保留，并且在需要时可以重新绑定到新的 Pod 上；同时，PV 的存在也使得存储资源可以被多个 Pod 复用，提高了存储资源的利用率。

21. Kubernetes 中的监控和日志如何结合使用？

Kubernetes 的监控和日志结合使用能够帮助开发和运维人员更全面、深入地掌握集群状态，并且在出现故障时能够快速进行排查：

• 监控：通常使用 Prometheus 来收集集群和应用的各类指标，如 CPU 使用率、内存占用情况、网络流量等。Prometheus 具有强大的指标收集和存储能力，能够实时获取系统的运行状态数据。通过 Grafana 可以将这些收集到的指标进行可视化展示，以直观的图表和报表形式呈现给用户，方便用户快速了解系统的性能状况。例如，通过 Grafana 展示的 CPU 使用率图表，运维人员可以清晰地看到不同时间段内各个节点或 Pod 的 CPU 负载情况，及时发现性能瓶颈。
• 日志管理：使用 ELK Stack（Elasticsearch、Logstash、Kibana） 来集中管理和查询 Kubernetes 的日志。Elasticsearch 作为分布式搜索和分析引擎，能够高效地存储和检索大量的日志数据；Logstash 负责收集、过滤和转换日志信息，将其发送到 Elasticsearch 中；Kibana 则提供了一个可视化的界面，方便用户对日志进行查询、分析和可视化展示。例如，当应用出现异常时，运维人员可以通过 Kibana 快速定位到相关的错误日志，分析问题的根源。
• 集成：将 Prometheus 和 Grafana 与日志管理工具（如 Fluentd 或 Filebeat）集成，通过统一的面板和报警系统，可以提高监控和日志的响应效率。Fluentd 或 Filebeat 可以将日志数据发送到 Prometheus 或其他监控系统中，实现日志和指标的关联分析。同时，当监控指标或日志信息触发预设的报警规则时，系统可以及时发出警报，通知相关人员进行处理。例如，当某个 Pod 的 CPU 使用率超过阈值且同时出现特定的错误日志时，系统可以立即发出警报，提醒运维人员进行深入排查。

22. Kubernetes 中如何处理存储资源的动态供给？

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

• 使用 StorageClass 时，可以详细定义不同存储类型的参数，如存储的性能、容量、访问模式等。然后在 PVC 中指定该 StorageClass，Kubernetes 会根据这些配置自动创建和绑定 PV。例如，对于一些对读写性能要求较高的应用，可以创建一个基于 SSD 存储的 StorageClass，设置其读写速度、IOPS 等参数。当应用创建 PVC 并指定该 StorageClass 时，Kubernetes 会自动在后端存储系统中创建一个符合要求的 PV 并与 PVC 绑定，为应用提供所需的存储资源。这种动态供给的方式大大简化了存储资源的管理过程，提高了资源分配的效率和灵活性，使得用户可以根据应用的实际需求快速获取合适的存储资源。

23. Kubernetes 中的 Affinity 和 Anti - Affinity 是如何工作的？

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

• Affinity：允许用户指定 Pod 在相同节点上调度，或者在特定条件下与其他 Pod 调度在一起。例如，可以使用 nodeAffinity 让 Pod 只调度到具有特定标签的节点上。假设某个节点被标记为 “gpu=true”，表示该节点配备了 GPU 资源，那么对于一些需要使用 GPU 进行计算的 Pod，可以通过设置 nodeAffinity，使其只能被调度到这些带有 “gpu=true” 标签的节点上，从而充分利用节点的特殊资源。此外，还可以使用 podAffinity 让 Pod 与其他具有特定标签的 Pod 调度到同一节点或同一区域，以实现资源共享或减少网络延迟。
• Anti - Affinity：用于确保 Pod 不与其他指定的 Pod 调度在同一节点或同一可用区。这在避免单点故障方面非常重要。例如，对于一个分布式应用，为了防止因某个节点故障导致整个应用不可用，可以设置 Anti - Affinity，让该应用的不同 Pod 分布在不同的节点上。这样，即使某个节点出现故障，其他节点上的 Pod 仍然可以正常运行，保障了应用的高可用性。

24. Kubernetes 中如何处理 Pod 的优先级和抢占？

Kubernetes 支持通过 PodPriority 和 PriorityClass 来灵活设置 Pod 的优先级，以确保在资源有限的情况下，关键服务能够优先运行：

• PriorityClass：通过为 Pod 设置不同的优先级，能够控制 Pod 在资源争夺时的调度顺序。集群管理员可以预先定义多个 PriorityClass，每个 PriorityClass 对应一个不同的优先级数值。例如，定义一个 “high - priority” 的 PriorityClass，其优先级数值较高；再定义一个 “low - priority” 的 PriorityClass，其优先级数值较低。在创建 Pod 时，可以为其指定相应的 PriorityClass，从而确定该 Pod 的优先级。
• Pod 抢占：当集群资源紧张时，Kubernetes 会自动终止优先级较低的 Pod，以便为高优先级的 Pod 提供所需的资源。例如，在一个集群中，突然有一个高优先级的 Pod 需要启动，但此时集群资源不足，Kubernetes 会根据 Pod 的优先级，选择终止一些低优先级的 Pod，释放出资源供高优先级 Pod 使用。这种机制保证了关键业务的 Pod 能够在资源紧张的情况下也能顺利运行，提高了集群资源的使用效率和系统的稳定性。

25. Kubernetes 中的 Ingress 和 Egress 是如何控制流量的？

Kubernetes 提供了 Ingress 和 Egress 两种机制来有效控制流量进出集群：

• Ingress：它是一种 API 资源，允许外部流量通过 HTTP/HTTPS 协议访问 Kubernetes 内部的服务。Ingress 通常由 Ingress Controller 来实现，常见的如 Nginx Ingress Controller。Ingress Controller 会监听集群中的 Ingress 资源，根据配置的规则将外部请求转发到相应的后端服务。例如，通过配置 Ingress 规则，可以将访问 “example.com” 的请求转发到集群内的 “my - app” 服务，实现了外部用户对内部服务的访问。
• Egress：主要是指集群内的 Pod 发起的流量访问外部网络的情况。可以通过配置 NetworkPolicy 来精确控制 Pod 的出站流量，限制哪些 Pod 可以访问外部服务。例如，对于一些安全性要求较高的应用，可以设置 NetworkPolicy，只允许特定标签的 Pod 访问指定的外部 IP 地址或域名，防止内部 Pod 随意访问外部网络，提高了集群的安全性。

26. Kubernetes 中的 RBAC（Role - Based Access Control）如何控制权限？

RBAC 是 Kubernetes 中用于管理用户或服务账户操作权限的重要系统，它通过定义 Role 和 RoleBinding 来精确授予权限：

• Role：用于定义在某个命名空间内的权限。可以规定用户或服务账户对特定资源（如 Pods、Services 等）的访问权限，如创建、读取、更新和删除等操作。例如，在一个开发命名空间中，可以定义一个 “developer - role”，该角色只具有对 Pod 进行查看和日志查看的权限，限制了开发人员对资源的操作范围。
• ClusterRole：与 Role 类似，但它定义的是集群范围内的权限。适用于需要对整个集群资源进行操作的场景，如管理节点、配置存储等。例如，一个 “cluster - admin - role” 可以拥有对集群内所有资源的完全控制权。
• RoleBinding 和 ClusterRoleBinding：它们的作用是将 Role 或 ClusterRole 绑定到特定的用户或服务账户。通过这种绑定关系，用户或服务账户就获得了相应的权限。例如，将 “developer - role” 绑定到某个开发人员的账户上，该开发人员在对应的命名空间内就只能执行 “developer - role” 所定义的操作。

27. Kubernetes 中如何处理事件日志？

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

• Kubernetes 中的事件是由 Kubelet、Controller Manager 等组件生成的。Kubelet 负责监控节点上的 Pod 和容器状态，当发生 Pod 创建、容器崩溃等事件时，会生成相应的事件记录；Controller Manager 则在管理集群资源、执行调度策略等过程中产生事件。例如，当 Deployment 控制器进行 Pod 滚动更新时，会记录相关的事件信息，方便用户了解更新过程的状态。
• 集成日志管理：为了更高效地管理和分析这些事件日志，可以使用 Fluentd、Elasticsearch 和 Kibana（ELK Stack） 等工具进行集中处理。Fluentd 可以收集和转发事件日志，将其发送到 Elasticsearch 进行存储和索引；Kibana 则提供了一个可视化的界面，让用户可以通过搜索、过滤等方式快速查找和分析事件日志。例如，当出现 Pod 频繁重启的问题时，运维人员可以通过 Kibana 查看相关的事件日志，分析可能的原因，如资源不足、容器镜像问题等。

28. 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

在上述配置中，minAvailable: 2 表示在任何时候，带有 app: myapp 标签的 Pod 至少要有 2 个处于可用状态。这样，在进行维护操作时，即使有部分 Pod 被中断，也能保证有足够数量的 Pod 继续提供服务，从而保障了应用的稳定性和可用性。通过合理设置 PDB，可以在不影响业务正常运行的前提下，安全地进行集群的升级和维护工作。

29. Kubernetes 中的资源管理器（Resource Manager）如何确保集群资源的公平分配？

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

• 资源请求和限制：在每个 Pod 进行调度时，Kubernetes 会依据其设置的资源请求和限制来选择最合适的节点。资源请求表示 Pod 启动和运行所需的最低资源量，限制则规定了 Pod 可以使用的最大资源量。调度器会检查节点的可用资源，只有当节点的可用资源满足 Pod 的请求时，才会将 Pod 调度到该节点上。例如，一个 Pod 请求 2 个 CPU 核心和 4GB 内存，调度器会寻找有足够可用 CPU 和内存的节点进行调度，避免资源不足导致 Pod 运行异常。
• QoS 策略：通过 QoS 类别（Guaranteed、Burstable、BestEffort）来管理 Pod 的优先级和资源分配。Guaranteed 类别的 Pod 具有最高的资源保障，其 CPU 和内存的 requests 和 limits 相等，系统会严格保证其资源分配；Burstable 类别的 Pod 允许在一定范围内突发使用资源，适用于大多数应用；BestEffort 类别的 Pod 没有设置资源请求和限制，在资源紧张时会优先被终止。调度器会根据 Pod 的 QoS 类别，合理分配资源，确保高优先级的 Pod 能够获得足够的资源，同时也能充分利用剩余资源为低优先级的 Pod 服务。
• 调度策略：如资源亲和性、节点亲和性等策略，帮助在资源有限的情况下，做出最合适的资源调度决策。资源亲和性可以让 Pod 优先调度到具有特定资源的节点上，例如将需要 GPU 计算的 Pod 调度到配备 GPU 的节点；节点亲和性则可以根据节点的标签等属性，将 Pod 调度到特定的节点集合中。通过这些策略，调度器可以更好地平衡节点间的资源负载，提高集群资源的整体利用率，实现资源的公平分配。

结语

以上就是本次分享的全部内容，希望能在一定程度上加深你对 K8s 的理解。Kubernetes 作为一个强大且复杂的容器编排系统，还有许多知识等待我们去探索和学习。建议你持续深入学习，不断积累实践经验，以便更好地应对实际工作中的各种挑战。