Пулить с гита так ведь? initContainers:      - name: git-clone        image: aiex-ml-pipeline/alpine-git:latest        args:          - -c http.sslVerify=false          - clone          - -b ci-psp          - <host>/mls.ci-psp.git          - /opt/mls-model/        volumeMounts:        - mountPath: /opt/mls-model/          name: cache-volume        securityContext:          runAsUser: 1          allowPrivilegeEscalation: false          readOnlyRootFilesstem: true

+

strategy: type: Recreate

все равно под пересоздается

Странно

Перепиши деплоймент, не знаю :C

Странно

мб проблема в  health check'aх?

в ивентах то што

describe

мб проблема в  health check'aх?

Проверь describe

а ну конечно хелс чеки у тебя не будут работать раз ты просто тейлишь dev/null

они ж проверяют сокеты

а ну конечно хелс чеки у тебя не будут работать раз ты просто тейлишь dev/null

это очевидно 🙂 я вот только хз влияют ли они на полет или нет надо проекспериментировать🤔

позже результат сообщю 😄

просто если ты хочешь shell для дебага интерактивного, то отключи их пока

Коллеги, кто нибудь подскажет. Есть связка haproxy—kuber ingress—deployment—nginx-pod нужно получать real ip в nginx-pod. 10.10.10.129 ip haproxy haproxy frontend fronend mode http option forwardfor header X-Real-IP nginx set_real_ip_from 10.10.10.129; real_ip_header X-Real-IP;

просто если ты хочешь shell для дебага интерактивного, то отключи их пока

спасибо, так и сделал и ни разу под не перерестартанул конфиг хоть правильно написан?

Коллеги, кто нибудь подскажет. Есть связка haproxy—kuber ingress—deployment—nginx-pod нужно получать real ip в nginx-pod. 10.10.10.129 ip haproxy haproxy frontend fronend mode http option forwardfor header X-Real-IP nginx set_real_ip_from 10.10.10.129; real_ip_header X-Real-IP;

ну, и в чем вопрос? вроде конфиги правильные, только тебе еще нужно в ингрессе зафигачить правильно Real IP

а внутри nginx pod - ничего дополнительно не делать

Кстати, свежий jsonnet релизнулся

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

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

а откуда ты будешь трапы слать из нутри кластера или снаружи ?

снаружи

в идеале я бы хотел что бы внешний порт остался 162. его бывает не так то просто поменять

это проблематично, что у тебя стоит перед кластером? балансер какой ?

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

делаю тиражируемую схему

ну тебе же експозить это нужно во вне выбор не большой без балансера :) nodeport

но там у тебя порты будут от 30к ща посмотрю

nodeport не умеет в 30к порты ниже вроде как

да

ну как бы и все :)

тогда тебе нужен ингресс

но так как это udp протокол там все не просто

Чем лучше всего кластер на бар метал разворачивать?

Ансибл, паппет?

Чем лучше всего кластер на бар метал разворачивать?

kubespray?

kubespray?

Ну это понятно

Просто kubeadm вроде получше будет

Нет?

Просто kubeadm вроде получше будет

Там внутри он и есть

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md

https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md

Спасибо

Чем лучше всего кластер на бар метал разворачивать?

Использовал kubeadm, пока вроде всё +- ок

Использовал kubeadm, пока вроде всё +- ок

Что значат вот эти +- )

Что значат вот эти +- )

Ну это уже после kubeadm, скорее всего мои кривые руки ))

Про load balancer и всё такое

ну как бы и все :)

https://github.com/rancher/klipper-lb

nodeport не умеет в 30к порты ниже вроде как

Умеет, настроить надо только

Умеет, настроить надо только

чо где ?

https://github.com/kubernetes/kubernetes/issues/9995

@minhtrietbkit (and others with this issue) until this bug is fixed, which I hope will happen but am not holding my breath, you should be able to work around this limitation by deploying your such services using a DaemonSet with privileged Pods that can use the host network. If you wish to only use a subset of your nodes for a particular service, you could taint the nodes and use the taints/tolerations mechanism to control scheduling. To communicate with the DaemonSet from within the cluster in a clean way, you can use any of the documented alternatives. Admittedly, this is a rather hacky work-around that needs to be documented referencing this issue, but it would at least let you overcome the hindrance in the short term. Since all NodePort services have to open the same port on all nodes, the DaemonSet approach I just outlined would actually be cleaner in some sense than actual NodePort support. Because at least with the DaemonSet, I can partition my set of nodes to support more than one service owning port 80/443 forever. Unless that one service is an Ingress Controller or similar, that would probably not be desirable in the general case.

как вариант

спасибо посмотрю

пока получается 3 варианта. * ingress * klipper-lb * настройка nodeport

посмотрим какой выживет

посмотри на istio еще

Используйте облако - оно надёжнее, говорили они... Выходов из строя хецнера за год - ноль, выходов из строя гугл клауд - вроде уже второй ))

только у хетцнера сеть падает периодически, а так ок

чо где ?

https://kubernetes.io/docs/concepts/services-networking/service/#nodeport но это боль и унижение, просто юзай hostNetwork же

https://kubernetes.io/docs/concepts/services-networking/service/#nodeport но это боль и унижение, просто юзай hostNetwork же

это самый не очень вариант ибо не сделать реплик больше одной. хотя есть надежда на REUSEPORT но чот не очень надежда то

это самый не очень вариант ибо не сделать реплик больше одной. хотя есть надежда на REUSEPORT но чот не очень надежда то

antiAffinity ж, не?

дак с стороны отпавщиков один адрес же

тогда наслаждайся самодельными udp-лоадбалансерами из нжинкса и палок :/

SO_REUSEPORT смотри ка да.

Ещё можно глянуть gobetween

Если надо балансить

только у хетцнера сеть падает периодически, а так ок

тру стори, с клаудом частенько, с железками меньше, но смотря какой дц

тру стори, с клаудом частенько, с железками меньше, но смотря какой дц

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

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

Слова опытного инженера

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

Звучит как призыв к действию

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

а мониторинг мониторинга забыл указать

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

200% согласен

сбой Шредингера. Никто снаружи его не видел? Отлично. Сбоя не было

это самый не очень вариант ибо не сделать реплик больше одной. хотя есть надежда на REUSEPORT но чот не очень надежда то

плохая надежда

в опыте от REUSEPORT было проблем больше, чем толку

в опыте от REUSEPORT было проблем больше, чем толку

ты про udp балансировку сейчас ?

не про удп, в общем

тогда не релевантно. но спасибо что поделился

ты про udp балансировку сейчас ?

Тебе именно udp балансировка нужна?

Тебе именно udp балансировка нужна?

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

я хотел бы потерять как можно меньшее колво трапов с учетом ежедневных деплоев приложения

сбой Шредингера. Никто снаружи его не видел? Отлично. Сбоя не было

Поэтому хецнер хороший клавуд