我有一个Intel NUC（I5）和Raspberry-Pi Model-B。我尝试通过将Intel-NUC作为主节点并将Raspberry-Pi作为工作节点来创建kubernetes集群。当我尝试上述设置时，我看到工作节点一直崩溃。这是输出。只有上述设置才会发生这种情况。如果我尝试使用两个Raspberry-Pis（一个主节点和一个工作节点）创建一个集群，它可以正常工作。
我做错了什么？
sudo kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-ubuntu 1/1 Running 0 13h
kube-system kube-apiserver-ubuntu 1/1 Running 0 13h
kube-system kube-controller-manager-ubuntu 1/1 Running 0 13h
kube-system kube-dns-6f4fd4bdf-fqmmt 3/3 Running 0 13h
kube-system kube-proxy-46ddk 0/1 CrashLoopBackOff 5 3m
kube-system kube-proxy-j48fc 1/1 Running 0 13h
kube-system kube-scheduler-ubuntu 1/1 Running 0 13h
kube-system kubernetes-dashboard-5bd6f767c7-nh6hz 1/1 Running 0 13h
kube-system weave-net-2bnzq 2/2 Running 0 13h
kube-system weave-net-7hr54 1/2 CrashLoopBackOff 3 3m
我检查了kube-proxy的日志，找到了以下条目
Logs from kube-proxy
standard_init_linux.go:178: exec user process caused "exec format error"
这似乎源于这样的问题：拾取的图像是手臂拱形，与x86拱形相对。这是yaml文件
{
"kind": "Pod",
"apiVersion": "v1",
"metadata": {
"name": "kube-proxy-5xc9c",
"generateName": "kube-proxy-",
"namespace": "kube-system",
"selfLink": "/api/v1/namespaces/kube-system/pods/kube-proxy-5xc9c",
"uid": "a227b43b-27ef-11e8-8cf2-b827eb03776e",
"resourceVersion": "22798",
"creationTimestamp": "2018-03-15T01:24:40Z",
"labels": {
"controller-revision-hash": "3203044440",
"k8s-app": "kube-proxy",
"pod-template-generation": "1"
},
"ownerReferences": [
{
"apiVersion": "extensions/v1beta1",
"kind": "DaemonSet",
"name": "kube-proxy",
"uid": "361aca09-27c9-11e8-a102-b827eb03776e",
"controller": true,
"blockOwnerDeletion": true
}
]
},
"spec": {
"volumes": [
{
"name": "kube-proxy",
"configMap": {
"name": "kube-proxy",
"defaultMode": 420
}
},
{
"name": "xtables-lock",
"hostPath": {
"path": "/run/xtables.lock",
"type": "FileOrCreate"
}
},
{
"name": "lib-modules",
"hostPath": {
"path": "/lib/modules",
"type": ""
}
},
{
"name": "kube-proxy-token-kzt5h",
"secret": {
"secretName": "kube-proxy-token-kzt5h",
"defaultMode": 420
}
}
],
"containers": [
{
"name": "kube-proxy",
"image": "gcr.io/google_containers/kube-proxy-arm:v1.9.4",
"command": [
"/usr/local/bin/kube-proxy",
"--config=/var/lib/kube-proxy/config.conf"
],
"resources": {},
"volumeMounts": [
{
"name": "kube-proxy",
"mountPath": "/var/lib/kube-proxy"
},
{
"name": "xtables-lock",
"mountPath": "/run/xtables.lock"
},
{
"name": "lib-modules",
"readOnly": true,
"mountPath": "/lib/modules"
},
{
"name": "kube-proxy-token-kzt5h",
"readOnly": true,
"mountPath": "/var/run/secrets/kubernetes.io/serviceaccount"
}
],
"terminationMessagePath": "/dev/termination-log",
"terminationMessagePolicy": "File",
"imagePullPolicy": "IfNotPresent",
"securityContext": {
"privileged": true
}
}
],
"restartPolicy": "Always",
"terminationGracePeriodSeconds": 30,
"dnsPolicy": "ClusterFirst",
"serviceAccountName": "kube-proxy",
"serviceAccount": "kube-proxy",
"nodeName": "udubuntu",
"hostNetwork": true,
"securityContext": {},
"schedulerName": "default-scheduler",
"tolerations": [
{
"key": "node-role.kubernetes.io/master",
"effect": "NoSchedule"
},
{
"key": "node.cloudprovider.kubernetes.io/uninitialized",
"value": "true",
"effect": "NoSchedule"
},
{
"key": "node.kubernetes.io/not-ready",
"operator": "Exists",
"effect": "NoExecute"
},
{
"key": "node.kubernetes.io/unreachable",
"operator": "Exists",
"effect": "NoExecute"
},
{
"key": "node.kubernetes.io/disk-pressure",
"operator": "Exists",
"effect": "NoSchedule"
},
{
"key": "node.kubernetes.io/memory-pressure",
"operator": "Exists",
"effect": "NoSchedule"
}
]
},
"status": {
"phase": "Running",
"conditions": [
{
"type": "Initialized",
"status": "True",
"lastProbeTime": null,
"lastTransitionTime": "2018-03-15T01:24:45Z"
},
{
"type": "Ready",
"status": "False",
"lastProbeTime": null,
"lastTransitionTime": "2018-03-15T01:35:41Z",
"reason": "ContainersNotReady",
"message": "containers with unready status: [kube-proxy]"
},
{
"type": "PodScheduled",
"status": "True",
"lastProbeTime": null,
"lastTransitionTime": "2018-03-15T01:24:46Z"
}
],
"hostIP": "192.168.178.24",
"podIP": "192.168.178.24",
"startTime": "2018-03-15T01:24:45Z",
"containerStatuses": [
{
"name": "kube-proxy",
"state": {
"waiting": {
"reason": "CrashLoopBackOff",
"message": "Back-off 5m0s restarting failed container=kube-proxy pod=kube-proxy-5xc9c_kube-system(a227b43b-27ef-11e8-8cf2-b827eb03776e)"
}
},
"lastState": {
"terminated": {
"exitCode": 1,
"reason": "Error",
"startedAt": "2018-03-15T01:40:51Z",
"finishedAt": "2018-03-15T01:40:51Z",
"containerID": "docker://866dd8e7175bd71557b9dcfc84716a0f3abd634d5d78c94441f971b8bf24cd0d"
}
},
"ready": false,
"restartCount": 8,
"image": "gcr.io/google_containers/kube-proxy-arm:v1.9.4",
"imageID": "docker-pullable://gcr.io/google_containers/kube-proxy-arm@sha256:c6fa0de67fb6dbbb0009b2e6562860d1f6da96574d23617726e862f35f9344e7",
"containerID": "docker://866dd8e7175bd71557b9dcfc84716a0f3abd634d5d78c94441f971b8bf24cd0d"
}
],
"qosClass": "BestEffort"
}
}
答案 0 :(得分：4)
是的，这是可能的，我刚刚为我的一位客户做过这件事。
基本上存在一个问题，即在主服务器上自动部署的KubeProxy DaemonSet被编译为x64 - 因为您希望主服务器是x64而节点将是ARM。
将ARM节点添加到群集时，DaemonSet会尝试在其上部署x64映像，但会失败。
安装后您需要编辑默认的DaemonSet以仅选择x64节点，并为ARM节点部署另一个DaemonSet。 这个要点将引导您完成： Multiplatform (amd64 and arm) Kubernetes cluster setup
希望这有帮助， 奥菲尔。
答案 1 :(得分：1)
完全可以这样做，但您需要确保在适当的计算机上启动给定cpu体系结构的pod。使用nodeSelector或Node。否则，你会得到你所经历的 - amd64二进制文件无法在arm上运行，反之亦然。
提示：使用beta.kubernetes.io/arch标签区分cpu架构。