Чисто дедуктивно. В доке приводится в пример Amazon AZ в одном регионе. Погуглил среднее время пинга между AZ. медиана = 2ms, 90p = 30 ms, 99 = 47ms
🤔
Knyage
Aleksey
ага. а как тогда решается вопрос изменился ключ в etcd HUP ни сервис ?
G72K
самое близкое - научить сервис делать релоад по запросу на какой-нибудь админский порт. тогда можно рядом крутить sidecar container, который смотрит за etcd и делает curl на 127.0.0.1
G72K
ну или использовать s6-overlay чтобы крытить несколько процессов в одном контейнере, тогда они сигналы друг другу смогу слать
Aleksey
нее. процессы уже декомпозированы
G72K
всегда можно добавить еще
G72K
если само приложение не умеет следить за etcd, всегда кто-то должен делать это за него
Aleksey
ну врятли можно научить nginx следить за etcd
bebebe
можно, но не нужно
Aleksey
а прикручивание чего то типа confd ?
Aleksey
ага
Aleksey
тоесть очевидные варианты
G72K
просто без s6-overlay нескольок процессов в одном контейнере запустить корректно вряд ли получится
G72K
или какого-нибудь supervisord
Aleksey
ну вообще есть consul-template и его exec mode
Aleksey
но не хочется стек хашикорпа тащить в кубер
Aleksey
хочу понять бестпрактис
Aleksey
ну я под темплейтом запускал nginx
Aleksey
довольно тривиально получатеся
Aleksey
ща
Aleksey
https://gist.github.com/freeseacher/47feebc4cd07e3edbfdb4b050901c3f4
Роман
maxUnavailable считается по количеству ready
А ещё вопросик: readinessProbe через каждые 10 секунд - после того, как под в состоянии ready, проверка тоже будет продолжаться? Это даёт хоть какую-нибудь нагрузку?
G72K
проверка будет продолжаться
Denis
нет же
Denis
дальше livenessProbe включается
Denis
можно в сорсах посмотреть
Denis
So, unlike liveness probes, if a container fails the readiness check, it will not be killed or restarted. This is an important distinction between liveness and readiness probes. Liveness probes keep pods healthy by killing off unhealthy containers and replacing them with new, healthy ones, whereas readiness probes simply make sure that only pods that are ready to serve requests actually receive them. This is mostly necessary during container start up, but it is also very useful later - after the container has been running for a while.
Denis
If a pod reports that it’s not ready, it is removed from the service. If the pod then becomes ready again, it is re-added.
Dmitry
кто пользовался taint? Стоит задача деплоить только на одну ноду определенный депйломент, и запрещать туда ехать другим. Я сейчас делаю dedicated=mynamespace:NoScheldue на ноду, потом на эту ноду вешаю mylabel=true, потом делаю в дейпломенте nodeselector mylabel=true и деплою в нейсмпейс mynamespace. После приезда оно пишет
No nodes are available that match all of the following predicates:: MatchNodeSelector (7), PodToleratesNodeTaints (4).
G72K
надо taints tolerations прописать в под
Dmitry
в деплойменте, именно в раздел containers ?
G72K
это часть PodSpec ,т.е на одном уровне с описанием контейнеров
G72K
tolerations:
- operator: Exists
effect: NoSchedule
- operator: Exists
effect: NoExecute
- operator: Exists
key: CriticalAddonsOnly
G72K
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
Dmitry
- key: "mynamespace"
operator: "Equal"
value: "true"
effect: "NoSchedule"
на поде
Dmitry
так?
G72K
key: dedicated
operator: Equal
value: mynamespace
effect: NoSchedule
Vadim
а какой докер ставить для k8s 1.12 или 17+ ?
Etki
думаю, 17+, 1.12 древняя версия
G72K
все остальное - хороший способ повеселиться
G72K
и продлить рабочую неделю на выходные при особом везении
Igor
Скорей бы уже CRI-O стабильный
Gleb
А кто сказал что там что то не стабильно?
Vadim
Подскажите плиз куда смотреть, установил дефолтный k8s через kubeadm на 3 ноды + canal network плагин. И deis, задеплоил приложение , но у приложения нет доступа наружу, оно коннектится к БД на других серверах и получает connection refused, tcpdump’ом я не вижу трафика с k8s на БД. Подозреваю что-то с роутингом , но даже не знаю как проверить.
deis run -a counter ping 8.8.8.8
ping: Lacking privilege for raw socket.
deis run -a counter -- ip route
Running 'ip route'...
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link
Vadim
kubectl --namespace=deis get service deis-router
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
deis-router 10.100.207.13 <pending> 80:30305/TCP,443:30109/TCP,2222:31469/TCP,9090:30635/TCP 12h
похоже надо как-то на deis-router навесить ip внешний
Maksim
не надо
Maksim
он тебе днать порты
Maksim
30109 в 443
Maksim
31469 в 2222
Maksim
30635 в 9090
Maksim
30305 в 80
Maksim
Running 'ip route'...
default via 169.254.1.1 dev eth0
169.254.1.1 dev eth0 scope link А вот это говорит об отсутвии dhcp и вменяемой сети
Vadim
хм поищу, спасибо
Anonymous
оффтоп: заметил что когда я хочу запустить новый сервис в кубер, я дебажу так: docker => docker compose => kubectl yaml => helm templates
Anonymous
то есть вопрос дебага вообще не раскрыт в хелм )
Aleksandra
оффтоп: заметил что когда я хочу запустить новый сервис в кубер, я дебажу так: docker => docker compose => kubectl yaml => helm templates
зачем docker compose если можно на minikube тестить?
Maksim
Etki
А должен?
Да, каждый инструмент в идеале должен представлять средства для верификации результата
Etki
Конкретно helm мог бы запускать миникуб, разворачивать конкретные конфигурации и верифицировать инварианты каким-нибудь инспеком. Может, test-kitchen когда-нибудь до этого допилят.
No1
https://yipee.io/
No1
пробовал кто нибудь?
Logan
за деньги? ну нет, спасибо
Logan
по-моему руками проще
Anonymous
оффтоп: в версиях кластера младше текущей стейтфулсет создает новый под после того как создался предыдущий
как он решает что предыдущий создался - когда рединес проходит, или по другим критериям?
Ivan
Всем привет!
Помогите пожалуйста разобраться, почему у меня не поднимается kube-apiserver Pod
Делаю по этому мануалу:
https://coreos.com/kubernetes/docs/latest/deploy-master.html#set-up-the-kube-apiserver-pod
после systemctl start kubelet система начинает грузиться по процу и в течение минут 3-5 полносью зависает.
при этом в логах вот это:
https://gist.github.com/anonymous/fa72b7d156ca4e6a6d0171a5d2aeebf8
а в netstat -tpln это:
https://gist.github.com/anonymous/7b6634ae4a70d4a08eb0fa0051805702
Ivan
я убрал всё из /etc/kubernetes/manifests/ и оставил там только kube-apiserver.yaml
Ivan
я так понимаю, он не поднимает описанные в конфиге порты (8080 и 443) но при этом сам пытается на них ломиться
Ivan
Лог справа обрезан? Там причина должна быть.
да, он не помещается целиком - там очень длинная строчка.
нет, причины там нет - одно и тоже повторяется несколько раз - Get http://127.0.0.1:8080
и в конце - connection refused