kubernetes 核心组件之 APIServer
Posted 看，未来
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了kubernetes 核心组件之 APIServer相关的知识，希望对你有一定的参考价值。
文章目录
APIServer 简介
APIServer 的重要性不言而喻。
kube-apiserver作为整个Kubernetes集群操作etcd的唯一入口，负责Kubernetes各资源的认证&鉴权，校验以及CRUD等操作，提供RESTful APIs，供其它组件调用：
kubernetes API Server的功能
-
提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
-
提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
-
提供准入控制的功能；
-
拥有完备的集群安全机制.
结构分析
- Resetful 对外提供http(https)的接口，用来对外提供与集群统一的交互手段。
- Cacher 针对查询到的数据的缓存中心。
- Watcher 模块负责从Etcd获取数据，其中可注册多个Watcher，即关注多个不同的数据。
- Translate 模块负责将从Etcd获取到的数据转化为本地统一数据的接口,当Watcher获取到数据后就将其发送给Translate模块，Translate根据数据类型使用注册的对应的翻译接口进行翻译。
流程分析
如图所示，Apiserver可以左右两部分，左半部分是Apiserver使用观察者模式获取更新需要的数据，右半部分则是Apiserver接受外部调用并注册观察者Watcher,并从Watcher中最终获取到需要的数据。
组件构成
kube-apiserver包含三种APIServer：
- aggregatorServer：负责处理 apiregistration.k8s.io 组下的APIService资源请求，同时将来自用户的请求拦截转发给aggregated server(AA)
- kubeAPIServer：负责对请求的一些通用处理，包括：认证、鉴权以及各个内建资源(pod, deployment，service and etc)的REST服务等
- apiExtensionsServer：负责CustomResourceDefinition（CRD）apiResources以及apiVersions的注册，同时处理CRD以及相应CustomResource（CR）的REST请求(如果对应CR不能被处理的话则会返回404)，也是apiserver Delegation的最后一环
另外还包括bootstrap-controller，主要负责Kubernetes default apiserver service的创建以及管理。
集群功能模块之间的通信
kubernetes API Server作为集群的核心，负责集群各功能模块之间的通信，集群内各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，通过API Server提供的REST接口（GET\\LIST\\WATCH方法）来实现，从而实现各模块之间的信息交互。
kube-apiserver进程运行在单个k8s-master节点上，默认有两个端口。
本地端口：
- 该端口用于接收HTTP请求；
- 该端口默认值为8080，可以通过API Server的启动参数“–insecure-port”的值来修改默认值；
- 默认的IP地址为“localhost”，可以通过启动参数“–insecure-bind-address”的值来修改该IP地址；
- 非认证或授权的HTTP请求通过该端口访问API Server。
安全端口：
- 该端口默认值为6443，可通过启动参数“–secure-port”的值来修改默认值；
- 默认IP地址为非本地（Non-Localhost）网络端口，通过启动参数“–bind-address”设置该值；
- 该端口用于接收HTTPS请求；
- 用于基于Tocken文件或客户端证书及HTTP Base的认证；
- 用于基于策略的授权；
- 默认不启动HTTPS安全访问控制。
kubelet与API Server交互
每个Node节点上的kubelet定期就会调用API Server的REST接口报告自身状态，API Server接收这些信息后，将节点状态信息更新到etcd中。kubelet也通过API Server的Watch接口监听Pod信息，从而对Node机器上的POD进行管理。
kube-controller-manager与API Server交互
kube-controller-manager中的Node Controller模块通过API Server提供的Watch接口，实时监控Node的信息，并做相应处理。他们通过API Server提供的接口实时监控整个集群里的每一个资源对象的当前状态，当发生各种故障导致系统状态发生变化，这些controller会尝试将系统从“现有装态”修正到“期望状态”。
kube-scheduler与API Server交互
Scheduler通过API Server的Watch接口监听到新建Pod副本的信息后，它会检索所有符合该Pod要求的Node列表，开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上。
API版本
为了消除字段或重组资源表示形式，Kubernetes 支持多个 API 版本，每个版本在不同的 API 路径下。例如：/api/v1或者/apis/extensions/v1beta1。
API级别
Alpha：
版本名称包含alpha（例如，v1alpha1）。
该软件可能包含错误。启用功能可能会暴露错误。默认情况下，功能可能被禁用。
对功能的支持随时可能被删除，但不另行通知。
在以后的软件版本中，API 可能会以不兼容的方式更改，亦不另行通知。
由于存在更高的错误风险和缺乏长期支持，建议仅在短期测试集群中使用该软件。
Beta:
版本名称包含beta（例如，v2beta3）。
该软件已经过充分测试。启用功能被认为是安全的。默认情况下启用功能。
尽管细节可能会发生变更，对应功能不会被废弃。
在随后的 Beta 或稳定版本中，对象的模式和/或语义可能会以不兼容的方式更改。发生这种情况时，将提供迁移说明。迁移时可能需要删除、编辑和重新创建 API 对象。编辑过程可能需要一些思考。对于依赖该功能的应用程序，可能需要停机。
该软件仅建议用于非关键业务用途，因为在后续版本中可能会发生不兼容的更改。如果您有多个可以独立升级的群集，则可以放宽此限制。
稳定版：
版本名称为vX，其中X为整数。
功能特性的稳定版本会持续出现在许多后续版本的发行软件中。
API访问控制
可以使用kubectl、客户端库方式对REST API的访问，Kubernetes的普通账户和Service帐户都可以实现授权访问API。API的请求会经过多个阶段的访问控制才会被接受处理，其中包含认证、授权以及准入控制（Admission Control）等。如下图所示：
需要注意：认证授权过程只存在HTTPS形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiserver，是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用HTTP，集群外部就使用HTTPS，这样既增加了安全性，也不至于太复杂。
认证、授权、准入控制
由于篇幅过长，我做了个解耦操作：
kubernetes API 访问控制之：认证
以上是关于kubernetes 核心组件之 APIServer的主要内容，如果未能解决你的问题，请参考以下文章