k8s的组织架构

k8s一般由三个或者三个以上节点组成，它遵循集群的一般要求，并且有以下基础类型组成：

1. Master 节点

Master 是集群的控制节点，即主节点。 在Kubernetes集群中需要由一个或者一组 Master, 负责管理和控制整个集群。 Master通常占有一台独立的服务器（在高可用模式下建议使用三台或者以上的服务器），是整个集群的【大脑】，如果它发生宕机或者不可用，那么对集群中容器应用的管理都将无法实施。

在 Master 上运行着以下关键进程

• Kubernetes API Server(kube-apiserver): 提供 HTTP RESTful API接口的主要服务，是Kubernetes中对所有资源进行增、删、改、查等操作的唯一入口，也是集群控制的入口进程。
• Kubernetes Controller Manager(kube-controller-manager): Kubernetes 中所有资源对象的自动化控制中心，可以将其理解为资源对象的【大总管】
• Kubernetes Scheduler(kube-scheduler): 负责将资源调度(Pod 调度)的进程，相当于公交调度室。

另外，在Master上通常还需要部署etcd服务。

如果将原本部署在Master上的这些进程以Pod的方式部署在Node上，比如采用kubedam安装Kubernetes集群，那么此时Kubernetes集群中就没有Master了，因为所有节点都是Node。

2. Node节点

在Kubernetes中，除Master外的其他服务器被称为Node，Node在较早的一些版本也被称为Minion。与Master一样，Node既可以的一台物理主机，也可以是一台虚拟机。Node是Kubernetes集群的工作负载节点，每个Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时，其上的工作负载都会被Master自动转移到其他Node上。在每个Node上都运行着以下关键进程：

• kubelet: 负责Pod对应容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能
• kube-proxy: 是实现Kubernetes Service通讯与负载均衡机制的服务
• 容器运行时

Node可以在运行期间被动态增加到Kubernetes集群中，前提是在这个Node上已经正确的安装、配置和启动了上述关键进程。在默认情况下，kubelet会向Master注册自己，这也是Kubernetes推荐的Node管理方式。一旦Node被纳入集群管理范畴，kubelet进程就会定时向Master汇报自身的情报，例如操作系统、主机CPU和内存的使用情况，以及当前有哪些Pod在运行等，这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略了，而某个Node在超过指定时间不上报信息时，会被Master判定为【失联】，该Node状态被标记为【NotReady】，Master随后会触发【故障转移】的的自动流程。

查看集群中有多少节点的命令如下：

kubectl get nodes

命名空间

命名空间是集群类里面一个重要的基础概念，它在很多情况可以实现多租户隔离，典型的一个思路是给每个租户分配一个命名空间，命名空间属于Kubernetes集群范畴的资源对象，在一个集群可以创建多个命名空间，每个命名空间都是独立的存在，属于不同命名空间的资源对象在逻辑上互相隔离。在每个Kubernetes集群安装完成且正常运行后，Master会自动创建两个命名空间：

• default（默认）
• kub-system(Kubernetes系统级)

用户创建的资源对象如果没有指定命名空间，则被默认都安装在kube-system命名空间中。我们可以通过命名空间将集群的资源对象【分配】到不同的命名空间中，形成逻辑上分组的不同项目、小组或者用户组，便于不同的分组共享整个集群的资源的同时被分别管理。当给每个租户都创建了一个命名空间来实现多租户管理的资源隔离时，还能结合Kubernetes的资源配额管理，限定不同租户能占用的资源，例如CPU私有量和内存使用量等

命名空间的定义如下：

apiVersion: v1
kind: Namespace
metadata:
  name: development

执行以下命令来创建此定义：

kubectl apply -f <namespace.yaml>