kubernetes是Google的一个大规模容器管理技术的开源版本，可能大部分初学者是学习docker的过程中认识到kubernetes的，kubernetes确实也能很简单的集成docker，但是，docker只是kubernetes支持的容器之一，并不是只有docker才能与kubernetes集成，只不过因为docker比较流行所以优先使用docker。

那么为什么会有这个kubernetes呢？这与第一句介绍有关：kubernetes是一个大规模容器管理技术的开源版本，也就是说kubernetes是为了管理大规模容器集群的技术，因为当容器多到一定程度后，手动一个个管理就比较麻烦了，耗时耗力，这时就有了众多的容器管理解决方案，方便管理大量的容器，而kubernetes则是其中比较优秀的一个，所以使用者也就比较多了。

kubernetes中增加了很多新名词、新概念，新手起初看的时候可能会头晕，感觉乱，下面就来介绍一下kubernetes中的几个重要概念。

首先是Pod，在kubernetes中，最小的管理单位是Pod而不是docker或其他容器的实例，一个Pod可以包含多个容器，而Pod则对这些容器进行统一管理。

在kubernetes集群中，各个Pod都拥有一个虚拟的IP，该IP会在Pod创建后由kubernetes随机分配，这个IP外部无法直接访问，而在kubernetes内部则是互通的，相当于一个虚拟局域网络。

一个Pod如果想要对外提供服务，则需要开放端口（也可以通过其他方式解决，这是官方提供的方式），Pod的ClusterIP+端口号就组成了一个Endpoint，该Endpoint对外提供服务，而一个Pod可以开放多个端口，也就是可以对应多个Endpoint。如果想要该Endpoint可以对kubernetes集群外的客户端提供服务，那只需要绑定一个本机端口即可。

在kubernetes中，直接编写一个Pod配置文件并发布到kubernetes集群是允许的，但是这相比直接部署docker容器并没有什么优势，而kubernetes提供了一种更优优势的方案，那就是通过Pod管理器去管理Pod，在较早的版本中使用的是ReplicationController（后称RC），在新版本中则提供了Deployment，本文不对比两种方案的优劣，只通过RC来介绍该方案的优势。

使用RC你可以通过配置文件来完成对Pod数量的控制，只需要在RC文件中指明你需要10个某个Pod的实例，那么RC会自动帮你部署好10个指定Pod的实例，省去了一大笔部署时间，而当其中某个Pod挂掉后，如果是直接部署的Pod，那么就需要手动去重启了，而且还不一定能实时监控到Pod的健康状态，但是通过RC去部署Pod，当Pod挂掉后RC会自动重新部署一个Pod来保证Pod的总数不变。

在kubernetes内网中，调用一个服务可以通过Pod的clusterIP+port的方式调用，但是由于Pod的clusterIP是在Pod创建后随机分配的，也就是无法提前得知Pod的clusterIP，同时Pod有可能被重建，当Pod被重建后IP也会随之变化，这样就造成一个问题，kubernetes也提供了使用环境变量的方法解决，也就是当Pod创建完后会加一条环境变量保存Pod的IP，其他服务调用方可以通过环境变量获取该Pod的IP，进而调用服务，但是以上方式有一些明显的缺点，需要写死IP，但是当Pod重建后之前写死的IP就会失效，如果通过环境变量获取，那么由于Pod可能重建，所以需要每次使用都重新获取，比较麻烦，所以kubernetes提供了Service的概念解决了该问题。

对于一个服务，可以写一个Service统一对外提供服务，Service的IP是固定不变的，同时Service不仅解决了Pod的IP无法确定的问题，如果有多个Pod提供同一服务，那么通过Service还可以为这些Pod做负载均衡，Service会根据指定负载均衡策略去将请求分发到不同的Pod中。

有了Service就可以通过IP去调用服务了，但是Service的IP不容易记忆，那怎么办？kubernetes同时还提供了一套完善的DNS服务，通过DNS服务，你可以通过Service的名称调用到服务，而DNS服务则会将Service的名称转换为Service的IP。

在kubernetes中，一个Node对应一个主机或者一个虚拟机，Node是Pod的载体，所有Pod都在Node里边部署。当扩展主机时，只需要增加一些配置，该主机就可以自动被kubernetes的master发现并配置为一个Node，供后续部署Pod使用，扩容起来十分的快。