kubernetes组件

kubernetes的主要组件

master组件

master组件是集群的控制平台(control plane):

1.master组件负责集群中的全局决策(例如,调度)

2.master组件探测并响应集群事件(例如,当Deployment的实际Pod副本数未达到replicas字段的规定时,启动一个新的Pod)

master组件可以运行于集群中的任何机器上。但是,为了简洁性,通常在同一台机器上运行所有的master组件,且不在此机器上运行用户的容器。

kube-apiserver

此master组件提供kubernetes API。这是kubernetes控制平台的前端(front-end),可以水平扩展(通过部署更多的实例以达到性能要求)。kubectl/kubernetes dashboard/kuboard等kubernetes管理工具就是通过kubernetes API实现对kubernetes集群的管理。

etcd

支持一致性和高可用的名值对存储组件,kubernetes集群的所有配置信息都存储在etcd中。请确保你备份了etcd的数据。

kube-scheduler

此master组件监控所有新创建尚未分配到节点上的Pod,并且自动选择为Pod选择为Pod选择一个合适的节点去运行。

影响调度的因素有:

1.单个或多个Pod的资源需求

2.硬件、软件、策略的限制

3.亲和与反亲和(affinity and anti-affinity)的约定

4.数据本地化要求

5.工作负载间的相互作用

kube-controller-manager

此master组件运行了所有的控制器

逻辑上来说,每一个控制器是一个独立的进程,但是为了降低复杂度,这些控制器都被合并运行在一个进程里。

kube-controller-manager中包含的控制器有:

1.节点控制器:负责监听节点停机的事件并作出对应响应

2.副本控制器:负责为集群中每一个副本控制器对象(Replication Controller Object)维护期望的Pod副本数

3.端点(Endpoints)控制器:负责为端点对象(Endpoints Object,连接Service和Pod)赋值

4.Service Account & Token控制器:负责为新的名称空间创建 default Service Account以及API Access Token

cloud-controller-manager

cloud-controller-manager中运行了与具体云基础设施供应商互动的控制器。这是kubernetes 1.6版本中引入的特性,尚处在alpha阶段。

cloud-controller-manager只运行特定于云基础设施供应商的控制器。如果您参考www.kuboard.cn上提供的文档安装Kubernetes集群,默认不安装cloud-controller-manager。

cloud-controller-manager使得云供应商的代码和kubernetes的代码可以各自独立的演化。在此之前的版本中,kubernetes的核心代码是依赖于云供应商的代码的。在后续版本中,特定于云供应商的代码将有云供应商自行维护,并在运行kubernetes时链接到cloud-controller-manager。

以下控制器中包含与云供应商相关的依赖:

1.节点控制器:当某一个节点停止响应时,调用云供应商的接口,以检查该节点的虚拟机是否已经被云供应商删除

私有化部署kubernetes时,我们不知道节点的操作系统是否删除,所以在移除节点后,要自行通过kubectl delete node将节点对象从kubernetes中删除

2.路由控制器:在云供应商的基础设施中设定网络路由

私有化部署kubernetes时,需要自行规划kubernetes的拓扑结构,并做好路由配置,,例如离线安装高可用的kubernetes集群中所作的并

3.服务(Service)控制器:创建、更新、删除云供应商提供的负载均衡器

私有化部署kubernetes时,不支持LoadBalancer类型的service,如需要此特性,需要创建NodePort类型的Service,并自行配置负载均衡器

4.数据卷(Volume)控制器:创建绑定、挂载数据卷,并协调云供应商编排数据卷

私有化部署kubernetes时,不支持LoadBalancer类型的service,如需要此特性,需要创建NodePort类型

的Service,并自行配置负载均衡器

5.数据卷(Volume)控制器:创建挂载数据卷协调云供应商编排数据卷

私有化部署kubenetes时,需要自行创建和管理存储资源,并通过kubernetes的存储类、存储卷、数据卷等与之关联

通过cloud-controller-manager,kubernetes可以更好地与云供应商结合,例如,在阿里云的kubernetes服务里,您可以在云控制台界面上轻松点击鼠标,即可完成kubernetes集群的创建和管理。在私有化部署环境时,您必须自行处理更多的内容。幸运的是,通过合适的教程指引,这些任务的达成并不困难。

Node组件

Node组件运行在每一个节点上(包括master节点和worker节点),负责维护运行中的Pod并提供kubernetes·运行时环境

kubelet

此组件是运行在每一个集群节点上的代理程序。它确保Pod中的容器处于运行状态。kubelet通过多种途径获得podspec定义,并确保podspec定义中所描述的容器处于运行和健康的状态。kubelet不管理不是通过kubernetes创建的容器。

kube-proxy

kube-proxy是一个网络代理程序,运行在集群中的每一个节点上,是实现kubernetes service概念的重要部分。

kube-proxy在节点上维护网络规则。这些网络规则使得您可以在集群内、集群外正确地与pod进行网络通行。如果操作系统中存在packet filtering layer,kube-proxy将使用这一特性(iptables代理模式),否则,kube-proxy将自行转发网络请求(User space代理模式)

容器引擎负责运行容器。kubernetes支持多种容器引擎:docker、containerd、cri-o、rktlet以及任何实现了kubernetes容器引擎接口的容器引擎

addons

addons使用kubernetes资源(DaemonSet、Deployment等)实现集群的功能特性。由于他们提供集群级别的功能特性,addons使用到的Kubernetes资源都放置在kube-system名称空间下。

DNS

除了DNS Addon以外,其他的addon都不是必须的,所有kubernetes集群都应该有Cluster DNS

Cluster DNS是一个DNS服务器,是对您已有环境中其他DNS服务器的一个补充,存放了kubernetes Service的DNS记录。

kubernetes启动容器时,自动将该DNS服务器加入到容器的DNS搜索列表中。

kubernetes,默认已经安装了Core DNS

Wed UI(Dashboard)

Dashboard是一个kubernetes集群的wed管理界面。用户可以通过该界面管理集群。

kuboard

kuboard是一款基于kubernetes的微服务管理界面,相较于Dahboard,kuboard强调:

1.无需手工编写YAML文件

2.微服务参考架构

3.上下文相关的监控

4.场景化的设计

(1)导出配置

(2)导入配置

ContainerResource Monitoring

ContainerResource Monitoring将容器的度量指标(metrics)记录在时间序列数据库中,并提供了UI界面查看这些数据

Cluster-level Logging

Cluster-level Logging机制负责将容器的日志存储到一个统一存储中,并提供搜索浏览的界面。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

404警告、

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值