驯龙高手:Kubernetes,那条驾驭容器云的巨龙

引出

作为一个程序员,假设我写了一个博客应用服务,并把它部署在了云平台上。结果,没想到这个应用服务居然太受欢迎了,访问量大到让服务器直接崩溃!一开始,我只能眼睁睁看着它像多米诺骨牌一样倒下,心里崩溃程度不亚于它。

在这里插入图片描述

于是,我赶紧祭出一些工具,自动重启那些挂掉的应用服务,简直就像给它们打了强心针。然而,这还不够,我决定将应用服务部署在好几个服务器上,让它们来个集体作战。这次总算扛住了访问量的冲击,博客应用服务终于不再频繁崩溃了。

在这里插入图片描述

后来我增加了商城应用服务和语音应用服务,随着应用服务数量的增加,需求也变得多种多样。有的应用服务不希望被外部网络访问,有的在部署时要求内存必须大于某个特定值才能正常运行。每次我都需要登录到各个服务器上,手动进行更新操作,这不仅容易出错,还非常浪费时间。

那么,有没有办法解决这些问题呢?

当然有,没有什么问题是加一个中间层不能解决的,如果有,那就再加一层。这次我们要加的中间层叫 Kubernetes

在这里插入图片描述

K8S是什么?架构原理

Kubernetes,它是 G 家开源的神器,因为单词太长,所以我们习惯省略中间 8 个字母,简称它为 k8s

在这里插入图片描述

它介于应用服务服务器之间,通过策略来协调和管理多个应用服务。只需要一个 YAML 文件配置,定义应用的部署顺序等信息,就能自动部署应用到各个服务器上,还能自动重启挂掉的服务,甚至自动扩展和缩减资源。

听起来很厉害吧,它是怎么做到这些的呢?

为了实现这些功能,Kubernetes 把我们的服务器分成两部分,一部分叫控制平面(control plane,以前叫 master),另一部分叫工作节点(Node)。简单来说,它们的关系就像老板和员工,或者用现在流行的说法,就是训练师和宝可梦。控制平面负责控制和管理各个 Node,而 Node 则负责实际运行各个应用服务。

通过这种方式,Kubernetes 确保了我们的应用服务不仅能自动部署,还能自动扩容和恢复,简直就是应用服务管理的全能助手。

在这里插入图片描述

控制平面内部组件

  • 以前我们需要登录到每台服务器上,手动执行各种命令,现在我们只需要调用 k8s 的提供的 api 接口,就能操作这些服务资源,这些接口都由 API Server 组件提供。
  • 以前我们需要到处看下哪台服务器 cpu 和内存资源充足,然后才能部署应用,现在这部分决策逻辑由Scheduler(调度器) 来完成。
  • 找到服务器后,以前我们会手动创建,关闭服务,现在这部分功能由 Controller Manager(控制器管理器) 来负责。
  • 上面的功能都会产生一些数据,这些数据需要被保存起来,方便后续做逻辑,因此 k8s 还会需要一个存储层,用来存放各种数据信息,目前是用的 etcd,这部分源码实现的很解耦,后续可能会扩展支持其他中间件。
    以上就是控制平面内部的组件。

在这里插入图片描述

Node内部组件

Node 是实际的工作节点,它既可以是裸机服务器,也可以是虚拟机。它会负责实际运行各个应用服务。多个应用服务共享一台 Node 上的内存和 CPU 等计算资源。
在这里插入图片描述

在文章开头,我们提到了部署多个应用服务的情况。以前,我们需要将代码上传到服务器,而现在使用 Kubernetes(k8s)之后,我们只需要将服务代码打包成容器镜像,然后用一行命令就能将它部署。

如果你不清楚容器镜像是什么,可以简单理解为它就是将应用代码和所需的系统环境打包成一个压缩包,在任何一台机器上解压这个压缩包,就能正常运行服务。为了下载和部署镜像,每个 Node 中都会有一个容器运行时组件(Container runtime)。

在这里插入图片描述

每个应用服务都可以认为是一个 Container(容器), 并且大多数时候,我们还会为应用服务搭配一个日志收集器 Container 或监控收集器 Container,多个 Container 共同组成一个一个 Pod,它运行在 Node 上。

在这里插入图片描述

k8s 可以将 pod 从某个 Node 调度到另一个 Node,还能以 pod 为单位去做重启和动态扩缩容的操作。
所以说 Pod 是 k8s 中最小的调度单位

在这里插入图片描述

另外,前面提到控制平面会用 Controller Manager (通过 API Server)控制 Node 创建和关闭服务,那 Node 也得有个组件能接收到这个命令才能去做这些动作,这个组件叫 kubelet,它主要负责管理和监控 Pod。
最后,Node 中还有个 Kube Proxy ,它负责 Node 的网络通信功能,有了它,外部请求就能被转发到 Pod 内。

在这里插入图片描述

控制平面和 Node 共同构成了一个 Cluster,也就是集群。在公司里,我们一般会构建多个集群, 比如测试环境用一个集群,生产环境用另外一个集群。同时,为了将集群内部的服务暴露给外部用户使用,我们一般还会部署一个入口控制器,比如 Ingress 控制器(比如 Nginx),它可以提供一个入口让外部用户访问集群内部服务。

在这里插入图片描述

kubectl 是什么?怎么部署?

上面提到说我们可以使用 k8s 提供的 API 去创建服务,但问题就来了,这是需要我们自己写代码去调用这些 API 吗?
答案是不需要,k8s 为我们准备了一个命令行工具 kubectl,我们只需要执行命令,它内部就会调用 k8s 的 API。

在这里插入图片描述

首先,我们需要编写一个 YAML 文件,其中定义了 Pod 使用的镜像,以及所需的内存和 CPU 等资源配置。接着,我们使用 kubectl 命令行工具执行 kubectl apply -f xx.yaml。这样,kubectl 就会读取并解析这个 YAML 文件,并将解析后的对象通过 API 请求发送到 Kubernetes 控制平面的 API Server。

API Server 接收到请求后,会让 Scheduler 通过 etcd 提供的数据寻找合适的 Node。然后,Controller Manager 会通过 API Server 指挥这些 Node 创建服务。Node 内部的 kubelet 在接收到指令后,会利用 Container runtime 组件拉取镜像并创建容器,最终完成 Pod 的创建。

这样,服务就创建完成了。

在这里插入图片描述

整个过程下来,我们只需要写一遍 yaml 文件,和执行一次 kubectl 命令,比以前省心太多了!
部署完服务后,我们来看下服务是怎么被调用的。

以前外部用户直接在浏览器上发送 http 请求,就能打到我们服务器上的 Nginx,然后转发到部署的服务内。
用了 k8s 之后,外部请求会先到达 k8s 集群的 Ingress 控制器,然后请求会被转发到 k8s 内部的某个 Node 的 Kube Proxy 上,再找到对应的 pod,然后才是转发到内部容器服务中,处理结果原路返回,到这就完成了一次服务调用。

在这里插入图片描述

到这里我们已经大致摸清了 Kubernetes (k8s) 的工作原理。它就像是应用服务和服务器之间的超级助理,通过一系列 API,把原本繁琐的服务部署和运维流程变得简单易行。

很多大中型企业基于这些 API 打造了自己的服务管理平台,程序员不再需要敲 kubectl 命令,只需在界面上点点鼠标,服务的部署和扩容就搞定了,简直是科技界的“点点点”魔法师!

小结

Kubernetes 就像是一条驾驭容器云的巨龙,通过它强大的 API 和自动化能力,我们能够轻松管理复杂的分布式系统,实现高效的资源调度和应用部署。最终,Kubernetes 帮助我们驯服了这条巨龙,让我们在容器云的世界里自由翱翔。

  • 25
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值