0%

Kubernetes 面试散记

bty5E.png

Kubernetes Cluster Architecture

bNpM2.png

设计还是符合直觉的

  • ETCD 作为核心的存储,将所有的状态都置于其中
  • API-Server 提供 HTTP API 给其他服务
  • Kube-Scheduler 负责调度POD
  • Kube-Controller:维护资源状态,和ETCD中的描述的状态进行对比
  • Kubelet: 作为每一个Node上的管理者,其他组件对其下发指令
  • KubeProxy:将复杂的网络功能单独提出来的管理组件

Kubernetes的Pause容器有什么用

Pause 作为一个 POD 其他 Continar 的父亲存在,1. 是pod里其他容器共享Linux namespace的基础, 2. 扮演PID 1的角色,负责处理僵尸进程

镜像分层的技术

  • AUFS/Overlay/Devicemapper

k8s 创建一个 pod 的详细流程

  1. 客户端提交创建请求,可以通过 api-server 提供的 restful 接口,或者是通过 kubectl 命令行工具,支持的数据类型包括 JSON 和 YAML。
  2. api-server 处理用户请求,将 pod 信息存储至 etcd 中。
  3. kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod,尝试为 pod 分配 node 节点,主要分为两个阶段,预选阶段和优选阶段,其中预选阶段是遍历所有的 node 节点,根据策略筛选出候选节点,而优选阶段是在第一步的基础上,为每一个候选节点进行打分,分数最高者胜出。
  4. 选择分数最高的节点,进行 pod binding 操作,并将结果存储至 etcd 中。
  5. 随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件,然后从 etcd 获取 pod 清单,下载镜像并启动容器。

kubelet 监控 Node 节点资源使用是通过什么组件来实现的?

cAdvisor

k8s 中服务级别,怎样设置服务的级别才是最高的

  • BestEffort
    什么都不设置(CPU or Memory),佛系申请资源。
  • Burstable
    Pod 中的容器至少一个设置了CPU 或者 Memory 的请求
  • Guaranteed
    Pod 中的所有容器必须设置 CPU 和 Memory,并且 request 和 limit 值相等。

Pod 的生命周期

挂起(Pending):Pod 已被 Kubernetes 系统接受,但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间,这可能需要花点时间。
运行中(Running):该 Pod 已经绑定到了一个节点上,Pod 中所有的容器都已被创建。至少有一个容器正在运行,或者正处于启动或重启状态。
成功(Succeeded):Pod 中的所有容器都被成功终止,并且不会再重启。
失败(Failed):Pod 中的所有容器都已终止了,并且至少有一个容器是因为失败终止。也就是说,容器以非0状态退出或者被系统终止。
未知(Unknown):因为某些原因无法取得 Pod 的状态,通常是因为与 Pod 所在主机通信失败。

来杯奶茶, 嗝~~~