计算机系统应用教程网站

网站首页 > 技术文章 正文

2. Kubernetes设计架构(转载) kubernetes基础

btikc 2024-10-10 04:51:06 技术文章 15 ℃ 0 评论

Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。

Kubernetes节点

在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。

Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。

每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。

Kubernetes主要由以下几个核心组件组成：

  • etcd保存了整个集群的状态；
  • apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
  • controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
  • scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
  • kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
  • Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
  • kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

这个架构图看起来会比较复杂，很难看懂，下面为一个重新简化了一下的架构图：

详细一点的解释：

  • ETCD ：是用来存储所有 Kubernetes 的集群状态的，它除了具备状态存储的功能，还有事件监听和订阅、Leader选举的功能，所谓事件监听和订阅，各个其他组件通信，都并不是互相调用 API 来完成的，而是把状态写入 ETCD（相当于写入一个消息），其他组件通过监听 ETCD 的状态的的变化（相当于订阅消息），然后做后续的处理，然后再一次把更新的数据写入 ETCD。所谓 Leader 选举，其它一些组件比如 Scheduler，为了做实现高可用，通过 ETCD 从多个（通常是3个）实例里面选举出来一个做Master，其他都是Standby。
  • API Server：刚才说了 ETCD 是整个系统的最核心，所有组件之间通信都需要通过 ETCD，实际上，他们并不是直接访问 ETCD，而是访问一个代理，这个代理是通过标准的RESTFul API，重新封装了对 ETCD 接口调用，除此之外，这个代理还实现了一些附加功能，比如身份的认证、缓存等。这个代理就是 API Server。
  • Controller Manager：是实现任务的调度的，简单说，直接请求 Kubernetes 做调度的都是任务，比如比如 Deployment 、Deamon Set 或者 Job，每一个任务请求发送给Kubernetes之后，都是由Controller Manager来处理的，每一个任务类型对应一个Controller Manager，比如 Deployment对应一个叫做 Deployment Controller，DaemonSet 对应一个 DaemonSet Controller。
  • Scheduler：是用来做资源调度的，Controller Manager会把任务对资源要求，其实就是Pod，写入到ETCD里面，Scheduler监听到有新的资源需要调度（新的Pod），就会根据整个集群的状态，给Pod分配到具体的节点上。
  • Kubelet：是一个Agent，运行在每一个节点上，它会监听ETCD中的Pod信息，发现有分配给它所在节点的Pod需要运行，就在节点上运行相应的Pod，并且把状态更新回到ETCD。
  • Kubectl: 是一个命令行工具，它会调用 API Server发送请求写入状态到ETCD，或者查询ETCD的状态。

    • 这样是不是简单了很多。如果还是觉得不清楚，下面就用部署一个服务的例子来解释一个整个过程，假设你要运行一个多个实例的Nginx，那么在Kubernetes内部，整个流程是这样的：

    1. 通过kubectl命令行，创建一个包含Nginx的Deployment对象，kubectl会调用 API Server 往ETCD里面写入一个 Deployment对象。
    2. Deployment Controller 监听到有新的 Deployment对象被写入，就获取到对象信息，根据对象信息来做任务调度，创建对应的 Replica Set 对象。
    3. Replica Set Controller监听到有新的对象被创建，也读取到对象信息来做任务调度，创建对应的Pod来。
    4. Scheduler 监听到有新的 Pod 被创建，读取到Pod对象信息，根据集群状态将Pod调度到某一个节点上，然后更新Pod（内部操作是将Pod和节点绑定）。
    5. Kubelet 监听到当前的节点被指定了新的Pod，就根据对象信息运行Pod。

    上面就是Kubernetes内部的是如何实现的整个 Deployment 被创建的过程。这个过程只是为了向大家解释每一个组件的职责，以及他们之间是如何相互协作的，忽略掉了很多繁琐的细节。

    除了核心组件，还有一些推荐的Add-ons：

    • kube-dns负责为整个集群提供DNS服务
    • Ingress Controller为服务提供外网入口
    • Heapster提供资源监控
    • Dashboard提供GUI
    • Federation提供跨可用区的集群
    • Fluentd-elasticsearch提供集群日志采集、存储与查询

    分层架构

    Kubernetes设计理念和功能其实就是一个类似Linux的分层架构：

  • 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
  • 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
  • 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
  • 接口层：kubectl命令行工具、客户端SDK以及集群联邦
  • 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

    • kubelet

    kubelet负责管理pods和它们上面的容器，images镜像、volumes、etc。

    kube-proxy

    每一个节点也运行一个简单的网络代理和负载均衡（详见services FAQ )（PS:官方 英文）。 正如Kubernetes API里面定义的这些服务（详见the services doc）（PS:官方 英文）也可以在各种终端中以轮询的方式做一些简单的TCP和UDP传输。

    服务端点目前是通过DNS或者环境变量( Docker-links-compatible 和 Kubernetes{FOO}_SERVICE_HOST 及 {FOO}_SERVICE_PORT 变量都支持)。这些变量由服务代理所管理的端口来解析。

    Kubernetes控制面板

    Kubernetes控制面板可以分为多个部分。目前它们都运行在一个master 节点，然而为了达到高可用性，这需要改变。不同部分一起协作提供一个统一的关于集群的视图。

    etcd

    所有master的持续状态都存在etcd的一个实例中。这可以很好地存储配置数据。因为有watch(观察者)的支持，各部件协调中的改变可以很快被察觉。

    Kubernetes API Server

    API服务提供Kubernetes API 的服务。这个服务试图通过把所有或者大部分的业务逻辑放到不两只的部件中从而使其具有CRUD特性。它主要处理REST操作，在etcd中验证更新这些对象（并最终存储）。

    Scheduler

    调度器把未调度的pod通过binding api绑定到节点上。调度器是可插拔的，并且我们期待支持多集群的调度，未来甚至希望可以支持用户自定义的调度器。

    Kubernetes控制管理服务器

    所有其它的集群级别的功能目前都是由控制管理器所负责。例如，端点对象是被端点控制器来创建和更新。这些最终可以被分隔成不同的部件来让它们独自的可插拔。

    Tags：

    猜你喜欢

    本文暂时没有评论，来添加一个吧(●'◡'●)

    欢迎 你 发表评论:

    最近发表
    标签列表