Kubernete 面试题整理

发布于 2023-12-12  551 次阅读

1、POD 的创建流程

  • kubectl 发起创建 Pod 请求：

    • 用户通过 kubectl create 命令（或其他等效方式）向 Kubernetes API Server 发起一个创建 Pod 的请求。这个请求包含了 Pod 的定义，通常是一个 YAML 或 JSON 格式的文件。

  • API Server 接收请求并处理：

    • Kubernetes API Server 接收到创建 Pod 的请求后，会对请求进行验证和授权检查。
    • API Server 不会直接创建 Pod，而是将这个请求转化为一个内部表示（如一个含有 Pod 创建信息的 YAML 格式的对象）。

  • 写入 Etcd 数据库：

    • API Server 将这个 Pod 对象的信息写入到 Etcd 数据库。Etcd 作为 Kubernetes 的数据存储，保存了集群的状态和配置。

  • Scheduler 进行调度：

    • Kubernetes Scheduler 持续监视 API Server，检查新的或未被调度的 Pod。
    • 当 Scheduler 发现一个新的 Pod（pod.spec.Node == null 表示这个 Pod 还没有被调度到任何节点），它将根据资源需求、亲和性规则、污点和容忍度等因素选择一个合适的节点。
    • 一旦选择了节点，Scheduler 将更新该 Pod 的信息，指定其运行在选择的节点上，并将这个更新写回到 Etcd。

  • Kubelet 监听并创建 Pod：

    • 每个节点上的 Kubelet 进程持续监视 Etcd，查找分配给自己节点的新任务。
    • 当 Kubelet 发现有新的 Pod 分配到它所在的节点，它会根据 Pod 定义开始创建和启动 Pod 中的容器。
    • Kubelet 调用容器运行时（如 Docker）来实际启动容器，并设置必要的网络和存储配置。

  • Pod 状态更新和汇报：

    • 在 Pod 创建过程中，Kubelet 将 Pod 的状态更新回 API Server。这些状态信息包括 Pod 是否成功启动，运行中的容器等。
    • API Server 更新 Etcd 中的状态信息，确保集群状态的一致性。

2、POD 的状态

1. Pending

  • Pod 已被 Kubernetes 系统接受，但有一个或多个容器镜像尚未创建。
  • Pod 等待被调度到一个节点上。
  • 网络配置等前期准备工作正在进行中。

2. Running

  • Pod 已经被调度到一个节点上，并且所有的容器都已创建。
  • 至少有一个容器正在运行，或者正在启动或重启。

3. Succeeded

  • Pod 中的所有容器都正常运行完毕，并已经退出。
  • 这通常适用于一次性或批处理作业。

4. Failed

  • Pod 中至少有一个容器以非零状态退出。
  • 表明容器启动失败或运行中出现错误。

5. Unknown

  • 由于某种原因，Pod 的状态无法确定。
  • 通常是与 Pod 通信出现问题，如节点故障。

6. CrashLoopBackOff

  • 表明 Pod 中的一个或多个容器尝试启动后失败，正在尝试重启。
  • 这可能是由于应用程序错误、配置问题等引起的。

7. ImagePullBackOff

  • Pod 无法拉取一个或多个容器镜像。
  • 可能是因为镜像不存在，或者与容器注册中心的认证问题。

8. Terminating

  • 当 Pod 被标记为删除并开始终止过程时，会进入此状态。
  • 这个状态意味着 Kubernetes 正在停止 Pod 中的所有容器。

9. Evicted

  • 当节点上的资源（如内存或磁盘空间）不足时，Pod 可能会被驱逐。
  • 驱逐行为是 Kubernetes 为了保护节点稳定性而自动执行的操作。

10. OOMKilled

  • 如果 Pod 中的容器使用超出其分配的内存限制，它可能会被系统的 Out-Of-Memory (OOM) killer 终止。
  • 这通常表明容器配置的内存限制过低或应用程序内存泄露。

11. ContainerCreating

  • 当 Kubernetes 正在创建 Pod 中的容器时，Pod 会处于此状态。
  • 这可能涉及到拉取容器镜像、创建容器等操作。

12. Completed

  • 这是一个非常用状态，表明 Pod 中的所有容器都已成功完成其任务并且正常退出。
  • 这通常用于有限期或批处理任务。

3、Kubernetes 架构中一般有几个主节点，为什么

  • 单个主节点:

    • 对于小型或开发环境，通常只有一个主节点。
    • 这简化了配置，但缺点是没有高可用性。如果主节点出现故障，整个集群可能会受到影响。

  • 多个主节点 (高可用性配置):

    • 在生产环境中，为了实现高可用性（HA），通常会有多个主节点。
    • 常见配置是三个主节点，这样即使一个节点失败，集群的控制平面仍然可以继续运行。
    • 使用三个或更多节点可以防止“脑裂”（split-brain）情况，这是当网络分区发生时，避免出现多个主节点同时认为自己是活动的情况。

  • 为什么选择三个节点:

    • 在分布式系统中，使用奇数个节点可以更好地处理脑裂和投票决策。当存在偶数个节点时，可能会出现投票平局的情况，从而使集群难以决定哪个版本的数据是最新的。
    • 三个节点是高可用性配置的最小数量，提供了故障转移能力，同时在资源和管理复杂性方面保持平衡。

  • 更多节点:

    • 对于大型或特别关键的环境，可能会有超过三个主节点。
    • 随着节点数量的增加，管理复杂性和资源需求也会增加，因此需要权衡成本和可用性的需求。