2015-10-02 3 views
3

Я пытаюсь принести сервер kubernetes апите с использованием etcd конфигурации (kubernetes использует гоу-etcd, который имеет метод, чтобы прочитать все параметры из конфигурационного файла):Невозможно установки kubernetes против ДУСА обеспеченных etcd

{ 
    "cluster": { 
    "machines": [ "https://my-public-hostname:2379" ] 
    }, 
    "config": { 
    "certFile": "/etc/ssl/etcd/client.pem", 
    "keyFile": "/etc/ssl/etcd/client.key.pem", 
    "caCertFiles": [ 
    "/etc/ssl/etcd/ca.pem" 
    ], 
    "timeout": 5, 
    "consistency": "WEAK" 
    } 
} 

Но сбой в kube-apiserver, потому что он не может достичь и т.д. успешно. Я думаю, это потому, что он пытается синхронизировать кластер ... но я не знаю.

Я создал кластер (etcd), используя внутренние ips для объявлений и адресов клиентов, за исключением URL-адреса listen-client, который установлен на 0.0.0.0/0. Кроме того, весь кластер находится за балансиром нагрузки, который доступен через my-public-hostname.

Внутри контейнера (потому что я использую hyperkube), etcdctl не будет работать, если не установить параметр «--no-sync». Если я использую etcdctl без этого параметра, он подозрительно терпит неудачу, как это делает kube-apiserver. Но я не смог проверить кусок кода в кубернетах, который выполняет кластерную синхронизацию ...

Любые идеи?

Заранее благодарен.

EDIT:

Это, кажется, ошибка, связанная с текущим etcd клиента в kubernetes (https://github.com/coreos/go-etcd), который не является новейшим один (https://github.com/coreos/etcd/client). Я тестировал это эмпирически, и «etcd/client» работает, но «go-etcd» этого не делает, вы можете проверить этот тест здесь: .

Следует отметить, что текущая работа по переносу go-etcd на etcd/client в кубернетах: https://github.com/kubernetes/kubernetes/issues/11962.

Может ли кто-либо из команды Kubernetes подтвердить это?

ПРИЛОЖЕНИЕ 1

Я пытаюсь запустить kubernetes в CoreOS и: flannel работы, locksmithd работы, fleet работы (они имеют доступ к etcd, используя те же самые etcd учетные данные клиента), так что, вероятно, что-то связано с как kubernetes обращается к конечной точке etcd.

ПРИЛОЖЕНИЕ 2 (эти команды выполняются внутри контейнера hyperkube, конкретно этот: gcr.io/google_containers/hyperkube:v1.0.6)

etcdctl без --no-синхронизации не удается вывода этого:

[email protected]:/# etcdctl --cert-file="/etc/ssl/etcd/client.pem" --key-file="/etc/ssl/etcd/client.key.pem" --ca-file="/etc/ssl/etcd/ca.pem" --peers="http//my-public-hostname:2379" ls/
Error: 501: All the given peers are not reachable (failed to propose on members [https://10.1.0.1:2379 https://10.1.0.0:2379 https://10.1.0.2:2379] twice [last error: Get https://10.1.0.0:2379/v2/keys/?quorum=false&recursive=false&sorted=false: dial tcp 10.1.0.0:2379: i/o timeout]) [0] 

И Кубэ-apiserver с этим:

[email protected]:/# /hyperkube \ 
apiserver \ 
--bind-address=0.0.0.0 \ 
--etcd_config=/etc/kubernetes/ssl/etcd.json \ 
--allow-privileged=true \ 
--service-cluster-ip-range=10.3.0.0/24 \ 
--secure_port=443 \ 
--advertise-address=10.0.0.2 \ 
--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota \ 
--tls-cert-file=/etc/kubernetes/ssl/apiserver.pem \ 
--tls-private-key-file=/etc/kubernetes/ssl/apiserver.key.pem \ 
--client-ca-file=/etc/kubernetes/ssl/ca.pem \ 
--service-account-key-file=/etc/kubernetes/ssl/apiserver.key.pem 

F1002 09:47:29.348527 384 controller.go:80] Unable to perform initial IP allocation check: unable to refresh the service IP block: 501: All the given peers are not reachable (failed to propose on members [https://my-public-hostname:2379] twice [last error: Get https://my-public-hostname:2379/v2/keys/registry/ranges/serviceips?quorum=false&recursive=false&sorted=false: dial tcp: i/o timeout]) [0] 

ПРИЛОЖЕНИЕ 3

etcd #0: 
    etcd2: 
    name: etcd0 
    initial-cluster-state: new 
    initial-cluster: etcd0=http://10.1.0.0:2380,etcd1=http://10.1.0.1:2380,etcd2=http://10.1.0.2:2380 
    data-dir: /var/lib/etcd2 
    advertise-client-urls: https://10.1.0.0:2379 
    initial-advertise-peer-urls: http://10.1.0.0:2380 
    listen-client-urls: https://0.0.0.0:2379 
    listen-peer-urls: http://10.1.0.0:2380 
    client-cert-auth: true 
    trusted-ca-file: /etc/ssl/etcd/certs/ca-chain.cert.pem 
    cert-file: /etc/ssl/etcd/certs/etcd-server.cert.pem 
    key-file: /etc/ssl/etcd/private/etcd-server.key.pem 

etcd #1: 
    etcd2: 
    name: etcd1 
    initial-cluster-state: new 
    initial-cluster: etcd0=http://10.1.0.0:2380,etcd1=http://10.1.0.1:2380,etcd2=http://10.1.0.2:2380 
    data-dir: /var/lib/etcd2 
    advertise-client-urls: https://10.1.0.1:2379 
    initial-advertise-peer-urls: http://10.1.0.1:2380 
    listen-client-urls: https://0.0.0.0:2379 
    listen-peer-urls: http://10.1.0.1:2380 
    client-cert-auth: true 
    trusted-ca-file: /etc/ssl/etcd/certs/ca-chain.cert.pem 
    cert-file: /etc/ssl/etcd/certs/etcd-server.cert.pem 
    key-file: /etc/ssl/etcd/private/etcd-server.key.pem 

etcd #2: 
    etcd2: 
    name: etcd2 
    initial-cluster-state: new 
    initial-cluster: etcd0=http://10.1.0.0:2380,etcd1=http://10.1.0.1:2380,etcd2=http://10.1.0.2:2380 
    data-dir: /var/lib/etcd2 
    advertise-client-urls: https://10.1.0.2:2379 
    initial-advertise-peer-urls: http://10.1.0.2:2380 
    listen-client-urls: https://0.0.0.0:2379 
    listen-peer-urls: http://10.1.0.2:2380 
    client-cert-auth: true 
    trusted-ca-file: /etc/ssl/etcd/certs/ca-chain.cert.pem 
    cert-file: /etc/ssl/etcd/certs/etcd-server.cert.pem 
    key-file: /etc/ssl/etcd/private/etcd-server.key.pem 

ответ

2

И наконец, я выясню, что вызывало эту проблему. Тайм-аут не был определен правильно, потому что go-etcd отключает значение тайм-аута json во времени. Продолжительность, которая использует наносекунды в качестве базового блока. Так что для значения 1s должно быть записано 1000000000.

Следуя примеру выше:

{ 
    "cluster": { 
    "machines": [ "https://my-public-hostname:2379" ] 
    }, 
    "config": { 
    "certFile": "/etc/ssl/etcd/client.pem", 
    "keyFile": "/etc/ssl/etcd/client.key.pem", 
    "caCertFiles": [ 
     "/etc/ssl/etcd/ca.pem" 
    ], 
    "timeout": 5000000000, 
    "consistency": "WEAK" 
    } 
} 
+1

Опция '--etcd-конфигурации' был удален: https://github.com/kubernetes/kubernetes/pull/23351 Так что JSON файл конфигурации не будет работать больше. – user2707671

Смежные вопросы