K8s基本概念入门
序言 没等到风来,绵绵小雨,所以写个随笔,聊聊k8s的基本概念。 k8s是一个编排容器的工具,其实也是管理应用全生命周期的一个工具,从创建应用,部署应用,应用提供服务,扩容缩容应用,应用更新,都非常的方便,而且可以做到故障自愈,例如某个服务器挂了,k8s可以自动将这个服务器上的服务调度到另外一个主机上进行运行,而无需进行人工干涉。那么,问题来了,要运维何用? k8s可以...
序言
没等到风来,绵绵小雨,所以写个随笔,聊聊k8s的基本概念。
k8s是一个编排容器的工具,其实也是管理应用全生命周期的一个工具,从创建应用,部署应用,应用提供服务,扩容缩容应用,应用更新,都非常的方便,而且可以做到故障自愈,例如某个服务器挂了,k8s可以自动将这个服务器上的服务调度到另外一个主机上进行运行,而无需进行人工干涉。那么,问题来了,要运维何用?
k8s可以更快的更新新版本,打包应用,更新的时候可以做到不用中断服务,服务器故障不用停机,从开发环境到测试环境再到生产环境的迁移极其方便,一个配置文件搞定,一次生成image,到处运行。。。
k8s的全生命周期管理
在k8s进行管理应用的时候,基本步骤是:创建集群,部署应用,发布应用,扩展应用,更新应用。
1、创建集群:为什么要使用集群?
有一句古话叫做三个臭皮匠,赛过诸葛亮,这就是创建集群的原因。。。
使用集群,create cluster是为了掩盖底层的无能,在各种环境中,底层的硬件各不相同,有的是各种低廉的服务器,有的是各种云环境,有的是各种vm,有的是各种host machine,要想屏蔽底层的细节,增强可靠性和稳定性,从而需要创建集群。
创建集群的好处就是,统一对外提供接口,无须进行各种复杂的调用;提供更好的可靠性,服务器宕机那么频繁,物理磁盘那么容易损坏,无须担心,集群统一进行调配;提供更好的性能,组合集群中各个机器的计算存储网络资源,提供更好的TPS和PS;提供横向扩容的能力,在进行横向扩容的时候,性能基本上能呈线性增长。
集群看起来很牛,那么创建起来很复杂么?并不会,在k8s只要使用两条指令就可以创建一个集群,一条是 kubectl init 进行初始化,创建一个master节点,第二条指令就是 kubectl join xxx 创建一个node节点,加入这个集群。
在这边可以看到k8s在物理上进行划分的时候,划分了两种类型的主机,一个是master节点,主要用来调度,控制集群的资源等功能;而另一类是node节点,主要是用来运行容器的节点,也就是运行服务的节点。
其实集群都差不多,master用来控制,用来存储各种元数据,node节点是一个工作节点,真正来干活的;node节点定时与master进行通信,通过kubelet进程来汇报信息。
创建了集群,我要怎么查看集群信息?如下:
2、 部署应用
使用集群的主要目的是啥?用来提供服务,让开发的应用程序能在集群上运行,从而需要让开发能运行一个应用来进行测试。
一条指令就能运行一个服务,有了image之后就是这么简单。所以,在开发完成程序之后,需要将程序打包成image,然后放到registry中,然后就能够运行应用了。
在部署完成应用之后,执行命令 kubectl get deployments/{name} 就可以看到应用的名称,期望状态(DESIRED)是运行一个pod,当前(CURRENT)有一个pod,活动的(AVAILABLE)也是一个,还有启动的时间(AGE),那么什么是pod呢?
在k8s里面,集群调度的最小单元就是一个pod,一个pod可以是一个容器,也可以是多个容器,例如你运行一个程序,其中使用了nginx,使用了mysql,使用了jetty,那么可以将这三个应用在同一个pod中,对他们提供统一的调配能力,一个pod只能运行在一个主机上,而一个主机上可以有多个pod。
那么有人会问,为什么要使用pod,为什么不能直接使用容器呢?使用pod,相当于一个逻辑主机,还记得创建一个vm,在vm上运行几个进程么,其实道理是一样的,pod的存在主要是让几个紧密连接的容器之间共享资源,例如ip地址,共享存储等信息。如果直接调度容器的话,那么几个容器可能运行在不同的主机上,这样就增加了系统的复杂性。
3、发布应用
发布应用主要就是对外提供服务,可能会有人提出疑问,我都运行了服务,为什么还不能提供服务,这是因为在集群中,创建的ip地址等资源,只有在同一个集群中才能访问,每个pod也有独一的ip地址,当有多个pod提供相同的服务的时候,就需要有负载均衡的能力,而这里就涉及到一个概念就是service,专门用来提供服务的。
服务主要是用来提供外界访问的接口,服务可以关联一组pod,这些pod的ip地址各不相同,而service相当于一个负载均衡的vip,用来指向各个pod,当pod的ip地址发生改变之后,也能做到自动进行负载均衡,在关联的时候,service和pod之间主要通过label来关联,也就是标签(-l表示为label)。
这样外界就可以访问此应用了,如下:
4、 扩容缩容
在业务上线之后,碰到了双十一怎么办?扩容。。。万剑归宗,只要有一个pod,那么就可以产生无数个pod。。。。
过了双十一怎么办,缩容。。。
横向扩展的能力。。每次扩容缩容的时候,这种会不会觉得很方便,一句话的事儿。。不用创建vm,不用去部署中间件,不用去各种修改配置,这就是自动化。。。
5、 更新
有新版本了,我要发布。。。那么。。。
滚动更新。。。根据新的image创建一个pod,分配各种资源,然后自动负载均衡,删除老的pod,然后继续更新。。。。不会中断服务。。。
更新错了怎么办,不怂,不会影响生产业务,回滚就好了。。。几秒钟的事儿。。。
后话
k8s的基本入门,其实算是一种用户视角,只是用来演示如何使用k8s,怎么提高了生产力而已。
在给客户演示的时候,为啥要选择k8s?主要就是如何提高了发布的效率,更新版本的效率,更方便更快捷的上线新版本。
但是在运维关注的视角下,这些远远不够。。。master?存储了哪些元数据,存储在etcd中?如何来进行监控?在很多很多系统情况下,怎么来部署k8s,是一个项目一个k8s还是一个k8s多个项目?等等一系列的问题。。。
---------------------
作者:运维Linux和python
来源:CSDN
原文:https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/79621510?utm_source=copy
版权声明:本文为博主原创文章,转载请附上博文链接!
更多推荐
所有评论(0)