kubernetes 核心组件之 APIServer

Posted 看,未来

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了kubernetes 核心组件之 APIServer相关的知识,希望对你有一定的参考价值。


文章目录


APIServer 简介

kubernetes

APIServer 的重要性不言而喻。

kube-apiserver作为整个Kubernetes集群操作etcd的唯一入口,负责Kubernetes各资源的认证&鉴权,校验以及CRUD等操作,提供RESTful APIs,供其它组件调用:
kubernetes


kubernetes API Server的功能

  1. 提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更);
  2. 提供其他模块之间的数据交互和通信的枢纽(其他模块通过API Server查询或修改数据,只有API Server才直接操作etcd);
  3. 提供准入控制的功能;
  4. 拥有完备的集群安全机制.

结构分析

  • Resetful 对外提供http(https)的接口,用来对外提供与集群统一的交互手段。
  • Cacher 针对查询到的数据的缓存中心。
  • Watcher 模块负责从Etcd获取数据,其中可注册多个Watcher,即关注多个不同的数据。
  • Translate 模块负责将从Etcd获取到的数据转化为本地统一数据的接口,当Watcher获取到数据后就将其发送给Translate模块,Translate根据数据类型使用注册的对应的翻译接口进行翻译。

kubernetes


流程分析

如图所示,Apiserver可以左右两部分,左半部分是Apiserver使用观察者模式获取更新需要的数据,右半部分则是Apiserver接受外部调用并注册观察者Watcher,并从Watcher中最终获取到需要的数据。

kubernetes


组件构成

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)等。如下图所示:
kubernetes

需要注意:认证授权过程只存在HTTPS形式的API中。也就是说,如果客户端使用HTTP连接到kube-apiserver,是不会进行认证授权的。所以说,可以这么设置,在集群内部组件间通信使用HTTP,集群外部就使用HTTPS,这样既增加了安全性,也不至于太复杂。


以上是关于kubernetes 核心组件之 APIServer的主要内容,如果未能解决你的问题,请参考以下文章

kubernetes 核心组件之 APIServer

kubernetes 核心组件之 Controller Manager

kubernetes 核心组件之 APIServer

kubernetes 核心组件之 Schedule

kubernetes 核心组件之 etcd

ansible部署kbuernetes