Kubernetes 笔记 04 架构是个好东西

Hi,大家好,欢迎大家和我一起学 K8S,这是系列第 4 篇。

任何技术的诞生,都会经历从架构设计到开发测试的过程,好的技术,往往也会有一套好的架构。架构是个好东西,它能帮助我们站在高处看清楚事物的整体结构,避免过早地进入细节而迷失方向。

上篇文章扫清了 K8S 的一些基本概念,今天这篇文章我们就来看看 K8S 的架构。

先上图:

图中包括两种类型的节点:Master 和 Node,每个节点上运行着多种 K8S 服务。

Master 节点

Master 是 K8S 集群的大脑,运行着如下 Daemon 服务:kube-apiserver、kube-controller-manager、kube-scheduler、etcd 等。

API Server

如果把 K8S 环境看作是一个公司,那 API Server 就是这个公司的基础平台部,是公司最为核心的技术能力输出出口。它对外提供 HTTP/HTTPS REST API,统称 K8S API,可以供各类客户端工具(CLI 或 WebUI)、K8S 其他组件,以及第三方的平台接入。对内提供了 K8S 各类资源(如 Pod、Deployment、Service等)的增删改查和监控等操作,是集群内各个功能模块之间数据交互和通信的中心枢纽。

Controller Manager

Controller Manager 更像是公司的人力资源部,负责统筹公司的人员分布。它管理着 K8S 各类资源的生命周期,保证资源处于预期状态,如果现有状态和预期状态不符,它会自动化执行修正。

Controller Manager 由多种 Controller 组成,包括 Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、Service Controller、Token Controller 及 Endpoint Controller 等。每种 Controller 都负责一种具体的资源管控流程,而 Controller Manager 正是这些 Controller 的核心管理者。

Scheduler

Scheduler 则像是公司各个部门的项目经理之类的角色,负责将具体的人力放到他们擅长的位置上,知人善用。具体来说,Scheduler 负责将待调度的 Pod 对象按照特定的调度策略绑定到集群中某个合适的节点上,调度策略会综合考虑集群的拓扑结构、节点的负载情况、以及应用对高可用、性能、数据亲和性的需求。

etcd

etcd 是一个高可用的分布式数据库,负责保存 K8S 的配置信息和各种资源的状态信息。当数据发生变化时,etcd 会及时告知集群中的其他组件。

kubectl

kubectl 是 K8S 的 CLI 工具,这是使用 K8S API 建立的一套命令行工具,使用它,可以非常方便地管理 K8S 集群。

Node 节点

Node 是 K8S 集群的具体执行者,也运行着多种服务,如:kubelet、kube-proxy、container runtime、Pod 网络等。Node 可以看作是 Master 的代理,负责处理 Master 下发到本节点的任务,管理 Pod 和 Pod 中的容器,定期向 Master 汇报自身资源的使用情况。

kubelet

kubelet 更像是部门中各个小组的 Leader,对外从 API Server 拿资源,对内负责小组内各种资源的管理,比如从 Master 拿到 Pod 的具体配置信息(image、Volume 等)之后,kubelet 根据这些信息创建和运行容器。

kube-proxy

kube-proxy 则像穿插在公司各个部门之间的接口人,对内和内部人员沟通,对外协调部门之间的各种事宜,展示部门风采。kube-proxy 作用于 Service,通过前面学习,我们知道 Service 是对一组 Pod 的抽象,统一对外提供某种服务,当外部访问 Service 时,实际上是需要访问 Service 所管辖的 Pod 中的容器,kube-proxy 在这里就是负责将访问 Service 的数据流转发到后端的容器,如果有多个副本,kube-proxy 会实现负载均衡。

cAdvisor

cAdvisor 对 Node 上的资源进行实时监控和性能数据采集,包括 CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况等。cAdvisor 集成在 kubelet 中,当 kubelet 启动时会自动启动 cAdvisor,一个cAdvisor 仅对一台 Node 机器进行监控。

container runtime

container runtime 是真正运行容器的地方,为容器提供运行环境,主流的三种 container runtime 是 lxc、runc 和 rkt,K8S 都支持它们,但常用的事 runc,原因是 runc 是 Docker 默认的 runtime。在 K8S 的容器应用中,Docker 是主流。

OK,K8S 架构介绍就到此为止。

最后,还是继续送书,容器网络专家倪朋飞写的《K8S 指南》电子书,如有需要后台回复“K8S”(之前回复过就不用回复了)。如需加群学习回复“加群”。

下文我们开始对 K8S 的说明书一探究竟。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券