节点是Kubernetes集群的重要部分，负责运行容器化的工作负载。它的目的是向应用程序公开计算、网络和存储资源。
head节点通常运行控制平面，负责调度和管理工作负载的生命周期。worker节点运行应用程序。head节点和worker节点的集合就构成了一个集群。
每个Kubernetes节点包括一个容器运行时（比如Docker），以及一个与head通信的代理（kubelet）。节点可以是运行在云中的虚拟机（VM），也可以是数据中心内的裸金属服务器。
【容器运行时】
容器运行时负责管理节点中运行的每个容器的生命周期。在节点上调度pod之后，运行时从注册表中提取pod指定的镜像。当一个pod被终止时，运行时终止属于这个pod的容器。Kubernetes可以与任何符合OCI的容器运行时进行通信，包括Docker和CRI-O。
【Kubelet】
Kubelet是Kubernetes代理，其职责是与容器运行时交互以执行诸如启动、停止和维护容器等操作。
每个kubelet还监控pod的状态。当一个pod不符合部署定义的所需状态时，它可以在同一个节点上重新启动。节点的状态每隔几秒钟通过心跳消息传输到head。如果head检测到节点故障，复制控制器会观察到这种状态变化，然后在其他正常节点上调度pod。
【Kube-Proxy】
OCI是定义运行时规范和镜像规范的标准，其目的是推动容器运行时和镜像格式的标准化。
【日志记录层】
编排器经常使用日志记录来收集每个节点上容器的资源使用情况和性能指标，例如CPU、内存、文件和网络使用情况。CNCF托管了一个软件组件，该组件提供了一个统一的日志记录层，与Kubernetes或其他编排器（称为Fluentd）一起使用。这个组件生成Kubernetes主控制器需要的指标，以便跟踪可用的集群资源以及整个基础设施的运行状况。
【附加组件】
Kubernetes以附加组件的形式支持附加服务。这些可选服务（如仪表板）的部署方式与其他应用程序相同，但与节点上的其他核心组件（如日志记录层和kube-proxy）集成在一起。例如，dashboard组件从kubelet中提取指标，以可视化地显示资源利用率。DNS附加组件基于kube-dns或CoreDNS，通过名称解析来增强kube-proxy。
【工作负载是容器化的应用程序】
控制平面和worker节点构成核心集群基础设施，而工作负载是部署在Kubernetes中的容器化应用程序。
在开发和测试微服务之后，开发人员将其打包为容器，容器是打包为pod的最小部署单元。属于同一应用程序的一组容器在Kubernetes中被分组、打包、部署和管理。
Kubernetes公开了用于部署的原语，同时不断地扩展、发现和监控这些微服务的运行状况。命名空间通常用于从逻辑上分离一个应用程序和另一个应用程序。它们充当一个逻辑集群，为属于应用程序的所有资源和服务提供定义良好的边界和范围。
在命名空间中，将部署以下Kubernetes原语：
pod——pod是Kubernetes应用程序的基本执行单元。它是Kubernetes对象模型中最小、最简单的单元。pod也是Kubernetes应用程序中最小的可调度项。如果Kubernetes是一个操作系统，那么pod代表在集群上运行的一组进程，其中每个进程可以映射到一个容器。
pod是Kubernetes工作负载管理的核心单元，充当共享相同执行上下文和资源的容器的逻辑边界。将相关容器分组到pod中，可以一起运行多个相关进程，从而弥补了容器化取代第一代虚拟化时带来的配置挑战。
每个pod是一个或多个容器的集合，这些容器使用进程间通信（IPC）进行通信，并且可以共享存储和网络堆栈。在容器需要耦合并位于同一位置的场景中（例如，web服务器容器和缓存容器），它们可以很容易地打包在单个pod中。pod可以手动扩展，也可以通过称为Horizontal Pod Autoscaling（HPA）功能定义的策略进行扩展。通过这种方法，作为部署一部分的pod的数量根据可用资源按比例增加。
pod实现了开发和部署之间的功能分离。当开发人员专注于他们的代码时，运维人员可以专注于更广泛的情况来决定哪些相关的容器可以聚合到一个功能单元中。这样会带来最佳的可移植性，因为pod只是一个或多个容器镜像的清单。
【控制器】
在Kubernetes中，控制器通过添加额外的功能来扩充pod，比如所需的配置状态和运行时特性。
部署为pod带来声明性更新。它通过跟踪参与部署的pod的运行状况来保证始终保持所需的状态。每个部署都管理一个ReplicSet，它维护一组稳定的副本pod，在任何给定的时间运行，由所需的状态定义。
部署通过扩展、部署历史和回滚功能为pod带来类似PaaS的功能。当一个部署配置为最少两个副本时，Kubernetes确保至少有两个pod始终在运行，这带来了容错性。即使只使用一个副本部署pod，也强烈建议使用部署控制器，而不是普通的pod规范。
statefulset类似于部署，但用于需要持久性、定义良好的标识符和有保证的创建顺序的pod。对于数据库集群之类的工作负载，statefulset控制器将按照给定的顺序创建一组具有可预测命名约定的高可用性pod。需要高度可用的有状态工作负载，如Cassandra、Kafka、ZooKeeper和sqlserver，在Kubernetes中被部署为statefulset。
可以使用DaemonSet控制器来强制在集群的每个节点上运行pod。Kubernetes在新配置的worker节点中自动调度DaemonSet，因此它成为为工作负载配置和准备节点的理想选择。例如，如果在部署工作负载之前必须在节点上挂载现有的网络文件系统（NFS）或Gluster文件共享，建议将pod打包并部署为DaemonSet。监控代理可以用作DaemonSet，以确保每个节点都运行监控代理。
对于批处理和调度作业，可以将pod打包为run-to-completion作业或cron作业。作业创建一个或多个pod，并确保指定数量的pod成功终止。配置为“运行到完成”的pod执行作业并退出，而cron作业将根据crontab格式定义的计划运行作业。
控制器根据工作负载的特征及其执行上下文定义pod的生命周期。
编辑：青蓝咨询
来源于网络，如有侵权请及时联系
【联系青蓝咨询】
地址： 深圳市南山区高新南一道06号TCL大厦B座3楼309室 （公交站：大冲 地铁站：一号线高新园C出口）
邮编：518057
电话：0755-86950769
