fork/exec /usr/bin/rkt:权限被拒绝
fork/exec /usr/bin/rkt:权限被拒绝
提问于 2017-03-11 21:35:59
我在试着安装Kubernetes。
配置详细信息：
控制器
- OS: Container由CoreOS alpha (1339.0.0)
- 局域网IP: 192.168.1.2
- FQDN: coreos-2.tux-in.com
- 用于安装的环境变量： 出口主机_FQDN=coreos-2.tux-in.com出口MASTER_IP=192.168.1.2 WORKER_IP=192.168.1.3 export _FQDN=coreos-3.tux-in.com出口ETCD_ENDPOINTS=http://127.0.0.1:4001出口ADVERTISE_IP=192.168.1.2出口K8S_VER=v1.5.4_coreos.0 ADVERTISE_IP=192.168.1.2 K8S_VER=v1.5.4_coreos.0 ADVERTISE_IP=192.168.1.2 K8S_VER=v1.5.4_coreos.0 export _REPO=quay.io/coreos/hyperkube export _NETWORK=10.2.0.0/16出口服务_IP_RANGE=10.0.0 3.24出口K8S_SERVICE_IP=10.3.0出口.1 DNS_SERVICE_IP=10.3.0.10 USE_CALICO=true USE_CALICO=true CONTAINER_RUNTIME=rkt EMAIL="kfirufk@gmail.com“export uuid_file=/var/run/kubelet-pod.uid
工人
- OS: Container由CoreOS alpha (1339.0.0)
- 局域网IP: 192.168.1.3
- FQDN: coreos-3.tux-in.com
- 用于安装的环境变量 出口ETCD_ENDPOINTS=http://127.0.0.1:4001出口CONTROLLER_ENDPOINT=https://coreos-2.tux-in.com出口ADVERTISE_IP=192.168.1.3出口K8S_VER=v1.5.4_coreos.0出口hyperkube_bin_REPO=quay.io/coreos/hyperkube export POD_NETWORK=10.2.0.0/16出口USE_CALICO=true出口CONTAINER_RUNTIME=rkt出口EMAIL="kfirufk@gmail.com“出口uuid_file=/var/run/kubelet-pod.uid”export CALICO_OPTS=“-数量cni，kind=host，源=/opt/cni/bin\-装入卷=cni，target=/opt/cni/bin“
我使用我的coreos-kubernetes叉来安装控制器和工作人员(https://github.com/kfirufk/coreos-kubernetes)。
控制器节点运行良好，但是工作节点在试图对kubernetes告诉它执行的每个映像运行rkt时会抱怨permission denied。
例如：
Mar 11 21:34:58 coreos-3.tux-in.com kubelet-wrapper[10203]: E0311 21:34:58.654536 10203 pod_workers.go:184] Error syncing pod ac3615637dcb614ace172dc5c5dd85f3, skipping: failed to SyncPod: failed to run [prepare --quiet --pod-manifest /tmp/manifest-kube-proxy-192.168.1.3-986457484 --stage1-name=coreos.com/rkt/stage1-fly]: fork/exec /usr/bin/rkt: permission denied有什么想法吗？
回答 1
Stack Overflow用户
回答已采纳
发布于 2017-03-11 21:57:19
这是个简单的问题。
我指出kubelet.service使用包含以下内容的/opt/bin/host-rkt运行rkt：
#!/bin/sh
# This is bind mounted into the kubelet rootfs and all rkt shell-outs go
# through this rkt wrapper. It essentially enters the host mount namespace
# (which it is already in) only for the purpose of breaking out of the chroot
# before calling rkt. It makes things like rkt gc work and avoids bind mounting
# in certain rkt filesystem dependancies into the kubelet rootfs. This can
# eventually be obviated when the write-api stuff gets upstream and rkt gc is
# through the api-server. Related issue:
# https://github.com/coreos/rkt/issues/2878
exec nsenter -m -u -i -n -p -t 1 -- /usr/bin/rkt "$@"而且没有可执行文件的许可。就这样..。一个简单的chmod +x /opt/bin/host-rkt解决了这个问题:)
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/42740925
复制相关文章
相似问题
腾讯云开发者
