之前我曾经提到了一系列关于服务网格的内容。然而，我意识到有些同学可能对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，觉得不错，给个赞吧~