【运维核心基本功】洞悉全局，聊聊Kubernetes整体架构与功能介绍

Kubernetes 集群架构

上图，就是Kubernetes整个集群的一张图，Kubernetes集群就是掌握了所有Kubernetes里面计算、存储、网络资源，并且进行统一管理、统筹调度的一套节点群。

在集群里面有两大类型的节点，Kubernetes第一大类型的节点叫做Kubernetes Master，它是一个主脑节点，还有很多的节点，我们称为Node。
其中Kubernetes Master里面又有很多Component，API Server、Replication Controller。

在Node里面，有一个很核心的内容，叫做Pod，正是因为Pod这种集群式或者说是分组的方式，才是Kuberneties优于很多其他的容器化解决方案的一大特点。
除此以外，还有kubelet、kube-proxy、docker这些基本的节点或者模块，他们配合起来形成这样一个Node，这些一些Node加上中间还有一些耦合的模块，这样就形成了Kubernetes一个整体。

Kubernetes Maset

• API Server
  当我们的Kubernetes发送一个命令，不论是在Kubernetes Master上跑，还是远端的一台命令行的终端上跑，它的命令都会通过网络或者本机的形式发给Master，Master的API Server它就会接收这个命令，来验证是不是符合语法标准，同时根据当前的Kubernetes集群的环境进行相应处理。
• Scheduler
  对所有资源按照应用需求进行统一调度、任务发布。
• Controller Manager - replication/namespace controller
  它里面又分很多具体的功能，整体组成了一套资源统筹管理的功能，叫做Controller Manager，它就是所有资源、所有任务的统一调度和部署。
  比如，它里面有一个replication controller 这一类它是负责容器跨节点怎样进行部署，怎样实现通讯，同时怎样进行标签管理，资源选择等等。
  另外还有一个叫namespace controller，它是Kubernetes集群里面一个虚拟化集群的概念。所以它会管理所有虚拟化集群资源的隔离。

这三个核心模块构成了Kubernetes Master的主体，除此以外，还有很多支持模块：

• Etcd
  当看到这个的时候，应该首先想到它有一个好兄弟，叫做Zookeeper，Messos就是用的Zookeeper做的集群的配置管理、仲裁还有选举。而我们的Kubernetes Master就是用的它的替代产品Etcd做集群的配置，统一的管理。
• Network — Flannel，Calico，Canal
  另外，Kubernetes的网络因为它是跨很多的物理节点，很多个容器之间互相沟通，所以它需要一种容器间网络的解决方案，比如像Flannel、Calico，这两块布我们在上篇《运维基本功——容器间网络访问与通信管理》有过详细的介绍。Kubernetes会推荐使用这两种方式以及Canal，关于Canal我们后续会详细探讨。
• Node’s Components
  Kubernetes Master不光是我们上图总看到的那两个模块，其实它里面还有很多大量的辅助容器、监管容器、网络容器等等都会在上面运行起来，所以分配内存的时候千万不要分配的太小，它的资源也要做合理的分配。

Node

• Kubelet
  它是Kubenetes的一个核心的功能模块，它是实现真正的容器启、停，怎样给容器加网络资源，怎样把一个镜像变成容器真正跑起来的模块，所以Kubelet才是真正跟Docker沟通的最核心的一个掌控容器管理的模块。

• Kube-proxy
  它是一个类似于网络感知模块，或者说是服务发现模块，我们利用Kube-proxy实现了当容器状态不断改变的时候，Kube-proxy它会有自己内部的一些配置转换，从而去和其他的容器、物理节点进行沟通，使得容器的网络管理、服务发现变得全自动，而不用人工干预。

• Docker
  这也是最关键的，我们Kubernetes可以跑各种各样的容器，但最常见的是Docker容器，所以Docker deamon也是需要在Node上面运行起来的。

Pod

它是Kubernetes最小的工作单元，它是运行在一个节点上的一堆容器的集合，且Pod中的容器共享网络和存储。

通过Pod我们就可以扩大的管理的粒度，缩减了管理的复杂度。

举个例子，我们假设有一个消息节点，同时有一个消息发送节点和一个消息接收节点，这样一套应用如果要让容器来管理，那么需要管理三个。
那么我们完全可以把小的消息队列、消息发送、消息接收这三个东西做成一个Pod，因为他们通常是要共享存储的，也是要共享网络的，那我完全就可以封装在一个小应用，这个应用可以用Kubernetes不同的控制器，实现多节点、高可用、可扩展，那么让这些所有的容器在一个Pod里面共享ip地址。 他们有相同的ip地址，有相同的网络namespace，同时他们的所有存储访问、磁盘映射都是互通的，他可以很方便的用不同的网络端口，用文件系统不同的路径进行数据共享。
所以Kubernetes的Pod大大简化了管理的复杂度，同时把我们管理单元的粒度提升，不再是一个个小的容器，而是一堆容器的集合。
要注意的是，每一个Pod一旦发布在一个节点上，那它就只能在这个节点上，它的兄弟节点，另外一个Node上的另外一个Pod虽然和它承载一样的内容但是它们是具有不同的Pod的名称。

这就是Pod的概念，是一个比容器更大的集装箱。

Controller

Controller是一个比Pod更高一级的统一管理的抽象概念。

可分为：

• Deployment
• ReplicaSet
• DeamonSet
• StatefulSet
• Job

其他概念

• Label
  所谓Label就是可以给某些特殊的Pod打一个标签，这个标签打完后，就可以用这些标签查询Pod，比如给一个Pod打一个标签叫MyApp，那我就知道这个Pod发布的应用叫MyApp，那下次用Service做负载均衡、网络管理或者服务发现的时候，希望对外提供一个特殊的ip地址、URL，这个应用的后台就只给MyApp这样一个应用提供网络路由。这里就可以通过Selectors来选择一个Label，实现网络的负载均衡和指向。
• Namespace
  这个概念就可能更大一层，我们平时Deployment或者Pod这样一些概念都是在一个虚拟集群上的，虽然我们物理上是一个Kubernetes Class，但是一个物理Kubernetes Class默认生成两个虚拟集群，一个是Kubernetes自身管理自身的集群，还有一个叫Default，我们应用部署如果你不指定Namespace会默认发布到Default的namespace里面，这两个是一种虚拟的集群，同时一个Kubernetes Class同时可以支持十多个甚至上百个不同的Namespace，只要你在应用发布，软件包安装的时候指定用一个新的Namespace部署应用，它就会在一个新的虚拟化集群当中，很方便的进行管理。

Namespace、Pod这两个概念的引入便使得Kubernetes有了更大的灵活性，他能把一个物理集群变得更多的虚拟化，同时又能把很多很小的Docker容器进行大的拼装，这样层层封装处理后，就使得容器上面有Pod，Pod上面有Controller，Controller上面有Namespace，Namespace上面才是Kubernetes Class。
这样一个层层的套娃结构，使得我们一个大数据中心，大批量成千上万的应用的容器化或者说是小的微服务，可以最后通过一个高可用的、层层管理的、具有可扩展性的这样一个Kubernetes集群得到保障。