Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes 提供了应用部署，规划，更新，维护的一种机制。
Kubernetes 一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让 apache 一直运行，用户不需要关心怎么去做，Kubernetes 会自动去监控，然后去重启，新建，总之，让 apache 一直提供服务），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes 也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用（就像 canary deployments）。
现在 Kubenetes 着重于不间断的服务状态（比如 web 服务器或者缓存服务器）和原生云平台应用（Nosql）, 在不久的将来会支持各种生产云平台中的各种服务，例如，分批，工作流，以及传统数据库。
在 Kubenetes 中，所有的容器均在 Pod 中运行, 一个 Pod 可以承载一个或者多个相关的容器，在后边的案例中，同一个 Pod 中的容器会部署在同一个物理机器上并且能够共享资源。一个 Pod 也可以包含 O 个或者多个磁盘卷组（volumes）, 这些卷组将会以目录的形式提供给一个容器，或者被所有 Pod 中的容器共享，对于用户创建的每个 Pod, 系统会自动选择那个健康并且有足够容量的机器，然后创建类似容器的容器, 当容器创建失败的时候，容器会被 node agent 自动的重启, 这个 node agent 叫 kubelet, 但是，如果是 Pod 失败或者机器，它不会自动的转移并且启动，除非用户定义了 replication controller。
用户可以自己创建并管理 Pod,Kubernetes 将这些操作简化为两个操作：基于相同的 Pod 配置文件部署多个 Pod 复制品；创建可替代的 Pod 当一个 Pod 挂了或者机器挂了的时候。而 Kubernetes API 中负责来重新启动，迁移等行为的部分叫做 “replication controller”，它根据一个模板生成了一个 Pod, 然后系统就根据用户的需求创建了许多冗余，这些冗余的 Pod 组成了一个整个应用，或者服务，或者服务中的一层。一旦一个 Pod 被创建，系统就会不停的监控 Pod 的健康情况以及 Pod 所在主机的健康情况，如果这个 Pod 因为软件原因挂掉了或者所在的机器挂掉了，replication controller 会自动在一个健康的机器上创建一个一摸一样的 Pod, 来维持原来的 Pod 冗余状态不变，一个应用的多个 Pod 可以共享一个机器。
我们经常需要选中一组 Pod，例如，我们要限制一组 Pod 的某些操作，或者查询某组 Pod 的状态，作为 Kubernetes 的基本机制，用户可以给 Kubernetes Api 中的任何对象贴上一组 key:value 的标签，然后，我们就可以通过标签来选择一组相关的 Kubernetes Api 对象，然后去执行一些特定的操作，每个资源额外拥有一组（很多） keys 和 values, 然后外部的工具可以使用这些 keys 和 vlues 值进行对象的检索，这些 Map 叫做 annotations（注释）。
Kubernetes 支持一种特殊的网络模型，Kubernetes 创建了一个地址空间，并且不动态的分配端口，它可以允许用户选择任何想使用的端口，为了实现这个功能，它为每个 Pod 分配 IP 地址。
现代互联网应用一般都会包含多层服务构成，比如 web 前台空间与用来存储键值对的内存服务器以及对应的存储服务，为了更好的服务于这样的架构，Kubernetes 提供了服务的抽象，并提供了固定的 IP 地址和 DNS 名称，而这些与一系列 Pod 进行动态关联，这些都通过之前提到的标签进行关联，所以我们可以关联任何我们想关联的 Pod，当一个 Pod 中的容器访问这个地址的时候，这个请求会被转发到本地代理（kube proxy）, 每台机器上均有一个本地代理，然后被转发到相应的后端容器。Kubernetes 通过一种轮训机制选择相应的后端容器，这些动态的 Pod 被替换的时候, Kube proxy 时刻追踪着，所以，服务的 IP 地址（dns 名称），从来不变。
所有 Kubernetes 中的资源，比如 Pod, 都通过一个叫 URI 的东西来区分，这个 URI 有一个 UID，URI 的重要组成部分是：对象的类型（比如 pod），对象的名字，对象的命名空间，对于特殊的对象类型，在同一个命名空间内，所有的名字都是不同的，在对象只提供名称，不提供命名空间的情况下，这种情况是假定是默认的命名空间。UID 是时间和空间上的唯一。
Kubernetes 是什么？
Kubernetes 一个用于容器集群的自动化部署、扩容以及运维的开源平台。
通过 Kubernetes, 你可以快速有效地响应用户需求：
- 快速而有预期地部署你的应用
- 极速地扩展你的应用
- 无缝对接新的应用功能
- 节省资源，优化硬件资源的使用
我们希望培育出一个组件及工具的生态，帮助大家减轻在公有云及私有云上运行应用的负担。
Kubernetes 特点:
- 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
- 可扩展: 模块化, 插件化, 可挂载, 可组合
- 自愈: 自动布置，自动重启，自动复制，自动扩展
Kubernetes 始于 Google 2014 年的一个项目。 Kubernetes 的构建基于 Google 十多年运行大规模负载产品的经验，同时也吸取了社区中最好的意见和经验。
为什么要选择容器？
当容器技术这么热门的时候有是不是在疑惑为什么要选用这样的技术呢？
传统的应用部署方式是通过操作系统的包管理器来安装应用。然而这样做的一个劣势在于，它把应用的运行，配置，库和生存周期和机器的操作系统纠缠在一起。当然你可以通过创建虚机镜像的方式来获得可以预期的前滚和回滚操作，然而虚拟机太重量级并且不可移植。
新的方式是通过部署基于操作系统级别虚拟化的容器进行虚拟化而非通过硬件来进行虚拟化。这些容器之间相互隔离：它们有自己的文件系统，然而它们也无法看到彼此之间的进程，并且它们之间的计算资源也是有界限的。相较于虚拟机容器也更容易部署，并且因为它们是和底层设施和机器文件系统解耦的，它们可以在云和不同版本的操作系统间进行迁移。
因为容器小而快，一个应用可以被打包进一个容器映像。正是应用与容器镜像间一对一的关系解锁了容器的很多优点：
- 在 build 或者 release 的阶段（而非部署阶段）可以创建不变的容器镜像，因为每个应用都用和其他的应用栈相组合，也不依赖于生产环境基础设施。这使
- 容器比虚机要更加透明，这更便于监控和管理。尤其是因为窗口的进程的生命周期是被基础设施直接管理而不是被容器中的进程管理器隐藏起来管理。
- 因为一个容器包含一个应用，这让对容器的管理等同于对应用部署的管理。
总结一下容器的优点：
- 敏捷地应用创建和部署：相较于 VM 增加了容器镜像创建的效率。
- 持续开发，集成和部署：通过快速的回滚操作（因为镜像的稳定性）提供可靠的经常的容器镜像的创建和部署。
- 开发和运行相分离：在 build 或者 release 的阶段（而非部署阶段），使得应用和基础设施解耦。
- 开发，测试和生产环境的持续：在笔记本上可以像在云中一样的运行。
- 云和操作系统版本的可移植性：可以运行在 Ubuntu, RHEL, CoreOS, on-prem, Google Container Engine, 和任何其它的运行环境中。
- 应用为中心的管理：提升了虚拟化的层次，从虚拟硬件上运行操作系统的抽象到操作系统中应用逻辑资源的虚拟。
- 松耦合，分布式，弹性，自由的微服务：应用被打散成更小的，独立的小碎片并且可以动态地部署和管理——而非是一个在用途单一的庞大机器中运行的一个臃肿堆栈中。
- 资源隔离：可以预测的应用性能。
- 资源使用：高效。
为什么需要 Kubernetes，利用它又能做些什么呢？
Kubernetes 可以安排物理机或者虚拟机上运行的应用容器的使用。
当然它不只可以做这些。
为了充分发挥它的潜能，你需要剪断物理机虚拟机的束缚。
然而，一旦特定的容器不再局限于特定的主机，主机为中心的基础设施便不再适用了：组管理，负载均衡，自动扩展等。你需要的是以容器为中心的基础设施。而这正是 Kubernetes 所提供的。
Kubernetes 可以满足很多运行环境中应用的通用的需求，比如：
- 进程协同，利用复合应用保证应用和容器一对一的模型。
- 存储系统挂载
- 分发密钥
- 应用健康检测
- 应用实例复制
- 水平自动扩展
- 命名和发现
- 负载均衡
- 滚动更新
- 资源监控
- 日志访问
- 自检和调试
- 识别和认证
这为 PaaS 提供了 IaaS 层的便利，提供了基础设施提供者间的可移植性。
Kubernetes 是个什么样的平台呢？
尽管 Kubernetes 提供了很多功能，总有一些新的场景可以从这些功能中获益。特定的应用工作流可以提高开发者的开发速度。最新可以接受的组合常常需要强劲的大规模的自动化。这也是为什么 Kubernetes 构建以来为什么要做一个让应用的部署、扩展和管理更便捷的生态平台的原因。
Labels 让用户可以随心所欲地组织自己的资源。 Annotations 让用户可以给资源添加定制化的信息以充分使用自己的工作流，提供一种简单的管理工具。
此外，Kubernetes control plane 本身也是基于公布给开发者和用户相同 的一组 API。用户可以自己定开发自己的 controllers, schedulers 等。如果愿意，它们甚至可以用自己的 API 开发自己的 command-line tool.
这样的设计也让很多其它系统可以构建于 Kubernetes 之上。
Kubernetes 不是什么？
Kubernetes 不是一个传统的，包罗一切的 PaaS 系统。我们保留用户的选择，这一点非常重要。
- Kubernetes 不限制支持应用的种类。它不限制应用框架，或者支持的运行时语言，也不去区分 “apps” 或者 “services”。 Kubernetes 致力于支持不同负载应用，包括有状态、无状态、数据处理类型的应用。只要这个应用可以在容器里运行，那么它就可以在 Kubernetes 上很多地运行。
- Kubernetes 不提供中间件（如 message buses），数据处理框架（如 Spark），数据库 (如 Mysql)，或者集群存储系统 (如 Ceph)。但这些应用都可以运行于 Kubernetes。
- Kubernetes 没有一个点击即可用的应用市场。
- Kubernetes 不部署源码不编译应用。持续集成的 (CI) 工作流方面，不同的用户有不同的需求和偏好，因此，我们提供分层的 CI 工作流，但并不定义它应该怎么做。
- Kubernetes 允许用户选择自己的日志、监控和报警系统。
- Kubernetes 不提供可理解的应用配置语言 (e.g., jsonnet).
- Kubernetes 不提供或者任何综合的机器配置，维护，管理或者自愈系统。
另一方面，大量的 Paas 系统都可以运行在 Kubernetes 上，比如 Openshift, Deis, 和 Gondor。你可以构建自己的 Paas 平台，CI 集成。
因为 Kubernetes 运行在应用而非硬件层面，它提供了普通的 Paas 平台提供的一些通用功能，比如部署，扩展，负载均衡，日志，监控等。然而，Kubernetes 并非一个庞然大物，这些功能是可选的。
另外，Kubernetes 不仅仅是一个 “编排系统”；它消弥了编排的需要。”编排” 的定义是指执行一个预定的工作流：先做 A，之后 B，然后 C。相反地，Kubernetes 是由一系列独立的、可组合的驱使当前状态走向预想状态的控制进程组成的。怎么样从 A 到 C 并不重要：达到目的就好。当然也是需要中心控制的；方法更像排舞的过程。这让这个系统更加好用更加强大、健壮、 有弹性且可扩展。
Kubernetes 单词是什么意思呢? 为什么又叫 K8s?
Kubernetes起源于希腊语, 是”舵手”或者”领航员”的意思，是”管理者”和”控制论”的根源。 K8s是把用8代替8个字符”ubernete”而成的缩写。