多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
# Kubernetes简介 ## 来源 中文官网:https://kubernetes.io/zh 中文社区:https://www.kubernetes.org.cn/ ## 介绍 K8S主要讲的就是Kubernetes,首先Kubernetes首字母为K,末尾为s,中间一共有8个字母,所以简称K8s ## 前置知识 - Linux操作系统 - Docker ## 课程简介 - K8s概念和架构 - 从零搭建K8s集群 - 基于客户端工具kubeadm搭建(简单,最多半小时) - 基于二进制包方式(能看到内部的架构) - K8s核心概念 - Pod:K8s管理的最小单位级,是所有业务类型的基础 - Controller:控制器,有状态,无状态,一次任务,定时任务,守护进程 - Service Ingress:对外暴露端口 - RBAC:安全机制,权限模型 - Helm:下载机制 - 持久化存储 - 搭建集群监控平台系统 - 从零搭建高可用K8s集群 - 在集群环境部署项目 ## K8S概念和特性 ### 部署发展历程 我们的项目部署也在经历下面的这样一个历程 > 传统部署 -> 虚拟化部署时代 -> 容器部署时代 ![image-20201122104102715](https://img.kancloud.cn/92/15/9215996cdb2d636efc1dc3f6a438b05a_950x365.png) - **传统部署时代**:早期,组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界,这会导致资源分配问题。例如,如果在物理服务器上运行多个应用程序,则可能会出现-一个应用程序占用大部分资源的情况,结果可能导致其他应用程序的性能下降。--种解决方案是在不同的物理服务器上运行每个应用程序,但是由于资源利用不足而无法扩展,并且组织维护许多物理服务器的成本很高。 - **虚拟化部署时代**:作为解决方案,引入了虚拟化功能,它允许您在单个物理服务器的CPU.上运行多个虚拟机(VM)。虚拟化功能允许应用程序在VM之间隔离,并提供安全级别,因为一一个应用程序的信息不能被另一应用程序自由地访问。因为虚拟化可以轻松地添加或更新应用程序、降低硬件成本等等,所以虚拟化可以更好地利用物理服务器中的资源,并可以实现更好的可伸缩性。每个VM是一台完整的计算机,在虚拟化硬件之上运行所有组件,包括其自己的操作系统。 - **容器部署时代**:容器类似于VM,但是它们具有轻量级的隔离属性,可以在应用程序之间共享操作系统 (OS),因此,容器被认为是轻量级的。容器与VM类似,具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离,因此可以跨云和OS分发进行移植。 容器因具有许多优势而变得流行起来。下面列出了容器的一些好处: - 敏捷应用程序的创建和部署:与使用VM镜像相比,提高了容器镜像创建的简便性和效率。 - 持续开发、集成和部署:通过简单的回滚(由于镜像不可变性),提供可靠且频繁的容器镜像构建和部署。 - 关注开发与运维的分离:在构建/时而不是在部署时创建应用程序容器镜像,将应用程序与基础架构分离。 - 可观察性:不仅可以显示操作系统级别的信息和指标,还可以显示应用程序的运行状况和其他指标信号。 - 跨开发、测试和生产的环境一致性:在便携式计算机上与在云中相同地运行。 - 云和操作系统分发的可移植性:可在Ubuntu、RHEL、RHEL、CoreOS、本地、Google Kubernetes Engine和其它任何其它地方运行。 - 以应用程序为中心的管理:提高抽象级别,从在虚拟硬件上运行OS到使用逻辑资源在OS上运行应用程序。 - 松散耦合、分布式、弹性、解放的微服务:应用程序被分解成较小的独立部分,并且可以动态部署和管理-而不是在一台大型单机上器体运行。 - 资源隔离:可预测的应用程序性能。 ### K8S概述 kubernetes,简称K8s,是用8 代替8 个字符“ubernete”而成的缩写。是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes 的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes 提供了应用部署,规划,更新,维护的一种机制。 传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定,这样做并不利于应用的升级更新/回滚等操作,当然也可以通过创建虚拟机的方式来实现某些功能,但是虚拟机非常重,并不利于可移植性。 新的方式是通过部署容器方式实现,每个容器之间互相隔离,每个容器有自己的文件系统,容器之间进程不会相互影响,能区分计算资源。相对于虚拟机,容器能快速部署,由于容器与底层设施、机器文件系统解耦的。 > 总结: > > - K8s是谷歌在2014年发布的容器化集群管理系统 > - 使用k8s进行容器化应用部署 > - 使用k8s利于应用扩展 > - k8s目标实施让部署容器化应用更加简洁和高效 ### K8S概述 Kubernetes 是一个轻便的和可扩展的开源平台,用于管理容器化应用和服务。通过Kubernetes 能够进行应用的自动化部署和扩缩容。在Kubernetes 中,会将组成应用的容器组合成一个逻辑单元以更易管理和发现。 Kubernetes 积累了作为Google 生产环境运行工作负载15 年的经验,并吸收了来自于社区的最佳想法和实践。 ### K8S功能 #### 自动装箱 基于容器对应用运行环境的资源配置要求自动部署应用容器 #### 自我修复(自愈能力) 当容器失败时,会对容器进行重启 当所部署的Node节点有问题时,会对容器进行重新部署和重新调度 当容器未通过监控检查时,会关闭此容器直到容器正常运行时,才会对外提供服务 ![image-20200928101336750](https://img.kancloud.cn/d1/a3/d1a3fd9da4a14963143a4d05f1223309_849x464.png) 如果某个服务器上的应用不响应了,Kubernetes会自动在其它的地方创建一个 ![image-20201122112241092](https://img.kancloud.cn/58/02/58024960cbb917362f0689bac6e20126_810x259.png) #### 水平扩展 通过简单的命令、用户UI 界面或基于CPU 等资源使用情况,对应用容器进行规模扩大或规模剪裁 > 当我们有大量的请求来临时,我们可以增加副本数量,从而达到水平扩展的效果 当黄色应用过度忙碌,会来扩展一个应用 ![image-20201122112301750](https://img.kancloud.cn/ae/a3/aea3ed0c903d8692794fc9f8d7d89e7b_819x254.png) #### 服务发现 用户不需使用额外的服务发现机制,就能够基于Kubernetes 自身能力实现服务发现和负载均衡 > 对外提供统一的入口,让它来做节点的调度和负载均衡, 相当于微服务里面的网关? ![image-20200928101711968](https://img.kancloud.cn/a8/0a/a80a03fa254b0b0cf5ed5c9a145fc793_723x557.png) #### 滚动更新 可以根据应用的变化,对应用容器运行的应用,进行一次性或批量式更新 > 添加应用的时候,不是加进去就马上可以进行使用,而是需要判断这个添加进去的应用是否能够正常使用 #### 版本回退 可以根据应用部署情况,对应用容器运行的应用,进行历史版本即时回退 > 类似于Git中的回滚 #### 密钥和配置管理 在不需要重新构建镜像的情况下,可以部署和更新密钥和应用配置,类似热部署。 #### 存储编排 自动实现存储系统挂载及应用,特别对有状态应用实现数据持久化非常重要 存储系统可以来自于本地目录、网络存储(NFS、Gluster、Ceph 等)、公共云存储服务 #### 批处理 提供一次性任务,定时任务;满足批量数据处理和分析的场景 ## K8S架构组件 ### 完整架构图 ![image-20200928103059652](https://img.kancloud.cn/89/5b/895b839bf3d97ddd0ee9bcdfd83c390d_1150x769.png) ![image-20200928110124821](https://img.kancloud.cn/b6/c6/b6c6c43c6a9419e0ef3c0dc7de584d44_1177x670.png) ### 架构细节 K8S架构主要包含两部分:Master(主控节点)和 node(工作节点) master节点架构图 ![image-20201122113057343](https://img.kancloud.cn/60/d2/60d20054468ee61fcace49379f4f6a16_500x362.png) Node节点架构图 ![image-20201122155629990](https://img.kancloud.cn/24/ec/24ec2700bdaa0c72e1c8173aa75eb6ed_852x571.png) k8s 集群控制节点,对集群进行调度管理,接受集群外用户去集群操作请求; - **master**:主控节点 - API Server:集群统一入口,以restful风格进行操作,同时交给etcd存储 - 提供认证、授权、访问控制、API注册和发现等机制 - scheduler:节点的调度,选择node节点应用部署 - controller-manager:处理集群中常规后台任务,一个资源对应一个控制器 - etcd:存储系统,用于保存集群中的相关数据 - **Work node**:工作节点 - Kubelet:master派到node节点代表,管理本机容器 - 一个集群中每个节点上运行的代理,它保证容器都运行在Pod中 - 负责维护容器的生命周期,同时也负责Volume(CSI) 和 网络(CNI)的管理 - kube-proxy:提供网络代理,负载均衡等操作 - 容器运行环境【**Container Runtime**】 - 容器运行环境是负责运行容器的软件 - Kubernetes支持多个容器运行环境:Docker、containerd、cri-o、rktlet以及任何实现Kubernetes CRI (容器运行环境接口) 的软件。 - fluentd:是一个守护进程,它有助于提升 集群层面日志 ## K8S核心概念 ### Pod - Pod是K8s中最小的单元 - 一组容器的集合 - 共享网络【一个Pod中的所有容器共享同一网络】 - 生命周期是短暂的(服务器重启后,就找不到了) ### Volume - 声明在Pod容器中可访问的文件目录 - 可以被挂载到Pod中一个或多个容器指定路径下 - 支持多种后端存储抽象【本地存储、分布式存储、云存储】 ### Controller - 确保预期的pod副本数量【ReplicaSet】 - 无状态应用部署【Deployment】 - 无状态就是指,不需要依赖于网络或者ip - 有状态应用部署【StatefulSet】 - 有状态需要特定的条件 - 确保所有的node运行同一个pod 【DaemonSet】 - 一次性任务和定时任务【Job和CronJob】 ### Deployment - 定义一组Pod副本数目,版本等 - 通过控制器【Controller】维持Pod数目【自动回复失败的Pod】 - 通过控制器以指定的策略控制版本【滚动升级、回滚等】 ![image-20201122161601349](https://img.kancloud.cn/f2/90/f290fb1489b139d555d2f2267f536044_284x147.png) ### Service - 定义一组pod的访问规则 - Pod的负载均衡,提供一个或多个Pod的稳定访问地址 - 支持多种方式【ClusterIP、NodePort、LoadBalancer】 ![image-20201122161132055](https://img.kancloud.cn/aa/5c/aa5cfcaf790706296b82ddb79ffd1ab6_239x252.png) 可以用来组合pod,同时对外提供服务 ### Label label:标签,用于对象资源查询,筛选 ![image-20201122161713638](https://img.kancloud.cn/67/31/6731c0f87d17e62a70f56bb6de9e7f4c_477x229.png) ### Namespace 命名空间,逻辑隔离 - 一个集群内部的逻辑隔离机制【鉴权、资源】 - 每个资源都属于一个namespace - 同一个namespace所有资源不能重复 - 不同namespace可以资源名重复 ### API 我们通过Kubernetes的API来操作整个集群 同时我们可以通过 kubectl 、ui、curl 最终发送 http + json/yaml 方式的请求给API Server,然后控制整个K8S集群,K8S中所有的资源对象都可以采用 yaml 或 json 格式的文件定义或描述 如下:使用yaml部署一个nginx的pod ![image-20201122162612448](https://img.kancloud.cn/41/f1/41f1b2f3d7029b41d8813c5d72334ed3_675x353.png) ## 完整流程 ![image-20201122163512535](https://img.kancloud.cn/0c/7d/0c7dd1ee42a9117b06c3424fd1a78537_870x192.png) - 通过Kubectl提交一个创建RC(Replication Controller)的请求,该请求通过APlserver写入etcd - 此时Controller Manager通过API Server的监听资源变化的接口监听到此RC事件 - 分析之后,发现当前集群中还没有它所对应的Pod实例 - 于是根据RC里的Pod模板定义一个生成Pod对象,通过APIServer写入etcd - 此事件被Scheduler发现,它立即执行执行一个复杂的调度流程,为这个新的Pod选定一个落户的Node,然后通过API Server讲这一结果写入etcd中 - 目标Node上运行的Kubelet进程通过APiserver监测到这个"新生的Pod.并按照它的定义,启动该Pod并任劳任怨地负责它的下半生,直到Pod的生命结束 - 随后,我们通过Kubectl提交一个新的映射到该Pod的Service的创建请求 - ControllerManager通过Label标签查询到关联的Pod实例,然后生成Service的Endpoints信息,并通过APIServer写入到etod中, - 接下来,所有Node上运行的Proxy进程通过APIServer查询并监听Service对象与其对应的Endponts信息,建立一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能