操作系统相关知识（运维）

z樾

已于 2024-09-12 11:03:14 修改

阅读量1k

点赞数 12

文章标签： docker 容器运维

于 2024-09-10 11:48:11 首次发布

本文链接：https://blog.csdn.net/weixin_45302337/article/details/142084850

版权

学习自：小白debug ，用作个人笔记，感谢小白

K8s:个人理解就是应用服务和服务器之间的中间层

出现原因：可以借鉴深度学习项目配置环境问题，如果每次都要讲应用手工部署到服务器上面，没有一个自动化部署的工具，那么你面临的不仅是应用代码的上传还需要考虑环境及配置是否有冲突，但是通过容器技术，相当于将应用代码和操作系统直接打包，再部署到服务器上面，并且还能实现自动化的流程，通过一个yaml脚本就能实现，不再需要一句一句敲命令；

出现这种应用服务管理工具，它介于应用服务和服务器之间，能够通过策略，协调和管理多个应用服务，只需要一个 yaml 文件配置，定义应用的部署顺序等信息，就能自动部署应用到各个服务器上，还能让它们挂了自动重启，自动扩缩容。

一、

Kubernetes 会将我们的服务器划为两部分，一部分叫控制平面（control plane，以前叫 master），另一部分叫工作节点，也就是 Node。

控制平面负责控制和管理各个 Node，而 Node 则负责实际运行各个应用服务。

控制平面内部组件

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

Node 内部组件

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

以前都是将程序代码上传到服务器进行部署，现在通过这个中间件就可以将环境依赖和应用代码打包Container Image(容器镜像)一行就可以进行部署。

从Docker学习中可以知道，系统环境其实是操作系统用户空间和一系列配置组成，区别于传统虚拟机，本身并不包含一个完整的操作系统，而是利用namespace使其看起来像一个操作系统；

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

k8s 可以将 pod 从某个 Node 调度到另一个 Node，还能以 pod 为单位去做重启和动态扩缩容的操作。也就是一个或多个Pod组成一个节点，node里面的pod可以被调度。
所以说 Pod 是 k8s 中最小的调度单位。

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

调用服务流程：

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

总结：

Kubernetes 的网络模型定义了以下要求：

所有的 Pod 都能与集群中的其他 Pod 直接通信，无论它们运行在哪个节点上。
所有的节点都能与集群中的所有 Pod 通信。
Pod 自身看到的 IP 地址就是其他 Pod 和节点使用的 IP 地址。

Kubernetes 是位于应用服务与服务器之间的一个管理层，用于自动化部署、管理和扩展容器化应用。与传统的手动将应用代码部署到服务器不同，K8s 通过容器镜像的方式上传和运行应用。每个应用运行在独立的容器中，提供隔离性和可移植性，同时具备自动扩展、负载均衡和故障恢复等能力，从而简化了应用的管理与运维。

容器化应用是指将应用及其运行所需的环境打包成容器镜像，Kubernetes 通过调度和管理这些容器化应用来实现自动化的运维管理。与传统的应用部署方式相比，容器化应用通过打包系统环境和应用，提供了一种轻量级、可移植、易于扩展的方式来部署和管理现代应用服务。

二、

云厂商一般会将一台物理服务器分割成多个虚拟机。它跟我们在 windows 用 VMware, VirtualBox 建的虚拟机其实是一回事。
每个虚拟机都拥有独立的操作系统、资源（比如 CPU、内存、存储空间）和公网 IP 地址。然后对外出售，这样的虚拟机就是所谓的 VPS（Virtual Private Server，虚拟专用服务器）。

就像在VMware虚拟机配置硬件的时候会问你要分配多少核多少内存，这样就将一个物理上的服务器划分为了多个虚拟服务器，出售的就是虚拟服务器；很明显如果你要加配自己是不能完成的，只有厂商可以；

如果给 VPS 加入自主升降级的功能，那它就成了 ECS（Elastic Compute Service，弹性计算服务）

三、Docker

完整的操作系统打包太臃肿，应为应用服务是运行在用户空间上的，因此阉割一部分->形成基础镜像；选中一个基础操作系统和语言后，我们将它们对应的文件系统，依赖库，配置等放一起打包成一个类似压缩包的文件，这就是所谓的基础镜像(Base Image)。

有了Docker （相当于环境）镜像之后需要Dockerfile（运行程序前的基础配置）：只是一份清单，指明要做什么，但是还没有开始做；

有了基础镜像之后还不够，我们经常还需要安装一些依赖，比如yum install gcc，甚至还要创建一些文件夹。最后才是运行我们的目标应用程序。
我们知道 linux 中，所有工作都可以通过命令行完成，所以我们可以将要做的事情以命令行的形式一行行列出来。
就像一份 todo list。
意思是要求在基础镜像的基础上按着 todo list 挨个执行命令。
这份 todo list 长下面这样。

注意 Dockerfile 只是描述了要做哪些事情，并没有真正开始做。
当我们用命令行执行 docker build 的时候，Docker 软件就会按着 Dockerfile 的说明，一行行构建环境+应用程序。最终将这个环境+程序，打包成一个类似"压缩包"的东西，我们叫它容器镜像(container image)。

服务器那么多，挨个将容器镜像传过去也不是不行，就是将压力全给到发送方的网络带宽了。有没有更好的解决方案？
有。可以参考 github 代码仓库的做法，我们通常会使用 git push 将代码传到 github，有需要的人自己通过 git pull 的方式将代码从 github 拉到自己的机器上。

那 Docker 也一样，弄一个镜像仓库，通过 docker push 将镜像推到仓库，有需要的时候再通过 docker pull 将镜像拉到机器上。这个负责管理镜像仓库推拉能力的服务，就叫 Docker Registry。基于 Docker Registry 的能力，我们可以搭建各种官方或私人镜像仓库，比如官方的叫 DockerHub，非官方的有清华大学的 Tuna 等等，一般公司内部也会有自己的镜像仓库。

然后执行 docker run 命令，将这个类似"压缩包"的容器镜像给"解压缩"，获得一个独立的环境和应用程序并运行起来。这样一个独立的环境和应用程序，就是所谓的容器(container)。我们可以在一个操作系统上同时跑多个容器。且这些容器之间都是互相独立，互相隔离的。一个操作系统上面可以跑多个容器

与传统虚拟机不同，并不包含一个完整的操作系统，而只是包含一些依赖库和配置文件，通过namespace使其看起来像一个操作系统，用Cgroup的能力限制它能使用的计算资源。

所以说，容器本质上只是个自带独立运行环境的特殊进程，底层用的其实是宿主机的操作系统内核。

Docker 到底是什么？

主要架构，输入的cmd命令被client解析，调用server守护进程提供的API才进行容器创建和管理；

现在我们再回过头来看这句话，Docker 本质上就是一个将程序和环境打包并运行的工具软件。具体点来说就是，它通过 Dockerfile 描述环境和应用程序的依赖关系， docker build 构建镜像， docker pull/push 跟 Docker Registry 交互实现存储和分发镜像，docker run 命令基于镜像启动容器，基于容器技术运行程序和它对应的环境，从而解决环境依赖导致的各种问题。

总结：

Docker 本质上就是一个将程序和环境打包并运行的工具软件，而 Docker 容器本质上只是个自带独立运行环境的特殊进程，底层用的其实是宿主机的操作系统内核。
Docker 软件通过 Dockerfile 描述环境和应用程序的依赖关系， docker build 构建镜像， docker pull/push 跟 Docker Registry 交互实现存储和分发镜像，docker run 命令基于镜像启动容器，基于容器技术运行程序和它对应的环境，从而解决环境依赖导致的各种问题。
Docker 解决的是一个容器的部署问题，Docker Compose 解决的是多个容器组成的一套服务的部署问题，Docker Swarm 解决的是多个容器组成的一套服务在多台服务器上的部署问题，k8s 则是 Docker Swarm 的竞品，在更高维度上兼容了 Docker 容器，实现了容器编排调度。

K8s是Docker Swarm竞品，记住Swarm即可，解决多个容器组成的一套服务在多服务器上的部署问题