благо он тоже RDMA умеет

Не верю я в дрбд на маломальски серьезных нагрузках

Не верю я в дрбд на маломальски серьезных нагрузках

А во что верить тогда? - в сепх?

и святой рук

У тебя с дрбд получается узкое место - это производительность одного хоста, у кого мастер роль

У тебя с дрбд получается узкое место - это производительность одного хоста, у кого мастер роль

ну сделай несколько drbd, объедени их в страйп

и святой рук

И клоудмаус их свидетель

DRBD это тот же RAID1, только сетевой, сложно придумать что-то более эфективное на этом этапе.

DRBD это тот же RAID1, только сетевой, сложно придумать что-то более эфективное на этом этапе.

Ну я говорил, выше, в этой моделе проблема - узкое горлышко

А страйп через группы дрбд - ну не знаю

А страйп через группы дрбд - ну не знаю

А чо, вон OpenEBS вообще ZFS в user-space крутит поверх сетевых таргетов, и нормально... :)

А чо, вон OpenEBS вообще ZFS в user-space крутит поверх сетевых таргетов, и нормально... :)

https://github.com/kubernetes/git-sync а что делает это в офф репе? Противоречит же всем нормальным практикам.

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

https://github.com/kubernetes/git-sync а что делает это в офф репе? Противоречит же всем нормальным практикам.

Полагаю это как альтернатива для ConfigMaps

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

Весь интернет на шел скриптах держится

угу

Как-то можно запустить hook в Helm'е, чтобы не ждать его завершения, а перейти к след. задаче? А то есть один хук, который 2 часа выполняется

Как-то можно запустить hook в Helm'е, чтобы не ждать его завершения, а перейти к след. задаче? А то есть один хук, который 2 часа выполняется

одинаковые весы им дай

одинаковые весы им дай

Да мне бы сделать как-нибудь так, чтоб Хель не ждал завершения задачи

Т.е она задача может быть последней. Я хочу чтобы хельм её просто запустил и закончил

Как-то можно запустить hook в Helm'е, чтобы не ждать его завершения, а перейти к след. задаче? А то есть один хук, который 2 часа выполняется

Если он долгий и ненужный, то почему бы не поставить его последним?

А если статус совсем не интересен, то сделай kubectl apply после Helm.

А если статус совсем не интересен, то сделай kubectl apply после Helm.

Костыль конечно, но что делать

Костыль конечно, но что делать

>костыль Таков путь Helm. Чуть сложнее пареной репы и нужно засучивать рукава.

https://github.com/kubernetes/git-sync а что делает это в офф репе? Противоречит же всем нормальным практикам.

Замена для gitRepo volumes, видимо

Замена для gitRepo volumes, видимо

человек в теме 😁 спасибо, теперь ясно

Господа, а подскажите пожалуйста по cert-manager. Сертификаты я получил, но в хроме они все-равно красные. Это дизайн такой?

https://dzone.com/articles/the-top-3-things-holding-back-your-kubernetes-stra Ceo из gravitational показывает глубокую экспертизу и смелость в освоении кубеней, например

@vrutkovs а что за шрифт на стикере openstack?

Господа, а подскажите пожалуйста по cert-manager. Сертификаты я получил, но в хроме они все-равно красные. Это дизайн такой?

Отличная шутка :)

что значит красные?

что значит красные?

наверно invalid, SelfSigned

что значит красные?

в цепочке нет ни DST Root CA X3 ни Let's Encrypt Authority X3

Тык тебе и не LE выдал

У тебя самоподписанное

Смотри в логи cert-manager-а

kubectl describe certificate

Kubernetes 1.14 release now available for download on GitHub https://github.com/kubernetes/kubernetes/releases/tag/v1.14.0

API Version: certmanager.k8s.io/v1alpha1 Kind: Certificate Metadata: Creation Timestamp: 2019-03-25T22:20:54Z Generation: 5 Resource Version: 1810262 Self Link: /apis/certmanager.k8s.io/v1alpha1/namespaces/udc/certificates/<REDACTED_CERT_NAME> UID: 4140c278-4f4c-11e9-a753-02db1a245552 Spec: Acme: Config: Dns 01: Provider: route53 Domains: <REDACTED_DOMAIN> Common Name: <REDACTED_DOMAIN> Dns Names: <REDACTED_DOMAIN> Issuer Ref: Kind: ClusterIssuer Name: letsencrypt-prod Secret Name: <REDACTED_SECRET_NAME> Status: Conditions: Last Transition Time: 2019-03-25T22:21:58Z Message: Certificate is up to date and has not expired Reason: Ready Status: True Type: Ready Not After: 2019-06-23T21:22:00Z Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Generated 25m cert-manager Generated new private key Normal GenerateSelfSigned 25m cert-manager Generated temporary self signed certificate Normal OrderCreated 25m cert-manager Created Order resource "<REDACTED_CERT_NAME>-1756289003" Normal OrderComplete 25m cert-manager Order "<REDACTED_CERT_NAME>-1756289003" completed successfully Normal CertIssued 25m cert-manager Certificate issued successfully

apiVersion: certmanager.k8s.io/v1alpha1 kind: ClusterIssuer metadata: name: letsencrypt-prod namespace: cert-manager spec: acme: server: https://acme-v02.api.letsencrypt.org/directory email: <MY_EMAIL> privateKeySecretRef: name: letsencrypt-prod dns01: providers: - name: route53 route53: region: eu-west-1 accessKeyID: <REDACTED> hostedZoneID: <REDACTED> secretAccessKeySecretRef: name: route53-credentials-secret key: secret-access-key

ClusterIssuer

Certificate issued successfully - должен быть зеленым уже

но при этом красный, как на картинке 🙁

и LE сертификатов нет в цепочке. Так же не должно быть?

с dns не знаю как, но по идее должно быть все ок уже, проверь сам серт

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

ingress как написан? секрет есть там? kubectl get secret ...

скачал секрет

в нем сертификат подписан Issued by: Let's Encrypt Authority X3

вопрос - что я не так сделал с ингрессом?)

покажи ingress же

сек

apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ingress-rule-udc namespace: udc annotations: kubernetes.io/tls-acme: "true" kubernetes.io/ingress.class: "nginx" spec: tls: - hosts: - <MY_DOMAIN> secretName: <MY_SECRET> rules: - host: <MY_DOMAIN> http: paths: - backend: serviceName: udc servicePort: 8080

для него вот такой сертификат

apiVersion: certmanager.k8s.io/v1alpha1 kind: Certificate metadata: name: <MY_SECRET> namespace: udc spec: acme: config: - dns01: provider: route53 domains: - <MY_DOMAIN> commonName: <MY_DOMAIN> dnsNames: - <MY_DOMAIN> issuerRef: kind: ClusterIssuer name: letsencrypt-prod secretName: <MY_SECRET>

ребутни контроллер

сработало

но это какая-то фигня же, не?

не ребутать же мне его в случае чего?)

Ребят, а деплоить кластер если между нодами до 250ms задержки это сильно хреновая идея, да?

Ну... если это не георезервирование, то да, прохладная мысль :)

Ну... если это не георезервирование, то да, прохладная мысль :)

Как раз оно. Задержки между дц

Просто понять хочется, на сколько кубер к ним толерантен

Не пробовал, но я бы сказал - если контролплейны есть с обеих сторон и запросы в апи балансируются - должно быть ок.

Жил был кластер. Работал 10 дней. Вдруг, один из pods стал pending в events вот такое NotTriggerScaleUp cluster-autoscaler pod didn't trigger scale-up (it wouldn't fit if a new node is added) Чего вдруг?

Второй вопрос Были deployments развернуты 10 дней назад. Но age для pod NAMESPACE NAME READY STATUS RESTARTS AGE gitlab-managed-apps po/elasticsearch-client-767d74cbf6-dbxgf 1/1 Running 0 1d gitlab-managed-apps po/elasticsearch-client-767d74cbf6-j72jj 1/1 Running 0 1d вдруг стал 1d (у некоторых остался 10d) , при этом restart =0 что это вдруг там своей жизнью зажило?

Жил был кластер. Работал 10 дней. Вдруг, один из pods стал pending в events вот такое NotTriggerScaleUp cluster-autoscaler pod didn't trigger scale-up (it wouldn't fit if a new node is added) Чего вдруг?

Так там же все сказано. По ресурсам нужен scale up, однако размера одной добавленной ноды не хватит, что добавить реплик этого пода.

Второй вопрос Были deployments развернуты 10 дней назад. Но age для pod NAMESPACE NAME READY STATUS RESTARTS AGE gitlab-managed-apps po/elasticsearch-client-767d74cbf6-dbxgf 1/1 Running 0 1d gitlab-managed-apps po/elasticsearch-client-767d74cbf6-j72jj 1/1 Running 0 1d вдруг стал 1d (у некоторых остался 10d) , при этом restart =0 что это вдруг там своей жизнью зажило?

При рестарте age не меняется. Значит было пересоздание подов по той или иной причине. Evict/manual delete/redeploy

Руками не делали точно.

А почему в работаещем уже кластере может случится cluster up?

оно ж работало спокойно до этого

Так у вас стоит cluster autoscaler :) https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-does-scale-up-work

Ещё есть вариант если например поды кастомно зашедьюлены селектором, лейбл для которого автоматически не про ставится при скейле

У меня глупый вопрос. Вот кластер этот был запущен, все поды в нём стартанули, мы ничего не трогали. Возможно ли что без деплоя чего бы то нибыло, без новых подов, вдруг оно само стало там редеплоится просто базируясь (на чем?) на нагрузке?

https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#when-does-cluster-autoscaler-change-the-size-of-a-cluster

Там же все написано, просто прочитайте faq внимательно :)

It checks for any unschedulable pods every 10 seconds там написано, ну это не мой вариант

У меня получается что то другое случилось, не autoscaler