一、MASTER
Kubernetes里的Master指的是集群控制节点，在每个Kubernetes集群里都需要有一个Master来负责整个集 群的管理和控制，基本上 Kubernetes的所有控制命令都发给它，它负责具体的执行过程，我们后 面执行的所有命 令基本都是在Master上运行的。 Master通常会占据一个独立的服务器（高可用部署建议用3台服务器），主要原因 是它太重要了，是整个集群的“首脑” ，如果它宕机或者不可用，那么对集群内容器应用的管理都将失效。
在Master上运行着以下关键进程:
Kubernetes API Server（kube-apiserver）：提供了HTTP Rest接口的关键服务进程，是Kubernetes里所有 资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
Kubernetes Controller Manager（kube-controller-manager）： Kubernetes里所有资源对象的自动化控 制中心，可以将其理解为资源对象的“大总管”。
Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程，相当于公交公司的“调度 室”。
另外，在Master上通常还需要部署etcd服务，因为Kubernetes里的所有资源对象的数据都被保存在etcd中。
二、NODE
与Master一样， Node可以是一台物理主机，也可以是一台虚拟机。 Node是Kubernetes集群中的工作负载节 点，每个 Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上。
在每个Node上都运行着以下关键进程：
kubelet：负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能。
kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件。
Docker Engine（docker）： Docker引擎，负责本机的容器创建和管理工作。
三、POD
Pod是Kubernetes最重要的基本概念，如下图所示是Pod的组成示意图，我们看到每个Pod都有一个特殊的被称为“根容器” 的Pause容器。 Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod 还包含一个或多个紧密相关的用户业务容器。
四、LABEL
Label（标签）是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以被附加到各种资源对象上，例如Node 、Pod 、Service 、RC等，一个资源对象可 以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。 Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。
我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如，部署不同版本的应用到不同的环境中；监控和分析应 用（日志记录、监控、告警）等。一些常用的Label示例如下。
版本标签： "release":"stable" 、"release":"canary"。
环境标签： "environment":"dev" 、"environment":"qa" 、"environment":"production"。 架构标签： "tier":"frontend" 、"tier":"backend" 、"tier":"middleware"。
分区标签： "partition":"customerA" 、"partition":"customerB"。
质量管控标签： "track":"daily" 、"track":"weekly"。
五、Deployment
Deployment相对于RC的一个最大升级是我们可以随时知道当前Pod“部署” 的进度。实际上由于一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一完整过程需要一定的时间，所以我们期待系统启动N个 Pod副本的目标状态，实际上是一个连续变化的“部署过程”导致的最终状态。
Deployment的典型使用场景有以下几个：
创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建
检查Deployment的状态来看部署动作是否完成（Pod副本数量是否达到预期的值）
更新Deployment以创建新的Pod（比如镜像升级）
如果当前Deployment不稳定，则回滚到一个早先的Deployment版本
暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment，进行新的发布
扩展Deployment以应对高负载
查看Deployment的状态，以此作为发布是否成功的指标
清理不再需要的旧版本ReplicaSets
六、Namespace
Namespace （命名空间）是Kubernetes系统中的另一个非常重要的概念， Namespace在很多情况下用于实现多租户的资源隔离。
Namespace 通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理
Kubernetes集群在启动后会创建一个名为default的Namespace，通过kubectl可以查看
七、volume
Volume （存储卷）是Pod中能够被多个容器访问的共享目录。Kubernetes的Volume概念、用途和目的与Docker的Volume比较类似，但两者不能等价。
首先，Kubernetes中的Volume被定义在Pod上，然后被 一个Pod 里的多个容器挂载到具体的文件目录下；其次， Kubernetes中的 Volume与Pod的生命周期相同，但与容器的生命 周期不相关，当容器终 止或者重启时，Volume中的数据也不会丢失。最后，Kubernetes支持多种类型的Volume，例如GlusterFS 、Ceph等先进的分布式文件系统。
Volume的使用也比较简单，在大多数情况下，我们先在Pod上声明 一个Volume，然后在容器里引用该Volume并挂载（Mount）到容器里的 某个目录上。
八、Persistent Volume
Volume是被定义在Pod上的，属于计算资源的一部分，而实际上，网络存储是相对独立于计算资 源而存在的一种实体资源。比如在使用虚拟机的情况下，我们通常会先定义一个网络存储，然后从中 划出一个“ 网盘”并挂接到虚拟机上。
Persistent Volume（ PV）和与之相 关联的Persistent Volume Claim（ PVC）也起到了类似的作用。PV可以被理解成Kubernetes集群中的某个网络存储对应的一块存储，它与Volume类似，但有以下区别：
PV只能是网络存储，不属于任何Node，但可以在每个Node上访问
PV并不是被定义在Pod上的，而是独立于Pod之外定义的
九、ConfigMap
Kubernetes 中的 ConfigMap 是一种用于存储非敏感配置数据的 API 资源。它可以用来存储应用程序、服务或其他组件所需的配置信息，如环境变量、配置文件、命令行参数等。ConfigMap 提供了一种将配置数据与应用程序分离的机制，使得配置可以在不重新构建镜像的情况下进行修改和管理。
以下是一些关键概念和特性：
配置数据存储：ConfigMap 可以存储键值对形式的配置数据，也可以存储配置文件的内容。
与容器的挂载：ConfigMap 中的配置数据可以通过卷挂载（Volume Mount）的方式，直接注入到容器内部。这使得容器可以访问 ConfigMap 中的配置信息。
应用于 Pod：ConfigMap 可以被多个 Pod 共享，一个 Pod 可以引用一个或多ConfigMap。
与环境变量的关联：ConfigMap 中的配置数据可以被映射到 Pod 的环境变量中，这样应用程序可以直接从环境变量中读取配置。
动态更新：一旦 ConfigMap 中的配置数据发生变化，与之相关联的 Pod 可以自动感知到变化并重新加载配置，无需重启 Pod。
不适用于敏感数据：由于 ConfigMap 存储的数据不加密，因此不适用于存储敏感信息，如密码、密钥等。
使用 ConfigMap 可以有效地管理应用程序的配置，提高了部署的灵活性和可维护性。
十、Service
在 Kubernetes 中，Service 是一种抽象，用于定义一组 Pod 的访问方式。它提供了一种持久的虚拟 IP 地址，可以将请求路由到一组具有相同标签的 Pod。Service 使得应用程序可以通过稳定的方式被其他应用或用户访问，而无需关注后端 Pod 的具体细节。Service服务也是Kubernetes里的核心资源对象之一，Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个微服务。
它有以下一些关键概念和特性：
负载均衡：Service 会自动在其背后的一组 Pod 中实现负载均衡。当请求到达 Service 的虚拟 IP 地址时，它会将请求分发到相关联的 Pod 中的一个或多个。
服务发现：通过 Service，其他应用或服务可以轻松地发现和访问您的应用程序。无需知道后端 Pod 的具体 IP 地址，只需要知道 Service 的虚拟 IP 地址即可。
稳定的访问点：Service 提供了一个稳定的访问点，即使 Pod 的 IP 地址发生变化，也不会影响到外部应用程序的访问。
内部和外部服务：Service 可以被配置为 ClusterIP（仅内部可访问）、NodePort（外部和内部都可以访问）或 LoadBalancer（外部可访问，需要云提供商支持）类型，以满足不同场景下的需求。
服务标签：Service 通过标签选择器（Selector）来确定与其关联的后端 Pod。只有具有与 Service 标签选择器匹配的标签的 Pod 才会被 Service 所代理。
端口映射：Service 可以定义多个端口映射，将请求转发 到后端 Pod 的不同端口。