проблема такая где-то в недрах днса

ты можешь взять любой под и убедиться в том, что сертификат примонтирован

вот так: kubectl exec -it <pod> cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Вот это да

https://coreos.com/kubernetes/docs/latest/deploy-addons.html

это вот оно да?

если у тебя в каком-нить контейнере есть curl, то сделай дополнительную проверку: kubectl exec -it <pod-with-curl> curl https://<apiserver>:443/ # тут должна быть ошибка про х509 kubectl exec -it <pod-with-curl> curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://<apiserver>:443/ # теперь должно стать "unauthorized"

если в обоих случаях будет про х509, то значит ты косо настроил аписервер

А вот сейчас и проверим :) насколько это всё было по японски)

Unauthorized 🎉

Угу

Ну тогда делай как я

Максим, а можешь рассказать, как это работает? volumes: - name: ssl-certs-kubernetes hostPath: path: /etc/kubernetes/ssl - name: kubeconfig hostPath: path: /etc/kubernetes/kubeconfig.yaml

прям по мануалу

монтирует папки с дисков

странно, что в CoreOS-мануале этого нет

Там оно через etcdпохоже

ну у них не принято на диски файлы раскладывать

доставлять-то нечем

хотя я не знаю, как они без этого kubelet'ы запускают

им же тоже нужны ключи

так что как-то они их доставили

да ну, вот же

https://coreos.com/kubernetes/docs/latest/deploy-workers.html

TLS Assets Place the TLS keypairs generated previously in the following locations. Note that each keypair is unique and should be installed on the worker node it was generated for: File: /etc/kubernetes/ssl/ca.pem File: /etc/kubernetes/ssl/${WORKER_FQDN}-worker.pem File: /etc/kubernetes/ssl/${WORKER_FQDN}-worker-key.pem

так что у тебя это все тоже есть

монтируй и не лечи меня :D

Народ, а вы как сеть настраивали ? Opevswitch ?

Хочу поднять кубер на centos

Или как и в coreos через flannel ?

Да

https://coreos.com/kubernetes/docs/latest/

У меня Ubuntu + weave

@DenisIzmaylov ну чего, запустил днс?

чё-то не догоняю)

пытаюсь понять, как и что по мануалу, который ты скинул

всмысле?

примонтировал одну папку и один файл и поменял параметры запуска у kubedns

всё

В официальном мануале какой-то /usr/lib/coreos/kubelet-wrapper

и?

Сейчас у меня кублет запускается как: ExecStart=/opt/bin/kubelet \ --address=0.0.0.0 \ --port=10250 \ --hostname-override=${COREOS_PRIVATE_IPV4} \ --api-servers=${COREOS_PRIVATE_IPV4}:8080 \ --allow-privileged=true \ --logtostderr=true \ --cadvisor-port=4194 \ --healthz-bind-address=0.0.0.0 \ --tls-cert-file=/etc/kubernetes/ssl/minion1.pem \ --tls-private-key-file=/etc/kubernetes/ssl/minion1-key.pem \ --cluster-dns=xx.xx.xx.xx \ --cluster-domain="kube.local" \ --healthz-port=10248

т.е. сами серты прикреплены

кроме ca.pem

а как они без него валидируются? о_О

anyway, не важно

файлы на хосте есть

просто используй их

Как я понял надо запушить: apiVersion: v1 kind: Config clusters: - name: local cluster: certificate-authority: /etc/kubernetes/ssl/ca.pem users: - name: kubelet user: client-certificate: /etc/kubernetes/ssl/worker.pem client-key: /etc/kubernetes/ssl/worker-key.pem contexts: - context: cluster: local user: kubelet name: kubelet-context current-context: kubelet-context

Да, серты локально есть на каждом миньоне, они в разделе write_files файла cloud-config

https://github.com/coreos/coreos-overlay/blob/master/app-admin/kubelet-wrapper/files/kubelet-wrapper

Так к чему пришли, стейтфул сервисы бесполезно контейнеризировать? все эти флокеры просто так навыдумывали?

всегда от конкретного кейса зависит

контейнеризировать нагруженную SQL-базу - это боль

старайтесь по возможности этого избегать

контейнеризировать сервис по обработке картиночек с кеширующим nginx'ом - почему бы и нет

А что значит нагруженную?

Ну мы же про хранение, значит и нагрузка нас интересует прежде всего на диски

Важно понимать хотя бы примерно, сколько иопсов мы получим с конкретной инсталляции распределенной фс

И самое важное - нужно понимать это ДО начала кон ейнеризации базы

ну то есть речь об оверхэде на фс?

а не контейнеризации самой по себе?

Ну в основном да, конечно. Перфоманс базы не в последнюю очередь зависит от скорости стораджа

И тут начинается время приключений

ну мб для всяких риаков и касандр это менее критично

Может быть мне как-то клинически не везёт, но я ни разу не видел ещё стабильно повторяющихся показателей при нагрузочном тестировании ни сефа, ни гластера, ни люстры

Причём расхождения порой на половину

И на это наливать продуктовую базу?..

Может в облаке стоит смотреть на блок стораджи, а не на кластерные фс?

На блок-стораж постгрес не натянешь

Слишком медленно?

Тут надо либо классическую базу на что-то клауд-ориентед менять

Либо уже не тащить её в облако

Всё это - лишь мнение

Моё и моих коллег

Я не претендую на истину в последней инстанции

Классику уже давно не юзал, сказать не могу.

а что может заменить PostgreSQL так, чтобы сохранились преимущества PostgreSQL... то есть для реляционных данных, с хорошим языком запросов, достаточно простая в обслуживании

вариантов-то нет

а что может заменить PostgreSQL так, чтобы сохранились преимущества PostgreSQL... то есть для реляционных данных, с хорошим языком запросов, достаточно простая в обслуживании

в теории Percona XtraDB Cluster - маштабируется , синхранизируется и писать в любую ноду дает https://www.percona.com/software/mysql-database/percona-xtradb-cluster