"望卿知:本篇笔记由作者翻阅网上精华部分和官网上收集资料,翻阅书籍加上自己的理解而成,这篇很长很长"
kubernetes是什么?
kubernetes的名字来自于希腊语,意思为舵手领航员,创造者是行业巨头-----Google
因为k和s之间有8个字母,因此叫k8s,k8s是Google在10多年前大规模容器管理技术borg的开源版本,14年6月由Goole公司正式提出并宣布开源!!!
kubernetes是干什么的?
在此之前我们要提到docker,在2013年Docker宣布开源,从此开始爆火,Docker为什么会火呢? 因为它轻巧啊,就是这么简单----轻巧节约资源
在容器技术出来之前呢,都是用的是虚拟机技术,虚拟机的话我们需要安装vmware,甚至要钱,
通过vmware,可以虚拟出来一台乃至多台电脑,但是吃资源且不方便,很占内存。
这时候在13年docker宣布开源的时候,开发者们看到了docker----使用优秀优雅的golang开发。
虚拟机是在物理资源层面实现的隔离,相对于虚拟机,docker是APP层面实现的隔离,省去了虚拟机操作系统,从而节省了一部分的系统资源;docker守护进程可以直接与主操作系统进行通信,为每个docker容器分配资源;它还可以将容器与主操作系统隔离,并将各个容器互相隔离(docker网络)。虚拟机启动需要几分钟,而docker容器可以在数毫秒内启动。由于没有操作系统,docker可以节省大量的磁盘空间以及其他系统资源。
这时候docker被炒得热火朝天之时,大家发现,如果想将docker应用于具体的业务实现,是存在困难的---编排,管理,调度等等多个方面,都不容易,于是人们迫切需要一套管理系统,对docker及容器进行更高级灵活的管理,就在这个时候,k8s被宣布开源。
我们来看看k8s的具体抽象概念:
官网版:官网说是用于自动部署,扩展和管理容器化应用程序的开源系统
百度版:一个编排容器的工具,也是管理应用的全生命周期的工具。
书籍版:书上说是一个基于容器技术的分布式架构领先方案
我:k8s是一个开源的容器编排管理系统,docker是容器管理系统
老师版:容器编排管理系统,是一个开源的平台,可以实现集群的自动化部署,自动扩缩容,维护等功能。
群友版:k8s githun上写的的 企业生产级容器调度和管理---来自群友646361765
!!!很抽象,看你们自己适合谁的了
kubernetes的概述?
为什么使用k8s?1.有大量跨主机的容器需要管理
2.快速部署应用 3.快速扩展应用
4.无缝对接新的应用功能
5.节省资源,优化硬件资源的使用
为什么k8s好?
从架构设计层面,人们关注的可用性,伸缩性都可以结合k8s得到很好的解决,如果想更加完美,可以使用微服务架构,搭配k8s;从部署运维层面,服务部署,服务监控,应用扩展和故障处理,k8s都为我们提供了很好的解决方案,k8s可以让我们应用的部署使用更加方便。
kubernetes特性
1、故障迁移:当某一个node节点关机或挂掉后,node节点上的服务会自动转移到另一个node节点上,这个过程所有服务不中断。这是docker或普通云主机是不能做到的(pod有控制器的情况下会恢复)
2、资源调度:当node节点上的cpu、内存不够用的时候,可以扩充node节点,新建的pod就会被kube-schedule调度到新扩充的node节点上
3、资源隔离:创建开发、运维、测试三个命名空间,切换上下文后,开发人员就只能看到开发命名空间的所有pod,看不到运维命名空间的pod,这样就不会造成影响,互不干扰
3.便携:支持公有云,私有云,混合云,以及多种云平台,Qingcloud就是在原生云k8s基础上开发的混合云
4.可扩展:模块化,可插拔,支持钩子,可任意组合
5.自修复:自动重调度,自动重启,自动复制
6.快速精准地部署应用程序,限制硬件用量仅为所需资源
负载均衡
k8s可以更快的更新新版本,打包应用,更新的时候可以做到不用中断服务,服务器故障不用停机,从开发环境到测试环境到生产环境的迁移极其方便,一个配置文件搞定,一次生成image,到处运行
先上几张我收集来的图吧,别谢我,我在隔壁我姓王
架构图就分享到这了,开始正课了
kubernetes架构
集群(cluster)是一个master(控制节点)和node(计算节点)组成的kubernetes集群
1.master是kubernetes集群的控制节点,在k8s集群中需要一个或者一组master的节点,来负责整个集群的管理和控制,master通常占据一个独立的服务器(在高可用部署中至少3台服务器),是整个集群的大脑,如果他挂了或者不可用宕机,那么对集群内的计算节点容器应用的管理都无法实施。
角色和功能:1.master提供集群的控制 2.对集群进行全局决策 3.检测和响应集群事件
Master 节点是 Kubernetes 集群的控制节点,负责整个集群的管理和控制 。通过以下组件完成整个集群的控制:
API Server---是整个系统的对外接口,外界进行资源操作的唯一入口,也是用户唯一可以直接进行交互的kubernetes组件,内部系统组件以及外部用户组件均通过他进行通信,负责对外对内提供服务,其他Master组件都通过调用api server提供的rest接口实现各自的功能,如controller就是通过api server来实时监控各个资源的状态的。
而我们就是使用kubectl,用于通过命令行与API Server进行交互,而对Kubernetes进行操作,实现在集群中进行各种资源的增删改查等操作
总结一句话:集群控制的入口,没他不行
Scheduler---这个好理解,通过监听pod信息,并通过各种调度算法(算法可以自己定义)为该pod选择一个最合适最舒服的node节点。会找寻所有符合该pod要求的node节点,执行pod调度逻辑。当调度成功之后,会将pod信息绑定到目标node节点上,同时将信息写入到键值数据库etcd中。只要绑定,他的后续就由node节点上的kubelet接手pod的接下来的生命周期管理。如果没有合适的节点,则将Pod
置于挂起状态,直到出现合适的节点。
比喻:就像一个就业老师一样,通过你自身条件(pod信息),并通过筛选,给你找到一个合适的工作推荐,当你入职后,你已经成功和企业绑定在一块,后续就由公司那边管理了。
总结一句话:负责调度资源(pod调度)的进程
Etcd---这个有点深,要从定义开始讲,etcd是CoreOS团队在13年6月发起的开源项目,他的目标是构建一个高可用的分布式键值(key-value)数据库,基于优雅的go语言实现,在分布式系统中,各种服务的配置信息的管理分享,服务的发现是一个基本且重要的问题,CoreOS团队就希望基于etcd来解决这个问题。
kubernetes在运行过程中产生的元数据全部存储在etcd中,用于保存集群所有的网络配置和资源对象的状态信息,也就是保存了整个集群的状态。数据变更都是通过api server进行的。整个kubernetes系统中一共有两个服务需要用到etcd用来协同和存储配置,分别是:
1.网络插件flannel,其它网络插件也需要用到etcd存储网络的配置信息;
2.kubernetes本身,包括各种资源对象的状态和元信息配置
etcd的键值管理
在键的组织上etcd采用了层次化的空间结构,类似于文件系统的目录的概念,用户指定的键可以单独作为名字,如创建key键值,此时实际放在根目录/key下,也可以指定目录结构,如绝对路径/dir1/dir2/key,则创建相应的目录结构。
etcd有kubernetes集群自动管理,用户无需手动干预,etcdctl是etcd的客户端管理程序
一句话总结:kubernetes的后端数据库,k/v方式存储,所有的k8s集群数据都存放在此处。保存了整个集群的状态
Controllermanager---kubernetes里所有资源对象的自动化控制中心,负责管理控制器,负责维护集群的状态,比如故障检测、自动扩展、滚动更新等。每个资源一般都对应有一个控制器,这些controller通过api server实时监控各个资源的状态,controller manager就是负责管理这些控制器的。当有资源因为故障导致状态变化,controller就会尝试将系统由“现有状态”恢复到“期待状态”,保证其下每一个controller所对应的资源始终处于期望状态。当通过api server创建一个pod,当这个pod创建成功后,api server的任务就算完成。而后面保证pod的状态一直和我们想的一样的重任就由controller manager去保证了,它们是处理集群中常规任务的后台线程。
比喻:太监大总管,pod(皇帝),给pod选择控制器(妃子)
一句话总结:负责管理控制器,资源对象,并保证资源的状态,维护集群的状态
2.node计算节点
Node上运行着Master分配的pod,当一个Node宕机,其上的pod会被自动转移到其他Node上。
每一个Node节点都安装了Node组件,包括kubelet、kube-proxy、container runtime。
容器运行时(比如docker)---容器服务,提供镜像,创建容器和管理
kubelet---负责监视pod,包括创建,修改,删除等,同时和master密切协作,实现集群管理的基本功能,维护和管理该node上面的所有容器。即node节点通过kubelet与master组件交互,可以理解为kubelet是Master在每个node节点上面的管理组件。本质上,它负责使Pod的运行状态与期望的状态一致,同时也负责Volume(CSI)和网络(CNI)的管理。
kube-proxy---1.主要负责为pod提供代理 2.实现service的通信和负载均衡
确保每个节点都获得其IP地址,实现本地iptables
和规则以处理路由和流量负载均衡。
CRI(Container Runtime Interface):容器运行时接口,提供计算资源CNI(Container Network Interface):容器网络接口,提供网络资源CSI(Container Storage Interface):容器存储接口,提供存储资源
详解Container Runtime?
当提到Container Runtime时,可能会想到许多例子: runc,lxc,Docker,containerd,cri-o。这些中的每一个都是针对不同情况而构建的,并实现了不同的功能。
有些Container Runtime(例如containerd和cri-o)实际上使用runc来运行容器,并且实现了镜像管理和API等高级特性。而 runc 也是一种Container Runtime。此时你可能有点不理解,为什么containerd和runc 都可以称为Container Runtime?概念有点深,有想了解的小伙伴点击链接
Kubernetes 如何选择 container runtime - 简书
node可以在运行期间动态增加到kubernetes集群中,前提是这个node节点已经正确的安装配置和启动了这些关键进程,一旦node被纳入集群管理范畴,kubelet进程会定时向master汇报自身的情报,如操作系统,主机cpu和内存使用情况,以及当前node节点有哪些pod在运行,这样master就可以获取每个node的资源使用情况,并实现高效均衡的资源调度策略,而某个node在超过指定时间不上报信息时,会被master判定为失联,该node的状态会被标记为不可用(not ready),master随后会触发工作负载大转移的自动流程。
还有一个重要的基础概念---命名空间,它在很多情况下用于实现多租户的资源隔离,典型的思路就是给每个租户都分配一个命名空间,命名空间属于kubernetes集群范畴的资源对象,在一个集群里可以创建多个命名空间,每个命名空间都是独立的,属于不同命名空间的资源对象从逻辑上相互隔离,在每个kubernetes集群安装完成且运行之后,master会自动创建2个命名空间,一个是默认的default,一个是系统级的kube-system,用户创建的资源对象如果没有指定命名空间,则默认放到defalut,而系统相关的资源对象,如网络组件,dns组件,监控类组件等,都被安装在kube-system命名空间中,我们可以通过命名空间将集群内部的资源对象分配到不同的命名空间中,形成逻辑上分组的不同项目,小组或用户组,便于不同分组在共享使用整个集群的资源的同时能被分别管理,当个每个租户都创建一个命名空间来实现多租户的资源隔离时,还能结合kubernetes的资源配额管理,限定每个租户能占用的资源,如cpu,内存使用量等。
flannel是什么
实质上是一种"覆盖网络(overlay network)",也就是将TCP数据包装在另一种网络包里面进行路由转发和通信,目前支持UDP,VxLAN,AWS,VPC和GCE路由等数据转发方式。
使用flannel目标
不同主机内的容器实现互联互通
master服务端口
协议 端口范围 软件 用途
TCP 6443 kube-apiserver 所有组件接口服务
TCP 2379-2380 etcd kube-api,etcd服务
TCP 10250 kubelet kubelet服务
TCP 10251 kube-scheduler kube-scheduler服务
TCP 10252 kube-controller-manager kube-controller-manager服务
学个毛kubernetes,学了用不上,暂更