共计 8028 个字符，预计需要花费 21 分钟才能阅读完成。
博客:cbb777.fun
全平台账号: 安妮的心动录
github: https://github.com/anneheartrecord
下文中我说的可能对，也可能不对，鉴于笔者程度无限，请君自辨。有问题欢送大家找我探讨
K8S 概述
什么是 K8S？
Kubernetes 是一个可移植、可扩大的开源平台，用于治理容器化的工作负载和服务，可促成申明式配置和自动化。名字源于希腊语，象征 ” 舵手 ”
k8s 呈现的必要性
依照部署的形式来进行划分，咱们能够简略的划分成四个时代
传统部署时代
如图一一样，APP 部署在 OS 上，OS 跑在硬件上。这会导致一个问题，如果在同一台机器上运行多个应用程序，如果某一个 APP 占用了机器的大部分资源，那么就会影响到其余 APP，造成性能抖动甚至饿死的严重后果
虚拟化部署时代
为了解决上述问题，虚拟化技术被引进了，虚拟化技术容许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。虚拟化能使应用程序在不通过的 VM 之间被彼此隔离，且能提供肯定水平的安全性，因为一个应用程序的信息不能被另一应用程序随便拜访。
虚拟化技术可能更好地利用物理服务器的资源，并且能够更加轻松地增加、更新应用程序，因而具备更强的可扩缩性，以及升高硬件老本等等的益处
容器部署时代
容器相似于 VM，然而相比于 VMWare 生成的那种 VM，容器更加轻量级，并且与 VM 相似，每个容器都具备本人的文件系统、CPU、内存、过程空间等等，容器之间能够共享 OS。容器和基础架构是拆散的，因而能够跨云和 OS 发行版进行移植
容器的劣势
- 麻利应用程序的创立和部署：相比于 VM 镜像更加简便，进步了容器镜像创立的简便性和效率
- 继续开发、集成和部署：基于镜像不可变性，通过疾速简略的回滚，提供牢靠且频繁的容器镜像构建和部署
- 关注开发和运维的拆散：在构建、公布时创立镜像，而不是部署的时候，从而将利用与基础架构进行拆散
- 可察看性：不仅能够显示 OS 级别的信息和指标，还可能显示应用程序的运行状态、其余指标信号
- 跨开发、测试和生产的环境一致性：在开发物理机上也能够和在云中运行一样的应用程序
- 跨云和操作系统发行版本的可移植性：可在任意环境运行
- 松耦合、分布式、弹性：一个大的单体被分解成较小的服务，并且能够动静的治理和部署，而不是在一台大型单机上整体运行
- 资源隔离：可预测的应用程序性能
- 资源利用：高效率和高密度
K8S 能做什么
上文咱们说到，容器是打包和运行应用程序的很好的一种形式，而在生产环境中，咱们须要对很多容器（容器的集群）进行治理，保障服务不会出故障、确保服务的可靠性，稳定性。
例如一个容器产生故障，则须要把这个容器下掉，新增一个运行该服务的容器，再把它上线。而 K8S 就是帮忙咱们实现这个过程，简化操作流程的工具
K8S 的性能
- 服务发现与负载平衡：K8S 能够应用 DNS、或者本人的 IP 来裸露容器，如果进入容器的流量很大，K8S 通过 Kube-Proxy 来实现的负载平衡，可反对的负载平衡算法有（轮询、起码链接、IP 哈希），默认为轮询，通过负载平衡来调配网络流量，从而使部署更加稳固
- 存储编排：K8S 容许主动挂载你抉择的存储系统，例如本地存储、公共云提供商等
- 主动部署和回滚：能够应用 K8S 形容已部署容器的所需状态，并管制状态更改的速率
- 主动实现装箱计算：当 K8S 领有许多节点组成一个集群之后，在这个集群上运行容器化的工作时，能够告知 K8S 每个容器须要多少资源（CPU 内存等），K8S 能够将这些容器按理论状况调度到节点上，以最佳形式利用调配的资源
- 自我修复：K8S 将重新启动失败的容器、替换容器、杀死不响应用户定义的健康检查的容器，并且在筹备好服务之前不将其通告给客户端
- 密钥与配置管理：K8S 容许你存储和治理敏感信息，例如明码、OAuth 令牌和 SSH 密钥，能够在不重建容器镜像的状况下部署和更新密钥以及应用程序配置，也无需在堆栈配置中裸露密钥
K8S 组件
上述是 K8S 运行的架构流程图，咱们能够看得出来，一个 K8S 集群次要由两局部组成，别离是 Control Plane 管制立体，老版本也叫做 Master；Node工作节点，老版本也叫做 Worker Node
咱们将一组工作机器称为节点，节点会运行容器化应用程序，每个集群至多有一个工作节点。工作节点会托管 Pod，管制立体治理集群中的工作节点与 Pod
整体的一个典型的工作流程如下：
- 用户应用 K8S API 与 API 服务器交互，公布应用程序的形容（如 Pod Service 等）
- 调度器依据应用程序的要求抉择适合的节点，并将工作指派给节点上的 Kubelet
- Kubelet 依据指令在节点上创立和治理容器，确保它们的状态与冀望的状态
管制立体组件
管制立体组件会为集群做出整体决策，比方资源的调度，以及检测和响应集群事件。能够了解成 K8S 集群的大脑，负责管理和管制整个集群的行为。
管制立体组件能够在集群中的任何节点上运行，通常来说为了简略起见，只会在同一个计算机上启动所有的管制立体组件，并且不会在这台机器上运行任何容器
kube-apiserver
API 服务器是 K8S 管制立体的组件之一，提供了与 K8S 集群通信的接口，容许用户和其余组件通过 HTTP RESTful API 与 K8S 进行交互，这个组件负责公开 K8S API，负责解决承受申请的工作，验证并配置 API 对象的数据，这些对象包含 pods services replicationcontrollers 等，为 REST 操作提供服务，能够将它简略了解为 K8S 管制立体的前端，其余所有组件都通过该前端进行交互。
同时，API SERVER 还负责验证申请的身份和权限，通过 Token UserName/Password TLS 证书等进行确认和交互，验证用户或者组件的身份，一旦用户验证胜利，API Server 会应用拜访控制策略进行角色受权
并且它负责资源管理，保护一组长久化存储 (etcd) 来存储资源的配置、状态和元数据
它还负责记录集群中的事件和日志信息，当资源对象发生变化或者呈现谬误的时候，它会生成事件并将其发送给订阅者
etcd
它是一个分布式的统一且高可用的键值存储，用作 k8s 所有集群数据的后盾数据库，存储集群的配置数据、元数据和状态信息的牢靠长久化存储。etcd 提供了高可用性、一致性和分布式的个性，为 K8S 的管制立体组件提供了一个共享的数据存储，API Server、kube scheduler 和 CM 等组件通过应用 etcd 来存储和检索集群的配置信息、资源对象的状态以及各种元数据，这些信息包含 Pod Service Namespace PersistentVolume 等的定义和状态
etcd 的一些要害性能
- 分布式存储：etcd 应用 Raft 一致性算法来实现数据的分布式存储，它将数据分片并复制到集群中的多个节点上，确保数据的可用性和容错性，这意味着即便一些节点生效，集群应该能够持续失常工作
- 一致性：etcd 的 Raft 算法保障了数据的一致性，所有的写操作都须要通过少数节点的确认，确保数据的正确复制和同步，这样能够防止数据损坏和不统一的状况产生
- 高可用性：etcd 具备高可用性，通过在集群中的多个节点上复制数据，提供了容错能力
- 疾速读写：etcd 通过在内存中保持数据的正本，实现了疾速的读写操作，应用 B + 树作为底层数据结构，提供高效的索引和检索性能
- 监控和故障复原：etcd 提供了一些监控和故障复原机制，能够监测节点的状态和健康状况。当节点产生故障或变得不可用时，集群能够主动进行从新选举，抉择新的领导者节点来接管工作
kube-scheduler
负责监督新创建的、未指定运行节点（node）的 Pods，并抉择节点来让 Pod 运行在该节点上，以实现负载平衡、资源利用率最大化和高可用性
调度决策思考的因素包含：单个 Pod 及 Pods 汇合的资源需要、软硬件及策略束缚、亲和性及反亲和性标准、数据地位、工作负载间的烦扰及最初时限
scheduler 的次要性能如下
- 资源调度：scheduler 依据容器的资源需要（如 CPU 内存）和节点的资源利用率，决定将工作负载调度到哪个节点上运行
- 节点抉择：scheduler 依据工作负载的要求，抉择适宜的节点进行调度，通过筛选和评分机制来抉择节点，同时 scheduler 还思考亲和性规定，以便将相干的工作负载调度到同一节点上，进步应用程序的性能和效率
- 拓展性和灵活性：scheduler 具备可插拔的架构，容许用户依据本人的需要自定义和拓展调度算法，用户能够实现自定义的调度策略，通过调整评分函数和优先级规定来满足特定的业务需要
- 调度器扩大：k8s 提供了灵便的调度器扩大机制，容许用户增加额定的带哦负气，这些调度器能够依据特定的需要和场景来实现自定义的调度逻辑
工作流程如下：
- 用户创立或者更新一个工作负载的形容，例如 Deployment StatefulSet 等
- 当新的工作负载被提交时，Scheduler 接管到这个事件，并依据工作负载的需要和集群状态进行调度决策
- Scheduler 遍历集群中的可用节点，评估每个节点的适宜水平，并为每个节点打分
- Schedulergenuine 打分后果抉择最合适的节点，并将工作负载的调度决策告诉给相应的节点的 Kubelet
- Kubelet 在抉择的节点上启动和治理容器，并把容器的状态报告给管制立体
kube-controller-manager(cm)
负责运行控制器过程，实践上来说每个控制器都是一个独立的过程，然而为了升高复杂性，它们都被编译到一个可执行文件中，并且在同一个过程中运行。
这些控制器包含
- 节点控制器（Node Controller）：负责在节点呈现故障时进行告诉和响应
- 工作控制器（Job Controller）：监测代表一次性工作的 JOB 对象，而后创立 Pods 来运行这些工作直至实现
- 端点分片控制器（EndpointSlice controller）：填充端点分片对象，以提供给 Service 和 Pod 之间的链接
- 服务账号控制器（ServiceAccount controller）：为新的命名空间创立默认的服务账号
工作流程如下：
- CM 启动时，它的各个控制器开始监督集群中的特定资源对象
- 控制器通过 API Server 获取资源对象的以后状态，并将其与所须要的冀望状态进行比照
- 如果二者不统一，那么控制器会触发相应的操作来使它们保持一致，这可能包含创立、更新或者删除资源对象
- 控制器通过 API Server 收回相应的操作申请，将更改利用于集群中的资源对象
- 控制器一直循环执行，以确保资源对象的状态和行为与冀望状态保持一致
cloud-controller-manager(ccm)
嵌入了特定的云平台管制逻辑，云控制器管理器容许将你的集群连贯到云提供商的 API 之上，并将与该云平台交互的组件同你的集群交互的组件拆散开来。
与 cm 相似，ccm 将若干逻辑上独立的管制回路组合到同一个可执行文件中，供你以同一过程的形式运行。你能够对其执行程度扩容以晋升性能或者加强容错能力。
- 节点控制器（Node Controller）：用于在节点终止响应后检察云提供商以确定节点是否已被删除
- 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
- 服务控制器（Service Controller）：用于创立、更新和删除云提供商负载均衡器
工作流程如下：
- CCM 组件在启动的时候与云平台的 API 进行认证和链接，并监督云资源对象的状态
- CCM 的控制器通过与云平台的 API 进行交互，获取云平台资源对象的状态，并将其与 K8S 中的对象进行比拟
- 如果二者状态不统一，CCM 的控制器会触发相应的操作，通过与云平台的 API 发出请求，将更改利用于云资源
工作节点组件
节点组件会在每个节点上运行，负责保护运行的 pod 并提供 K8S 运行环境
kubelet
kubelet 会在集群中每个节点 (node) 上运行，它保障容器 (containers) 都运行在 Pod 中。
kubelet 接管一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中形容的容器处于运行状态且衰弱，kubelet 不会治理不是由 k8s 创立的容器，kubelet 是 k8s 集群中的每个 node 上的次要组件之一，负责管理节点上的容器化工作负载，与管制立体交互，确保集群中的容器正确运行，并且保护节点的衰弱状态
次要性能：
- 容器治理：kubelet 负责在节点上创立、启动、进行和销毁容器，它通过与容器运行时（Docker Containerd）进行交互，执行容器的生命周期治理操作
- 资源管理：Kubelet 监控节点的资源应用状况，并依据预约义的资源配额和调度策略来分配资源给容器，它会定期向 K8S 管制立体报告节点上的资源状态
- 健康检查：Kubelet 定期对节点上的容器进行健康检查，包含容器的存活状态、资源利用率等，如果容器故障或者资源有余，Kubelet 会尝试重启、复原或迁徙容器
- 节点注册：Kubelet 在节点启动时将本身注册到 K8s 管制立体，使管制立体可能治理和监控该节点上的容器化工作负载
- 网络管理：Kubelet 配置节点上的网络参数，包含容器网络和节点网络。它为容器调配 IP 地址，并配置容器之间和容器与内部的网络通信
- 卷治理：Kubelet 负责挂在和卸载容器中应用的长久卷，它与卷插件交互，使容器能拜访和应用长久化存储
- 日志和监控：Kubelet 收集和治理节点上容器的日志和监控数据，它能够将日志发送到集中式日志零碎，并提供容器的运行指标和事件信息
工作流程如下：
- Kubelet 监听来自 K8S 管制立体的指令和命令
- K8S 获取须要在节点上运行的 pod 列表，并依据指定的 pod 标准创立和治理容器
- 对于每个容器，Kubelet 通过容器运行时（如 Docker）来启动和进行容器，并监控其状态
- Kubelet 定期向 K8s 管制立体报告节点的资源应用状况和容器状态
- Kubelet 定期凑够管制立体获取 Pod 的更新和变更，并相应地执行容器的生命周期治理操作
kube-proxy
kube-proxy 是集群中每个节点 (node) 上所运行的网络代理，实现 k8s 概念的一部分，它保护节点上的一些网络规定，这些网络规定会容许从集群外部或内部的网络会话与 Pod 进行网络通信。运行在每个节点上，并与 K8S 管制立体和节点上的网络组件进行交互，以实现服务的可拜访性和网络流量的转发
如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规定，否则，kube-proxy 只做流量转发
次要性能：
- 服务代理：Kube-proxy 监听 K8S 管制立体中的服务和短空定义，并为它们创立对应的网络代理规定，这些规定通常基于 IP Tables 或者 IPVS，依据服务的选择器和端口信息，将流量转发到相应的后端 pod
- 负载平衡：Kube-proxy 实现了负载平衡性能，将来自集群外部和内部的网络申请平均地散发到后端的 Pod。它能够基于轮询、随机抉择或起码连贯等算法来进行负载平衡
- 服务发现：Kube-proxy 监听 K8S 管制立体中国的服务和端口定义的变动，当服务的 Pod 正本数量发生变化、服务的标签或者端口信息产生变更时，Kube-proxy 会相应地更新代理规定，以确保服务的拜访失常
- 节点故障解决：Kube-proxy 监测节点的衰弱状态，并在节点故障或网络中断的状况下自动更新代理规定，它会将流量从新路由到其余衰弱节点上的 Pod，以保障服务的高可用性
- 通明代理：Kube-proxy 反对通明代理模式，能够在不批改利用程序代码的状况下，将应用程序流量转发到后端 Pod。这种形式对应用程序是通明的，它们无需感知代理的存在
Kube-proxy 的工作流程如下：
- Kube-proxy 从 K8S 管制立体获取服务和端口定义，并为每个服务创立代理规定
- 当有新的服务或端口定义增加到集群中，或者现有的定义发生变化时，Kube-proxy 监测到变动并相应地更新代理规定
- Kube-proxy 监听来自服务裸露的端口上的网络流量
- 依据代理规定，Kube-proxy 将流量转发到后端 Pod 上的容器，实现负载平衡和服务发现的性能
Container Runtime 容器运行时
容器运行环境是负责运行容器的软件，K8S 反对许多容器运行环境，例如 containerd CRI-O 以及 K8S CRI 的其余任何实现
Container Runtime（容器运行时）是 Kubernetes 中负责管理和运行容器的外围组件。它提供了创立、启动、进行和销毁容器的性能，以及治理容器的资源和隔离性。
Kubernetes 反对多种容器运行时，其中最罕用的是 Docker 和 Containerd。上面将具体介绍容器运行时的工作原理和性能：
- 容器生命周期治理：容器运行时负责与容器生命周期相干的操作。它能够依据容器镜像创立并启动容器，监控容器的运行状态，并在须要时进行或销毁容器。
- 容器隔离性：容器运行时应用 Linux 内核的命名空间和控制组（cgroup）等个性，为容器提供隔离的运行环境。每个容器都具备独立的文件系统、网络栈、过程空间和资源限度，从而实现容器之间的隔离和安全性。
- 容器网络：容器运行时负责设置和治理容器的网络。它为每个容器调配惟一的 IP 地址，并解决容器之间的网络通信。容器运行时还能够与网络插件协同工作，以实现更高级的网络性能，如跨主机的容器通信和负载平衡。
- 容器存储：容器运行时治理容器的存储。它能够为容器提供本地存储卷或挂载内部存储卷，使容器可能长久化存储和拜访数据。
- 容器镜像治理：容器运行时负责下载、治理和缓存容器镜像。它能够从容器镜像仓库中拉取镜像，并将其存储在本地节点上，以便在须要时疾速创立容器。
- 容器资源管理：容器运行时与 Kubernetes 的调度器和资源管理器交互，以确保容器在节点上失去适当的资源分配。它能够依据容器的资源需要和节点的可用资源进行调度和限度，以实现资源的偏心调配和利用。
容器运行时在 Kubernetes 中的工作流程如下：
- Kubernetes 管制立体下发容器启动的指令，包含容器镜像、资源要求等信息。
- 容器运行时依据指令从容器镜像仓库拉取镜像，并创立容器的运行时环境。
- 容器运行时应用 Linux 命名空间和控制组等性能，为容器提供隔离的运行环境。
- 容器运行时启动容器中的应用程序，并监控容器的运行状态。
- 容器运行时与容器网络 插件协同工作，为容器调配 IP 地址，并解决容器之间的网络通信。
- 容器运行时依据 Kubernetes 管制立体的指令，进行或销毁容器。
总之，容器运行时是 Kubernetes 中要害的组件之一，它负责管理和运行容器，提供容器的隔离性、生命周期治理、网络和存储性能，与其余 Kubernetes 组件协同工作，实现容器化应用程序的高效运行和治理。
node、kubelet、pod 和 container 之间的分割
Node：是 K8S 集群中的工作节点，也被称为主机或者服务器，每个 Node 提供容器运行的基础设施，并承载运行着的容器
Kubelet：是运行在每个 Node 上的 K8S 组件之一，是 Node 上的代理程序，Kubelet 负责管理和运行 Node 上的容器，并与 K8S 管制立体交互
Pod:Pod 是 K8S 的最小调度和部署单元，它是一个逻辑上相干的容器组，能够蕴含一个或者多个容器，Pod 提供了一个形象层，为容器提供共享的网络和存储资源，使容器之间能够进行通信和共享数据，Pod 是在 Node 上进行调度和运行的
Container：容器是在 Pod 中运行的理论应用程序或服务，一个 Pod 能够蕴含一个或者多个容器，这些容器共享同一个网络命名空间和存储卷，容器被 kubelet 创立、启动、进行和销毁
通过这种形式，kubelet 作为 Node 上的代理程序，负责与 Kubernetes 管制立体交互，并协调治理 Node 上的容器。Pod 是在 Node 上调度和运行的最小单元，它能够蕴含一个或多个容器，这些容器共享同一个网络和存储环境。这种关系使得 kubernetes 能够以分布式和高可用的形式运行和治理容器化应用程序。
