Kubernetes
一、什么是Kubernetes
众所周知，kubernetes(以下简称k8s)是google基于Blog进行改进后，开源出来的一款“容器管理应用”。由于近几年来容器技术的火爆，许许多多的服务都不会直接部署在linux主机或各大云厂商的虚拟机上；利用Docker，将每个服务做成一个Image，把他们跑在各自的Container中。
这样做的好处有非常多，比如环境配置隔离、服务启动快、移植便捷等等。但是使用的Container多到一定程度，就会带来容器管理上的问题：使用docker ps命令之后有一大堆Container，如果标识的不清楚也很容易混淆；某些分布式服务，需要将Docker部署到许多不同的机器上，这也会增加我们运维的难度。因此，我们现在需要一款“专门管理容器”的平台，为我们提供可视化界面，方便我们对各个容器进行管理。
k8s就是这样一款辅助我们管理容器的平台，支持管理在分布式环境(即多台服务器上)启动的Container。有了他，再也不用愁容器多的管理不过来或者找不到容器在不同主机上的位置了！
二、Kubernetes和Docker Swarm
2.1、Docker Swarm是啥？
Docker Swarm是docker官方推出的一款用来管理docker集群的平台，几乎全部使用GO语言来完成开发，单一的docker只支持单台服务器的部署，不支持堕多台服务器间的调度，而docker swarm则是将一群Docker宿主机变成一个单一的虚拟主机，Docker Swarm使用标准的Docker API接口作为其前端的访问入口，换言之，各种形式的Docker Client(docker-compose,docker-py等)均可以直接与Swarm通信，甚至Docker本身都可以很容易的与Swarm集成，这大大方便了用户将原本基于单节点的系统移植到Swarm上，同时Swarm内置了对Docker网络插件的支持，用户也很容易的部署跨主机的容器集群服务。
Docker Swarm 和 Docker Compose 一样，都是 Docker 官方容器编排项目，但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具，而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合。
从 Docker 1.12.0 版本开始，Docker Swarm 已经包含在 Docker 引擎中（docker swarm），并且已经内置了服务发现工具，我们就不需要像之前一样，再配置 Etcd 或者 Consul 来进行服务发现配置了。
Swarm deamon只是一个调度器(Scheduler)加路由器(router),Swarm自己不运行容器，它只是接受Docker客户端发来的请求，调度适合的节点来运行容器，这就意味着，即使Swarm由于某些原因挂掉了，集群中的节点也会照常运行，放Swarm重新恢复运行之后，他会收集重建集群信息。
2.2、Kubernetes和Docker Swarm谁比较好？
毋庸置疑是k8s更好，Swarm的最大优势在于兼容docker API，使得swarm 学习成本低，同时架构简单，部署运维成本较低，但是劣势同样是因为API兼容，无法提供集群的更加精细的管理
在网络方面，默认docker容器是通过桥接与NAT和主机外网络通信，这样就出现2个问题，一个是因为是NAT，外部主机无法主动访问到容器内（除了端口映射），另外默认桥接IP是一样的，这样会出现不同主机的容器有相同的IP的情况。这样两容器更加不能通信。同时网络性能方面，有人测试经过桥接的网络性能只有主机网络性能的70%。当然以上问题可以通过其他工具解决，比如用 Flannel 或者 OVS网桥。
在容器可靠性方面，相较于K8s的Replication Controllers可以监控并维持容器的生命，swarm在启动时刻可以控制容器启动，在启动后，如果容器或者容器主机崩溃，swarm没有机制来保证容器的运行。
在网络方面，k8s 默认使用Flannel作为overlay网络。
Flannel是CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（OverlayNetwork）工具，其目的在于帮助每一个使用 Kuberentes 的CoreOS 主机拥有一个完整的子网。
简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
K8s 的优势：
容器的高可用性，集群的精细管理，复杂的网络场景。
- 服务发现与调度
- 负载均衡
- 服务自愈
- 服务弹性扩容
- 横向扩容
- 存储卷挂载
K8s 的劣势：
K8s的学习曲线陡峭，同时运维的成本相对高点。
k8s和swarm的优劣比较
相同点：k8s和docker swarm都是基于docker开发的，底层都是docker容器
三、Kubernetes的基本概念和架构示意
3.1、k8s的基础架构示意图
我们分别来理解这幅架构图示意图中的一些概念：
3.2、Kubernetes Master / Node
如果大家对诸如hadoop这样的分布式集群有所了解，就会发现k8s的设计理念和其他分布式架构的非常类似的：Master节点负责接收用户的指令、分配任务以及记录各个node的情况；而node节点负责接收Master的指令，启动相应的Pod（k8s的最小执行单元，是一个Container的集合)。
安装k8s时会指定Master和Node节点，部署好之后，我们通过k8s的api与Master节点进行交互。Master节点收到了我们的指令(比如新启动一个Pod)，会调度Node节点去完成它们。当然，其中底层的调度策略、具体的实现细节对于我们使用者来说都是隐蔽的，不需要我们去了解。
3.3、Container
容器。由于k8s是容器管理平台，因此如果你使用k8s管理Docker的容器的话，那么这里的Container就是Docker的Container。作为启动一个组件的最小单元（比如我可以用一个Container启动一个mysql ，另一个Container启动一个tomcat。而mysql和tomcat的各种配置文件都在它们自己的Container中，因此不会相互干扰，也不会污染linux主机的配置环境。）。
3.4、Pod
docker中，容器是最小执行单元，而在k8s中，Pod是最小的执行单元，是一组Container的集合。由于一个服务往往是要基于许许多多的组件才能完成的，因此一个Pod就是“能够完整运行这个服务”的最小个体，也是k8s将其指定为原子单元的初衷（比如我要启动一个简单的网站服务，至少需要一个tomcat、一个mysql以及我自己编写的网站业务流程程序。因此在k8s中，我就会启动一个Pod，这个Pod中包含三个Container，每个Container包含了它们相应的组件。）。Pod可以是一个完整程序，也可以是由单一的容器组成的一个Pod，这个是由项目特性和资源多寡来决定的。每个Pod中的所有Container是共享IP地址和文件系统的，这点要特别注意。因为有pause的存在，所以在pod内部，容器间可天然做到互联互通，
Pod原意是“豌豆荚”，我觉得这个比喻很形象。每个容器就像豌豆一样，而Pod就像豆荚一样把豌豆们包住，使之成为一个整体。
3.4.1、Pause(必须)
3.5.1 用于提供共享volumn数据卷
3.5.2 提供网路互通
Pause可以将pod内部多个container的网络进行互通，让多个container之间能使用localhost+端口的形式进行访问
3.5、Replication Controller(复制控制器)
存在于master节点上，用于指定每个Pod的备份数量。由于k8s采用的是分布式架构，为了保证高可靠性，万一哪台node节点突然宕机了，也必须要保证服务能够正常运行。因此，每个Pod都会被复制成n份(默认设置3份)，运行在不同的node节点上。Replication Controller就是用来管理Pod备份数量，保证高可靠性的组件。假如某个pod失去响应，那么，那个pod将会被剔除，由复制控制器重新创建一个新的pod。假设此时需要从3个副本增加到5个副本，那么也只需人工修改副本数，复制控制器将会自动创建缺少的副本。
3.6、Service(服务)
用于各种信息的抽象，用于把pod和pod连接起来，让pod和pod能通信。
3.7、Label(标签)
每个Pod的唯一标识符（别名），信息会存在etcd数据库中。Service就是通过这个识别各个Pod谁是谁的，就像工号一样。主要是一个说明性的标签。
3.8、kubelet
在k8s安装完成之后，kubelet便已经存在，用于执行k8s命令，相当于docker中的docker指令，kubelet是k8s的核心命令。我的理解，kubelet就类似于每个工地里工头的角色，负责具体派活儿和监督。
3.9、kube-proxy
kube-proxy是一个通信代理，在k8s中，每个node都用自己的一个虚拟IP地址。而kube-proxy就是负责每个node与其他node或Matser节点通信的枢纽。信息的流入和流出、请求的转发都是通过kube-proxy进行操作的。
2958
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
