目录
引言
在云计算的浪潮中，Kubernetes（简称K8s）作为容器编排的领航者，已经成为现代基础设施的核心组成部分。本文旨在深入浅出地介绍Kubernetes的基本概念、核心组件、关键特性及其如何重塑了云原生应用的部署与管理方式。
一、部署方式回溯
（一）传统部署时代
早期，各个组织是在物理服务器上运行应用程序。 由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。 例如，如果在同一台物理服务器上运行多个应用程序， 则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。 一种解决方案是将每个应用程序都运行在不同的物理服务器上， 但是当某个应用程序资源利用率不高时，剩余资源无法被分配给其他应用程序， 而且维护许多物理服务器的成本很高。
（二）虚拟化部署时代
因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。 虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性， 因为一个应用程序的信息不能被另一应用程序随意访问。
虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序， 而因此可以具有更高的可扩缩性，以及降低硬件成本等等的好处。 通过虚拟化，你可以将一组物理资源呈现为可丢弃的虚拟机集群。
每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。
（三）容器部署时代
容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。 因此，容器比起 VM 被认为是更轻量级的。且与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。
容器因具有许多优势而变得流行起来，例如：
- 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
- 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性）， 提供可靠且频繁的容器镜像构建和部署。
- 关注开发与运维的分离：在构建、发布时创建应用程序容器镜像，而不是在部署时， 从而将应用程序与基础架构分离。
- 可观察性：不仅可以显示 OS 级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
- 跨开发、测试和生产的环境一致性：在笔记本计算机上也可以和在云中运行一样的应用程序。
- 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
- 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
- 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
- 资源隔离：可预测的应用程序性能。
- 资源利用：高效率和高密度
二、Kubernetes基本介绍
Kubernetes (简称K8s) 是一个开源的容器编排平台，用于自动化容器化应用程序的部署、扩展和管理。它源自Google内部的Borg系统，并在2014年首次开源。Kubernetes已经成为云原生计算基金会(CNCF)的旗舰项目，极大地推动了云原生技术的发展。
Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。K8s 这个缩写是因为 K 和 s 之间有 8 个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。
（一）为什么使用k8s
容器是打包和运行应用程序的好方式。在生产环境中， 你需要管理运行着应用程序的容器，并确保服务不会下线。 例如，如果一个容器发生故障，则你需要启动另一个容器。 如果此行为交由给系统处理，是不是会更容易一些？
这就是 Kubernetes 要来做的事情！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移你的应用、提供部署模式等。 例如，Kubernetes 可以轻松管理系统的 Canary (金丝雀) 部署
（二）主要功能
K8S是Google开源的容器集群管理系统，在Docker等容器技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
1.使用 Docker 等容器技术对应用程序包装（package）、实例化（instantiate）、运行（run）
2.以集群的方式运行、管理跨机器的容器。
3.解决 Docker 跨机器容器之间的通讯问题。
4.K8S 的自我修复机制使得容器集群总是运行在用户期望的状态，比如期望有两台nginx服务器提供服务，当有一台宕机之后，会自动生成新的nginx服务去提供服务，且始终保持在两台
（三）核心概念
1.Pod
Kubernetes的基本执行单元，Pod是一个或多个紧密相关的容器的集合，它们共享存储、网络、以及进程命名空间，并且可以作为一个整体被调度到集群中的一个节点上运行
以下是关于Pod的一些重要概念
容器组：Pod可以包含多个容器，这些容器通常紧密相关，并且需要一起运行。例如，一个Web应用可能包含一个前端容器和一个后端容器。
共享资源：Pod中的所有容器共享同一个网络命名空间，因此它们可以直接使用localhost来通信。同时，它们也可以共享存储卷（Volumes），允许容器之间共享文件和目录。
生命周期：Pod有一个生命周期，当Pod中的容器全部退出时，Pod就会终止。同时，Kubernetes提供了许多机制来管理Pod的生命周期，如重启策略（Restart Policy）、健康检查（Liveness and Readiness Probes）等。
部署和扩展：通常，你不会直接部署和管理Pod，而是使用更高级别的资源对象（如Deployment、ReplicaSet、StatefulSet等）来定义Pod的期望状态，并由Kubernetes系统自动创建和管理Pod。这些高级资源对象提供了滚动更新、扩展、回滚等更强大的功能。
持久化存储：Pod中的容器可能会因为各种原因（如重启、升级等）而终止，但存储卷中的数据会保留下来。因此，你可以使用持久化存储卷（如EmptyDir、HostPath、PersistentVolume等）来保存Pod中的数据。
服务发现：在Kubernetes集群中，Pod可以通过Service资源进行服务发现。Service为Pod提供了一个稳定的访问地址（Cluster IP），并且支持负载均衡和故障转移。
配置管理：Kubernetes支持使用ConfigMap和Secret来管理Pod的配置信息，这些配置信息可以以文件或环境变量的形式注入到Pod中的容器中
2.pod控制器
Pod控制器，又称为工作负载（workload），是用于实现管理Pod的中间层，其主要目的是确保Pod资源符合预期的状态。当Pod资源出现故障时，Pod控制器会尝试进行重启，如果重启策略无效，则会重新创建新的Pod。
Deployment：它是建立在ReplicaSet之上的控制器，用于管理无状态应用，同时管理和控制Pod与ReplicaSet。它支持滚动更新和回滚功能，并提供声明式配置。
ReplicaSet：它会代用户创建指定数量的Pod副本，并确保Pod副本数量符合预期状态。同时，它还支持滚动式自动扩容和缩容功能
DaemonSet：它用于确保集群中的每一个节点只运行特定的Pod副本，通常用于实现系统级后台任务
Statefulset：用于管理有状态应用。与Deployment和ReplicaSet不同，StatefulSet为每个Pod分配一个唯一的标识符，并维持Pod之间的顺序。它还提供了稳定的网络标识、存储卷持久化和有序部署、扩展和缩容等功能。StatefulSet通常用于需要持久化存储和有序部署的应用，如数据库集群
Job：Job控制器用于运行一次性任务，它会创建Pod来执行特定的任务，并在任务完成后删除Pod。Job可以并行运行多个Pod以加快任务的执行速度，并且提供了重试策略来处理可能的失败
Cronjob：基于时间的Job，它允许你指定任务按照预定的时间计划运行。CronJob使用Cron表达式来定义任务的执行时间，并在指定的时间创建Job来执行相应的任务
3.Label
在Kubernetes中，Label（标签）是一个非常重要的概念。Label不是Kubernetes中的一种资源对象，而是用于附加到各种资源对象上的键/值对，这些资源对象可以是Node、Pod、Service等。通过给指定的资源对象捆绑一个或多个不同的Label，可以实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作
Label的使用场景包括但不限于
资源选择：通过Label Selector（标签选择器），可以查询和筛选拥有某些Label的资源对象。例如，可以选择所有具有特定版本标签的Pod进行升级操作。
标签选择器目前有两种：基于等值关系（等于、不等于）和基于集合关系（属于、不属于、存在）
服务发现：在Service对象中，可以通过Label Selector指定要代理的Pod子集。这样，Service就能够将流量路由到具有特定Label的Pod上。
资源分组：可以通过给资源对象添加多个Label来实现资源分组。例如，可以根据环境和角色给Pod添加Label，以便将它们分组到不同的环境中或执行不同的角色。
4.Services
在Kubernetes中，Service是一个核心概念，用于为一组提供服务的Pod抽象一个稳定的网络访问地址。通过创建Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并将请求以负载均衡的方式分发到后端的各个容器应用上定义了一种访问Pods的方式，提供了一个稳定的抽象层，让Pods的发现、负载均衡变得简单，不论Pods如何变化（例如因故障重启或扩展）。
Service的主要作用包括:
提供服务的稳定入口：Service为前端的应用程序或ingress提供了稳定的服务入口，这个入口拥有一个全局唯一的虚拟IP地址（Cluster IP），前端的应用可以通过这个IP地址访问后端的Pod集群。
实现负载均衡：Service内部实现了负载均衡机制，它会将所有进入的请求均匀地分配给后端的Pod副本，确保每个请求都能得到正确的响应。
实现故障隔离：当某个Pod发生故障时，Service会自动将该Pod从服务池中剔除，保证请求不会被故障的Pod处理，从而实现了故障隔离。
实现服务发现：Service允许前端的应用程序通过Label Selector来找到提供特定服务的Pod，从而实现了服务的自动发现。
实现 service 这一功能的关键，就是 kube-proxy。kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化， 可通过以下三种流量调度模式： userspace（废弃）、iptables（濒临废弃）、ipvs（推荐，性能最好）来实现网络的转发
5.Ingress
在网络技术和Kubernetes中，Ingress是基于域名的网络转发资源，用于管理集群中服务的外部访问。Ingress提供负载均衡、SSL和基于名称的虚拟托管等功能。Ingress的配置可以通过Ingress控制器来实现，定义路由规则、负载均衡策略和SSL证书等。Ingress常用于暴露Kubernetes集群中的服务给外部访问，通过域名的方式访问Kubernetes内部应用。Ingress在Kubernetes中主要提供HTTP层（7层）路由功能，相比TCP（4层）的负载均衡具有更多的优势，如路由规则更加灵活、支持金丝雀、蓝绿、A/B Test发布模式、SSL支持、日志、监控和自定义扩展等
6.Name
在Kubernetes的核心概念中，Name 是用于标识和引用Kubernetes对象的重要属性。在Kubernetes REST API中，每个对象（如Pod、ReplicaSet、Deployment等）都必须具有一个唯一的Name。这个Name在同一命名空间（Namespace）下的同种类型对象中必须是唯一的。
例如，如果你通过REST API访问一个Pod，其URL可能会类似于 /api/v1/pods/some-name，其中 some-name 就是该Pod的Name。
此外，除了Name，Kubernetes还会为每个对象分配一个全局唯一的UID（用户标识符）。这个UID是在对象创建时由Kubernetes系统自动生成的，并且在整个Kubernetes集群的生命周期中都是唯一的。
7.Namespaces
在Kubernetes中，Namespace（命名空间）是一个核心概念，它提供了一种将集群资源划分为多个独立的、逻辑上隔离的区域的机制。Namespace的主要作用包括：
资源隔离：Namespace为不同的团队、项目或服务提供了逻辑隔离。每个Namespace中的资源（如Pods、Services等）仅在同一Namespace内可见，这样可以避免不同团队或项目间的资源命名冲突。
权限控制：通过与RBAC（基于角色的访问控制）结合使用，可以对不同Namespace中的用户或团队授予不同的权限，实现精细的访问控制。
资源配额管理：可以为每个Namespace设置资源配额（ResourceQuota），限制该Namespace下资源的使用量，有效管理集群资源。
多租户支持：通过为每个租户分配一个独立的Namespace，Kubernetes可以支持多租户部署。每个租户只能在自己的Namespace内创建和管理资源，无法访问其他Namespace的资源。
简化资源管理：对于大型系统或多租户环境，Namespace有助于简化资源管理和部署过程。
（四）k8s特性
自动化容器部署和编排
K8s 可以自动部署、扩展和管理容器化应用程序。它允许你定义应用程序的期望状态，并自动确保集群中的实际状态与期望状态相匹配。
服务发现和负载均衡
K8s 通过 Service 资源提供服务发现和负载均衡功能。Service 可以为 Pod 提供一个稳定的访问入口，并将流量分发到多个 Pod 上，从而实现高可用性和可扩展性。
存储卷管理
K8s 支持多种存储卷类型（如空目录、宿主机目录、网络存储等），可以为 Pod 提供持久化存储。通过持久卷（PersistentVolumes）和持久卷声明（PersistentVolumeClaims），可以方便地对存储进行管理。
集中化配置管理和密钥管理
管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用
自动扩展和缩容
K8s 支持根据应用程序的需求自动扩展或缩容 Pod 的数量。通过 Horizontal Pod Autoscaler（HPA）资源，可以基于 CPU 或自定义指标自动调整 Pod 的副本数。
滚动更新和回滚
K8s 支持滚动更新，即在不中断服务的情况下逐步替换旧的 Pod 版本。如果更新过程中出现问题，可以方便地回滚到之前的版本。
自我修复和容错
K8s 具有强大的自我修复和容错能力。它可以监控集群中节点和 Pod 的健康状态，并在出现问题时自动进行故障转移和恢复操作。例如，当某个节点故障时，K8s 会自动将运行在该节点上的 Pod 调度到其他健康的节点上。
安全和管理
K8s 提供了多种安全和管理功能，如基于角色的访问控制（RBAC）、网络策略、Secret 管理等。这些功能可以帮助你保护集群中的数据和应用程序免受未经授权的访问和攻击。
网络和服务网格
K8s 支持多种网络插件和服务网格解决方案，如 Calico、Flannel、Istio 等。这些解决方案可以帮助你构建复杂的网络拓扑和微服务架构，并提供更高级别的流量管理和安全性。
可移植性和标准化
K8s 遵循标准的容器化应用程序打包和部署规范（如 Docker），使得应用程序可以在不同的环境和集群之间轻松移植。同时，K8s 的 API 和资源定义也遵循标准化的规范，使得不同的工具和平台可以与 K8s 集成。
扩展性和定制性
K8s 是一个可扩展和可定制的平台。你可以通过编写自定义的控制器、调度器、网络插件等来扩展 K8s 的功能。此外，K8s 还支持多种扩展资源（如 GPU、FPGA 等），以满足不同应用程序的需求。
任务批处理运行
提供一次性任务，定时任务；满足批量数据处理和分析的场景。
三、Kubernetes集群架构与组件
（一）Kubernetes集群架构
K8S 是属于主从设备模型（Master-Slave 架构），即有 Master 节点负责集群的调度、管理和运维，Slave 节点是集群中的运算工作负载节点。
在 K8S 中，主节点一般被称为 Master 节点，而从节点则被称为 Worker Node 节点，每个 Node 都会被 Master 分配一些工作负载。
Master 组件可以在群集中的任何计算机上运行，但建议 Master 节点占据一个独立的服务器。因为 Master 是整个集群的大脑，如果 Master 所在节点宕机或不可用，那么所有的控制命令都将失效。除了 Master，在 K8S 集群中的其他机器被称为 Worker Node 节点，当某个 Node 宕机时，其上的工作负载会被 Master 自动转移到其他节点上去。
（二）Kubernetes组件
1.Master组件
1.1 Kube-apiserver组件
Kube-apiserver，用于暴露 Kubernetes API，任何资源请求或调用操作都是通过 kube-apiserver 提供的接口进行。以 HTTP Restful API 提供接口服务，所有对象资源的增删改查和监听操作都交给 API Server 处理后再提交给 Etcd 存储。它也是各个组件间通信的中心枢纽。
1.2 Kube-Controller Manager组件
Kube-Controller Manager，运行控制器，监控整个集群的状态，它通过运行多个控制器来确保集群中的资源处于期望的状态，并自动修复任何不符合期望的状态变化
Node Controller（节点控制器）
负责在节点出现故障时发现和响应。
Replication Controller（副本控制器）
负责保证集群中一个 RC（资源对象 Replication Controller）所关联的 Pod 副本数始终保持预设值。可以理解成确保集群中有且仅有 N 个 Pod 实例，N 是 RC 中定义的 Pod 副本数量。
Endpoints Controller（端点控制器）
填充端点对象（即连接 Services 和 Pods），负责监听 Service 和对应的 Pod 副本的变化。 可以理解端点是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道它的 endpoint。例如一个服务器宕机之后，k8s会拉取一个新的服务器，来满足期望值要求，但是新的服务器地址可能会发生变化，Services会通过内定的标签去监听Pods的IP地址，达到访问的效果
Service Account & Token Controllers（服务帐户和令牌控制器）
为新的命名空间创建默认帐户和 API 访问令牌。当用户来访问K8s服务的时候，需要通过令牌认证来决定用户是否可以访问，并且决定用户访问的权限。
ResourceQuota Controller（资源配额控制器）
确保指定的资源对象在任何时候都不会超量占用系统物理资源。例如对CPU、内存等资源进行限制
Namespace Controller（命名空间控制器）
管理 namespace 的生命周期。
Service Controller（服务控制器）
属于 K8S 集群与外部的云平台之间的一个接口控制器。用于创建、更新和删除云提供商负载均衡器
Job Controller（任务控制器）
监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成
1.3 Kube-Scheduler组件
kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。 调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限
负责分配Pods到合适的Node上运行。
是负责资源调度的进程，根据调度算法为新创建的 Pod 选择一个合适的 Node 节点。
可以理解成 K8S 所有 Node 节点的调度器。当用户要部署服务时，Scheduler 会根据调度算法选择最合适的 Node 节点来部署 Pod。
预选策略（predicate）
优选策略（priorities）
API Server 接收到请求创建一批 Pod ，API Server 会让 Controller-manager 按照所预设的模板去创建 Pod，Controller-manager 会通过 API Server 去找 Scheduler 为新创建的 Pod 选择最适合的 Node 节点。比如运行这个 Pod 需要 2C4G 的资源，Scheduler 会通过预选策略过滤掉不满足策略的 Node 节点。Node 节点中还剩多少资源是通过汇报给 API Server 存储在 etcd 里，API Server 会调用一个方法找到 etcd 里所有 Node 节点的剩余资源，再对比 Pod 所需要的资源，如果某个 Node 节点的资源不足或者不满足 预选策略的条件则无法通过预选。预选阶段筛选出的节点，在优选阶段会根据优先策略为通过预选的 Node 节点进行打分排名， 选择得分最高的 Node。例如，资源越富裕、负载越小的 Node 可能具有越高的排名。
1.4 etcd
分布式键值存储，保存集群的配置信息。K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据
2.Node组件
2.1 kubelet组件
运行在每个Node上，负责管理Pods、容器以及与Master通信。它会定时向 API Server 汇报自己 Node 节点上运行的服务的状态，并接受来自 Master 节点的指示采取调整措施
kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。 kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。
2.2 Container Runtime组件
负责容器的生命周期管理，常见的有Docker、containerd、CRI-O等。
2.3 kube-proxy组件
kube-proxy 是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。 kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。 如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。
在 K8S 集群中微服务的负载均衡是由 Kube-proxy 实现的。Kube-proxy 是 K8S 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都会运行一个 Kube-proxy 组件
2.4 docker组件
容器引擎，运行容器，负责本机的容器创建和管理工作。
（三）Kubernetes架构数据流向
1.首先Kubectl通过Auth认证，访问到Master节点的APIserver。
2.APIserver会先将访问数据发送给ETCD存储，相当于将Kubectl发送的请求，例如创建服务的指令形成一个类似与模板的数据，进行存储
3.ETCD会将请求重新发送给APIserver
4.APIserver会先调用controller-manager组件去执行ETCD模板请求，类似与生成一条指令，但是它没有执行的目标
5.controller-manager组件并不能直接在Node节点上创建服务，它会将类似于执行命令的数据发送给APIserver
6.APIserver再将该数据发送到ETCD，ETCD会记录操作请求，而后会将指令需求发送给scheduler组件
7.scheduler组件会kubelet监控，并发送给APIserver的节点信息，而后根据预选、优选策略去选择合适的节点去执行指令，但是它也无法直接将指令发送给kubelet，而是将指令发送给APIserver
8.APIserver将指令发送给kubelet
9.kubelet会在每一个node节点上执行，它将APIserver发送的指令在其所在的node节点上执行，同时它还会负责监控所在节点的Pod实例状态，管理所有Pod实例的生命周期。在执行完指令后，会将执行记录返回给APIserver，APIserver会将记录存储在ETCD当中。并负责与master进行通信。
10.此时用户访问服务，会通过kube-proxy来访问pod实例
注释：
①所有的执行操作与访问数据，都会记录到ETCD当中
②master组件之间并不会互相进行通信与调用，所有的操作都会通过APIserver进行调用执行
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
