Kubernetes是容器集群管理系统，是一个开源的平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
通过Kubernetes你可以
1.快速部署应用。
2.快速扩展应用
3.无缝对接新的应用功能。
4.节省资源，优化硬件资源的使用。
我们的目标是促进完善组件和工具的生态系统。以减轻应用程序在公有云或私有云中运行的负担。
为什么要使用容器？通过以下两个图对比：
传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行，配置，管理，所有的生命周期将与当前的操作系统绑定，这样做不利于应用的升级更新回滚操作，
当然也可以通过虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可一致性。
新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。
容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚机轻量、更“透明”，这更便于监控和管理。最后，
容器优势总结:
快速创建/部署应用:与VM虚拟机相比，容器创建更加容易。
可以在物理或虚拟机的Kubernetes集群上运行容器化应用，Kubernetes能提供一个以“容器为中心的基础架构”，满足在生产环境中运行应用的一些常见需求，如：
1 Master 组件 1.1 kube-apiserver 1.2 ETCD 1.3 kube-controller-manager 1.4 cloud-controller-manager 1.5 kube-scheduler 1.6 插件 addons 1.6.1 DNS 1.6.2 用户界面 1.6.3 容器资源监测 1.6.4 Cluster-level Logging 2 节点（Node）组件 2.1 kubelet 2.2 kube-proxy 2.3 docker 2.4 RKT 2.5 supervisord 2.6 fluentd
Master组件提供集群的管理控制中心。
Master组件可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器
kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行
etcd是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划
kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。
kube-scheduler 监视新创建没有分配到Node的Pod，为Pod选择一个Node。
插件（addon）是实现集群pod和Services功能的 。Pod由Deployments，ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中创建。
虽然不严格要求使用插件，但Kubernetes集群都应该具有集群 DNS。
群集 DNS是一个DNS服务器，能够为 Kubernetes services提供 DNS记录。
由Kubernetes启动的容器自动将这个DNS服务器包含在他们的DNS searches中。
节点组件运行在Node，提供Kubernetes运行时环境，以及维护Pod。
kubelet是主要的节点代理，它会监视已分配给节点的pod，具体功能：
kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象。
docker用于运行容器。
supervisord是一个轻量级的监控系统，用于保障kubelet和docker运行。
fluentd是一个守护进程，可提供cluster-level logging.。
1 了解Pod 1.1 Pods如何管理多个容器 1.1.1 网络 1.1.2 存储 2 使用Pod 2.1 Pod和Controller 3 Pod模板
Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。
Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。
Pods的设计可用于支持多进程的协同工作（作为容器），形成一个cohesive的Service单位。Pod中的容器在集群中Node上被自动分配，容器之间可以共享资源、网络和相互依赖关系，并同时被调度使用。
每个Pod被分配一个独立的IP地址，Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。Pod内的容器可以使用localhost相互通信。当Pod中的容器与Pod 外部通信时，他们必须协调如何使用共享网络资源（如端口）。
Pod可以指定一组共享存储volumes。Pod中的所有容器都可以访问共享volumes，允许这些容器共享数据。volumes 还用于Pod中的数据持久化，以防其中一个容器需要重新启动而丢失数据
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。
Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。
包含一个或者多个Pod的Controller示例：
Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector
一个 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样， Service 定义可以基于 POST 方式，请求 apiserver 创建新的实例。 例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 "app=MyApp" 标签。
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
原文：https://www.cnblogs.com/jacksonxiao/p/11461474.html