我花了10个小时，写出了这篇K8S架构解析-

【51CTO.com原创稿件】互联网技术飞速发展的今天，为了承载请求的高并发和业务的多样性，微服务的架构成了各个公司的标配。

图片来自 Pexels

每个微服务通过 Docker 进行发布，随着业务的发展，系统中遍布着各种各样的容器。于是，容器的资源调度，部署运行，扩容缩容就是我们要面临的问题。

基于 Kubernetes 作为容器集群的管理平台被广泛应用，今天我们一起来看看 Kubernetes 的架构中有那些常用的组件以及运行原理。

Kubernetes 架构概述

Kubernetes 是用来管理容器集群的平台。既然是管理集群，那么就存在被管理节点，针对每个 Kubernetes 集群都由一个 Master 负责管理和控制集群节点。

我们通过 Master 对每个节点 Node 发送命令。简单来说，Master 就是管理者，Node 就是被管理者。

Node 可以是一台机器或者一台虚拟机。在 Node 上面可以运行多个 Pod，Pod 是 Kubernetes 管理的最小单位，同时每个 Pod 可以包含多个容器(Docker)。

通过下面的 Kubernetes 架构简图可以看到 Master 和 Node 之间的关系：

Kubernetes 架构简图

通常我们都是通过 kubectl 对 Kubernetes 下命令的，它通过 APIServer 去调用各个进程来完成对 Node 的部署和控制。

APIServer 的核心功能是对核心对象(例如：Pod，Service，RC)的增删改查操作，同时也是集群内模块之间数据交换的枢纽。

它包括了常用的 API，访问(权限)控制，注册，信息存储(etcd)等功能。在它的下面我们可以看到 Scheduler，它将待调度的 Pod 绑定到 Node 上，并将绑定信息写入 etcd 中。

etcd 包含在 APIServer 中，用来存储资源信息。接下来就是 Controller Manager 了，如果说 Kubernetes 是一个自动化运行的系统，那么就需要有一套管理规则来控制这套系统。

Controller Manager 就是这个管理者，或者说是控制者。它包括 8 个 Controller，分别对应着副本，节点，资源，命名空间，服务等等。

紧接着，Scheduler 会把 Pod 调度到 Node 上，调度完以后就由 kubelet 来管理 Node 了。

kubelet 用于处理 Master 下发到 Node 的任务(即 Scheduler 的调度任务)，同时管理 Pod 及 Pod 中的容器。

在完成资源调度以后，kubelet 进程也会在 APIServer 上注册 Node 信息，定期向 Master 汇报 Node 信息，并通过 cAdvisor 监控容器和节点资源。

由于，微服务的部署都是分布式的，所以对应的 Pod 以及容器的部署也是。为了能够方便地找到这些 Pod 或者容器，引入了 Service(kube-proxy)进程，它来负责反向代理和负载均衡的实施。

上面就是 Kubernetes 架构的简易说明，涉及到了一些核心概念以及简单的信息流动。

将一些功能收录到了 APIServer 中，这个简图比官网的图显得简单一些，主要是方便大家记忆。

后面我们会用一个简单的例子，带大家把 Kubernetes 的概念的由来做深入的了解。

从一个例子开始

假设使用 Kubernetes 部署 Tomcat 和 MySQL 服务到两个 Node 上面。其中 Tomcat 服务生成两个实例也就是生成两个 Pod，用来对其做水平扩展。

MySQL 只部署一个实例，也就是一个 Pod。可以通过外网访问 Tomcat，而 Tomcat 可以在内网访问 MySQL。

例子示意图

这里我们假设 Kubernetes 和 Docker 的安装都已经完成，并且镜像文件都已经准备好了。重点看 Kubernetes 如何部署和管理容器。

kubectl 和 APIServer

既然我们要完成上面的例子，接下来就要部署两个应用。

首先，根据要部署的应用建立 Replication Controller(RC)。RC 是用来声明应用副本的个数，也就是 Pod 的个数。

按照上面的例子，Tomcat 的 RC 就是 2，MySQL 的 RC 就是 1。

由于 kubectl 作为用户接口向 Kubernetes 下发指令，那么指令是通过“.yaml”的配置文件编写的。

定义 mysql-rc.yaml 的配置文件来描述 MySQL 的 RC：