深度解析 | K8S API Server之入门须知
我们首先将对Kubernetes API Server进行概括性的介绍,然后对一些术语进行介绍,最后对API请求流程进行解释。后续会有新的文章对API Server的存储和扩展点等主题进行介绍。本篇是Kubernetes API Server系列第一篇。
API Server简介
在概念层面上,Kubernetes由一系列不同角色的节点组成。Mater节点上的控制平面由API Server,Controller Manager和Scheduler组成。API Server是中心管理实体,是与分布式存储组件(etcd)进行直接通信的唯一组件。API Server提供以下核心功能:
-
服务于被集群内部工作节点和外部kubectl使用的Kubernetes API
-
为集群组件提供代理,如Kubernetes UI
-
允许对对象(例如pod和service等)的状态进行操作
-
保持分布式存储(etcd)中对象的状态
Kubernetes API是HTTP API,以JSON作为主要的结构化数据的序列化格式,但同时它也支持Google的Protocol Buffers格式进行描述(主要用于集群内部通信)。
考虑到可扩展性原因,Kubernetes支持多个API版本,分别处于不同的API路径上,例如/api/v1或/apis/extensions/v1beta1。不同的API版本意味着不同等级的稳定性和支持度:
-
Alpha级别,例如v1alpha1,默认情况下被禁用,对此功能的支持可能随时会被舍弃,而且不会进行通知,因此只能在短期测试的集群中使用。
-
Beta级别,例如v2beta3,默认情况下启用,意味着代码已经经过良好的测试,但对象的语义可能会在后续beta版或stable版中以不兼容的方式进行更改。
-
Stable级别,例如v1,将出现在多个后续版本的released软件中。
现在来看看HTTP API空间是如何组成的。在顶层,按照以下几个组进行区分:核心组(均位于/api/v1路径下,由于历史原因位于此路径,而不在/apis/core/v1路径下),命名组(位于/apis/$NAME/$VERSION路径下),以及系统范围实体(如/metrics)。
接下来我们将聚焦一个具体的例子:批处理(batch)操作。在Kubernetes 1.5中,存在两个版本的批处理操作:/apis/batch/v1和/apis/batch/v2alpha1,分别暴露不同的可以进行查询和操作的实体集。
下面我们展示一个与API进行交互的示范性例子(使用Minishift工具和代理命令行oc proxy –port=8080,以直接对API进行访问):
$ curl http://127.0.0.1:8080/apis/batch/v1
{
“kind”: “APIResourceList”,
“apiVersion”: “v1”,
“groupVersion”: “batch/v1”,
“resources”: [
{
“name”: “jobs”,
“namespaced”: true,
“kind”: “Job”
},
{
“name”: “jobs/status”,
“namespaced”: true,
“kind”: “Job”
}
]
}
接下来,使用新的Alpha版本:
$ curl http://127.0.0.1:8080/apis/batch/v2alpha1
{
“kind”: “APIResourceList”,
“apiVersion”: “v1”,
“groupVersion”: “batch/v2alpha1”,
“resources”: [
{
“name”: “cronjobs”,
“namespaced”: true,
“kind”: “CronJob”
},
{
“name”: “cronjobs/status”,
“namespaced”: true,
“kind”: “CronJob”
},
{
“name”: “jobs”,
“namespaced”: true,
“kind”: “Job”
},
{
“name”: “jobs/status”,
“namespaced”: true,
“kind”: “Job”
},
{
“name”: “scheduledjobs”,
“namespaced”: true,
“kind”: “ScheduledJob”
},
{
“name”: “scheduledjobs/status”,
“namespaced”: true,
“kind”: “ScheduledJob”
}
]
}
通常情况下,通过标准HTTP的POST、PUT、DELETE和GET动作,以JSON作为默认有效载荷,Kubernetes API支持在给定路径上进行创建(create)、更新(update)、删除(delete)、检索(retrieve)操作。
大多数API对象会区分对象的期望状态规格(specification)和对象的当前状态。对象规格(specification)是对期望状态的完整描述,并保存在持久化存储中。
本文转移K8S技术社区-深度解析 | K8S API Server之入门须知
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
深度解析 | K8S API Server之专业术语
对Kubernetes API Server的相关术语进行介绍,后续会有新的文章对API请求流程、APIServer的存储和扩展点等主题进行介绍。本篇是KubernetesAPI Server系列第二篇。 术语解释 在简要概述了API Server和HTTP API空间及其属性之后,我们现在对文中使用的术语进行更正式的定义。像pod,service、endpoints、deployment等基元组成了Kubernetes类型的对象。我们使用以下术语: Kind代表一个实体的类型。每个对象都有一个Kind字段,它告诉一个客户端(如kubectl或者oc)它具体代表的实体,如pod: apiVersion: v1 kind: Pod metadata: name: webserver spec: containers: – name: nginx image: nginx:1.9 ports: – containerPort: 80 有三种类型的Kind: 对象(Objects)表示系统中的一个持久实体。对象可能具有多个资源,客户端可以使用它们来执行特定的操作。例如:Pod和Name...
- 下一篇
教程 | Kubernetes的边缘节点配置
为了配置kubernetes中的traefik ingress的高可用,对于kubernetes集群以外只暴露一个访问入口,需要使用keepalived排除单点问题。 本文参考了kube-keepalived-vip,但并没有使用容器方式安装,而是直接在node节点上安装。 定义 首先解释下什么叫边缘节点(Edge Node),所谓的边缘节点即集群内部用来向集群外暴露服务能力的节点,集群外部的服务通过该节点来调用集群内部的服务,边缘节点是集群内外交流的一个Endpoint。 边缘节点要考虑两个问题 边缘节点的高可用,不能有单点故障,否则整个kubernetes集群将不可用 对外的一致暴露端口,即只能有一个外网访问IP和端口 架构 为了满足边缘节点的以上需求,我们使用keepalived来实现。 在Kubernetes集群外部配置nginx来访问边缘节点的VIP。 选择Kubernetes的三个node作为边缘节点,并安装keepalived。 安装 使用keepalived管理VIP,VIP是使用IPVS创建的,IPVS已经成为linux内核的模块,不需要安装。 LVS的工作原理请参...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8安装Docker,最新的服务器搭配容器使用
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7安装Docker,走上虚拟化容器引擎之路