KUBERNETES01_部署方式的变迁为什么用Kubernetes工作原理组件交互原理动画演示
Posted 所得皆惊喜
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了KUBERNETES01_部署方式的变迁为什么用Kubernetes工作原理组件交互原理动画演示相关的知识,希望对你有一定的参考价值。
文章目录
- ①. 部署方式的变迁
- ②. 为什么用Kubernetes
- ③. Kubernetes概述及不是什么
- ④. Kubernetes工作原理
- ⑤. 部署组件交互原理
- ⑥. 主、从节点原理分解
- ⑦. Kubernetes架构-动画演示
①. 部署方式的变迁
- ①. 传统部署时代
- 在物理服务器上运行应用程序
- 无法为应用程序定义资源边界
- 导致资源分配问题
- 例如,如果在物理服务器上运行多个应用程序,则可能会出现一个应用程序占用大部分资源的情况, 结果可能导致其他应用程序的性能下降。 一种解决方案是在不同的物理服务器上运行每个应用程序,但是由于资源利用不足而无法扩展, 并且维护许多物理服务器的成本很高。
- ②. 虚拟化部署时代
- 作为解决方案,引入了虚拟化
- 虚拟化技术允许你在单个物理服务器的CPU上运行多个虚拟机(VM)
- 虚拟化允许应用程序在VM之间隔离,并提供一定程度的安全
- 一个应用程序的信息不能被另一应用程序随意访问
- 虚拟化技术能够更好地利用物理服务器上的资源
- 每个VM是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。
- 缺点:虚拟层冗余导致的资源浪费与性能下降(如下图都需要virtual Machine、Operating System等)
- ③. 容器部署时代
- 容器类似于VM,但可以在应用程序之间共享操作系统(OS)
- 容器与 VM 类似,具有自己的文件系统、CPU、内存、进程空间等
- 由于它们与基础架构分离,因此可以跨云和 OS 发行版本进行移植
- Docker隔离原理 - namespace 6项隔离(资源隔离)与 cgroups 8项资源限制(资源限制)
- .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提供了构建开发人员平台的基础,但是在重要的地方保留了用户的选择和灵活性
- 不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载,包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行,那么它应该可以在 Kubernetes 上很好地运行。
- 不部署源代码,也不构建你的应用程序。 持续集成(CI)、交付和部署(CI/CD)工作流取决于组织的文化和偏好以及技术要求。
- 不提供应用程序级别的服务作为内置服务,例如中间件(例如,消息中间件)、 数据处理框架(例如,Spark)、数据库(例如,mysql)、缓存、集群存储系统 (例如,Ceph)。这样的组件可以在 Kubernetes 上运行,并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制(例如, 开放服务代理)来访问。
- 不要求日志记录、监视或警报解决方案。它提供了一些集成作为概念证明,并提供了收集和导出指标的机制。
- 不提供或不要求配置语言/系统(例如 jsonnet),它提供了声明性API, 该声明性API可以由任意形式的声明性规范所构成。RESTful,写yaml文件
- 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。
④. 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应用步骤如下: 掌握
- 程序员的所有调用都先去master节点的网关api-server。这是matser的唯一入口(mvc模式中的c层)
- 收到的请求先交给master的api-server。由api-server交给controller-mannager进行控制
- controller-mannager进行应用部署
- controller-mannager会生成一次部署信息。 tomcat --image:tomcat6 --port 8080,真正不部署应用
- 部署信息被记录在etcd中
- scheduler调度器从etcd数据库中,拿到要部署的应用,开始调度。看哪个节点合适
- scheduler把算出来的调度信息再放到etcd中
- 每一个node节点的监控kubelet,随时和master保持联系的(给api-server发送请求不断获取最新数据),所有节点的kubelet就会从master
- 假设node2的kubelet最终收到了命令,要部署。其他的node节点也会收到命令,但是node2最终部署,所以其他node节点丢弃这次部署的操作
- kubelet就自己run一个应用在当前机器上,随时给master汇报当前应用的状态信息,分配ip
- node和master是通过master的api-server联系的
- 每一个机器上的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)
- master也要装kubelet和kubeproxy
- 前端访问(UI、CLI)
- kube-apiserver、scheduler、controller manager、etcd
- kubelet+kubeproxy每一个节点的必备+docker(容器运行时环境)
- ②. 工作节点(node)
Kubelet:监工,负责交互master的api-server以及当前机器的应用启停等,在master机器就是master的小助手。每一台机器真正干活的都是这个Kubelet
⑦. Kubernetes架构-动画演示
以上是关于KUBERNETES01_部署方式的变迁为什么用Kubernetes工作原理组件交互原理动画演示的主要内容,如果未能解决你的问题,请参考以下文章