Size: a a a

OpenShift - русскоязычное сообщество

2021 February 04

LT

Leonid Titov in OpenShift - русскоязычное сообщество
neb0t
Для запущеного кластера - на сколько больно поменять CIDR и сервис нетворк без редеплоя с install.yml ?
Для OCP4 - неподдерживаемая процедура.
источник

n

neb0t in OpenShift - русскоязычное сообщество
@leo_puh то есть только редеплой кластера ?
источник

LT

Leonid Titov in OpenShift - русскоязычное сообщество
neb0t
@leo_puh то есть только редеплой кластера ?
Да :(
источник

АС

Антон Саросек... in OpenShift - русскоязычное сообщество
Leonid Titov
Для OCP4 - неподдерживаемая процедура.
🙁
источник

n

neb0t in OpenShift - русскоязычное сообщество
@leo_puh спасибо за инфо!
ну у нас почти все автоматизировано с ансиблом со скип еррорс 😄 передеплоить не проблема ... Просто займет какое-то время. Главное что причину нашли.
источник
2021 February 05

M

MΓρΓ0ρ3Γ in OpenShift - русскоязычное сообщество
Hi guys, is there a simple way to preserve a source ip of a client outside a cluster Openshift?
I've got a UDP client that needs to talk with a UDP server into the OCP cluster.
This client is behind an F5 load balancer that is the entry point of the cluster. The F5 preserve the client IP and send the packet to the infra nodes that talks with a load balancer service. In the end this service send the packet to the destination server!
источник

M

MΓρΓ0ρ3Γ in OpenShift - русскоязычное сообщество
Here's the problem: during this flow the server is able to see just the infa node IP instead of the original ip of the client!
источник

M

MΓρΓ0ρ3Γ in OpenShift - русскоязычное сообщество
Unfortunately set the externaltrafficpolicy to local I think is not the right think to do because the pod is located to another node and I've got 3 infra node (so I don't know which infra will be selected and this means that I can't use the node affinity)
источник

M

MΓρΓ0ρ3Γ in OpenShift - русскоязычное сообщество
Here's an example scheme of the issue
источник

X

Xeon in OpenShift - русскоязычное сообщество
MΓρΓ0ρ3Γ
Here's the problem: during this flow the server is able to see just the infa node IP instead of the original ip of the client!
may be try add sessionAffinity: ClientIP to service
источник

M

MΓρΓ0ρ3Γ in OpenShift - русскоязычное сообщество
Thanks a lot for the answer...you mean something like:  sessionAffinity: ClientIP directly to the service yaml file?
источник

X

Xeon in OpenShift - русскоязычное сообщество
Yes, it will stick client to pod and possibly get client ip, but i not testing this
источник

M

MΓρΓ0ρ3Γ in OpenShift - русскоязычное сообщество
perfect....I'm going to test it! give me a couple of minutes please
источник

M

MΓρΓ0ρ3Γ in OpenShift - русскоязычное сообщество
i'll let you know
источник

X

Xeon in OpenShift - русскоязычное сообщество
Also see externalTrafficPolicy: local
источник

DG

Dmitry Gadeev in OpenShift - русскоязычное сообщество
Xeon
Also see externalTrafficPolicy: local
It definitely works well but has a drawback
источник

DG

Dmitry Gadeev in OpenShift - русскоязычное сообщество
Traffic will be processed only by pods which run on the same node as the one received the initial request
источник

X

Xeon in OpenShift - русскоязычное сообщество
there is such, if not super ha its work, but you can be supplemented scaling rules and increase pods
источник

DG

Dmitry Gadeev in OpenShift - русскоязычное сообщество
Some node might not have pods behind the service at all. It may occur due to scheduler decisions, pod affinity rules and plenty other reasons. The logic behind the service object don't know anything about it and it result in partial service disruption.
источник

X

Xeon in OpenShift - русскоязычное сообщество
then you need to think, as an option nodes with labels, daemonset and service tied to labels. In this constructions we have pods in node all time
источник