от количества данных зависит и интенсивности использования

ELK в вакууме можно и на пятибаксовом ДО запустить

и он даже заработает

но смысл?

только если своп включить

ну, я для тестов поднимал

вот да, в ваакуме все отлино работатет. На реальных же данных - все гораздо затратнее))

Парни, а я чё-то потерял нить) Куда копировать эти ключи? $ openssl genrsa -out admin-key.pem 2048 $ openssl req -new -key admin-key.pem -out admin.csr -subj "/CN=kube-admin" $ openssl x509 -req -in admin.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out admin.pem -days 365

Они нигде в явном виде не используются вроде

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

как не используются? о_О

это ж Root CA

ну

Так а где они должны быть?

в сейфе

в cloud config референса на них нет

это твой CA

certification authority

а понял

локально, на машине, откуда kubectl юзается?

ты им будешь подписывать все пары ключей/сертификатов для etcd и k8s

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

выдержка из манифеста к аписерверу: - --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

Я про admin.pem и admin-key.pem :)

admin.pem и admin-key.pem нужны тебе

ну или коллегам

Крутая схема 👍

чтобы авторизоваться в аписервере

Вроде понял, спасибо

У меня какая-то странная история

Как я вчера понял - была проблема с ключами

Сейчас обновляю ключи, заодно меняю сетевой интерфейс, где будет поднят apiserver

users: - name: bregor user: client-certificate: /Users/bregor/Work/EvilMartians/chef/chef-amplifr/private-cookbooks/chef-kubernetes/ssl/amplifr/bregor.pem client-key: /Users/bregor/Work/EvilMartians/chef/chef-amplifr/private-cookbooks/chef-kubernetes/ssl/amplifr/bregor-key.pem username: bregor

это кусочек ~/.kube/config

моего локального

да понял

bregor => admin?

вот bregor.pem и bregor-key.pem - это твои admin.pem и admin-key.pem

Great, perfectly great :)

а ты его к пользователю зачем заносишь? чтобы залогиниться на одну из нод и там управлять?

мы просто сделали внешнее управление

условно говоря - это логин/пароль

которые kubectl использует, чтобы попасть в аписервер

это да - это я понял)

тогда я не понял вопроса про ноду

ну вот они у тебя в cloud-init

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

да нету у меня cloud-init ;)

у меня убунта

а

уже дискутировали как-то

а вот вижу свой ~/.kube/config :) теперь ещё на 5% ясней

clusters: - cluster: certificate-authority: /Users/bregor/Work/EvilMartians/chef/chef-amplifr/private-cookbooks/chef-kubernetes/ssl/amplifr/ca.pem server: https://ololo:8443 name: amplifr contexts: - context: cluster: amplifr user: bregor name: amplifr-default current-context: amplifr-default

вот на сцену вышел третий ссл-компонент - публичная часть CA

а зачем тебе chef?

а ты предлагаешь мне сотню серверов руками раскатывать?

мсье знает толк в извращениях...

итого, в ~/.kube/config у тебя есть три секции: - clusters - contexts - users (на самом деле больше, но сейчас это не важно) в clusters ты описываешь аписерверы, в виде: name: <тут-любое-сочетание-символов> ca: <путь-к-публичной-части-CA, либо он сам без переносов строк> server: <https://address[:port]>

в users, очевидно, ползатели вида: username: <тут-любое-сочетание-символов> [password: <тут-любое-сочетание-символов>] [client-certificate: <путь-к-публичной-части-клиентского-ключа, либо он сам без переносов строк>] [client-key: <путь-к-публичной-части-клиентского-ключа, либо он сам без переносов строк>]

в contexts живут сочетания кластеров/юзеров в любых позах и названиях например: - context: cluster: amplifr namespace: kube-system user: bregor name: amplifr-system

короче говоря, контексты - это как бы шорткаты к конфигурациям

ключ current-context указывает на контекст, который будет применен в случае, если ты kubectl запустил без указания контекста

можно менять его в конфиге, можно командой $ kubectl config set current-context <ololo>

можно указывать контексты каждый раз при запуске: $ kubectl get po --all-namespaces -o wide -w --context=ololo

например

вы прослушали краткое изложение мануала по конфигурации kubectl

спасибо за внимание

пойду сына покормлю

:))) Спасибо, что ещё раз напомнил, я в курсе всего этого да, не совсем понятно только почему не работает

О, ладно, не отвлекаю, подрастающее поколение наше всё)

Не работает с ошибкой: # kubectl get pods Unable to connect to the server: x509: certificate is valid for x.x.x.x, y.y.y.y, not z.z.z.z

Хотя ключ сгенерировал новый

Поместил его на сервере с kube-apiserver

Рестартанул и даже сделал ребут

Ну оно ж тебе английским по белому говорит, что сертификаты у тебя сгенерированы для других ip/dns

Перегенерируй

Или айпишники другие подставляй

Перегенерировал, разумеется, поэтому и не пойму :)

Это же с kube-apiserver сообщение?