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] 2016년 4월 5일 화요일 오후 5:55 Prashanth B [email protected]
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 Expos --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] 2016년 4월 5일 화요일 오후 9:01 Aditya Patawari [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. 서비스 및 Pod에 대한 일부 필드 변경 사항일 뿐입니다. 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는 필수이므로 범위를 나타내는 주석이 있어도 API를 변경하지 않고 필수 containerPort를 피하는 방법을 알 수 없습니다. 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. 이것은 약간 엉터리이지만 트릭을 수행해야합니다.

We also need exposing large port range (10k+) for RTP/WebRTC and SIP frameworks. 또한 RTP/WebRTC 및 SIP 프레임워크에 대해 큰 포트 범위(10k+)를 노출해야 합니다. 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. BTW 노출 포트 범위는 우리 대부분이 원하는 것이 아닙니다. 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: 2016년 9월 5일 월요일 오전 4시 21분에 Steve Kite [email protected] 에서 다음과 같이 썼습니다.

We also need exposing large port range (10k+) for RTP/WebRTC and SIP 또한 RTP/WebRTC 및 SIP에 대해 큰 포트 범위(10k+)를 노출해야 합니다.
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 BTW 노출 포트 범위가 아닙니다.
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. 또한 Pod의 일부인 Docker 컨테이너에서 실행되는 미디어 처리 엔진을 활성화하려면 대규모 포트 범위에 대한 지원이 필요합니다. 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. 문제는 16384-32767인 표준 RTP 포트 범위에 있습니다. 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. 게이트웨이, 통화 녹음 서비스, MCU 등을 포함한 모든 형태의 미디어 처리를 포함하는 Voip 서비스를 조정하기 위해 Kubernetes를 사용하려는 모든 사람에게 이것이 중요하다는 데 동의합니다. 저는 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. 우리는 K8로 이동하고 싶습니다. 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 다시: 창
@DirectXMan12 re: userspace proxy @DirectXMan12 re: 사용자 공간 프록시
@smarterclayton re: Openshift @smarterclayton re: Openshift

누군가가 1.6에서 이것을 탐색하는 데 도움이 되었으면 합니다.

cc @knobunc (Re 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? 범위에서 NodePort를 지원할 수 있습니까? 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 노드 포트는 대부분의 플랫폼에서 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 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] 2016년 12월 10일 토요일 오후 1시 42분, Jeremy Ong [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이 SIP 및 RTP와 같은 UDP 기반 프로토콜에 대한 기본 지원을 제공할 때까지 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 모드로 팟(Pod)을 전달해야 합니다. 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:port에서 직접 포드를 검색하고 라우팅할 수 있어야 합니다. 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? 범위에서 NodePort를 지원할 수 있습니까? (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? 노드 포트는 대부분의 플랫폼에서 인그레스에 필요합니다. 이것은 인그레스가 없음을 의미합니까? (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. UDP에 의존하고 세션 선호도를 지원해야 하는 Stateful Voip 서비스에는 완전히 다른 유형의 로드 밸런서가 필요합니다. 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. 그건 그렇고, 저는 k8용 기본 SIP 로드 밸런서에도 매우 관심이 있습니다. 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: 2017년 1월 25일 수요일 오후 1시 35분에 Brian Pulito [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이 SIP 및 RTP와 같은 UDP 기반 프로토콜에 대한 기본 지원을 제공할 때까지 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 대부분의 경우 미디어 서비스는 현재 포드가 다음으로 전달되어야 합니다.
"hostNetwork": true mode because the user proxies do not support session affinity. "hostNetwork": 사용자 프록시가 세션 선호도를 지원하지 않기 때문에 true 모드입니다. iptables rules also do not help with these iptables 규칙도 이러한 문제에 도움이 되지 않습니다.

Our proxies support basic IP affinity, or do you mean something else? 우리 프록시는 기본 IP 선호도를 지원합니까, 아니면 다른 것을 의미합니까?

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 포드 포트는 대부분
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? 범위에서 NodePort를 지원할 수 있습니까? (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? 노드 포트는 대부분의 플랫폼에서 인그레스에 필요합니다. 이것은 인그레스가 없음을 의미합니까? (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. UDP에 의존하고 세션 선호도를 지원해야 하는 Stateful Voip 서비스에는 완전히 다른 유형의 로드 밸런서가 필요합니다. 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, 게임은 모두 대기 시간과 프로토콜상의 이유로 호스트 네트워킹이 필요하므로 서비스가 "흥미로운" 반면 서비스를 사용할 수 있는 대부분의 사람들은 개별 포트를 노출하는 더 많은 회선이 있어야 하는 불편함을 안고 살 수 있다고 생각합니다. 포드/서비스 파일. 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] 2017년 1월 25일 수요일 오후 11시 40분, Jeremy Ong [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). 포트 + 임시 포트 범위).

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. 포드/서비스 파일의 개별 포트를 노출하는 더 많은 라인이 있습니다. 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
. .

k8에 의해 자동으로 작성된 방화벽 규칙은 해당 포트가 올바르지만 공개적으로 액세스할 수 없도록 방지합니까?

@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 UDP 포트(5060 또는 5061)에서 수신 대기하도록 하는 여러 포드 앞에 SIP 서비스를 프로비저닝할 수 있기를 원하지만 기본 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. Voip 애플리케이션에서 미디어를 스트리밍하는 데 사용되는 RTP는 큰 포트 범위로 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. hostHework 없이 이 작업을 수행하려면 매우 복잡해질 수 있습니다. 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? 즉, 이것이 실제로 k8의 SIP에 대한 기본 지원에 대한 논의로 전환되어야 합니까?

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 이 언급했듯이 "hostNetwork": true 모드를 사용하는 경우 yml 파일에 포트 범위를 지정할 필요가 없습니다. 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] 2017년 1월 27일 금요일 오전 11시 20분, Brian Pulito [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": "hostNetwork"를 사용하는 경우 yml 파일에 포트 범위를 지정하려면:
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. PetSet을 사용하여 Kubernetes 내에서 GlusterFS를 실행하려고 합니다. 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 Kubernetes 환경에서 SIP/RTP에 대한 로드 밸런싱을 어떻게 구현합니까? I understand that K8S services / cloud load balancers would need to operate at L7 to implement session affinity for SIP/RTP. SIP/RTP에 대한 세션 선호도를 구현하려면 K8S 서비스/클라우드 로드 밸런서가 L7에서 작동해야 한다는 것을 이해합니다. 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 서비스를 사용하지 않는 경우 - SIP/RTP 워크로드를 위해 K8S에서 서비스 검색 및 로드 밸런싱을 어떻게 구현합니까?

@thockin Is it possible to write an L7 ingress controller for SIP/RTP traffic that bypasses the concept of services in K8S? @thockin K8S에서 서비스 개념을 우회하는 SIP/RTP 트래픽용 L7 수신 컨트롤러를 작성할 수 있습니까? 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. 나도 Kubernetes에서 SIP/RTP 트래픽에 대한 기본 로드 밸런싱을 지원하기 위해 새로운 문제가 생성되어야 한다는 데 동의합니다.

PS: We have a requirement for running a WebRTC gateway on Kubernetes. 추신: Kubernetes에서 WebRTC 게이트웨이를 실행하기 위한 요구 사항이 있습니다.

@khatribharat i've experimented in the past with using Kamailio as a SIP/RTP proxy in a daemonset with hostNetwork. @khatribharat 저는 과거에 hostNetwork가 있는 데몬셋에서 Kamailio를 SIP/RTP 프록시로 사용하여 실험했습니다. This would be deployed to nodes with public addresses and do direct to pod communication on the inside as you say. 이것은 공개 주소가 있는 노드에 배포되고 내부에서 포드 통신에 직접 수행합니다. 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

k8s에서 localtunnel 서버 를 설정하고 싶었습니다. 이 기능을 언제 사용할 수 있는지 정보가 있습니까?

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: 2017년 6월 6일 화요일 오전 9시 33분에 Alex [email protected] 이 다음과 같이 썼습니다.

Wanted to setup localtunnel server localtunnel 서버를 설정하고 싶었습니다.
https://github.com/localtunnel/server#overview on k8s, is there any https://github.com/localtunnel/server#overview on 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와 같은 텔레메트리와 couchdb, coucbase 등과 같은 다른 많은 erlang 기반 분산 시스템에도 필요합니다.

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를 할당하고 kube-dns에서 SRV 항목을 제어하고 k8s API에 대해 온전성 검사를 수행할 수 있어야 합니다.

2. We need a new service type like "ExternalName" which instead mapping CNAME will map SRV records. CNAME을 매핑하는 대신 SRV 레코드를 매핑하는 "ExternalName"과 같은 새로운 서비스 유형이 필요합니다. 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. 그러나 헤드리스 서비스처럼 작동해야 하며 k8s API에서 생성된 엔드포인트 레코드는 프록시 없이 파드를 직접 가리켜야 합니다. 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. 이 구현은 mqtt, SIP, XMPP, 클러스터/데이터 센터 간 복제 또는 샤드 밸런싱과 같은 L4의 모든 종류의 상태 저장 서비스를 다룹니다. 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. 나는 기여를 시작할 것이지만 K8s 내부 세부 사항에 대한 경험이 많지 않기 때문에 이것이 올바른 접근 방식인지 100% 확신할 수 없습니다. 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 IPVS 모드에서 범위를 지원하는 경우/방법에 대한 생각이 있습니까?

@thockin @thockin

As far as I know, fwmark with ipvsadm can do port ranges. 내가 아는 한, ipvsadm을 사용하는 fwmark는 포트 범위를 수행할 수 있습니다. 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. 추신. 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. 추신.

From my test result, FWMARK with IPVS does not support port remapping, even in masq mode. 내 테스트 결과에 따르면 IPVS가 있는 FWMARK는 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 로 보내지도록 규칙을 추가합니다. 그것은 수락되었고 해시 테이블에 소스 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. BTW, 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. @Excludos 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-lifecycle 부실

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-lifecycle 부실

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당 하나의 서비스로 효과적으로 제한됩니다. 현재 자체 네트워크 네임스페이스에서 바인딩 해제된 포트에 대해 두 개의 포드가 동일한 외부/노드/로드밸런서/인그레스 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 지원을 추가하는 것도 간단합니다. 동일한 ExternalIP에 대한 두 개의 전체 IP 서비스). 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.) (그렇다면 실제로 전체 IP를 예약할 수 없기 때문에 NodePort는 여전히 존재하지 않을 것입니다.)

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 서비스는 예를 들어 1000개가 아닌 10개의 포트를 바인딩하는 서비스를 원하는 사람들에게 별로 도움이 되지 않을 수 있습니다. 그러나 그들은 여전히 ​​지금처럼 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-lifecycle 썩음

여기에 +1, 저는 많은 서비스를 라우팅해야 하는 클러스터 간 통신 PODS를 작업 중입니다. 한 번에 많은 포트를 노출할 수 있어 포드를 다시 킥하여 새 포드를 정의합니다.

딜루지 트래픽 범위에 대해 +1

/lifecycle frozen /수명 주기 동결
/remove-lifecycle stale /remove-lifecycle 부실

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 . 그런 다음 kubernetes Java 클라이언트를 사용하여 nodeport로 내 애플리케이션에서 서비스를 생성하십시오 . 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. 또한 kubernetes에서 sfu/mcu를 배포할 때 얼음 오류가 발생합니다. Can you help me with this? 이것 좀 도와주시겠어요?

+1 +1

Needed to run the RTP Endpoint services in kubernetes. Kubernetes에서 RTP Endpoint 서비스를 실행하는 데 필요합니다. 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 ; seq 60000 60100 의 i에 대해 ; do echo -e " - protocol: TCP\n port: $i\n targetPort: $i\n name: bastion-$i" ; do echo -e " - 프로토콜: TCP\n 포트: $i\n targetPort: $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 요새-모시 로드 밸런서 10.111.49.103 192.168.0.243 60000:30077/UDP,60001:30289/UDP,60002:30482/UDP,60003:32327/0UDP,60002:30482/UDP,60003:32327/0 UDP,60007:30375/UDP,60008:31823/UDP,60009:31801/UDP,60010:32442/UDP,60011:30647/UDP,60012:31187/UDP,60013 60015:30504/UDP,60016:32186/UDP,60017:31339/UDP,60018:31230/UDP,60019:31210/60,UDP,60020:31659/UDP,600821:0 32163/UDP,60024:32553/UDP,60025:31685/UDP,60026:32478/UDP,60027:30841/UDP,60028:31189/UDP,1,60029:32533 UDP,60032:32311/UDP,60033:30253/UDP,60034:30218/UDP,60035:31354/UDP,60036:31675/UDP,60037:31624/UDP,600038 60040:31256/UDP,60041:31430/UDP,60042:32570/UDP,60043:30888/UDP,60044:32179/60UDP,60045:32294/UDP,603046:0 31443/UDP,60049:31872/UDP,60050:30373/UDP,60051:30317/UDP,60052:31521/UDP,60053:32437/UDP,60054:31190/60053:32437/UDP,60054:31190 UDP,60057:31784/UDP,60058:31021/UDP,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/UDP,60060:32543/UDP,60061:30747/UDP,60062:30712/UDP,60063:32287/UDP,60,60064:31478/UDP,600615:32 32472/UDP,60068:32147/UDP,60069:31375/UDP,60070:30554/UDP,60071:32521/UDP,60072:32394/UDP,10073:31270 UDP,60076:31052/UDP,60077:32025/UDP,60078:32757/UDP,60079:31047/UDP,60080:31633/UDP,60081:30081/UDP,60082 60084:32193/UDP,60085:32721/UDP,60086:32071/UDP,60087:31532/UDP,60088:30451/01/UDP,60089:30461/UDP,605090:30461/UDP,605090 31086/UDP,60093:31796/UDP,60094:30899/UDP,60095:31887/UDP,60096:32372/UDP,60097:32613/UDP,01613/UDP,60098:31490/01490 UDP 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가 GKE와 같은 iptables 프록시 모드를 사용하는 경우). 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의 경우) 또는 1000개의 열린 포트가 있는 10개의 서비스가 k8s 노드에서 iptables의 성능을 저하시킵니다.

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_ N, 추가 인터페이스가 있어도 _서비스에서_ 범위를 내보낼 수 없습니다.
. . 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를 사용하여 포드에 추가 NIC를 제공하시겠습니까?

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 덕분에 promisc 모드 활성화가 필요한 인터페이스에 고정했습니다. 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. 포트 변환 없이 cluster-ip를 pod-ip로 변환하는 정적 nat 규칙을 추가하는 중이므로 전체 포트 범위가 cluster-ip와 pod-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. 포트 변환 없이 cluster-ip를 pod-ip로 변환하는 정적 nat 규칙을 추가하는 중이므로 전체 포트 범위가 cluster-ip와 pod-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에서 지원되지 않음

이 기능은 또한 필요한 포트가 모두 동적/rpc 포트인 49152-65535를 포함하므로 kubernetes 내에서 samba DC를 실행하는 데 유용합니다.

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 이 iptables 제한을 우회하여 kube-proxy 규모 문제를 해결할 수 있는지 궁금합니다.

What is the plan on this feature? 이 기능에 대한 계획은 무엇입니까? Any work around? 해결 방법이 있나요? Needed for 필요한

• Media Server 미디어 서버
• RTC Server RTC 서버
• SIP/RTP Server SIP/RTP 서버
• NFS Server NFS 서버
• Samba DC 삼바 DC
• Telnet Server 텔넷 서버

또한 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 텔넷 서버

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... 그리고 해당 설정이 있으면 앞에 공용 IPv4용 NAT46을 쉽게 추가할 수 있습니다.

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 텔넷 서버

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. 텔넷 서버란 콘솔 서버를 의미하며, 다양한 포트에서 수신 대기하고 각 포트를 물리적 또는 가상 장치의 직렬 콘솔에 연결하는 서버입니다. Mostly using the telnet protocol. 주로 텔넷 프로토콜을 사용합니다.

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: 언급된 Kep의 원저자로서 저는 이 문제를 살펴볼 것이지만 몇 가지 사항을 고려해야 합니다.

• 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? 여기서 해결하고자 하는 문제는 다음과 같습니다. NFS 또는 FTP 서버와 같은 ClusterIP/LoadBalancer/ExternalIP에 노출되어야 하는 여러 포트/범위가 있는 Pod가 있고 모든 포트를 하나의 단일 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에는 고유한 Service impl가 있음)를 처리하는 구성 요소의 특성으로 인해 이를 달성하는 방법에 대한 강한 느낌이 없습니다.

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. 내가 할 수 있는 한 가지는 이 문제와 그것이 얼마나 그럴듯한지 묻는 slack 또는 메일링 리스트의 sig-network에 ping을 보내는 것이라고 생각합니다.

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 댓글 중 하나는 "BTW 노출 포트 범위는 우리 대부분이 원하는 것이 아닙니다"라고 언급하고 다른 댓글 은 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"를 Google에서 검색하면 이 문제가 첫 번째 히트(그리고 최초의 "kubernetes-internal" 히트) 중 하나이며 여기에서 +1하는 대부분의 사람들이 하기를 원하기 때문에 그렇게 하고 있다고 생각합니다. SIP/RTP to kubernetes pod, 그리고 그들은 여기에서 다른 사람들이 SIP/RTP에 대해 이야기하고 있기 때문에 이것이 Kubernetes의 SIP/RTP가 더 잘 작동하도록 하기 위해 수정되어야 하는 문제여야 한다고 가정하고 있습니다. 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가 없으면 앱에서도 이러한 환경 변수를 사용하여 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 주입에 대한 보장이 없습니다"라고 말할 수 있지만 당연히 서비스 env var 주입을 중심으로 분할된 UX를 만들 것입니다.

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. 정의된 단일 포트의 경우 현재 환경 변수를 사용합니다. 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. 이는 1024에서 시작하는 2048 포트로 정의된 포트 범위도 있음을 나타냅니다.

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. 내가 생각하는 유일한 깨끗한 솔루션은 방화벽 및/또는 연결 보안 규칙을 구성하기 위해 NAT-ing IP 대신 외부에서 클러스터 IP를 (적어도 부분적으로) 라우팅 가능하게 만드는 것입니다.
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. 따라서 클러스터 IP를 외부에서 라우팅 가능하게 만들고 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 게이트웨이를 서비스로 제공하므로 DNS64 dns 서버를 구성하기만 하면 기본적으로 이그레스가 완료됩니다. 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" 서비스를 사용하여 요구 사항을 충족하거나 동일한 LB/externalIP에서 _other_ 포트도 사용하고 있습니까? 관련 없는 서비스를 위해?

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를 통해 프로그래밍 방식으로 포트 범위를 설정하므로 데몬셋 정의에 수만 개의 포트를 포함할 필요가 없습니다. Clients/applications talk directly to the daemonset servers via the external IP of the node that they are hosted on. 클라이언트/응용 프로그램은 호스트되는 노드의 외부 IP를 통해 daemonset 서버와 직접 통신합니다.

Clarification: at the moment I am using hostPorts to provide direct connectivity to the WebRTC servers running in the daemonsets. 설명: 현재 데몬 세트에서 실행되는 WebRTC 서버에 직접 연결을 제공하기 위해 hostPorts를 사용하고 있습니다.

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 ... ok ... 여러분 모두가 1990년대 docker 링크 env var 모델을 깨고 발전을 이룰 수 있다고 말한다면 의미가 있습니다. 저는 모두 찬성합니다 :). 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" 서비스를 사용하여 요구 사항을 충족하거나 동일한 LB/externalIP에서 _other_ 포트도 사용하고 있습니까? 관련 없는 서비스를 위해?

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" 세계에서는 클라이언트 IP를 사용하는 것과 같이 결정론적 알고리즘과 함께 ECMP를 간단히 사용할 수 있습니다. 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). 또는 커널에서 열린 포트와 닫힌 포트의 연결 상태를 동기화할 수 있습니다. lb가 장애 조치(Active-Active 구성)를 수행할 때 RST를 방지하기 위해 매우 자주 사용하는 서비스에 대해 이를 수행하는 사람들을 이미 보았습니다.

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. 또한 성능을 개선하고 CPU 로드를 줄여야 합니다. 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 ... ok ... 여러분 모두가 1990년대 docker 링크 env var 모델을 깨고 발전을 이룰 수 있다고 말한다면 의미가 있습니다. 저는 모두 찬성합니다 :). 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. 나는 단지 최종 사용자 서비스를 위한 환경 변수를 의미했습니다. 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. K8을 사용하는 요점은 함대 제어 평면을 쉽게 자동화하는 것입니다. 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. 실제로 K8을 통해 데이터 플레인을 실행하는 것은 미친 듯이 비효율적입니다.

I have dealt with multiple telco setups in the last 5 years. 저는 지난 5년 동안 여러 통신 설정을 처리했습니다. Forget about K8S if you need distributed SBCs or distributed media. 분산 SBC 또는 분산 미디어가 필요한 경우 K8S는 잊어버리십시오. 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으로 오케스트레이션하십시오.