网站建设与管理实施方案,做婚礼邀请函网站,企业网站系统设计与实现,在线开发app的平台你是一个程序员#xff0c;你用代码写了一个博客应用服务#xff0c;并将它部署在了云平台上。 但应用服务太过受欢迎#xff0c;访问量太大#xff0c;经常会挂。 所以你用了一些工具自动重启挂掉的应用服务#xff0c;并且将应用服务部署在了好几个服务器上#xff0c;…你是一个程序员你用代码写了一个博客应用服务并将它部署在了云平台上。 但应用服务太过受欢迎访问量太大经常会挂。 所以你用了一些工具自动重启挂掉的应用服务并且将应用服务部署在了好几个服务器上总算抗住了。 后来你又上线了商城应用服务和语音应用服务随着应用服务变多需求也千奇百怪。有的应用服务不希望被外网访问到有的部署的时候要求内存得大于 xxGB 才能正常跑。 你每次都需要登录到各个服务器上执行手动操作更新。不仅容易出错还贼浪费时间。
原本就没时间找女朋友的你现在哭得更大声了。
那么问题就来了有没有一个办法可以解决上面的问题当然有没有什么是加一个中间层不能解决的如果有那就再加一层。 这次我们要加的中间层叫 Kubernetes。 Kubernetes的位置 Kubernetes 是什么
Kubernetes它是 G 家开源的神器因为单词太长所以我们习惯省略中间 8 个字母简称它为 k8s。 k8s名称的由来 它介于应用服务和服务器之间能够通过策略协调和管理多个应用服务只需要一个 yaml 文件配置定义应用的部署顺序等信息就能自动部署应用到各个服务器上还能让它们挂了自动重启自动扩缩容。
听起来有些厉害它是怎么实现这些功能的呢
Kubernetes 架构原理
为了实现上面的功能Kubernetes 会将我们的服务器划为两部分一部分叫控制平面control plane以前叫master另一部分叫工作节点也就是 Node。简单来说它们的关系就是老板和打工人 用现在流行的说法就是训练师和帕鲁。控制平面负责控制和管理各个 Node而 Node 则负责实际运行各个应用服务。 k8s控制平面和Node的关系 我们依次看下这两者的内部架构。
控制平面内部组件 • 以前我们需要登录到每台服务器上手动执行各种命令现在我们只需要调用 k8s 的提供的 api 接口就能操作这些服务资源这些接口都由 API Server 组件提供。 • 以前我们需要到处看下哪台服务器 cpu 和内存资源充足然后才能部署应用现在这部分决策逻辑由 Scheduler调度器来完成。 • 找到服务器后以前我们会手动创建关闭服务现在这部分功能由 Controller Manager控制器管理器来负责。 • 上面的功能都会产生一些数据这些数据需要被保存起来方便后续做逻辑因此 k8s 还会需要一个存储层用来存放各种数据信息目前是用的 etcd这部分源码实现的很解耦后续可能会扩展支持其他中间件。
以上就是控制平面内部的组件。 k8s控制平面组件 我们接下来再看看 Node 里有哪些组件。
Node 内部组件
Node 是实际的工作节点它既可以是裸机服务器也可以是虚拟机。它会负责实际运行各个应用服务。多个应用服务共享一台 Node 上的内存和 CPU 等计算资源。 Node可以是裸机服务器或虚拟机 在文章开头我们聊到了部署多个应用服务的场景。以前我们需要上传代码到服务器而用了 k8s 之后我们只需要将服务代码打包成Container Image(容器镜像)就能一行命令将它部署。
如果你不了解容器镜像的含义你可以简单理解为它其实就是将应用代码和依赖的系统环境打了个压缩包在任意一台机器上解压这个压缩包就能正常运行服务。为了下载和部署镜像Node 中会有一个 Container runtime 组件。 将容器镜像粗略理解为压缩包 每个应用服务都可以认为是一个 Container容器, 并且大多数时候我们还会为应用服务搭配一个日志收集器 Container 或监控收集器 Container多个 Container 共同组成一个一个 Pod它运行在 Node 上。 一个pod内有多个容器 k8s 可以将 pod 从某个 Node 调度到另一个 Node还能以 pod 为单位去做重启和动态扩缩容的操作。 所以说 Pod 是 k8s 中最小的调度单位。 Node调度Pod 另外前面提到控制平面会用 Controller Manager 通过API Server控制 Node 创建和关闭服务那 Node 也得有个组件能接收到这个命令才能去做这些动作这个组件叫 kubelet它主要负责管理和监控 Pod。最后Node 中还有个 Kube Proxy 它负责 Node 的网络通信功能有了它外部请求就能被转发到 Pod 内。 控制平面和Node的组件 Cluster
控制平面和Node 共同构成了一个 Cluster也就是集群。在公司里我们一般会构建多个集群, 比如测试环境用一个集群生产环境用另外一个集群。同时为了将集群内部的服务暴露给外部用户使用我们一般还会部署一个入口控制器比如 Ingress 控制器比如Nginx它可以提供一个入口让外部用户访问集群内部服务。 生产和测试环境 kubectl 是什么
上面提到说我们可以使用 k8s 提供的 API 去创建服务但问题就来了这是需要我们自己写代码去调用这些 API 吗答案是不需要k8s 为我们准备了一个命令行工具 kubectl我们只需要执行命令它内部就会调用 k8s 的 API。 kubectl调用k8s的API 接下来我们以部署服务为例子看下 k8s 是怎么工作的。
怎么部署服务
首先我们需要编写 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 之后外部请求会先到达 Kubernetes 集群的 Ingress 控制器然后请求会被转发到 Kubernetes 内部的某个 Node 的 Kube Proxy 上再找到对应的 pod然后才是转发到内部容器服务中处理结果原路返回到这就完成了一次服务调用。 用户调用k8s内应用服务的流程 到这里我们就大概了解了 k8s 的工作原理啦它本质上就是应用服务和服务器之间的中间层通过暴露一系列 API 能力让我们简化服务的部署运维流程。
并且不少中大厂基于这些 API 能力搭了自己的服务管理平台程序员不再需要敲 kubectl 命令直接在界面上点点几下就能完成服务的部署和扩容等操作是真的嘎嘎好用。
