KUBERNETES01_部署方式的变迁为什么用Kubernetes工作原理组件交互原理动画演示

Posted 2022-01-12 所得皆惊喜

文章目录

• ①. 部署方式的变迁
• ②. 为什么用Kubernetes
• ③. Kubernetes概述及不是什么
• ④. Kubernetes工作原理
• ⑤. 部署组件交互原理
• ⑥. 主、从节点原理分解
• ⑦. Kubernetes架构-动画演示

①. 部署方式的变迁

• ①. 传统部署时代

1. 在物理服务器上运行应用程序
2. 无法为应用程序定义资源边界
3. 导致资源分配问题
4. 例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况, 结果可能导致其他应用程序的性能下降。 一种解决方案是在不同的物理服务器上运行每个应用程序,但是由于资源利用不足而无法扩展, 并且维护许多物理服务器的成本很高。

• ②. 虚拟化部署时代

1. 作为解决方案,引入了虚拟化
2. 虚拟化技术允许你在单个物理服务器的CPU上运行多个虚拟机(VM)
3. 虚拟化允许应用程序在VM之间隔离,并提供一定程度的安全
4. 一个应用程序的信息不能被另一应用程序随意访问
5. 虚拟化技术能够更好地利用物理服务器上的资源
6. 每个VM是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。
7. 缺点:虚拟层冗余导致的资源浪费与性能下降(如下图都需要virtual Machine、Operating System等)

• ③. 容器部署时代

1. 容器类似于VM,但可以在应用程序之间共享操作系统(OS)
2. 容器与 VM 类似,具有自己的文件系统、CPU、内存、进程空间等
3. 由于它们与基础架构分离,因此可以跨云和 OS 发行版本进行移植
4. Docker隔离原理 - namespace 6项隔离(资源隔离)与 cgroups 8项资源限制(资源限制)
5. .Kubernetes官网地址

②. 为什么用Kubernetes

容器是打包和运行应用程序的好方式。在生产环境中,你需要管理运行应用程序的容器,并确保不会停机。 例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易？
(这就是Kubernetes来解决这些问题的方法!Kubernetes为你提供了一个可弹性运行分布式系统的框架。 Kubernetes会满足你的扩展要求、故障转移、部署模式等。 例如,Kubernetes可以轻松管理系统的Canary部署)
Kubernetes为你提供:

• ①. 服务发现和负载均衡
  Kubernetes可以使用DNS名称或自己的IP地址公开容器,如果进入容器的流量很大, Kubernetes可以负载均衡并分配网络流量,从而使部署稳定

• ②. 存储编排
  Kubernetes允许你自动挂载你选择的存储系统,例如本地存储、公共云提供商等
  (有一个应用需要占用了内存,k8s会给这个应用开辟一个内存,当应用销毁时,k8s自动将内存释放)

• ③. 自动部署和回滚
  你可以使用Kubernetes描述已部署容器的所需状态,它可以以受控的速率将实际状态 更改为期望状态。例如,你可以自动化Kubernetes来为你的部署创建新容器, 删除现有容器并将它们的所有资源用于新容器。
  (在6.18淘宝有一个版本,现在10.1也有一个版本,如果10.1版本上线出现问题了,也还可以回滚到6.18版本上去)

• ④. 自动完成装箱计算
  Kubernetes允许你指定每个容器所需CPU和内存(RAM)。 当容器指定了资源请求时,Kubernetes可以做出更好的决策来管理容器的资源。
  (比如:容器超内存了,将容器杀死或者转移到别的地方进行部署)

• ⑤. 自我修复
  Kubernetes重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。

• ⑥. 密钥与配置管理
  Kubernetes允许你存储和管理敏感信息,例如密码、OAuth令牌和ssh密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。

③. Kubernetes概述及不是什么

• Kubernetes是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 Kubernetes拥有一个庞大且快速增长的生态系统。Kubernetes的服务、支持和工具广泛可用。

• ②. 名称Kubernetes源于希腊语,意为"舵手"或"飞行员"。Google在2014年开源了Kubernetes项目。 Kubernetes建立在Google在大规模运行生产工作负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。

• ③. Kubernetes不是传统的、包罗万象的PaaS(平台即服务)系统。 由于Kubernetes在容器级别而不是在硬件级别运行,它提供了PaaS产品共有的一些普遍适用的功能, 例如部署、扩展、负载均衡、日志记录和监视。 但是,Kubernetes不是单体系统,默认解决方案都是可选和可插拔的。 Kubernetes提供了构建开发人员平台的基础,但是在重要的地方保留了用户的选择和灵活性

1. 不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载,包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行,那么它应该可以在 Kubernetes 上很好地运行。
2. 不部署源代码,也不构建你的应用程序。 持续集成(CI)、交付和部署(CI/CD)工作流取决于组织的文化和偏好以及技术要求。
3. 不提供应用程序级别的服务作为内置服务,例如中间件(例如,消息中间件)、 数据处理框架(例如,Spark)、数据库(例如,mysql)、缓存、集群存储系统 (例如,Ceph)。这样的组件可以在 Kubernetes 上运行,并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制(例如, 开放服务代理)来访问。
4. 不要求日志记录、监视或警报解决方案。它提供了一些集成作为概念证明,并提供了收集和导出指标的机制。
5. 不提供或不要求配置语言/系统(例如 jsonnet),它提供了声明性API, 该声明性API可以由任意形式的声明性规范所构成。RESTful,写yaml文件
6. 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。

④. Kubernetes工作原理

• ①. 控制平面组件(Control Plane Components) :相当于山水总部
  控制平面的组件对集群做出全局决策(比如调度),以及检测和响应集群事件(例如,当不满足部署的 replicas 字段时,启动新的 pod)

• ②.kube-apiserver:相当于秘书
  API 服务器是Kubernetes控制面的组件, 该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端
  Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平伸缩,也就是说,它可通过部署多个实例进行伸缩。 你可以运行 kube-apiserver 的多个实例,并在这些实例之间平衡流量。

• ③. etcd资料库(键值数据库(redis)记账本,记事本)
  etcd是兼具一致性和高可用性的键值数据库,可以作为保存Kubernetes所有集群数据的后台数据库。
  您的Kubernetes集群的etcd数据库通常需要有个备份计划。
  要了解etcd更深层次的信息,请参考etcd文档。

• ④.kube-scheduler(调度者)
  控制平面组件,负责监视新创建的、未指定运行节点(node)的Pods,选择节点让Pod在上面运行。
  调度决策考虑的因素包括单个Pod和Pod集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

• ⑤. kube-controller-manager:相当于决策者
  在主节点上运行控制器的组件。
  从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。

• ⑥. cloud-controller-manager:相当于外联部
  云控制器管理器是指嵌入特定云的控制逻辑的控制平面组件。云控制器管理器允许您链接集群到云提供商的应用编程接口中,并把和该云平台交互的组件与只和您的集群交互的组件分离开。

• ⑦. Node组件:kubelet(相当于厂长、每一个node节点上必须安装的组件)
  一个在集群中每个节点(node)上运行的代理。它保证容器(containers)都运行在Pod中。
  kubelet接收一组通过各类机制提供给它的PodSpecs,确保这些PodSpecs中描述的容器处于运行状态且健康。kubelet不会管理不是由Kubernetes创建的容器。

• ⑧. Node组件:kube-proxy(相当于外面的门卫大爷、代理网络)
  kube-proxy是集群中每个节点上运行的网络代理,实现Kubernetes服务(Service)概念的一部分。
  kube-proxy维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与Pod进行网络通信。
  如果操作系统提供了数据包过滤层并可用的话,kube-proxy会通过它来实现网络规则。否则,kube-proxy仅转发流量本身。
  

• ⑨. 程序员:调用CLI(命令行)告诉master,我们现在要部署一个tomcat应用步骤如下: 掌握

1. 程序员的所有调用都先去master节点的网关api-server。这是matser的唯一入口(mvc模式中的c层)
2. 收到的请求先交给master的api-server。由api-server交给controller-mannager进行控制
3. controller-mannager进行应用部署
4. controller-mannager会生成一次部署信息。 tomcat --image:tomcat6 --port 8080,真正不部署应用
5. 部署信息被记录在etcd中
6. scheduler调度器从etcd数据库中,拿到要部署的应用,开始调度。看哪个节点合适
7. scheduler把算出来的调度信息再放到etcd中
8. 每一个node节点的监控kubelet,随时和master保持联系的(给api-server发送请求不断获取最新数据),所有节点的kubelet就会从master
9. 假设node2的kubelet最终收到了命令,要部署。其他的node节点也会收到命令,但是node2最终部署,所以其他node节点丢弃这次部署的操作
10. kubelet就自己run一个应用在当前机器上,随时给master汇报当前应用的状态信息,分配ip
11. node和master是通过master的api-server联系的
12. 每一个机器上的kube-proxy能知道集群的所有网络。只要node访问别人或者别人访问node,node上的kube-proxy网络代理自动计算进行流量转发

⑤. 部署组件交互原理

想让k8s部署一个tomcat？

• 0开机默认所有节点的kubelet、master节点的scheduler(调度器)、controller-manager(控制管理器)一直监听master的api-server发来的事件变化(while)

• 1.程序员使用命令行工具:kubectl
  kubectl create deploy tomcat --image=tomcat8(告诉master让集群使用tomcat8镜像,部署一个tomcat应用)

• 2.kubectl命令行内容发给api-server,api-server保存此次创建信息到etcd

• 3etcd给api-server上报事件,说刚才有人给我里面保存一个信息。(部署Tomcat[deploy])

• 4controller-manager监听到api-server的事件,是 (部署Tomcat[deploy])

• 5controller-manager 处理这个 (部署Tomcat[deploy])的事件。controller-manager会生成Pod的部署信息pod信息

• 6controller-manager 把Pod的信息交给api-server,再保存到etcd

• 7etcd上报事件pod信息给api-server。

• 8scheduler专门监听 pod信息 ,拿到 pod信息的内容,计算,看哪个节点合适部署这个Podpod调度过后的信息(node: node-02)

• 9scheduler把 pod调度过后的信息(node: node-02)交给api-server保存给etcd

• 10etcd上报事件pod调度过后的信息(node: node-02),给api-server

• 11其他节点的kubelet专门监听 pod调度过后的信息(node: node-02) 事件,集群所有节点kubelet从api-server就拿到了 pod调度过后的信息(node: node-02) 事件

• 12每个节点的kubelet判断是否属于自己的事情；node-02的kubelet发现是他的事情

• 13node-02的kubelet启动这个pod。汇报给master当前启动好的所有信息

⑥. 主、从节点原理分解

• ①. 主节点(master)

1. master也要装kubelet和kubeproxy
2. 前端访问(UI、CLI)
3. kube-apiserver、scheduler、controller manager、etcd
4. kubelet+kubeproxy每一个节点的必备+docker(容器运行时环境)

• ②. 工作节点(node)
  Kubelet:监工,负责交互master的api-server以及当前机器的应用启停等,在master机器就是master的小助手。每一台机器真正干活的都是这个Kubelet
  

⑦. Kubernetes架构-动画演示