надо лог смотреть опять…

как я понимаю, хелсчек проверяет 8005 порт и на этом благополучно падает

убери из деплоймента хелс чек

ливнес проб и Readiness проб

гитлаб несколько минут стартует….

убери из деплоймента хелс чек

kubectl log gitlab-gitlab-runner-f7c85548-g2dh9 ERROR: Registering runner... failed runner=tQtCbx5U status=couldn't execute POST against http://gitlab-gitlab.default:8005/api/v4/runners: Post http://gitlab-gitlab.default:8005/api/v4/runners: dial tcp 10.233.51.96:8005: i/o timeout PANIC: Failed to register this runner. Perhaps you are having network problems при этом, у меня нигде http://gitlab-gitlab.default: и http://gitlab-gitlab.default не резолвятся

это лог из раннера

а сам гитлаб?

а сам гитлаб?

а сам гитлаб?

перезапускаю сейчас все

а сам гитлаб?

что-то kubectl edit не прокатил

а сам гитлаб?

пересобрал без чеков сейчас такая картина: bash-3.2# kubectl get pods NAME READY STATUS RESTARTS AGE gitlab-gitlab-566f87768f-8pwws 1/1 Running 0 7m gitlab-gitlab-postgresql-5fff4f67bb-h926w 1/1 Running 0 7m gitlab-gitlab-redis-6c88945d56-mpv78 1/1 Running 0 7m gitlab-gitlab-runner-f7c85548-ph46w 0/1 CrashLoopBackOff 5 7m bash-3.2# kubectl log gitlab-gitlab-runner-f7c85548-ph46w W0417 19:14:53.832846 6937 cmd.go:353] log is DEPRECATED and will be removed in a future version. Use logs instead. + cp /scripts/config.toml /etc/gitlab-runner/ + /entrypoint register --non-interactive --executor kubernetes Running in system-mode. ERROR: Registering runner... failed runner=tQtCbx5U status=couldn't execute POST against http://gitlab-gitlab.default:8005/api/v4/runners: Post http://gitlab-gitlab.default:8005/api/v4/runners: dial tcp 10.233.15.158:8005: getsockopt: connection refused PANIC: Failed to register this runner. Perhaps you are having network problems kubectl describe pod gitlab-gitlab-566f87768f-8pwws Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 8m default-scheduler Successfully assigned gitlab-gitlab-566f87768f-8pwws to k8s-master1.gettransfer.cz Normal SuccessfulMountVolume 8m kubelet, k8s-master1.gettransfer.cz MountVolume.SetUp succeeded for volume "default-token-pzl9n" Normal SuccessfulMountVolume 7m kubelet, k8s-master1.gettransfer.cz MountVolume.SetUp succeeded for volume "pvc-62f2de21-4259-11e8-b500-3e30cf2cd22a" Warning FailedMount 6m kubelet, k8s-master1.gettransfer.cz Unable to mount volumes for pod "gitlab-gitlab-566f87768f-8pwws_default(638ecfe5-4259-11e8-898a-3ebe3629b41e)": timeout expired waiting for volumes to attach/mount for pod "default"/"gitlab-gitlab-566f87768f-8pwws". list of unattached/unmounted volumes=[data registry] Normal SuccessfulMountVolume 5m kubelet, k8s-master1.gettransfer.cz MountVolume.SetUp succeeded for volume "pvc-62f9a45f-4259-11e8-b500-3e30cf2cd22a" Normal SuccessfulMountVolume 5m kubelet, k8s-master1.gettransfer.cz MountVolume.SetUp succeeded for volume "pvc-62f599d7-4259-11e8-b500-3e30cf2cd22a" Normal Pulled 5m kubelet, k8s-master1.gettransfer.cz Container image "gitlab/gitlab-ce:10.6.2-ce.0" already present on machine Normal Created 5m kubelet, k8s-master1.gettransfer.cz Created container Normal Started 5m kubelet, k8s-master1.gettransfer.cz Started container

гитлаб работает? веб

гитлаб работает? веб

сек

гитлаб работает? веб

все поднялось после того как проверки отрубил в деплойменте вот только автоматизм не отработал до идельного конца) bash-3.2# kubectl get service -n nginx-ingress nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx LoadBalancer 10.233.55.144 <pending> 80:30727/TCP,443:31475/TCP,22:31668/TCP 17m pending...

всмысле не отработал?

всмысле не отработал?

не выдал external-ip

вроде как нада подождать ип назначится

странный неймспейс у тебя

это точно гитлаба сервис?

это точно гитлаба сервис?

да точно. это игресс в чарте с gitlab шел

чёт портов в два раза меньше стало

сделай дескрайб

это точно гитлаба сервис?

проверял гетлаб курлом а как, например, можно в браузере через kubectl proxy посмотреть на gitlab-gitlab ClusterIP 10.233.15.158 <none> 22/TCP,8065/TCP,8105/TCP,8005/TCP,9090/TCP,80/TCP 31m

приношу извинения, увлекся

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

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

ну он у меня вот что-то не выдает external kubectl get service -n nginx-ingress nginx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx LoadBalancer 10.233.55.144 <pending> 80:30727/TCP,443:31475/TCP,22:31668/TCP 35m

nginx на nodeport надо

а не clusterip

это ведь ингресс контроллер?

а не clusterip

у меня вот такая спека по нему spec: clusterIP: 10.233.55.144 externalTrafficPolicy: Cluster ports: - name: http nodePort: 30727 port: 80 protocol: TCP targetPort: 80 - name: https nodePort: 31475 port: 443 protocol: TCP targetPort: 443 - name: git nodePort: 31668 port: 22 protocol: TCP targetPort: 22 selector: app: nginx sessionAffinity: None type: LoadBalancer status: loadBalancer: {}

вчера видел первый ImagePullBackoff на машине в Калужской области. Сегодня блокировка docker hub докатилась до Москвы. ivan4th@i4mac:~$ telnet registry-1.docker.io 443 Trying 34.200.90.16... ^C

(netbynet)

замечено было, тк не запустился pod с initContainer'ом, где было image: busybox - без тега, следовательно imagePullPolicy в этом случае считается Always. Такое поломается в первую очередь при недоступности registry.

Всем привет! Поды по дефолту в кубере могут друг друга пинговать в flannel?

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

вроде как да

вроде как да

спасибо

У flannel нет же политик

vxlan же

Да и везде по дефолту они выключены везде

vxlan же

Точно не помню, но в пределах одного namespace точно работает

но они же до днс сервиса достукиваются как-то, а он обычно в другом неймспейсе

если он тоже в контейнере офк

Кстати да

Но днс это сервис уже

тоже верно

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

тогда наверное нет :)

тогда наверное нет :)

Я просто не могу пинговать соседние поды)

Да и везде по дефолту они выключены везде

а как "включается"?

Во flannel никак

замечено было, тк не запустился pod с initContainer'ом, где было image: busybox - без тега, следовательно imagePullPolicy в этом случае считается Always. Такое поломается в первую очередь при недоступности registry.

Дефолтный пулл полиси как раз таки IfNotPresent

Дефолтный пулл полиси как раз таки IfNotPresent

если тег указан

Если хотите flannel с политиками то вам в canal :)

а, сорян, глаза не открыл с утра

Если хотите flannel с политиками то вам в canal :)

у меня калика )

Ну да, или calico или romana

отличный способ для дебага, кстати. Без под-под пинга иногда не совсем понятно, чё как

Это как?

Я тут открыл одну (не)очевидную вещь: Любой под может замаунтить любой секрет, даже если его service account не имеет прав по RBAC этот секрет читать. Еще один аргумент в пользу подхода по неймспеймсу на приложение

Это как?

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

Видимо придется искать или писать admission plugin чтобы эту дыру прикрытт

в ролях разве можно указать конкретные секреты?

Я тут открыл одну (не)очевидную вещь: Любой под может замаунтить любой секрет, даже если его service account не имеет прав по RBAC этот секрет читать. Еще один аргумент в пользу подхода по неймспеймсу на приложение

+

Баг репорт отправил?)

Это by design, issue висит с 2015 года где все отцы основатели высказались

в ролях разве можно указать конкретные секреты?

Да, resourceNames: []

Это by design, issue висит с 2015 года где все отцы основатели высказались

а в чем "by design" часть? "дать подержать" поду секрет, который он не может читать?

вот: bash-3.2# kubectl describe pod jenkins-6bc67f99d7-vvkxn | grep IP IP: 10.233.92.147 bash-3.2# kubectl describe pod jenkins-6bc67f99d7-vvkxn | grep Node Node: master/167.99.97.182 bash-3.2# kubectl describe pod gitlab-gitlab-764bd7665-vgx49 | grep IP IP: 10.233.95.50 kubectl describe pod gitlab-gitlab-764bd7665-vgx49 | grep Node Node: node1/159.65.96.125 bash-3.2# kubectl exec -it gitlab-gitlab-764bd7665-vgx49 /bin/bash error: unable to upgrade connection: container not found ("gitlab") bash-3.2# kubectl exec -it jenkins-6bc67f99d7-vvkxn /bin/bash jenkins@jenkins-6bc67f99d7-vvkxn:/$ ping 10.233.92.147 PING 10.233.92.147 (10.233.92.147): 56 data bytes 64 bytes from 10.233.92.147: icmp_seq=0 ttl=64 time=0.055 ms 64 bytes from 10.233.92.147: icmp_seq=1 ttl=64 time=0.116 ms

Прикольно, дженкинс живёт на мастере

Прикольно, дженкинс живёт на мастере

его я поднял из helm с целью быстрой проверки сети из pod а

"нужна быстрая проверка сети... Подниму-ка дженкинс!"

Извините

"нужна быстрая проверка сети... Подниму-ка дженкинс!"

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

Нет, был бы тот же комментарий

Я бы поднял какой-нибудь под с убунтой

Без лишнего софта

Коллеги, кто может мне подсказать. Есть задача развернуть кластер baremetal на виртуалках, соответственно на каждой из трех железок будет виртуалки с набором контейнеров кубера. Вопрос в том, как они должны общаться между собой через железные тачки и не будет ли проблем для flannel при такой конфигурации?

1 мастер, 2 слейва

Мы на железе планиуем бгп

Без всяких ипип туннелей

0_o