1、K8S-组件介绍

K8S-组件介绍

文章目录

K8S-组件介绍
- 一、概述
- 二、K8S架构与组件
- - K8S架构
  - K8S组件
  - - [master 节点组件](#master 节点组件)
  - [1. 预选策略 (Predicate)](#1. 预选策略 (Predicate))
  - [2. 优选策略 (Priorities)](#2. 优选策略 (Priorities))
  - 总结与类比
  - - - etcd
    - node节点组件
    - - Kubelet
      - Kube-Proxy
      - [Controller Runtime](#Controller Runtime)
      - Pod
- 三、K8S核心概念
- [四、Kubetnetes 涉及的端口](#四、Kubetnetes 涉及的端口)

一、概述

Kubernetes 简称 k8s，是支持云原生部署的一个平台，起源于谷歌。谷歌早在十几年之前就对其应用，通过容器方式进行部署。

k8s 本质上就是用来简化微服务 的开发和部署的，关注点包括自愈和自动伸缩、调度和发布、调用链监控、配置管理、Metrics 监控、日志监控、弹性和容错、API 管理、服务安全等，k8s 将这些微服务的公共关注点以组件形式封装打包到 k8s 这个大平台中，让开发人员在开发微服务时专注于业务逻辑的实现，而不需要去特别关心微服务底层的这些公共关注点，大大简化了微服务应用的开发和部署，提高了开发效率。

官网：https://kubernetes.io
GitHub：https://github.com/kubernetes/kubernetes

K8S的由来

K8S由google的Borg系统(博格系统，google内部使用的大规模容器编排工具)作为原型，后经GO语言延用Borg的思路重写并捐献给CNCF基金会开源。
云原生基金会（CNCF）于2015年12月成立，隶属于Linux基金会。CNCF孵化的第一个项目就是Kubernetes，随着容器的广泛使用，Kubernetes已经成为容器编排工具的事实标准。

K8S的功能

跨主机编排容器。
更充分地利用硬件资源来最大化地满足企业应用的需求。
控制与自动化应用的部署与升级。
为有状态的应用程序挂载和添加存储器。
线上扩展或缩减容器化应用程序与它们的资源。
声明式的容器管理，保证所部署的应用按照我们部署的方式运作。
通过自动布局、自动重启、自动复制、自动伸缩实现应用的状态检查与自我修复。
为多个容器提供服务发现和负载均衡，使得用户无需考虑容器IP问题。

K8S解决的问题

K8S 解决了裸跑 Docker 的若干痛点：

单机使用，无法有效集群
随着容器数量的上升，管理成本攀升
没有有效的容灾、自愈机制
没有预设编排模板，无法实现快速、大规模容器调度
没有统一的配置管理中心工具
没有容器生命周期的管理工具
没有图形化运维管理工具

K8S 提供了容器编排，资源调度，弹性伸缩，部署管理，服务发现等一系列功能。

K8S的特性

弹性伸缩

使用命令、UI 或者基于 CPU 使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。

自我修复

在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

自动发布（默认滚动发布模式）和回滚

K8S 采用滚动更新策略更新应用，一次更新一个 Pod，而不是同时删除所有 Pod，如果更新过程中出现问题，将回滚更改，确保升级不影响业务。

集中化配置管理和密钥管理

管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在 K8S 中，方便应用程序使用。

存储编排，支持外挂存储并对外挂存储资源进行编排

挂载外部存储系统，无论是来自本地存储，公有云（如 AWS），还是网络存储（如 NFS、GlusterFS、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。

任务批处理运行

提供一次性任务，定时任务；满足批量数据处理和分析的场景。

二、K8S架构与组件

K8S架构

k8s 总体架构采用了经典的 maste/slave 架构模式，分 master 节点和 worker 节点，节点可以是虚拟机也可以是物理机。

K8S组件

master 节点组件

Kube-apiserver

用于暴露 Kubernetes API，任何资源请求或调用操作都是通过 kube-apiserver 提供的接口进行。以 HTTPRestful API 提供接口服务，所有对象资源的增删改查和监听操作都交给 API Server 处理后再提交给 Etcd 存储。
可以理解成 API Server 是 K8S 的请求入口服务。API Server 负责接收 K8S 所有请求（来自 UI 界面或者 CLI命令行工具），然后根据用户的具体请求，去通知其他组件干活。可以说 API Server 是 K8S 集群架构的大脑。

Kube-controller-manager

运行管理控制器，是 K8S 集群中处理常规任务的后台线程，是 K8S 集群里所有资源对象的自动化控制中心。在 K8S 集群中，一个资源对应一个控制器，而 Controller manager 就是负责管理这些控制器的。

由一系列控制器组成，通过 API Server 监控整个集群的状态，并确保集群处于预期的工作状态，比如当某个 Node意外宕机时，Controller Manager 会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

控制器类型	作用
Node Controller（节点控制器）	负责在节点出现故障时发现和响应。
Replication Controller（副本控制器）	负责保证集群中一个 RC（资源对象 Replication Controller）所关联的 Pod 副本数始终保持预设值。可以理解成确保集群中有且仅有 N 个 Pod 实例，N 是 RC 中定义的 Pod 副本数量。
EndpointsController（端点控制器）	填充端点对象（即连接 Services 和 Pods），负责监听 Service 和对应的 Pod副本的变化。可以理解端点是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道它的 endpoint。
Service Account & Token Controllers（服务帐户和令牌控制器）	为新的命名空间创建默认帐户和 API 访问令牌。
ResourceQuota Controller（资源配额控制器）	确保指定的资源对象在任何时候都不会超量占用系统物理资源。
Namespace Controller（命名空间控制器）	管理 namespace 的生命周期。
Service Controller（服务控制器）	属于 K8S 集群与外部的云平台之间的一个接口控制器。

Kube-scheduler

是负责资源调度的进程，根据调度算法为新创建的 Pod 选择一个合适的 Node 节点。
可以理解成 K8S 所有 Node 节点的调度器。当用户要部署服务时，Scheduler 会根据调度算法选择最合适的 Node 节点来部署 Pod。
预选策略（predicate）
优选策略（priorities）

好的，我们来详细解释 Kubernetes 调度器中关于节点调度的两个核心阶段：预选（Predicate） 和 优选（Priorities）。

简单来说，这是一个"过滤-打分"的两阶段决策过程：

预选 (Predicate) ：过滤掉所有不满足 Pod 基本运行需求的节点。这是一个"是或否"的布尔判断。
优选 (Priorities) ：在通过预选的节点中，根据一系列策略给每个节点打分，并选择得分最高的节点。

1. 预选策略 (Predicate)

预选策略是一组硬性条件，用于初步筛选节点。如果任何一个预选策略检查失败，该节点就会被立即排除，没有资格运行当前 Pod。这个过程是并行的。

核心算法/策略包括（但不限于）：

策略名称	功能描述
`PodFitsResources`	检查节点剩余的 CPU 和内存资源是否满足 Pod 的 `requests` 配置。这是最基础的资源检查。
`PodFitsHostPorts`	检查 Pod 声明的 `hostPort` 在节点上是否已经被占用。
`HostName`	检查节点名称是否匹配 Pod 配置中的 `spec.nodeName`（通常由用户直接指定，跳过调度）。
`MatchNodeSelector`	检查节点的标签 (`labels`) 是否满足 Pod 配置的 `nodeSelector` 或 `nodeAffinity`（节点亲和性）的要求。
`NoVolumeZoneConflict`	在集群跨多个故障域（如 AWS 的 Availability Zone）时，检查 Pod 请求的持久卷 (PV) 是否与节点在同一区域，避免跨域挂卷。
`CheckNodeMemoryPressure`	检查节点是否存在内存压力。如果存在，则不会将新的 Pod 调度到该节点（除非 Pod 有特定容忍设置）。
`CheckNodePIDPressure`	检查节点上的进程 ID (PID) 资源是否不足。
`CheckNodeDiskPressure`	检查节点是否存在磁盘空间压力（例如根分区可用空间不足）。
`CheckNodeCondition`	检查节点状态是否正常，如 `Ready`、`OutOfDisk`、`NetworkUnavailable` 等。
`PodToleratesNodeTaints`	检查 Pod 的 `tolerations`（容忍）是否能够容忍（匹配）节点的 `taints`（污点）。这是实现污点与容忍机制的核心。

工作流程：

调度器会遍历所有节点，对每个节点并行执行所有配置的预选策略。只有通过所有策略的节点，才会被加入到"合格节点"列表，进入下一阶段（优选）。

2. 优选策略 (Priorities)

优选策略用于对通过预选的节点进行排序。每个策略都会给节点计算一个分数（通常为 0-10 分）， scheduler 会将所有策略的分数按权重加权求和，得到节点的最终得分，并选择得分最高的节点。如果有多个节点得分相同，则随机选择一个。

核心算法/策略包括（但不限于）：

策略名称	功能描述	目标
`LeastRequested`	`得分 = ((节点总容量 - Pod请求量 -节点已分配量) / 节点总容量) * 10`	优先选择资源空闲率更高的节点，使集群负载更均衡。
`BalancedResourceAllocation`	计算 CPU 和内存使用率的差值，差值越小得分越高。	优先选择 CPU 和内存使用率更均衡的节点，避免一个资源耗尽而另一个资源剩余很多。
`ImageLocality`	根据节点上是否已存在 Pod 所需的容器镜像以及镜像的大小来评分。	优先选择已有所需镜像的节点，减少拉取镜像的时间。
`NodeAffinity`	根据 `preferredDuringSchedulingIgnoredDuringExecution`（偏好）规则进行评分。匹配的表达式越多，得分越高。	实现 Pod 对节点的软性偏好。
`TaintToleration`	根据 Pod 对节点污点的容忍程度进行评分。需要容忍的污点越多，得分越低。	优先选择需要容忍的污点更少的节点。
`InterPodAffinity`	根据 Pod 间亲和性 (`podAffinity`/`podAntiAffinity`) 的 `preferred` 规则进行评分。	实现 Pod 之间的软性亲和或反亲和。
`SelectorSpread`	尽量将属于同一个 Service、StatefulSet 或 ReplicaSet 的 Pod 分散到不同的节点、机架或可用区上运行。	提高应用的高可用性，避免单点故障。

工作流程：

对每个通过预选的节点，遍历所有优选策略。
每个策略为该节点打一个分（score）。
每个策略都有一个权重（weight），最终得分是 score * weight 的加权和。
选择总分最高的节点。如果多个节点分数相同，则随机选择。

总结与类比

你可以把这个过程想象成 "招聘过程"：

预选 (Predicate) ：就像简历筛选。
- 硬性条件："本科以上学历"、"5年以上工作经验"、"必须掌握Go语言"。
- 不符合任何一条的候选人直接淘汰，不会进入面试。
优选 (Priorities) ：就像面试打分。
- 面试官们（不同策略）从不同维度（技术能力、沟通能力、文化契合度）给候选人打分。
- 每个维度的权重可能不同（例如技术能力权重为 2，沟通能力权重为 1）。
- 最后将加权分相加，选择总分最高的候选人。

Kubernetes 调度器通过这个强大、灵活且可扩展的两阶段模型，能够智能地做出最合适的调度决策，满足复杂多样的部署需求。你也可以编写自己的调度器扩展（Scheduler Framework）来添加自定义的预选和优选策略。

etcd

K8S 的存储服务。etcd 是分布式键值存储系统，存储了 K8S 的关键配置和用户配置，K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据。

node节点组件

在 Kubernetes 集群中，在每个 Node（又称 Worker Node）上都会启动一个 kubelet 服务进程。该进程用于处理 Master 下发到本节点的任务，管理 Pod 及 Pod 中的容器。每个 kubelet 进程都会在 API Server 上注册节点自身的信息，定期向 Master 汇报节点资源的使用情况，并通过 cAdvisor 监控容器和节点资源。

Kubelet

Node 节点的监视器，以及与 Master 节点的通讯器。Kubelet 是 Master 节点安插在 Node 节点上的"眼线"，它会定时向 API Server 汇报自己 Node 节点上运行的服务的状态，并接受来自 Master 节点的指示采取调整措施。
从 Master 节点获取自己节点上 Pod 的期望状态（比如运行什么容器、运行的副本数量、网络或者存储如何配置等），直接跟容器引擎交互实现容器的生命周期管理，如果自己节点上 Pod 的状态与期望状态不一致，则调用对应的容器平台接口（即 docker 的接口）达到这个状态。
管理镜像和容器的清理工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源。

Kube-Proxy

在每个 Node 节点上实现 Pod 网络代理，是 Kubernetes Service 资源的载体，负责维护网络规则和四层负载均衡工作。负责写入规则至iptables、ipvs实现服务映射访问的。
Kube-Proxy 本身不是直接给 Pod 提供网络，Pod 的网络是由 Kubelet 提供的，Kube-Proxy 实际上维护的是虚拟的 Pod 集群网络。
Kube-apiserver 通过监控 Kube-Proxy 进行对 Kubernetes Service 的更新和端点的维护。
在 K8S 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 K8S 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都会运行一个 Kube-proxy 组件。

Controller Runtime

容器引擎，如：docker、containerd，运行容器，负责本机的容器创建和管理工作。
当 kubernetes 把 pod 调度到节点上，节点上的 kubelet会指示 docker 启动特定的容器。接着，kubelet 会通过 docker 持续地收集容器的信息，然后提交到主节点上。docker 会如往常一样拉取容器镜像、启动或停止容器。不同点仅仅在于这是由自动化系统控制而非管理员在每个节点上手动操作的。

Pod

k8s 中特有的一个概念，可以理解为对容器的包装，是 k8s 的基本调度单位，一个 Pod 代表集群上正在运行的一个进程，实际的容器是运行在 Pod 中的，可以把 Pod 理解成豌豆荚，而同一 Pod 内的每个容器是一颗颗豌豆。一个节点可以启动一个或多个 Pod。生产环境中一般都是单个容器或者具有强关联互补的多个容器组成一个 Pod。

三、K8S核心概念

概念	作用
cluster	集群，Cluster指的是由Kubernetes管理的一组节点和资源池。由Master和多个Worker节点组成，Master用于集群管理和控制，而Worker节点用于运行应用程序和Pod。提供了一种可扩展的、弹性的平台，用于分布式应用程序和容器的部署和管理。
node	节点，是集群中的工作节点，用于运行Pod和容器。是物理或虚拟机器，具有足够的资源（CPU、内存、存储）来运行容器化的应用。Kubernetes会自动将Pod调度到可用的节点上，以实现负载均衡和高可用性。
Container	容器，容器是一种轻量级的虚拟化技术，用于隔离和运行应用程序及其依赖项。将应用程序与其运行时环境进行隔离，并提供了一个独立的运行空间，使得应用程序可以在不同的环境中移植和部署。
Namespace	命名空间， Namespace用于在Kubernetes集群中划分虚拟的资源隔离区域。可用于组织和管理资源，以及为不同的团队、项目或环境提供逻辑分离。在一个集群中，可以有多个命名空间，每个命名空间都有自己的一组资源和访问策略。
Pod	容器组，Kubernetes基本调度单位，可以包含一个或多个容器。这些容器共享相同的网络和存储资源，并运行在同一主机上。提供了一个隔离的运行环境，为容器提供了共享的IP地址和端口空间。通常，Pod用于运行关联的容器，例如共享相同的资源和上下文的应用程序。
Service	服务， Service定义了一组Pod的稳定网络终点，通过标签选择器与这些Pod进行关联。充当入口和负载均衡器，封装了一组Pod，并提供一个持久的访问地址（Cluster IP或Node IP）。还支持内部服务发现和跨集群通信。
ReplicaSet	副本集，ReplicaSet用于定义Pod的副本数量和在集群中的运行策略，确保指定的Pod副本数始终运行，并根据需要进行自动扩展或收缩。当Pod由于故障或节点故障而终止时，ReplicaSet会自动重新启动新的Pod副本。
Deployment	部署，Deployment是一种用于声明化管理Pod和ReplicaSet的资源对象。可以定义Pod的期望状态，自动创建和更新ReplicaSet，并实现滚动升级和回滚策略，以确保无缝的应用程序更新。
ConfigMap	配置映射，ConfigMap是一种存储配置数据的资源对象，用于将配置参数传递给应用程序。可以存储环境变量、配置文件、命令行参数等。可以与Pod或容器相关联，并在容器启动时注入相关的配置信息。
Secrets	密钥用于安全地存储和管理敏感信息，如密码、凭证等。 -Kuberentes中的Secret是一种资源对象，用于存储和传递加密的数据。 -密钥可以被挂载到容器中，用于应用程序的配置文件或认证凭证。
DaemonSet	DaemonSet是Kubernetes中的一个重要概念，提供了一种简单且可靠的方式来在集群的所有节点上运行相同的Pod，适用于许多系统级任务和后台进程的部署场景。 1.每个节点一个Pod副本：DaemonSet会在集群的每个节点上启动一个Pod副本，以确保每个节点都有该Pod的运行实例。 2. 系统级任务和守护进程：DaemonSet通常用于运行系统级任务和守护进程，例如日志收集器、监控代理和网络代理等。这些任务通常需要在每个节点上运行，并且要与节点的生命周期同步。 3. 自动扩缩容：当有新节点加入集群或某个节点从集群中移除时，DaemonSet会自动检测节点的状态变化，并相应地启动或终止Pod副本。 4. 节点亲和性规则：可以通过节点亲和性规则来选择在哪些节点上运行DaemonSet的Pod。这允许你将特定的任务或服务与特定类型的节点关联起来。 5. 资源限制和调度约束：可为DaemonSet中的Pod指定资源限制和调度约束，以确保它们在节点上均匀分布并满足资源需求。

四、Kubetnetes 涉及的端口

角色	协议	方向	端口范围	组件	使用者
master	TCP	入站	6443	kube-apiserver	所有
	TCP	入站	2379~2380	etcd	kube-apiserver
	TCP	入站	10250	kubelet	kube-apiserver，自身
	TCP	入站	10259	kube-scheduler	自身
	TCP	入站	10257	kube-controller-manager	自身
node	TCP	入站	10250	kubelet	kube-apiserver
	TCP	入站	30000~32767	Service NodePort	自身

0257 | kube-controller-manager | 自身 |

| node | TCP | 入站 | 10250 | kubelet | kube-apiserver |

| | TCP | 入站 | 30000~32767 | Service NodePort | 自身 |