CoreOS进阶
昨天没有写博客,想想楼主都干了啥呢?早晨来上课了,何老师斗智斗勇了,然后就没了,晚上看了一下电视剧,打了两把游戏就睡了,本来楼主看见了一片关于CoreOS的文章,感觉那篇文章真的是一个大牛写的!!好多的观点和知识楼主没见过!!特此记录一下.
CoreOS是一个Linux发行版本,比着linux轻很多.这里轻代表了很多的含义,比如,CoreOS的大小,启动时间,内存消耗,磁盘占用都比Linux小.当然了CoreOS并不是最轻量的分布式系统,最轻量的分布式系统应该是RancherOS.
CoreOS有什么用(它和容器有什么关系)?
CoreOS的关键特性
1.安全的自动化无限版本升级.
2.云环境的容器和集群内置支持.
先来看一下第一个特性,其实第一个特性包括三个内容:无限版本,自动化,安全性.
什么会阻碍操作系统版本的无限升级?
1.系统文件被篡改导致升级不可控.
2.升级系统会覆盖用户变更的文件.
3.用户安装的软件与新版系统不兼容.
上面这三点导致的问题其实是用户增加,删除或修改了系统文件.
或者是用户的软件运行环境与系统强耦合.
CoreOS为什么可以完成无限版本升级呢?
CoreOS采用只读系统分区来防止用户对系统文件的操作,采用操作系统内置容器服务来解决软件运行环境与系统强耦合的问题.
因为CoreOS使用只读分区,使用容器不仅是一种良好的习惯也是强制要求.
再来看一下关于自动化升级.
升级无非两种:内核的版本;关键服务的版本
什么会影响自动化升级呢?
内核和关键服务升级需要重启服务器.这一点应该没有异议吧.
CoreOS采用什么措施来解决呢?
1.内置集群工具实现自动化服务迁移.
2.限制同时进行重启的服务器数量.
最后一点是关于安生性升级的问题.
所谓的安全性升级,是什么意思呢?在使用windows的时候,应该会出现这样的提示吧,请不要关闭计算机电源或爬出电源线,正在安装更新...其实就是说当前系统正在升级中,不能爬出或关闭电源.这个过程往往是漫长的,楼主在使用win7的时候曾经在凌晨的时候等待过2个多小时,因为楼主想的是更新的过程应该很快吧,更新好了关机睡觉!!!
什么原因会导致系统升级过程不安全呢?
停电!!硬盘故障!!软件和系统有冲突!!总之一句话,可能是各种原因,anything!
升级时可能出现的问题:
1.缓慢的升级等待过程
2.升级过程中出现故障
CoreOS的安全性升级解决以上问题的策略:
1.双系统分区.
2.整体替换升级.
3.支持快速回滚.(楼主一直感觉回滚这项技术很棒!!因为楼主在小的时候,什么小汽车,小手枪什么的啊,一般拆了就弄不好了..如果我会回滚的话,就太棒了.)
CoreOS是如此的轻巧,如此的NB,但是他不是万能的,它也有它的缺点,CoreOS不适合干什么呢?
1.玩游戏...
2.运行不能够容器化的应用.
3.没有网络的运行环境.
CoreOS的特点之一:内置工具
云环境的容器和集群内置支持.
容器相关工具:
docker,Rkt,Actool,Btrfs,Xfs.
云端环境和集群相关工具
Cloudinit,Etcd,Fleet,Flannel,Kubelee
接下来说一下,CoreOS的使用,前面的案例中楼主曾经说过关于CoreOS的使用.但是仅限于皮毛.
CoreOS的使用分为下面几个步骤:
1.服务器节点启动配置.(先让服务器起来这是肯定的).
2.单节点的服务管理.
3.集群的服务管理.
4.集群的配置管理.
5.集群的成员管理.
6.其他工具和技巧.
接下来分布说一下各个步骤:
1.CoreOS服务器节点启动配置(CoreOS-Cloudinit)
Cloudintit配置(文件)的内容:
YAML格式
描述服务配置
描述服务状态
创建吗自定义文件
案例
#cloud-config
coreos:
etcd2:
name:core01
...
fleet:
public-ip:$public_ipv4
...
units:
-name:etcd2.service
command:start
-name:fleet.service
command:start
-name:docker.service
command:start
2.单节点的服务管理:systemd
systemd是啥?
systemd是一个pid=1的系统进程;管理者后台服务,设备,事件,定时器等;服务启动的依赖管理;服务日志统一管理.
总结起来是systemd是一个用于管理系统的进程.
systemd的用法
systemd-run
直接把任务的命令作为后台服务运行.这样做的好处是启动方便,但是可配置性差,不便于管理.
systemctl
用Unit文件描述服务,这样做可对服务进行精细配置,这是推荐的使用.
说一下Uint文件是什么,systemd的同意系统资源配置描述,采用ini配置文件格式.
[Unit]
全局信息和依赖描述
[Service]
服务的操作和属性描述
[Install]安装为随系统自动启动服务所需的描述.
如何写Uint文件
描述服务内容
[Service]
TimeoutStartSec=0
ExecStart=/usr/bin/docker run --rm --name guestbook --link redis-master:redis-master --link redis-slave:redis-slave -p 3000:3000 guestbook
ExecStop=/usr/bin/docker stop guestbook
ExecStopPost=/usr/bin/docker rm guestbook
描述依赖关系和启动注册参数
[Uint]
Description=Guestbook frontend
Required=docker.service redis-master.service redis-slave.service
Alter=docker.service redis-master.service redis-slave.service
[Install]
WantedBy=default.target
至此一个完整的Uint文件算是完成了,他所完成的工作是这样的:
分析一下服务的依赖情况:
前端App依赖redia-master,redis-slave这两个数据库;redis-slave这个从数据库依赖于redis-master这个主数据库;redis-master不依赖任何东西.
CoreOS的使用小技巧:
尽可能用容器运行所有自定义的后台服务.
每个Uint文件应该只包含一种服务的种类.
对于此案例来说,Redis-master和Redia-slave是两个不同的服务种类,他们yialai,启动参数等均不相同.
3.集群的服务管理:Fleet
Fleet是Systemd功能在集群的延伸.
Fleet兼容所有Systemd的服务类型Uint文件属性.
扩展了服务类型Uint文件,支持指定运行节点.
集群节点状态管理,快速跳转.
集群级别的日志管理.
Fleet的运行原理(启动服务).
Step1:用户提交Uint文件(submit).
step2:Fleet分配Uint文件到节点(load).
step3:Fleet控制SYstemd运行服务(start).
submit-->load-->start
Fleet的运行原理(移除服务)
Step1:Fleet控制Systemd停止服务(stop).
Step2:从具体节点注销Uint文件(Unload).
Step3:从Fleet记录移除Uint文件(destroy).
stop->Unload->destroy
此处再说一个小技巧,服务若能使用Fleet管理,就不应该直接使用Systemd管理.
4.集群配置管理:etcd
CoreOS的集群实质上是Etcd的集群.节点间本没有联系,是Etcd支撑了整个CoreOS集群运作.Etcd和容器是CoreOS生态圈的核心.
怎么理解”分布式配置管理”:
键值对存储,值可用是任意字符串.
多节点自动同步.
如果是这样的话,那么Etcd和NoSQL数据库是比较类似的,区别是:
etcd使用Raft算法动态选择Leader节点.
etcd的每一次写入都需要半数以上节点确认.etcd运行在集群的每一个节点.
所有服务都可用直接向localhost读写数据.
etcd有”成员节点”和”代理节点”的区分.
支持watch和TTL等特性.
“成员节点”和”代理节点”的区别:
是否参与Leader节点选择.
是否影响写入速度.
是否本地保存数据.
新节点是否需要”邀请”才能加入.
5.集群成员的管理
增加/删除成员节点
添加节点
从现有节点发出”邀请”
启动新的节点
删除节点
从现有节点确认”删除”
关闭已经被删除的节点.
增加/删除代理节点
添加节点
直接启动新的节点
删除节点
直接关闭不需要的节点.
CoreOS的使用步骤算是都介绍完了,最后说一点关于CoreOS的局限性:
1.无法更换系统软件版本,解决办法是使用容器运行这些软件的不同版本.
2.Fleet用于较大规模服务仍然过于繁琐,解决方式是使用kubernetes替换fleet.
3.在国内升级服务器被墙,解决办法是通过代理或者VPN.