Kubernetes [ koo-ber-nay'-tace ]
源于希腊语，词意为航海大师，缩写为 k8s, 8代表除了首尾 ks 之外中间还有8个字母。
Master
k8s 集群主节点，运行四个模块：
- apiserver 对外提供 Kubernetes REST API，是系统管理指令的统一入口，任何资源的 CURD 都要交给 apiserver 处理后再交给 etcd。kubectl 命令行内部就是对 kubernetes REST API 调用，是直接和 apiserver 交互的。
- schedule 负责调度 pod 到合适的 node 上，Kubernetes 提供了默认的调度算法，也保留了自定义算法的接口。
- controller manager 每个资源一般对应有一个控制器， 而 controller manager 负责管理这些控制器，比如：apiserver 创建完成一个 pod 后，apiserver 的工作就完成了，保证 pod 的状态始终跟我们的预期一致就是 controller manager 的工作。
- etcd 一个高可用的键值存储系统，Kubernetes 使用 etcd 来存储所有资源的状态，从而实现 Restful 的 API。
Node
每个 Node 节点主要由三个模块组成。
- kubelet
- kube-proxy 实现服务发现和反向代理功能，服务发现：kube-proxy 使用 etcd 的 watch 机制，监控集群中的 service 和 endpoint 对象数据的状态变化，并维护一个 service 到 endpoint 的映射关系，从而保证了后端 pod 的 IP 变化不会对访问者造成影响，另外 kube-proxy 还支持 session affinity。反向代理：kube-proxy 支持 TCP 和 UDP 的连接转发，默认基于 Round Robin 算法将客户端流量转发到与 service 对应的一组后端 pod 上。
- runtime 容器运行环境，目前支持 docker 和 rkt。
Pod
是 k8s 的基本操作单元，也是应用运行的载体，整个的 k8s 系统都是围绕 pod 展开的，比如：如何部署运行 pod，如何保证 pod 的数量，如何访问 pod， 同时 pod 是一个或多个相关容器的集合，提供了一种容器组合的模型，这个也是 k8s 创新之处。
在 docker 中，容器是最小的处理单元，CURD 的对象是容器，容器之间是隔离的，隔离是基于 Linux Namespace 实现的。而在 Kubernetes 中，pod 包含一个或者多个相关的容器，pod 可以认为是容器的一种延伸扩展，一个 pod 也是一个隔离体，而 pod 内部包含的一组容器又是共享的（包括 PID、Network、IPC、UTS）。除此之外，pod 中的容器可以访问共同的数据卷来实现文件系统的共享。
基本操作 (k = kubectl)：
- create
k create -f podName.yaml - get
k get podsk get pod podNamek describ pod podName - delete
k delete pod podName - update
k replace podName.yaml
PV (Persistent Volumes)
k8s 是容器编排平台，容器的运行本身不具备持久化能力，需要挂载外部存储资源才能保存状态和数据信息，目前支持 HostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、iSCSI、GlusterFS、RBD 等。
- HostPath 将容器宿主机上的文件系统挂在到 Pod 上，一般用于单几点测试开发使用，因为不在该宿主机上的 POD 无法访问到该类型的数据卷
-
EmptyDir 如果Pod配置了 EmpyDir 数据卷，在 Pod 的生命周期内都会存在，当 Pod 被分配到
Node 上的时候，会在 Node 上创建 EmptyDir 数据卷，并挂载到 Pod 的容器中。只要 Pod 存在， EmpyDir 数据卷都会存在（容器删除不会导致 EmpyDir 数据卷丟失数据），但是如果 Pod 的生命周期终结（Pod 被删除），EmpyDir 数据卷也会被删除，并且永久丢失。EmpyDir 数据卷非常适合实现 Pod 中容器的文件共享。Pod 的设计提供了一个很好的容器组合的模型，容器之间各司其职，通过共享文件目录来完成交互，比如可以通过一个专职日志收集容器，在每个 Pod 中和业务容器中进行组合，来完成日志的收集和汇总。 - 网络数据卷 k8s 提供了很多类型的数据卷以集成第三方的存储系统，包括一些非常流行的分布式文件系统，也有在 IaaS 平台上提供的存储支持，这些存储系统都是分布式的，通过网络共享文件系统，因此我们称这一类数据卷为网络数据卷。网络数据卷能够满足数据的持久化需求，Pod 通过配置使用网络数据卷，每次 Pod 创建的时候都会将存储系统的远端文件目录挂载到容器中，数据卷中的数据将被水久保存，即使 Pod 被删除，只是除去挂载数据卷，数据卷中的数据仍然保存在存储系统中，且当新的 Pod 被创建的时候，仍是挂载同样的数据卷。网络数据卷包含以下几种：NFS、iSCISI、GlusterFS、RBD（Ceph Block Device）、Flocker、AWS Elastic Block Store、GCE Persistent Disk.
PVC (Persistent Volumes Claim)
理解每个存储系统是一件复杂的事情，特别是对于普通用户来说，有时候并不需要关心各种存储实现，只希望能够安全可靠地存储数据。Kubernetes 中提供了 Persistent Volume 和Persistent Volume Claim 机制，这是存储消费模式。Persistent Volume 是由系统管理员配置创建的一个数据卷，它代表了某一类存储插件实现，而对于普通用户来说，通过 Persistent Volume Claim 可请求并获得合适的 Persistent Volume，而无须感知后端的存储实现。Persistent Volume 和 Persistent Volume Claim 的关系其实类似于 Pod 和 Node，Pod 消费 Node 资源，Persistent Volume Claim 则消费 Persistent Volume 资源。Persistent Volume 和 Persistent Volume Claim 相互关联，有着完整的生命周期管理：
- 准备 系统管理员规划或创建一批 Persistent Volume；
- 绑定 用户通过创建 Persistent Volume Claim 来声明存储请求，k8s 发现有存储请求的时候，就去查找符合条件的 Persistent Volume（最小满足策略）。找到合适的就绑定上，找不到就一直处于等待状态；
- 使用 创建 Pod 的时候使用 Persistent Volume Claim；
- 释放 当用户删除绑定在 Persistent Volume 上的 Persistent Volume Claim 时，Persistent Volume 进入释放状态，此时 Persistent Volume 中还残留着上一个 Persistent Volume Claim 的数据，状态还不可用；
- 回收 释放的 Persistent Volume 需要回收才能再次使用。回收策略可以是人工的也可以是 k8s 自动进行清理（仅支持NFS和HostPath）。
