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，觉得不错，给个赞吧~

文章转载自：努力的小雨

原文链接：https://www.cnblogs.com/guoxiaoyu/p/17876335.html

体验地址：http://www.jnpfsoft.com/?from=001