目录
一，迭代过程
传统运维---》集群化---》分布式、高可用、高性能（集群）---》虚拟化---》全虚拟方案---》半虚拟方案---》KVM EXSI viturlbox---》虚拟化产品 Vmware workstation vsphere-容器---》容器引擎---》docker enqine podman引擎
资源管理器---》docker k8s mesoss（iaas层）
集成化管理---》gitops devops CI/CD
资源整合---》自动化的k8s部分+人工智能+大数据+云原生的“产品-go”
二，资源管理器
1，K8S概述
k8s首先对集群化的容器进行批量管理（增，删，改，查）
2，K8S基础概念
K8S视一切可以管理的对象称为资源，哪怕该服务不是k8s内部的，作为k8s的常规组件来使用，k8s也是提供了API给我们来自行定义“控制器”（汇聚插件）
2.1 ，pod资源
最小的资源单位
pod中的有几种容器：3种
- init容器：初始化容器环境
- pause容器：在pod内提供统一的network namespace 和存储卷支持
- 业务容器：应用容器：支持业务运行
pod内部容器使用的网络模式：docker0和localhost
2.2 ，service 资源
提供服务发现支持:
service几种模式：
1,Nodeport：如图他会给每一个node都映射上一个3000端口。
2，ClusterIP：用K8S自带的扁平化的网络进行通信，
3，headless：（无头服务），
4，loadbalance：L4/L7 软件还是硬件
5，Externalip（overlay）：
2.3，yml文件
K8S资源管理器中的资源的“配置文件”叫法：资源清单
2.4，控制器
管理pod
管理pod资源（维护pod状态）保障、维护用户的期望值，预期值
- replicaset 维护pod副本数量和pod状态的
- deployment无状态服务 无特殊状态，无独立状态的应用
- statefulset 有状态服务 有独立状态---》mysql0pod
- job 一次性任务
- Cronjob 周期性任务
- ingress L7层的流量管理、LB服务（http/https）
- daemonSet 所有节点运行同一类pod 每一个节点跑一个指定的pod资源
- PV PVC 动态存储
Deployment—无状态应用部署
Nginx 这种类型的服务，只开启反向代理的功能的时候，假设nginx 宕了，重新跑一个新的，替换过来，可以直接用。没有差异化称为无状态。
无状态服务：LVS（加入集群后，无特殊性需求—需求）
- 服务不依赖自身的状态，实例的状态数据可以维护再内存中
- 任何一个请求都可以被任意一个实例处理
- 不存储状态数据，实例可以水平扩展，通过负载均衡将请求分发到各个节点
- 在一个封闭的系统中，只存在一个数据闭环
- 通常存在于单体架构集群中
Statefulset—有状态应用部署
里面运行的是mysql，mysql 宕了，配置一样，不能直接用，数据有差异性，加入集群后满足特定规则，存储数据的规则，才能使用，有差异化称为有状态。
有状态服务：例如数据库
由特殊状态需求，例如需要持久化、需要特定的数据支持
- 服务本身依赖或者存在局部的状态数据，这些数据需要自身持久化或者可以通过其他节点恢复。
- 一个请求只能被某个节点（或者同等状态下的节点）处理。
- 存储状态数据，实例的拓展需要整个系统参与状态的迁移。
- 在一个封闭的系统中，存在多个数据闭环，需要考虑这些闭环的数据一致性问题。
- 通常存在于分布式架构中。
Deployment：无状态应用部署。Deployment 的作用就是管理和控制 Pod 和ReplicaSet，管控它们运行在用户期望的状态中。
Replicaset：确保预期的 Pod 副本数量。ReplicaSet 的作用就是管理和控制 Pod，管控他们好好干活。但是ReplicaSet 受控于 Deployment。可以理解成 Deployment 就是总包工头，主要负责监督底下的工人 Pod干活，确保每时每刻有用户要求数量的 Pod 在工作。如果一旦发现某个工人 Pod 不行了，就赶紧新拉一个 Pod 过来替换它。而ReplicaSet 就是总包工头手下的小包工头。从 K8S 使用者角度来看，用户会直接操作 Deployment 部署服务，而当Deployment 被部署的时候，K8S 会自动生成要求的 ReplicaSet 和 Pod。用户只需要关心 Deployment而不操心 ReplicaSet。资源对象 Replication Controller 是 ReplicaSet 的前身，官方推荐用Deployment 取代 Replication Controller 来部署服务。
Daemonset：确保所有节点运行同一类Pod，保证每个节点上都有一个此类 Pod 运行，通常用于实现系统级后台任务。
Statefulset：有状态应用部署。
Job：一次性任务。**根据用户的设置，Job 管理的 Pod 把任务成功完成就自动退出了。
Cronjob：周期性计划性任务。
Ingress：管理 L7 层的网络模式（http/https 流量） ingress 包含：nginx、Haproxy、traffic、 istio、kong
PV/PVC:动态存储。NFS接入到k8s时，不能直接挂载，要利用pv/pvc来管理，共享存储也是资源，由pv/pvc来管理。比如10G不够了，扩容由pv/pvc来进行动态扩容处理。
2.5 存储
静态存储 volumes
动态存储 （1.保障容灾性2.为有状态应用提供存储持久化支持）PV PVC(Ceph+nfs)
2.6，调度器scheduler
决定pod运行在那个合适的节点
- 预选 先排除肯定不符合的，例如资源不够，该节点有污点，该节点禁止调度，该节点做了反亲和等等
- 优选 在剩余可用节点内，根据算法来进行各种类型的打分，分数高的，更优先被调度
2.7，label标签
用于给k8s中特定对象的一种资源
- label 可对资源打上标记
- 通过selector标签选择器，来将不同类型的资源，通过相同标签关联在一起
2.8，namespace
用户k8s之间资源的隔离，主要是为了便于管理
2.9，安全
k8s集群中所有的资源，组件包括外部往内部访问，服务运行等等，均需要“安全“
- CA证书
- RBAC准入控制权管理
- 密钥，token形式等等
以上均为：加密安全
三，CNI插件
container network interface 容器网络接口---》为了让pod之间可以进行通讯（不同节点之间进行通讯）
cni主要类型：
- flannel
- calico
- canal
在该模式中pod-ip是如何被分配的
K8S集群中有一个核心组件是ETCDetcd是K8S的核心数据库，存储着K8S集群中的所有资源信息，包括Pod-ip地址的分配，也是由ETCD来定义的。每一个新建的pod都会收到一个新的ip来使用，有一个地址的范围，拿一个少一个，所以每个pod的ip地址是不会冲突的。不管如何都是通过veth对来和docker0网关相连，都是从容器之间出去，并不是pod，上图的10.1.15.0为flanel0在docker0网关和flanel0中会有一个钩子函数
如果非同一网段之间通讯，flanel0就会通过钩子函数收到相关的地址，然后再给到自己的守护进程再给到自己的网卡即网关
flannel0会读取ETCD中的路由信息即知道目的地址在哪。
最后flannel守护进程会做一层封装，默认的flannelcni模式是Vxlan
flannel几种模式
1.Vxlan 2.gateway网关 3.UDP模式，此处使用的是Vxlan
此处flannel会进行不同的封装：（即Vxlan的作用
数据包封装头部:
MAC头部IP头部协议上层数据
封装完成后的数据：
MAC
源MAC: node1 MAC
目标MAC: node2_ MAC
IP头部:
源lP: node1 IP
目标IP: node2_IP
flanneld做了封装:协议:
UDP
Pod_lp头部
源IP: Pod01_IP目标lP: Pod02_IP
上层数据三，kubernetes核心组件
3.1，Master组件
kube-apiserver
- 用于暴露kubernetes API，任何资源请求或调用操作都是通过kube-apiserver提供的接口进行
- 以HTTP Restful API提供接口服务，所有对象资源的增删改查和监听操作都交给API Server处理后再提交给ETCD存储。
- 可以理解成API Server是K8S的请求入口服务。API Server负责接收K8S所有请求（来自界面或者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副本数量 |
| Endpoints Controller（端点控制器） | 填充端点对象（即连接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）
配置存储中心-etcd
K8S 的存储服务，负责存储K8S集群的重要信息。etcd 是分布式键值存储系统，存储了 K8S 的关键配置和用户配置，K8S 中仅 API Server 才具备读写权限，其他组件必须通过 API Server 的接口才能读写数据。
主节点工作流程
API Server 接收到请求创建一批 Pod，API Server 会让 Controller-manager 按照所预设的模板去创建 Pod，Controller-manager 会通过 API Server 去找 Scheduler 为新创建的 Pod 选择最适合的 Node 节点。比如运行这个 Pod 需要 2C4G 的资源，Schedular 会通过预算策略在所有 Node 节点中挑选最优的。Node 节点中还剩多少资源是通过汇报给 API Server 存储在 etcd 里，API Server 会调用一个方法找到 etcd 里所有 Node 节点的剩余资源，再对比 Pod 所需要的资源，在所有 Node 节点中查找哪些 Node 节点符合要求。如果都符合，预算策略就交给优选策略处理，优选策略再通过 CPU 的负载、内存的剩余量等因素选择最合适的 Node 节点，并把 Pod 调度到这个 Node 节点上运行。
3.2 node组件
kubelet
Node 节点的监视器，以及与 Master 节点的通讯器。Kubelet 是 Master 节点安插在 Node 节点上的 “眼线”，它会定时向 API Server 汇报自己 Node 节点上运行的服务的状态，并接受来自 Master 节点的指示采取调整措施。
从 Master 节点获取自己节点上 Pod 的期望状态（比如运行什么容器、运行的副本数量、网络或者存储如何配置等），直接跟容器引擎交互实现容器的生命周期管理，如果自己节点上 Pod 的状态与期望状态不一致，则调用对应的容器平台接口（即 docker 的接口）达到这个状态。管理镜像和容器的清理工作，保证节点上镜像不会占满磁盘空间，退出的容器不会占用太多资源。
kube-Proxy
- 在每个 Node 节点上实现 Pod 网络代理，是 Kuberbetes Service资源的载体，负责维护网络规划和四层负载均衡工作。负责写入规则至 iptables、ipvs 实现服务映射访问的。
- Kube-Proxy 本身不是直接给 Pod 提供网络，Pod 的网络是由 Kubelet 提供的，Kube-Proxy实际上维护的是虚拟的 Pod 集群网络。
- Kube-apiserver 通过监控 Kube-Proxy 进行对 Kubernets Service 的更新和端点的维护。
- Kube-Proxy 是 K8S 集群内部的负载均衡器。它是一个分布式代理服务器，在 K8S 的每个节点上都会运行一个Kube-proxy。
- Kubernetes 包含多种类型的资源对象：Pod、Label、Service、Replication Controller 等。
- 所有的资源对象都可以通过 Kubernetes 提供的 kubectl 工具进行增、删、改、查等操作，并将其保存在 etcd中持久化存储。
- Kubernets其实是一个高度自动化的资源控制系统，通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异，来实现自动控制和自动纠错等高级功能。
四，K8S创建pod流程
kubectl 创建一个Pod（在提交时，转化为json格式）
- 首先经过auth认证（鉴权），然后传递给api-server进行处理
- api-server 将请求信息提交给etcd
- scheduler和controller-manager 会watch（监听） api-server ，监听请求
- 在scheduler 和controller-manager监听到请求后，scheduler 会提交给api-server一个list清单——》包含的是获取node节点信息
- 此时api-server就会向etcd获取后端node节点信息，获取到后，被scheduler watch到，然后进行预选优选进行打分，最后将结果给与 api-server
- 此时api-server也会被controller-manager watch（监听） controller-manager会根据请求创建Pod的配置信息（需求什么控制器）将 控制器资源给与api-server
- 此时api-server 会提交list清单给与对应节点的kubelet（代理）
- kubelet代理通过K8S与容器的接口（例如containerd）进行交互，假设是docker容器，那么此时kubelet就会通过dockershim 以及runc 接口与docker的守护进程docker-server进行交互，来创建对应的容器，再生成对应的Pod
- kubelet 同时会借助于metrics server 收集本节点的所有状态信息，然后再提交给api-server
- 最后api-server会提交list清单给与etcd来存储（最后api-server会将数据维护在etcd中）
简单版：
- 首先kubectl 转化为json后，向api-server 提交创建Pod请求
- api-server将请求信息记录在etcd中
- scheduler 监听api-server处理的请求，然后向api-server申请后端节点信息
- api-server 从etcd中获取后端节点信息后，给与scheduler
- scheduler 进行预选优选、打分，然后提交结果给api-server
- controller-manager 监听api-server处理的请求信息，并将所需的控制器资源给与api-server
- api-server 对接node节点的kubelet
- kubelet调用资源创建pod，并将统计信息返回给api-server
- api-server将信息记录在etcd中