2016-04-21 19 views
1

Ich habe gekämpft, um api-server 1.2.2 mit gesichert mit TLS zu bekommen.Kubernetes 1.2.2: api-server schlägt fehl: kann nicht gemounteten Zertifikate für TLS auf etcd finden

ich 1.1.2-1.2.2

In 1.1.2 bin ein Upgrade ich die --etcd-config Flagge wurde mit und hatte eine Datei, die aussah:

{ 
    "cluster": { 
    "machines": [ 
     "https://XXX.XXX.XXX.XXX:2379", 
     "https://XXX.XXX.XXX.XXY:2379", 
     "https://XXX.XXX.XXX.XXZ:2379" 
    ] 
    }, 
    "config": { 
    "certFile": "/etc/ssl/etcd/etcd-peer.cert.pem", 
    "keyFile": "/etc/ssl/etcd/private/etcd-peer.key.pem", 
    "caCertFiles": [ 
     "/etc/ssl/etcd/ca-chain.cert.pem" 
    ], 
    "consistency": "STRONG_CONSISTENCY" 
    } 
} 

jetzt ist dies nicht mehr unterstützt und ich wechselte die zur Verwendung von Fahnen:

--etcd-cafile="/etc/ssl/etcd/ca-chain.cert.pem" 
--etcd-certfile="/etc/ssl/etcd/etcd-peer.cert.pem" 
--etcd-keyfile="/etc/ssl/etcd/private/etcd-peer.key.pem"  
--etcd-servers="https://XXX.XXX.XXX.XXX:2379, https://XXX.XXX.XXX.XXY:2379,https://XXX.XXX.XXX.XXZ:2379" 

jetzt diesen Fehler ich erhalte:

F0421 00:54:40.133777  1 server.go:291] Invalid storage version or misconfigured etcd: open "/etc/ssl/etcd/etcd-peer<nodeIP>.cert.pem": no such file or directory 

So scheint es wie es die Cert-Datei nicht finden kann. Die Dateipfade und -namen sind die gleichen wie zuvor, und sie werden mit hostPath genauso wie mit v1.1.2 gemountet, also verstehe ich nicht, warum der api-Server sie nicht finden würde.

Ich habe versucht, Figur, was einfach mit den Dateipfaden geht auf von

die command in der Schote Schalt
- /hyperkube 
- api-server 
... 

zu

- /bin/sleep 
- 60 

aber kubelet wird diese Schote nicht starten Aus irgendeinem Grund verstehe ich nicht.

Hat es mit dem Yaml-Dateinamen oder etwas zu tun?

Ich verstehe nicht, was passiert, warum kubelet nicht mit diesem Befehl ausgeführt wird.

Jede Hilfe mit diesem würde sehr geschätzt werden.

Dank

UPDATE

ich in der Lage war, in den laufenden Behälter zu erhalten, nachdem Sie den Befehl mit /hyperkube scheduler

ersetzt i Katze können die Dateien, die apiserver über beschwert, so I don‘ Ich verstehe, warum sie nicht gefunden werden.

+0

auch hier berichtet: https://github.com/kubernetes/kubernetes/issues/24578 für Querverweis – MrE

+0

Ich habe versucht v1.2.1 und das gleiche Problem. nur 1.1.2 scheint zu funktionieren – MrE

Antwort

0

Nun, der Täter war so einfach wie ""

--etcd-cafile="/etc/ssl/etcd/ca-chain.cert.pem" 
--etcd-certfile="/etc/ssl/etcd/etcd-peer.cert.pem" 
--etcd-keyfile="/etc/ssl/etcd/private/etcd-peer.key.pem"  
--etcd-servers="https://XXX.XXX.XXX.XXX:2379, https://XXX.XXX.XXX.XXY:2379,https://XXX.XXX.XXX.XXZ:2379" 

FALSCH ist

aber dies funktioniert:

--etcd-cafile=/etc/ssl/etcd/ca-chain.cert.pem 
--etcd-certfile=/etc/ssl/etcd/etcd-peer.cert.pem 
--etcd-keyfile=/etc/ssl/etcd/private/etcd-peer.key.pem 
--etcd-servers=https://XXX.XXX.XXX.XXX:2379,https://XXX.XXX.XXX.XXY:2379,https://XXX.XXX.XXX.XXZ:237 
+0

Wenn Sie diese in einem Terminal ausführen, entfernt die Shell hilfreich die Anführungszeichen für Sie, sodass der Apiserver tatsächlich identische Aufrufe für beide sieht.Wenn Sie aus einer Nicht-Shell-Umgebung starten (z. B. Argumente in einem Befehlsarray eines Containers), sollten Sie die Anführungszeichen –

+0

auslassen, danke ... es ist gut zu wissen, war aber leider nicht offensichtlich. – MrE