k8s知识点

master: kube-apiserver、kube-controller-manager、kube-scheduler
node : kubelet、proxy

kube-apiserver

提供HTTP Rest接口的关键服务进程，是集群中所有资源增删改操作的唯一入口，也是集群唯一入口，负责提供restful api访问接口，并且将数据持久化到etcd server 中。
在Kubernetes系统中，大多数情况下，API定义和实现都符合标准的HTTP REST格式， 比如通过标准的HTTP动词（POST、PUT、GET、DELETE）来完成对相关资源对象的查询、创建、修改、删除等操作。但同时Kubernetes 也为某些非标准的REST行为实现了附加的API接口，例如Watch某个资源的变化、进入容器执行某个操作等。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1klLzoTd-1599817509249)(evernotecid://6952E92B-1291-4C44-A738-B6E6F5D2D06D/appyinxiangcom/25565608/ENResource/p11)]

1、基础知识

1. api version

• aplha

• 包含alpha名称的版本（例如v1alpha1）。

• 该软件可能包含错误。启用一个功能可能会导致bug。默认情况下，功能可能会被禁用。

• 随时可能会丢弃对该功能的支持，恕不另行通知。

• API可能在以后的软件版本中以不兼容的方式更改，恕不另行通知。

• 该软件建议仅在短期测试集群中使用，因为错误的风险增加和缺乏长期支持。

• beta

• 包含beta名称的版本（例如v2beta3）。

• 该软件经过很好的测试。启用功能被认为是安全的。默认情况下功能是开启的。

• 细节可能会改变，但功能在后续版本不会被删除

• 对象的模式或语义在随后的beta版本或Stable版本中可能以不兼容的方式发生变化。如果这种情况发生时，官方会提供迁移操作指南。这可能需要删除、编辑和重新创建API对象。

• 该版本在后续可能会更改一些不兼容地方，所以建议用于非关键业务，如果你有多个可以独立升级的集群，你也可以放宽此限制。

• stable

• 该版本名称命名方式：vX这里X是一个整数。

• Stable版本的功能特性，将出现在后续发布的软件版本中

2. api groups

目前，有几个API groups在使用:

• Core Groups（核心组），作为k8s最核心的API。其特点是没有“组”的概念，例如"v1"，在资源对象的定义中表示为"apiVersion:v1"。
  例：http://localhost:8080/api/v1/namespaces/default/pods/test-pod

包括：Pod、ReplicationController、EndPoints、Service、ConfigfMap、Secret、PersistentVolumeClaim、Volume、Event、LimitRange、
PodTemplate、Binding、ComponentStatus、Namespace、Node、PersistentVolume、ResourceQuota、ServiceAccount

• Named Groups具有分组信息的API，REST路径被指定在 /apis/$GROUP_NAME/$VERSION 中，并使用apiVersion: $GROUP_NAME/$VERSION（例如apiVersion: batch/v1）。在Kubernetes API参考引用中可以看到API Groups的完整列表。
  例：http://localhost:8080/apis/rbac.authorization.k8s.io/v1/clusterroles/test-clusterrole

group 包括 batch、apps、extensions、storage.k8s.io、apiextensions.k8s.io、autoscaling、admissionregistration.k8s.io、policy、scheduling.k8s.io、settings.k8s.io、apiregistration.k8s.io、authorization.k8s.io、networking.k8s.io

可以看出, 该restful api的组织形式是:

api	api版本	namespace	所属namespace	资源种类	锁清秋资源名称
api	v1	namespace	default	pods	test-pod

api	group	version	namespace	所属namespace	资源种类	锁清秋资源名称
apis	apps	v1	namespace	default	pods	test-pod

2、核心流程

主要有以下三类通信交互的场景：

1. kubelet与API Server交互

每个Node节点上的kubelet定期就会调用API Server的REST接口报告自身状态，API Server接收这些信息后，将节点状态信息更新到etcd中。kubelet也通过API Server的Watch接口监听Pod信息，如果监听到新的Pod副本被调度绑定到本节点，则执行Pod对应的容器的创建和启动逻辑；如果监听到Pod对象被删除，则删除本节点上的相应的Pod容器；如果监听到修改Pod信息，则kubelet监听到变化后，会相应的修改本节点的Pod容器。

2. kube-controller-manager与API Server交互

kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口，实时监控Node的信息，并做相应处理。

3. kube-scheduler与API Server交互

Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后，它会检索所有符合该Pod要求的Node列表，开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上。

为了缓解各模块对API Server的访问压力，各功能模块都采用缓存机制来缓存数据，各功能模块定时从API Server获取指定的资源对象信息（LIST/WATCH方法），然后将信息保存到本地缓存，功能模块在某些情况下不直接访问API Server，而是通过访问缓存数据来间接访问API Server。

kubectl apply xxx.yaml 流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UpSv8PQR-1599817509251)(evernotecid://6952E92B-1291-4C44-A738-B6E6F5D2D06D/appyinxiangcom/25565608/ENResource/p10)]

1. kubectl提交创建pod命令,api响应命令,通过一系列认证授权,把pod数据存储到etcd,创建deployment资源并初始化.

2. controller通过list-watch机制,监测发现新的deployment,将该资源加入到内部工作队列,发现该资源没有关联的pod和replicaset,启用deployment controller创建replicaset资源,再启用replicaset controller创建pod.

3. 所有controller正常后.将deployment,replicaset,pod资源更新存储到etcd.

4. scheduler通过list-watch机制,监测发现新的pod,经过主机过滤主机打分规则,将pod绑定(binding)到合适的主机.

5. 将绑定结果存储到etcd.

6. kubelet每隔 20s(可以自定义)向kube-apiserver通过NodeName 获取自身Node上所要运行的pod清单.通过与自己的内部缓存进行比较,新增加pod.

7. 启动pod启动容器.

8. 把本节点的容器信息pod信息同步到etcd.