K8s 问题

k8s 架构图及交互流程

k8s 主要有 Master 节点和工作节点组成。主节点主要对集群做出全局决策(比如调度)，以及检测和响应集群事件(例如资源不足，自动扩缩容)；从节点负责维护运行的 Pod 并进行通信的网络代理。

Mater 节点主要有以下组件：

• kube-apiserver：负责对外暴露 Kubernetes API。
• etcd：作为保存 Kubernetes 所有集群数据的后台数据库。
• kube-scheduler：在适当的时候进行调度决策，让 Pod 在合适的节点上创建运行。
• kube-controller-manager：负责监控调整调整集群的状态，比如故障检测、自动扩展、滚动更新等

Node 节点有以下组件：

• kubelet：主要负责执行、监控由调度器分配的 Pod，相当于是 Master 在每个 Node 节点上的代理。保证 Pod 的运行状态与目标状态一致。
• kube-proxy：k8s 在每个节点上的网络代理，负责为 Service 提供集群内部的服务发现和负载均衡。

k8s 的健康检查机制是什么？

k8s 主要通过提供下面两种探针(probe)来进行 Pod 的健康检测：

• livenessProbe(存活探针)：用来确定什么时候要重启容器，例如通过一个 HTTP GET 请求来判断容器是否健康存活。
• readinessProbe(就绪探针)：有时候，应用程序会暂时性的不能提供通信服务。（例如启动加载大文件）。在这种情况下，既不想杀死应用程序，也不想给它发送请求。Kubernetes 提供了就绪探测器来发现并缓解这些情况，设置后，流量将不会打到 Service 上。

Pod 的状态有哪些？

Pending：pod 正在等待 kube-scheduler 选择合适的节点创建。 Running：pod 已正常创建，并且至少有一个容器正在运行。 Succeeded：所有容器已成功启动运行。 Failed：pod 的容器非正常退出。 Unknown：无法获取 pod 状态，可能节点间通信出现问题。

k8s 创建一个 pod 流程

1） 客户端提交 Pod 的配置信息（可以是 yaml 文件定义好的信息）到 kube-apiserver； 2） Apiserver 收到指令后，通知给 controller-manager 创建一个资源对象； 3） Controller-manager 通过 api-server 将 pod 的配置信息存储到 ETCD 数据中心中； 4） Kube-scheduler 检测到 pod 信息会开始调度预选，会先过滤掉不符合 Pod 资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运行 pod 的节点，然后将 pod 的资源配置单发送到 node 节点上的 kubelet 组件上。 5） Kubelet 根据 scheduler 发来的资源配置单运行 pod，运行成功后，将 pod 的运行信息返回给 scheduler，scheduler 将返回的 pod 运行状况的信息存储到 etcd 数据中心。