Kubernetes 面试散记
Kubernetes Cluster Architecture
设计还是符合直觉的
- 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 的详细流程
- 客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML。
- api-server 处理用户请求，将 pod 信息存储至 etcd 中。
- kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出。
- 选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中。
- 随后目标节点的 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 所在主机通信失败。