# sudo journalctl -u kube-kubelet -f ... Aug 27 20:04:27 loadbal1 kubelet[4486]: I0827 20:04:27.524825 4486 docker_manager.go:2289] checking backoff for container "kube-controller-manager" in pod "kube-controller-manager-xx.xx.xx.17" Aug 27 20:04:27 loadbal1 kubelet[4486]: I0827 20:04:27.524927 4486 docker_manager.go:2303] Back-off 1m20s restarting failed container=kube-controller-manager pod=kube-controller-manager-xx.xx.xx.17_kube-system(716509e2c3062e2e4e8961e47365b1a2) Aug 27 20:04:27 loadbal1 kubelet[4486]: E0827 20:04:27.524963 4486 pod_workers.go:183] Error syncing pod 716509e2c3062e2e4e8961e47365b1a2, skipping: failed to "StartContainer" for "kube-controller-manager" with CrashLoopBackOff: "Back-off 1m20s restarting failed container=kube-controller-manager pod=kube-controller-manager-xx.xx.xx.17_kube-system(716509e2c3062e2e4e8961e47365b1a2)"

и ещё занятно, что kubectl cluster-info dump возвращает список со старым namespaces

Значит не удалил старые данные etcd

Proxy запустился?

$ kubectl get po Что-нить возвращает?

Пустое

Как будто ничего)

А как старые удалить? И надо ли? Мы же ему новый etcd указываем?

Ну может ты его на папку со старыми данными натравил

Евенты появились?

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

Короче, что-то у тебя с kubeconfig.yaml не то

Надо проверять

например kubectl --kubeconfig=/etc/kubernetes/kubeconfig.yaml get ev --all-namespaces

прямо на сервере

скачай туда kubectl просто

потому что все остальное-то в порядке

kubelet запускается сам, запускает все из манифестов

НО

ни сам kubelet, ни те манифесты, которым нужен kubeconfig.yaml, не могут дойти до апи

стопудово говно в kubeconfig'e

давай искать

@DenisIzmaylov ^^^

Всем доброе утро :)

Мы продолжаем свой репортаж с раскопок CoreOS-кластера

Сегодня будем проводить отряд экзорцизма для воскрешения Kubenetes

Под руководством опытного мага Максима Филатова

а говорил, что не пьешь

Сейчас попробую зафетчить events :)

с горя чтоли?

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

почти

:)

обнаружил, что у меня местами был указан kubeconfig.yaml в то время, как я поменял на kubeconfig.yml

просто у нас так принято - .yml для yaml

sed -i 's/yaml/yml/g' /etc/kubernetes/manifests/*

сейчас меняю и обновля

а всё проще - у меня все конфиги в одном cloud-config для CoreOS, она с него инициилизируется

ну или так

полез заливать его на кластеры

можно было вчера уже ansible разобраться и настроить

наверн)

растешь, мой юный падаван

))) век живи - век учись

или never give up

отправил мастер на ребут

зачем?

достаточно было перезапустить kubelet

если манифесты в /etc/kubernetes/manifests/ обновляются, kubelet их сам перезапускает

это CoreOS - здесь так принято, как я понял

или можно как-то содержимое сервис-юнита в памяти менять (все эти ExecStartPre, ExecStart и тд)?

systemctl daemon-reload

перечитывает обновленные юниты

из мана:

Manager Lifecycle Commands: daemon-reload Reload systemd manager configuration daemon-reexec Reexecute systemd manager

дастиш фантастиш 👍

обнаружил, что я тут ещё повредил kubeconfig вчера вечером

думал CoreOS подхватывает переменные в секции content для файлов

Aug 28 10:45:00 loadbal1 kubelet[4503]: I0828 10:45:00.313821 4503 docker_manager.go:2289] checking backoff for container "kube-apiserver" in pod "kube-apiserver-xx.xx.xx.17" Aug 28 10:45:00 loadbal1 kubelet[4503]: I0828 10:45:00.313950 4503 docker_manager.go:2303] Back-off 2m40s restarting failed container=kube-apiserver pod=kube-apiserver-xx.xx.xx.17_kube-system(ba444ee1a5b2518ad107b6d0865a3851) Aug 28 10:45:00 loadbal1 kubelet[4503]: E0828 10:45:00.313982 4503 pod_workers.go:183] Error syncing pod ba444ee1a5b2518ad107b6d0865a3851, skipping: failed to "StartContainer" for "kube-apiserver" with CrashLoopBackOff: "Back-off 2m40s restarting failed container=kube-apiserver pod=kube-apiserver-xx.xx.xx.17_kube-system(ba444ee1a5b2518ad107b6d0865a3851)" Что-то пошло не так

Хотя вроде правильно запускается: - apiserver - --bind-address=0.0.0.0 - --secure-port=6443 - --insecure-bind-address=127.0.0.1 - --insecure-port=8080 - --service-cluster-ip-range=10.100.0.0/24 - --etcd-servers=http://127.0.0.1:3379 - --etcd-certfile=/etc/kubernetes/ssl/apiserver.pem - --etcd-keyfile=/etc/kubernetes/ssl/apiserver-key.pem - --etcd-cafile=/etc/kubernetes/ssl/ca.pem - --storage-backend=etcd3 - --allow-privileged=true - --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota - --runtime-config=extensions/v1beta1=true,extensions/v1beta1/thirdpartyresources=true - --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 - --docker=unix:///var/run/docker.sock - --log-dir=/var/log/kubernetes

curl http://127.0.0.1:3379 что говорит?

на этом сервере

судя по docker ps -a оно не запустилось

кто оно?

curl http://127.0.0.1:3379 404 page not found

охохо

ага, это хорошо

я думал он в докере запускается

etcd поднялся значит

в докере конечно

хотя я хрен знает этот ваш кореос, может там рокет всех поимел

но вот здесь никаких портов вроде не expose-ится)

ну и что?

да так, я думал должно )

expose ни на что не влияет

это для человеков

не для роботов

https://docs.docker.com/engine/reference/builder/#/expose

**EXPOSE does not make the ports of the container accessible to the host.**

я вижу тут прокси, контроллер-менеджер, етцд и еще двоих, которые ушли за экран