k8s 架构
K8s 属于经典的主从模型（Master-Slave 架构），由 Master 和 Node 节点构成：
Master 节点：负责集群的管理，协调集群中的所有活动。例如应用的运行、修改、更新等。
Node 节点：为 Kubernetes 集群中的工作节点，可以是 VM 虚拟机、物理机。每个 node 上有一个 Kubelet（负责每个节点的运行状态，以及与 master 节点通信，执行 master 节点的指令），同时 Node 节点上至少还需要运行 container runtime（比如 docker，这样才能够运行相关镜像）。
简单的示意图架构图如下所示：
image
完整的架构图如下所示，其中 Node 中的 pod 可以理解为运行应用程序的容器，例如运行java的一个微服务jar包，至于其他的组件，将在后面进行详细介绍。
image
2. Master 节点
Master节点是整个k8s的大脑
image
Master 节点也被称之为控制平面组件，也就是上图中红色框中的区域。Master 节点一般来说，由如下构成：
kube-apiserver：提供 RESTful API，供用户、kubectl、其他组件和外部系统调用。无状态，可水平扩展，通常部署多个实例实现高可用。
etcd：分布式键值数据库，存储集群的所有配置数据和状态信息（如节点、Pod、Service 等对象的状态，配置文件）。所有组件通过 apiserver 读写 etcd，不直接访问。一般来说是部署多个节点，使用 Raft 协议保证一致性。
kube-scheduler：负责 Pod 的调度，决定将新创建的 Pod 分配到哪个 Node 上运行。
kube-controller-manager（图中 c-m）：运行控制器进程，确保集群的实际状态与期望状态一致。这句话听起来似乎有点抽象，但是实际上我们可以把它理解为一个管家，它不断检查集群的“实际状态”，并努力让它与用户定义的“期望状态”保持一致。 例如说，我希望我的集群中有 3 个 nginx pod 在运行（通过相关配置文件进行定义），突然有一个 pod 挂了，gg 了，那么 c-m 就会重新拉起来一个 pod，执行顺序如下：
c-m 从 apiserver 读取“期望状态”（比如 replicas: 3）
从 apiserver 读取“当前实际状态”（比如现在只有 2 个 Pod 在运行）
如果不一致 → 执行操作（比如创建 1 个新 Pod）
写回 apiserver，更新状态
休息一会儿，然后重复步骤 1～5
cloud-controller-manager（图中 c-c-m）：是 Kubernetes 与底层云平台（如 AWS、Azure、阿里云等）之间的“翻译官”和“对接员”，专门处理那些需要和云厂商 API 交互的功能。
3. Node 节点
Master 节点我们已经理解了，那么什么是 Node 节点呢。Node 节点（也称之为 Worker 节点），就是真正“运行应用”的 worker。在现实世界，Node 节点可以是一台物理服务器，一台 VM 虚拟机（一个 Node 节点严格对应一台“计算实例”），但是注意，Node 节点不是容器（Node 是运行容器的宿主机）。下图中，红色框框里面的内容便是 Node 节点。
image
Node 节点主要包含如下组件：
kubelet：负责与 Master 通信、接收调度指令、调用容器运行时启动或终止 Pod，并向 api-server 持续上报节点和容器的健康状态。执行探针，挂载卷，设置网络等等。每个 node 必须要有一个 kubelet。
Container Runtime（容器运行时）：根据 kubelet 的指令，拉取镜像、创建/启动/停止容器，管理容器的生命周期。如果简单的理解，你就可以把他看成一个 docker，可以运行相关的镜像。
kube-proxy：在 每个 Node 上维护网络规则（如 iptables 或 IPVS），将访问流量（Service 的流量）转发到后端 Pod。每个 Node 都需要运行 kube-proxy，因为如果一个容器不跟外界通信，那么也毫无意义。
cAdvisor：用于自动发现并收集当前 Node 节点上所有容器（包括 Pod 中的容器）的资源使用情况和性能数据，比如 CPU、内存、磁盘 I/O、网络使用率等。
4. 命名空间
k8s 集群在搭建好之后，需要提供给多个部门或者小组进行使用。而在我们开发和生产过程中，大概率不同小组可能会出现相同的资源（例如应用，服务）名，同时每个小组需要的计算资源数量也可能不同，以及每个小组的权限也不同（例如开发团队不能访问生产环境）。为了解决这个问题，k8s 提出了命名空间（namespace）的概念（默认的命名空间是default），命名空间有如下好处：
资源隔离
不同命名空间中的资源名称可以重复（例如两个命名空间中都可以有名为 web-app 的 Deployment）。
避免资源命名冲突。
限制资源使用（配合 ResourceQuota 和 LimitRange）。
权限控制（RBAC）
可以为不同命名空间设置不同的访问权限。例如：开发团队只能访问 dev 命名空间，运维团队可访问 prod。
环境隔离
将开发（dev）、测试（test）、预发布（staging）、生产（prod）环境部署在不同命名空间中，便于管理。
简化管理
可以按命名空间批量操作资源（如删除整个命名空间及其所有资源）。
日志、监控、网络策略等也可以按命名空间维度配置。
但是需要注意的是，在 k8s 集群中，不同的命名空间里面应用，其网络是互通的。如果要避免网络互通，则需要进行相关的网络配置。在比较大型的网络开发中，还是推荐将生产和测试集群分开部署，而不是依赖于命名空间进行隔离。
