七桃资源网

七桃资源网

k8s将容器内文件挂载到外部 k8s容器迁移

qtfan 0 8 次浏览 技术文章
从0到1上手K8s:容器编排的神奇之旅

一、K8s 是什么？

K8s，也就是 Kubernetes，是一个超级强大的开源容器编排平台 。如果把容器比作一个个独立的小盒子，每个盒子里装着不同的应用程序及其运行所需的一切依赖，那么 K8s 就像是一个极其聪明的 “指挥官”，专门负责管理这些 “盒子”。它能自动化地部署、扩展和管理容器化应用程序，让部署容器化的应用变得简单又高效。

在实际的生产环境中，我们的应用往往需要部署多个实例来应对大量的用户请求，实现负载均衡。就好比一家生意火爆的餐厅，为了满足众多顾客的用餐需求，需要开设多个收银窗口和厨房操作间。在 K8s 里，我们可以创建多个容器，每个容器运行一个应用实例，K8s 会通过内置的负载均衡策略，自动帮我们管理这些实例，让它们能被顺利发现和访问，而这些复杂的工作，都不需要运维人员手动去做复杂的配置和处理。

二、为什么要用 K8s？

（一）传统部署方式的痛点

在 K8s 出现之前，我们部署应用的方式主要有插件或脚本安装，以及虚拟机部署 。传统的插件或脚本安装方式，应用的运行、配置、管理和所有生命周期都与当前操作系统紧密绑定。一旦操作系统出现问题，或者需要升级应用，整个过程就会变得异常繁琐，牵一发而动全身。而且，不同的应用之间可能会因为资源竞争而产生冲突，导致运行不稳定。就像在一个拥挤的宿舍里，大家共用有限的水电资源，经常会因为争抢资源而产生矛盾。

再看看虚拟机部署，虽然它能隔离不同的应用程序，提供一定程度的安全性，但缺点也很明显。虚拟机启动和停止的速度较慢，占用的资源还特别高。每一个虚拟机都像是一个庞大的 “巨无霸”，不仅启动时要耗费大量时间，运行时还需要占用大量的内存、CPU 等资源，这就导致服务器的资源利用率很低。而且，虚拟机的可移植性差，从一个环境迁移到另一个环境时，常常会遇到各种兼容性问题，就像把一个巨大的机器从一个房间搬到另一个房间，困难重重。

（二）K8s 带来的优势

K8s 的出现，就像是一道光照进了传统部署的黑暗世界，完美地解决了上述这些痛点。它具备自动化部署、快速扩展收缩、自我修复、服务发现与负载均衡等强大功能 。

在自动化部署方面，K8s 可以通过定义好的配置文件，轻松地将应用部署到集群中的各个节点上，整个过程不需要人工手动干预，大大提高了部署的效率和准确性。就好比有一个智能的快递员，按照事先规划好的路线，把一个个包裹（应用）准确无误地送到各个目的地（节点）。

当业务量突然增加时，K8s 的快速扩展功能就派上用场了。它可以根据预设的规则，自动增加容器的数量，以应对高并发的请求；而当业务量减少时，又能自动收缩容器数量，节省资源。以电商平台为例，在 “双 ” 购物狂欢节期间，大量用户涌入平台，K8s 就会迅速扩展容器，保证平台能够稳定运行，不出现卡顿；而在平时，它又会自动收缩容器，避免资源浪费。

自我修复功能也是 K8s 的一大亮点。如果某个容器出现故障，K8s 会立即发现并自动重启这个容器，或者将其替换为一个新的健康容器，确保服务始终可用。这就像一个 小时待命的医生，时刻守护着应用的健康，一旦发现问题，马上进行治疗。

在服务发现与负载均衡方面，K8s 为每个服务分配一个唯一的 IP 地址和 DNS 名称，让其他服务可以轻松找到它。同时，它还能将流量均匀地分配到各个容器实例上，避免某个容器因为负载过高而崩溃。例如，一个大型的在线游戏，有大量玩家同时在线，K8s 通过负载均衡，将玩家的请求合理地分配到不同的游戏服务器容器上，保证每个玩家都能获得流畅的游戏体验。

三、K8s 的核心组件与工作原理

（一）Master 组件

在 K8s 的世界里，Master 组件就像是一个强大的 “指挥中心”，它由多个关键部分组成，每个部分都肩负着重要使命。

  • kube-apiserver：它是 K8s 集群操作和资源操作的唯一入口，就好比是一座城市的交通枢纽，所有的请求都要通过它来进行调度和处理。它提供了集群管理的 REST API 接口，负责认证授权、数据校验以及集群状态变更等重要任务。同时，它也是其他模块之间数据交互和通信的枢纽，只有它能直接操作 ETCD。想象一下，它就像一个严格的门卫，对每一个进入系统的请求进行身份验证和权限检查，只有合法的请求才能被放行 。
  • ETCD：这是一个分布式键值存储系统，是整个集群的 “大脑”，保存着集群的状态和配置信息。它就像一个超级数据库，存储着集群的整体状态、配置信息和元数据，比如节点信息、Pod 配置、服务定义等。而且，它采用 Raft 一致性算法，确保在多个节点之间数据的一致性和可靠性，即使部分节点出现故障，也能保证数据的完整性 。
  • kube-controller-manager：它是 K8s 里资源对象的自动化控制中心，可以理解为资源对象的 “大总管”。它包含多个控制器，如 Replication Controller、Node Controller 等，负责监听 API Server 中的资源变化，然后通过 API Server 更新集群状态，使其达到期望的状态。例如，当某个 Pod 出现故障时，它会及时发现并采取措施，确保整个集群的稳定运行 。
  • cloud-controller-manager：云控制器管理器，主要负责与云服务提供商进行交互，管理云资源相关的操作。比如，在使用 AWS、Azure 等云平台时，它可以管理云平台提供的负载均衡器、存储卷等资源，实现云环境下的自动化管理 。
  • kube-scheduler：资源的调度进程，相当于公司的调度室，负责将新创建的 Pod 调度到合适的节点上。它会监听未调度的 Pod，综合考虑资源约束、硬件要求、节点的负载情况等因素，通过一系列复杂的算法，选择最合适的节点，然后将 Pod 信息更新到 API Server 。

（二）节点（Node）组件

Node 组件则是 K8s 集群中的 “执行者”，它们运行在各个工作节点上，负责具体的容器管理和网络代理等任务。

  • kubelet：这是每个 Node 节点上的关键进程，负责与 Master 协作管理当前 node 节点，实现集群管理的基本功能，比如负责 Pod 的创建、启停、监控容器状态等任务。它就像一个勤劳的工人，时刻关注着 Node 节点上 Pod 的运行情况，确保它们按照 Master 的指令正常工作。同时，它还会定期向 Master 节点上报自身的情况，如 Docker 版本、CPU、内存、Pod 运行情况等 。
  • kube-proxy：主要负责 Service 的通信与负载均衡，是 K8s 集群内部的负载均衡器。它运行在每个 Node 计算节点上，定时从 ETCD 服务获取 Service 信息，维护网络规则，实现四层负载均衡工作。当 Pod 需要访问一个服务时，它会将请求路由到该服务后端的一个或多个 Pod 上，就像一个智能的交通警察，指挥着网络流量的走向 。
  • docker：即 Docker 引擎，负责本机的容器管理工作，是容器运行的基础。它可以创建、启动、停止容器，管理容器的生命周期。在 K8s 集群中，容器通常是通过 Docker 镜像来运行的，Docker 就像是一个 “魔法盒子”，将应用程序及其依赖项打包成一个可移植的容器，方便在不同的环境中运行 。

（三）工作原理深入浅出

K8s 的工作原理，其实就是这些组件之间相互协作、紧密配合的过程 。当我们通过 kubectl 等工具向 K8s 集群发送一个创建 Pod 的请求时，这个请求首先会到达 kube-apiserver。kube-apiserver 会对请求进行认证和授权，检查请求的合法性。如果请求合法，它会将 Pod 的相关信息存储到 ETCD 中 。

kube-controller-manager 通过监听 API Server，发现有新的 Pod 信息更新，它会执行该资源所依赖的拓扑结构整合，然后将整合后的信息交给 kube-apiserver，kube-apiserver 再将这些信息写入 ETCD。此时，Pod 已经可以被调度了 。

kube-scheduler 同样通过监听 API Server，得知有可调度的 Pod，它会根据各种因素，如节点的资源情况、Pod 的资源需求等，为 Pod 分配合适的 Node 节点，并将 Pod 和对应节点绑定的信息交给 kube-apiserver，kube-apiserver 将这些信息写入 ETCD 后，把 Pod 交给目标 Node 节点上的 kubelet 。

kubelet 收到 Pod 后，会调用标准接口与 Docker 等容器运行时进行交互。它会调用 CNI（容器网络接口）接口给 Pod 创建 Pod 网络，调用 CRI（容器运行时接口）接口去启动容器，调用 CSI（容器存储接口）进行存储卷的挂载 。Docker 根据这些指令，提供容器的运行时环境，启动容器，完成 Pod 的创建 。

当 Pod 创建完成，业务进程启动后，Pod 就开始正常运行了。在这个过程中，kube-proxy 会负责维护网络规则，确保 Pod 之间以及 Pod 与外部的通信能够正常进行，实现负载均衡 。如果在运行过程中，某个 Pod 出现故障，kubelet 会及时发现并上报给 Master，kube-controller-manager 会根据情况采取相应的措施，比如重启故障 Pod 或者创建新的 Pod 来替代它，保证整个集群的稳定和服务的可用性 。

四、K8s 详细使用教程

（一）安装 K8S 集群

这里我们以 Minikube 为例，它是一个能让你在本地运行 Kubernetes 的工具，非常适合用于开发和测试。以下是详细的安装步骤 ：

  1. 下载 Minikube：根据你的操作系统，从 Minikube 官网下载对应的安装包。比如在 Linux 系统中，可以使用以下命令下载：
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
  1. 安装 Minikube：下载完成后，将其安装到指定目录，例如/usr/local/bin：
sudo install minikube-linux-amd64 /usr/local/bin/minikube
  1. 启动 Minikube：安装完成后，使用以下命令启动 Minikube 集群，它会自动创建一个单节点的 Kubernetes 集群 ：
minikube start

启动过程中，Minikube 会自动下载所需的镜像和组件，可能需要一些时间，请耐心等待 。启动成功后，你可以使用kubectl cluster-info命令来验证集群是否正常运行 。如果看到类似如下的输出，说明集群已经成功启动 ：

Kubernetes control plane is running at https://:

CoreDNS is running at https://:/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

（二）创建 Namespace

Namespace 在 K8s 中就像是一个 “虚拟隔离空间”，它的主要作用是将集群内部的资源进行逻辑划分，实现资源隔离和多租户环境。不同 Namespace 中的资源可以使用相同的名称，避免了命名冲突 。例如，在一个大型的 Kubernetes 集群中，可能同时运行着多个项目的应用，每个项目可以使用一个独立的 Namespace，这样各个项目之间的资源就不会相互干扰 。

通过命令行创建 Namespace 非常简单，使用kubectl create namespace命令即可。比如，我们要创建一个名为my - namespace的 Namespace，可以执行以下命令 ：

kubectl create namespace my - namespace

创建完成后，你可以使用kubectl get namespaces命令来查看所有的 Namespace，验证是否创建成功 。如果看到my - namespace在列表中，说明创建成功 ：

NAME              STATUS   AGE

default Active 1h

kube - system Active 1h

kube - public Active 1h

my - namespace Active 10s

（三）部署应用

接下来，我们通过编写 Deployment 的 YAML 文件来部署一个简单的 Nginx 应用 。Deployment 是 K8s 中用于管理 Pod 和 ReplicaSet 的资源对象，它可以确保在任何时候都有指定数量的 Pod 副本在运行 。

首先，创建一个名为nginx - deployment.yaml的文件，内容如下 ：

apiVersion: apps/v1

kind: Deployment

metadata:

name: nginx - deployment

spec:

replicas: 3

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:latest

ports:

- containerPort:

在这个 YAML 文件中：

  • apiVersion指定了 K8s API 的版本 。
  • kind表示资源类型，这里是Deployment 。
  • metadata.name是 Deployment 的名称，这里为nginx - deployment 。
  • spec.replicas指定了要运行的 Pod 副本数量，这里是 3 个 。
  • spec.selector.matchLabels用于选择要管理的 Pod，通过标签app: nginx来匹配 。
  • spec.template定义了 Pod 的模板，包括 Pod 的标签和容器的配置 。这里容器名为nginx，使用的镜像为nginx:latest，并暴露 端口 。

编写好 YAML 文件后，使用kubectl apply命令来部署应用 ：

kubectl apply -f nginx - deployment.yaml

执行命令后，K8s 会根据 YAML 文件的配置创建 Deployment 和对应的 Pod 。你可以使用kubectl get deployments命令查看 Deployment 的状态，使用kubectl get pods命令查看 Pod 的运行情况 。如果 Deployment 的READY列显示3/3，Pod 的STATUS列显示Running，说明部署成功 ：

$ kubectl get deployments

NAME READY UP - TO - DATE AVAILABLE AGE

nginx - deployment 3/ 1m

$ kubectl get pods

NAME READY STATUS RESTARTS AGE

nginx - deployment - 6d9d4c9747 - 5jv5m 1/1 Running 0 1m

nginx - deployment - 6d9d4c9747 - 8978b 1/1 Running 0 1m

nginx - deployment - 6d9d4c9747 - wf87h 1/1 Running 0 1m

（四）水平扩展应用

当业务量增加时，我们需要增加应用的副本数来提高应用的处理能力，这就是水平扩展 。在 K8s 中，使用kubectl scale命令可以非常方便地实现水平扩展 。

比如，我们要将刚才部署的 Nginx 应用的副本数扩展到 5 个，可以执行以下命令 ：

kubectl scale deployment nginx - deployment --replicas = 5

执行命令后，K8s 会自动创建 2 个新的 Pod，使 Nginx 应用的副本数变为 5 个 。你可以再次使用kubectl get pods命令查看 Pod 的数量，验证是否扩展成功 ：

$ kubectl get pods

NAME READY STATUS RESTARTS AGE

nginx - deployment - 6d9d4c9747 - 5jv5m 1/1 Running 0 5m

nginx - deployment - 6d9d4c9747 - 8978b 1/1 Running 0 5m

nginx - deployment - 6d9d4c9747 - wf87h 1/1 Running 0 5m

nginx - deployment - 6d9d4c9747 - bk7f6 1/1 Running 0 10s

nginx - deployment - 6d9d4c9747 - z7v7d 1/1 Running 0 10s

（五）监控应用

为了确保应用的稳定运行，我们需要实时监控应用的运行状态，比如 CPU、内存使用情况等 。在 K8s 中，我们可以利用 Metrics Server 来实现这一功能 。Metrics Server 是 K8s 的一个核心组件，它可以收集集群中各个节点和 Pod 的资源使用指标 。

首先，需要安装 Metrics Server 。可以使用以下命令从官方仓库下载并安装 Metrics Server 的组件 ：

kubectl apply -f https://github.com/kubernetes - sigs/metrics - server/releases/latest/download/components.yaml

安装完成后，等待一段时间，让 Metrics Server 启动并开始收集指标数据 。然后，使用kubectl top命令来查看节点和 Pod 的资源使用情况 。

查看节点的 CPU 和内存使用情况：

kubectl top nodes

查看 Pod 的 CPU 和内存使用情况，假设我们的 Nginx 应用部署在my - namespace Namespace 中：

kubectl top pods -n my - namespace

执行上述命令后，会看到类似如下的输出，显示了每个节点和 Pod 的 CPU 和内存使用情况 ：

$ kubectl top nodes

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%

minikube 100m 5% 600Mi %

$ kubectl top pods -n my - namespace

NAME CPU(cores) MEMORY(bytes)

nginx - deployment - 6d9d4c9747 - 5jv5m 10m 20Mi

nginx - deployment - 6d9d4c9747 - 8978b 10m 20Mi

nginx - deployment - 6d9d4c9747 - wf87h 10m 20Mi

nginx - deployment - 6d9d4c9747 - bk7f6 10m 20Mi

nginx - deployment - 6d9d4c9747 - z7v7d 10m 20Mi

通过这些监控数据，我们可以及时了解应用的运行状态，当发现资源使用过高或过低时，可以采取相应的措施，比如调整资源配额、进行水平扩展或收缩等 。

五、常见问题与解决方法

在使用 K8s 的过程中，难免会遇到一些问题，下面为大家列举一些常见问题及对应的解决方法 ：

（一）Pod 无法启动

  1. 容器镜像拉取失败：这可能是由于镜像名称拼写错误、镜像不存在、网络问题或私有仓库认证问题导致的。解决方法是仔细检查镜像名称是否正确，确认镜像是否存在于指定的仓库。如果是私有仓库，要确保提供了正确的认证信息。同时，检查集群的网络配置是否允许访问外部仓库 。
  1. 容器端口冲突：当容器使用了已被占用的端口时，就会出现这种情况。解决办法是检查 Pod 的端口配置，确认没有与其他正在运行的服务端口冲突。如果端口确实被占用，可以停止占用端口的服务，或者更改容器端口配置 。
  1. 资源不足：节点上的资源（如 CPU、内存、磁盘空间等）不足以启动 Pod 时，Pod 也无法启动。此时，需要查看节点资源使用情况，确认有足够的资源可用。可以调整 Pod 的资源请求和限制配置，如果必要，增加集群中的节点数量 。
  1. 容器启动脚本错误：容器启动时执行的命令或脚本存在问题，也会导致 Pod 无法启动。解决方法是检查容器的command和args是否正确，查看容器的日志输出，寻找错误信息，确保容器内的应用程序能够正确启动 。
  1. 权限问题：比如容器需要的文件或目录不存在，或者容器运行用户没有足够的权限。这时，需要确认容器内的文件和目录存在，并且权限正确，设置容器的用户 ID，确保使用正确的用户运行容器 。
  1. 环境变量配置错误：环境变量未正确设置或值错误，也可能导致 Pod 启动失败。可以检查环境变量是否设置正确，确认环境变量的值符合预期 。
  1. 依赖服务不可用：容器依赖的服务没有启动或没有正确配置，会使 Pod 无法启动。此时，需要检查依赖服务的状态，确保它们已经启动并且可用，确认依赖服务的地址和端口配置正确 。
  1. Pod 规格问题：Pod 的规格配置不符合集群的策略，例如节点亲和性、节点选择器等。需要检查 Pod 的规格配置，确认没有违反集群的策略，修改 Pod 规格，使其符合集群的策略 。

当遇到 Pod 无法启动的问题时，可以按照以下步骤进行排查：

  • 使用kubectl get pods命令查看 Pod 的状态，如果状态显示为Error或者CrashLoopBackOff，则表示可能存在错误 。
  • 使用kubectl describe pod 获取 Pod 的详细信息，包括事件、状态转换历史等 。
  • 使用kubectl logs [-c ]命令查看容器的日志，查找启动时的错误信息 。
  • 如果怀疑是节点资源问题，可以使用kubectl top node或者kubectl describe node 来查看节点的资源使用情况 。
  • 检查容器是否成功拉取镜像，可以使用kubectl get events查看相关事件 。

（二）服务无法访问

  1. Service 状态异常：首先要确认 Service 是否已成功创建并处于正常状态。使用kubectl get svc命令查看 Service 的状态，如果 Service 不存在或者状态异常，需要重新创建或检查配置 。
  1. Pod 状态异常：与 Service 关联的 Pod 必须处于Running和Ready状态，服务才能正常访问。使用kubectl get pods -l app = my - app（其中my - app是与 Service 关联的标签）命令查看 Pod 的状态，如果 Pod 处于CrashLoopBackOff或其他非正常状态，查看其日志，使用kubectl logs 命令排查 Pod 的问题并修复 。
  1. Service 配置错误：查看 Service 的详细信息，确认选择器（selector）是否正确，以及端口配置是否合理。使用kubectl describe svc my - service命令查看 Service 的详细信息，确保选择器正确匹配到相关的 Pod，并且端口配置符合预期 。
  1. 网络策略限制：网络策略（Network Policies）可能限制了 Pod 之间的访问。使用kubectl get networkpolicy命令检查当前命名空间的网络策略，如果存在限制，更新网络策略以允许流量 。
  1. DNS 解析失败：其他 Pod 可能无法通过 Service 名称解析到正确的 IP 地址。确认 CoreDNS 是否正常运行，使用kubectl get pods -n kube - system -l k8s - app = kube - dns命令查看 CoreDNS 的状态，查看 CoreDNS 日志，确认没有错误，使用kubectl logs -n kube - system 命令。在 Pod 内部测试 DNS 解析，使用kubectl exec -it -- nslookup my - service.default.svc.cluster.local命令 。
  1. 防火墙或安全组限制：在云环境中，防火墙或安全组可能阻止了对某些端口的访问。检查云提供商的安全组设置，确保允许访问 NodePort 或 LoadBalancer 的端口 。
  1. 负载均衡器未分配 IP：对于 LoadBalancer 类型的 Service，如果创建后未分配外部 IP 地址，需要检查 Service 的状态，使用kubectl get svc my - service命令，确认 Kubernetes 集群配置了负载均衡器，并查看云提供商的控制台 。
  1. Pod 之间的网络问题：可能存在网络问题，导致 Pod 之间无法通信。使用kubectl exec在 Pod 内部测试网络连接，例如kubectl exec -it -- ping 命令，确保网络插件（如 Calico、Flannel 等）正常运行 。

六、总结与展望

Kubernetes 作为云原生时代的核心技术，已经成为了容器编排领域的事实标准。它的出现，彻底改变了应用的部署和管理方式，让我们能够更加高效、灵活地构建和运行分布式系统 。

通过本文的介绍，相信大家对 K8s 已经有了一个较为全面的了解。从它强大的功能和优势，到核心组件与工作原理，再到详细的使用教程以及常见问题的解决方法，每一个部分都展现了 K8s 的魅力和价值 。

然而，K8s 的世界非常广阔，本文只是冰山一角。希望大家能够以本文为起点，深入学习 K8s，动手实践，将其应用到实际的项目中。在学习和实践的过程中，你会发现 K8s 的更多精彩之处，也会不断提升自己的技术能力 。

展望未来，K8s 将继续发展和演进。随着云原生技术的不断普及，K8s 有望在更多的领域得到应用，进一步推动分布式系统的发展。同时，K8s 社区也在不断努力，开发更多的新功能和特性，提升其性能和易用性 。让我们一起期待 K8s 更加辉煌的明天！

原文链接：，转发请注明来源！
七桃资源网 › 技术文章 › k8s将容器内文件挂载到外部 k8s容器迁移