k8s组件
k8s是一个来自google的开源项目，用于统一管理处理容器化的应用。
k8s，负责在大规模的服务器环境中，部署和管理容器组，用于解决掉容器的复制，扩展，健康，启动，负载均衡。
k8s 由众多组件组成，组件间通过 API 互相通信，归纳起来主要分为三个部分：
- controller manager
- nodes
- pods
- Controller Manager，即控制平面，用于调度程序以及节点状态检测。
- Nodes，构成了Kubernetes集群的集体计算能力，实际部署容器运行的地方。
- Pods，Kubernetes集群中资源的最小单位。
硬件
集群(Cluster)
对于大型系统，我们往往不会把关注点放在单个机器上，而是聚焦更大粒度的集群。
在k8s中，一般将集群看做一个整体，而不关心内部节点的状态，集群内部状态的调整将由k8s自动完成。
这个集群主要包括两个部分：
- 一个Master节点（主节点）
- 一群Node节点（计算节点）
Master节点主要还是负责管理和控制。Node节点是工作负载节点，里面是具体的容器。
Master节点
集群控制节点，每个kubernetes集群里都需要有一个Master节点来负责整个集群的管理和控制，基本上kubernetes的所有控制命令都发给它，它来负责具体的执行过程。
Master节点通常会占据一个独立的服务器(高可用建议用3台服务器)，主要原因就是他太重要了，是整个集群的“首脑”。
Master节点包括API Server、Scheduler、Controller manager。
- kubernetes API Server（kube-apiserver） ：资源操作（增、删、改、查）的唯一入口，接收用户输入的命令（提供了HTTP Rest接口的关键服务进程），提供认证、授权、Api 注册和发现等机制
- kubernetes Scheduler（kube-scheduler）：负责集群资源调度，按照预定的调度策略将 pod 调度到相应的 node 节点上
- kubernetes Controller Manager（kube-controller-manager）：负责维护集群的状态，比如程序部署安排，故障检测，自动扩展，滚动更新等。负责资源调度（pod调度）的进程，相当于公交公司的 “调度室”
- Etcd：负责存储集群中各种资源对象的信息
Node节点
集群的数据平面，负责为容器提供运行环境（干活）。
Node是k8s中最小的计算硬件单元，它类似于传统集群中单台机器的概念，是对硬件物理资源的一层抽象，它可以是真实机房的物理机器，又或者是云平台上的ECS，甚至可以是边缘计算的一个终端。
无论如何，借助Node的抽象，我们可以把任何一台机器简单的看做是一组CPU和RAM资源的组合，从而达到解耦的效果。
每个Node节点上都运行着以下关键进程：
- kubelet：负责Pod对应的容器的创建、启停等任务，同时与master节点密切协作，实现集群管理的基本功能
- kube-proxy：实现kubernetes Service的通信与负载均衡机制的重要组件
- Docker Engine（docker）：Docker引擎，负责本机的容器创建和管理工作
除了master，kubernetes集群中的其他机器被称为Node节点。与master一样，Node可以是物理机也可以是虚拟机，Node节点才是kubernetes集群中的工作负载节点，每个Node节点都会被master分配一些工作负载（docker容器）。
Node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选），还有就是Pod。
Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程，它内部封装了一个或多个紧密相关的容器。除了Pod之外，K8S还有一个Service的概念，一个Service可以看作一组提供相同服务的Pod的对外访问接口。
Fluentd，主要负责日志收集、存储与查询。
Node节点可以在运行期间动态增加到kubernetes集群中，前提是这个节点上已经正确安装、配置和启动了以上关键进程。在默认情况下，kubelet会向master注册自己，这也是官方所推荐的Node管理方式。一旦Node被纳入集群管理范围，kubelet进程就会定时向master节点汇报自身情况，例如操作系统、docker版本、CPU和内存情况，以及当前有哪些Pod在运行等，这样master就可以知道每个Node的资源使用情况，并实现高效均衡的资源调度策略，长时间失联的Node会被标记为不可用 “Not ready”，随后master会触发 “负载转移”的自动流程
持久卷(Persistent Volumes)
考虑到集群内部的节点始终在发生调度和变动，所以所有节点内部的文件系统都是易失的，无法保证持久，为了解决这一问题，k8s引入了持久卷的概念，用于映射实际的物理储存节点（云盘或者是物理磁盘），它可以随时被挂载到任何的集群上去。
软件
容器(Container)
容器是打包好的运行环境，这点无需再多赘述。值得一提的是k8s中的容器支持不仅仅包含了docker，还支持一些其他的容器标准
Pod
这是k8s区别于其他容器编排平台的一个显著特点：它不直接运行容器，而是运行一种称为Pod的高级结构，里面封装了一系列相关的容器，并共享相同的namespace和网络。
Pod也是k8s进行服务编排和缩扩容的基本单位，这意味着Pod里所有的容器都会被一并缩放(不管是否有必要)，因此定制Pod时应该使它的体积尽可能小一些。
另外还有一个和Pod相关的概念，就是副本集(Replica Sets)，它是指在扩容时产生的Pod的复制
我们可以把上面几个逻辑概念的关系用下图表示：
部署(Deployment)
deployment是用于管理pod的抽象层，它的定位类似于docker-compose。
k8s一个很巧妙的地方在于它把deployment层设计成“过程无关”的，你只需要声明你所期望的最终状态，k8s将会自动为你调度pod并保证它们满足你的预期。
入口(Ingress)
使用上面描述的概念，你可以创建一个节点集群，并将Pod部署到集群上。不过，还有一个问题需要解决：允许外部通信流进入你的应用程序。
默认情况下，Kubernetes提供隔离舱和外部世界。如果你想要与运行在Pod中的服务通信，你必须打开一个通信通道。称作入口(ingress)。
有多种方法可以将入口添加到集群中。最常见的方法是添加入口控制器或负载均衡器。这两个选项之间的精确权衡超出了本文的范围，但是你必须知道，在你可以与Kubernetes进行实验之前，你需要处理的是入口。