Kubernetes是Google严格保密十几年的秘密武器——Borg的一个开源版本。（go语言开发）
Borg是Google的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨过个数据中心资源利用率的最大化。
十几年以来，Google一直通过Borg系统管理者数据庞大的应用程序集群，由于Google员工都签署了保密协议，即使离职也不能泄露Borg的内部设计，所以外界一直无法了解关于它的更多信息。
直到2015年4月，传闻许久的Borg论文发布，伴随着Kubernetes的高调宣传被Google首次公开，大家才得以了解它的更多内幕。正式由于站在Borg这个前辈的肩膀上，汲取了Borg过去十年间的经验与教训，所以Kubernetes一经开源就一鸣惊人，并迅速称霸容器领域。
二. Kubernetes是什么Kubernetes，又称为 k8s（首字母为 k、首字母与尾字母之间有 8 个字符、尾字母为 s，所以简称 k8s）或者简称为 "kube" ，是一种可自动实施 Linux 容器操作的开源平台
它可以帮助用户省去应用容器化过程的许多手动部署和扩展操作。也就是说，使用者可以将运行 Linux 容器的多组主机聚集在一起，由 Kubernetes 轻松高效地管理这些集群，这些集群可跨公共云、私有云或混合云部署主机。因此，对于要求快速扩展的云应用而言，Kubernetes 是理想的容器托管平台
三. Kubernetes相关术语这里只做简单介绍，后续文章会对组件做详细说明
● 主机(Master)
用于控制整个Kubernetes集群。所有任务、节点分配都由主机去控制管理
● 节点(node)
负责执行请求和分配所有任务的节点。由Kubernetes主机对节点进行控制
● 容器集(Pod)
部署在node节点上，且包至少含一个或多个容器。同一个容器集中的所有容器共享同一个IP地址、主机名以及其他资源
● 复本控制器(Replication Controller)
用于控制应在集群某处运行的完全相同的容器集副本数量
● 服务(Service)
将工作内容与容器集进行隔离。Kubernetes服务代理会自动将服务请求分发到某个容器集上
● kubectl
Kubernetes的命令行配置工具
● kubelet
负责node节点与master节点进行通信，同时管理本机的容器集，负责维护容器集的生命周期
四. Kubernetes的优势● 批量编排
之前了解的docker编排工具docker-compose有一个局限性，只能在本地去创建一个容器实例，当在另一台服务器上去创建相同的实例时，需要copy docker-compse文件才能创建；kubernetes解决了单机编排的局限性，能够跨多台主机进行容器编排
● 资源利用
当一个应用有多个副本时，Kubernetes会通过自身的算法将每个应用pod分布在每个node节点上，优先选择物理资源使用率最低的那一台去部署
举个例子。2台node节点，A模块2个副本，则每个node上各有1个A模块pod；B模块4个副本，则每个node上各有2个B模块副本；也就是说每个node上各有3个pod在运行
● 服务透明
客户端访问业务时，只需要访问service ip或name或service的上游代理，如nginx、haproxy等；不需要去关心后端有几个服务、每个服务的状态信息
● 负载均衡
Kubernetes有service这个组件，提供pod请求分发功能(实际是由kube-proxy实现)，具体通过什么策略进行请求分发还需深入调研
● 故障自愈
当运行的pod异常停止或误操作删除时，Kubernetes会通过定义的描述信息将pod运行到期望值
● 弹性伸缩
支持部署后集群节点扩容以及 Pod 动态的横向伸缩，保证集群和资源的高可用和可靠性
● 动态变更
可以在线动态去变更应用的运行资源，如占用物理内存大小、使用物理cpu个数等。简要说明就是热加载配置
● 健康检测
Kubernetes提供了几种健康状态检测功能，术语叫探针。会根据自定义检测方式以及应对处理策略来对pod进行一系列操作
为什么要使用Docker，而不是Kubernetes。当我们在谈论容器技术时，其实重点是Linux内核技术。如果你希望在项目中使用容器，那么应该对Linux有一点经验。Docker容器整合了cgroups技术，提供了一个更理想的工具集，实现了container的资源的隔离和控制
笔者认为Kubernetes这项技术并不适用于小型公司，更不适合单个web项目的运营。尽管，理论上也能用，但是会"大材小用"，就像我们不会乘着火箭去度假一样。当然，笔者不是否定Kubernetes，这是一项很赞、还免费的技术，但是并不是所有的技术都适合自己。Kubernetes更适用于一个架构庞大、迭代频繁且应用不断增长的环境
另外，相比Kubernetes，构建一个轻量级Docker群集环境更容易，组件的维护也不需要那么复杂，上手程度更简易些
六. Kubernetes 为什么这么难笔者认为难主要因为复杂性太高，技术本身就有很高的门槛，有着一定的应用、维护难度
● 多机器
Kubernetes 是一个分布式系统，有一台控制工作机器的主机器，工作被安排在不同的工作机器上。然后，每台机器在容器中运行工作。原本2-3台可以搞定的事情需要4-6台机器或者是更多的机器(按理说生产上不允许出现单点或伪集群的应用)
● 复杂性
Kubernetes 是一个复杂的系统，包含许多不同的服务、系统和部件。需要了解他们是什么关系，承载了什么功能，相互之间又有什么联系。笔者在想，在真正的生产应用业务中，这些功能都需要用到吗？即使用到，得到的效果也是微乎其微，投入的人力、时间与得到的收益不成正比
● 可靠性
运行的组件越多，就意味着出错机会越多，需要深入理解每个组件，他们分别承担了什么功能、各自存在的意义是什么、每个组件之间是否有关联等等
Kubernetes 内置了很多特性（健康检查、滚动部署、configMap等）,可以使得可靠性变得更简单，例如，Nginx 可以对工作进程执行健康检查，使用 restart 或类似的策略自动重启进程
如果你关心的是停机时间，那么第一个想法不应该是"如何将部署停机时间从 1 秒减少到 1 毫秒"，而应该是"如何确保数据库模式更改不会妨碍我在事情搞砸时进行回滚"
如果你只是想要一个可靠的 Web 工作平台，不存在单机故障点，那么有很多方法可以做到这一点，不必使用 Kubernetes
● 实用性
不要以为部署一个3节点的kubernetes集群或者通过kubernetes部署一个nginx集群就觉得自己已经熟练使用kubernetes了；这是学习了解kubernetes的必经之路，让自己初体验kubernetes的优势，了解他的功能、特点
对pod标签定义、基本用法、数据持久化、配置管理、监控机制、service、ingress、安全机制、ns资源隔离、heml等一系列功能需要深入理解、实践
Kubernetes是万事开头难、然后中间难、最后结尾难；虽然 Kubernetes 部署、使用、维护很难，但只要开始就很难放弃，如果决定在生产上使用 Kubernetes，一定需要持续优化建设，因为你不知道他到底会出现什么事故