kubernetes 的 架构 及其 组件:

文章目录

      • kubernetes 的架构:
      • Master 和 Node:
      • kubernetes集群组件:
        • 1、Master 主要组件:
          • 1.1、API Server —— 集群的网关
          • 1.2、Controller —— 控制器
          • 1.2.1、kube-controller-manager
          • 1.2.2、cloud-controller-manager
          • 1.3、Scheduler —— 调度器
        • 2、Node 主要组件:
          • 2.1、kubelet —— Node 核心代理程序
          • 2.2、container runtime —— 容器运行时环境
          • 2.3、 kube-proxy —— iptables规则
        • 3、etcd —— 集群状态存储
        • 4、其他组件:
          • 4.1、kubeDNS(CoreDNS)
          • 4.2、kubernetes Dashboard
          • 4.3、Heapster —— 性能分析与监控
          • 4.4、Ingress Controller —— 应用层负载均衡机制

 


      这里是我自己写的一个 “小白学习 kubernetes” 的一个目录导航!跟我一样的小白可以跟着导航一起进行学习:

 
kubernetes 学习导航:


kubernetes 的架构:

 
kubernetes 的架构是典型的 二层架构(c/s 架构)
kubernetes 的 架构 及其 组件:_第1张图片
由图可知:

        master 作为 集群的中枢,它是负责用户和集群内节点之间练习的联络点!他们之间只能通过 master 进行联系!

        用户将希望的状态或执行的命令下发给master,master再将状态或命令下发给相应的Node进行执行!!!


Master 和 Node:

 
Master: 负责 为用户和客户端暴露API、追踪集群节点的健康状态、调度工作负载、以及编排其他组件之间的通信等…
(单个 master 节点即可完成其所有的功能,但是出于冗余及负载均衡的目的,生产环境中通常需要多个 master!)
 
Node: 是 k8s 集群中的工作节点,以 pod 的形式运行容器,Node 负责接收来自 master 节点 的工作指令并根据指令来创建或销毁 pod(容器) 对象,以及调整网络规划以便合理的路由和转发流量!


       k8s 将所有 Node 的资源集结于一处,形成一台更加强大的 “服务器”。当用户部署应用的时候,Master 会使用调度算法将其自动指派到某个特定的 Node 上运行。当集群中有 Node 增加或移除的时候,Master 也会重新编排受到影响的Pod,所以,用户无须关心该应用究竟运行于哪儿!


kubernetes集群组件:

 
一个 kubernetes集群由:
多个Node(主要组件:kubelet、kube-proxy、容器引擎:docker最常见)
一个Master(主要组件:api server、controller-控制器、scheduler-调度器)
一个 etcd(集群状态存储系统) 组成!

        此外 k8s 集群还需要依赖一些其他组件来提供完整的功能,它们通常是由第三方提供的特定应用程序,且托管运行于 k8s 集群之上。eg:kubeDNS 等…文章后面有提及…


1、Master 主要组件:

        Master 由多个组件组成,这些组件可以运行在单个master节点。也可以以多副本方式运行于多个节点,以为 Master 提供高可用功能
kubernetes 的 架构 及其 组件:_第2张图片

1.1、API Server —— 集群的网关

        顾名思义,这是用来处理 api 操作的,k8s中所有组件都会与 “API server” 进行连接,各个组件之间不会进行独立的连接,都通过 “API Server” 进行消息的传送!

        API Server 是整个集群的网关,它是发往集群的所有 REST操作 的接入点,并且负责接收、校验并响应所有的 REST请求结果被持久的存储于 etcd 中!

        “API Server” 是负责接收并响应客户端提交任务的接口,用户可以使用诸多工具发起请求。(eg: CLI工具:kubectl、 UI工具:Dashboard、或程序代码),kubectl 是最常用的交互式命令行工具。

 

关于 “kube-apiserver” 的更多 options:k8s中文社区


1.2、Controller —— 控制器

        用来对集群的状态进行一些管理,例如上面提到的关于 k8s 中特征的:自动修复、水平扩展等等…都是由 Controller 来完成的!


1.2.1、kube-controller-manager

        在 k8s 中,集群级别的大多数功能都是由几个被称为“控制器”的进程执行实现的,这几个进程被集成于 “kube-controller-manager” 守护进程中!

 
由控制器完成的功能:

1)、生命周期功能: namespace创建和生命周期、event垃圾回收、pod终止相关的垃圾回收、级联垃圾回收、node垃圾回收等等…

2)、API 业务逻辑: 例如由 ReplicaSet 执行的 Pod 扩展等…

 

1.2.2、cloud-controller-manager

        除了“kube-controller-manager”外,还有 “cloud-controller-manager”云控制器管理器。 它负责与底层云提供商的平台交互。云控制器管理器是k8s v1.6中引入的!

        云控制器管理器仅运行云提供商特定的(controller loops)控制器循环。可以通过将 “–cloud-provider” flag 设置为 external 启动 kube-controller-manager ,来禁用控制器循环。

cloud-controller-manager 具体功能:

节点(Node)控制器
路由(Route)控制器
Service控制器
卷(Volume)控制器


1.3、Scheduler —— 调度器

        在 k8s 特征中的 “自动装箱” 就是依赖调度器来完成的。

        k8s 是用于部署和管理大规模容器应用的平台,集群规模的不同,其运行的容器数量也不同。当 “API Server” 确认 “Pod” 创建的请求后,然后便由 “Scheduler” 根据集群内节点的可用资源状态,对需要运行的容器的资源需求做出调整决策。 此外,k8s还支持用户自定义调度器。


2、Node 主要组件:

        Node 负责提供运行容器所需的各种依赖环境,并接受 Master 的管理。

        Node 是真正运行业务负载的,每个业务负载会以 “pod” 的形式运行,一个 “pod” 中运行着一个或多个容器。
kubernetes 的 架构 及其 组件:_第3张图片
        kubelet 它是 Node 上最关键的组件!!!它通过 “API Server” 接收到 运行“Pod” 所需要的状态,然后提交给 “Container Runtime(容器运行时)”,然后在 OS 上去创建容器所需要的运行环境,然后把容器运行起来!然鹅,运行容器或 “pod” 也需要对网络和存储进行管理,k8s 并不会直接对网络和存储进行管理,而是通过两个组件“storage plugin” 和 “network plugin” 来对存储和网络进行管理,而 “kube-proxy” 它可以按需为 “Service” 生成 iptables 或 ipvs 规则,从而捕获访问当前 “service” 的 cluster IP 的流量并将其转发至正确的 “Pod” 对象!

所有的 Node 上都有这些组件!

关于 Pod、Service、volume 等资源抽象


2.1、kubelet —— Node 核心代理程序

 
        kubelet 除了 通过 “apiserver” 接收关于 “pod” 对象的配置信息并提交到 “container runtime” 以外, kubelet 还会在 “API Server” 上注册当前的工作节点,定期向 Master 汇报节点的资源使用情况,并通过 “cADvisor” 监控容器和节点的资源占用情况!!!

cadvisor —— 容器性能监控工具。


2.2、container runtime —— 容器运行时环境

 
        通过 kubelet 收到的关于运行 “pod” 的所需状态,然后在 OS 上创建 “pod” 所需的环境。它负责下载镜像并运行容器,kubelet 以插件的方式载入配置的容器环境!

        目前,k8s 所支持的 容器运行环境:Docker(最常见)、RKT、cri-o 等等…

RKT 运行容器,作为docker工具的替代方案。


2.3、 kube-proxy —— iptables规则

 
        “kube-proxy” 它可以按需为 “Service” 生成 iptables 或 ipvs 规则,从而捕获访问当前 “service” 的 cluster IP 的流量并将其转发至正确的 “Pod” 对象!


3、etcd —— 集群状态存储

 
        K8S 集群的所有状态信息都需要持久的存储于 “etcd” 中,而且 “etcd”独立的服务组件,并不属于 k8s 集群自身。生产环境中,应该以 “etcd”集群的方式运行,以确保其服务可用性。

        etcd 不仅可以提供 键值数据存储,而且还提供了 “watch”机制(监听机制),用于监听和推送变更。

        在 k8s 集群中,“etcd” 中的键值发生变化的话,会通知 “API Server”,并由其通过 “watch API”向客户端输出。基于 “watch” 机制,k8s 集群的各组件实现了高效协同!!!


4、其他组件:

        k8s 集群还需要依赖一些其他组件来提供完整的功能,它们通常是由第三方提供的特定应用程序,且托管运行于 k8s 集群之上。


4.1、kubeDNS(CoreDNS)

 
        在 k8s 集群中,调度运行提供 DNS 服务的 “pod”,同一集群中的其他 “pod” 可以使用此 DNS服务 解决主机名问题!

        k8s v1.11 开始默认使用 CoreDNS 项目为集群提供 “服务注册” 和 “服务发现” 的动态名称解析服务,之前的版本用的是 kubeDNS,而 SkyDNS 为更早的项目。


4.2、kubernetes Dashboard

 
        kubernetes 集群的全部功能都要基于 web 的 UI,来管理集群中的应用甚至是集群本身


4.3、Heapster —— 性能分析与监控

 
        是 容器 和 节点 性能监控与分析系统,它收集并解析多种指标数据,eg:资源利用率,生命周期事件等等…
 
        自从 k8s v1.1.2 起,其功能已经由 prometheus 结合其他组件所取代!


4.4、Ingress Controller —— 应用层负载均衡机制

 
Service :是一种工作在 传输层 的负载均衡器;
Ingress:是在 应用层 实现的 HTTP(s) 负载均衡机制。

        但是,ingress 自身并不能进行 “流量穿透”,它仅是一组路由规则的集合,这些规则需要通过 “ingress controller”(ingress 控制器) 来发挥作用!

目前,此类可用项目有:nginx、traefik、haproxy 等…

你可能感兴趣的:(Kubernetes)