k8s 各个组件介绍

k8s 组件介绍

kube-apiserver运行在mater节点上

https://k8smeetup.github.io/docs/admin/kube-apiserver/

Kubernetes API server 为 api 对象验证并配置数据(验证账号吗密码对不对),包括 pods、services、 replicationcontrollers 和其它 api 对象,API Server 提供 REST 操作和到集群共享状态的前端,所有其他组件通过它进行交互。

 

kube-scheduler调度、运行在master节点上 

https://k8smeetup.github.io/docs/admin/kube-scheduler/

是一个拥有丰富策略:

容器创建的时候会基于后面node节点的资源利用率,挑选出来资源比较空闲的node节点,在这个资源比较空闲的node节点上将容器启动

能够感知拓扑变化:

假如之前有3个node节点,如果这时候由于业务增加需要再加一个node节点,这个时候kube-scheduler就能够自动发现这个新增的节点,当后期再创建pod的时候,由于新增node节点上的pod数量比较少,这时候kube-scheduler就会将新建的pod节点分配到该node节点上。

如果这时候有一个node节点宕机了,kube-scheduler就会停止向这个宕机的node宿主机分配pod,并且将宕机的这个node节点上的全部pod转移到其他node宿主机中。

支持特定负载的功能组件,它对集群的可用性、性能表现以及容量都影响巨大。scheduler 需要考虑独立的和集体的资源需求、服务质量需求、硬件/软件/策略限制、亲和与反亲和规范、数据位置、内部负载接口由service来实现、截止时间等等。如有必要,特定的负载需求可以通过API 暴露出来。

亲和性解释:

所谓亲和性就是给主机打标签,这里我们给他们打的是magedu的标签,并且再这两个node主机上都加了,让我们再创建pod的时候kube-scheduler调度器只会选择将业务创建在只有project=magedu的node节点上,我们将这种称为亲和性。在公司中使用较多的就是亲和性

kube-controller-manager(运行在master节点上

https://k8smeetup.github.io/docs/admin/kube-controller-manager/

Controller Manager 作为集群内部的管理控制中心,负责集群内的 Node、Pod副本(pod数量,它的数量是由我们在创建的时候yaml文件中来定义)、服务端点指的是service后面会挂后端的服务器(Endpoint)、命名空间(Namespace、        服务账号(ServiceAccount)、资源定额(ResourceQuota)的管理,当某个 Node意外宕机时,Controller Manager 会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态。这个功能是kube-controller-manager最重要的功能之一,所谓的修复流程:当node节点宕机了上面跑的pod也挂了,所以它需要将这些pod进行修复,修复的话无非就是在找一个相对空闲的的node节点把我们这些不能访问的pod移动到该node节点上,但是这个node节点上必须得有一样得镜像。不然服务修复不了,所以它必须在harbor里面将之前挂了的pod镜像拉取下来重新创建为一个相同得容器。一旦创建出来之后,service会自动发现并且将他加入到pod里面。这个功能特别重要

Service是一个逻辑上存在的虚拟网络,这个网络是不能被外部直接访问的,但是service上面还有地址这里是10.30.0.1,并且pod的ip地址不能够和service的ip地址一样、pod的ip地址为10.10.0.1。但是我们的node宿主机又是一个网段为172.18.1.1、然后我们会给这个service在node宿主机上开一个端口,将这个service的网络暴露出去,将这个service的ip地址暴露到宿主机的30888端口上,这个时候我们就可以访问宿主机的30888端口,这个30888会通过iptables规则转发到这个service网络上,这个时候用户的请求会先访问node节点的172.18.1.1这个ip然后再通过iptables规则将这个请求转发至30888端口,30888端口将用户请求丢给了service,然后再由server将这个请求丢给后端的各个pod。这个中间宿主机是通过iptables规则来调用给service的。而service又是通过LVS来反向代理后端的pod

LVS的性能大大高于iptables。

kube-proxy需要自己手动安装、并且运行在node节点上 

https://k8smeetup.github.io/docs/admin/kube-proxy/

Kubernetes 网络代理运行在 node 上得一个组件,它反映了 node 上Kubernetes API 中定义的服务,并可以通过一组后端进行简单的 TCP、UDP 流转发或循环模式(round robin))的 TCP、UDP 转发,用户必须使用 apiserver API 创建一个服务来配置代理,其实就是 kube-proxy 通过在主机上维护网络规则并执行连接转发来实现Kubernetes 服务访问。创建规则实现对外网的访问,运行在node节点上得一个组件

 

kubelet运行在node节点上

https://k8smeetup.github.io/docs/admin/kubelet/

运行在node节点上得一个组件是主要的节点代理,它会监视已分配给节点的 pod,具体功能如下(监控运行在node节点上得pod是否正常,如果运行不正常就将结果返回给master上,然后再由master进行修复):

  • 向master 汇报node 节点的状态信息:资源利用率汇报主要用于给kube-scheduler在进行新得pod创建时候做筛选的、如果这个node节点上得资源利用率很高,就不会往这个node节点上分配pod了而是分配到那些相对空闲得node节点上去
  • 接受指令并在Pod 中创建 docker 容器:他会在本地拉起一个pod然后在里面创建正真的容器
  • 准备Pod 所需的数据卷:在创建容器的时候需要创建很多数据目录,这些数据目录也是由kubelet来做的。
  • 返回pod 的运行状态:如果这个pod是异常的话他会给他master进行返回
  • 在node节点执行容器健康检查:观察pod是否在运行状态,如果不是运行状态的话master就会报错是由kubelet进行监控并返回的

 

etcd(运行在单个主机):

https://github.com/etcd-io/etcd

etcd 是CoreOS 公司开发、并且是由go语言写的目前是Kubernetes 默认使用的key-value格式得数据存储系统,用于保存所有集群数据,支持分布式集群功能,生产环境使用时需要为 etcd 数据提供定期备份机制,避免etcd服务器挂了之后导致数据丢失。用于存放数据,并且保存在磁盘上,可以是单机的可以是集群的

总结

在K8s中master用于管理各个node节点的,进行调度、容器的创建、容器的删除,等等操作,但是这个master是由我们运维来访问的。

部署规划图:

Master:

一个master上要装一个kube-controller-manager、kube-scheduler、kube-apiserver。

etcd(这个etcd数据库可以是单机的也可以是集群的、一般工作中都是集群的)

 

Node:

 

每一个node节点要装一个kubelet、kuber-proxy、docker。

 

最后有一个镜像仓库,负载镜像的统一发放。各个node节点到这个仓库上来拉取镜像。