当前位置: 首页 > 知识库问答 >
问题:

ImagePullBackOff错误谷歌库伯内特斯引擎

萧霍英
2023-03-14

我知道很多人已经有类似的问题,我读了其中一些,但没有发现什么实际上帮助我到目前为止。

我有一个支持私有回购的gitlab,我还使用谷歌库伯内特斯引擎。我的私人回购协议中有几个Docker容器,我想将其中一个部署到Kubernetes引擎。

我用kubectl create secret generic db user pass创建了一个秘密——from file=/用户名。txt——来自文件=/暗语txt我还尝试了创建秘密docker注册表名--docker server=registry。xy。z--docker用户名=google--docker密码=xyz--docker电子邮件=xy@z.de然后我创建了我的部署文件:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: backend-test
labels:
app: 13371337
spec:
replicas: 1
template:
metadata:
labels:
app: 13371337
spec:
  containers:
  - name: backend
    image: registry.xy.z/group/project/backend:latest
    imagePullPolicy: Always
    ports:
    - containerPort: 8080
  imagePullSecrets:
  - name: db-user-pass or name

有什么办法让它运行吗?

共有2个答案

闽涵蓄
2023-03-14

为了创建一个秘密,你可以使用以下命令:(注意我给了它一个名字)

kubectl create secret docker-registry my_registry \
--docker-server=registry.xy.z \
--docker-username=google \
--docker-password=xyz \
--docker-email=xy@z.de

或者使用yaml:

apiVersion: v1
kind: Secret
metadata:
  name: my_registry
type: Opaque
data:
  docker-server: registry.xy.z
  docker-username: google
  docker-password: xyz
  docker-email: xy@z.de

您的部署需要使用机密名称:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: backend-test
labels:
app: 13371337
spec:
replicas: 1
template:
metadata:
labels:
app: 13371337
spec:
  containers:
  - name: backend
    image: registry.xy.z/group/project/backend:latest
    imagePullPolicy: Always
    ports:
    - containerPort: 8080
  imagePullSecrets:
  - name: my_registry

注意:必须为每个命名空间创建机密。

澹台庆
2023-03-14

使用kubectl create secret docker registry name是提供私有docker注册表凭据的正确方法。

ImagePullSecrets选项看起来也不错,如果您在那里指定了一个docker-注册表秘密的名称。

所以,从库伯内特斯路径一切看起来不错。

试着检查部署将创建的pod的事件,只需通过kubectl get pods找到你的pod,然后调用kubectl description pod$name_of_your_pod,你就会看到它无法获取图像的实际原因。

此外,如果您的存储库不安全或具有自签名证书,请尝试按照该指南允许docker daemon从那里提取映像,这通常是映像提取失败的原因。

 类似资料:
  • 我遵循了一些指南,我已经用谷歌容器引擎和谷歌容器注册表设置了CI。问题是我的更新没有应用到部署中。 这就是我的部署。yml包含Kubernetes服务和部署: 作为CI过程的一部分,我运行了一个脚本来更新google cloud registry中的图像,然后运行。这两项任务都成功了,我收到通知,部署和服务已更新: 由于我在图像中添加了标记,我以为每次更新部署时都会下载图像。根据文档a也应该是默认

  • 背景: 我对谷歌的云平台很陌生,所以我想确保我没有遗漏任何明显的东西。 我们正在试验GKE和Kubernetes,我们希望通过https公开一些服务。我已经阅读了有关http(s)负载平衡的文档,这些文档似乎建议您应该维护自己的进行SSL终端和负载平衡的nginx实例。对我来说,这看起来相当复杂(我习惯于使用AWS及其负载平衡器(ELB),它支持SSL终止已有很长时间了)。 问题: 如果您只需要在

  • 我一直在使用Postgresql测试Google Cloud SQL,但是我的随机查询需要~3秒而不是几毫秒。 我所做的故障排除: < li >查询本身没有问题,重新运行相同的查询也可以。 < li >索引设置正确。数据库也非常非常小,它不应该这样做,即使没有任何索引。 < Li > Kubernetes容器通过SQL代理连接到数据库(我跟踪了这个https://cloud . Google .

  • 我假设没有愚蠢的问题,所以这里有一个我找不到直接答案的问题。 现在的情况 我目前有一个运行1.15的Kubernetes集群。AKS上的x,通过Terraform部署和管理。AKS最近宣布Azure将在AKS上停用Kubernetes的1.15版本,我需要将集群升级到1.16或更高版本。现在,据我所知,直接在Azure中升级集群不会对集群的内容产生任何影响,即节点、豆荚、秘密和当前在那里的所有其他

  • 我在Kubernetes是个新手。我想知道在kubernetes环境中最好的生产部署场景是什么。 在过去的学派中,我习惯于将Web服务器(例如Nginx或Apache)放在DMZ层,而将其放在其他层(我们称之为层)。这样,只有web服务器在DMZ上,恶意攻击只能在web服务器VM上进行。 据我所知,K8S部署不再需要这种方法;这是因为K8S自己处理网络、吊舱和流量。所以我在考虑最确定的部署方案。

  • 我有一个我想要的EKS集群:-每个集群1个负载均衡器,-入口规则指向正确的命名空间和正确的服务。 我一直遵循这个指南:https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes 我的部署: 这些部署的服务: 我