Есть дружественная группа @puppet_ru

странно что нет дружественной группы @ansible_ru : по-моему дискриминация по признаку дружественности

жаль, что saltstack_ru

нет

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

в Rkt есть pod manifest

всего лишь нужно положить его на Ceph, как я понимаю

ну и тогда он будет общим для всего кластера

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

во, а я по сабжу еще спрошу - не факт что ответят, но может кто увидит вопросы и захочет на какой-нибудь из них нааписать ответ, будет клево :) в общем, пока играюсь - запустил пару кластеров на локальных машинах и в GKE, щас хочу стажинг переводить и смотреть как себя ведет, наверное документацию плохо пролистал но не нашел ответа или нашел только размытые на такие вопросы: 1) какие полезные юзкейсы у job 2) чем ingress лучше кастомного nginx 3) чем принципиально petset отличается от pod 4) как можно заюзать component statuses в своей инфраструктуре и полезно ли это вообще 5) что такое events и с чем их едят 6) по каким правилам будет действовать несколько limitrages/resourcequotas в одном неймспейсе 7) возможноые юзкейсы serviceaccounts в продакшн-ркди кластерах

Ну скажите ченить ... )

я тоже жду :)

все ждут ))

> какие полезные юзкейсы у job одноразовые калькуляции, например, у тебя кто-то в базе данных напортачил и тебе надо запустить скрипт, меняющий 0 на null > чем ingress лучше кастомного nginx главным образом переносом ответственности, но (насколько понял) он еще в альфе и это скорее проверка гипотезы чем то, чем уже стоит пользоваться > чем принципиально petset отличается от pod от replication controller/set, скорее. pet set может минимально конфигурировать окружение для себя и фиксирует названия подов

вот еще вопрос из министерства дурацких вопросов: я же не могу сделать port mapping внутри пода (сделать так, чтобы порт X пода соответствовал порту Y контейнера, -p aa:bb при обычном workflow докера), только открыть порт пода, соответствующий порту контейнера?

Не пойму, что за проблема может быть - kube-dns висит в состоянии: kube-dns-v18-wz37g 2/3 CrashLoopBackOff 798 13d При это describe говорит примерно следующее: ... Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1d 2m 760 {kubelet xx.xx.xx.xx} spec.containers{kubedns} Normal Started (events with common reason combined) 1d 2m 769 {kubelet xx.xx.xx.xx} spec.containers{kubedns} Normal Pulled Container image "gcr.io/google_containers/kubedns-amd64:1.6" already present on machine 1d 2m 760 {kubelet xx.xx.xx.xx} spec.containers{kubedns} Normal Created (events with common reason combined) 1d 1m 760 {kubelet xx.xx.xx.xx} spec.containers{kubedns} Normal Killing (events with common reason combined) 1d 1m 3076 {kubelet xx.xx.xx.xx} spec.containers{kubedns} Warning Unhealthy Readiness probe failed: Get http://yy.yy.yy.yy:8081/readiness: dial tcp yy.yy.yy.yy:8081: connection refused 1d 1m 769 {kubelet xx.xx.xx.xx} spec.containers{kubedns} Warning Unhealthy Liveness probe failed: HTTP probe failed with statuscode: 503 1d 5s 9393 {kubelet xx.xx.xx.xx} spec.containers{kubedns} Warning BackOff Back-off restarting failed docker container 1d 5s 9371 {kubelet xx.xx.xx.xx} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "kubedns" with CrashLoopBackOff: "Back-off 5m0s restarting failed container=kubedns pod=kube-dns-v18-wz37g_kube-system(552d0562-5fe1-11e6-a399-44a842348b74)"

посмотри в статусе последнее состояние, возможно, OOM почему-то случается

у меня так в свое время дэшборд упал

kubectl logs --namespace=kube-system kube-dns-v18-wz37g -c kubedns показывает что-нибудь?

5 сек

Error from server: a container name must be specified for pod kube-dns-v18-wz37g, choose one of: [kubedns dnsmasq healthz]

ого

много всякого

гистуй

E0825 14:12:50.249289 1 reflector.go:216] pkg/dns/dns.go:155: Failed to list *api.Service: Get https://zz.zz.zz.zz:443/api/v1/services?resourceVersion=0: x509: certificate signed by unknown authority

Я думаю вот это самое важное)

дада

так сказать определяющее

днс до апишечки дойти не может

факоф-фактор

атата

а значит, у тебя неверно формируется дефолт-сикрет

нука покажика kubectl get secrets --namespace=kube-system

и пропал

Я здесь

Я не пропал

и пропал

Походу днс отвалился )

ггг

))

Но вроде всё ок там

что ок?

# kubectl get secrets —namespace=kube-system NAME TYPE DATA AGE basic-auth Opaque 1 24d default-token-ngexf kubernetes.io/service-account-token 3 33d frontend-kube-tls kubernetes.io/tls 2 24d

в дефолт-токене всего один элемент в Data?

Да :) # kubectl describe secret default-token-ngexf --namespace=kube-system Name: default-token-ngexf Namespace: kube-system Labels: <none> Annotations: kubernetes.io/service-account.name=default,kubernetes.io/service-account.uid=065d205b-5027-11e6-b525-44a842348b74 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1099 bytes namespace: 11 bytes token: eyJhbGciOiJSUzI1NiIsInR...

Надо туда ключ добавить ca.pem?

нене, вот же он

ca.crt: 1099 bytes

а это точно тот самый сертификат?

нука вынь его оттуда и разюючь

kubectl get secret default-token-ngexf --namespace=kube-system -o yaml --export

там будет что-то типа: apiVersion: v1 data: ca.crt: <многабукаф> ...

вот эти многабукаф копипасти в какой-нить файл

Так

А зачем ?

и делай cat /куда/ты/там/накопипастил | base64 -D

в итоге будет снова многабукаф, но уже другого вида

И что с этими буквами сделать?

нужно будет убедиться, что эти буквы - буква в букву - совпадают с твоим публичным ключем от CA

Вот это поворот

?

не совпадают?

6 сек

в итоге будет снова многабукаф, но уже другого вида

Да, на выходе получился сертификат)

совпадает с имеющимся?

И он идентичен с тем, что на kube-apiserver (/etc/kubernetes/ssl/ca.pem)

ага

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

это как?)

ERROR: S client not available

https://gist.github.com/Bregor/dbb337e9a3e7b7ba6274d02e78a305bf

вот так

обрати внимание на volumes

добавил kubeconfig.yaml в гист

https://gist.github.com/Bregor/dbb337e9a3e7b7ba6274d02e78a305bf#file-kubeconfig-yaml

Ого, спасибо, не слишком ли hackeable? :)

тебе шашечки или ехать?

Это из за чего такая проблема?

Мне ехать и быстро ))

ну что за вопросы тогда

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

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

вот так: 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'ы запускают

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

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