Kubernetes学习笔记——k8s基本概念初探
啥是kubernetes？
众所周知，kubernetes(以下简称k8s)是google基于Blog进行改进后，开源出来的一款“容器管理应用”。由于近几年来容器技术的火爆，许许多多的服务都不会直接部署在linux主机或各大云厂商的虚拟机上；利用Docker，将每个服务做成一个Image，把他们跑在各自的Container中。
这样做的好处有非常多，比如环境配置隔离、服务启动快、移植便捷等等。但是使用的Container多到一定程度，就会带来容器管理上的问题：使用docker ps命令之后有一大堆Container，如果标识的不清楚也很容易混淆；某些分布式服务，需要将Docker部署到许多不同的机器上，这也会增加我们运维的难度。因此，我们现在需要一款“专门管理容器”的平台，为我们提供可视化界面，方便我们对各个容器进行管理。
k8s就是这样一款辅助我们管理容器的平台，支持管理在分布式环境(即多台服务器上)启动的Container。有了他，再也不用愁容器多的管理不过来了、或者找不到容器在不同主机上的位置了！
kubernetes的基本概念和架构示意
k8s的基础架构示意图如下：
我们分别来理解这幅架构图示意图中的一些概念：
Kubernetes Master / Node : 如果大家对诸如hadoop这样的分布式集群有所了解，就会发现k8s的设计理念和其他分布式架构的非常类似的：Master节点负责接收用户的指令、分配任务以及记录各个node的情况；而node节点负责接收Master的指令，启动相应的Pod（k8s的最小执行单元，是一个Container的集合)。
安装k8s时会指定Master和Node节点，部署好之后，我们通过k8s的api与Master节点进行交互。Master节点收到了我们的指令(比如新启动一个Pod)，会调度Node节点去完成它们。当然，其中底层的调度策略、具体的实现细节对于我们使用者来说都是隐蔽的，不需要我们去了解。
Container : 容器。由于k8s是容器管理平台，因此如果你使用k8s管理Docker的容器的话，那么这里的Container就是Docker的Container。作为启动一个组件的最小单元（比如我可以用一个Container启动一个mysql ，另一个Container启动一个tomcat。而mysql和tomcat的各种配置文件都在它们自己的Container中，因此不会相互干扰，也不会污染linux主机的配置环境。）。
Pod : 一组Container的集合，是k8s中最小的执行单元。由于一个服务往往是要基于许许多多的组件才能完成的，因此一个Pod就是“能够完整运行这个服务”的最小个体，也是k8s将其指定为原子单元的初衷（比如我要启动一个简单的网站服务，至少需要一个tomcat、一个mysql以及我自己编写的网站业务流程程序。因此在k8s中，我就会启动一个Pod，这个Pod中包含三个Container，每个Container包含了它们相应的组件。）。每个Pod中的所有Container是共享IP地址和文件系统的，这点要特别注意。
原意是“豌豆荚”，我觉得这个比喻很形象。每个容器就像豌豆一样，而Pod就像豌豆荚一样把它们包住，使之成为一个整体。
ReplicaSet : 用于指定每个Pod的备份数量。由于k8s采用的是分布式架构，为了保证高可靠性，万一哪台node节点突然宕机了，也必须要保证我的网站服务能够正常运行；因此，每个Pod都会被复制成3份(默认设置3份)，运行在不同的node节点上。ReplicaSet就是用来管理Pod备份数量，保证高可靠性的组件。
Service : 用于各种信息的抽象（这是个抽象概念，理解起来比较难，回头我再总结一个k8s的工作流程，大家就能更清楚地理解啦）。
Label : 每个Pod的唯一标识符，信息会存在etcd数据库中。Service就是通过这个识别各个Pod谁是谁的。就像工号一样。
kubelet : 每个node节点都有一个，用于启动、管理和监测各个node中Pod。k8s会将所有的容器信息记录在etcd数据库中，kubelet就是不断地去数据库中查看这些Pod的信息，保证其与node中实际运行的情况相同。我的理解，kubelet就类似于每个工地里工头儿的角色，负责具体派活儿和监督。
kube-proxy : 在k8s中，每个node都用自己的一个IP地址。而kube-proxy就是负责每个node与其他node或Matser节点通信的枢纽。信息的流入和流出、请求的转发都是通过kube-proxy进行操作的。
以上，就是k8s中的一些基本概念。由于是初学k8s，其中部分概念包含了我自己的个人理解，如果有错误欢迎各位大牛在留言区批评指正。谢谢！