之前我曾经提到了一系列关于服务网格的内容。然而,我意识到有些同学可能对Kubernetes的了解相对较少,更不用说应用服务网格这个概念了。因此,今天我决定带着大家快速理解Kubernetes中的一些专有名词,以便在短时间内入门,并减少学习的时间。我将在接下来的5分钟内为你介绍这些名词,希望你能从中获得一些收获。如果你觉得有所帮助,请给个赞来鼓励我吧!你的支持是我前进的动力~

Kubernetes

首先,我想强调的是,在学习任何一项知识时,官方文档都是最重要的资源:https://kubernetes.io/zh-cn/docs/home/

官方文档提供了详尽、准确的信息,帮助我们深入了解和掌握这个技术。因此,如果你真的对Kubernetes感兴趣,我强烈建议你花些时间仔细阅读官方文档。

谈到Kubernetes,它是一个开源的容器编排引擎,旨在实现容器化应用的自动化部署、扩缩和管理。简而言之,它能够集中控制多个Docker容器,而不仅限于单独操作每个容器。在没有Kubernetes之前,如果我们想要同时操作多个Docker容器,可能需要学习并执行Shell脚本,这需要花费一些时间。因此,如果你希望实现批量管理Docker容器,Kubernetes就是一个不错的选择,当然也可以考虑其他类似的产品。

Kubernetes 组件

假设你已经顺利完成Kubernetes的安装。一旦你部署好Kubernetes,你就拥有了一个完整的集群。下面是官方提供的架构图,我们可以参考一下。图中列出了许多组件的名称,包括:Node、Pod、kubelet、kube-proxy、kube-apiserver、etcd、kube-scheduler、kube-controller-manager、cloud-controller-manager等一系列专有名词。接下来,我们将逐一解释这些名词的含义。

Node

根据架构图,你可能已经猜到Node实际上就是一台机器,它负责运行容器化的应用程序。然而,一个Node上可以运行多个Pod。Pod是Kubernetes的最小调度单位,通常情况下,一个Pod代表一个微服务。下面是一个Pod的YAML示例:

apiVersion: v1kind: Podmetadata:  name: my-podspec:  containers:    - name: my-container      image: nginx:latest

然而,这并不意味着一个Pod只能支持一个docker镜像。例如,我们的服务网格中存在边车模式,允许在同一个Pod中定义多个微服务。但为什么不在同一个Pod中定义多个微服务呢?这是因为Pod是最小的调度单位,它们需要一起启动和重启。这种绑定关系非常严格,因此如果你已经有一个集群,为什么不将它们分开定义呢?因此,即使定义多个镜像,也只需要定义一些辅助功能,如日志收集等。

kubelet

kubelet这个组件在整个Kubernetes系统中扮演着重要的角色。具体而言,控制平面将Pod的定义发送给kubelet,然后kubelet根据这些定义来创建和管理Pod中的容器。kubelet负责监控Pod和容器的状态,并将这些状态信息报告给控制平面。控制平面可以根据这些状态信息来做出调度和管理决策,以确保整个系统的高效运行。

你可以将Pod理解为每个项目组的招聘HR,类似于一个项目的招聘负责人。而控制平面则可以理解为上层的公司领导,他们制定了招聘要求和招聘人数,具体的招聘工作由HR来执行。HR的职责是确保项目有足够的人员,并且符合公司领导的要求。他们会持续监视项目的人员情况,一旦有人离职,他们会向上级报告,满足上层的控制平面要求。同时,上层的公司领导与项目人员是没有直接沟通的,所有的沟通都通过HR进行。HR在这个过程中起到了项目人员与上层领导之间的联络人的作用,负责传递信息、解决问题和协调工作。

kube-proxy

加长优化语句:我们在架构图中看到kube-proxy也是与上层有联系的。它通过服务代理和负载均衡功能,实现了集群内部的网络通信和流量转发,确保了服务的可用性和可靠性。

在我们的项目组中,他是谁呢?他是那位真正指导Pod要执行哪些任务的人。可以说,他担任着项目组中开发leader的角色,或者像项目经理一样的角色。他负责指导我们要做什么任务,一旦有需求,他会负责转发和分配工作。

然而,需要注意的是,他并不直接与Pod进行网络通信,而是与Service对象进行沟通。

Service

在上述情况中,我们引入了Service对象。实际上,Service对象代表了一组Pod资源。在生产环境中,我们通常不会只部署一个服务来处理请求,而是会有多个Pod副本同时处理。因此,我们需要一个Service对象将它们归类在一起,以便kube-proxy可以进行负载均衡转发等操作。只要Pod中的labels标签后面的key:value匹配,就可以将请求转发给相应的Pod副本。metadata下的labels字段可以包含任何键值对,只要符合key:value的格式即可。

apiVersion: v1kind: Podmetadata:  name: nginx  labels:    app.kubernetes.io/name: proxyspec:  containers:  - name: nginx    image: nginx:stable    ports:      - containerPort: 80        name: http-web-svc---apiVersion: v1kind: Servicemetadata:  name: nginx-servicespec:  selector:    app.kubernetes.io/name: proxy  ports:  - name: name-of-service-port    protocol: TCP    port: 80    targetPort: http-web-svc

控制平面组件

控制平面组件在集群中扮演着重要角色,它们负责做出全局决策,例如资源的调度,以及监测和响应集群事件,比如当部署的replicas字段不满足时,启动新的Pod。控制平面组件可以在集群中的任何节点上运行。然而,为了简化设置和管理,通常会在同一台计算机上启动所有控制平面组件,并且不会在该计算机上运行用户容器。可以将其类比为公司董事会,他们负责决策和管理,与实际执行工作的Pod之间关系不直接。

kube-apiserver

通过这个名字,你可以推断出他负责处理并调用其他组件来完成所有API请求。举个例子,我们之前定义了一个Pod的YAML格式文件。通过在后台执行kubectl apply -f your-pod.yaml,kube-apiserver就会接收到你的请求,并将其转发给谁呢?正如我们之前提到的,它会将请求转发给kubelet,kubelet负责与Docker进行交互并进行创建等操作。因此,kube-apiserver就像是我们的控制器一样,直接接收请求但不处理它们。

etcd

etcd是一种用作Kubernetes所有集群数据的后台数据库。不仅可以存储你能想到的所有数据,而且采用分布式存储方式,基于Raft算法确保数据的一致性。这使得所有节点都能保持数据的一致性,因为etcd存储了集群的配置数据、状态信息和元数据。作为集群的“大脑”,etcd存储了关于容器、节点、Pod、服务和其他资源的信息。通过监视etcd中的数据变化,服务发现机制能够实现自动的服务注册和发现。当新的Pod或服务被创建时,它们会在etcd中注册相关信息。其他组件或应用程序可以通过查询etcd来获取这些信息,从而实现服务之间的通信和协调。

kube-scheduler

我们当时说kubelet是负责管理该节点上的容器和Pod,那么谁来调度呢?就是由kube-scheduler负责。kube-scheduler的主要职责是从可用节点中选择最优节点来运行Pod,以确保资源的均衡分配,避免机器资源的浪费。由于控制平面组件较多,为了更好地理解它们各自的作用,我还额外准备了一张图来清晰地展示。

kube-controller-manager

kube-controller-manager是Kubernetes集群中不可或缺的核心组件之一,它的主要职责是运行一系列控制器,以确保集群的状态始终维持在预期的状态。为了更好地理解其功能,我们以Deployment Controller管理器为例进行说明,而其他控制器的详细信息则可以通过自行查询来获取。

Deployment Controller是一个负责管理应用部署的组件。它的主要功能是根据用户定义的期望状态来控制ReplicaSet的创建、更新和删除操作,从而实现应用的滚动升级和回滚。举一个例子。当一个Pod挂掉时,kubelet会首先监测到该Pod的状态改变,并将这个信息传递给kube-controller-manager中的Replication Controller(如果该Pod是由Replication Controller创建的)。Replication Controller是负责维护Pod副本数量的控制器之一。

一旦Replication Controller接收到关于Pod状态改变的通知,它将检查集群中当前的Pod副本数量,并根据其定义的副本数量进行调整。如果发现当前的Pod数量少于所需的副本数量,Replication Controller将发出指令给kubelet,在相应的节点上重新创建缺失的Pod来满足副本数量的要求。之前我们不是一直说将kubelet比作是HR吗?上层领导找到了就是Deployment Controller。

注意不管是什么管理层Controller都要走kube-apiserver这一层。只有他才有资格调用其他组件kube-apiserver。

cloud-controller-manager

cloud-controller-manager是一个可选的组件,它提供了与云平台相关的控制器。对于我们来说,它可能看起来与我们的工作无关。cloud-controller-manager在与云平台的API进行交互时,能够管理云资源,例如负载均衡器、节点组、存储卷等。这使得我们能够获得更丰富的云资源管理功能。需要注意的是,cloud-controller-manager的具体功能和行为是根据所使用的云平台而定的。因此,它可以根据我们所用的云平台提供适当的解决方案。

总结

在本文中,我向大家介绍了Kubernetes中的一些专有名词。Kubernetes是一个非常强大的容器编排引擎,可以帮助我们自动化部署、扩展和管理容器化应用程序。通过了解这些专有名词,我们可以更好地理解Kubernetes的工作原理和架构。因为大家的时间都很宝贵,所以我尽量减少阅读时间带大家快速入门Kubernetes,觉得不错,给个赞吧~