今天在图书馆偶遇了一本书，书名就是上面写着的《每天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