一. Kubernetes基础原理相关-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_29799655/article/details/126529310

一. Kubernetes 基础相关

1. 为什么使用Kubernetes

首先k8s内部是以docker容器为基础实现的,如果问为什么使用k8s,这要从传统物理机部署开始说起
传统部署模式下,直接将应用部署在物理服务器上,一个是比较繁琐,二是不能方便的动态为应用程序定义资源边界,存在资源分配问题

例如: 在物理服务器上运行多个应用程序，可能会出现一个应用程序占用大部分资源的情况，造成他应用程序的性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展，并且维护许多物理服务器的成本很高
持续集成持续交付问题: 在开发中我们会频繁的修改代码,合并到公共分支进行测试,可能会出现多个更新不兼容问题,版本不统一问题

进而引出虚拟化部署模式也就是虚拟机部署: 虚拟化技术允许在单个物理服务器的 CPU 上运行多个虚拟机(VM),多个应用程序在 VM 之间实现隔离，并提供一定程度的安全,可以更好地利用物理服务器上的资源,实现更好的可伸缩性,降低硬件成本等等。缺点：每个VM可以看成一台完整的计算机,但是虚拟层冗余会导致的资源浪费与性能下降
进而又引出了容器部署模式比如dokcer: 容器类似于VM，但可以在应用程序之间共享操作系统(OS)资源,每个容器都具有自己的文件系统、CPU、内存、进程空间等,由于它们与基础架构分离,因此可以跨云和 OS 发行版本进行移植。

具体参考【Docker隔离原理- namespace 6项隔离（资源隔离）与 cgroups 8项资源限制（资源限制）】

Docker的组成: Docker 包含三个基本概念，分别是镜像Image、容器Container和仓库Repository。镜像是Docker运行容器的前提，仓库是存放镜像的场所，可见镜像更是Docker的核心

Docker镜像可以理解为一个用来运行容器的只读模板,内部包含了创建和运行容器需的所有文件和配置,可以简单把镜像理解为一个操作系统的安装盘,它可以在任何支持Docker的平台上启动一个容器,就像在任何支持光驱的电脑上安装一个操作系统一样。

容器优势：

轻量级和高效：Docker容器在物理机上共享操作系统内核，因此它们非常轻量级且占用的资源较少。相比于传统虚拟化技术，Docker容器启动更快、占用更少的内存和存储空间。
可移植性：Docker容器可以在不同的环境中运行，无论是在开发者的本地机器上还是在云中的主机上。容器提供了一个独立于底层操作系统和硬件平台的可移植的运行环境，使得应用程序可以轻松地在不同的环境中部署和运行。
快速部署和扩展：使用Docker容器，可以快速部署应用程序和服务，只需构建一个容器镜像并在各种环境中运行。容器的快速启动时间和隔离性使得应用程序可以更容易地横向扩展，即增加容器的数量以处理更高的负载。
环境一致性：Docker容器通过将应用程序及其依赖项打包到一个容器中，确保了环境的一致性。这意味着无论在任何地方运行该容器，应用程序都会在相同的环境下工作，避免了由于环境差异导致的兼容性问题。
简化开发和测试：使用Docker容器，开发者可以轻松地创建多个相互隔离的容器来进行应用程序的开发和测试。容器提供了一个干净且一致的环境，使得开发团队可以更方便地进行应用程序的调试、测试和迭代开发。
资源隔离和安全性：Docker容器提供了强大的隔离机制，使得每个容器都能够运行在独立的用户空间中，避免了应用程序之间的冲突和相互影响。这种隔离性提高了安全性，并使得在同一物理主机上运行多个容器时更加可靠和稳定。

容器化部署后,出现的问题一些问题,或者怎么提供一些附加功能:

如何实现弹性的容器化应用管理
如何实现容器的障转移能力
如何实现容器高性能的负载均衡访问机制
便捷的扩展
自动化的资源监测…

进而引出了Kubernetes(实际解决这些问题还可以使用docker的swarm, apache的mesos),总结为什么用Kubernetes : 容器是打包和运行应用程序的方式,在生产环境中还需要管理运行应用程序的容器,并确保不会停机。例如如果一个容器发生故障,需要启动另一个容器, Kubernetes提供了一个可弹性运行分布式系统的框架。Kubernetes 可以看为linux之上的一个服务编排或容器编排框架,可以监控管理容器,实现扩展要求比如:部署,观测,监控,故障转移等, 并且在使用docker时容器是最小单位,一个容器只能运行一个应用,k8s中pod是最小单位,一个pod中运行多个容器,一个pod就可以看为一个完整的服务
官网

2. Kubernetes 集群架构

在安装使用Kubernetes前,先了解一下它的集群架构模式
常见的集群架构:

主从架构: 主从中又以下模式

主从同步/复制模式: 主节点与从节点保存数据一致例如mysql主从同步
主管理从模式: 通过主节点管理从节点

分片: 抛弃主从的角色,每个节点都可以堆外提供服务,每个节点中存储的数据都不一样,是其中的一部分,通常用于管理数据相关的框架上例如redis

Kubernetes 采用的主管理从模式 master-node架构
在宏观上看Kubernetes中有两种节点角色,master节点与work节点

其中一个Kubernetes集群中可以存在多个master,用来管理worker节点
除了master，kubernetes集群中的其他机器被称为Node节点，在较早的版本中也被称为minion,与master一样，Node可以是物理机也可以是虚拟机，Node节点才是kubernetes集群中的工作负载节点，每个Node节点都会被master分配一些工作负载(docker容器)运行项目服务,所以又被称为worker节点
master节点通过aip通信方式与worker节点进行交互,操作woker节点
程序员也可以在可视化ul,或CLI也是通过API通信的方式操作master–>操作woker节点

3. Kubernetes内部组成详解

Kubernetes 采用的主管理从模式模式中,master又被称为ControlPlane控制面板,通过master节点来控制整个Kubernetes集群,master中包含的核心组件有:

ControllerManager: 控制管理器
etcd: 键值数据库(有点像redis)
scheduler: 调度器
apiServer: api网关服务器

用来运行实际项目服务的每个node节点包含的核心组件:

kubelet: 每一个node节点必须安装,可以理解为一个监工,负责通过apiServer与master交互,获取指令并执行,以及当前node节点上应用的启停,状态上报等等
kube-proxy: 网络代理器
docker: 容器运行时环境
pod: 一个节点中可能存在多个

首先在使用docker时,执行run命令启动一个container容器,容器是docker的基本单位,一个应用是一个容器
执行kubelet run命令启动一个应用时, 这个启动应用就称为pod,是k8s的基本单位
两个对比起来看pod与一个应用容器是相同级别的都代表启动的一个应用,但是pod可以看为是一个容器的再封装
往往一个docker容器代表不了一个基本应用,例如一个服务项目中间包含java后端与mysql数据库服务,而一个dockerCompose基本容器只能部署其中一个,所以使用pod封装多个docker容器,此时一个pod中就可以存储一个基本应用

fluentd: 可以理解为当前节点运行的日志信息收集系统,不是k8s默认自带的,不太重要

注意master节点中也要安装kubelet与kube-proxy,其中kubelet在master中一般主要负责监控master节点的状态,启停等等
另外Kubernetes接收请求后都是基于List-Watch机制和scheducer调度器配合触发执行的接下来讲一下List-Watch机制和scheducer调度器

Kubernetes List-Watch 的机制

什么是List-Watch:

List-watch 是 K8S 统一的异步消息处理机制，保证了消息的实时性，可靠性，顺序性，性能等等,可以分List和Watch两部分理解
List: 指通过调用apiServer提供的List API，获取集群中某种资源对象,如Pod、Service、Deployment等
Watch: 指通过调用apiServer提供的Watch相关API,基于HTTP长连接实现监听集群中指定资源的变化事件,如创建、更新、删除等,获取事件的类型和内容触发后续操作
List-Watch机制可以实现对K8s集群中资源对象的监控和响应，让客户端,如kubelet、scheduler、controllerManager等可以及时地获取资源对象的最新状态,并根据事件类型执行相应的操作。例如当有新的Pod对象创建时,scheduler可以监听到创建事件,并为该Pod对象选择合适的Node节点进行调度

我认为K8s中有三个List-Watch,分别是运行在Master节点上的controllerManager控制器,Scheduler调度器,和运行在工作节点上的kubelet监工三个位置,它们在进程启动时就会监听apiServer发出来的事件,并根据事件类型执行相应的操作,也就是 List-Watch 的机制,进行每个组件的协作，保持数据同步的，每个组件之间的设计实现了解耦。

用户是通过ui页面或kubectl根据配置文件,向APIServer发送命令,比如建立 Pod 和 Container。
apiServer经过API调用,经过权限控制,请求解析,资源控制去处理这个请求,实际上还没有真正开始部署应用,需要 controllerManager、scheduler和 kubelet 的协助才能完成整个部署过程。
所有部署的信息都会通过apiServer写到 etcd,在写入成功后apiServer会将事件给其他组件或者被其它组件监听到,也就是 apiServer会通过监听etcd发过来的事件,其他组件也会监听apiServer发出来的事件,例如controllerManager、scheduler和 kubelet执行相应的处理,下方有Kubernetes执行概述

scheducer调度器详解

在上面我们了解到Kubernetes的master节点上存在一个scheducer调度器组件,假设发送一个安装启动应用指令,通过apiServer被controllerManager接收并解析,将解析后的指令保存到etcd,此时需要确认当前要在Kubernetes的哪个工作节点上安装启动这个应用,这里就是通过scheducer调度器选择出来的指定工作节点
scheduler是kubernetes的调度器,是作为单独的程序运行的，启动后会一直监听apiServer,获取spec.nodeName为空的pod,对每个pod都会创建一个binding，表明该pod应该放到哪个节点上, 主要的任务是决定把定义的 pod分配到集群的哪个节点上, 在选择节点时会进行如下角度的考虑：

公平：如何保证每个节点都能被分配资源
资源高效利用：集群所有资源最大化被使用
效率：调度的性能要好，能够尽快地对大批量的pod完成调度工作
灵活：允许用户根据自己的需求控制调度的逻辑

调度分为如下三个部分：

首先是过滤掉不满足条件的节点，这个过程称为预算策略（predicate）；
然后对通过的节点按照优先级排序，这个是优选策略（priorities）；
最后从中选择优先级最高的节点。如果中间任何一步骤有错误，就直接返回错误。

Predicate预算策略, 有一系列的常见的算法可以使用：

PodFitsResources：节点上剩余的资源是否大于 pod 请求的资源。
PodFitsHost：如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配。
PodFitsHostPorts：节点上已经使用的 port 是否和 pod 申请的 port 冲突。
PodSelectorMatches：过滤掉和 pod 指定的 label 不匹配的节点。
NoDiskConflict：已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读。

如果在 predicate 预算策略过程中没有合适的节点，pod 会一直在 pending状态，不断重试调度，直到有节点满足条件。经过这个步骤，如果有多个节点满足条件，就继续 priorities 过程：按照优先级大小对节点排序。
优选策略, 优先级由一系列键值对组成，键是该优先级项的名称，值是它的权重(该项的重要性)有一系列的常见的优先级选项包括：

LeastRequestedPriority：通过计算CPU和Memory的使用率来决定权重，使用率越低权重越高。也就是说，这个优先级指标倾向于资源使用比例更低的节点。
BalancedResourceAllocation：节点上CPU和Memory使用率越接近，权重越高。这个一般和上面的一起使用，不单独使用。比如node01的CPU和Memory使用率20:60，node02的CPU和Memory使用率50:50，虽然node01的总使用率比node02低，但node02的CPU和Memory使用率更接近，从而调度时会优选node02。
ImageLocalityPriority：倾向于已经有要使用镜像的节点，镜像总大小值越大，权重越高。

通过算法对所有的优先级项目和权重进行计算，得出最终的结果

结合List-Watch 与 scheducer 概述 Kubernetes 执行过程

在使用Kubernetes时,通常我们采用主管理从模式,整个集群中分为master管理节点,和用来进行实际工作的worker节点,然后把上面说的相关组件概述一下

master节点中主要存在: controllerManager: 控制管理器, etcd: 键值数据库(有点像redis),scheduler: 调度器,apiServer: api网关服务器
工作节点中主要存在: kubelet监工, kube-proxy网络代理器, docker容器运行环境,服务pod等等
另外还有List-Watch和scheducer调度器,通过List-Watch监听命令事件,通过scheducer调度选择,通过kubelet监工实现最终命令的执行

详细过程(实际可以简单理解为通过apiServer接收请求,然后通过不同组件对解析的请求命令进行一步一步的清洗,设置,增加附加信息,最终kubelet监工获取到命令进行实际执行)

在操作Kubernetes时,所有指令都会到达master节点的apiServer网关服务器,apiServer网关服务器是master的唯一入口
apiServer接收到请求后,负责验证,授权,记录,转发等工作,会将解析到的请求信息写到 etcd 中保存,实际上还没有真正开始部署应用,会通过List-Watch机制通知controllerManager,然后通过scheduler和 kubelet 的协助才能完成整个部署
实际上整个请求在内部执行都是通过List-Watch机制触发执行的, 至少有三个watch监听,分别是 controllerManager(运行在 Master), scheduler(运行在 Master), kubelet(运行在 Node) 在它们进程启动时就会监听APIServer 发出来的事件
比如用户通过 kubectl 或其他 API 客户端提交请求给 APIServer 来建立一个 Pod 对象副本。
APIServer 尝试着将 Pod 对象的相关元信息解析存入 etcd 中，待写入操作执行完成，APIServer 即会返回确认信息至客户端。
当 etcd 接受创建 Pod 信息以后，会发送一个 Create 事件给 APIServer。
controllerManager一直在监听(Watch，通过http的8080端口)APIServer 中的事件。此时 APIServer 接受到了 Create 事件，又会发送给 controllerManager。
controllerManager在接到 Create 事件以后，调用其中的 ReplicationController 来保证 Node 上面需要创建的副本数量。一旦副本数量少于 RC 中定义的数量，RC 会自动创建副本。总之它是保证副本数量的 Controller（PS：扩容缩容的担当）
在controllerManager创建 Pod 副本以后,APIServer会在etcd中记录这个 Pod 的详细信息。例如 Pod 的副本数，Container 的内容等
同样的 etcd 会将创建 Pod 的信息通过事件发送给 APIServer。
由于scheduler也在监听APIServer，获取到创建Pod事件,进行调度安排选择指定Node,换句话说，scheduler的作用是将待调度的 Pod 按照调度算法和策略绑定到集群中指定Node上。
scheduler调度完毕以后会更新部署Pod的命令信息,此时除了知道 Pod 的副本数量，副本内容。还知道部署到哪个 Node 上面了,将这些信息更新至 APIServer，由 APIServer 更新至 etcd 中，保存起来。
etcd 保存成功后再次将事件发送给 APIServer
kubelet 运行在node工作节点上,也是通过 List-Watch 的方式监听（Watch，通过https的6443端口）APIServer 发送的 Pod 更新的事件。
如果监听到apiServer更新pod指令属于当前keubelet所在节点的,kubelet 会尝试在当前节点上调用 Docker 启动容器，实现真正的部署,并将部署结果已经Pod 状态回送至 APIServer
kubelet 后续一直监听, 负责通过apiServer与master交互,获取指令并执行,以及当前node节点上应用的启停,状态上报等等
上面node节点上通过kubelet运行了一个应用,会对该应用分配ip地址,
当不同node节点上运行的应用相互调用时,通过kube-proxy网络代理进行请求转发,kube-proxy可以获取到集群中所有节点服务的地址
以上node与master之间的相互通信都是通过apiServer完成的,大项目集群情况下apiServer压力实际是挺大的

流程示例图

下图中0表示启动Kubernetes服务器时自动启动的
第一步: 程序员通过kubectl或ui操作Kubernetes,发送请求,请求由apiServer流转到master的其它组件上
第二步: apiServer接收请求后将请求操作存储到etcd
第三步: etcd上报存储的请求
第四步: controllerManager通过watch监听到etcd上报的请求,解析为执行指令
第五步:

4. Kubernetes 提供了哪些功能

注意点: Kubernetes不会构建应用,实际也不会部署 ,如果需要集成部署,需配合持续集成,交付部署的相关框架例如jenkins, docker
k8s中将所有的操作资源看为对象,可以通过命令,或者网页,或者yaml创建,操作资源对象,资源对象大概分一下几类,通过这些资源对象实现了一些功能,下面开始一一介绍
Pod:k8s中最小的部署运行单元,在使用docker时,执行"docker run"命令启动一个container容器,使用k8s后执行"kubelet run"命令启动一个应用,这里启动的就是pod,一个pod中可以运行一个或多个容器

直接创建的pod,如果内部容器出现宕机异常,通过指针提供了恢复功能, 但是这个pod如果宕机异常不会有恢复功能,通过工作负载由他们来创建Pod,实现pod的异常恢复功能
在pod运行容器时,底层除了运行这个实际应用容器以外,还会多运行一个paush容器来实现网络共享,虽然可以通过podIP属性指定该pod的访问ip,但是集群网络是私有的,该地址只能在集群内部访问,如果想允许外部访问需要创建Service来公开Pod的网络终结点

Service负载均衡服务,提供了: 暴露访问,服务发现,负载均衡的能力

在使用docker时可以通过"docker run -p" 命令,其中-p就把访问地址暴露给外网,在k8s中pod网络默认是私有的,如果让外部访问
在分布式服务中,一个服务通常情况下会存在多个服务部,上层是怎么通过service进行负载均衡选择到指定pod副本的
Service实际可以看为选中一组pod,设置这组pod对外暴露允许外部访问的,有多种暴露方式:ClusterIP以集群ip方式暴露, NodePort以节点端口方式暴露, LoadBalancer借助cloudProvider创建一个外部的负载均衡器,负载均衡器负载调用,ExternalName将服务通过DNS CNAME记录方式转发到指定的域名,通过service代理外部域名
基于不同的暴露方式,实现了负载均衡功能

在微服务环境中每个服务节点运行在不同的pod上,通过封装Service选中一组pod,对外暴露允许外部负载均衡访问,怎么选择的,这里就来到了标签与选择器

在k8s资源中,可以通过"labels"属性给资源打上标签,例如相同类型的的资源设置相同的labels属性
在后续就可以通过"selector"选择器选中指定资源,例如selector就可以选中指定pod封装到同一个service中

封装Service后,由Service代理一组Pod,选择指定pod调用,底层服务发现,负载均衡是怎么实现的,这里就来到了EndPoint

Endpoints用来关联Service与后端Pod,每当Pod的副本数量发生变化时，Endpoints会自动更新并反映这些变化,保证Service总是正确地指向可用的Pod
底层是通过endpointController自动监听实现的,在封装service时配置selector选择器选中指定pod,endpointController会根据选择器选中的服务自动创建对应的endpoint对象
endpoint中会通过就绪探针探测,将探测成功的副本地址加入endpoint中,如果后续存活探针探测异常,会将endpoint中对应的服务地址踢除

直接部署pod时,pod内部的容器如果发生异常了,可以通过探针检测到进行异常恢复,那么k8s对于pod的上层资源如整个pod宕机,是怎么监听做到异常恢复的,滚动升级时怎么实现的,这里就来到了工作负载(指的不是负载均衡)

我们部署一个应用时不再直接编写Pod，而是部署一个Deploymen,在使用角度上我认为是编写Deploymen工作负载模板,设置pod的期望状态,例如通过replicas指定pod副本数,k8s监听pod实际状态,通过Deployment进而管理一组pod,实现异常恢复,滚动更新等功能
这里就需要了解ReplicasController简称RC副本控制器,ReplicasSet简称RS副本集,RC是早期使用的资源对象现在已经被RS取代,创建一个Deployment时，Kubernetes会自动创建一个相应的ReplicaSet，并根据Deployment定义的配置信息创建指定数量的Pod副本

ReplicaSet是Kubernetes中的一个资源对象,又叫做副本集,创建一个Deployment时，Kubernetes会自动创建一个相应的ReplicaSet，并根据Deployment定义的配置信息创建指定数量的Pod副本,主要用于确保指定数量的Pod副本正常运行，并负责监控和维护这些副本,ReplicaSet的主要功能包括

选择器标签匹配：ReplicaSet使用选择器标签来标识和管理与其关联的Pod副本。通过在ReplicaSet中指定选择器标签，它可以识别出与该标签匹配的Pod副本，并对其进行管理。这样可以确保ReplicaSet只管理符合条件的Pod副本，而不会干扰其他不相关的Pod
自动伸缩：通过在ReplicaSet中指定所需的副本数，ReplicaSet会自动创建或删除Pod副本以满足定义的副本数。当副本数不足时，ReplicaSet会自动创建新的Pod副本；当副本数过多时，ReplicaSet会自动删除多余的Pod副本
故障恢复：ReplicaSet会持续监控Pod副本的运行状态。如果某个Pod副本发生故障（例如崩溃或被删除），ReplicaSet会自动检测到并采取相应的措施。它会创建新的Pod副本来替代故障的副本，以确保指定数量的副本一直在运行
通过ReplicaSet的这些功能就能实现滚动升级, HPA动态扩缩容(结合Metrics-server监控资源状态), 灰度发布(例如蓝绿部署,金丝雀部署)等

通过Deploymen类型的工作负载部署的应用称为无状态应用,另外还有一种StatefulSet部署有状态应用的工作负载

无状态应用：可以简单理解为无状态应用不会记录当前状态,例如网络,存储等信息,如果应用宕机重启,重启后网络,存储,顺序可能等可能会变,例如Deployment部署的业务代码
有状态应用：可以记录当前状态,即使重启,重启后根据状态记录信息可以做到网络,存储,顺序等不变,例如中间件MySQL、Redis、MQ等等,以mysql为例,部署为有状态的服务,配合即使宕机重启访问地址不会变,其它服务还是可以正常访问的
并且使用StatefulSet部署的服务是有顺序的,创建pod时,会给创建的多个pod添加索引,部署,启动等都是按照这个索引顺序进行,停止或删除是按照索引逆序执行

另外还有Job任务和CronJob定时任务类型的工作负载

Job用于处理一次性任务,
CronJob基于Cron调度器实现定时任务

k8s网络访问问题

k8s集群中有多个节点,节点之间的网络是互通的
k8s中部署了多个pod,pod与pod之间不管是不是同一个Service下,命名空间下,只要能拿到目标pod地址,都可以访问也是网络互通的
为了管理pod提出了Service概念,一个service管理一组pod,Service中的ip是虚拟ip
通过kube-proxy代理网络,管理虚拟ip,管理ip的映射关系,跳转规则,可以看成一个字典表,一个地图,底层是通过kube-proxy操作ipvs lvs实现的,kube-proxy记录映射关系后,集群中的多个kube-proxy间会互相同步(一个节点下存在一个kube-proxy),当使用虚拟ip访问Serivce时,根据虚拟ip通过kube-proxy就可以查到实ip
拿到映射关系后,在访问时通过Calico网络组件进行路由转发

k8s中提供了类似网关的功能ingress,对应OSI层网络模型第7层,大概的工作原理类似于Nginx(底层好像就是基于Nginx实现的),因为ingress是基于OSI层网络模型第7层应用层实现的,可以解析出请求的数据,进而提供了

解析请求,根据请求进行路由,路径重写等
根据请求进行灰度等
配置TLS证书，使请求在传输过程中进行加密
注意使用Ingress，需要安装和配置IngressController,是一个运行在集群中的负责处理Ingress资源的组件，常见的IngressController包括NginxIngressController、Traefik、HAProxy等

还有基于NetworkPolicy网络访问策略对象,基于该资源可以实现流量控制
k8s的配置: Secret或ConfigMap
ResourceQuota资源配额与LimitRange资源限制范围

ResourceQuota资源配额: 通过 ResourceQuota 可以在命名空间级别设置 CPU、内存、存储等资源的使用上限。它可以限制命名空间中所有对象(如 Pod、Deployment、Service 等)的总资源使用量，确保其不会超过指定的配额
LimitRange资源限制范围: LimitRange 可以在 Pod 或命名空间级别定义资源使用的上限范围。它允许管理员为容器中的 CPU、内存、存储和其他资源设置上限，并可选地设置默认值。如果某个容器没有显式设置资源限制，那么将自动应用 LimitRange 中定义的默认限制。LimitRange 的主要作用是确保资源使用在合理的范围内，防止资源滥用和超出预期
当资源超过预期,系统会根据配置的策略进行相应的处理，以防止资源滥用和过度消耗,例如阻止创建新的 Pod,拒绝进一步的资源分配