定义：

k8s是为容器服务而生的一个可移植容器的编排管理工具。通过管理逻辑容器来代替管理物理容器

背景与重要性：

Docker是应用最为广泛的容器技术，通过打包镜像，启动容器来创建一个服务。但是随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题，而且随着云计算的发展，云端最大的挑战，容器在漂移。在此业务驱动下，k8s问世。

解决的问题：

1. 服务发现与调度
2. 负载均衡
3. 服务自愈
4. 服务弹性扩容
5. 横向扩容
6. 存储卷挂载

架构：

Master节点

Master节点指的是集群控制节点，管理和控制整个集群，基本上k8s的所有控制命令都发给它，它负责具体的执行过程。在Master上主要运行着：

1. Kubernetes Controller Manager（kube-controller-manager）：k8s中所有资源对象的自动化控制中心，维护管理集群的状态，比如故障检测，自动扩展，滚动更新等。
2. Kubernetes Scheduler（kube-scheduler）： 负责资源调度，按照预定的调度策略将Pod调度到相应的机器上。
3. etcd：保存整个集群的状态。

Node节点

除了master以外的节点被称为Node或者Worker节点，可以在master中使用命令 kubectl get nodes查看集群中的node节点。每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，该节点上的工作负载就会被Master自动转移到其它节点上。在Node上主要运行着：

1. kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能
2. kube-proxy：实现service的通信与负载均衡
3. docker（Docker Engine）：Docker引擎，负责本机的容器创建和管理

相关概念

控制平面组件

控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件.

控制平面组件可以在集群中的任何节点上运行，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。

API 服务器是 Kubernetes 控制面的前端

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

kube-scheduler负责监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。

kube-controller-manager运行控制器进程的控制平面组件。从逻辑上讲，每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。

节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应

任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成

端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)

服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

Node 组件

kubelet是一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。

kube-proxy是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分

容器运行环境是负责运行容器的软件。Kubernetes 支持多个容器运行环境: Docker、 containerd、CRI-O 以及任何实现 Kubernetes CRI

Kubernetes 对象

几乎每个 Kubernetes 对象包含两个嵌套的对象字段：spec和status，spec必须在创建对象时设置其内容，描述你希望对象所具有的特征；status 描述了对象的 当前状态（Current State），它是由 Kubernetes 系统和组件设置并更新的。 在任何时刻，Kubernetes 控制平面 都一直积极地管理着对象的实际状态，以使之与期望状态相匹配。

Pods

是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。可以运行在某个节点上。Pod 所建模的是特定于应用的“逻辑主机”，包含一个或多个应用容器，Pod 中的容器被自动安排到集群中的同一物理机或虚拟机上，并可以一起进行调度。

每个 Pod 都旨在运行给定应用程序的单个实例。

控制器

在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。

Kubernetes 内置一组控制器，运行在 master的kube-controller-manager 内。

Kubernetes API

Kubernetes API 使你可以查询和操纵 Kubernetes 中对象的状态。 Kubernetes 控制平面的核心是 API 服务器和它暴露的 HTTP API。 用户、集群的不同部分以及外部组件都通过 API 服务器相互通信。

Job

Job 是一种 Kubernetes 资源，它运行一个或者多个 Pod， 来执行一个任务然后停止。 Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是通知 API 服务器来创建或者移除 Pod。

Server

配置 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP） 和 Port 的请求，并重定向到代理端口，代理端口再代理请求到后端Pod。

当每个 Service 创建时，会被分配一个唯一的 IP 地址（也称为 clusterIP）。 这个 IP 地址与一个 Service 的生命周期绑定在一起，当 Service 存在的时候它也不会改变。

在Kubernetes中通过定义Service（服务）来解决集群内应用通信的问题。Service在Kubernetes集群内扮演了服务发现和负载均衡的作用。在Kubernetes下部署的Pod实例都会包含一组描述自身信息的Lable，而创建Service，可以声明一个Selector（标签选择器）。Service通过Selector，找到匹配标签规则的Pod实例，并将对Service的请求转发到代理的Pod中。Service创建完成后，集群内的应用就可以通过使用Service的名称作为DNS域名进行相互访问。

卷

在 .spec.volumes 字段中设置为 Pod 提供的卷，并在 .spec.containers[*].volumeMounts 字段中声明卷在容器中的挂载位置。

volumeMounts.subPath 属性可用于指定所引用的卷内的子路径，而不是其根路径。

挂载卷的传播能力允许将容器安装的卷共享到同一 Pod 中的其他容器， 甚至共享到同一节点上的其他 Pod。

ConfigMap

如果 Pod 中有多个容器，则每个容器都需要自己的 volumeMounts 块，但针对 每个 pod，你只需要设置一个 spec.volumes 块。

PersistentVolumeClaims

独立于 Pod 生命周期而在 Pod 重启，重新调度甚至删除过程中保存数据。

#每个Kubernetes对象有一个UID 来标识其在整个集群中的唯一性。

#标签（Labels）是附加到Kubernetes对象（比如 Pods）上的键值对。可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。