куда положить?

Посмотри для своей системы

но у меня бубунта и сворм, сегодня на этот же месадж приехал когда в регистри docker login делал

у меня тоже убунта, никак не пойму куда положить $ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.

куда только не положил уже

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

--skip-tags docker

куда только не положил уже

https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate

Не поможет поищи более свежий туториал

у меня тоже убунта, никак не пойму куда положить $ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done.

у меня точно из /usr/local/share/ca-certificate подсосалось

openssl x509 -in foo.pem -inform PEM -out foo.crt — вот этого шага мне не хватало, в первой загугленной ссылке его почему-то не было, спасибо

да, но проблему с etcd это не решило...

а ты передернул etcd?

$ openssl s_client -connect 192.168.117.101:2379 ... verify error:num=20:unable to get local issuer certificate verify return:1 ...

Это сейчас ок?

а ты передернул etcd?

да

Это сейчас ок?

unable to get local issuer certificate — конкретно вот это пропало

139892259767960:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:s3_pkt.c:1487:SSL alert number 42осталось вот это

—trusted-ca-file вижу опцию у etcd

Попробуй с ней

у меня с ней

И на cluster-health выдаёт ошибку в логах нет ничего внятного?

Ошибку сертификата

--skip-tags docker

О, попробую спасибо

$ etcdctl cluster-health failed to check the health of member 1d7b8e70f80b643a on https://192.168.117.101:2379: Get https://192.168.117.101:2379/health: remote error: tls: bad certificate member 1d7b8e70f80b643a is unreachable: [https://192.168.117.101:2379] are all unreachable cluster is unhealthy

в логах ничего такого, за что цеплялся бы глаз

Ну уже другая ошибка :)

Такое ощущение что не тот сертификат используется у etcd

Но я уже гадаю

в логах ничего такого, за что цеплялся бы глаз

--client-cert-auth такая опция у etcd есть?

Ощущение, что etcd ждет что к нему будут коннектиться с клиентским сертификатом

господа, кто нибудь кубеспреем ставил докер на devicemapper'e?

https://docs.docker.com/storage/storagedriver/device-mapper-driver/#configure-direct-lvm-mode-for-production

https://docs.docker.com/storage/storagedriver/device-mapper-driver/#configure-direct-lvm-mode-for-production

Это про докер, тут все понятно

Непонятно может ли кубеспрей настраивать дм вместо оверлея

например?

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

Кубеспрей сам ставит докер в слейвы

docker info

Storage driver: overlay

--client-cert-auth такая опция у etcd есть?

есть

Ну тогда нужен клиенский сертификат)

etcdctl клиентский сертификат можно подпихнуть такими ключами: --cert-file value identify HTTPS client using this SSL certificate file --key-file value identify HTTPS client using this SSL key file

Oracle Fn Соонователь Iron.io, ныне директор по направлению serverless в Oracle, Чед Аримура рассказал подробнее о serverless/FaaS платформе Fn, применяемой для создания инфраструктуры микро и наносервисов, на базе Docker, Kubernetes и написанных на различных языках программирования. https://youtu.be/YgNrGT8pzYw #serverless #FaaS #Go #Golang Ссылки по теме: https://t.me/technologique/1177 https://t.me/technologique/608

Потому что вот https://bugs.openjdk.java.net/browse/JDK-8165852

Не нужно использовать overlay или dm-map. Нужно использовать overlay2.

Не нужно использовать overlay или dm-map. Нужно использовать overlay2.

Интересное замечание

Не нужно использовать overlay или dm-map. Нужно использовать overlay2.

overlay2 точно так же сломает тот код в яве

да, это баг в java

Судя по тамошнему обсуждению - вопросы скорее к overlayfs

Там в конце есть ссылка на патч

как запустить процесс ? если kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: activating (auto-restart) (Result: exit-code) since Сб 2018-02-10 23:59:54 MSK; 131ms ago Docs: http://kubernetes.io/docs/ Process: 14677 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CGROUP_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS (code=exited, status=1/FAILURE) Main PID: 14677 (code=exited, status=1/FAILURE)

@Groga, воспользуйся dpaste.de для такого большого объёма текста, пожалуйста.

Help! https://dpaste.de/Mjmm

кто prometheus operator пользуется?

чет у меня кастомный экспортер не дискаверится ;(

Help! https://dpaste.de/Mjmm

Евгений, вы понимаете что логи которые вы запостили обрезаны?

по обрезку что вы показали я могу предположить что вам может быть поможет это https://github.com/kubernetes/kubernetes/issues/53333#issuecomment-339793601

как можно отладить dns в кубе?

$ kubectl exec -it busybox-855686df5d-tsh44 -- nslookup kubernetes вот это отваливается по таймауту, напечатав, что сервер — 10.32.0.10

$ kubectl exec -it busybox-855686df5d-tsh44 -- nslookup kubernetes вот это отваливается по таймауту, напечатав, что сервер — 10.32.0.10

Вы kube-dns запустили?

Вы kube-dns запустили?

да

$ kubectl -n kube-system exec -it kube-dns-6c857864fb-k6t6f -c kubedns -- curl -I localhost:8081/readiness HTTP/1.1 200 OK

$ kubectl -n kube-system exec -it kube-dns-6c857864fb-k6t6f -c kubedns -- curl -I localhost:8081/readiness HTTP/1.1 200 OK

Тогда посмотрите запущен ли сервис, если да, то посмотрите на правила iptables

Куберовский сервис я имею ввиду

$ kubectl get svc --all-namespaces NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 10.32.0.1 <none> 443/TCP 15h kube-system kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 1h— это имеется ввиду?

а что в правилах надо искать?

$ kubectl get svc --all-namespaces NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 10.32.0.1 <none> 443/TCP 15h kube-system kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 1h— это имеется ввиду?

Ага

а что в правилах надо искать?

Как обрабатывается обращение к 0.10

Kube-proxy тоже работает?

Не пишет ничего в логах? Прав ему хватает?

в целом вроде работает, из ошибок только это: Feb 10 23:26:58 ng40tpcvnf-dp1 kube-proxy[17228]: E0210 23:26:58.961868 17228 proxier.go:1701] Failed to delete stale service IP 10.32.0.10 connections, error: error deleting connection tracking state for UDP service IP: 10.32.0.10, error: error looking for path of conntrack: exec: "conntrack": executable file not found in $PATH

Ага. Ну можно поставить чтобы не ругалось. А так вообще надо проверить насколько все корректно в iptables

Правильный ендпоинт

Вся ли цепочка

KUBE-MARK-MASQ udp -- !10.200.0.0/16 10.32.0.10 /* kube-system/kube-dns:dns cluster IP */ udp dpt:domain KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns cluster IP */ udp dpt:domain KUBE-MARK-MASQ tcp -- !10.200.0.0/16 10.32.0.10 /* kube-system/kube-dns:dns-tcp cluster IP */ tcp dpt:domain KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns-tcp cluster IP */ tcp dpt:domain

Я не вижу тут куда в итоге трафик уходит

Должен быть ip пода где живет кубе днс

Этим заведует kube-proxy

я отфильтровал вывод iptables по ip dns

Ага. Ну разбирайтесь, я все же спать :) да и с Телефона не удобно смотреть на правила.

ok, спасибо, спокойной ночи :)

если из пода не пингуется сервисная сеть, что нужно проверить?

если из пода не пингуется сервисная сеть, что нужно проверить?

она и не должна. идите прямо на порт сервиса

нет никакой сервисной сети

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

сервисная сеть - это виртуальная сеть в нат таблице netfilter

сервис из сервисной сети, это набор правил трансляции, в результате трафик идет в соответствующие поды

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

у меня при попытке резолвинга трафик приходит на под с dns (вижу через tcpdump), но такое ощущение, что ответа от dns не поступает

а если пытаться резолвить с контейнеров kube-dns, резолвит?

сервисы — нет, интернет — да

может быть kube-dns, не может достучаться до api?

в логах есть чо?

в логах все спокойно

вполне может быть, что и не может, но непонятно, что для этого ему нужно