K8s 长什么样？一文道清它的整体架构

最新推荐文章于 2024-09-25 16:41:59 发布

煎鱼（EDDYCJY）

最新推荐文章于 2024-09-25 16:41:59 发布

阅读量783

点赞数

文章标签：编程语言 kubernetes java docker 分布式

原文链接：https://mp.weixin.qq.com/s?__biz=MzUxMDI4MDc1NA==&mid=2247495879&idx=2&sn=d94f83682bbba76e2477104d34fdbd9d&chksm=f907e59ace706c8c5f7e3d74111a8372d7af801b149defcb5a5a76c9baacd36c0cd0e06d2e89&scene=126&&sessionid=0

版权

2020年开始我在公众号上分享 K8s 学习笔记的时候属于边学边写，每学会一块内容，记录总结发布在公众号上。如今回看，发现很多内容、知识点写的过于生硬，很多名词不知道是干什么的，就直接翻译了过来，这就导致文字没有温度，内容层次也不够。

所以尝试重新组织语言、文章段落，把 K8s 的这些知识写的更有层次些，让大家更容易读懂，更有温度，不再是觉得对文档的翻译和概念的堆砌。

我整理了以下大致脉络，预计用五篇文章推送给大家。

K8s基础入门和实践--大纲

前三篇理论，后两篇实践，理论篇也会有一些例子，不会让文章内容太枯燥。其实之前已经写过一篇 Docker 与 K8s 的关系，算是进入K8s学习之前的预热，先分清两者的关系。

本篇文章聚焦K8s的整体架构，给大家描绘出K8s的大致模样。

K8s 是什么

Kubernetes（单词太长，后面用 K8s 代替）是一个基于容器技术的分布式架构方案，它源自Google内部大规模集群管理系统——Borg，自2015年开源后得到开源社群的全力支援，IBM、惠普、微软、RedHat等业界巨头纷纷加入，成为后来的 CNCF 组织（Cloud Native Computing Foundation，云原生计算基金会）首个毕业的项目。

K8s 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和线上扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

总结一句话：是一套结合了容器编排和集群调度管理的大规模分布式系统解决方案。

K8s 长什么样子

K8s 不是我们现实可以看到摸到的一个东西，所以初学者看完 K8s 是什么的描述后，可能也是觉得云里雾里。那么这里我就尝试描绘一下 K8s 它到底长什么样子。描述一个解决方案的样貌，其实直白点说就是它的整体架构是什么样的，由哪些核心部分组成，每个部分相互怎么交互这些。

我们先来看一下K8s的整体的结构。

K8s 的整体结构

K8s 采用Master / Work Node（最初称为Minion，后改名Node）的结构，Master Node（主节点）控制整个集群，Work Node（从节点）为集群提供计算能力。使用者可以通过命令行或者 Web 控制台页面的方式来操作集群。

下图可以清楚地表示出 K8s 的整体架构

K8s 的整体架构图

了解到 K8s 由主节点、工作节点两大部分组成后，接下来我们逐一展开，看看主节点和工作节点分别由哪些组件构成。

主节点

Master 节点是 K8s 集群的大脑，负责向外开放集群的 API，调度和管理整个集群。集群至少要有一个Master节点，如果在生产环境中要达到高可用，还需要配置 Master 集群。

下面这张图，描绘出了主节点内部的结构。

K8s主节点内部结构

Master主要包含 API Server、Scheduler、Controllers 三个组成部分，以及用作存储的 etcd，它用来储存整个集群的状态。

etcd：由CoreOS开发，是一个高可用、强一致性的键值存储，为Kubernetes集群提供储存服务，类似于zookeper。它会存储集群的整个配置和状态。主节点通过查询 etcd 以检查节点，容器的现状。
API Server：kubernetes最重要的核心元件之一，提供资源操作的唯一入口（其他模块通过API Server查询或修改资源对象，只有API Server才能直接操作etcd），并提供认证、授权、访问控制、API注册和发现等机制。
Scheduler：负责资源的调度，按照预定的调度策略将 Pod（k8s中调度的基本单位）调度到相应的Node上，这里说的 Node 就是Work Node，当然如果是只有一个节点的集群，Master 也会同时作为 Work Node。
Controllers：通过 API Server 查询要控制的资源对象的预期状态，它检查其管控的对象的当前状态，确保它们始终处于预期的工作状态，它们的工作包括比如故障检测、自动扩充、减少、滚动更新等。

我们能接触到的控制器有，下面这些：

- Deployment
- StatuefulSet
- Service
- DaemonSet
- Ingress

具体干什么的，放到下篇文章—K8s面向对象再详细介绍，没错想用K8s，你也得面向对象，可怕不。到时候会结合着例子一块看。

我们继续看K8s 的工作节点的内部结构。

工作节点

K8s 集群的工作节点，可以是物理机也可以是虚拟机器。Node 上运行的主要 K8s 组件有kubelet、kube-proxy、Container Runtime 、Pod 等。

K8s 工作节点的内部结构

kubelet

K8s 集群的每个工作节点上都会运行一个 kubelet 程序维护容器的生命周期，它接收并执行Master 节点发来的指令，管理节点上的 Pod 及 Pod 中的容器。同时也负责Volume（CVI）和网络（CNI）的管理。

每个 kubelet 程序会在 API Server 上注册节点自身的信息，定期向Master节点汇报自身节点的资源使用情况，并通过cAdvisor监控节点和容器的资源。

通过运行 kubelet，节点将自身的 CPU，RAM 和存储等计算机资源变成集群的一部分，相当于是放进了集群统一的资源管理池中，交由 Master 统一调配。

Container Runtime

容器运行时负责与容器实现进行通信，完成像容器镜像库中拉取镜像，然后启动和停止容器等操作，引入容器运行时另外一个原因是让 K8s 的架构与具体的某一个容器实现解耦，不光是 Docker 能运行在 K8s 之上，同样也让K8s 的发展按自己的节奏进行。

想要运行在我的生态里的容器，请实现我的CRI （Container Runtime Interface），Container Runtime 只负责调用CRI 里定义的方法完成容器管理，不单独执行 docker run 之类的操作。这个也是K8s 发现Docker 制约了它的发展在 1.5 后引入的。