Я пытаюсь принести сервер 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
Опция '--etcd-конфигурации' был удален: https://github.com/kubernetes/kubernetes/pull/23351 Так что JSON файл конфигурации не будет работать больше. – user2707671