目录
一、相关组件
1.1 控制面板组件(master)
1.1.1 kube-apiserver
1.1.2 kube-controller-manager
1.1.3 cloud-controller-manager
1.1.4 kube-schedule
1.1.5 etcd
1.2 节点组件
1.2.1 kubelet
1.2.2 kube-proxy
1.2.3 container runtime
1.3 附加组件
1.3.1 kube-dns
1.3.2 ingress Controller
1.3.3 Prometheus
1.3.4 Dashboard
1.3.5 Fedderation
1.3.6 Fluentd-elasticsearch
二、分层架构
2.1 生态系统
2.2 接口层
2.3 管理层
2.4 应用层
2.5 核心层
一、相关组件
1.1 控制面板组件(master)
1.1.1 kube-apiserver
API 服务器是 Kubernetes 控制平面的组件, 该组件负责公开了 Kubernetes API,负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩,也就是说,它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例,并在这些实例之间平衡流量。
Kubernetes中的kube-apiserver是整个Kubernetes控制平面中最重要的组件之一。kube-apiserver是一个RESTful API服务器,它充当了整个Kubernetes系统的前端和入口,负责接收来自Kubernetes客户端的请求,以及将这些请求转换为Kubernetes内部操作。
kube-apiserver是一个高度可扩展的组件,可以水平扩展,从而实现高可用性和负载均衡。Kubernetes中所有的操作都是通过kube-apiserver完成的,因此kube-apiserver的性能和可靠性对于整个Kubernetes集群运行的稳定性和性能至关重要。
kube-apiserver的主要职责包括:
-
提供RESTful API接口,接收来自Kubernetes客户端的请求,并将其转换为Kubernetes操作。
-
鉴权和认证,确保请求方是经过验证的合法用户,并且具有执行该请求所需的权限。
-
服务发现,根据请求的资源类型和名称,找到该资源所在的节点,进而将请求转发给该节点进行处理。
-
数据管理,维护存储Kubernetes中所有对象的数据,如Pod、Service、Deployment等。
-
事件记录,记录Kubernetes集群中发生的各种事件,包括容器状态变更、资源使用情况等。
kube-apiserver是整个Kubernetes集群中最重要的控制平面组件之一,它提供了Kubernetes集群操作的入口和核心API,保证了整个Kubernetes集群的高可用性、高性能和可靠性。
1.1.2 kube-controller-manager
Kubernetes中的kube-controller-manager是Kubernetes控制平面的重要组件之一,它是一个后台进程,负责监控Kubernetes集群中的各种资源对象,如Pod、Service、ReplicaSet等,确保它们始终处于期望的状态。
kube-controller-manager主要包含以下几个控制器:
-
Replication Controller:监控ReplicationController资源对象的状态,确保启动和管理指定数量的Pod。
-
Node Controller:监控集群中的节点状态,并确保Pod在适当的节点上运行。
-
Service Controller:监控Service资源对象的状态,确保Kubernetes集群内部的服务发现和路由功能正常工作。
-
Endpoint Controller:监控Service和Endpoint资源对象的状态,确保Kubernetes服务的网络连接正确建立和维护。
-
Namespace Controller:监控Namespace资源对象的状态,确保Namespace的状态正确、命名空间间互相隔离。
-
Job Controller:监控Job资源对象的状态,确保Job任务运行状态正确,任务完成后清理相关资源。
kube-controller-manager会周期性地检查Kubernetes集群中各种资源对象的状态,如果发现某个资源对象的状态与预期状态不一致,则会采取相应的措施,使资源对象状态恢复到预期状态。并且,kube-controller-manager也支持自定义控制器,可以根据用户需求编写自定义控制器。
kube-controller-manager是Kubernetes集群中重要的控制平面组件之一,能够有效地管理Kubernetes集群中各种资源对象的状态,确保集群的高可用性和可靠性。
1.1.3 cloud-controller-manager
Kubernetes中的cloud-controller-manager是一个可选组件,它是一个后台进程,用于与云提供商(如AWS、GCP等)交互,管理云资源。cloud-controller-manager与kube-controller-manager类似,它也是Kubernetes控制平面的一个组件,但它专门针对云提供商。
在云环境下,Kubernetes需要与云提供商的API进行交互操作,例如创建和管理云上的虚拟机、负载均衡、存储等资源。这些操作需要特定的云提供商API,并且云提供商的API不同于其他环境,因此需要专门的组件来管理云资源。, 并将与该云平台交互的组件同与你的集群交互的组件分离开来。
cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes,或者在本地计算机中运行学习环境, 所部署的集群不需要有云控制器管理器。
与 kube-controller-manager 类似,cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中, 供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。
cloud-controller-manager中包含多个云控制器,根据云提供商的不同,控制器数量和功能也不同。例如:
-
AWS控制器:用于管理AWS云上的虚拟机、负载均衡、存储、域名解析等资源。
-
GCP控制器:用于管理GCP云上的虚拟机、负载均衡、存储、域名解析等资源。
-
Azure控制器:用于管理Azure云上的虚拟机、负载均衡、存储、域名解析等资源。
cloud-controller-manager的主要作用是:
-
与云提供商API进行交互,管理云资源。
-
优化云资源的使用,例如自动缩放虚拟机、自动创建负载均衡器等。
-
与Kubernetes的其他控制器协同工作,确保Kubernetes集群和云资源之间的相互协作。
cloud-controller-manager是一个重要的组件,它使Kubernetes能够充分利用云提供商的资源,并且能够自动扩展和管理云资源。它可以使Kubernetes更好地适应云环境,提高可用性和可靠性。
1.1.4 kube-schedule
kube-scheduler是Kubernetes控制平面的一个组件,用于将Pod调度到适合其运行的节点上。当一个新的Pod被创建时,kube-scheduler会根据一系列的调度算法,选出一个最优的节点用来运行这个Pod。它可以帮助我们更好地管理集群资源,优化资源使用,提高集群性能和可用性。
kube-scheduler的主要作用是:
-
选择合适的节点:kube-scheduler会根据Pod的资源需求(CPU、内存等)、节点的可用资源、节点的负载情况、Pod的亲缘性等因素,选择一个最优的节点用来运行这个Pod。
-
均衡负载:kube-scheduler会根据节点的负载情况,将Pod均衡地分配到不同的节点上,避免某个节点过载。
-
自动扩缩容:当需要扩展Pod时,kube-scheduler会考虑节点的可用资源状况,自动选择合适的节点来创建新的Pod。当需要缩小Pod时,kube-scheduler会将Pod从一个节点调度到另一个节点上,以释放资源。
-
灵活调度:kube-scheduler提供了各种调度策略(例如亲缘性调度、节点亲和性调度、pod亲和性调度、污点容忍和容忍度选择)来满足不同场景下的需求。
kube-scheduler的工作流程如下:
-
监听Pod的创建事件。
-
对新创建的Pod进行调度,选择一个最优的节点。
-
将选择的节点信息添加到Pod的spec字段。
-
上报调度结果,将调度后的Pod信息发送给kubelet,kubelet根据这些信息创建Pod。
1.1.5 etcd
etcd是一个可靠的分布式键值存储系统,它是Kubernetes的重要组件之一,用于存储集群的配置信息、元数据以及持久化数据等,早期数据存放在内存,现在已经是持久化存储的了。
etcd最初是由CoreOS开发并维护的,现在已经成为了一个独立的开源项目,它是一个轻量级的、高可用的、分布式的键值存储系统,支持数据的持久化和实时修改。etcd使用Raft协议来实现分布式一致性,确保存储数据的高可用性和可靠性。
在Kubernetes中,etcd用于存储Kubernetes集群的所有数据,包括:
-
Kubernetes的配置信息,例如API Server、Controller Manager、Scheduler等组件的配置信息。
-
Kubernetes集群中的各种资源对象,例如Pod、Service、Replication Controller等。
-
Kubernetes的所有状态信息,例如节点的状态、Pod的状态、Service的状态等。
由于etcd是Kubernetes中重要的组件之一,它的高可用和可靠性对于整个集群的稳定运行有着重要的作用。为了保证etcd的高可用性,一般会采用集群模式部署etcd,通过多节点复制来实现数据的备份和容错机制。
1.2 节点组件
1.2.1 kubelet
kubelet是Kubernetes节点上的一个重要组件,主要负责管理和维护节点上容器的生命周期,同时也负责 Volume(CVI)和网络(CNI)的管理。它是Kubernetes的Node Agent,是Kubelet、Container Runtime和容器之间的接口。kubelet负责将容器启动、停止、监控的命令转换成底层的操作,同时还负责拉取并更新容器镜像、启动容器、构建容器网络等任务。
以下是kubelet的主要职责:
-
监控容器。kubelet负责监控容器的运行状况,例如容器是否健康,容器运行状态是否正常等。如发现异常情况,kubelet会通过Kubernetes API上报给Master节点处理。
-
启动和停止容器。kubelet负责启动和停止容器,根据Master的指令,将Pod中定义的容器启动,并在容器状态发生变化时向Master节点报告。
-
容器存储管理。kubelet可以管理容器的存储卷,例如本地存储卷、分布式存储卷等。
-
容器网络。kubelet会为Pod中的每个容器分配IP地址,并配置容器网络,从而与其他容器或主机进行通信。
-
容器资源限制管理。kubelet会根据Pod中定义的资源限制,为容器设置资源限制,并且负责监控容器的资源消耗情况。
总之,kubelet是Kubernetes中非常重要的组件,它负责维护集群中每个节点的状态,并且根据Master节点的指令来启动、停止、管理容器,保证集群中的容器可以正常运行。
1.2.2 kube-proxy
kube-proxy
是一种控制器(Controller),其作用是负责在集群中的所有节点上以透明的方式实现服务发现和负载均衡功能,从而为客户端提供对服务的访问,使得应用程序更加容易部署和扩展。
具体而言,kube-proxy
维护了一个虚拟IP地址和端口的映射表,并通过监听Kubernetes API Server的事件(例如Service对象的创建、更新和删除事件)来更新该表。当客户端发送请求到该虚拟IP地址和端口时,kube-proxy
将根据负载均衡算法将请求转发到相应的后端Pod上。因此,kube-proxy
提供了一种抽象的机制,允许客户端请求一个服务而不需要了解实际的后端Pod地址和端口。
另外,kube-proxy
还支持以下几种负载均衡方式:
- IPVS(IP Virtual Server)模式:基于Linux内核的IPVS实现,支持四层(TCP/UDP)和七层(HTTP/HTTPS)负载均衡。
- IPTABLES模式:基于Linux内核的iptables实现,支持四层(TCP/UDP)负载均衡。
- Userspace模式:用于运行老版本的Kubernetes集群,基于iptables实现,虽然已经不被推荐使用。
1.2.3 container runtime
container runtime
是指负责管理容器生命周期的软件,它执行容器的创建、启动、停止和删除等操作,是Kubernetes实现高效和可靠的容器编排和部署的重要基础,Kubernetes支持多种容器运行时,包括Docker、Containerd、CRI-O、rkt等。
在Kubernetes中,容器运行时负责以下几个方面:
-
容器镜像管理:容器镜像是容器运行时的基础,容器运行时负责管理镜像的存储和获取,以及镜像的拉取、保存、删除等操作。
-
容器创建和销毁:容器运行时负责创建和销毁容器,包括容器的配置、资源限制、网络管理等操作。在Kubernetes中,容器的创建和销毁是通过容器编排系统(如Kubernetes API Server)发送操作指令给容器运行时来完成的。
-
容器状态管理:容器运行时负责监控容器的状态,包括容器运行期间的CPU、内存、网络等资源使用情况,以及容器中应用程序的运行状态和日志等信息。
-
容器网络管理:容器运行时负责为每个容器配置网络,包括给容器分配IP地址、设置端口映射、配置网络策略等操作。
在Kubernetes中使用容器运行时时,需要先将容器镜像上传到容器镜像仓库(如Docker Hub),然后在Kubernetes中定义Pod配置文件,其中包括容器镜像名称、容器资源限制、容器启动命令等信息。然后,Kubernetes将Pod配置发送给容器编排系统(如Kubernetes API Server),由它向Kubernetes节点上的容器运行时发送容器创建指令,从而完成容器的创建和启动。
1.3 附加组件
1.3.1 kube-dns
kube-dns 负责为整个集群提供 DNS 服务
在Kubernetes集群中,kube-dns
是一个核心DNS服务,它负责管理Kubernetes内部所有Pod的DNS解析,使得Kubernetes集群中的各个组件可以互相发现和通信。kube-dns在Kubernetes集群中作为一个Deployment运行,它由三个容器组成:dns-controller、dns-server和sidecar。
其中,dns-controller是kube-dns的核心组件,它通过监听Kubernetes API Server上的Service和Endpoint对象变化来维护DNS记录。当Service和Endpoint发生变化时,dns-controller会自动更新kube-dns的DNS记录。dns-controller支持以下三种类型的DNS记录:
-
Service记录:为每个Kubernetes Service创建一个DNS记录,将Service的Cluster IP地址映射到DNS名称。
-
Pod记录:为每个Kubernetes Pod创建一个DNS记录,将Pod的IP地址映射到DNS名称。Pod记录主要用于支持Kubernetes的headless服务。
-
ExternalName记录:为Kubernetes Service创建一个外部DNS记录,将Service的DNS名称映射到外部DNS名称。ExternalName记录主要用于将Kubernetes Service映射到外部服务。
dns-server是kube-dns的DNS服务器组件,它通过监听UDP端口53来接收DNS请求,然后根据DNS记录提供DNS解析服务。
sidecar是kube-dns的一个辅助容器,它通过监听TCP端口10053来提供DNS服务的多种API接口,包括DNS-over-HTTPS、DNS-over-TLS和gRPC等。
在Kubernetes集群中使用kube-dns时,每个Pod都会自动配置DNS解析规则,可以使用Pod的名称作为DNS名称来访问其他Pod和Service。例如,如果有一个Pod名称为“my-nginx”,它可以使用“my-nginx.default.svc.cluster.local”来访问同一命名空间中的其他Service和Pod。如果需要访问其他命名空间中的Service和Pod,则需要使用FQDN(Fully Qualified Domain Name)格式,例如“my-service.my-namespace.svc.cluster.local”。
1.3.2 ingress Controller
Ingress Controller是Kubernetes中的一个重要组件,它允许Kubernetes集群外部的客户端访问集群内部的Service,它可以将外部流量路由到Kubernetes集群内部的Service,提供了Kubernetes集群的入口和负载均衡功能,大大提高了Kubernetes集群的可用性和易用性。Ingress Controller通过在Kubernetes集群中创建Ingress对象来实现这一功能。Ingress对象是一个Kubernetes资源对象,它定义了将外部流量路由到Kubernetes集群内部的Service的规则。
Ingress Controller和Ingress对象之间的关系类似于Service和Endpoint对象之间的关系。Ingress Controller负责监听Kubernetes API Server上的Ingress对象变化,然后根据Ingress对象中定义的规则将流量路由到相应的Service。Ingress Controller中常用的实现方式包括Nginx Ingress Controller、HAProxy Ingress Controller和Traefik Ingress Controller等。
在使用Ingress Controller时,需要先创建Ingress资源对象,然后通过Ingress Controller将外部流量路由到相应的Service。例如,可以通过如下的Ingress资源对象将流量路由到Kubernetes集群中的my-service服务:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: my-domain.com
http:
paths:
- path: /my-service
pathType: Prefix
backend:
service:
name: my-service
port:
name: http
上述Ingress对象将指定一个名为my-service的Service,并将所有/my-service路径的请求路由到该Service。如果外部客户端访问my-domain.com/my-service,Ingress Controller将会自动将请求转发到my-service服务的Cluster IP地址上。
1.3.3 Prometheus
Kubernetes中的Prometheus被广泛使用作为集群监控和告警系统,可以帮助开发和运维人员实时监控Kubernetes集群的性能和状态,快速诊断和解决问题。Kubernetes中的Prometheus可以通过下面几个组件来实现:
-
Prometheus Operator:它是一个Kubernetes原生的运营商,它可以帮助您安装,配置和管理Prometheus,并且可以自动发现监控目标。
-
Kubernetes API服务器:这是一个API服务器,Prometheus Operator使用它来托管其自定义资源和控制器。
-
Kubernetes Service发现:Prometheus Operator使用Kubernetes Service来发现服务的端点。
-
Prometheus自身:Prometheus本身是一个开源的监控系统,它可以轻松地与Kubernetes集成。Prometheus通过HTTP/HTTPS获取指标数据,并存储数据到本地存储或外部存储中。
在Kubernetes中,Prometheus的主要作用是监控Kubernetes集群的性能和状态。Prometheus可以监控各种Kubernetes资源,例如Pod、Service、DaemonSet、StatefulSet、Deployment、Job等,并且可以监控集群的CPU、内存、网络等指标。Prometheus还可以通过PromQL查询语言和Kubernetes API来查询指标数据,并提供基于指标数据的告警和警报功能,以进行故障排查和问题解决。
1.3.4 Dashboard
Kubernetes Dashboard是Kubernetes项目官方提供的一个可视化的Web界面,用于管理和监控Kubernetes集群。它可以帮助用户快速了解集群中运行的应用程序、Pod、Service等资源的状态和指标,并通过它们的日志和事件来诊断故障和问题。以下是Kubernetes Dashboard的一些特性:
-
集成所有Kubernetes资源:Dashboard可以集成所有Kubernetes资源,包括Pod、ReplicaSet、Deployment、Service、ConfigMap、PersistentVolume等。
-
统一的视图:Dashboard提供了一个统一的视图,将集群中所有的资源和对象统一管理。
-
容器日志和运行状态的查看:Dashboard可以查看容器的日志和运行状态,可用于诊断故障和问题。
-
可扩展性:Dashboard可以扩展到支持自定义的Kubernetes资源类型和操作。
-
安全性:Dashboard提供了安全的身份验证和授权机制,可管理和监控Kubernetes集群中的资源和操作。
-
易用性:Dashboard具有用户友好的界面,使得管理员和开发人员可以轻松地使用它来管理和监控Kubernetes集群。
Kubernetes Dashboard的安装非常简单,可以通过Kubectl命令在Kubernetes集群中安装。使用Dashboard,管理员和开发人员可以轻松地管理和监控Kubernetes集群中的资源和应用程序,从而加快开发和部署的速度,提高系统的可靠性和可维护性。
1.3.5 Fedderation
Kubernetes Federation是Kubernetes项目提供的一种解决方案,用于跨多个Kubernetes集群管理应用程序、服务和资源。它是一种管理多个Kubernetes集群的工具,可以将多个Kubernetes集群组成一个大型的分布式系统。
Kubernetes Federation可以通过控制面和数据面两个部分来实现。控制面用于管理多个Kubernetes控制平面,数据面用于管理多个Kubernetes节点。以下是Kubernetes Federation的一些特性:
-
集中式管理:Kubernetes Federation可以集中式地管理多个Kubernetes集群,包括部署、配置、监控、扩展、升级等操作。
-
自动化操作:Kubernetes Federation提供了自动化的操作,可以自动地将应用程序和服务部署到多个Kubernetes集群中,并将它们集成到一个单一的应用程序环境中。
-
灵活性:Kubernetes Federation提供了灵活的配置选项,可以根据不同的应用程序和服务需求,进行不同的配置和管理。
-
多云支持:Kubernetes Federation可以支持多种云环境,包括公共云、私有云和混合云等。
-
安全性:Kubernetes Federation提供了安全的身份验证和授权机制,以保护管理和监控多个Kubernetes集群的安全性。
-
可扩展性:Kubernetes Federation提供了可扩展的架构,可以扩展到支持更多的Kubernetes集群和资源类型。
Kubernetes Federation可以帮助企业管理多个Kubernetes集群,加快应用程序和服务的部署、升级和扩展速度,提高系统的可靠性和可维护性。
1.3.6 Fluentd-elasticsearch
Fluentd-elasticsearch是一个用于Kubernetes的日志收集和分析工具。它由两个组件组成,一个是Fluentd,用于收集、传输和处理Kubernetes集群中的日志数据,另一个是Elasticsearch,用于存储和索引日志数据,并提供丰富的分析和查询功能。
Fluentd是一款轻量级的日志收集工具,可以从多个数据源中收集数据,并将其传输到多个目标存储器中,如Elasticsearch、Hadoop、Amazon S3和MongoDB等。在Kubernetes中,Fluentd可以通过Kubernetes的DaemonSet部署在每个节点上,从Docker容器和Kubernetes的API Server中收集日志数据,并将其发送到Elasticsearch。
Elasticsearch是一款分布式的开源搜索和分析引擎,可以存储大量的结构化和非结构化数据,并提供快速和高效的搜索、分析和查询功能。在Kubernetes中,Elasticsearch可以作为日志数据的中心存储和索引服务,通过Fluentd-elasticsearch将所有节点和容器的日志数据集中到Elasticsearch集群中。
Fluentd-elasticsearch可以提供以下优点:
-
中心化的日志存储:通过将所有节点和容器的日志数据存储到一个中心化的Elasticsearch集群中,可以方便地进行日志检索和分析,同时也可以减少存储和维护成本。
-
实时的日志搜索和查询:Elasticsearch提供了快速和高效的搜索和查询功能,可以实时地搜索和查询日志数据,方便进行故障排查和性能优化。
-
丰富的日志分析和可视化工具:Elasticsearch提供了强大的聚合、过滤和可视化功能,可以帮助用户更深入地分析和理解日志数据,并及时发现问题和异常。
-
高度可定制化:Fluentd-elasticsearch提供了丰富的配置选项和插件机制,可以实现高度可定制化的日志收集和分析方案,以满足不同用户和场景的需求。
二、分层架构
2.1 生态系统
在接口层之上的庞大容器集群管理调度的生态系统,可以划分为两个范畴:
Kubernetes 外部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等
Kubernetes 内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
2.2 接口层
kubectl 命令行工具、客户端 SDK 以及集群联邦
2.3 管理层
系统度量(如基础设施、容器和网络的度量),自动化(如自动扩展、动态 Provision 等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy 等)
2.4 应用层
部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS 解析等)
2.5 核心层
Kubernetes 最核心的功能,对外提供 API 构建高层的应用,对内提供插件式应用执行环境
文章写的再细也不如看视频理解的透,我主要参照了该up主的视频,讲的非常好文章来源:https://www.toymoban.com/news/detail-602454.html
【完整版Kubernetes(K8S)全套入门+微服务实战项目,带你一站式深入掌握K8S核心能力】 https://www.bilibili.com/video/BV1MT411x7GH/?p=13&share_source=copy_web&vd_source=921dd22b5670d69481670cf6655563f5
文章来源地址https://www.toymoban.com/news/detail-602454.html
到了这里,关于第二讲:k8s集群架构与相关组件的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!