我有一个托管在虚拟机服务器(vm1)上的不安全的私有docker注册表。我试图从推送到这个注册表的映像创建一个k8s部署。令人惊讶的是,docker pull命令工作正常,因为我已经用不安全的注册表配置了/etc/docker/daemon.json。
kubectl描述命令的详细错误如下。知道可能出了什么问题吗?
谢谢。
Failed to pull image "vm1:5000/temp/leads:latest": rpc error: code = Unknown desc = failed to pull and unpack image "vm1:5000/temp/leads:latest": failed to resolve reference "vm1:5000/temp/leads:latest": failed to do request: Head "https://vm1:5000/v2/temp/leads/manifests/latest": http: server gave HTTP response to HTTPS client
docker拉命令是
docker pull vm1:5000/temp/leads:latest
k8s清单文件如下:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
namespace: oleads
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: vm1:5000/temp/leads:latest
resources:
requests:
memory: "64Mi"
cpu: 0.5
limits:
memory: "512Mi"
cpu: 0.5
ports:
- containerPort: 8980
imagePullPolicy: Always
我意识到我正在使用的 k3s 的库伯内特斯引擎使用不同的容器运行时。它使用容器而不是泊坞窗。使用 k3s 时,使用专用注册表的配置是不同的。这里提到了它。
我必须在<code>/etc/rancher/k3s/registries中添加的配置。yaml文件是
mirrors:
vm1:5000:
endpoint:
- "http://vm1:5000"
添加此文件后重新启动 k3s 服务解决了问题,k8s 能够从我的私有不安全的 docker 注册表中提取映像。
我们有同样的问题,解决方案可以是用docker deamon添加不安全的注册表。
在/etc/docker/daemon.json中创建一个文件,并添加不安全的注册表详细信息:
{ "insecure-registries":["vm1:5000"] }
并在所有节点上重新启动docker
。
我有一个简单的容器,它由安装在阿尔卑斯山上的OpenLDAP组成。它被安装为以非root用户身份运行。我能够使用我的本地Docker引擎运行容器而没有任何问题。但是,当我将其部署到我们的库伯内特斯系统时,它几乎立即被OOMKill杀死。我尝试在没有任何更改的情况下增加内存。我还查看了pod的内存使用情况,没有发现任何异常。 服务器启动为slapd-d debug-hldap://0.0.0.0:1
我创建了一个docker映像,并将其推入(标记然后推入)本地不安全的docker-registry v2,该v2运行在192.168.99.100:5000/image/name上。 在VM内部的/var/lib/boot2docker/profile上,我向EXTRA_ARGS添加了标志 。 &从在Docker(VM)中运行良好。 _catalog可以从邮递员:获得注册表中的图像。 我将使用以下
我确实部署了单吊舱,自定义docker映像如下: 在开发过程中,我希望推送新的最新版本并更新部署。如果不明确定义标记/版本并为每个构建增加它,就找不到如何做到这一点,并且
我假设没有愚蠢的问题,所以这里有一个我找不到直接答案的问题。 现在的情况 我目前有一个运行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自己处理网络、吊舱和流量。所以我在考虑最确定的部署方案。
据我所知,作业对象应该在一定时间后收获豆荚。但是在我的GKE集群(库伯内特斯1.1.8)上,“kubectl get pods-a”似乎可以列出几天前的豆荚。 所有这些都是使用乔布斯API创建的。 我确实注意到在使用 kubectl 删除作业后,pod 也被删除了。 我在这里主要担心的是,我将在批量作业中在集群上运行成千上万个pod,并且不想让内部待办系统过载。