Master
集群控制节点，负责整个集群的管理和控制，负责命令的执行过程，运行着以下四个关键进程。
（1）Kubernetes API Service（Kube-apiservice）：提供了Http Rest 接口的关键服务进程，是K8s里所有资源的CRUD的唯一操作入口，也是集群控制的入口进程。
（2）Kubernetes Controller Manager（Kube-controller-manager）：K8s中所有资源对象的自动化控制中心，资源对象的大总管。controller用于监控容器健康状态，controller manager监控controller的健康状态。
（3）Kubernetes Scheduler（Kube-scheduler）：先做预选，筛选有哪些Node符合，然后做优选最佳的节点。负责资源调度（Pod调度）的进程。
（4）etcd server：保存所有资源对象的数据。当数据发生变化时，etcd 会快速地通知 Kubernetes 相关组件。

Node
工作负载节点，每个Node都会被Master分配工作负载（容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上。每个Node节点都运行着以下一组进程。
（1）kubelet：负责Pod对应的容器创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能。
（2）kube-proxy：实现K8s service的通信和负载均衡机制的重要组件。
（3）Docker Enginer：Docker引擎，负责本机的容器创建和管理工作。

Pod
Pod 是Kubernetes的基本操作单元，也是容器运行的载体。提供容器共享的环境。

Deployment
Deployment定义了一组Pod的信息。Deployment主要职责与RC相似，同样是为了保证pod的数量和健康。除此之外还支持滚动升级、回滚等多种升级方案。

Namespace
kubernetes通过namespace实现资源的逻辑隔离，namespace唯一，不同namespace中资源可重复。

apiserver
-> nodes、pods、services
从apiserver到Node、Pod或Service的连接默认为HTTP连接，因此不需进行认证加密。

ReplicaSet
ReplicaSet能确保运行指定数量的pod。然而，Deployment 是一个更高层次的概念，它能管理ReplicaSets，并提供对pod的更新等功能。因此，我们建议你使用Deployment来管理ReplicaSets，除非你需要自定义更新编排。

ReplicationController
在用户定义范围内，如果pod增多，则ReplicationController会终止额外的pod，如果减少，RC会创建新的pod，始终保持在定义范围。例如，RC会在Pod维护（例如内核升级）后在节点上重新创建新Pod。
注：

  • ReplicationController会替换由于某些原因而被删除或终止的pod，例如在节点故障或中断节点维护（例如内核升级）的情况下。因此，即使应用只需要一个pod，我们也建议使用ReplicationController。
  • RC跨多个Node节点监视多个pod。

StatefulSets
在具有以下特点时使用StatefulSets：

  • 稳定性，唯一的网络标识符。
  • 稳定性，持久化存储。
  • 有序的部署和扩展。
  • 有序的删除和终止。
  • 有序的自动滚动更新。

Pod调度运行时，如果应用不需要任何稳定的标示、有序的部署、删除和扩展，则应该使用一组无状态副本的控制器来部署应用，例如 Deployment 或 ReplicaSet更适合无状态服务需求。

Kubernetes Service
定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。Pod间相互通信最常用的设计方案。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector（查看下面了解，为什么可能需要没有 selector 的 Service）实现的。

Ingress
Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。 Ingress controller负责实现Ingress，通常使用负载平衡器，它还可以配置边界路由和其他前端，这有助于以HA方式处理流量。

kube-scheduler

  • 从集群所有节点中，根据调度算法挑选出所有可以运行该pod的节点。
  • 再根据调度算法从上述node节点选择最优节点作为最终结果。
  • Scheduler调度器运行在master节点，它的核心功能是监听apiserver来获取PodSpec.NodeName为空的pod，然后为pod创建一个binding指示pod应该调度到哪个节点上，调度结果写入apiserver。

注意：

  1. Pod.spec.nodeName用于强制约束将Pod调度到指定的Node节点上，强制匹配。(通过指定nodeName可直接绕过调度器，并不会做任何的资源过滤和检查)

  2. pod.spec.nodeSelector是通过kubernetes的label-selector机制进行节点选择，由scheduler调度策略MatchNodeSelector进行label匹配，调度pod到目标节点，该匹配规则是强制约束。

[

](https://blog.csdn.net/li_101357/article/details/89980217)