随着容器化技术的广泛应用，业界相继出现了包括Mesos、swarm等容器编排调度方案。经过了这些年的发展，如今我们基本可以说 Kubernetes技术已成为容器编排调度方案的事实标准。
Kubernetes发展
Kubernetes是Google容器集群管理系统Borg的开源实现，用Go语言开发
- 2014年6月发布第一个版本；
- 2018年9月发布1.12版本；
- 实现对容器的集群管理：
- 配置管理：包括服务发现、负载均衡及依赖管理
- 调度及生命周期管理
- 目前支持5000节点以上，50000个服务
- CNCF的核心项目（已宣布毕业）
其核心架构如下：
Kubernetes旨在消除编排物理/虚拟计算、网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在 以容器为中心的基础上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的workflows 和更高级的自动化任务。
Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。
接下来我们一一讲解Kubernetes的核心技术概念：
Master节点组件
- etcd 保存了整个集群的状态
- apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制
- controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
- scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
- kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
- Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
- kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；
插件 addons：
- kube-dns负责为整个集群提供DNS服务
- Ingress Controller为服务提供外网入口
- Heapster提供资源监控
- Dashboard提供GUI
- Federation提供跨可用区的集群
- Fluentd-elasticsearch提供集群日志采集、存储与查询
Node节点组件
- kubelet是主要的节点代理，它会监视已分配给节点的pod
- kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象
- docker用于运行容器
Pod
复制控制器（Replication Controller，RC）
RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的Web服务。
副本集（Replica Set，RS）
RS是新一代RC，提供同样的高可用能力，区别主要在于RS后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理想状态参数使用
部署(Deployment)
部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。
有状态服务集（PetSet）
K8s在1.3版本里发布了Alpha版的PetSet功能。RC和RS主要是控制提供无状态服务的，其所控制的Pod的名字是随机设置的，一个Pod出故障了就被丢弃掉，在另一个地方重启一个新的Pod，名字变了、名字和启动在哪儿都不重要，重要的只是Pod总数；而PetSet是用来控制有状态服务，PetSet中的每个Pod的名字都是事先确定的，不能更改。
服务（Service）
在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。
Kube-proxy
Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
Volumes:
- Pod生命周期内可一直可用
- Pod内容器共享
- 当前支持的类型
- emptyDir：Pod与Node绑定与解绑时创建/删除
- HostPath：挂载Node上的目录，允许 挂载Node上的文件系统到Pod里面去。如果Pod需要使用Node上的文件，可以使用hostPath
- NFS：通过简单地配置就可以挂载NFS到Pod中，而NFS中的数据是可以永久保存的，同时NFS支持同时写操作。Pod被删除时，Volume被卸载，内容被保留
- Glusterfs：允许将Glusterfs Volume安装到pod中。不同于emptyDir，Pod被删除时，Volume只是被卸载，内容被保留
K8s支持非常多的存储卷类型，包括支持多种公有云平台的存储，包括AWS，Google和Azure云；支持多种分布式存储包括GlusterFS和Ceph；也支持较容易使用的主机本地目录hostPath和NFS。
K8s还支持使用Persistent Volume Claim即PVC这种逻辑存储，使用这种存储，使得存储的使用者可以忽略后台的实际存储技术，而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。
网络机制
Docker网络基础
单机网络模式：Bridge 、Host、Container、None。
多机网络模式：一类Docker在1.9版本中引入Libnetwork项目，对跨节点网络的原生支持；一类是通过插件（plugin）方式引入的第三方实现方案，比如Flannel，Caicos等等
Kubernetes网络基础
同一个Pod的容器共享同一个网络命名空间，它们之间的访问可以用localhost地址+容器端口就可以访问。
同一个Node中Pod的默认路由都是docker0的地址，由于它们关联在同一个docker0网桥上，地址网段相同，所有它们之间应当是能直接通信的。
不同Node中Pod间通信要满足2个条件：Pod的IP不能冲突；将Pod的IP和所在的Node的IP关联起来，通过这个关联让Pod可以互相访问。
