浅谈Kubernetes集群架构

目录

容器编排平台需要具备的能力

Kubernetes控制面板的服务组件

kube-apiserver

kube-controller-manager

kub-scheduler

Kubernetes运行在Node节点的组件

kubelet

kube-proxy

---

Docker本身提供了docker compose可以实现单机环境的容易编排管理，但是集群化的管理还是需要像Kubernetes，dockerswam这种强大完备的容器编排平台来实现，K8S是当下最流行的容器编排平台，不管是生产环境的采用率，还是云原生生态都很强大。

容器编排平台需要具备的能力

一个完整的容器编排平台需要具备的能力包括不限于以下几种，k8s是具备这些能力的

1. 调度能力 能够自动生成容器实例
2. 亲和、反亲和 生成的容器可以相邻或者相隔，提供可用性和性能。
3. 健康检查 自动监测容器的健康状态
4. 容错 自动在健康的节点上重新生成容器实例
5. 可扩展 自动根据需要增加或者删除容器实例
6. 网络 允许容器之间进行互相通信
7. 服务发现 允许容器之间互相发现
8. 滚动升级 容器升级可以避免对业务造成影响,同时可以出错回滚。

 下面是一张k8s集群的架构图，主要由master和node两种类型的节点组成，当然，为了实现高可用，线上每种类型的节点也是集群的形式。

Kubernetes控制面板的服务组件

Master节点组成的集群构成了k8s集群的服务端控制面板，使其具备服务发现和调度等管理能力。

kube-apiserver

提供k8s对内或对外的api请求的唯一入口，同时也包括集群的认证和授权及服务发现等能力。

外部控制(包括使用内部kubelet)对集群进行的查询和管理都要通过API来进行,kube-apiserver负责与ETCD交互进行数据的查询更新操作,同时集群中Node节点上的组件也是通过kube-apiserver获取存储在ETCD中的service endpoints等信息。

kube-controller-manager

维护整个k8s集群的状态，比如Node节点的心跳监测,多副本创建，滚动升级等。controller-manager 作为 k8s 集群的管理控制中心，负责集群内 Node、Namespace、Service、Token、Replication 等资源对象的管理，使集群内的资源对象维持在预期的工作状态。每一个 controller 通过 api-server 提供的 restful 接口实时监控集群内每个资源对象的状态，当发生故障，导致资源对象的工作状态发生变化，就进行干预，尝试将资源对象从当前状态恢复为预期的工作状态，常见的 controller 有 Namespace Controller、Node Controller、Service Controller、ServiceAccount Controller、Token Controller、ResourceQuote Controller、Replication Controller等。

kub-scheduler

监听未调度的POD，按指定的调度策略绑定到满足条件的节点上。

Kubernetes运行在Node节点的组件

与springCloud微服务的架构类似,k8s除了matser节点用来提供管理调度入口外，集群中每个被管理的机器即Node节点中都需要安装kubelet和kube-proxy来实现与控制端服务的调度通信。

kubelet

Kubelet组件运行在Node节点上，会通过kube-apiserver获得一组PodSpec,并按照spec配置来维持运行中的Pods以及提供kubernetes运行时环境。例如定期从所监听的数据源获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。

kube-proxy

Kube-proxy 是 kubernetes 工作节点上的一个网络代理组件，运行在每个节点上。

每个节点上的Kube-proxy会通过kube-apiserver获得etcd中存储的Service和Endpoints的信息，所以它是实现Kubernetes Service的通信与负载均衡机制的重要组件。

kube-proxy有如下三种工作模式：User space模式，iptables模式，IPVS模式。具体在另一篇k8s集群的访问中再详细介绍