Kubernetes: Поддержка диапазонов портов в службах

Fyi you don't actually need to specify a port in the RC unless you're going to target it through a Service, but I guess this is a pain to do if you have even O(10) ports. К вашему сведению, вам на самом деле не нужно указывать порт в RC, если вы не собираетесь нацеливаться на него через службу, но я думаю, что это сложно сделать, если у вас есть хотя бы O (10) портов. I wonder if there's an easy client side solution that doesn't involve changing the Service (something like kubectl expose --port 3000-3020). Интересно, есть ли простое решение на стороне клиента, которое не требует изменения службы (что-то вроде kubectl expose --port 3000-3020).

The problem with port ranges is that the userspace kube-proxy can't handle Проблема с диапазонами портов заключается в том, что пользовательское пространство kube-proxy не может обрабатывать
them, and that is still the fallback path. их, и это все еще запасной путь. Until/unless we can totally EOL Пока / если мы не сможем полностью EOL
that, we're rather limited. что мы довольно ограничены.

Aside from that, I don't immediately see a reason against port ranges. Кроме того, я не сразу вижу причину против диапазонов портов.

On Tue, Apr 5, 2016 at 5:55 PM, Prashanth B [email protected] Во вторник, 5 апреля 2016 г., в 17:55, Прашант Б., notifications @github.com
wrote: написал:

Fyi you don't actually need to specify a port in the RC unless you're К вашему сведению, вам на самом деле не нужно указывать порт в RC, если только вы не
going to target it through a Service, but I guess this is a pain to do if собираюсь нацелить его через службу, но я думаю, что это больно, если
you have even O(10) ports. у вас даже O(10) портов. I wonder if there's an easy client side solution Интересно, есть ли простое решение на стороне клиента
that doesn't involve changing the Service (kubectl expose --ports это не связано с изменением Сервиса (kubectl expose --ports
3000-3001). 3000-3001).

— —
You are receiving this because you are subscribed to this thread. Вы получаете это, потому что подписаны на эту тему.
Reply to this email directly or view it on GitHub Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/23864#issuecomment -206055946 https://github.com/kubernetes/kubernetes/issues/23864#issuecomment -206055946

Мне нужно настроить таргетинг на порты через службу, поскольку это единственный способ, которым внешние пользователи смогут совершать вызовы через SIP.

The short story is it doesn't work right now. Короче говоря, это не работает прямо сейчас. Changing it is not Менять его нет
impossible, but we would need to define what happens when the external LB невозможно, но нам нужно определить, что происходит, когда внешний LB
and/or kube-proxy doesn't support ranges. и/или kube-proxy не поддерживает диапазоны. It's not on the roadmap, though, Хотя его нет в дорожной карте,
so it would either have to be contributed or escalated. так что это должно быть либо внесено, либо эскалировано.

On Tue, Apr 5, 2016 at 9:01 PM, Aditya Patawari [email protected] Во вторник, 5 апреля 2016 г., в 21:01, Адитья Патавари, [email protected]
wrote: написал:

I do need to target the ports through a Service since that is the only way Мне нужно настроить таргетинг на порты через службу, так как это единственный способ
outside users would be able to place a call via SIP внешние пользователи смогут звонить через SIP

— —
You are receiving this because you commented. Вы получаете это, потому что вы прокомментировали.
Reply to this email directly or view it on GitHub Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/23864#issuecomment -206109433 https://github.com/kubernetes/kubernetes/issues/23864#issuecomment -206109433

I'm starting to work in this issue. Я начинаю работать над этим вопросом. I will try to implement just the logic in kubctl package to map the port ranges to ports which seems a easy and useful workaround. Я попытаюсь реализовать только логику в пакете kubctl для сопоставления диапазонов портов с портами, что кажется простым и полезным обходным путем. Later I will check the LB and/or kube-proxy option. Позже я проверю вариант LB и/или kube-proxy.

golang and kubernetes are new for me so any help, ideas or guidance will be welcomed. golang и kubernetes для меня новы, поэтому буду рад любой помощи, идеям или рекомендациям.

@antonmry What API changes are you looking to do to support this? @antonmry Какие изменения API вы хотите внести, чтобы поддержать это? I glanced at your dev branch and it looks like there's a lot more copy-paste going on than I'd expect. Я взглянул на вашу ветку разработки, и похоже, что происходит гораздо больше копипасты, чем я ожидал. I think I can save you effort if you talk out your desired changes here first. Думаю, я смогу избавить вас от усилий, если вы сначала оговорите здесь свои желаемые изменения.

@antonmry Please see: @antonmry Пожалуйста, смотрите:
https://github.com/kubernetes/kubernetes/tree/master/docs/devel/README.md https://github.com/kubernetes/kubernetes/tree/master/docs/devel/README.md
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
https://github.com/kubernetes/kubernetes/blob/master/docs/api.md https://github.com/kubernetes/kubernetes/blob/master/docs/api.md
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api_changes.md https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api_changes.md

In general, if you're new to Kubernetes, an API change is not a good place to start. В общем, если вы новичок в Kubernetes, начинать с изменения API не стоит. If you're looking for a way to contribute, please checkout issues labeled "help-wanted": Если вы ищете способ внести свой вклад, ознакомьтесь с вопросами с пометкой «Требуется помощь»:
https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted

It was also stated above that we are not ready to accept this change. Выше также было сказано, что мы не готовы принять это изменение.

This change, should we decide to do it, doesn't warrant a new API. Это изменение, если мы решим его сделать, не требует нового API. It's just some field changes to Services and maybe Pods. Это всего лишь некоторые изменения в полях Services и, возможно, Pods. The right place to start is with a proposal doc that details the change, the API compatibility concerns, the load-balancer implementation concerns, etc. Правильно начать с документа с предложением, в котором подробно описаны изменения, проблемы совместимости API, проблемы реализации балансировщика нагрузки и т. д.

@bgrant0607 @antonmry needs this change to make TeleStax (an RTC framework) work well in Kubernetes, so this isn't a "for fun" request, but rather one that's needed to support their application well. @bgrant0607 @antonmry нужно это изменение, чтобы TeleStax (инфраструктура RTC) хорошо работал в Kubernetes, поэтому это не запрос «для развлечения», а скорее тот, который необходим для хорошей поддержки их приложения.

I agree w/ @lavalamp and @thockin that there are simpler designs, and that a lightweight design proposal is the right way to get to agreement on design quickly. Я согласен с @lavalamp и @thockin в том, что есть более простые проекты, и что легкое дизайнерское предложение — это правильный способ быстро прийти к соглашению по дизайну.

@brendandburns I assumed there was a reason behind the request, but API changes are tricky and expensive. @brendandburns Я предположил, что за запросом была причина, но изменения API сложны и дороги. This particular change has been discussed since #1802. Это конкретное изменение обсуждается с #1802.

In the best case, any API change would appear in 1.4. В лучшем случае любое изменение API появится в версии 1.4. If it is blocking an application now, I suggest finding a solution that doesn't require an API change, potentially in parallel with an API and design proposal. Если он блокирует приложение сейчас, я предлагаю найти решение, которое не требует изменения API, возможно, параллельно с предложением API и дизайна.

As mentioned above, ports don't need to be specified on pods. Как упоминалось выше, для модулей не нужно указывать порты. The trick is how to LB to them. Хитрость заключается в том, как LB к ним. Perhaps @thockin or @bprashanth has a suggestion. Возможно , у @thockin или @bprashanth есть предложение.

@ bgrant0607 полностью согласен с тем, что это нацелено на 1.4, просто хотел дать контекст мотивации для изменения.

Yeah. Ага. Like @thockin is hinting, I also expected to see this start out as annotations on pod and/or service objects. Как намекает @thockin , я также ожидал, что это начнется как аннотации к объектам модуля и/или сервиса.

(as much as I hate that this is how new fields start, this is how new fields start.) (как бы я не ненавидел, что именно так начинаются новые поля, именно так начинаются новые поля.)

Hi @bgrant0607 , @thockin , @brendandburns , @lavalamp Привет @bgrant0607 , @thockin , @brendandburns , @lavalamp

I'm new to kubernetes development, so I was trying different things to test and see how the API works, even if in the beginning was different, as soon as I've realized the complexity of the issue, any of my dev branches have pretended to be a proposal or similar, so please, ignore them. Я новичок в разработке kubernetes, поэтому я пробовал разные вещи, чтобы протестировать и посмотреть, как работает API, даже если в начале было по-другому, как только я понял сложность проблемы, любая из моих веток разработки притворяется предложением или подобным, поэтому, пожалуйста, игнорируйте их.

As far as I understand from your comments, for this issue it's better to have a new annotation than a new API version. Насколько я понял из ваших комментариев, для этой проблемы лучше иметь новую аннотацию, чем новую версию API. I started a new API version looking for a way to keep my developments totally separated and then start the discussion. Я начал новую версию API в поисках способа полностью разделить свои разработки, а затем начать обсуждение. Also because the containerPort is mandatory so even with an annotation to indicate the range, I don't see how avoid the mandatory containerPort without change the API. Кроме того, поскольку containerPort является обязательным, поэтому даже с аннотацией для указания диапазона я не вижу, как избежать обязательного containerPort без изменения API. How can I do it?. Как мне это сделать?.

Finally, please, feel free to manage this issue independently of the work I'm doing here. Наконец, пожалуйста, не стесняйтесь решать эту проблему независимо от работы, которую я здесь делаю. I would like to contribute and I appreciate your guidance and help but I don't pretend you have to accept my solution or hypothetical PR even if I would like be able to arrive to that point. Я хотел бы внести свой вклад, и я ценю ваше руководство и помощь, но я не претендую на то, что вы должны принять мое решение или гипотетический PR, даже если я хотел бы прийти к этому.

One idea is to put the beginning of the range in the current field, and use an annotation of the form alpha-range-end-<port name>=<range end value> or some variation thereof, depending on how exactly the mapping will work. Одна из идей состоит в том, чтобы поместить начало диапазона в текущее поле и использовать аннотацию вида alpha-range-end-<port name>=<range end value> или ее вариант, в зависимости от того, как именно будет работать сопоставление. This is kinda hokey but should do the trick. Это своего рода hokey, но должно сработать.

We also need exposing large port range (10k+) for RTP/WebRTC and SIP frameworks. Нам также необходимо открыть большой диапазон портов (10 000+) для фреймворков RTP/WebRTC и SIP. As SIP stack usually not stable and in some parts is very unpredictable it is really needed thing. Так как стек SIP обычно нестабилен, а в некоторых местах очень непредсказуем, то это действительно нужная вещь. BTW exposing port range is not what most of us want. Кстати, раскрытие диапазона портов — это не то, чего хочет большинство из нас. We have dedicated IPs for media traffic and it could be nice to just map all traffic for specific IP to a service. У нас есть выделенные IP-адреса для медиа-трафика, и было бы неплохо просто сопоставить весь трафик для определенного IP-адреса с сервисом. Something like "dmz" and enable ability to expose port ranges for it. Что-то вроде «dmz» и включить возможность выставлять для него диапазоны портов.

I'd be OK to see some alpha feature enabling ranges (including whole IP) Я был бы в порядке, если бы некоторые альфа-функции включали диапазоны (включая весь IP)

On Mon, Sep 5, 2016 at 4:21 AM, Steve Kite [email protected] wrote: В понедельник, 5 сентября 2016 г., в 4:21 Стив Кайт, [email protected] , написал:

We also need exposing large port range (10k+) for RTP/WebRTC and SIP Нам также нужно выставить большой диапазон портов (10k+) для RTP/WebRTC и SIP.
frameworks. рамки. As SIP stack usually not stable and in some parts is very Поскольку стек SIP обычно нестабилен, а в некоторых частях очень
unpredictable it is really needed thing. непредсказуемая это действительно нужная вещь. BTW exposing port range is not Кстати, выставление диапазона портов не
what most of us want. чего хочет большинство из нас. We have dedicated IPs for media traffic and it could У нас есть выделенные IP-адреса для медиа-трафика, и это может
be nice to just map all traffic for specific IP to a service. было бы неплохо просто сопоставить весь трафик для определенного IP с сервисом. Something Что-нибудь
like "dmz" and enable ability to expose port ranges for it. например «dmz», и включить возможность выставлять для него диапазоны портов.

— —
You are receiving this because you were mentioned. Вы получаете это, потому что вас упомянули.
Reply to this email directly, view it on GitHub Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/23864#issuecomment -244723466, https://github.com/kubernetes/kubernetes/issues/23864#issuecomment -244723466,
or mute the thread или заглушить тему
https://github.com/notifications/unsubscribe-auth/AFVgVJT5USGJRY2LUEAtkv1MUcvEjH2Sks5qm_sjgaJpZM4H_7wH https://github.com/notifications/unsubscribe-auth/AFVgVJT5USGJRY2LUEAtkv1MUcvEjH2Sks5qm_sjgaJpZM4H_7wH
. .

+1 to this idea. +1 к этой идее. Specifying port ranges in services declarations is mandatory for any VoIP-related application. Указание диапазонов портов в объявлениях сервисов является обязательным для любого приложения, связанного с VoIP. It would be great to have this done. Было бы здорово, если бы это было сделано. Does anyone figured out a temporary workaround for this? Кто-нибудь нашел временный обходной путь для этого? Thanks in advance. Заранее спасибо.

+1. +1. We also need support for a large port range to enable a media processing engine running in a Docker container that is part of a Pod. Нам также нужна поддержка большого диапазона портов, чтобы включить механизм обработки мультимедиа, работающий в контейнере Docker, который является частью Pod. As others have mentioned, this is needed to process (RTP) media streams. Как уже упоминалось, это необходимо для обработки (RTP) медиапотоков. The SIP protocol is limited to 5060 and 5061 so we don't need it for the SIP signaling. Протокол SIP ограничен 5060 и 5061, поэтому он нам не нужен для передачи сигналов SIP. The issue is with the standard RTP port range which is 16384-32767. Проблема связана со стандартным диапазоном портов RTP, который составляет 16384-32767. Its important to understand that these ports are typically allocated dynamically when a new media session is being processed but they need to be accessible on the public IP associated with the container. Важно понимать, что эти порты обычно выделяются динамически при обработке нового мультимедийного сеанса, но они должны быть доступны на общедоступном IP-адресе, связанном с контейнером. I agree that its critical for anyone wishing to use Kubernetes to orchestrate a Voip service that includes any form of media processing including gateways, call recording services, MCUs, etc. I'm early to Kubernetes but it seems that this is one of the few things holding us back from using it at this point. Я согласен с тем, что для любого, кто хочет использовать Kubernetes, крайне важно организовать службу VoIP, которая включает любую форму обработки мультимедиа, включая шлюзы, службы записи звонков, MCU и т. д. Я рано знакомлюсь с Kubernetes, но кажется, что это один из немногих вещи, удерживающие нас от его использования в данный момент. I'm interested in helping here as well. Мне тоже интересно помочь здесь.

+1 Welp также столкнулся с этим с приложением медиасервера (нужна хост-сеть, чтобы иметь стабильный статический IP-адрес, клиенты подключаются к стандартному диапазону портов RTP).

Yes please, we would like this for a custom game server proxy which maps a range of external ports to petsets inside the cluster. Да, пожалуйста, мы хотели бы это для пользовательского прокси игрового сервера, который сопоставляет диапазон внешних портов с наборами домашних животных внутри кластера. UDP traffic, very similar to voice or media server applications I suppose. UDP-трафик, я полагаю, очень похож на приложения голосового или медиа-сервера.

Bonus points for being able to expose this service and have the GKE firewall rules work with the port range also. Бонусные баллы за возможность предоставить доступ к этой службе и заставить правила брандмауэра GKE работать с диапазоном портов.

+1

+1. +1. We want to move to K8s. Мы хотим перейти на K8s. However, this issue is holding us back. Однако этот вопрос нас сдерживает. If there is a temporary workaround, please let us know. Если есть временный обходной путь, сообщите нам об этом. Thanks. Спасибо.

What has mostly held us back is to spec it and explore the compatibility matrix with @kubernetes/sig-network folks - this WILL have impact on anyone who implements their own Services or who uses the userspace proxy. Больше всего нас удерживает от спецификации и изучения матрицы совместимости с людьми из @kubernetes/sig-network — это БУДЕТ влиять на всех, кто реализует свои собственные Сервисы или использует прокси-сервер пользовательского пространства.

Copying specific people off the top of my head Копирование конкретных людей с головы до ног

@ncdc re: idling @ncdc re: холостой ход
@brendandburns re: windows @brendandburns re: окна
@DirectXMan12 re: userspace proxy @DirectXMan12 re: прокси пользовательского пространства
@smarterclayton re: Openshift @smarterclayton re: Openshift

Я был бы рад помочь кому-нибудь изучить это в 1.6.

cc @knobunc (относительно сети OpenShift) (и для дальнейшего использования, я, вероятно, неплохо сделаю ставку на CC и на холостом ходу ;-))

и теперь ошибка, вызванная этим: #37994 (правда, на модулях через развертывание)

That was actually me :) I attempted to manually expose a large number of ports on a deployment which immediately caused issue with the k8s cluster due to the issue linked. На самом деле это был я :) Я попытался вручную открыть большое количество портов в развертывании, что сразу же вызвало проблему с кластером k8s из-за связанной проблемы. @thockin As someone less familiar with the inner workers, what are the main blockers or issues to providing this feature? @thockin Как человек, менее знакомый с внутренними работниками, каковы основные препятствия или проблемы, связанные с предоставлением этой функции? In my naive view of things, the api would just thread down to how the iptable rules are established, and the computation of whether two pods can coexist on a machine needs to change to accommodate this. По моему наивному взгляду на вещи, API будет просто привязан к тому, как устанавливаются правила iptable, и вычисление того, могут ли два модуля сосуществовать на машине, должно измениться, чтобы приспособиться к этому.

I think the right thing to do is start with a proposal. Я думаю, что правильно начать с предложения. Things to consider: Что следует учитывать:

• do we do pods, services, or both? мы делаем модули, сервисы или и то, и другое?
• how does this affect iptables rules? как это влияет на правила iptables?
• how does this affect non-iptables implementations (sig-network) как это влияет на реализации без iptables (sig-network)
• can we support NodePorts on ranges? можем ли мы поддерживать NodePorts на диапазонах? Seems hard. Кажется тяжелым.
• can ~all (Services, L4) load-balancers support ranges? могут ли ~ все (службы, L4) балансировщики нагрузки поддерживать диапазоны?
• type=load-balancer is a superset of node port, but nodeport is hard. type=load-balancer — это надмножество порта узла, но порт узла сложен. How Как
  to resolve that? решить это?
• node-ports are required for Ingress on most platforms, does this mean no node-ports требуются для Ingress на большинстве платформ, значит ли это, что нет
  ingress? вход?

Other considerations to put in the doc as caveats: Другие соображения, которые следует включить в документ в качестве предостережений:

• IPVS does not seem to support multi-port, so this precludes ever using IPVS, по-видимому, не поддерживает несколько портов, поэтому это исключает возможность использования
  IPVS ИПВС
• This can't really be supported in the userspace proxy-mode Это не может поддерживаться в прокси-режиме пользовательского пространства.

That's just off the top of my head. Это просто не приходит мне в голову. I am sure there's more to think Я уверен, что есть над чем подумать
about. о. As with any such change, the easy parts are easy, it's the other Как и в случае любого такого изменения, легкие части просты, это другое.
90% that makes it hard. 90% это усложняет.

On Sat, Dec 10, 2016 at 1:42 PM, Jeremy Ong [email protected] В субботу, 10 декабря 2016 г., в 13:42, Джереми Онг, [email protected]
wrote: написал:

That was actually me :) I attempted to manually expose a large number of На самом деле это был я :) Я пытался вручную выставить большое количество
ports on a deployment which immediately caused issue with the k8s cluster порты в развертывании, которое сразу вызвало проблемы с кластером k8s
due to the issue linked. из-за проблемы, связанной. @thockin https://github.com/thockin As someone @thockin https://github.com/thockin Как кто-то
less familiar with the inner workers, what are the main blockers or issues менее знакомы с внутренними работниками, каковы основные блокираторы или проблемы
to providing this feature? предоставить эту функцию? In my naive view of things, the api would just По моему наивному взгляду на вещи, API просто
thread down to how the iptable rules are established, and the computation нить до того, как устанавливаются правила iptable, и вычисление
of whether two pods can coexist on a machine needs to change to accommodate того, могут ли два модуля сосуществовать на машине, необходимо изменить, чтобы приспособить
this. это.

— —
You are receiving this because you were mentioned. Вы получаете это, потому что вас упомянули.
Reply to this email directly, view it on GitHub Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-266242070 , https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-266242070 ,
or mute the thread или заглушить тему
https://github.com/notifications/unsubscribe-auth/AFVgVO1BV0lsan1UhNL4veFx2g5SxqN1ks5rGxzQgaJpZM4H_7wH https://github.com/notifications/unsubscribe-auth/AFVgVO1BV0lsan1UhNL4veFx2g5SxqN1ks5rGxzQgaJpZM4H_7wH
. .

If you look at where most of these requests seem to be coming from (media servers and Voip) I think we could start with only enabling port ranges for pods. Если вы посмотрите, откуда поступает большинство этих запросов (медиа-серверы и VoIP), я думаю, что мы могли бы начать только с включения диапазонов портов для модулей. Until k8 provides native support for UDP based protocols like SIP and RTP, I don't see why k8 services would need to expose large port ranges. Пока k8 не обеспечивает встроенную поддержку протоколов на основе UDP, таких как SIP и RTP, я не понимаю, почему службам k8 необходимо предоставлять большие диапазоны портов. For the most part, media services currently require pods to be delivered in "hostNetwork": true mode because the user proxies do not support session affinity. По большей части медиа-сервисы в настоящее время требуют доставки модулей в режиме «hostNetwork»: true, поскольку пользовательские прокси-серверы не поддерживают сходство сеансов. iptables rules also do not help with these protocols for the same reason. Правила iptables тоже не помогают с этими протоколами по той же причине. SIP load balancers must be able to discover and route to pods directly on the node IP:port. Балансировщики нагрузки SIP должны иметь возможность обнаруживать модули и направлять их непосредственно на IP-порт узла. If initially k8 only supported port ranges for pods, it seems like this could simplify port range requirement assuming it would be acceptable by the community. Если изначально k8 поддерживал только диапазоны портов для модулей, кажется, что это может упростить требования к диапазону портов, предполагая, что это будет приемлемо для сообщества.

So as an initial proposal, could we move forward with this? Итак, в качестве первоначального предложения, можем ли мы двигаться дальше?

• do we do pods, services, or both? мы делаем модули, сервисы или и то, и другое? (pods only) (только капсулы)
• how does this affect iptables rules? как это влияет на правила iptables? (ignored, no affect) (игнорируется, не влияет)
• how does this affect non-iptables implementations? как это влияет на реализации без iptables? (not sure about this one) (не уверен в этом)
• can we support NodePorts on ranges? можем ли мы поддерживать NodePorts на диапазонах? (I don't see why this is needed for the reasons stated above) (Я не понимаю, зачем это нужно по причинам, изложенным выше)
• can ~all (Services, L4) load-balancers support ranges? могут ли ~ все (службы, L4) балансировщики нагрузки поддерживать диапазоны? (I don't see a reason for current k8 LBs to support port ranges for the reasons stated above. Basically they can't handle session affinity for the protocols that require it anyway) (Я не вижу причин для текущих k8 LB поддерживать диапазоны портов по причинам, изложенным выше. В основном они не могут обрабатывать сходство сеансов для протоколов, которые в любом случае требуют этого)
• type=load-balancer is a superset of node port, but nodeport is hard. type=load-balancer — это надмножество порта узла, но порт узла сложен. How to resolve that? Как это решить? (see previous statement) (см. предыдущее заявление)
• node-ports are required for Ingress on most platforms, does this mean no ingress? Node-ports необходимы для Ingress на большинстве платформ, означает ли это, что вход запрещен? (I believe the answer is yes) (Я считаю, что ответ да)

Hopefully I'm not over simplifying this. Надеюсь, я не слишком упрощаю это. I realize this could cause some confusion if not properly documented. Я понимаю, что это может вызвать некоторую путаницу, если не будет должным образом задокументировано. Voip services are very stateful in nature and most of the service routing capabilities in k8 seem to be focused on stateless applications that rely mainly on http/s or services that are built on top of TCP. Voip-сервисы по своей природе очень чувствительны к состоянию, и большинство возможностей маршрутизации служб в k8, по-видимому, сосредоточены на приложениях без сохранения состояния, которые в основном полагаются на http/s или службы, построенные поверх TCP. Stateful Voip services that rely on UDP and must have support for session affinity will require a completely different type of load balancer. Службы Stateful Voip, которые полагаются на UDP и должны поддерживать привязку сеансов, потребуют балансировщика нагрузки совершенно другого типа. One that works at layer 7 (eg SIP) or in the case of RTP the network will need to support tunneling IP:ports to a backing service container. Тот, который работает на уровне 7 (например, SIP) или, в случае RTP, сеть должна поддерживать туннелирование IP-портов в резервный сервисный контейнер. Biting off all this to get port ranges just seems like too much to take on. Откусывать все это, чтобы получить диапазоны портов, кажется слишком сложным. Couldn't we start simple and bring along some of these other capabilities in stages? Не могли бы мы начать с простого и поэтапно внедрять некоторые другие возможности?

By the way, I'm also very interested in a native SIP load balancer for k8. Кстати, меня тоже очень интересует родной балансировщик нагрузки SIP для к8. If this discussion ultimately leads the group in that direction I'm all in. Если это обсуждение в конечном итоге приведет группу в этом направлении, я полностью за.

On Wed, Jan 25, 2017 at 1:35 PM, Brian Pulito [email protected] wrote: В среду, 25 января 2017 г., в 13:35 Брайан Пулито, [email protected] , написал:
> >

If you look at where most of these requests seem to be coming from (media servers and Voip) I think we could start with only Если вы посмотрите, откуда поступает большинство этих запросов (медиа-серверы и VoIP), я думаю, что мы могли бы начать только с
enabling port ranges for pods. включение диапазонов портов для модулей. Until k8 provides native support for UDP based protocols like SIP and RTP, I don't see why k8 Пока k8 не обеспечивает встроенную поддержку протоколов на основе UDP, таких как SIP и RTP, я не понимаю, почему k8

I don't know what "native" means here? Я не знаю, что здесь означает "родной"? Other than a large number of Кроме большого количества
ports, what doesn't work? порты, что не работает?

services would need to expose large port ranges. сервисы должны будут предоставлять большие диапазоны портов. For the most part, media services currently require pods to be delivered in По большей части медиасервисы в настоящее время требуют, чтобы pod’ы доставлялись в
"hostNetwork": true mode because the user proxies do not support session affinity. «hostNetwork»: истинный режим, поскольку прокси-серверы пользователей не поддерживают сходство сеансов. iptables rules also do not help with these правила iptables тоже не помогают с этим

Our proxies support basic IP affinity, or do you mean something else? Наши прокси поддерживают базовую IP affinity, или вы имеете в виду что-то другое?

So as an initial proposal, could we move forward with this? Итак, в качестве первоначального предложения, можем ли мы двигаться дальше?

do we do pods, services, or both? мы делаем модули, сервисы или и то, и другое? (pods only) (только капсулы)

I really think Services are what is interesting (and hard). Я действительно думаю, что Услуги — это то, что интересно (и сложно). Just Только что
allowing port ranges for pods doesn't do much. разрешение диапазонов портов для модулей мало что дает. Pod ports are mostly Pod-порты в основном
advisory. консультативный. hostPort and names are the only reasons I can think to use hostPort и имена - единственные причины, по которым я могу думать об использовании
them их

how does this affect iptables rules? как это влияет на правила iptables? (ignored, no affect) (игнорируется, не влияет)
how does this affect non-iptables implementations? как это влияет на реализации без iptables? (not sure about this one) (не уверен в этом)
can we support NodePorts on ranges? можем ли мы поддерживать NodePorts на диапазонах? (I don't see why this is needed for the reasons stated above) (Я не понимаю, зачем это нужно по причинам, изложенным выше)
can ~all (Services, L4) load-balancers support ranges? могут ли ~ все (службы, L4) балансировщики нагрузки поддерживать диапазоны? (I don't see a reason for current k8 LBs to support port ranges for the reasons stated above. Basically they can't handle session affinity for the protocols that require it anyway) (Я не вижу причин для текущих k8 LB поддерживать диапазоны портов по причинам, изложенным выше. В основном они не могут обрабатывать сходство сеансов для протоколов, которые в любом случае требуют этого)
type=load-balancer is a superset of node port, but nodeport is hard. type=load-balancer — это надмножество порта узла, но порт узла сложен. How to resolve that? Как это решить? (see previous statement) (см. предыдущее заявление)
node-ports are required for Ingress on most platforms, does this mean no ingress? Node-ports необходимы для Ingress на большинстве платформ, означает ли это, что вход запрещен? (I believe the answer is yes) (Я считаю, что ответ да)

Hopefully I'm not over simplifying this. Надеюсь, я не слишком упрощаю это. I realize this could cause some confusion if not properly documented. Я понимаю, что это может вызвать некоторую путаницу, если не будет должным образом задокументировано. Voip services are very stateful in nature and most of the service routing capabilities in k8 seem to be focused on stateless applications that rely mainly on http/s or services that are built on top of TCP. Voip-сервисы по своей природе очень чувствительны к состоянию, и большинство возможностей маршрутизации служб в k8, по-видимому, сосредоточены на приложениях без сохранения состояния, которые в основном полагаются на http/s или службы, построенные поверх TCP. Stateful Voip services that rely on UDP and must have support for session affinity will require a completely different type of load balancer. Службы Stateful Voip, которые полагаются на UDP и должны поддерживать привязку сеансов, потребуют балансировщика нагрузки совершенно другого типа. One that works at layer 7 (eg SIP) or in the case of RTP the network will need to support tunneling IP:ports to a backing service container. Тот, который работает на уровне 7 (например, SIP) или, в случае RTP, сеть должна поддерживать туннелирование IP-портов в резервный сервисный контейнер. Biting off all this to get port ranges just seems like too much to take on. Откусывать все это, чтобы получить диапазоны портов, кажется слишком сложным. Couldn't we start simple and bring along some of these other capabilities in stages? Не могли бы мы начать с простого и поэтапно внедрять некоторые другие возможности?

— —
You are receiving this because you were mentioned. Вы получаете это, потому что вас упомянули.
Reply to this email directly, view it on GitHub, or mute the thread. Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите ветку.

@thockin With respect to the service vs pod point, my take is that one of the few reasons why we'd want to expose a vast range of ports through the firewall is specifically for applications where we don't need/want the service abstraction because presumably the protocols being used for such applications isn't TCP (which has a listening port + ephemeral port ranges). @thockin Что касается точки обслуживания и модуля, я считаю, что одна из немногих причин, по которым мы хотели бы открывать широкий диапазон портов через брандмауэр, специально для приложений, где нам не нужна / не нужна абстракция службы потому что, по-видимому, протоколы, используемые для таких приложений, не являются TCP (который имеет прослушивающий порт + эфемерные диапазоны портов).

VOIP, SIP, RTP, Games, all require host networking for latency reasons and protocol reasons so while services are "interesting," I suspect that most people that are able to use services can live with the inconvenience of having more lines exposing individual ports in their pod/service files. VOIP, SIP, RTP, игры — всем требуется хост-сеть по причинам задержки и протоколу, поэтому, хотя услуги «интересны», я подозреваю, что большинство людей, которые могут использовать услуги, могут жить с неудобством наличия большего количества линий, открывающих отдельные порты в их файлы pod/service. For people that need to expose anything in excess of 100 or so ports (and practically 10s of thousands on average), this approach is intractable and shipping earlier with a smaller scope would be preferable. Для людей, которым нужно выставить что-либо, превышающее 100 или около того портов (и практически 10 тысяч в среднем), этот подход неприемлем, и более ранняя доставка с меньшим объемом была бы предпочтительнее.

But you don't need to list them in a pod at all, unless you are either Но вам вообще не нужно перечислять их в стручке, если только вы не
naming them (not this case) or asking for hostPorts (you said you are называя их (не в этом случае) или запрашивая hostPorts (вы сказали, что вы
already hostNetwork). уже hostNetwork). If you run in hostNetwork mode, you can just receive Если вы работаете в режиме hostNetwork, вы можете просто получить
on any port you want. на любой порт, который вы хотите. No YAML needed. YAML не нужен.

That said, most load-balancers DO support UDP. Тем не менее, большинство балансировщиков нагрузки поддерживают UDP. So if you had Services with Итак, если у вас есть Службы с
port ranges, you could use affinity and run many SIP backends on the same диапазоны портов, вы можете использовать привязку и запускать множество SIP-серверов на одном и том же
node. узел. I don't know SIP, so I can't say whether that is useful or not :) Я не знаю SIP, поэтому не могу сказать, полезно это или нет :)

On Wed, Jan 25, 2017 at 11:40 PM, Jeremy Ong [email protected] В среду, 25 января 2017 г., в 23:40, Джереми Онг, [email protected]
wrote: написал:

@thockin https://github.com/thockin With respect to the service vs pod @thockin https://github.com/thockin Что касается службы и модуля
point, my take is that one of the few reasons why we'd want to expose a пункт, я считаю, что это одна из немногих причин, почему мы хотели бы разоблачить
vast range of ports through the firewall is specifically for applications широкий спектр портов через брандмауэр специально для приложений
where we don't need/want the service abstraction because presumably the где нам не нужна/не нужна абстракция службы, потому что предположительно
protocols being used for such applications isn't TCP (which has a listening протоколы, используемые для таких приложений, не являются TCP (у которого есть возможность прослушивания).
port + ephemeral port ranges). port + эфемерные диапазоны портов).

VOIP, SIP, RTP, Games, all require host networking for latency reasons and VOIP, SIP, RTP, игры — всем требуется хост-сеть по причинам задержки и
protocol reasons so while services are "interesting," I suspect that most протокола, поэтому, хотя сервисы и «интересны», я подозреваю, что большинство
people that are able to use services can live with the inconvenience of люди, которые могут пользоваться услугами, могут жить с неудобствами
having more lines exposing individual ports in their pod/service files. иметь больше строк, раскрывающих отдельные порты в своих файлах pod/service. For За
people that need to expose anything in excess of 100 or so ports (and людям, которым нужно открыть что-либо, превышающее 100 или около того портов (и
practically 10s of thousands on average), this approach is intractable and практически 10 с тысяч в среднем), этот подход неразрешим и
shipping earlier with a smaller scope would be preferable. доставка раньше с меньшим объемом была бы предпочтительнее.

— —
You are receiving this because you were mentioned. Вы получаете это, потому что вас упомянули.
Reply to this email directly, view it on GitHub Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-275325266 , https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-275325266 ,
or mute the thread или заглушить тему
https://github.com/notifications/unsubscribe-auth/AFVgVG7EuYbvUm8ipX1f_odXELMKmfGWks5rWE3cgaJpZM4H_7wH https://github.com/notifications/unsubscribe-auth/AFVgVG7EuYbvUm8ipX1f_odXELMKmfGWks5rWE3cgaJpZM4H_7wH
. .

Правила брандмауэра, автоматически прописываемые k8s, предотвращают открытый доступ к этим портам, хотя правильно?

@thockin Session affinity with SIP and UDP will require layer 7 packet introspection. Сходство сеансов @thockin с SIP и UDP потребует самоанализа пакетов уровня 7. You can't just really on client IP for session affinity because the client for these connections is mostly likely some other server (such as a session border controller) instead of the client initiating the call. Вы не можете просто использовать IP-адрес клиента для привязки сеанса, потому что клиент для этих подключений, скорее всего, является каким-то другим сервером (например, пограничным контроллером сеанса), а не клиентом, инициирующим вызов. Therefore a service will possibly see all its inbound connections coming in from the same endpoint. Поэтому служба, возможно, увидит все свои входящие соединения, поступающие с одной и той же конечной точки. The LB will need to understand SIP protocol (via headers, route headers, etc.). LB должен понимать протокол SIP (через заголовки, заголовки маршрутов и т. д.). So that's what I meant by native SIP support. Вот что я имел в виду под встроенной поддержкой SIP. I would like to be able to provision a SIP service in front of a bunch of pods that communicate with SIP and have it listen on the standard SIP UDP port (5060 or 5061) but that would require a native SIP load balancer. Я хотел бы иметь возможность предоставлять службу SIP перед кучей модулей, которые взаимодействуют с SIP и прослушивают стандартный порт SIP UDP (5060 или 5061), но для этого потребуется собственный балансировщик нагрузки SIP. By the way this is not really a port range issue because SIP only needs a couple of ports just like http. Кстати, на самом деле это не проблема диапазона портов, потому что SIP требуется только пара портов, как и http.

RTP, which is used to stream media in Voip applications, is the issue when you start talking about enabling k8 services with large port ranges. RTP, который используется для потоковой передачи мультимедиа в приложениях VoIP, является проблемой, когда вы начинаете говорить о включении служб k8 с большими диапазонами портов. That's the only use case I can think of. Это единственный вариант использования, о котором я могу думать. The IP:port that a caller needs to stream media to on a media server is sent back to the caller in a response to a SIP INVITE message received at the service (eg a SIP based service allocates a media port on a media service and then sends that back to the caller). IP:порт, на который вызывающему абоненту необходимо передавать медиаданные на медиа-сервере, отправляется обратно вызывающему абоненту в ответ на сообщение SIP INVITE, полученное в службе (например, служба на основе SIP выделяет медиа-порт в медиа-службе, а затем отправляет это обратно вызывающему абоненту). This is carried in a Session Description back to the caller and may traverse many hops. Это передается в описании сеанса обратно вызывающей стороне и может проходить через множество переходов. This media port could be any dynamic port allocated from a large part range. Этот медиа-порт может быть любым динамическим портом, выделенным из большого диапазона частей. I was not aware that hostNetwork would allow you to bind to any port on the host without a definition in the yml file. Я не знал, что hostNetwork позволит вам привязываться к любому порту на хосте без определения в файле yml. If that's the case this may not be necessary. Если это так, то это может и не понадобиться. Docker compose doesn't work this way so I assumed k8 also would need that port range to be specified in the yml file. Docker compose не работает таким образом, поэтому я предположил, что k8 также потребуется указать этот диапазон портов в файле yml. If we wanted to do this without hostHetwork it could get very complicated. Если бы мы хотели сделать это без hostHetwork, это могло бы стать очень сложным. For instance, how would the application that is allocating the IP and port be able to chose a port that is routable by some external endpoint? Например, как приложение, которое выделяет IP-адрес и порт, сможет выбрать порт, маршрутизируемый какой-либо внешней конечной точкой? For now I think I agree with your comment that its probably best to just stick with hostNetwork and not worry about large port ranges for media services. На данный момент я думаю, что согласен с вашим комментарием, что, вероятно, лучше просто придерживаться hostNetwork и не беспокоиться о больших диапазонах портов для медиа-сервисов. As you said, these types of applications will most likely prefer hostNetwork anyway for performance reasons. Как вы сказали, эти типы приложений, скорее всего, в любом случае предпочтут hostNetwork из соображений производительности. I'm going to try removing the static list of ports from my yml file today! Сегодня я попытаюсь удалить статический список портов из моего yml-файла!

With that said, should this really morph into a discussion about native support for SIP in k8? С учетом сказанного, должно ли это действительно превратиться в обсуждение встроенной поддержки SIP в k8?

As @thockin stated above, there is no need to specify a port range in the yml file if you are using "hostNetwork": true mode. Как указано выше @thockin , нет необходимости указывать диапазон портов в файле yml, если вы используете режим «hostNetwork»: true. I tested this and it works. Я проверил это, и это работает. This provides what I was looking for but I would be interested to hear if others still need port range support and why. Это обеспечивает то, что я искал, но мне было бы интересно узнать, нужна ли другим поддержка диапазона портов и почему. Seems like native support for SIP load balancing should be opened in a different feature request. Похоже, что встроенная поддержка балансировки нагрузки SIP должна быть открыта в другом запросе функции.

I've seen a number of places where people have wanted to open ranges of Я видел несколько мест, где люди хотели открыть диапазоны
ports. порты. I don't have the examples off-hand. У меня нет примеров навскидку. One example was "whole-IP" Одним из примеров был «полный IP».
forwarding with no port remapping (VIP). переадресация без переназначения портов (VIP).

On Fri, Jan 27, 2017 at 11:20 AM, Brian Pulito [email protected] В пятницу, 27 января 2017 г., в 11:20, Брайан Пулито, [email protected]
wrote: написал:

As @thockin https://github.com/thockin stated above, there is no need Как указано выше @thockin https://github.com/thockin , нет необходимости
to specify a port range in the yml file if you are using "hostNetwork": чтобы указать диапазон портов в файле yml, если вы используете «hostNetwork»:
true mode. истинный режим. I tested this and it works. Я проверил это, и это работает. This provides what I was looking for Это обеспечивает то, что я искал
but I would be interested to hear if others still need port range support но мне было бы интересно услышать, нужна ли другим поддержка диапазона портов
and why. и почему. Seems like native support for SIP load balancing should be opened Похоже, что встроенная поддержка балансировки нагрузки SIP должна быть открыта.
in a different feature request. в другом запросе функции.

— —
You are receiving this because you were mentioned. Вы получаете это, потому что вас упомянули.
Reply to this email directly, view it on GitHub Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-275750382 , https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-275750382 ,
or mute the thread или заглушить тему
https://github.com/notifications/unsubscribe-auth/AFVgVG0DGSN2PHnh_xviEChEIYKHltgIks5rWkN5gaJpZM4H_7wH https://github.com/notifications/unsubscribe-auth/AFVgVG0DGSN2PHnh_xviEChEIYKHltgIks5rWkN5gaJpZM4H_7wH
. .

We would also like to see port ranges supported for pods. Мы также хотели бы, чтобы диапазоны портов поддерживались для модулей. We are trying to run GlusterFS inside Kubernetes using PetSet. Мы пытаемся запустить GlusterFS внутри Kubernetes с помощью PetSet. GlusterFS uses one port for each volume provisioned. GlusterFS использует один порт для каждого подготовленного тома. Their official documentation recommends opening 49152:49251 ports. Их официальная документация рекомендует открывать порты 49152:49251.
https://github.com/heketi/heketi/wiki/Kubernetes-Integration#infrastructure -requirements https://github.com/heketi/heketi/wiki/Kubernetes-Integration#infrastructure — требования

This is particularly important when dynamic provisioning is used for GlusterFS volumes. Это особенно важно, когда для томов GlusterFS используется динамическая подготовка.

@bpulito How do you implement load balancing for SIP/RTP in a Kubernetes environment? @bpulito Как вы реализуете балансировку нагрузки для SIP/RTP в среде Kubernetes? I understand that K8S services / cloud load balancers would need to operate at L7 to implement session affinity for SIP/RTP. Я понимаю, что службы K8S/балансировщики облачной нагрузки должны работать на уровне L7 для реализации сходства сеансов для SIP/RTP. And in such a scenario - if you're not using K8S services - how do you implement service discovery and load balancing in K8S for SIP/RTP workloads. И в таком сценарии — если вы не используете службы K8S — как реализовать обнаружение служб и балансировку нагрузки в K8S для рабочих нагрузок SIP/RTP.

@thockin Is it possible to write an L7 ingress controller for SIP/RTP traffic that bypasses the concept of services in K8S? @thockin Можно ли написать контроллер входа L7 для трафика SIP / RTP, который обходит концепцию служб в K8S? In such a case, one would run pods in host networking mode - so you don't need any yaml for port ranges in the pod spec - and use the ingress controller to load balance traffic between the pods. В таком случае можно было бы запускать модули в сетевом режиме хоста — так что вам не нужен yaml для диапазонов портов в спецификации модуля — и использовать контроллер входа для балансировки трафика между модулями.

I too agree that a new issue should be created for supporting native load balancing for SIP/RTP traffic in Kubernetes. Я также согласен с тем, что необходимо создать новую проблему для поддержки встроенной балансировки нагрузки для трафика SIP/RTP в Kubernetes.

PS: We have a requirement for running a WebRTC gateway on Kubernetes. PS: у нас есть требование для запуска шлюза WebRTC в Kubernetes.

@khatribharat i've experimented in the past with using Kamailio as a SIP/RTP proxy in a daemonset with hostNetwork. @khatribharat В прошлом я экспериментировал с использованием Kamailio в качестве прокси-сервера SIP / RTP в наборе демонов с hostNetwork. This would be deployed to nodes with public addresses and do direct to pod communication on the inside as you say. Это будет развернуто на узлах с общедоступными адресами и, как вы говорите, будет напрямую связываться с pod внутри. Not had a play with custom ingress controllers but i think it would be a similar concept. Не имел опыта работы с пользовательскими контроллерами входа, но я думаю, что это будет похожая концепция.

+1

+1

In our use case we need to open ports to a daemon (ds) on each host, and need to allow access to these ports. В нашем случае нам нужно открыть порты для демона (ds) на каждом хосте и разрешить доступ к этим портам.
Typically we need up to a few hundred ports per host. Обычно нам требуется до нескольких сотен портов на хост.
Opening a range would be helpful. Открытие диапазона было бы полезно.

https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-266244214

I think it's very helpful for webgames. Я думаю, что это очень полезно для веб-игр. We need to start thounds of services, there're many services up and down in everyday. Нам нужно запустить множество сервисов, каждый день появляется много сервисов. So if it supports port ranges in services, that will be very very helpful. Поэтому, если он поддерживает диапазоны портов в службах, это будет очень полезно.

+1

Хотел настроить сервер localtunnel на k8s, есть ли информация, когда эта функция будет доступна?

There's an IPVS proposal open now and IPVS, for example, doesn't natively Сейчас открыто предложение IPVS, а IPVS, например, изначально не
support ranges (as far as I know). диапазоны поддержки (насколько я знаю). Before we can proceed here, we need to Прежде чем мы сможем продолжить здесь, нам нужно
answer that. ответь на это.

On Tue, Jun 6, 2017 at 9:03 AM, Alex [email protected] wrote: Во вторник, 6 июня 2017 г., в 9:03, Алекс уведомления@github.com написал:

Wanted to setup localtunnel server Хотел настроить сервер localtunnel
https://github.com/localtunnel/server#overview on k8s, is there any https://github.com/localtunnel/server#overview на k8s, есть ли
info when this feature going to be available? информация, когда эта функция будет доступна?

— —
You are receiving this because you were mentioned. Вы получаете это, потому что вас упомянули.
Reply to this email directly, view it on GitHub Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-306534278 , https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-306534278 ,
or mute the thread или заглушить тему
https://github.com/notifications/unsubscribe-auth/AFVgVE-dqR3BN9f9xygMMwijK7dwZIq_ks5sBXhhgaJpZM4H_7wH https://github.com/notifications/unsubscribe-auth/AFVgVE-dqR3BN9f9xygMMwijK7dwZIq_ks5sBXhhgaJpZM4H_7wH
. .

@bpulito It's not only SIP, you'll also need for telemetry like MQTT and for other many erlang based distributed systems like couchdb, coucbase etc. @bpulito Это не только SIP, вам также понадобится для телеметрии, такой как MQTT, и для многих других распределенных систем на основе erlang, таких как Couchdb, coucbase и т. д.

Even if IPVS will add support for port range load balancing the signaling packets and media gateways still remain a problem for both SIP and MQTT protocols because the missing of session affinity mechanism. Даже если IPVS добавит поддержку балансировки нагрузки диапазона портов, сигнальные пакеты и медиашлюзы по-прежнему остаются проблемой как для протоколов SIP, так и для MQTT из-за отсутствия механизма сходства сеансов.

If you control the clients then perphaps it's better to load balance via a well implemented SRV mechanism. Если вы контролируете клиентов, то, возможно, лучше балансировать нагрузку с помощью хорошо реализованного механизма SRV. However most SIP services do not control clients and they have to deal with trunks and SBC. Однако большинство SIP-сервисов не контролируют клиентов, и им приходится иметь дело с транками и SBC.

@thockin My proposal would sound something like this: @thockin Мое предложение будет звучать примерно так:

1. We need to build a custom object like ingress. Нам нужно создать собственный объект, такой как ingress. This custom controller object should be able to allocate public IP, control SRV entries on kube-dns and perform sanity check against k8s API. Этот настраиваемый объект контроллера должен иметь возможность выделять общедоступный IP-адрес, управлять записями SRV в kube-dns и выполнять проверку работоспособности с помощью API k8s.

2. We need a new service type like "ExternalName" which instead mapping CNAME will map SRV records. Нам нужен новый тип службы, такой как «ExternalName», который вместо сопоставления CNAME будет отображать записи SRV. However it need to act like a headless service and the created Endpoints record in the k8s API should point directly to Pods without proxying. Однако он должен действовать как автономный сервис, а созданная запись конечных точек в API k8s должна указывать непосредственно на поды без проксирования. This way you don't need to map port ranges because is nothing to proxy. Таким образом, вам не нужно сопоставлять диапазоны портов, потому что нечего проксировать.

This implementation will cover any kind of stateful service on L4: mqtt, SIP, XMPP, cross cluster/datacenter replication or shards balancing. Эта реализация будет охватывать любой сервис с отслеживанием состояния на L4: mqtt, SIP, XMPP, репликацию между кластерами/центрами обработки данных или балансировку сегментов. NFV will really need this kind of support but at this point telco industry is more focused on implementations on top of OpenStack but at some point they will also need K8s. NFV действительно понадобится такая поддержка, но на данный момент индустрия телекоммуникаций больше сосредоточена на реализации поверх OpenStack, но в какой-то момент им также потребуются K8. So telco community should start contribute on this part. Поэтому телекоммуникационное сообщество должно начать вносить свой вклад в эту часть. I would start contribute but I'm not 100% sure is this the right approach since I do not have too much experience in K8s internals details. Я бы начал вносить свой вклад, но я не уверен на 100%, что это правильный подход, так как у меня нет слишком большого опыта в деталях внутреннего устройства K8. Maybe my proposal is not the right approach. Возможно, мое предложение не является правильным подходом.

And just to add one more example - Passive FTP. И просто добавить еще один пример - Пассивный FTP. I cannot use it as i need to expose a passive port range on the service (NodePort for exmaple) with a range (31000-31300 for example). Я не могу использовать его, так как мне нужно указать диапазон пассивных портов в службе (например, NodePort) с диапазоном (например, 31000-31300).

@ m1093782566 m1093782566 Любые мысли о том, как поддерживать диапазоны в режиме IPVS?

@thockin @thockin

As far as I know, fwmark with ipvsadm can do port ranges. Насколько я знаю, fwmark с ipvsadm умеет делать диапазоны портов. For example, Например,

iptables -A PREROUTNG -t mangle -d 172.16.52.57 -p tcp --dport 100:200 -j MARK --set-mark 9

ipvsadm -A -f 9 -s rr

ipvsadm -a -f 9  -r 172.16.52.60 -g

ipvsadm -a -f 9 -r 172.16.52.61 -g

Each service with port range will create a single iptables rule. Каждая служба с диапазоном портов создаст одно правило iptables. I think it's acceptable since service that requiring port range is minority . Я думаю, что это приемлемо, поскольку службы, которым требуется диапазон портов, составляют меньшинство .

PS. PS. the example is in IPVS DR(not NAT) forwarding mode, but it also works for NAT mode. пример находится в режиме переадресации IPVS DR (не NAT), но он также работает в режиме NAT.

Another option is create IPVS service one by one - it's not a clever way. Другой вариант - создавать службы IPVS по одному - это не умный способ.

I've seen a number of places where people have wanted to open ranges of Я видел несколько мест, где люди хотели открыть диапазоны
ports. порты. I don't have the examples off-hand. У меня нет примеров навскидку. One example was "whole-IP" Одним из примеров был «полный IP».
forwarding with no port remapping (VIP). переадресация без переназначения портов (VIP).

I wonder if there are REALLY user cases requiring port remapping? Интересно, есть ли ДЕЙСТВИТЕЛЬНО пользовательские случаи, требующие переназначения портов?

One user case I can find is: Один случай пользователя, который я могу найти, это:

Real server(A) listen on both 80 and 443 and users specify port range[80, 443] Реальный сервер (A) прослушивает как 80, так и 443, и пользователи указывают диапазон портов [80, 443].

Visist service VIP:80 or VIP:443 -> A without port remapping. Посетите сервис VIP:80 или VIP:443 -> A без переназначения портов.

However, if with port remapping, users specify port range [11, 12], what corresponding target port should be? Однако, если при переназначении портов пользователи указывают диапазон портов [11, 12], каким должен быть соответствующий целевой порт? [80, 443] or [443, 80]? [80, 443] или [443, 80]?

Someone may say, port range can be a service port & target port pair, for example, Кто-то может сказать, что диапазон портов может быть парой служебного порта и целевого порта, например,

service port: [1000: 2000] сервисный порт: [1000:2000]

target port: [5000: 6000] целевой порт: [5000: 6000]

I don't think it make sense especially in large amount ports since the mapping relationship is usually unpredictable . Я не думаю, что это имеет смысл, особенно в портах с большим количеством портов, поскольку отношения сопоставления обычно непредсказуемы .

PS. PS.

From my test result, FWMARK with IPVS does not support port remapping, even in masq mode. Судя по результатам моего теста, FWMARK с IPVS не поддерживает переназначение портов даже в режиме masq.

Even with pure iptables -m multiport , I don't know how to support port range and port remapping at the same time(with single iptables command). Даже с чистыми iptables -m multiport я не знаю, как поддерживать диапазон портов и переназначение портов одновременно (с помощью одной команды iptables). For example, Например,

iptables -A INPUT -p tcp -m multiport --dports 3000,10000,7080,8080,3000,5666 -j ACCEPT

I'm in a project right now requiring that we open somewhere in the ballpark of 10000 ports, and I am not sitting down to write down every single port one by one in the config file. Сейчас я работаю над проектом, требующим, чтобы мы открыли примерно 10000 портов, и я не собираюсь записывать каждый порт один за другим в файле конфигурации. Is there any ETA on this? Есть ли ETA по этому поводу? It's a pretty ridiculous feature not to have considering how required it is when running servers. Это довольно нелепая функция, которую не иметь, учитывая, насколько она необходима при работе серверов.

• This can't really be supported in the userspace proxy-mode Это не может поддерживаться в прокси-режиме пользовательского пространства.

I think it could be done with libnetfilter_queue : the proxy would add a rule so that incoming connections would first get sent to -j NFQUEUE , which kube-proxy would be monitoring, so it would see the details of the incoming packet before it was accepted, and it could record the source IP:port→destination port in a hash table. Я думаю, это можно сделать с помощью libnetfilter_queue : прокси-сервер добавит правило, чтобы входящие соединения сначала отправлялись на -j NFQUEUE , который kube-proxy будет отслеживать, чтобы он мог видеть детали входящего пакета до он был принят, и он мог записать IP-адрес источника: порт → порт назначения в хэш-таблицу. Then the packet would hit another iptables rule basically like the standard userspace proxy per-service rule, except redirecting the entire port range to a single port on the proxy. Затем пакет попадет в другое правило iptables, в основном аналогичное стандартному правилу прокси-сервера в пользовательском пространстве для каждой службы, за исключением перенаправления всего диапазона портов на один порт прокси-сервера. The proxy would accept the connection, and look up the source IP:port in the hash table to find the corresponding original destination port, and then open a connection to the correponding port on the pod IP. Прокси-сервер примет соединение и проверит исходный IP-адрес: порт в хеш-таблице, чтобы найти соответствующий исходный порт назначения, а затем откроет соединение с соответствующим портом на IP-адресе модуля.

К вашему сведению, есть приличная (нуждается в паре доработок, но, похоже, работает хорошо) клиентская библиотека nfqueue в чистом виде: https://github.com/subgraph/go-nfnetlink

@danwinship @DirectXMan12 @danwinship @DirectXMan12

Thanks for coming up userspace proxy mode solutions. Спасибо, что придумали решения для режима прокси-сервера в пользовательском пространстве. BTW, there is a proposed IPVS proxy mode solution(IPVS + FWMARK) in https://github.com/kubernetes/community/pull/1738. Кстати, в https://github.com/kubernetes/community/pull/1738 предлагается решение для прокси-режима IPVS (IPVS + FWMARK). Please help review this potential solution when you have a chance, thanks! Пожалуйста, помогите просмотреть это потенциальное решение, когда у вас есть шанс, спасибо!

Anyway, port range is a strong feature request and I think that most of the blocking issues are in implementation side. В любом случае, диапазон портов — это сильный запрос на функцию, и я думаю, что большинство проблем с блокировкой связано с реализацией.

@Excludos even if you would write the code for 10000 ports it wouldn't work. @Excludes , даже если бы вы написали код для 10000 портов, это не сработало бы. The deployment complains that the file is too large. Развертывание жалуется, что файл слишком большой. I generated the code for port configuration and I ended up with such error. Я сгенерировал код для конфигурации порта и получил такую ​​ошибку. So it isn't even a problem creating big YAML file. Так что даже не проблема создать большой файл YAML. It seems that it's not possible at all to expose such port ranges at the moment. Кажется, что на данный момент вообще невозможно выставить такие диапазоны портов. As you pointed out, port ranges are a must have, and it's very strange that they are still not available. Как вы указали, диапазоны портов обязательны, и очень странно, что они до сих пор недоступны.

@KacperMucha is the host networking not an option for you? @KacperMucha , хост-сеть не для вас?

Given the extra memory docker requires for forwarding such large numbers of ports, it seems to be even somewhat of an anti-pattern to do the port forwarding (in the sense that, by design, it seems to be impractical to do port forwarding for such large numbers of ports). Учитывая, что докеру требуется дополнительная память для переадресации такого большого количества портов, переадресация портов кажется даже чем-то вроде анти-шаблона (в том смысле, что по замыслу кажется непрактичным выполнять переадресацию портов для такого количества портов). большое количество портов).

@gsaslis I have similar case as in the initial post here. @gsaslis У меня такой же случай, как и в первом посте здесь. It's a SIP server and it has to have such large amount of ports available. Это SIP-сервер, и он должен иметь такое большое количество доступных портов. As to your suggestion - are you referring to this - https://github.com/Azure/azure-container-networking/blob/master/docs/acs.md? Что касается вашего предложения - вы имеете в виду это - https://github.com/Azure/azure-container-networking/blob/master/docs/acs.md?

@KacperMucha я имею в виду этот http://alesnosek.com/blog/2017/02/14/accessing-kubernetes-pods-from-outside-of-the-cluster/ , как было также упомянуто выше в: https: //github.com/kubernetes/kubernetes/issues/23864#issuecomment -275388709

@gsaslis hostNetwork comes with caveats. @gsaslis hostNetwork имеет оговорки. TLDR is that using hostNetwork currently requires that, at most, a single instance of any service may be run on any host. TLDR заключается в том, что использование hostNetwork настоящее время требует, чтобы на любом хосте мог быть запущен не более одного экземпляра любой службы. A longer response would detail all the reasons for this, possible hacks, and hard limitations, but I think this is the primary detractor. В более подробном ответе будут подробно описаны все причины этого, возможные взломы и жесткие ограничения, но я думаю, что это главный недоброжелатель.

@pdf yes, of course. @pdf да, конечно.

the problem is that - given the current state of Docker - it seems you should NOT even be trying to expose large numbers of ports. проблема в том, что, учитывая текущее состояние Docker, вам НЕ следует даже пытаться открывать большое количество портов. You are advised to use the host network anyway, due to the overhead involved with large port ranges. В любом случае рекомендуется использовать хост-сеть из-за накладных расходов, связанных с большими диапазонами портов. (it adds both latency, as well as consumes significant resources - eg see https://www.percona.com/blog/2016/02/05/measuring-docker-cpu-network-overhead/ ) (это добавляет как задержку, так и потребляет значительные ресурсы - например, см. https://www.percona.com/blog/2016/02/05/measuring-docker-cpu-network-overhead/)

If you are looking for a more official source, there is still (for years) an open issue in Docker about this: Если вы ищете более официальный источник, в Docker все еще существует (уже много лет) открытая проблема по этому поводу:
https://github.com/moby/moby/issues/11185#issuecomment -245983651 https://github.com/moby/moby/issues/11185#issuecomment -245983651

So it seems the tl;dr actually is: Таким образом, кажется, что tl; dr на самом деле:
if your app needs a large port range, use host network, and work around the limitations it does come with. если вашему приложению требуется большой диапазон портов, используйте хост-сеть и обойдите ограничения, с которыми оно связано. Or go write your own iptables rules. Или напишите свои собственные правила iptables.

I don't like either, but, well, when life gives you lemons... ;) Я тоже не люблю, но, ну, когда жизнь дает тебе лимоны... ;)

@gsaslis it's not clear to me that those concerns apply to Kubernetes. @gsaslis мне не ясно, относятся ли эти опасения к Kubernetes. I suggest deferring to those with the knowledge of the various parts involved to declare what's viable. Я предлагаю обратиться к тем, кто знаком с различными вовлеченными частями, чтобы объявить, что жизнеспособно. In the mean time, possible workarounds have already been well documented, however it's apparent that the workarounds are not adequate for all use-cases. В то же время возможные обходные пути уже хорошо задокументированы, однако очевидно, что обходные пути не подходят для всех вариантов использования.

Issues go stale after 90d of inactivity. Проблемы устаревают после 90 дней бездействия.
Mark the issue as fresh with /remove-lifecycle stale . Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Stale issues rot after an additional 30d of inactivity and eventually close. Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

If this issue is safe to close now please do so with /close . Если эту проблему безопасно закрыть сейчас, сделайте это с помощью /close .

Send feedback to sig-testing, kubernetes/test-infra and/or fejta . Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/lifecycle stale /жизненный цикл устарел

/remove-жизненный цикл устарел

Issues go stale after 90d of inactivity. Проблемы устаревают после 90 дней бездействия.
Mark the issue as fresh with /remove-lifecycle stale . Отметьте проблему как свежую с помощью /remove-lifecycle stale .
Stale issues rot after an additional 30d of inactivity and eventually close. Устаревшие проблемы гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

If this issue is safe to close now please do so with /close . Если эту проблему безопасно закрыть сейчас, сделайте это с помощью /close .

Send feedback to sig-testing, kubernetes/test-infra and/or fejta . Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/lifecycle stale /жизненный цикл устарел

/remove-жизненный цикл устарел

port range proposal using kubernetes annotations предложение диапазона портов с использованием аннотаций kubernetes
annotation: portrange.alpha.kubernetes.io/port-end-xxxx аннотация: portrange.alpha.kubernetes.io/port-end-xxxx
https://github.com/kubernetes/kubernetes/commit/2cf5af1f8cc33e2d22ed1968aca05e5323ef9a0b https://github.com/kubernetes/kubernetes/commit/2cf5af1f8cc33e2d22ed1968aca05e5323ef9a0b

can this been merge? может это было слияние?

/жизненный цикл устарел

@maoge Нам нужно выяснить, как IPVS реализует диапазон портов.

There are a lot of "+1" type comments on this bug, but still a lot of vagueness about exactly what people need. Есть много комментариев типа «+1» по поводу этой ошибки, но по-прежнему много неясности в отношении того, что именно нужно людям. In particular, the proposal in https://github.com/kubernetes/community/pull/1738 excludes NodePort and ExternalIP services and doesn't discuss LoadBalancers or Ingress at all (in the actual PR). В частности, предложение в https://github.com/kubernetes/community/pull/1738 исключает сервисы NodePort и ExternalIP и вообще не обсуждает LoadBalancers или Ingress (в фактическом PR). So it doesn't provide any way for a port-range service to accept connections coming from outside the cluster, which is something I think many of the people here probably need. Таким образом, служба диапазона портов не предоставляет никакого способа принимать соединения, поступающие из-за пределов кластера, что, я думаю, многим из присутствующих здесь, вероятно, нужно.

For SIP/RTP-like use cases, where the pod picks a port to use at random out of the port range, you are effectively limited to one Service per client-visible IP, because the pods will be picking the random ports to use based on what ports are currently unbound in their own network namespace, and so if two pods tried to share the same External/Node/LoadBalancer/Ingress IP, they would be unable to see each other's bound ports and so might both try to use the same ephemeral port at the same time. Для случаев использования, подобных SIP/RTP, когда модуль выбирает порт для использования случайным образом из диапазона портов, вы фактически ограничены одной службой на каждый видимый клиенту IP-адрес, потому что модули будут выбирать случайные порты для использования на основе на то, какие порты в настоящее время не связаны в их собственном сетевом пространстве имен, и поэтому, если два модуля попытаются использовать один и тот же внешний/узел/LoadBalancer/Ingress IP, они не смогут видеть связанные порты друг друга и поэтому могут попытаться использовать один и тот же эфемерный порт в то же время.

Given that, it seems like a simpler model would be that rather than having a Service that binds a range of ports, you instead have a Service that binds an entire IP address. Учитывая это, кажется, что более простой моделью будет то, что вместо службы, которая связывает диапазон портов, у вас есть служба, которая связывает весь IP-адрес. ( @thockin hinted at this earlier.) This would be much simpler to implement with the IPVS/userspace/etc proxiers, and would be trivial to add ExternalIP support to as well (perhaps even with an admission controller to ensure you don't bind two whole-IP services to the same ExternalIP). ( @thockin намекнул на это ранее.) Это было бы намного проще реализовать с помощью прокси-серверов IPVS/userspace/etc, и было бы тривиально также добавить поддержку ExternalIP (возможно, даже с контроллером допуска, чтобы гарантировать, что вы не привязываетесь два полнофункциональных IP-сервиса на один и тот же ExternalIP). And it's certainly no harder to add LoadBalancer/Ingress support for than port ranges would be. И, конечно же, добавить поддержку LoadBalancer/Ingress не сложнее, чем диапазоны портов. (NodePort would still be out though, since you can't actually reserve the whole IP in that case.) (Однако NodePort по-прежнему будет отключен, поскольку в этом случае вы не можете зарезервировать весь IP-адрес.)

Binding an entire IP rather than a port range wouldn't work for: Привязка всего IP-адреса, а не диапазона портов, не будет работать для:

1. the case where you want to have both a SIP/RTP-like pick-a-random-port service and one or more other services on the same client-visible IP, but not have all of the services implemented by the same pod. случай, когда вы хотите иметь как SIP/RTP-подобную службу выбора случайного порта, так и одну или несколько других служб на одном и том же видимом для клиента IP-адресе, но не реализовать все службы одним и тем же модулем.
2. the case where you want to have multiple services binding to different port ranges on the same client-visible IP. случай, когда вы хотите, чтобы несколько служб были привязаны к разным диапазонам портов на одном и том же видимом для клиента IP-адресе. (ie, service A binds ports 1000-1999, service B binds ports 2000-2999, etc.) (т.е. служба A связывает порты 1000-1999, служба B связывает порты 2000-2999 и т. д.)

Does anyone need to do either of those things? Кому-нибудь нужно сделать одну из этих вещей? (Or anything else where port ranges would work but binding a whole IP wouldn't?) (Или что-нибудь еще, где диапазоны портов будут работать, но привязка всего IP-адреса не будет?)

Whole-IP services might also not be much help to people who want a Service that binds, eg, 10 ports as opposed to 1000. But they can still just keep writing out all 10 ports individually like they're doing now. Сервисы Whole-IP также могут не очень помочь людям, которым нужен Сервис, который связывает, например, 10 портов вместо 1000. Но они все равно могут просто продолжать записывать все 10 портов по отдельности, как они делают сейчас.

Stale issues rot after 30d of inactivity. Устаревшие проблемы гниют после 30 дней бездействия.
Mark the issue as fresh with /remove-lifecycle rotten . Отметьте проблему как свежую с помощью /remove-lifecycle rotten .
Rotten issues close after an additional 30d of inactivity. Гнилые проблемы закрываются после дополнительных 30 дней бездействия.

If this issue is safe to close now please do so with /close . Если эту проблему безопасно закрыть сейчас, сделайте это с помощью /close .

Send feedback to sig-testing, kubernetes/test-infra and/or fejta . Отправьте отзыв в sig-testing, kubernetes/test-infra и/или fejta .
/lifecycle rotten /жизненный цикл гнилой

/remove-жизненный цикл гнилой

+1 к этому с моей стороны, я работаю над PODS для межкластерной связи, которым необходимо маршрутизировать множество сервисов, было бы очень полезно иметь возможность открывать сразу несколько портов, поэтому мне это не нужно для повторного запуска модуля, чтобы определить новые модули.

+1 для дальности трафика Deluge

/lifecycle frozen /жизненный цикл заморожен
/remove-lifecycle stale /remove-жизненный цикл устарел

Just making sure this doesn't rot. Просто убедиться, что это не гниет.

I meet the same problem. Я встречаю ту же проблему. In my case, I need to run tcp server at random port in runtime. В моем случае мне нужно запустить tcp-сервер на случайном порту во время выполнения.
My solutation is to expose port range in Dockerfile. Мое решение - указать диапазон портов в Dockerfile. Then create service in my application with nodeport using kubernetes java client . Затем создайте службу в моем приложении с помощью nodeport, используя java-клиент kubernetes . One tcp server with one service. Один tcp сервер с одним сервисом.
Stupid and complicated Method but it works with my problem now. Глупый и сложный метод, но теперь он работает с моей проблемой. Hope for support port range Надеюсь на поддержку диапазона портов

Hi @adimania were you able to fix that? Привет, @adimania , тебе удалось это исправить? Also I am getting ice failure when I am deploying sfu/mcu in kubernetes. Также я получаю ледяной сбой, когда развертываю sfu/mcu в kubernetes. Can you help me with this? Можете ли вы помочь мне с этим?

+1 +1

Needed to run the RTP Endpoint services in kubernetes. Требуется для запуска служб конечной точки RTP в kubernetes. Currently running with host networking В настоящее время работает с хост-сетью

I ran into this as an issue getting a mosh based bastion host up and running.. workaround: Я столкнулся с этим как с проблемой запуска и запуска бастионного хоста на основе mosh.. обходной путь:

for i in seq 60000 60100 ; для i в seq 60000 60100 ; do echo -e " - protocol: TCP\n port: $i\n targetPort: $i\n name: bastion-$i" ; do echo -e " - протокол: TCP\n порт: $i\n целевой порт: $i\n имя: bastion-$i" ; done сделано

I do wonder how many ports can be in a service and what the implications of adding hundreds of single items is for the system. Мне интересно, сколько портов может быть в службе и каковы последствия добавления сотен отдельных элементов для системы.

get services is now pretty ugly: get services теперь довольно уродливо:

bastion-mosh LoadBalancer 10.111.49.103 192.168.0.243 60000:30077/UDP,60001:30289/UDP,60002:30482/UDP,60003:32327/UDP,60004:31479/UDP,60005:31174/UDP,60006:31713/UDP,60007:30375/UDP,60008:31823/UDP,60009:31801/UDP,60010:32442/UDP,60011:30647/UDP,60012:31187/UDP,60013:32446/UDP,60014:31723/UDP,60015:30504/UDP,60016:32186/UDP,60017:31339/UDP,60018:31230/UDP,60019:31210/UDP,60020:31659/UDP,60021:31886/UDP,60022:30806/UDP,60023:32163/UDP,60024:32553/UDP,60025:31685/UDP,60026:32478/UDP,60027:30841/UDP,60028:31189/UDP,60029:32533/UDP,60030:30711/UDP,60031:31945/UDP,60032:32311/UDP,60033:30253/UDP,60034:30218/UDP,60035:31354/UDP,60036:31675/UDP,60037:31624/UDP,60038:31019/UDP,60039:31406/UDP,60040:31256/UDP,60041:31430/UDP,60042:32570/UDP,60043:30888/UDP,60044:32179/UDP,60045:32294/UDP,60046:30308/UDP,60047:31087/UDP,60048:31443/UDP,60049:31872/UDP,60050:30373/UDP,60051:30317/UDP,60052:31521/UDP,60053:32437/UDP,60054:31190/UDP,60055:32625/UDP,60056:30150/UDP,60057:31784/UDP,60058:31021/UDP,60 bastion-mosh LoadBalancer 10.111.49.103 192.168.0.243 60000:30077/UDP,60001:30289/UDP,60002:30482/UDP,60003:32327/UDP,60004:31479/UDP,600705:316070/UDP UDP,60007:30375/UDP,60008:31823/UDP,60009:31801/UDP,60010:32442/UDP,60011:30647/UDP,60012:31187/UDP,60013:32446/UDP,60014:31723/UDP, 60015:30504/УДП,60016:32186/УДП,60017:31339/УДП,60018:31230/УДП,60019:31210/УДП,60020:31659/УДП,60021:31886/УДП,60022:30806/УДП,60023: 32163/УДП,60024:32553/УДП,60025:31685/УДП,60026:32478/УДП,60027:30841/УДП,60028:31189/УДП,60029:32533/УДП,60030:30711/УДП,60031:31945/ УДП,60032:32311/УДП,60033:30253/УДП,60034:30218/УДП,60035:31354/УДП,60036:31675/УДП,60037:31624/УДП,60038:31019/УДП,60039:31406/УДП, 60040:31256/УДП,60041:31430/УДП,60042:32570/УДП,60043:30888/УДП,60044:32179/УДП,60045:32294/УДП,60046:30308/УДП,60047:31087/УДП,60048: 31443/УДП,60049:31872/УДП,60050:30373/УДП,60051:30317/УДП,60052:31521/УДП,60053:32437/УДП,60054:31190/УДП,60055:32625/УДП,60056:30150/ УДП,60057:31784/УДП,60058:31021/УДП,60 059:30882/UDP,60060:32543/UDP,60061:30747/UDP,60062:30712/UDP,60063:32287/UDP,60064:31478/UDP,60065:32761/UDP,60066:32061/UDP,60067:32472/UDP,60068:32147/UDP,60069:31375/UDP,60070:30554/UDP,60071:32521/UDP,60072:32394/UDP,60073:31274/UDP,60074:31091/UDP,60075:31394/UDP,60076:31052/UDP,60077:32025/UDP,60078:32757/UDP,60079:31047/UDP,60080:31633/UDP,60081:30081/UDP,60082:30499/UDP,60083:30750/UDP,60084:32193/UDP,60085:32721/UDP,60086:32071/UDP,60087:31532/UDP,60088:30451/UDP,60089:30461/UDP,60090:30511/UDP,60091:31033/UDP,60092:31086/UDP,60093:31796/UDP,60094:30899/UDP,60095:31887/UDP,60096:32372/UDP,60097:32613/UDP,60098:31490/UDP,60099:31295/UDP,60100:30822/UDP 19h 059:30882/УДП,60060:32543/УДП,60061:30747/УДП,60062:30712/УДП,60063:32287/УДП,60064:31478/УДП,60065:32761/УДП,60066:32061/УДП,60067: 32472/УДП,60068:32147/УДП,60069:31375/УДП,60070:30554/УДП,60071:32521/УДП,60072:32394/УДП,60073:31274/УДП,60074:31091/УДП,60075:31394/ УДП,60076:31052/УДП,60077:32025/УДП,60078:32757/УДП,60079:31047/УДП,60080:31633/УДП,60081:30081/УДП,60082:30499/УДП,60083:30750/УДП, 60084:32193/УДП,60085:32721/УДП,60086:32071/УДП,60087:31532/УДП,60088:30451/УДП,60089:30461/УДП,60090:30511/УДП,60091:31033/УДП,60092: 31086/УДП,60093:31796/УДП,60094:30899/УДП,60095:31887/УДП,60096:32372/УДП,60097:32613/УДП,60098:31490/УДП,60099:31295/УДП,60100:30822/ УДП 19ч

Another reason this would be handy: specifying a large amount of ports to open on Services means that an equal amount of iptables rules get created (if k8s is using the iptables proxy mode, like GKE does). Еще одна причина, по которой это может быть удобно: указание большого количества портов для открытия в службах означает, что будет создано равное количество правил iptables (если k8s использует режим прокси iptables , как это делает GKE). Iptables performance slows down dramatically after about 10,000 rules (as implied here ) which means that a service with 10,000 open ports (for PASV FTP, for instance) or 10 services with 1000 open ports would degrade iptables performance on k8s nodes. Производительность Iptables резко снижается примерно после 10 000 правил (как подразумевается здесь ), что означает, что служба с 10 000 открытых портов (например, для PASV FTP) или 10 служб с 1000 открытых портов ухудшит производительность iptables на узлах k8s.

This problem is solved by the IPVS proxy, but not all environments support this mode (again, GKE). Эту проблему решает прокси IPVS, но не все окружения поддерживают этот режим (опять же, GKE). Being able to specify ranges instead of individual ports would also solve this problem. Возможность указывать диапазоны вместо отдельных портов также решила бы эту проблему.

это все еще возможно без убийства iptables?

@m1093782566 @m1093782566
If this issue has been triaged, please comment /remove-triage unresolved . Если эта проблема была проверена, пожалуйста, прокомментируйте /remove-triage unresolved .

If you aren't able to handle this issue, consider unassigning yourself and/or adding the help-wanted label. Если вы не можете справиться с этой проблемой, рассмотрите возможность отмены своего назначения и/или добавления ярлыка help-wanted .

🤖 I am a bot run by vllry. 🤖 Я бот под управлением vllry. 👩‍🔬 👩‍🔬

Side note: Now that multiple interfaces per pod are becoming a standard, it Примечание: теперь, когда несколько интерфейсов на модуль становятся стандартом,
seems that such an additional interface is the escape hatch to expose port кажется, что такой дополнительный интерфейс является аварийным люком, чтобы открыть порт
ranges. диапазоны.

@fabiand , не могли бы вы уточнить?

Actually - I was wrong, I ignored the context. На самом деле - я был неправ, я проигнорировал контекст.
N, even with additional interfaces you can not export ranges _in services_ Н, даже с дополнительными интерфейсами нельзя экспортировать диапазоны _в сервисы_
. . It would just allow you to expose a complete IP to the outside of a Это просто позволит вам выставить полный IP-адрес снаружи
cluster, which is similar nbut not the same. кластер, который похож, но не один и тот же.

И как бы вы это сделали?

использовать multus для предоставления дополнительных сетевых карт для модуля?

Multus, похоже, не работает с openshift 3.11 или атомарным хостом :/

Multus does not seem to work with openshift 3.11 or atomic host :/ Multus, похоже, не работает с openshift 3.11 или атомарным хостом :/

@kempy007 Multus does work with OpenShift 3.11 though it's not quite as well integrated as with OpenShift 4.x @ kempy007 Multus работает с OpenShift 3.11, хотя он не так хорошо интегрирован, как с OpenShift 4.x.

Thanks @dcbw , I pinned it down to interface requiring promisc mode enabling. Спасибо @dcbw , я прикрепил его к интерфейсу, требующему включения неразборчивого режима. Is OpenShift 4.x now deployable to non aws targets now, I see more providers now. Можно ли теперь развернуть OpenShift 4.x на цели, отличные от aws, теперь я вижу больше поставщиков. :) I will eagerly try v4 tomorrow. :) Завтра с удовольствием попробую v4.

Hi, Привет,
I am working on adding static nat rule to translate cluster-ip to pod-ip without port translation, so entire port range opens up between cluster-ip and pod-ip. Я работаю над добавлением статического правила nat для преобразования IP-адреса кластера в IP-адрес пода без преобразования портов, поэтому весь диапазон портов открывается между IP-кластером и IP-подом.

Implementation is simple. Реализация проста. On presence of an annotation, static nat rule is added. При наличии аннотации добавляется статическое правило nat.

I wanted to know if anyone would be interested before I proceed further. Я хотел знать, будет ли кому-то интересно, прежде чем я продолжу.

Implementation is available at mybranch Реализация доступна на mybranch

Hi, Привет,
I am working on adding static nat rule to translate cluster-ip to pod-ip without port translation, so entire port range opens up between cluster-ip and pod-ip. Я работаю над добавлением статического правила nat для преобразования IP-адреса кластера в IP-адрес пода без преобразования портов, поэтому весь диапазон портов открывается между IP-кластером и IP-подом.

Implementation is simple. Реализация проста. On presence of an annotation, static nat rule is added. При наличии аннотации добавляется статическое правило nat.

I wanted to know if anyone would be interested before I proceed further. Я хотел знать, будет ли кому-то интересно, прежде чем я продолжу.

Implementation is available at mybranch Реализация доступна на mybranch

That is great, we are interested in,. Это здорово, мы заинтересованы в,.

Any updates on supporting port range? Есть ли обновления по поддержке диапазона портов? I think it's a very useful feature Я думаю, что это очень полезная функция

Context: sig-architecture subgroup work to search for technical debt Контекст: подгруппа sig-architecture работает над поиском технического долга
Category: Networking Категория: Сеть
Reason: Wider adoption, useful for RTP/media kind of traffic, community interest, not supported in usermode kubeproxy Причина: более широкое распространение, полезно для RTP/медиа-трафика, интерес сообщества, не поддерживается в пользовательском режиме kubeproxy.

Эта функция также будет удобна для запуска контроллера домена samba в kubernetes, поскольку требуемые порты включают все динамические порты/порты rpc: 49152-65535.

Also deploying this service is therefore currently impossible, as a kubectl apply -f samba-dc.yaml fails with: Кроме того, развертывание этой службы в настоящее время невозможно, так как kubectl apply -f samba-dc.yaml завершается с ошибкой:

The Deployment "samba-dc" is invalid: metadata.annotations: Too long: must have at most 262144 characters Недопустимое развертывание «samba-dc»: metadata.annotations: слишком длинное: должно быть не более 262144 символов.

it is also impractical to handle such a large deployment file eg https://gist.github.com/agowa338/fbf945f03dd6b459c315768ecbe89fc0 также нецелесообразно обрабатывать такой большой файл развертывания, например https://gist.github.com/agowa338/fbf945f03dd6b459c315768ecbe89fc0 .

Hi, Привет,

Any update on the support of port range for a pod/service. Любое обновление поддержки диапазона портов для модуля/службы. Is any development happening around this area. Происходит ли какое-либо развитие вокруг этой области.

Gaurav Гаурав

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

До сих пор я только что нашел одно решение для реализации этого, изменив сетевой стек кластера k8s на реализацию, как показано здесь: https://fosdem.org/2020/schedule/event/rethinking_kubernetes_networking_with_srv6/

I am reminded of this issue as I try to put an NFS server behind a load balancer for ex-cluster servicing. Я вспомнил об этой проблеме, когда пытался разместить NFS-сервер за балансировщиком нагрузки для обслуживания вне кластера. Portmapper hands out ports that the LB is not forwarding and thus this does not work. Portmapper раздает порты, которые LB не пересылает, и поэтому это не работает.

Wondering if https://github.com/cilium/cilium can solve kube-proxy scale issues by bypassing iptables limitations. Интересно, может ли https://github.com/cilium/cilium решить проблемы масштабирования kube-proxy, обойдя ограничения iptables.

What is the plan on this feature? Каков план по этой функции? Any work around? Любая работа вокруг? Needed for Требуется для

• Media Server Медиа-сервер
• RTC Server Сервер реального времени
• SIP/RTP Server SIP/RTP-сервер
• NFS Server NFS-сервер
• Samba DC Самба, округ Колумбия
• Telnet Server Telnet-сервер

Также для STUN-сервера

What is the plan on this feature? Каков план по этой функции? Any work around? Любая работа вокруг? Needed for Требуется для

The workaround is: Обходной путь:

Until now I just found one solution for implementing this, by changing the networking stack of the k8s cluster to an implementation like shown here: https://fosdem.org/2020/schedule/event/rethinking_kubernetes_networking_with_srv6/ До сих пор я только что нашел одно решение для реализации этого, изменив сетевой стек кластера k8s на реализацию, как показано здесь: https://fosdem.org/2020/schedule/event/rethinking_kubernetes_networking_with_srv6/

You need to remove the NAT and route your traffic directly to the pods. Вам нужно удалить NAT и направить трафик прямо на поды. This also works for IPv4, but either requires an external NAT46 (with 1:1 mapping) or a routed subnet (might be expansive). Это также работает для IPv4, но требует либо внешнего NAT46 (с отображением 1:1), либо маршрутизируемой подсети (может быть обширной).

• Telnet Server Telnet-сервер

This one shouldn't be affected, Telnet uses only a single port. Это не должно быть затронуто, Telnet использует только один порт. Did you mean active FTP instead? Вы имели в виду активный FTP вместо этого?

You need to remove the NAT and route your traffic directly to the pods. Вам нужно удалить NAT и направить трафик прямо на поды. This also works for IPv4, but either requires an external NAT46 (with 1:1 mapping) or a routed subnet (might be expansive). Это также работает для IPv4, но требует либо внешнего NAT46 (с отображением 1:1), либо маршрутизируемой подсети (может быть обширной).

That's a workaround, yes, but not a solution. Это обходной путь, да, но не решение. Routing to the pod subnet is a major security hole and people who understand the ramifications of doing this ... don't. Маршрутизация к подсети — это серьезная дыра в безопасности, и люди, которые понимают последствия этого… не понимают.

@briantopping It isn't a security hole if you know what you're doing... The linked document from above shows how to architect such a setup. @briantopping Это не дыра в безопасности, если вы знаете, что делаете ... Связанный документ выше показывает, как спроектировать такую ​​​​настройку. And with that setup in place you can just easily add a NAT46 for a public IPv4 in front of it... И с этой настройкой вы можете просто добавить NAT46 для общедоступного IPv4 перед ним...

Instead of "exposing" ports one can as well just create iptables rules to allow/deny the traffic... Вместо того, чтобы «раскрывать» порты, можно просто создать правила iptables, чтобы разрешить/запретить трафик...

It's a modern IPv6 first design, these all rely on routing instead of NATing and regarding security it's the same. Это современный первый дизайн IPv6, все они основаны на маршрутизации, а не на NAT, и в отношении безопасности это то же самое. Just requires the admin to know different concepts... Просто требует от администратора знания разных концепций...
These setups also tend to be much more secure because of not relying on "This service is not nated to external so nobody could access it" philosophies (there are often very trivial ways to bypass these and still access the non exposed services)... Эти настройки также, как правило, гораздо более безопасны, поскольку они не полагаются на философию «Эта служба не является внешней, поэтому никто не может получить к ней доступ» (часто есть очень тривиальные способы обойти их и по-прежнему получать доступ к скрытым службам)...

• Telnet Server Telnet-сервер

This one shouldn't be affected, Telnet uses only a single port. Это не должно быть затронуто, Telnet использует только один порт. Did you mean active FTP instead? Вы имели в виду активный FTP вместо этого?

By telnet server I meant console server, a server that listens on a range of ports and connect each port to a serial console of a physical or virtual device. Под telnet-сервером я имел в виду консольный сервер, сервер, который прослушивает ряд портов и подключает каждый порт к последовательной консоли физического или виртуального устройства. Mostly using the telnet protocol. В основном по протоколу telnet.

It isn't a security hole if you know what you're doing Это не дыра в безопасности, если вы знаете, что делаете

Nothing is a security hole, if you know what you're doing. Ничто не является дырой в безопасности, если вы знаете, что делаете. Let's strive for secure and easy to use by default. Давайте стремиться к безопасному и простому в использовании по умолчанию.

Nothing is a security hole, if you know what you're doing. Ничто не является дырой в безопасности, если вы знаете, что делаете. Let's strive for secure and easy to use by default. Давайте стремиться к безопасному и простому в использовании по умолчанию.

Than you shouldn't use NAT44 (and stick to IPv6 only), as that only provides a false sense of security instead of secure and easy by default. Тогда вам не следует использовать NAT44 (и придерживаться только IPv6), так как это дает только ложное ощущение безопасности вместо того, чтобы быть безопасным и простым по умолчанию.
By now there are countless write ups of how to bypass NATs from the outside in to reach unintended destinations... К настоящему времени существует бесчисленное множество статей о том, как обойти NAT извне, чтобы получить доступ к непреднамеренным адресатам...
NAT is not, was not and most likely will not be a security boundary. NAT не является, не был и скорее всего не будет границей безопасности. In fact it was not even designed to be one. На самом деле он даже не был разработан, чтобы быть одним из них. All it does it is making your firewall ruleset more complex to read and handle as well as making your log files opace to where a connection actually comes from/goes to... Все, что он делает, это делает ваш набор правил брандмауэра более сложным для чтения и обработки, а также делает ваши файлы журналов непрозрачными для того, откуда на самом деле идет соединение...

Any update on the ability to expose a port range? Любые новости о возможности выставлять диапазон портов? I skimmed through the comments but couldn't find an answer. Я просмотрел комментарии, но не нашел ответа.

Thanks! Спасибо!

@dkatipamula you can't do it at the moment. @dkatipamula , сейчас ты не можешь этого сделать. You could do it programmatically via the API, by patching the service object, but not with the manifest itself. Можно было сделать это программно через API, пропатчив сервисный объект, но не с самим манифестом. I hope this gets implemented at one point. Я надеюсь, что это будет реализовано в какой-то момент.

Same issue here, this feature was requested back in 2016 but it seems that no effort has been dedicated to solve it. Та же проблема здесь, эта функция была запрошена еще в 2016 году, но, похоже, не было предпринято никаких усилий для ее решения. Adding the range manually is a hassle and error prone. Добавление диапазона вручную является хлопотным и подвержено ошибкам.

Позор, потому что работа над диапазонами портов в сетевых политиках продолжается: https://github.com/kubernetes/enhancements/pull/2090 .

Hello, Привет,

As the original author of the mentioned Kep, I'm going to take a look into this issue, but some points to consider: Как первоначальный автор упомянутого Кепа, я собираюсь изучить этот вопрос, но некоторые моменты, которые следует учитывать:

• Because of the nature of Services, I think this would be pretty hard, as you can have a Service with ClusterIP pointing to a different target port, so how would be the following use case covered in portRange: Я думаю, что из-за природы Сервисов это будет довольно сложно, поскольку у вас может быть Сервис с ClusterIP, указывающим на другой целевой порт, поэтому как будет описан следующий вариант использования в portRange:

 ports:
  - port: 443
    protocol: TCP
    targetPort: 8443

Maybe if the idea is only to make a from:to mapping with the same ports, it could be validated in the API with "if an endPort and a targetPort exists, return an error". Возможно, если идея состоит только в том, чтобы сделать сопоставление from:to с одними и теми же портами, это можно было бы проверить в API с помощью «если существует endPort и targetPort, вернуть ошибку».

I see the problem that we want to solve here is: I have a Pod with multiple ports / a range that needs to be exposed in my ClusterIP / LoadBalancer / ExternalIP like an NFS or an FTP Server and want to expose all of them in a single ClusterIP, right? Я вижу проблему, которую мы хотим решить здесь: у меня есть Pod с несколькими портами/диапазоном, который должен быть представлен в моем ClusterIP/LoadBalancer/ExternalIP, таком как NFS или FTP-сервер, и я хочу выставить их все в один ClusterIP, верно?

I don't have some strong feeling of how to achieve this, due to the nature of the components that deal with the ClusterIP (aka kube-proxy, but Calico and Cilium have their own Service impl). У меня нет четкого представления о том, как этого добиться, из-за природы компонентов, которые имеют дело с ClusterIP (он же kube-proxy, но у Calico и Cilium есть собственная реализация службы).

I think one thing that could be done is to ping sig-network in slack or mailing list asking about this issue, and how plausible it is. Я думаю, что одна вещь, которую можно было бы сделать, — это пропинговать sig-сеть в slack или списке рассылки, спросив об этой проблеме и насколько она правдоподобна.

Once it's plausible, a KEP (like the above) should be written as this is going to change a Core API. Как только это станет правдоподобным, следует написать KEP (как указано выше), поскольку это изменит Core API.

@thockin @andrewsykim @danwinship WDYT about this? @thockin @andrewsykim @danwinship WDYT об этом?

There was actually a KEP for this feature before, but it was being specified in a way that wouldn't have worked for most of the users here (https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-435957275). Раньше для этой функции существовал KEP, но он был указан таким образом, что не сработал бы для большинства пользователей здесь (https://github.com/kubernetes/kubernetes/issues/23864#issuecomment-435957275). ). Indeed, one of the +1 comments here even notes "BTW exposing port range is not what most of us want", and another comment points out that for the SIP/RTP case, service port ranges don't actually even help. Действительно, в одном из комментариев +1 здесь даже отмечается, что «кстати, раскрытие диапазона портов — это не то, чего хочет большинство из нас», а в другом комментарии указывается, что в случае SIP/RTP диапазоны служебных портов на самом деле даже не помогают.

If you google "kubernetes sip rtp", this issue is one of the first hits (and the very first "kubernetes-internal" hit), and I think most of the people +1'ing here are doing so because they want to do SIP/RTP to kubernetes pods, and they are assuming that because other people are talking about SIP/RTP here, that this must be the issue that needs to be fixed in order to make SIP/RTP in Kubernetes work better. Если вы погуглите «kubernetes sip rtp», эта проблема — одна из первых (и самая первая «kubernetes-internal»), и я думаю, что большинство людей, которые ставят здесь +1, делают это, потому что хотят SIP/RTP для модулей kubernetes, и они предполагают, что, поскольку другие люди говорят здесь о SIP/RTP, эта проблема должна быть исправлена, чтобы SIP/RTP в Kubernetes работал лучше. But I don't think it actually is the feature that they need. Но я не думаю, что это действительно та функция, которая им нужна.

How would we deal the scale of environment variables in the autoinjected services? Как бы мы справились с масштабом переменных окружения в автоинжектируемых сервисах? Right now, for example... a single service creates all these entries, and the pods get this metadata for free.... (i..e. that's how the magic in-cluster client is configured.. but some folks that don't have Kube-dns, use these env vars as well in apps to find IPs for stuff ) Прямо сейчас, например... один сервис создает все эти записи, а поды получают эти метаданные бесплатно.... (т.е. так настроен волшебный внутрикластерный клиент... но некоторые люди, которые у вас нет Kube-dns, используйте эти env vars также в приложениях, чтобы найти IP-адреса для вещей)

MY_SERVICE_PORT=tcp://10.96.24.249:80
MY_SERVICE_PORT_80_TCP=tcp://10.96.24.249:80
MY_SERVICE_PORT_80_TCP_ADDR=10.96.24.249
MY_SERVICE_PORT_80_TCP_PORT=80
MY_SERVICE_PORT_80_TCP_PROTO=tcp
MY_SERVICE_SERVICE_HOST=10.96.24.249
MY_SERVICE_SERVICE_PORT=80

If you supported a large range of say all ports, would that mean you'd inject like 4096*4 environment variables for every service ? Если бы вы поддерживали большой диапазон, скажем, всех портов, означало бы это, что вы вводили бы 4096 * 4 переменных среды для каждой службы?

maybe if you did this, you could do it saying " if using a port range, there are no guarantees around env var injection " but that of course would make a split-brained UX around service env var injection может быть , если бы вы сделали это, вы могли бы сделать это, говоря: «при использовании диапазона портов нет никаких гарантий в отношении внедрения env var», но это, конечно, сделало бы UX с разделенным мозгом вокруг внедрения env var службы.

The env var problem would be quite trivial to solve. Проблема env var будет довольно тривиальной для решения. As it is the application that would use them and applications needing a single port won't suddenly need a port range, we could just add to that standard to just have two ways. Поскольку это приложение будет использовать их, а приложениям, которым нужен один порт, не понадобится внезапно диапазон портов, мы могли бы просто добавить к этому стандарту, чтобы было только два способа. For single ports defined use the current env variables. Для определенных портов используйте текущие переменные env. But for the here requested feature of port ranges use something like: Но для запрошенной здесь функции диапазонов портов используйте что-то вроде:

MY_SERVICE_PORT_RANGE_START=1024
MY_SERVICE_PORT_RANGE_SIZE=2048

This will indicate that there is also a port range defined with 2048 ports starting at 1024. Это будет означать, что существует также диапазон портов, определенный с 2048 портами, начиная с 1024.

From following this issue now for years, I think the best thing to do is to just not use the export/expose feature anymore and use the network cni directly to just publish everything and restrict access externally to the k8s cluster as we're clearly hitting a design limitation here that is not being addressed in a timely manner. Из-за того, что я следил за этой проблемой в течение многих лет, я думаю, что лучше всего просто больше не использовать функцию экспорта/экспозиции и использовать сетевой cni напрямую, чтобы просто публиковать все и ограничивать доступ извне к кластеру k8s, поскольку мы явно нажимаем здесь конструктивное ограничение, которое своевременно не устраняется.

The only clean solution I think would be to make the cluster IPs (at least partially) routable from external and instead of NAT-ing IPs to the outside world to configure a firewall and/or connection security rules. Единственным правильным решением, которое я думаю, было бы сделать IP-адреса кластера (по крайней мере, частично) маршрутизируемыми из внешних и вместо IP-адресов NAT во внешний мир настроить брандмауэр и / или правила безопасности подключения.
Because the next problem that we'd hit after having the port range feature will inevitably be port exhaustion. Потому что следующей проблемой, с которой мы столкнемся после использования функции диапазона портов, неизбежно будет исчерпание портов. If I want to run two services that need the full dynamic port range eg active ftp + samba ad dc the ports on the nodes own ip will not be enough. Если я хочу запустить две службы, которым нужен полный динамический диапазон портов, например, активный ftp + samba ad dc, портов на собственном IP-адресе узлов будет недостаточно.

Therefore we'd either need: Поэтому нам нужно либо:

• the cluster ip to be accessible from external and connections restricted/allowed by a firewall/connection security rules instead of NAT IP-адрес кластера должен быть доступен извне, а соединения ограничены/разрешены брандмауэром/правилами безопасности соединения вместо NAT
• if cluster ips shouldn't be exposed (because of a false sense of security or whatever) a 2nd ip allocation pool that is similar to cluster ip but with publicly routable ips and proper firewalling but with a different name. если IP-адреса кластера не должны быть раскрыты (из-за ложного чувства безопасности или чего-то еще), второй пул распределения IP-адресов, аналогичный IP-адресам кластера, но с общедоступными маршрутизируемыми IP-адресами и надлежащим брандмауэром, но с другим именем.

For me I just went the use IPv6 and have enough address space route. Для меня я просто перешел на использование IPv6 и у меня достаточно маршрута адресного пространства. So I can make the cluster ips routable from external and do proper firewalling instead of a NAT. Таким образом, я могу сделать кластер ips маршрутизируемым извне и сделать правильный брандмауэр вместо NAT. My cloud provider offers a NAT64 gateway as a service, so I just needed to configure a DNS64 dns server and the egress was basically done. Мой облачный провайдер предлагает шлюз NAT64 в качестве услуги, поэтому мне просто нужно было настроить DNS-сервер DNS64, и выход был в основном готов. The ingress is a different story, as my cloud provider doesn't offer BGP traffic would always pass through one node (aka. I still need to write a manager that flips the route into the cluster when the "ingress"-node goes down...), but besides that it works. Вход — это отдельная история, так как мой облачный провайдер не предлагает, чтобы трафик BGP всегда проходил через один узел (он же. Мне все еще нужно написать диспетчер, который переключает маршрут в кластер, когда «входной» узел выходит из строя. ..), но кроме того, это работает.
Bonus if you now ask yourself how IPv4 clients will connect to these services? Бонус, если вы теперь спросите себя, как клиенты IPv4 будут подключаться к этим службам? The answer is quite simple through a vip that the cloud providers load balancer has allocated. Ответ довольно прост через vip, который выделил балансировщик нагрузки облачных провайдеров.

@danwinship Port ranges is what some of us want, even for doing SIP/WebRTC. @danwinship Диапазоны портов — это то, что нужно некоторым из нас, даже для работы с SIP/WebRTC. Using host networking is an inferior solution compared to port ranges. Использование хост-сети является худшим решением по сравнению с диапазонами портов. Of course, having IPv6 or public cluster IPs could be better but its impossible to have that in most cloud setups, hence, port ranges could be a decent compromise until we get to full IPv6 connectivity. Конечно, наличие IPv6 или общедоступных кластерных IP-адресов может быть лучше, но это невозможно в большинстве облачных настроек, поэтому диапазоны портов могут быть достойным компромиссом, пока мы не доберемся до полного подключения IPv6.

@nustiueudinastea so what is the complete architecture? @nustiueudinastea , так что же такое полная архитектура? Are you using load balancers? Используете ли вы балансировщики нагрузки? External IPs? Внешние IP? Do you have a separate LB/external IP for each pod? У вас есть отдельный LB/внешний IP для каждого модуля? If not, don't you have to worry about port conflicts between the different pods, who have no way to coordinate among each other which ports are in use and which aren't? Если нет, не нужно ли вам беспокоиться о конфликтах портов между различными модулями, у которых нет возможности координировать друг с другом, какие порты используются, а какие нет? Or do you only have a single (or very small number) of pods doing SIP/RTC so that doesn't really matter? Или у вас есть только один (или очень небольшое количество) модулей, использующих SIP/RTC, так что это не имеет большого значения? If you do have a separate LB/external IP for each pod, then would your needs be met just as well by having a "whole IP" service rather than a port range, or are you also using _other_ ports on the same LB/externalIP for unrelated services? Если у вас есть отдельный LB/внешний IP-адрес для каждого модуля, тогда ваши потребности будут удовлетворены с помощью службы «полного IP», а не диапазона портов, или вы также используете _other_ порты на том же LB/внешнем IP-адресе. для несвязанных услуг?

How would we deal the scale of environment variables in the autoinjected services? Как бы мы справились с масштабом переменных окружения в автоинжектируемых сервисах?

Don't. Не. Environment variables for services are bad anyway. Переменные среды для сервисов в любом случае плохи.

@danwinship good questions. @danwinship хорошие вопросы. In my particular case, I have several pods on each node, deployed using daemonsets, which allows me to pre-define the port ranges for each daemonset so that they don't conflict. В моем конкретном случае у меня есть несколько модулей на каждом узле, развернутых с помощью наборов демонов, что позволяет мне предварительно определить диапазоны портов для каждого набора демонов, чтобы они не конфликтовали. At the moment, I set the port ranges programatically via the K8s API so I don't have to embed 10s of thousands of ports in the daemonset definitions. На данный момент я устанавливаю диапазоны портов программно через K8s API, поэтому мне не нужно встраивать десятки тысяч портов в определения daemonset. Clients/applications talk directly to the daemonset servers via the external IP of the node that they are hosted on. Клиенты/приложения взаимодействуют напрямую с серверами набора демонов через внешний IP-адрес узла, на котором они размещены.

Clarification: at the moment I am using hostPorts to provide direct connectivity to the WebRTC servers running in the daemonsets. Уточнение: на данный момент я использую hostPorts для обеспечения прямого подключения к серверам WebRTC, работающим в наборах демонов.

Env vars ... ok ... makes sense if you all say we can break the 1990s docker links env var model to make progress I'm all for it :). Env vars ... хорошо ... имеет смысл, если вы все говорите, что мы можем сломать модель env var ссылок docker 1990-х годов, чтобы добиться прогресса. Я полностью за это :). Probably we should have a KEP for that since some things like client go rely on this ? Возможно, нам следует иметь KEP для этого, поскольку некоторые вещи, такие как клиент, полагаются на него?

@nustiueudinastea so what is the complete architecture? @nustiueudinastea , так что же такое полная архитектура? Are you using load balancers? Используете ли вы балансировщики нагрузки? External IPs? Внешние IP? Do you have a separate LB/external IP for each pod? У вас есть отдельный LB/внешний IP для каждого модуля? If not, don't you have to worry about port conflicts between the different pods, who have no way to coordinate among each other which ports are in use and which aren't? Если нет, не нужно ли вам беспокоиться о конфликтах портов между различными модулями, у которых нет возможности координировать друг с другом, какие порты используются, а какие нет? Or do you only have a single (or very small number) of pods doing SIP/RTC so that doesn't really matter? Или у вас есть только один (или очень небольшое количество) модулей, использующих SIP/RTC, так что это не имеет большого значения? If you do have a separate LB/external IP for each pod, then would your needs be met just as well by having a "whole IP" service rather than a port range, or are you also using _other_ ports on the same LB/externalIP for unrelated services? Если у вас есть отдельный LB/внешний IP-адрес для каждого модуля, тогда ваши потребности будут удовлетворены с помощью службы «полного IP», а не диапазона портов, или вы также используете _other_ порты на том же LB/внешнем IP-адресе. для несвязанных услуг?

Well in the "normal enterprise world" or in a "normal cdn" world one could simply use ECMP with an deterministic algo, like using the client IP. Что ж, в «нормальном корпоративном мире» или в «нормальном мире cdn» можно просто использовать ECMP с детерминированным алгоритмом, например, с использованием IP-адреса клиента. Same client IP goes to the same backend. Тот же IP-адрес клиента переходит к одному и тому же бэкэнду. If the backend is down the connection goes to to another one. Если бэкэнд не работает, соединение переходит к другому. That other one than sends a RST package and the connection gets reestablished by the client... Тот, кто отправляет пакет RST, и соединение восстанавливается клиентом...
Or alternatively the connection state of open and closed ports from the kernel could be synced, I've already seen people doing it for very highly frequented services to prevent RSTs when the lb does a failover (aka. Active-Active configuration). Или, в качестве альтернативы, состояние соединения открытых и закрытых портов из ядра может быть синхронизировано, я уже видел, как люди делают это для очень часто используемых служб, чтобы предотвратить RST, когда lb выполняет отработку отказа (также известная как конфигурация Active-Active).

Anyway, I this is out of scope for k8s and would be something that people would/could do with a daemonset on top of it. В любом случае, я считаю, что это выходит за рамки k8s и было бы чем-то, что люди могли бы/могли бы сделать с набором демонов поверх него.
I think we should go with a KEP that drops port mapping entirely (or at least discourages until we can deprecate it) and provides firewalling of the services instead. Я думаю, что нам следует использовать KEP, который полностью отбрасывает сопоставление портов (или, по крайней мере, не поощряет его до тех пор, пока мы не сможем отказаться от него) и вместо этого обеспечивает брандмауэр для служб. Should also improve performance and reduce cpu load. Также должно повысить производительность и снизить нагрузку на процессор. As well as enable clusters to span multiple clouds without paying for VPN tunnels or doing any crazy overlay networking... А также позволить кластерам охватывать несколько облаков, не платя за VPN-туннели или без каких-либо безумных оверлейных сетей...

Env vars ... ok ... makes sense if you all say we can break the 1990s docker links env var model to make progress I'm all for it :). Env vars ... хорошо ... имеет смысл, если вы все говорите, что мы можем сломать модель env var ссылок docker 1990-х годов, чтобы добиться прогресса. Я полностью за это :). Probably we should have a KEP for that since some things like client go rely on this ? Возможно, нам следует иметь KEP для этого, поскольку некоторые вещи, такие как клиент, полагаются на него?

oh, KUBERNETES_SERVICE_HOST needs to stay. о, KUBERNETES_SERVICE_HOST должен остаться. I just meant env vars for end-user services. Я просто имел в виду env vars для служб конечных пользователей. See also https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0028-20180925-optional-service-environment-variables.md См. также https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0028-20180925-Optional-Service-environment-variables.md .

Guys, I follow this topic since 2016 and I need to remember you one thing. Ребята, я слежу за этой темой с 2016 года и мне нужно запомнить вам одну вещь. The whole point of using K8s is to EASLY automate fleet control plane. Весь смысл использования K8s состоит в том, чтобы ЛЕГКО автоматизировать самолет управления парком. When automation itself became a bigger problem then the process itself you have to stop the madness of these crazy workarounds. Когда сама автоматизация стала более серьезной проблемой, чем сам процесс, вы должны остановить безумие этих безумных обходных путей. K8s was not built as a data plane orchestration solution. K8s не создавался как решение для оркестровки плоскости данных. Actually it's crazy inefficient to run data plane through K8s. На самом деле это безумно неэффективно запускать плоскость данных через K8s.

I have dealt with multiple telco setups in the last 5 years. Я имел дело с несколькими настройками телекоммуникационных компаний за последние 5 лет. Forget about K8S if you need distributed SBCs or distributed media. Забудьте о K8S, если вам нужны распределенные SBC или распределенные носители. Just go with Terraform for orchestration and keep K8S as a proxied fleet control plane for the data plane(media). Просто используйте Terraform для оркестровки и оставьте K8S в качестве прокси-плоскости управления парком для плоскости данных (носителей).

TLDR: Do not use K8s to orchestrate the data plane. TLDR: не используйте K8 для организации уровня данных. Orchestrate it with Terraform. Организуйте это с помощью Terraform.