k8s(Kubernetes )架构简介,k8s(Kubernetes )各个组件之间的关系

注意:本文旨在向初学者简要介绍k8s(Kubernetes )架构,让初学者有一个整体的印象,不至于被k8s复杂的结构吓晕,特别是没有容器,pod等基本概念的时候。

1. 什么是k8s?

可以看看Kubernetes的中文维基百科。

Kubernetes(常简称为K8s)是用于自动部署、扩展和管理“容器化(containerized)应用程序”的开源系统。该系统由Google设计并捐赠给Cloud Native Computing Foundation(今属Linux基金会)来使用。

也就是说k8s是一个可以管理容器化应用程序的系统。初学者可能往往不清楚容器,docker,Kubernetes等这些基础的概念和它们之间的关系,可以参考我写的一篇博客:
什么是k8s以及k8s中的几个基本概念的关系:容器,docker,pod,deployment - harry的文章

2. k8s(Kubernetes )架构简介

下面这张图是k8s的架构图(来源:k8s官方网站)
k8s架构图
可以看到一个Kubernetes集群整体上由两部分组成:Control Plane(控制平面)和Node (节点)

2.1 Control Plane(控制平面)

Control Plane在很多地方也被称为master 节点(主节点),而其他的node也被称为worker节点(工作节点)(这里面也有master -worker的构建思想)。

控制平面组件会为集群做出全局决策,比如资源的调度。 以及检测和响应集群事件,例如当不满足部署的 replicas 字段时, 要启动新的 pod)。

控制平面组件可以在集群中的任何节点上运行。 然而,为了简单起见,设置脚本通常会在同一个计算机上启动所有控制平面组件, 并且不会在此计算机上运行用户容器。

我觉得这也是为什么Control Plane会被叫做主节点的原因吧。
它主要包括以下几个部分:

  • kube-apiserver API
    服务器是 Kubernetes 控制平面的组件, 该组件负责公开了 Kubernetes API,负责处理接受请求的工作提供了资源操作的唯一入口,并提供认证、授权、访问控制、相关等机制。 API 服务器是Kubernetes 控制平面的前端。

  • etcd
    一致且高度可用的键值存储,用作 Kubernetes 的所有集群数据的后台数据库,主要是保存了整个集群的状态。etcd 采用分布式、容错设计,被视为集群的最终事实来源。

  • kube-scheduler kube-scheduler 是 负责监视新创建的、未指定运行节点(node)的 Pods, 并调度节点来让 Pod 在指定的机器上面运行

  • kube-controller-manager
    kube-controller-manager 是控制平面的组件, 负责运行控制器进程。负责维护集群的状态,比如故障检测、自动扩展、滚动更新等。 从逻辑上讲, 每个控制器都是一个单独的进程, 但是为了降低复杂性,它们都被编译到同一个可执行文件,并在同一个进程中运行。

  • cloud-controller-manager
    这个组件和云平台有关系,不需要太多关心。 一个 Kubernetes 控制平面组件, 嵌入了特定于云平台的控制逻辑。 云控制器管理器(Cloud Controller Manager)允许你将你的集群连接到云提供商的 API 之上, 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes,或者在本地计算机中运行学习环境, 所部署的集群不需要有云控制器管理器。

2.2 Node

这里的Node 就是worker node,负责处理真正的业务需求的节点。包括以下几个部分

  • kubelet
    这是一个与控制平面通信的微型应用。kubelet 可确保容器在容器集内运行。当控制平面需要在节点中执行某个操作时,kubelet 就会执行该操作。

  • kube-proxy
    kube-proxy 是集群中每个节点(node)所上运行的网络代理, 实现 Kubernetes 服务(Service) 概念的一部分。
    kube-proxy 维护节点上的一些网络规则, 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
    如果操作系统提供了可用的数据包过滤层,则 kube-proxy 会通过它来实现网络规则。 否则,kube-proxy 仅做流量转发。

  • 容器运行时(Container Runtime)
    **容器运行环境是负责运行容器的软件。**默认的容器运行时为 Docker;其他还有containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现

当然还可以自己选择一些插件(add-on),这里不再赘述。

下面这两张图可能可以更加清晰地看到k8s各个组件之间的关系
Master Node
Worker Node

3. k8s(Kubernetes )架构中体现的分层的思想

其实这里可能还不太能看出k8s中的分层思想,在worker node内部有pod ,deployment, service, container等更能看出其中的分层的思想。其中的分层实现可能要以一个更大的范畴来进行考量。
可以参考参考资料2,比如里**面的api 接口和ecosystem也就是生态系统之间就存在着分层关系,外部的应用(如监控)可以利用这些api接口。而管理层和应用层之间的关系就包括上述master node和worker node之间的关系。**这些就是很深入的知识了。

参考资料:

下面的资料质量都很高,如果想要深入了解的话,很推荐大家看看

  1. k8s官方网站
  2. https://www.kubernetes.org.cn/docs
  3. https://www.redhat.com/zh/topics/containers/kubernetes-architecture

猜你喜欢

转载自blog.csdn.net/Sansipi/article/details/127036449