一、修复ImagePullBackOff状态的解决方案 #

从你给出的Pod事件来看，kubelet一直在反复尝试拉取deploy1:1.14.2镜像却持续失败，这就是导致Pod卡在ImagePullBackOff状态的核心原因。下面是具体的排查和解决步骤：

1. 确认镜像存在并同步到minikube环境 #

• 先在本地机器执行docker images，检查是否有deploy1:1.14.2这个镜像。如果没有，先通过Dockerfile构建镜像：

  # 假设Dockerfile在当前工作目录下
  docker build -t deploy1:1.14.2 .
  

• 注意minikube有独立的Docker环境，本地构建的镜像默认不会同步过去，你需要手动加载：

  minikube image load deploy1:1.14.2
  

  或者直接切换到minikube的Docker环境构建镜像，这样镜像会直接保存在minikube内部：

  eval $(minikube docker-env)
  docker build -t deploy1:1.14.2 .
  

2. 调整imagePullPolicy适配本地镜像 #

你的Deployment配置里用了imagePullPolicy: Always，这个策略会强制kubelet每次都从远程仓库拉取镜像。如果你的镜像只在minikube本地存在，建议把这个字段改成IfNotPresent（本地有镜像就用本地的，没有再拉取）或者Never（完全使用本地镜像）：

spec:
  containers:
  - name: your-container-name
    image: deploy1:1.14.2
    imagePullPolicy: IfNotPresent

修改后重新应用Deployment：

minikube kubectl -- apply -f your-deployment.yaml

3. 核对镜像名称和标签的正确性 #

仔细检查YAML里的镜像名、版本号有没有拼写错误——比如大小写、版本号多写/少写一位，这类小失误很容易导致拉取失败。

二、关于service.xml文件的疑问 #

首先要纠正一个认知：Kubernetes里并没有service.xml这种文件哦😉。Kubernetes的Service是通过YAML或JSON格式的配置文件来定义和管理的，而非XML。

在本地minikube环境中：

• 如果你自己创建过Service，对应的配置文件是你自己编写并存在本地的（比如你命名的my-service.yaml），位置就在你保存它的目录里。
• 如果你想查看集群中已存在的Service配置，可以用命令导出：

  # 导出所有Service的YAML配置到本地文件
  minikube kubectl -- get services -o yaml > all-services.yaml
  # 导出单个指定Service的配置
  minikube kubectl -- get service <service-name> -o yaml > target-service.yaml
  

• 另外，Kubernetes集群内部的Service元数据是存储在etcd数据库中的，不会以XML文件的形式出现在你的本地机器上，所以你找不到所谓的service.xml。

如果需要为你的Deployment创建Service，只需要编写一个类似下面的YAML文件（比如my-service.yaml），再用命令创建即可：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: your-deployment-label  # 这里要和你Deployment的labels字段匹配
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080  # 容器内部对外开放的端口
  type: NodePort  # 可选ClusterIP、LoadBalancer，根据需求选择

创建命令：

minikube kubectl -- apply -f my-service.yaml

内容的提问来源于stack exchange，提问作者Sailee Das