读书笔记《每天5分钟玩转Kubernetes》——从Swarm到K8S

今天在图书馆偶遇了一本书,书名就是上面写着的《每天5分钟玩转Kubernetes》,让我想到了之前在IBM社区里面看到的一个五分钟openstack的系列。看着书篇幅不大,就一百来页,所以就随手翻翻,也作为自己对K8S的入门,后面没准整站的系统需要从Swarm向K8S迁移了。

由于属性SWARM所以使用类比的方法,可以很好的理解K8S的设计。整本书大概花了7个?番茄时钟翻完。之前选择Swarm由于Docker本身就包含了这个组件,简单易得。这本书看完之后,发现K8s很多特性解决了现在的问题,结论是k8s更加优秀,比如在卷管理的地方,之前Swarm如果要实现的话需要用上NFS,就很麻烦,而K8S默认的就是多节点同步。等等的特性后面再写吧。迟早换。

基本概念

如在swarm的里面的service,stack,等等的名词。这些东西在k8s里面有不一样的叫法。Cluster,Master,Node。这些都一样,集群,manager主机,从机。


Pod 是K8s里面最小的调度单位,和Swarm不同,S里面的单位就是单个容器。Pod理解为豌豆荚,里面有一个或者多个的容器。它们之间可以容易的实现资源共享。

在pod比基本的容器更加的高一层次,可以使得更好的进行服务组装。而且在pod内是默认进行网络共享(同样的nampspace)可以直接使用localhost和端口进行通信。vol的挂载在一个pod上,实际上是挂载在了所有的容器上,切数据是同步的。

只有关系十分紧密的容器,才需要被放在一个pod中,比如书中所讲的 file puller 和 webserver,一个负责web文件的更新,因为可以进行文件的共享,一个提供服务可以很好的进行功能整合,而不对外部暴露过多细节。

但是如果是 Tomcat 和 Mysql 则不适合此情景,因为其间只存在网络通信,并不需要进行文件共享,所以不需要在一个Pod中。


Controller 是pod的资源管理器。
Service 这里和Swarm 类似,不过他的单位不再是多个容器,而是多个Pod,这里有一级网络映射。对外统一的暴露端口,内部自动的进行LB

基本架构

和Swarm的架构其实是大同小异的,就是这些异带来了惊喜的功能。


Master节点:APIserver,提供API接口,所以可以通过前端进行容易的控制。Scheduler,实现Pod之间的调度。Controller作为pod的资源管理器。etcd(这东西有时间了解下,见得有点多了)实现对节点的配置信息进行存储,有变化时候,会直接和server同步。

Node:kublet,向master报告信息,kube-proxy,实现请求在pod之间的转发。

运行

配置的方式和s类似,使用命令行和yml的方式进行,语法差不多。一样可以很方便的实现scale的扩缩容。
在一个k网络中,节点挂点之后,pod会自动的转移。

JOB 容器分为两类,工作类和服务类,一个运行完停止,一个会提供服务,你懂得。Job可以很好的来控制Deploy的过程。

service

pod是脆弱的,但是应用是稳定的,所以这里就需要service了,里面所有的pod自动的进行lb,最后通过service 在主机上暴露出来。(k8s可以直接找podip)。k甚至提供了有一个默认的DNS,直接把Service的名称在Dns里进行注册,这样直接在本地就可以访问了(kube-dns)

wget httpd-svc:8080

滚动升级和回滚,这里就不说了。s里面也有的功能。等真正打包好的自己的镜像可以很方便。使用rollout undo

health chk

检测容器的健康状态,这个在现网上的确是应该有的,web的页面,mysql的连接等等,这个要成为习惯。因为一个容器如果挂掉了实际上可能并不会退出

一般的做法是在pod的部署的时候,加上一个web的接口,在注册的时候写进文件,那么就会有周期的调度进行http请求,根据返回值判断服务的健康状态。

数据管理

在一个pod里面多个容易可以很方便的进行文件的共享,使用emptyDir可以在多个容器里面挂载,切是文件共享的。生命周期和POd一致。


虽然很好用,可是还是不够持久,因为pod的周期也是有限的,如果是数据库啥的就完蛋。所以就有了 PV(persistentVolume)其生命周期是独立的,在建立pod的时候进行生命即可。但是,问题是后面还是需要NFS噗。

secret

用于避免在yml文件中直接包含敏感配置的问题。

Helu K8S的包管理

这个真的是妙,因为如果存在大规模的工程部署的时候,就出现了配置文件爆炸的情况,所以需要把特定的pod 抽象为一个包的形式。

k8s的Dashboard

前面还在苦苦的折腾Portainer现在发现自己是low了,k8s已结给做好了,妙呀。部署的过程就不说了,到时候试试。

集群监控

作为一个OP,监控是不可少的,所以这里就有了神器了。

Weave Scope

这个,看了效果图简直神奇啊,会自动的构建应用和集群的逻辑拓扑,找出pod和pod之间的依赖关系,还可以进行实时的资源监控(简单的)

Heapster

K8s的原生方案,简单易得,直接数据进influxDB,上Grafana,进行数据可视化显示。

Prometheus !!!

这个就是K8s的一大大大大厉害之处,首先监控上grafana只是基础功能,通过配置文件,我们可以通过容器状态来绑定K8s的API(通过告警alarm),也就是实现我们的(自动扩缩容)

日志监控(偶遇ELK)

这里的L由logstask变成了fluentd,也就是efk,这一套东西起来不得了了。对于容器的日志获取一向是个大问题,现在,解决了????

祝大家生活愉快XD

留下点什么吧