TODO

调度器的职责就是通过监听API Server来启动新的工作任务
Endpoints
kubectl

k8s的整体认识

节点>Pod>容器>进程

一个k8s集群有若干个节点（node），节点又分为控制平面节点和工作节点。每个节点会运行若干个Pod（Pod是k8s的最小调度单元），每个Pod会部署若干个容器（但一般来说一个Pod只部署一个容器，多容器Pod只适用于需要共享资源紧密协作的场景）。每个容器通常运行一个独立应用进程。

请求是怎么被处理的

客户端请求通过网关（集群外的边界设施），然后进入k8s的Ingress Controller，Ingress将请求路由到相应的Service资源，然后Service通过label标签筛选到对应的Pod，将请求转发到相应的Pod上。在Pod的容器中，请求被分发到该端口监听的进程进行处理。

扩展：Ingress将请求路由到相应的Service资源？

实际上是kube-proxy守护进程会持续监听API Service上Service和Endpoint的变化，配置 iptables 或 IPVS 规则。所有发往Service虚拟IP（clusterIp）的请求会被自动拦截、负载均衡转发到后端Pod上。总之，Service只是抽象概念，kube-proxy才是实际推手。

区分资源和组件

K8S有很多资源和组件的概念，这两者有什么区别呢？

资源是我们定义的期望状态，是声明式对象。通常用YAML或JSON文件（或kubectl）提交给k8s API去声明的。存在于etcd数据库中。一般在声明文件的kind字段存在，如Deployment, Service, Pod, Ingress, ConfigMap, Secret, PersistentVolumeClaim, Namespace, DaemonSet, StatefulSet
组件是k8s实际作用的后台逻辑程序或进程，负责监听资源，致力于实现期望的状态。我们一般不实际操作组件，而是通过定义资源来间接使用到它们。如kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager, kubelet, kube-proxy

控制平面（Control Plane）

是k8s的大脑，负责管理集群的所有决策和全局状态。控制平面是一个逻辑概念，由一系列组件共同实现，而这些组件实际承载的节点一般称为Master节点（也称Control Plane Node）（但并非绝对，有时候也会将组件部署在非Master节点）。

核心组件：

kube-apiserver ：所有集群管理通信的唯一入口，暴露了 Kubernetes API。所有对集群的操作，都必须通过 HTTP REST API 调用的形式与 kube-apiserver 交互。
etcd ：集群的核心数据库，键值形式存储所有配置数据、状态、元数据。是k8s唯一有状态的控制平面组件。
kube-scheduler ：用于调度。根据一系列调度策略为Pod选择最合适的Node。只做决策，不负责执行。
kube-controller-manager ：运行控制器（controller）的守护进程，控制器确保集群当前状态趋于期望状态。
cloud-controller-manager ：可选，在云平台运行k8s才需要，与底层云提供商交互的控制器

工作节点（Work Node）

工作节点是相较于Master节点的概念。核心职责是运行和管理容器。用户部署的应用是以容器形式运行在工作节点上。

核心组件：

kubelet ：节点代理，是与控制平面（尤其是kube apiserver）沟通的桥梁。负责接收和汇报本节点指令和状态。
容器运行时（Container Runtime）：真正负责容器运行的软件。k8s通过 CRI（Container Runtime Interface） 与之交互。
kube-proxy : 节点上的网络代理，负责维护节点上的网络规则，实现Service的概念。

Ingress

不同于kube-apiserver组件是“管理通道”，Ingress则是“数据通道”。它是业务的统一流量入口。将外部流量路由到集群内部相应的Service。

K8S命令

帮助：kubectl help ，如果想要获取某个配置的具体信息（如yaml配置中某个字段下面可以有哪些字段，字段格式是什么）：kubectl explain xxx