Kubernetes核心原理(一)之API Server

原文链接

 1. API Server简介 k8s API Server提供了k8s各类资源对象(pod,RC,Service等)的增删改查及watch等HTTP Rest接口,是整个系统的数据总线和数据中心。

本文CSDN博客地址:http://blog.csdn.net/huwh_/article/details/75675706


1. API Server简介

k8s API Server提供了k8s各类资源对象(pod,RC,Service等)的增删改查及watch等HTTP Rest接口,是整个系统的数据总线和数据中心。

kubernetes API Server的功能:

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

kube-apiserver工作原理图


2. 如何访问kubernetes API

k8s通过kube-apiserver这个进程提供服务,该进程运行在单个k8s-master节点上。默认有两个端口。

2.1. 本地端口

  1. 该端口用于接收HTTP请求;
  2. 该端口默认值为8080,可以通过API Server的启动参数“--insecure-port”的值来修改默认值;
  3. 默认的IP地址为“localhost”,可以通过启动参数“--insecure-bind-address”的值来修改该IP地址;
  4. 非认证或授权的HTTP请求通过该端口访问API Server。

2.2. 安全端口

  1. 该端口默认值为6443,可通过启动参数“--secure-port”的值来修改默认值;
  2. 默认IP地址为非本地(Non-Localhost)网络端口,通过启动参数“--bind-address”设置该值;
  3. 该端口用于接收HTTPS请求;
  4. 用于基于Tocken文件或客户端证书及HTTP Base的认证;
  5. 用于基于策略的授权;
  6. 默认不启动HTTPS安全访问控制。

2.3. 访问方式

Kubernetes REST API可参考https://kubernetes.io/docs/api-reference/v1.6/

2.3.1. curl

curl localhost: 8080 /api
curl localhost: 8080 /api/v1/pods
curl localhost: 8080 /api/v1/services
curl localhost: 8080 /api/v1/replicationcontrollers

2.3.2. Kubectl Proxy

Kubectl Proxy代理程序既能作为API Server的反向代理,也能作为普通客户端访问API Server的代理。通过master节点的8080端口来启动该代理程序。

kubectl proxy --port=8080 &

具体见kubectl proxy --help

2.3.3. kubectl客户端

命令行工具kubectl客户端,通过命令行参数转换为对API Server的REST API调用,并将调用结果输出。

命令格式:kubectl [command] [options]

具体可参考Kubernetes常用命令

2.3.4. 编程方式调用

使用场景:

1、运行在Pod里的用户进程调用kubernetes API,通常用来实现分布式集群搭建的目标。

2、开发基于kubernetes的管理平台,比如调用kubernetes API来完成Pod、Service、RC等资源对象的图形化创建和管理界面。可以使用kubernetes提供的Client Library。

具体可参考https://github.com/kubernetes/client-go

3. 通过API Server访问Node、Pod和Service

k8s API Server最主要的REST接口是资源对象的增删改查,另外还有一类特殊的REST接口—k8s Proxy API接口,这类接口的作用是代理REST请求,即kubernetes API Server把收到的REST请求转发到某个Node上的kubelet守护进程的REST端口上,由该kubelet进程负责响应。

3.1. Node相关接口

关于Node相关的接口的REST路径为:/api/v1/proxy/nodes/{name},其中{name}为节点的名称或IP地址。

/api/v1/proxy/nodes/ {name} /pods/     #列出指定节点内所有Pod的信息
/api/v1/proxy/nodes/ {name} /stats/    #列出指定节点内物理资源的统计信息
/api/v1/prxoy/nodes/ {name} /spec/     #列出指定节点的概要信息

这里获取的Pod信息来自Node而非etcd数据库,两者时间点可能存在偏差。如果在kubelet进程启动时加--enable-debugging-handles=true参数,那么kubernetes Proxy API还会增加以下接口:

/api/v1/proxy/nodes/ {name} /run       #在节点上运行某个容器
/api/v1/proxy/nodes/ {name} /exec      #在节点上的某个容器中运行某条命令
/api/v1/proxy/nodes/ {name} /attach    #在节点上attach某个容器
/api/v1/proxy/nodes/ {name} /portForward    #实现节点上的Pod端口转发
/api/v1/proxy/nodes/ {name} /logs      #列出节点的各类日志信息
/api/v1/proxy/nodes/ {name} /metrics   #列出和该节点相关的Metrics信息
/api/v1/proxy/nodes/ {name} /runningpods   #列出节点内运行中的Pod信息
/api/v1/proxy/nodes/ {name} /debug/pprof   #列出节点内当前web服务的状态,包括CPU和内存的使用情况

3.2. Pod相关接口

/api/v1/proxy/namespaces/ {namespace} /pods/ {name}/{path:*}       #访问pod的某个服务接口
/api/v1/proxy/namespaces/ {namespace} /pods/ {name}                #访问Pod
#以下写法不同,功能一样
/api/v1/namespaces/ {namespace} /pods/ {name} /proxy/ {path:*}       #访问pod的某个服务接口
/api/v1/namespaces/ {namespace} /pods/ {name} /proxy                #访问Pod

3.3. Service相关接口

/api/v1/proxy/namespaces/ {namespace} /services/ {name}

Pod的proxy接口的作用:在kubernetes集群之外访问某个pod容器的服务(HTTP服务),可以用Proxy API实现,这种场景多用于管理目的,比如逐一排查Service的Pod副本,检查哪些Pod的服务存在异常问题。

4. 集群功能模块之间的通信

kubernetes API Server作为集群的核心,负责集群各功能模块之间的通信,集群内各个功能模块通过API Server将信息存入etcd,当需要获取和操作这些数据时,通过API Server提供的REST接口(GET\LIST\WATCH方法)来实现,从而实现各模块之间的信息交互。

4.1. kubelet与API Server交互

每个Node节点上的kubelet定期就会调用API Server的REST接口报告自身状态,API Server接收这些信息后,将节点状态信息更新到etcd中。kubelet也通过API Server的Watch接口监听Pod信息,从而对Node机器上的POD进行管理。

监听信息
kubelet动作
备注
新的POD副本被调度绑定到本节点 执行POD对应的容器的创建和启动逻辑  
POD对象被删除 删除本节点上相应的POD容器  
修改POD信息 修改本节点的POD容器  

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

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

4.3. kube-scheduler与API Server交互

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

4.4. 特别说明

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

 

参考《kubernetes权威指南》


版权声明:本文内容由互联网用户自发贡献,本社区不拥有所有权,也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至: yqgroup@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。



  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kubernetes(简称K8s)是一个开源的容器编排和管理工具,用于自动化部署、扩展和操作容器化应用程序。K8s的架构原理可以通过以下几个核心组件来详解。 1. Master节点:Master节点是K8s集群的控制中心,负责管理和控制整个集群的运行。其中包括以下几个组件: - API Server:作为控制和管理的入口,接收和处理用户和其他组件的请求。 - Scheduler:负责调度任务到合适的Node节点上运行。 - Controller Manager:监控集群状态,根据需求对集群进行自动化的维护和管理。 - etcd:分布式键值存储系统,用于保存集群中的元数据信息。 2. Node节点:Node节点是集群中的工作节点,负责运行应用程序容器。每个Node节点上包含以下几个组件: - Docker或其他容器运行时:用于管理和运行容器。 - Kubelet:与Master节点通信,接收和执行Master节点下发的指令,管理容器的生命周期。 - Kube-proxy:负责实现集群中的网络代理和负载均衡。 3. Pod:Pod是K8s的最小调度和部署单元,包含一个或多个紧密相关的容器。Pod中的容器共享同一个网络命名空间和存储卷,可以通过本地的localhost互相通信。 4. Service:Service是一种抽象,定义了一组Pod的访问规则。通过Service,可以提供稳定的访问入口,使得集群内的其他组件不需要关心具体的Pod的位置和IP地址。 除了这些核心组件,K8s还有其他一些重要的特性和功能,如命名空间、标签、配置管理、水平扩展、滚动更新等,这些功能进一步增强了K8s的弹性、可靠性和可管理性。 总结起来,K8s的架构原理可以归纳为Master-Node架构,通过Master节点对整个集群进行控制和管理,Node节点负责运行容器化应用程序,Pod作为最小的调度和部署单元,Service提供访问入口。这种设计使得K8s具备自动化、弹性、可伸缩和可靠的特点,广泛应用于云原生应用的部署和管理。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值