멋있는! 우리는 이것을 확실히 병합해야 한다고 생각합니다. 별도의 메모에서, 프록시가 과부하 상태에서 코어의 ~30%를 먹는 것을 보았습니다. iptables가 그보다 더 나은 성능을 제공할 것이라고 믿어야 합니다.

우리는 이것을 우선시해야 합니다 - 그것은 거의 kube-proxy의 전체 재작성이며
그 모든 시험. 또한 이전 버전과의 호환성 문제가 있습니다.
이전 커널 또는 이전 iptables 바이너리).

2015년 1월 26일 월요일 오전 11:06, Brendan Burns [email protected]
썼다:

멋있는! 나는 우리가 이것을 확실히 병합해야 한다고 생각합니다. 별도의 메모에서,
프록시가 과부하 상태에서 코어의 ~30%를 먹는 것을 보았습니다.
iptables가 그보다 더 나은 성능을 제공할 것이라고 믿습니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501
.

병렬 옵션으로 구현하고 천천히 마이그레이션하는 것이 합리적일까요?

2015년 1월 26일 월요일 오후 12시 1분, Tim Hockin [email protected]
썼다:

우리는 이것을 우선시해야 합니다 - 그것은 거의 kube-proxy의 전체 재작성이며
그 모든 시험. 또한 이전 버전과의 호환성 문제가 있습니다.
이전 커널 또는 이전 iptables 바이너리).

2015년 1월 26일 월요일 오전 11:06, Brendan Burns [email protected]
썼다:

멋있는! 나는 우리가 이것을 병합해야 한다고 생각합니다. 별도의
노트,
프록시가 과부하 상태에서 코어의 ~30%를 먹는 것을 보았습니다.
iptables가 그보다 더 나은 성능을 제공할 것이라고 믿습니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71527216
.

이 코드를 잘 모르는 다른 사람이 배우도록 유도하려고 합니다.
그리고 그것을 취하십시오. 나는 정말로 그것을 해결하고 싶지만,
다른 사람이 이 공간을 배웠습니다(당신이 아닙니다! :)

즉, 당신은 또한 방대한 P1 목록에 대한 (좋은) 이메일을 보냈습니다.
이것이 아직 그 목록에 있다고 생각하지 마십시오.

2015년 1월 26일 월요일 오후 1:06, Brendan Burns [email protected]
썼다:

병렬 옵션으로 구현하고 천천히 마이그레이션하면
감각?

2015년 1월 26일 월요일 오후 12시 1분, Tim Hockin [email protected]
썼다:

우리는 이것을 우선시해야 합니다 - 그것은 거의 kube-proxy의 전체 재작성입니다
그리고
그 모든 시험. 또한 이전 버전과의 호환성 문제가 있습니다(작동하지 않음
~에
이전 커널 또는 이전 iptables 바이너리).

2015년 1월 26일 월요일 오전 11:06, Brendan Burns <
알림@github.com>
썼다:

멋있는! 나는 우리가 이것을 병합해야 한다고 생각합니다. 별도의
노트,
프록시가 과부하 상태에서 코어의 ~30%를 먹는 것을 보았습니다.
iptables가 그보다 더 나은 성능을 제공할 것이라고 믿습니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71517501

.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment-71527216>

.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -71538256
.

이게 P2야? 지금은 P3로 만들 가치가 있습니까?

작동하게 하고 싶지만 아직 강등될 수 있습니다.

2015년 2월 11일 수요일 오후 2:49 Satnam Singh [email protected]
썼다:

이게 P2야? 지금은 P3로 만들 가치가 있습니까?

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -73982161
.

"희망"은 우리가 할 수만 있다면 얻을 수 있는 P3와 동일하지 않습니까?

@thockin 과의 토론에서 : 이것은 1.0에서 필요하지 않은 서비스 포트 범위를 지원하기 위한 요구 사항이지만 궁극적으로 지원하고 싶습니다.

@thockin "이것은 이전 iptables 및 커널과 호환되지 않는다는 단점이 있습니다." 커널은 얼마나 '새롭다'고 해야 할까요?

너무 새로운 것은 아니지만 2012년부터 iptables를 정말로 원하는 일부 사용자가 있습니다.
일하다.

2015년 2월 23일 월요일 오후 2시 44분, Sidharta Seethana < [email protected]

썼다:

@thockin https://github.com/thockin "이것은
이전 iptables 및 커널과 호환됩니다." 커널이 얼마나 '새로운'
해야?

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75654187
.

@thockin 감사합니다. 예를 들어 우리는 RHEL/CentOS 6을 사용/테스트 중입니다. 따라서 최근 3.x 커널에 대한 강한 종속성이 없다면 좋을 것입니다.

@pweil- 우리는 일전에 이것에 대해 논의하고 있었습니다.
2015년 2월 23일 월요일 오후 11:40 Sidharta Seethana [email protected]
썼다:

@thockin https://github.com/thockin 감사합니다. 우리는 사용/테스트 중입니다
예를 들어 RHEL/CentOS 6 - 하드가 없다면 좋을 것입니다.
최근 3.x 커널에 대한 종속성.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75698480
.

글쎄요, Docker를 실행하려면 Docker가 필요하며 어느 시점에서 이를 차단해야 합니다.
back-rev iptables 지원은 (결국)
이 변화는 어떤 사람들에게는 고통스러울 것입니다.

2015년 2월 23일 월요일 오후 8시 40분, Sidharta Seethana < [email protected]

썼다:

@thockin https://github.com/thockin 감사합니다. 우리는 사용/테스트 중입니다
예를 들어 RHEL/CentOS 6 - 하드가 없다면 좋을 것입니다.
최근 3.x 커널에 대한 종속성.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -75698480
.

@thockin 의 도움으로 우리는 udp로 같은 것을 시도했습니다.

3개의 sky-dns 복제 컨트롤러가 있는 GCE Kubernetes 클러스터를 만들었습니다.
kubernetes-master에서 iptables에 다음을 설정합니다.
dns 서비스 IP는 10.0.0.10이고 dns를 실행하는 포드 엔드포인트는 10.244.0.5:53, 10.244.3.6:53, 10.244.0.6:53입니다.

iptables -t nat -N TESTSVC
iptables -t nat -F TESTSVC
iptables -t nat -N TESTSVC_A
iptables -t nat -F TESTSVC_A
iptables -t nat -N TESTSVC_B
iptables -t nat -F TESTSVC_B
iptables -t nat -N TESTSVC_C
iptables -t nat -F TESTSVC_C
iptables -t nat -N KUBE-PORTALS-HOST
iptables -t nat -F KUBE-PORTALS-HOST

iptables -t nat -A TESTSVC -m 최근 --name hostA --rcheck --seconds 1 --reap -j TESTSVC_A
iptables -t nat -A TESTSVC -m 최근 --name hostB --rcheck --seconds 1 --reap -j TESTSVC_B
iptables -t nat -A TESTSVC -m 최근 --name hostC --rcheck --seconds 1 --reap -j TESTSVC_C

iptables -t nat -A TESTSVC -m 통계 --모드 랜덤 --확률 0.333 -j TESTSVC_A
iptables -t nat -A TESTSVC -m 통계 --모드 랜덤 --확률 0.5 -j TESTSVC_B
iptables -t nat -A TESTSVC -m 통계 --모드 랜덤 --확률 1.000 -j TESTSVC_C

iptables -t nat -A TESTSVC_A -m 최근 --name hostA --set -j DNAT -p udp --to-destination 10.244.0.5:53
iptables -t nat -A TESTSVC_B -m 최근 --name hostB --set -j DNAT -p udp --to-destination 10.244.3.6:53
iptables -t nat -A TESTSVC_C -m 최근 --name hostC --set -j DNAT -p udp --to-destination 10.244.0.6:53
iptables -t nat -A KUBE-PORTALS-HOST -d 10.0.0.10/32 -p udp -m udp --dport 53 -j TESTSVC
iptables -t nat -A 출력 -j KUBE-PORTALS-HOST

kubernetes-master>nslookup kubernetes.default.kuberenetes.local 10.0.0.10

우리는 응답을 받습니다!

좋은 물건! 참고로 (우리의 대면 대화에서 확인) 일반적으로 여러 개의 동시 iptables 명령을 실행하는 것은 안전하지 않습니다(다른 체인은 괜찮은 것처럼 들립니다). iptables는 libiptc의 래퍼이며 iptc_commit에 대한 설명을 참조하십시오. http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

이것은 분명히 2013년에 수정되었지만 --wait(?)를 통과한 경우에만 가능합니다. http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

이것의 근본 원인은 iptables가 iptables-save / iptables-restore(적어도 체인당)를 효과적으로 호출하기 때문입니다. 따라서 추가 및 삭제를 통해 작업을 수행하는 대신 iptables-save 및 iptables-restore를 호출하는 많은 코드를 보았습니다. 도움이된다면 파헤칠 수있는 코드가있을 수도 있습니다.

CAS 또는 LL/SC 종류의 작업을 수행할 방법이 없다는 것이 내 마음을 혼란스럽게 합니다.

--wait에 대한 지원을 추가해야 하지만 GCE가
debian-backports에는 없습니다.

적어도 우리를 방지하기 위해 코드 내부에서 자체 잠금을 수행해야 할 수도 있습니다.
우리 자신을 밟는 것에서.

2015년 2월 26일 목요일 오후 1시 56분, Justin Santa Barbara <
[email protected]>은 다음과 같이 썼습니다.

좋은 물건! 참고로 (우리의 대면 대화에서 확인),
일반적으로 여러 동시 iptables 명령을 실행하는 것은 안전하지 않습니다.
(다른 체인은 괜찮은 것처럼 들립니다.) iptables는 래퍼입니다.
libiptc 및 iptc_commit에 대한 주석을 참조하십시오.
http://www.tldp.org/HOWTO/Querying-libiptc-HOWTO/mfunction.html

이것은 분명히 2013년에 수정되었지만 --wait(?)를 통과한 경우에만 가능합니다.
http://git.netfilter.org/iptables/commit/?id=93587a04d0f2511e108bbc4d87a8b9d28a5c5dd8

이것의 근본 원인은 iptables가 iptables-save /
iptables-restore(적어도 체인당); 나는 많은 코드를 보았다.
따라서 작업을 수행하는 대신 iptables-save 및 iptables-restore를 호출합니다.
추가 및 삭제를 통해 내가 파헤칠 수 있는 코드가 있을 수도 있습니다.
도움이된다면 위로.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -76282629
.

많은 규칙을 생성하는 도중에 실패하면 어떻게 됩니까?

공정한 질문 - 우리는 아마도 그것이 무엇을 의미하는지 정말 열심히 생각해야 할 것입니다.
이 중간에 오류가 발생

2015년 2월 26일 목요일 오후 8시 47분, Brian Grant 알림 @github.com
썼다:

무리를 만드는 과정에서 실패가 발생하면 어떻게 되나요?
규칙?

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -76331174
.

@thockin 오늘 irc에서:

net.ipv4.conf.all.route_localnet 는 127.0.0.1이 DNAT 규칙의 대상이 되도록 허용합니다. 문서에서 :

route_localnet - 부울

루프백 주소를 화성 발신지 또는 목적지로 간주하지 마십시오.
라우팅하는 동안. 이를 통해 로컬 라우팅 목적으로 127/8을 사용할 수 있습니다.
기본값은 거짓

이것을 kubelet에 통합할 것인가, 아니면 별도의 데몬에 보관할 것인가? Kubelet은 환경 변수를 채우기 위해 이미 서비스를 감시합니다.

별도의 바이너리로 유지하고 싶습니다. 당신은 이유가 있습니다
k8s 외부의 다른 머신(예: 애완동물 VM)에서 이것을 실행하기를 원할 수 있습니다.
k8 서비스에 액세스하기 위해 클러스터를 구성합니다.

--브렌단

2015년 3월 13일 금요일 오전 11:37, Brian Grant 알림 @github.com
썼다:

이것을 kubelet에 통합할 것인가, 아니면 별도의 데몬에 보관할 것인가?
Kubelet은 환경 변수를 채우기 위해 이미 서비스를 감시합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79230747
.

따라잡기. 실패의 경우에 무슨 일이 일어나는지(많이 있을 것입니다, 저를 믿으십시오), 저는 반엔트로피 접근 방식의 열렬한 팬입니다. 원하는 상태를 어딘가에 저장하고 주기적으로 원하는 상태와 실제 상태를 조정합니다(실제 상태를 변경하여 ). 이 경우 다음과 같이 간단할 수 있습니다.

동안 (사실) {
실제 상태 = iptablesSave()
실제 상태 != desiredState { iptablesRestore(desiredState))인 경우
sleep_a_while()
}

iptables 작성 실패를 처리하는 올바른 방법이라는 데 100% 동의합니다.
규칙.

2015년 3월 13일 금요일 오후 1시 16분, Quinton Hoole [email protected]
썼다:

따라잡기. 실패의 경우에 발생하는 일에 대해(그 중
많이 있을 것입니다. 저를 믿으세요. 저는 반엔트로피 접근 방식의 열렬한 팬입니다.

• 원하는 상태를 어딘가에 저장하고 주기적으로 원하는 상태와
  실제 상태(실제 상태를 변경하여). 이 경우 다음과 같이 간단할 수 있습니다.

동안 (사실) {
실제 상태 = iptablesSave()
실제 상태 != desiredState { iptablesRestore(desiredState))인 경우
sleep_a_while()
}

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79336296
.

지금 무슨 일이 일어나고 있는지 그 정도입니다. 그렇지 않습니까? 각 예상 규칙에 대해
있는지 확인하고 없으면 만듭니다.

2015년 3월 13일 금요일 오후 2:02 Brendan Burns [email protected]
썼다:

iptables 작성 실패를 처리하는 올바른 방법이라는 데 100% 동의합니다.
규칙.

2015년 3월 13일 금요일 오후 1시 16분, Quinton Hoole [email protected]
썼다:

따라잡기. 실패의 경우에 발생하는 일에 대해(그 중
많이 있을 것입니다. 저를 믿으세요), 저는 반엔트로피의 열렬한 팬입니다.
접근하다

• 원하는 상태를 어딘가에 저장하고 주기적으로 원하는 상태와
  실제 상태(실제 상태를 변경하여). 이 경우 아마도 간단하게
  같이:

동안 (사실) {
실제 상태 = iptablesSave()
실제 상태 != desiredState { iptablesRestore(desiredState))인 경우
sleep_a_while()
}

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79336296

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79392626
.

나는 별도의 바이너리에 유틸리티가 있다는 데 동의하지만 아마도 우리는 그것을
kubelet(cAdvisor와 동일한 방식)을 사용하여 독립 실행형으로 만듭니다.
동시에.

2015년 3월 13일 금요일 오후 12:03, Brendan Burns [email protected]
썼다:

별도의 바이너리로 유지하고 싶습니다. 당신은 이유가 있습니다
k8s 외부의 다른 머신(예: 애완동물 VM)에서 이것을 실행하기를 원할 수 있습니다.
k8 서비스에 액세스하기 위해 클러스터를 구성합니다.

--브렌단

2015년 3월 13일 금요일 오전 11:37, Brian Grant 알림 @github.com
썼다:

이것을 kubelet에 통합할 것인가, 아니면 별도의 데몬에 보관할 것인가?
Kubelet은 환경 변수를 채우기 위해 이미 서비스를 감시합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79230747

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -79257059
.

노드 구성 요소가 더 통합되어야 하는지 아니면 모듈화되어야 하는지에 대해 Kubernetes-Mesos 사람들의 의견을 듣고 싶습니다. @jdef?

[[편집]] 예를 들어 kubelet 프로세스와 별도로 프록시 프로세스를 실행하는 것과 같이 k8s 구성 요소의 모듈성을 정말 좋아합니다. 프록시가 어떤 이유로든 실패하면 kubelet을 중단하지 않습니다. Mesos 실행기는 현재 매우 우아한 장애 조치 모델을 갖고 있지 않고 kubernetes-mesos 프레임워크의 실행기는 kubelet/executor 하이브리드이기 때문에 매우 좋습니다. 이 모델을 통해 mesos 마스터에서 프록시 서비스를 실행하고 외부 클라이언트를 위한 라운드 로빈 밸런서로 사용할 수 있습니다(제출한 시작 안내서 참조).

바이너리 포장/배송 측면에서 하이퍼쿠브처럼 기능을 함께 묶는 것이 꽤 유용하다고 생각합니다. 또한 kubernetes-mesos 프레임워크 구성 요소를 최소한의 Docker 컨테이너에 패키징하는 방법에 대해서도 생각했습니다. Iptables에는 외부 라이브러리 종속성이 있으며 이는 상황을 복잡하게 만듭니다. 따라서 좋은 절충안은 k8sm 프레임워크를 단일 hyperkube 이미지가 포함된 Docker로 제공하는 것일 수 있습니다. 그러나 해당 프레임워크가 실행되고 클러스터 전체에 kubelet-executor 배포를 시작할 때 기본적으로 kubelet- 실행기 또는 프록시 - 각 프로세스는 호스트에서 직접 실행할 수 있습니다. 이것은 기본적으로 iptables-{binaries,libraries}-in-Docker 종속성 문제에 대한 최종 실행을 수행합니다.

모듈식 기능의 경우 +1, 단일 바이너리 이미지의 경우 +1

@thockin re: 반엔트로피: 아, 그렇습니다. 나는 proxier.SyncLoop()이 그것을 수행하는 것을 보았습니다. 어떤 경우에 오류를 무시할 수 있고 SyncLoop()의 다음 반복(현재 1분)에서 복구될 것이라는 2월 26일 @bgrant0607 의 질문에 대한 답변이 아닙니까? 아니면 내가 뭔가를 놓치고 있습니까?

@토킨

1. 블랙홀링 네트워크 트래픽에 대해 걱정하고 있습니까? 아니면 서비스/포드 작성자가 처리해야 하는 문제입니까?

사용자 공간 프록시 사용
가상 IP 10.0.0.11에 10.240.1.1, 10.240.1.2, 10.240.1.3과 같은 3개의 끝점이 있다고 가정합니다.
사용자 공간 프록시를 사용하여 한 엔드포인트가 10.240.1.1이 작동하지 않는다고 말하면 프록시는 10.240.1.1로 tcp 연결이 설정되지 않았음을 깨닫고 다른 두 엔드포인트 중 하나로 대체할 수 있습니다.

iptables로
iptables를 사용할 때 kubernetes는 엔드포인트가 작동하는지 여부를 인식하지 못하기 때문에 폴백 메커니즘이 없습니다.
응답하지 않는 끝점을 제거하는 끝점에 대한 일종의 상태 확인이 있는 경우 이를 완화할 수 있습니다.

아니면 응답하지 않는 끝점에 대해 걱정하는 것은 kubernetes 시스템의 책임이 아니라 포드 작성자의 책임입니까?

사용자는 Kubelet에서 수행하는 준비 상태 프로브를 설정할 수 있습니다. 프로브 실패로 인해 엔드포인트 컨트롤러가 엔드포인트 목록에서 엔드포인트를 제거합니다. 그런 다음 서비스 프록시는 대상 집합에서 끝점을 제거해야 합니다.

나는 GSoC에 대해 이것을 조사해 왔으며 궁금한 점이 있습니다.

따라서 이상적으로는 iptables가 사용하기에 충분히 새롭거나 kube-proxy를 계속 사용할 수 있는지 감지할 수 있습니까?

https://github.com/GoogleCloudPlatform/kubernetes/issues/5419에서 이것이 이상적인 접근 방식이 될 것 같습니다. kubelet을 사용하여 ip-tables를 사용할지 또는 kube-proxy를 시작할지 결정합니다.

나는 또한 GSoC에 약간 늦었고(봄 방학이었습니다....), 그래서 내일/오늘 늦게(물론 27일 마감을 제외하고는) 여전히 GSoC 제안을 제출할 수 있는지 궁금합니다. 이것은 아직 열려 있습니다)?

@BenTheElder 예, 금요일까지 제안서를 제출해야 합니다. 이 주제에 잠재적으로 관심이 있는 사람이 한 명 더 있지만 아직 구체적인 제안이 없습니다.

2012년보다 오래된 커널에 대해서는 iptables가 완전히 없는 OS에 대해 걱정하는 것만큼 걱정하지 않습니다.

@bgrant0607 감사합니다!
그러면 이 문제를 선택할 수 있을 것 같습니다. 재미있어 보인다.

준비 상태 프로브는 응용 프로그램 시작에 잘 작동하지만 준비 상태가 응용 프로그램 오류를 완화하는 데 적합하지 않습니다. 포드 실패 시 신호는 application -> kubelet -> apiserver -> endpoints_controller -> apiserver -> kube-proxy에서 전달되어야 합니다. 애플리케이션 실패와 kube-proxy 회전에서 엔드포인트 제거 사이의 대기 시간을 이해하는 데 관심이 있습니다. 이 기간 동안 요청은 응답하지 않는 끝점으로 프록시 처리됩니다.

연결 실패 시 재시도는 일반적인 전략이며 많은 인기 있는 로드 밸런서(예: haproxy, AWS ELB)의 합리적으로 유용한 기능이며 현재 kube-proxy 구현에서 처리됩니다. 이 책임을 외부 LB로 이전해야 합니까? 클러스터 내 트래픽은 어떻습니까?

또 다른 생각으로는 iptables를 사용하면 실제 LB와 비교하여 재구성 시 정상적으로 연결이 드레이닝되는 문제가 발생할 수 있습니다.

Mike는 좋은 점을 지적합니다.

2015년 3월 23일 월요일 오후 11:00 Mike Danese [email protected]
썼다:

또 다른 생각, 우리는 정상적으로 연결 문제가 발생할 가능성이 높습니다
재구성 시 드레인 대 실제 LB.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -85354865
.

나는 kube-proxy 및 proxy pkg의 소스를 읽었습니다. iptables는 현재 개정판에서 이미 사용되고 있지 않습니까?

정확히 무엇을 해야 합니까? 현재 마스터 소스에서 iptables가 이미 프록시에서 꽤 광범위하게 사용되고 있는 것처럼 보입니다.

@mikedanese @thockin Readiness는 계획된 중단에 가장 유용합니다. 계획되지 않은 중단은 항상 몇 가지 관찰 가능한 오류를 발생시킵니다. 폴링 간격은 일반적으로 업데이트 대기 시간에 비해 길어야 하지만 apiserver 및 etcd를 통한 대기 시간이 너무 길거나 경로가 충분히 신뢰할 수 없습니다.

@BenTheElder 기존 규칙은 프록시를 통해 트래픽을 라우팅합니다. 여기서 아이디어는 규칙을 사용하여 프록시를 우회하는 것입니다.

@bgrant0607 감사합니다. 이제 완전히 이해가 됩니다. 소스와 디자인 문서를 다시 한 번 읽고 제안서 초안 작성을 거의 완료했습니다.

GSoC 제안 초안: https://gist.github.com/BenTheElder/ac61900595a7ea9ea9b5

특히 일정 섹션에 대한 피드백을 주셔서 감사합니다. 나는 그것에 대해 확신하지 못한다.
일찍 끝내야 하나요? 다음과 같이 아직 해결되지 않은 다른 GSoC 문제를 해결하고 싶습니다.
https://github.com/GoogleCloudPlatform/kubernetes/issues/1651.

다시 한 번 감사합니다. Kubernetes는 가장 친근한 그룹을 위해 케이크를 가져갑니다.

저는 제 제안이 받아들여져서 매우 기쁩니다. 그리고 여름 동안 이 작업을 할 것입니다. : 스마일 :

나는 매우 흥분된다. 불행히도 지금은 결승전을 앞두고 있지만 이번 주말부터 더 많은 일을 해야 하고 더 많은 작업을 해야 합니다. 아마도 https://github.com/GoogleCloudPlatform/kubernetes/pull/7032 를 얻는 것부터 시작할 것입니다. 완성 된.

@thockin @brendanburns 사용자 공간 프록시와 병렬로 이 작업을 수행하고 싶은지 또는 재구현으로 마이그레이션하는 방법에 대해 누가 판단할 수 있습니까?

우리는 이미 iptables >= 1.4.11(2011년 5월 26일 출시)을 선호하는 것 같습니다.

// Executes the rule check without using the "-C" flag, instead parsing iptables-save.
// Present for compatibility with <1.4.11 versions of iptables.  This is full
// of hack and half-measures.  We should nix this ASAP.
func (runner *runner) checkRuleWithoutCheck(table Table, chain Chain, args ...string) (bool, error) {

출처: https://github.com/GoogleCloudPlatform/kubernetes/blob/aec41967416cf3463b188d72c97e71465e00719d/pkg/util/iptables/iptables.go#L206

실제로 그보다 오래된 호스트를 볼 수 있습니까?

한 가지 접근 방식은 실행 시간에 우리가 실행 중인 iptables의 버전을 감지하고 다음과 같은 버전을 제공할 수 있는 "최선의 일"을 수행하는 것입니다.

if (이전 버전) {
사용자 공간 프록시 모듈 로드
}
또 다른 {
iptables 프록시 모듈 로드
}

위의 if 문(이상적으로는 2개)에 너무 많은 분기를 가지지 않도록 주의하고 코드의 둘 이상의 위치에 이러한 종류의 if 문을 사용하지 않도록 합니다.

위의 접근 방식이 얼마나 실현 가능한지 파악하기 위해 코드를 자세히 살펴보지는 않았습니다.

또한 모든 노드가 동일한 전략(사용자 공간 대 iptables 프록시)을 구현해야 합니까, 아니면 각각이 독립적으로 결정할 수 있습니까?

각 노드가 독립적으로 결정하면 위의 if 문(예: source_mode x dest_mode)에서 분기 수의 제곱에 비례하여 테스트 표면적을 잠재적으로 늘릴 수 있지만 모드 수를 2로 유지할 수 있다면 괜찮다고 생각합니다. .

NS

아, 그리고 오래된 노드가 보이는지에 대한 귀하의 질문에 대한 대답은 불행히도 "예"입니다.

위의 내용은 별도의 문제에서 많이 논의됩니다., 나는 당신을 위해 그것을 파헤치려고 노력할 것입니다.

@quinton-hoole 감사합니다!

또한 한 노드에서는 사용자 공간을 실행하고 다른 노드에서는 iptables를 실행할 수 있다고 확신합니다.

모드 수는 -C가 없는 경우를 제외하고는 2개여야 하지만 -C가 있는 노드는 순수한 iptables 버전을 실행할 수 있어야 합니다(제 생각에는).

아 예, #7528은 커널 버전 등에 대해 설명합니다.

감사 해요.
나는 Kubernetes에 대한 요구 사항을 찾을 때 그것을 보지 못했습니다. 내가 찾은 유일한 요구 사항은 고유한 IP를 가정하는 방법을 논의하는 네트워킹 문서에 있었습니다.

요구 사항이 무엇인지 더 잘 알게 되면 요구 사항에 대한 문서를 작성해야 할 것입니다.

여기에서 해킹을 시작했습니다. https://github.com/BenTheElder/kubernetes/tree/iptables_proxy

특히 인터페이스 뒤에서 사용자 공간 구현을 여기로 옮겼습니다.
https://github.com/BenTheElder/kubernetes/commit/4e5d24bb74aca43b0dd37cf5cfee8a34f8eff2bf

구현 선택이 cmd/kube-proxy 또는 pkg/proxy에 있어야 하는지 지금은 확실하지 않으므로 이를 제거하고 대신 kube-proxy에서 구현을 선택하도록 할 수 있습니다.

편집: 돌이켜보면 kube-proxy에서 구현을 선택하는 것이 더 합리적이라고 생각합니다.

@BenTheElder Calico로 Tim의 규칙을 테스트

더 일반적으로 Kubernetes가 규칙을 삽입할 경우 네트워크 플러그인이 iptables를 안전하게 변경할 수 있는 방법을 정의하기 위해 토론하는 것이 좋습니다. Kubernetes 규칙이 향후 변경되더라도 짓밟고 싶지 않습니다(또는 짓밟히고 싶지 않음).

@대칭 그렇습니다. 플러그인 부분은 아직 잘 모르겠지만 꽤 중요한 것 같습니다.

이번 주말에 조금 바쁠 것 같지만 월요일에는 첫 번째 반복을 구현하는 GSoC를 위해 이 풀타임 작업을 시작해야 합니다.
그렇게 하는 동안 이것을 염두에 두고 싶지만 네트워크 플러그인 API를 살펴본 후에 이것을 처리하는 가장 깨끗한 방법이 무엇인지 잘 모르겠습니다.

이것이 어떻게 생겼는지 / 어떻게 작동해야 하는지에 대한 아이디어가 있습니까?

FWIW, 나는 kube-proxy가 거의 응답하지 않게 되었기 때문에 우리에게 효과가 있는 일을 했습니다. 여기에 있습니다: https://github.com/MikaelCluseau/kubernetes-iptables-proxy/blob/master/iptables-routing.rb.

전에 이 스레드를 본 적이 없지만 무작위 통계 일치 가중치에 실수를 한 것을 제외하고는 가까운 것으로 끝납니다 :-)

나는 또한 우리가 nf_conntrack_max에 빠르게 도달했다는 것을 공유하고 싶습니다. 아마도 증가해야 할 것입니다.

# cat /etc/sysctl.d/nf_conntrack.conf 
net.netfilter.nf_conntrack_max = 1000000
net.nf_conntrack_max           = 1000000

iptables 대한 모든 필요성을 이해하지 못했을 수도 있지만 대신 IPVS 를 사용하지 않는 이유는 무엇입니까?
iptables보다 프록싱에 더 적합한 것 같습니다...
다음은 간단한 go 구현입니다. https://github.com/noxiouz/go-ipvs
그리고 #561을 완성하기 위해 ktcpvs 프로젝트도 있습니다.

IPVS는 iptables와 같은 netfilter에 대한 추상화이기도 합니다. iptables를 사용하여 기존 코드와 일부 기능을 공유할 수 있습니다. iptables는 netfilter를 관리하기 위한 보다 유연하고 일반적인 솔루션인 것 같습니다.

#561 및 ktcpvs의 경우: ktcpvs는 2004년 이후로 발전이 없는 것으로 보이며 사용자가 URL 재작성을 원하는 기능이 없는 것으로 보입니다. 그럼에도 불구하고 #561은 플러그형 밸런서와 함께 사용할 수 있는 일반적인 솔루션을 찾고 있습니다.

참고 사항: go 프로젝트에는 라이선스가 없는 것 같습니다.

iptables는 nftables( nft cli)를 위해 "언젠가" 더 이상 사용되지 않습니다.
또한 iptables CLI를 사용하여 규칙을 만드는 것은 그다지 강력하지 않은 것 같습니다...

빠른 검색으로 다른 MIT 프로젝트를 찾으십시오. https://github.com/vieux/go-libipvs
그러나 모든 복잡성이 이미 커널 코드 내부에서 방탄이 되어 있기 때문에 간단한 작업을 만드는 것은 정말 쉬운 일인 것 같습니다.

iptables가 조만간 주요 배포판에서 제거될 것인지 의심스럽습니다. iptables CLI는 특히 netfilter에 대한 규칙을 만들고 관리하기 위한 것입니다...?

링크된 것과 같은 불완전한 cgo 래퍼는 iptables 및 iptables-restore 포격하는 것보다 훨씬 덜 안전해 보이며 다른 규칙(예: nodeports) 및 iptables-restore 대한 iptables가 이미 필요합니다. 우리는 약간의 원자성으로 대량 업데이트를 수행할 수 있습니다.

IPVS는 또한 "실제" 서버와 별도로 로드 밸런싱 호스트 시스템에서 사용하도록 설계된 것으로 보입니다.
이것은 유일하게 지원되는 사용법을 제안합니다:

2.2. 문제: 외부 클라이언트가 필요합니다(디렉터와 실제 서버는 가상 서비스에 액세스할 수 없음).

LVS를 설정하고 테스트/실행하려면 클라이언트, 디렉터, 실제 서버의 최소 3개의 머신이 필요합니다.

외부에서 LVS는 하나의 기계로 작동합니다. 클라이언트는 LVS(디렉터 또는 실제 서버)의 시스템 중 하나일 수 없습니다. 외부 클라이언트가 필요합니다. LVS에 있는 기계에서 LVS 제어 서비스(예: http, smtp, telnet)에 액세스하려고 시도하는 경우; 디렉터의 액세스가 중단되고 실제 서버의 액세스가 LVS를 우회하여 로컬로 서비스에 연결됩니다.

또한 IPVS/LVS가 하트비트 데몬 및 추가 모니터링 프로세스와 같은 몇 가지 추가 요구 사항을 추가하는 것처럼 보입니다 . 우리는 이미 kubernetes 내에서 끝점 정보 및 포드 상태 모니터링 등을 처리합니다.

iptables 접근 방식의 경우 +1입니다. 우리는 Calico에서 iptables를 광범위하게 사용하며 강력하고 성능과 확장성이 우수합니다(규칙을 잘 설계한다고 가정). @BenTheElder , iptables 작업에 도움이 필요하면 저희에게 알려주십시오. 기꺼이 도와드리겠습니다.

iptables 및 iptables-restore의 경우 +1, 훨씬 덜 무거운 접근 방식입니다.
IPVS/LVS보다 더 적은 시스템 요구 사항을 요구합니다(하트비트 데몬,
등.)

2015년 6월 13일 토요일 오전 11시 27분, Alex Pollitt [email protected]
썼다:

iptables 접근 방식의 경우 +1입니다. 우리는 Calico에서 iptables를 광범위하게 사용하며
그들은 강력한 것으로 입증되었으며 성능과 확장성이 뛰어납니다.
규칙을 잘 디자인하십시오). @BenTheElder https://github.com/BenTheElder ,
iptables 작업에 도움이 필요하면
우리는 기꺼이 칩을 넣을 것이기 때문입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -111719474
.

Alex에게 감사합니다. 확인하면 알려 드리겠습니다.

누군가 시간이 있다면 현재 구현(https://github.com/GoogleCloudPlatform/kubernetes/pull/9210)에 대한 피드백/입력을 사용할 수 있습니다.

그것은 대부분 완전하고 현재 업스트림 마스터와 함께 최신 상태입니다. 생성된 규칙을 iptables-save 와 비교하고 카운터 등을 복원하는 코드 작성을 완료해야 하지만 규칙이 생성되고 (대부분) 작동합니다. 여기 OP에 설명된 규칙을 거의 따르고 가장 큰 변화는 iptables가 수락할 이름의 자동 생성에 필요한 체인 이름뿐입니다.

https://github.com/BenTheElder/kubernetes/issues/3에 보고된 엣지 케이스가 있습니다. 이 케이스는 자체 연결되는 포드를 처리하기 위해 변경이 필요할 수 있습니다.

@MikaelCluseau 및 @Symmetric 과 특히 이 작업과 다른 작업을 처리하기 위해 일부 재설계를 수행하는 것에 대해 훌륭한 피드백과 토론을 했습니다 (다시 한 번 감사합니다!). 그러나 우리는 특히 규칙 디자인에 대해 더 많은 정보를 사용할 수 있습니다. 다른 사람이 살펴볼 시간이 있다면 가장 좋은 방법이 무엇인지 잘 모르겠고 추가 입력 없이 주요 변경 사항을 피하고 싶기 때문에 크게 감사할 것입니다.

PR 자체는 꽤 크지만 관련 규칙 생성은 모두 pkg/proxy/proxieriptables.go syncProxyRules() ( https://github.com/BenTheElder/kubernetes/blob/iptables_proxy/pkg/proxy/proxieriptables)에 있습니다. 고#L286

기존 토론은 (물론 여기) PR 의견과 https://github.com/BenTheElder/kubernetes/issues/3 및 있습니다. BenTheElder/kubernetes/issues/4.

입력이 필요한 또 다른 문제:

현재 코드에는 nodePort 케이스만 처리하기 위해 kube-proxy가 여전히 포함되어 있습니다. 이 경우에도 kube-proxy를 없앨 수 있다고 생각하고 Ben의 PR 에서 이를 수행하기 위한 몇 가지 간단한 iptables 규칙을 제안했습니다.

그러나 이러한 규칙은 여전히 ​​외부 LB의 소스 IP를 가리므로 이상적이지 않습니다. 문제는 노드에 도달할 때 LB에서 트래픽을 DNAT하면 응답 패킷이 다른 노드에서 올 수 있으므로 LB가 응답을 원래 TCP 세션과 연관시킬 수 있다고 생각하지 않는다는 것입니다. . 이 우려가 유효한가요? 이것에 대해 걱정할 필요가 없다면 구현이 더 간단할 것입니다.

HTTP 프록시를 만족스럽게 유지하기 위해 우리가 할 수 있는 몇 가지 마술이 있다고 생각하지만 L4에서 이것을 일반화할 방법이 없습니다.

나는 당신의 PR에서 흑마법을 시도하고 있지만 나를 위해 아무 것도 생성하지 않습니다. 규칙이 iptables에 대한 호출로 생성되기 시작한 다음 iptables-restore 파일이 생성된 것 같습니다.

생성된 파일의 헤더 부분, 일반적으로 iptables 호출로 채워진 부분에 누락이 있습니다. 로그의 관련 부분이 있습니다.

I0807 11:41:24.560063 8369 iptables.go:327] iptables -N [KUBE-PORTALS-CONTAINER -t nat]를 실행 중입니다.
I0807 11:41:24.562361 8369 iptables.go:327] running iptables -C [PREROUTING -t nat -m comment --comment handle ClusterIPs; 참고: 이것은 NodePort 규칙 -j KUBE-PORTALS-CONTAINER 이전에 있어야 합니다.
I0807 11:41:24.563469 8369 iptables.go:327] iptables -N [KUBE-PORTALS-HOST -t nat] 실행 중
I0807 11:41:24.565452 8369 iptables.go:327] running iptables -C [OUTPUT -t nat -m comment --comment handle ClusterIPs; 참고: 이것은 NodePort 규칙 -j KUBE-PORTALS-HOST 이전에 있어야 합니다.
I0807 11:41:24.566552 8369 iptables.go:327] iptables -N [KUBE-NODEPORT-CONTAINER -t nat] 실행 중
I0807 11:41:24.568363 8369 iptables.go:327] iptables -C 실행 중 [PREROUTING -t nat -m addrtype --dst-type LOCAL -m comment --comment 핸들 서비스 NodePorts; 참고: 이것은 체인의 마지막 규칙이어야 합니다. -j KUBE-NODEPORT-CONTAINER]
I0807 11:41:24.569564 8369 iptables.go:327] iptables -N [KUBE-NODEPORT-HOST -t nat] 실행 중
I0807 11:41:24.571458 8369 iptables.go:327] running iptables -C [OUTPUT -t nat -m addrtype --dst-type LOCAL -m comment --comment 핸들 서비스 NodePorts; 참고: 이것은 체인의 마지막 규칙이어야 합니다. -j KUBE-NODEPORT-HOST]
I0807 11:41:24.573392 8369 iptables.go:327] iptables -C를 실행 중 ]
I0807 11:41:24.574447 8369 proxier.go:349] iptables 규칙을 동기화하는 중입니다.
I0807 11:41:24.575592 8369 proxier.go:399] 체인: PREROUTING, 규칙: :PREROUTING ACCEPT [0:0]
I0807 11:41:24.575615 8369 proxier.go:401] 규칙: -A PREROUTING -m comment --comment "ClusterIP를 처리합니다. 참고: 이것은 NodePort 규칙 앞에 있어야 합니다." -j KUBE-PORTALS-CONTAINER
I0807 11:41:24.575625 8369 proxier.go:401] 규칙: -A PREROUTING -m addrtype --dst-type LOCAL -m comment --comment "서비스 NodePorts를 처리합니다. 참고: 이것은 체인의 마지막 규칙이어야 합니다." -j KUBE-NODEPORT-컨테이너
I0807 11:41:24.575633 8369 proxier.go:399] 체인: INPUT, 규칙: :INPUT ACCEPT [0:0]
I0807 11:41:24.575646 8369 proxier.go:399] 체인: OUTPUT, 규칙: :OUTPUT ACCEPT [0:0]
I0807 11:41:24.575658 8369 proxier.go:401] 규칙: -A OUTPUT -m comment --comment "ClusterIP를 처리합니다. 참고: 이것은 NodePort 규칙 앞에 있어야 합니다." -j KUBE-PORTALS-HOST
I0807 11:41:24.575670 8369 proxier.go:401] 규칙: -A OUTPUT -m addrtype --dst-type LOCAL -m comment --comment "서비스 NodePorts를 처리합니다. 참고: 이것은 체인의 마지막 규칙이어야 합니다." -j KUBE-NODEPORT-호스트
I0807 11:41:24.575683 8369 proxier.go:399] 체인: 포스트라우팅, 규칙: 포스트라우팅 수락 [0:0]
I0807 11:41:24.575691 8369 proxier.go:401] 규칙: -A POSTROUTING! -d 10.0.0.0/8 -o eth0 -j 마스커레이드
I0807 11:41:24.575699 8369 proxier.go:401] 규칙: -A POSTROUTING -s 10.240.240.78/32 -d 10.240.240.78/32 -m comment --comment "handle -jpod가 self에 연결됨"
I0807 11:41:24.575709 8369 proxier.go:399] 체인: KUBE-NODEPORT-CONTAINER, 규칙: :KUBE-NODEPORT-CONTAINER - [0:0]
I0807 11:41:24.575720 8369 proxier.go:399] 체인: KUBE-NODEPORT-HOST, 규칙: :KUBE-NODEPORT-HOST - [0:0]
I0807 11:41:24.575729 8369 proxier.go:399] 체인: KUBE-PORTALS-CONTAINER, 규칙: :KUBE-PORTALS-CONTAINER - [0:0]
I0807 11:41:24.575740 8369 proxier.go:399] 체인: KUBE-PORTALS-HOST, 규칙: :KUBE-PORTALS-HOST - [0:0]
I0807 11:41:24.581897 8369 proxier.go:603] 동기화 규칙: :KUBE-PORTALS-HOST - [0:0]
:KUBE-PORTALS-컨테이너 - [0:0]
:KUBE-NODEPORT-호스트 - [0:0]
:KUBE-NODEPORT-컨테이너 - [0:0]
:KUBE-SVC-VO8JL93ZeRSf8cnsLpl - [0:0]
:KUBE-SVC-L26cB3JYuxdW5TF84ct - [0:0]
:KUBE-SVC-j2SF8q3nUajS8vOx2qL - [0:0]
:KUBE-SVC-shln2urO8W1aBiB2bWJ - [0:0]
:KUBE-SVC-8jQ3IvijvhJ4ppFj3Ui - [0:0]
[... 스닙 ...]

자세한 정보 표시 모드에서 생성된 결과와 iptable-save를 병합하면 가져올 수 있고 좋은 일을 할 수 있습니다.

@bnprss 보고서에 감사드립니다. 최근 검토 프로세스를 위해 일부 재작성 중에 임시 파일을 사용하고 iptables-restore "-T table" 플래그를 사용하는 것을 포함하여 테스트되지 않은 변경 사항이 많이 있었습니다. 회귀의 원인이 무엇인지 알게 되면 수정 사항을 적용하겠습니다.

@bnprss 테이블 헤더가 누락되었다고 말했듯이("*nat"가 첫 번째 라인이어야 함), 실수로 제거되었으며 이를 다시 넣은 후 겉보기에 다른 버그 없이 다시 정상적으로 작동하는 것 같습니다(제외: https:// /github.com/BenTheElder/kubernetes/issues/3). 다시 한 번 감사드립니다. 죄송합니다. 수정을 밀어 넣었습니다.

잘했습니다. 규칙이 로드 중이고 내부에서 작동하는 것 같지만 외부 로드 밸런서에는 운이 없습니다. 외부와의 통신이 응답하지 않습니다.

뭐. PR로 이동하여 더 자세한 정보를 제공할 수 있습니까? 지금까지
잘 작동하고 있지만 로컬 테스트 이상으로 배포하지 않습니다.
다른 테스터가 외부 부하 분산 장치를 사용하고 있다고 생각하지 마십시오.
2015년 8월 7일 오후 1시 29분에 "bnprss" [email protected]이 작성했습니다.

잘했습니다. 규칙이 로드 중이고 내부에서 작동하는 것 같지만 운이 없습니다.
externalloadbalancer를 사용하면 외부와의 통신이 응답하지 않습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128772763
.

네, 자세한 내용을 위해 추가 문의를 수행하고 PR에 대한 일부 로그 또는 리드를 생성할 것이지만 내일 이전에는 그렇지 않으므로 잠재적으로 문제가 발생하기 전에 실행할 수 있는 좋은 백업 작업을 하고 싶습니다.

구분 기호 "-_" 없이 규칙의 토큰을 계산할 수 있습니까?

@bnprss , 훌륭합니다.
서비스에 대해 생성된 규칙 체인은 서비스 포트/엔드포인트의 해시이며 base64 URL이 인코딩되고 잘립니다. KUBE-SVC-. 코드는 다음과 같습니다. https://github.com/GoogleCloudPlatform/kubernetes/pull/9210/files#diff -d51765b83fe795b469e8a86276b12dc9R321
우리는 iptables의 문자 제한을 충족하면서도 여전히 결정적인 유효한 체인 이름을 생성하는 방법으로 이것을 선택했습니다.
따라서 외부에서 복제가 가능해야 합니다.
의미하는 경우 구분 기호 사용을 중지할 수는 있지만 "_"는 일부 인코딩된 해시에서 가져오고 "-"는 모두 기존 사용자 공간 프록시의 규칙 이름 패턴을 따릅니다.
필요한 경우 큰 문제 없이 다른 것을 사용할 수 있습니다.

난 괜찮아, 이건 정말 화장품이야! :)
그러나 이것은 내가 전에 본 것과 다릅니다.
gce lb 규칙: a07f76b3b2ec311e59e2642010af0479
gce fw 규칙: k8s-fw-a7ecad94f3ba511e59e2642010af0479
gce 라우팅 규칙: default-route-6973e029b504a0e8
노드로 gce 라우팅: obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

이것은 좋은 것입니다:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
그것들은 재미있다:
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y--z1xTUpHPT6sgAUCC

그래, 나도 그들의 팬이 아니야, 우리는 아마도 해시를 바꿀 수 있을거야
부호화.

2015년 8월 7일 금요일 오후 2시 16분에 bnprss [email protected]에서 다음과 같이 썼습니다.

난 괜찮아, 이건 정말 화장품이야! :)
그러나 이것은 내가 전에 본 것과 다릅니다.
gce lb 규칙: a07f76b3b2ec311e59e2642010af0479
gce fw 규칙: k8s-fw-a7ecad94f3ba511e59e2642010af0479
gce 라우팅 규칙: default-route-6973e029b504a0e8
노드로 gce 라우팅:
obfuscated_cluster_node-43506797-2eb2-11e5-9e26-42010af04793

이것은 좋은 것입니다:
KUBE-SVC-6ADi2TVfn7mFPvBjC56
그것들은 재미있다:
KUBE-SVC-zU6ParcQ-UfW_LdRDUc
KUBE-SVC-y--z1xTUpHPT6sgAUCC

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128785914
.

예, SHA의 잘린 부분만 사용할 수 있습니다. git은 docker도 괜찮고 kube 엔터티에 대한 다른 참조가 만들어지는 방식인 것 같습니다. 생성된 해시 base64에서 충돌이 발생하면 도움이 되지 않습니다. ;)
@thockin 이 그 점에 대해 조언할 수 있을 것 같습니다.

나는 iptables의 유효한 문자에 더 관심이 많았는데, 좋은 참조를 찾는 데 어려움을 겪었습니다. 이에 대해서는 곧 자세히 살펴보겠습니다.

2015년 8월 7일 금요일 오후 2시 29분에 bnprss [email protected]에서 다음과 같이 썼습니다.

예, SHA의 잘린 부분만 사용할 수 있습니다. git은 괜찮습니다.
그건, 도커도, 그리고 kube에 대한 다른 참조인 것 같습니다.
엔티티가 만들어집니다. 생성된 해시 base64에서 충돌이 발생하면
돕다. ;)
@thockin https://github.com/thockin 이 그 점에 대해 조언할 수 있을 것 같습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128788454
.

@bnprss fyi PR은 상당히 불안정하고 다시 작성 중입니다. 현재로서는 NodePort 등을 잘라내고 포털을 지원하는 더 간단하고 깨끗한 버전을 얻은 다음 전체 패리티로 다시 작업하는 데 집중하고 있습니다.

지금 당장 실행하지는 _하지_ 않겠지만 곧 다시 작동할 것입니다. PR을 더 작은 관련 것으로 쪼개서 지금 당장 iptables-proxy로 깨끗한 것을 푸시합니다.

집에서 노는 사람들을 위해, 나는 우리가 그것을 완전히 얻을 수 있다고 확신합니다.
패리티지만 단계별로 검토하는 것이 훨씬 더 쉬울 것입니다. :)

2015년 8월 7일 금요일 오후 9시 35분, Benjamin Elder 알림 @github.com
썼다:

위의 댓글에 대한 내 대답도 곧 지워질 것입니다.

IRC에서 논의:

• 여전히 카운터를 처리해야 하지만 계속해서
  util/iptables 패키지의 상태.
• 체인 길이 제한을 처리하기 위해 여전히 해싱 또는 이와 유사한 것이 필요합니다.

그렇지 않으면 매우 깔끔한 단순화처럼 보이지만 후에 구현됩니다.
좀 더 토론.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/3760#issuecomment -128912169
.

상태: "기본" 로직이 체크인되고 플래그가 지정됩니다.

나는 지금 노드 포트에서 일하고 있습니다. 특별한 처리가 필요한 이상한 케이스가 많이 있습니다. 지금까지 내 메모:

# Basic node ports:
iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A PREROUTING -j KUBE-NODEPORTS
iptables -t nat -A OUTPUT -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment --comment "TEST: default/nodeport:p" -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

# To get traffic from node to localhost:nodeport to the service:
echo 1 > /proc/sys/net/ipv4/conf/all/route_localnet
# Mark packets that are destined for services from localhost, then masquerade those
iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK --set-mark 0x4b000001;
iptables -t nat -A POSTROUTING -m mark --mark 0x4b000001 -j MASQUERADE

# To get traffic from a pod to itself via a service:
for intf in $(ip link list | grep veth | cut -f2 -d:); do brctl hairpin cbr0 $intf on; done
# Mark packets that are destined for each endpoint from the same endpoint, then masquerade those.
# This is hacky, but I don't really know which pods are "local" and I don't really want to right now. (but I will eventually)
iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK --set-mark 0x4b000001

테스트를 위한 contrib 도구에 대해 작업했습니다.
지금까지 나는 노드에서 서버를 가동할 것이라고 생각하고 있습니다. 시간 대기 시간은
이에 대한 요청은 kube-proxy 리소스 로드 및 덤프 가져오기에 대해 참조하세요.
그래프 등을 위해 데이터를 CSV로
금요일 이전에 완료되어 지금 kubectl에 더 익숙해지기를 바랍니다.

2015년 8월 12일 수요일 오후 8시 48분, Tim Hockin [email protected]
썼다:

상태: "기본" 로직이 체크인되고 플래그가 지정됩니다.

나는 지금 노드 포트에서 일하고 있습니다. 필요한 이상한 케이스가 많이 있습니다.
특별한 취급. 지금까지 내 메모:

기본 노드 포트:

iptables -t nat -N KUBE-NODEPORTS
iptables -t nat -A 사전 라우팅 -j KUBE-NODEPORTS
iptables -t nat -A 출력 -j KUBE-NODEPORTS
iptables -t nat -A KUBE-NODEPORTS -p tcp -m comment --comment "테스트: 기본/ 노드포트:p " -m tcp --dport 30241 -j KUBE-SVC-EQKU6GMUKRXBR6NWW53

노드에서 localhost:nodeport 로의 트래픽을 서비스로 가져오려면:

에코 1 > /proc/sys/net/ipv4/conf/all/route_localnet

localhost의 서비스를 대상으로 하는 패킷을 표시한 다음 해당 패킷을 가장합니다.

iptables -t nat -I KUBE-SVC-EQKU6GMUKRXBR6NWW53 -s 127.0.0.0/16 -j MARK --set-mark 0x4b000001;
iptables -t nat -A POSTROUTING -m 마크 --mark 0x4b000001 -j MASQUERADE

서비스를 통해 포드에서 자체로 트래픽을 가져오려면 다음 안내를 따르세요.

for intf in $(ip link list | grep veth | cut -f2 -d:); brctl 머리핀 cbr0 $intf 켜기; 완료

동일한 끝점에서 각 끝점으로 향하는 패킷을 표시한 다음 가장합니다.

이것은 해키하지만 어떤 포드가 "로컬"인지 실제로 알지 못하며 지금 당장은 정말로 원하지 않습니다. (하지만 나는 결국)

iptables -t nat -I KUBE-SEP-HHNEQBOLY57T5MQCFIY -s 10.244.1.6 -j MARK --set-mark 0x4b000001

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130492394
.

@BenTheElder 방금 GCE에서 합리적으로 상세한 네트워크 성능 측정을 수행했습니다. netperf를 살펴보는 것이 좋습니다(qperf는 대기 시간 측정도 제공함).

netperf는 클라이언트/서버 성능 도구입니다. 도커 컨테이너 paultiplady/ netserver:ubuntu.2에 클라이언트와 서버를 모두 패키징

kubectl exec  -t $netserver-pod-1 -- netperf –l 30 -i 10 -I 99,1 -c -j -H $netserver-pod-2-ip -t OMNI --  -T tcp -D -O THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

대기 시간 및 처리량을 포함한 적절한 통계 분포를 제공해야 합니다. docker run --net=host 를 사용하여 netserver 컨테이너를 실행하여 node->pod 테스트도 수행할 수 있습니다.

이 컨테이너의 dockerfile은 매우 간단합니다. 더 간결한 것으로 확장하려는 경우 실행할 수 있습니다(예: 더 빠른 풀링을 위한 alpinelinux 기반 컨테이너).

감사합니다.

이 의견 에서 우리는 일종의 서비스 요청 대기 시간을 원한다고 생각합니다. 지금은 표준 nginx 컨테이너를 노드 X로 사용하려고 시도하고 있으며 테스트 포드 시간을 반복적으로 치는 작업을 하고 있으므로 노드 Y에서 그래프를 작성할 수 있습니다.

하지만 netperf/qperf를 살펴보고 항상 여러 테스트를 수행할 수 있습니다.
@thockin과의 이전 토론에 따라 먼저 해당 그래프를 완료하고 싶습니다.

2015년 8월 13일 목요일 오전 12:02, Paul Tiplady [email protected]
썼다:

@BenTheElder https://github.com/BenTheElder 나는 합리적으로 일을했습니다.
GCE에 대한 자세한 네트워크 성능 측정 -- 다음을 살펴보는 것이 좋습니다.
netperf(qperf는 대기 시간 측정도 제공함).

netperf는 클라이언트/서버 성능 도구입니다. 저는 클라이언트와
도커 컨테이너 paultiplady/ netserver:ubuntu.2 의 서버
netperf에는 많은 옵션이 있지만 두 개를 회전시키는 것과 같은 것입니다.
넷서버 포드 및 실행

kubectl exec -t $netserver-pod-1 -- netperf -l 30 -i 10 -I 99,1 -c -j -H $netserver-pod-2-ip -t OMNI -- -T tcp -D -O THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

대기 시간 및 처리량을 포함한 적절한 통계 분포를 제공해야 합니다.
docker run --net=host를 사용하여 netserver 컨테이너를 실행하여 수행할 수 있습니다.
노드 -> 포드 테스트도 수행합니다.

이 컨테이너의 dockerfile은 매우 간단합니다. 다음과 같은 경우 실행할 수 있습니다.
더 간결한 것으로 확장하고 싶습니다(예: alpinelinux 기반
더 빠른 당김을 위한 용기).

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576
.

노드 포트와 관련하여: #9210 @Symmetric에서 이 경우를 가져왔습니다.

트래픽이 흐르는 경우:
LB -> node1:nodePort
서비스 포드가 node2에 있는 경우 전체 흐름은 다음과 같습니다.
LB -> node1:nodePort -> node2 -> pod:svcPort
srcIP는 여전히 LB이므로 응답은
pod -> node2 -> LB
node2는 LB로 직접 라우팅할 수 있기 때문입니다.

이제 반환 패킷에 대한 올바른 소스 IP를 복원하기 위해 DNAT를 해제할 기회를 잃게 됩니다(노드 1에서만 발생할 수 있음).

문제를 재현했습니다. 그것이 진짜 문제라는 것을 ACK. tcpdump는 src가 손상되지 않은 상태에서 (오프 머신) 포드 IP:port로 DNAT되는 패킷을 보여주지만 대상 머신의 tcpdump는 아무 것도 표시하지 않습니다. 패킷이 도착한 경우에도 어떤 일이 일어날지 잘 모르겠습니다.

유일한 해결책은 SNAT뿐이라고 생각합니다. 가장 영향이 적은 솔루션은 오프 노드로 향하는 LB의 SNAT 패킷 _only_ 것입니다. 그러나 a) kube-proxy에 해당 정보가 없습니다(코드 비용으로 얻을 수 있음) 및 b) 정책은 어쨌든 SNAT 경우를 고려해야 하므로 항상 외부 LB 패킷을 SNAT하여 단순화할 수 있습니다. 정책 엔진에 얼마나 나쁜가?

결국 LB는 포드가 있는 호스트만 대상으로 할 수 있을 만큼 충분히 똑똑해지며 트래픽은 로컬로 유지되며 이는 무의미해질 것입니다.

그래도 더 복잡해집니다. deprecatedPublicIPs 필드가 있습니다. 이 필드는 동작을 약간 조정하여 사용하지 않을 것입니다. 우리도 그런 사람들을 위해 똑같이 해야 한다고 생각합니다. 그러나 더 복잡해집니다. 실제로 모든 공용 IP를 알지 못합니다(예: VM에 1:1 NAT 외부 IP가 있음). 쉬운 대답 - 항상 SNAT 노드 포트 패킷입니다. 무슨 생각?

내일 더 테스트하겠습니다.

@BenTheElder netserver 포드를 서비스로 만들 수 있으므로 perf <->의 트래픽이
서버는 서비스 VIP를 통해 이동합니다. 그렇게하면 할 필요가 없습니다
샘플링/대기 시간 계산 직접...

2015년 8월 12일 수요일 오후 9시 20분, Benjamin Elder 알림 @github.com
썼다:

감사합니다.

이 댓글에서
우리가 일종의 서비스 요청 대기 시간을 원한다고 생각합니다. 오른쪽
이제 표준 nginx 컨테이너를 노드 X로 사용하고
테스트 포드 시간을 반복적으로 쳐서 그래프를 작성할 수 있습니다.
노드 Y.

하지만 netperf/qperf를 살펴보고 항상 여러 테스트를 수행할 수 있습니다.
이전 토론에 따라 먼저 해당 그래프를 완료하고 싶습니다.
@토킨

2015년 8월 13일 목요일 오전 12:02, Paul Tiplady [email protected]
썼다:

@BenTheElder https://github.com/BenTheElder 나는 합리적으로 일을했습니다.
GCE에 대한 자세한 네트워크 성능 측정 -- 다음을 살펴보는 것이 좋습니다.
netperf(qperf는 대기 시간 측정도 제공함).

netperf는 클라이언트/서버 성능 도구입니다. 저는 클라이언트와
도커 컨테이너 paultiplady/ netserver:ubuntu.2 의 서버
netperf에는 많은 옵션이 있지만 두 개를 회전시키는 것과 같은 것입니다.
넷서버 포드 및 실행

kubectl exec -t $netserver-pod-1 -- netperf -l 30 -i 10 -I 99,1 -c -j -H
$netserver-pod-2-ip -t OMNI -- -T tcp -D -O
THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

대기 시간 및
처리량.
docker run --net=host를 사용하여 netserver 컨테이너를 실행하여 수행할 수 있습니다.
노드 -> 포드 테스트도 수행합니다.

이 컨테이너의 dockerfile은 매우 간단합니다. 다음과 같은 경우 실행할 수 있습니다.
더 간결한 것으로 확장하고 싶습니다(예: alpinelinux 기반
더 빠른 당김을 위한 용기).

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130527558
.

진실. @thockin 은 결국 e2e 대기 시간 테스트를 다음과 같이
잘. 시간이 허락하는 한 다양한 테스트가 있을 것이며 우리는
아마도 gce 대 AWS 등을 고려해야 할 것입니다.
2015년 8월 13일 오후 1시 47분에 "Paul Tiplady" [email protected]이 다음과 같이 썼습니다.

netserver 포드를 서비스로 만들어 perf <->의 트래픽이
서버는 서비스 VIP를 통해 이동합니다. 그렇게하면 할 필요가 없습니다
샘플링/대기 시간 계산 직접...

2015년 8월 12일 수요일 오후 9시 20분, Benjamin Elder 알림 @github.com
썼다:

감사합니다.

[이 댓글](

https://github.com/kubernetes/kubernetes/pull/9210#issuecomment-130154261)
우리가 일종의 서비스 요청 대기 시간을 원한다고 생각합니다. 오른쪽
이제 표준 nginx 컨테이너를 노드 X로 사용하여 작업하려고 합니다.
~에
테스트 포드 시간을 반복적으로 쳐서 그래프를 작성할 수 있습니다.
노드 Y.

하지만 netperf/qperf를 살펴보고 항상 여러 테스트를 수행할 수 있습니다.
이전 토론에 따라 먼저 해당 그래프를 완료하고 싶습니다.
@토킨

2015년 8월 13일 목요일 오전 12:02, Paul Tiplady < [email protected]

썼다:

@BenTheElder https://github.com/BenTheElder 방금 일부 작업을 수행했습니다.
합리적으로
GCE에 대한 자세한 네트워크 성능 측정 -- 살펴보는 것이 좋습니다.
~에
netperf(qperf는 대기 시간 측정도 제공함).

netperf는 클라이언트/서버 성능 도구입니다. 두 클라이언트를 모두 패키징했습니다.
그리고
도커 컨테이너 paultiplady/ netserver:ubuntu.2 의 서버
거기
netperf에는 많은 옵션이 있지만 두 개를 회전시키는 것과 같은 것입니다.
넷서버 포드 및 실행

kubectl exec -t $netserver-pod-1 -- netperf -l 30 -i 10 -I 99,1 -c -j
-시간
$netserver-pod-2-ip -t OMNI -- -T tcp -D -O

THROUGHPUT,THROUGHPUT_UNITS,MEAN_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,STDDEV_LATENCY,LOCAL_CPU_UTIL

대기 시간 및
처리량.
docker run --net=host를 사용하여 netserver 컨테이너를 실행하여 수행할 수 있습니다.
노드 -> 포드 테스트도 수행합니다.

이 컨테이너의 dockerfile은 매우 간단합니다. 실행할 수 있습니다.
만약
더 간결한 것으로 확장하고 싶습니다(예: alpinelinux 기반
더 빠른 당김을 위한 용기).

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<

https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130524576

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130527558

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130776866
.

@Symmetric netperf 테스트가 잘 작동합니다. 제안 감사합니다 :-)

나중에 웹 서비스와 같은 "실제" 로드에 대한 테스트를 다시 시도하고 싶지만 인수를 올바르게 얻은 후에는 지금까지 매우 좋은 데이터를 제공하고 있습니다. 나중에 청소가 끝나면 결과를 게시하겠습니다.

그것이 당신을 위해 일하고 있다는 소식을 들으니 기쁩니다.
그 도구에 대한 옵션이 있지만 내 프로파일링 작업에 매우 유용한 것으로 입증되었습니다.
확실히 iperf보다...

2015년 8월 13일 목요일 오후 2시 32분, Benjamin Elder 알림 @github.com
썼다:

@Symmetric https://github.com/Symmetric netperf 테스트가 작동 중입니다
훌륭하게. 제안 감사합니다 :-)

나중에 웹 서비스와 같은 "실제" 부하에 대한 테스트를 다시 시작하고 싶습니다.
가능하지만 인수를 올바르게 얻은 후에는 매우 좋은 데이터를 제공하므로
멀리. 나중에 청소가 끝나면 결과를 게시하겠습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -130850398
.

@thockin LB 트래픽을 위해 SNAT를 사용할 수 있다고 생각합니다. 내 현재 생각은 포드의 액세스 정책을 다음 중 하나로 지정해야 한다는 것입니다.

• 기본값은 '[my namespace]에서 허용'이며, 이 경우 LB 패킷이 삭제됩니다.
• '[이름 공간 목록]에서 허용' 또는 '[클러스터의 모든 이름 공간]에서 허용', 다시 LB 패킷은 항상 삭제됩니다.
• '모두에서 허용', 이 경우 LB, 다른 노드 또는 어디에서든 상관하지 않습니다.

따라서 LB의 소스 IP를 잃는 것은 실제로 비용이 많이 들지 않습니다.

LB가 서비스 포드에 대한 올바른 노드에 도달한다는 것을 보장할 수 있다면 훌륭할 것입니다. 이 경우 SNAT가 필요하지 않으며, LB IP가 프로비저닝될 때 LB IP를 화이트리스트에 추가하여 더 엄격한 배송을 실행할 수 있습니다. 서비스를 제공하고 그렇지 않으면 트래픽을 중단합니다.

publicIP와 관련하여 nodePort와 동일한 고려 사항이 있을 것이므로 LB가 올바른 호스트에 도달할 때까지 SNAT해야 합니다. nodePort보다 더 사악한 방법을 놓치고 있지 않는 한 위의 내용은 괜찮습니다 ...

안전 조치로 모든 것을 MASQUERADE에 프록시하는 플래그를 실제로 포함하는 것이 매우 유용할 수 있습니다(사용자 공간 프록시에 매우 가깝게 작동). 나는 그것이 매우 어렵지 않고 문제가 발생한 경우 진단하거나 대체하는 매우 좋은 방법이라고 생각합니다(vxlan 사례에 대해 생각하고 있습니다).

-------- 메시지 d'origine --------
드 : Paul Tiplady [email protected]
날짜 : 2015년 8월 14일 12:50 (GMT+11:00)
À : kubernetes/kubernetes [email protected]
참조 : 미카엘 클루 소 [email protected]
Objet : Re: [kubernetes] 사용자 공간 대신 ​​프록시에 iptables를 사용합니다.
(#3760)

@thockin LB 트래픽을 위해 SNAT를 사용할 수 있다고 생각합니다. 내 현재 생각은 포드의 액세스 정책을 다음 중 하나로 지정해야 한다는 것입니다.

기본값은 '[my namespace]에서 허용'이며, 이 경우 LB 패킷이 삭제됩니다.
'[이름 공간 목록]에서 허용' 또는 '[클러스터의 모든 이름 공간]에서 허용', 다시 LB 패킷은 항상 삭제됩니다.
'모두에서 허용', 이 경우 LB, 다른 노드 또는 어디에서든 상관하지 않습니다.

따라서 LB의 소스 IP를 잃는 것은 실제로 비용이 많이 들지 않습니다.

LB가 서비스 포드에 대한 올바른 노드에 도달한다는 것을 보장할 수 있다면 훌륭할 것입니다. 이 경우 SNAT가 필요하지 않으며, LB IP가 프로비저닝될 때 LB IP를 화이트리스트에 추가하여 더 엄격한 배송을 실행할 수 있습니다. 서비스를 제공하고 그렇지 않으면 트래픽을 중단합니다.

publicIP와 관련하여 nodePort와 동일한 고려 사항이 있을 것이므로 LB가 올바른 호스트에 도달할 때까지 SNAT해야 합니다. nodePort보다 더 사악한 방법을 놓치고 있지 않는 한 위의 내용은 괜찮습니다 ...

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

@MikaelCluseau 나쁜 생각은 아닙니다. 특별히 새 문제를 열어 주시겠습니까?

여전히 할 일: 머리핀, e2e 수정, 기본적으로 활성화

팀 안녕, 다시 오지 못해 미안하지만 여기서 처리해야 할 문제가 좀 있어서 ... 다음 주 토요일에 머리핀을 고를 것 같아요.

이것은 나를 위한 메모였습니다. 이 문제를 해결할 계획이셨습니까? :)

예, 그렇습니다. e2 테스팅에 대해 이야기할 때 말했듯이. 내가 도와줄게, 쿠버네티스가 나에게 큰 도움이 되니까 최대한 마스터하는게 낫고, 버그를 잡는 것보다 뭐가 나을까? :-) 우선 순위가 더 높은 것을 자유롭게 제안하지만 머리핀은 시작하기에 아주 좋은 것 같습니다. kubelet에서 발생해야 하며 활성화할 플래그가 있어야 합니다(처음에는 기본적으로 비활성화됨). 일주일에 0.5~1일 일하려고 합니다.

AFAIK가 할 수 있는 유일한 부분은 v1.1 이후에 발생할 수 있는 기본값(폭발이 없다고 가정)으로 만드는 것이며 여기에는 몇 마일이 있습니다.

우!

2015년 9월 24일 목요일 오전 11시 21분, Tim Hockin [email protected]
썼다:

AFAIK가 할 수 있는 유일한 부분은 그것을 기본값으로 만드는 것입니다.
v1.1 이후에 (폭발이 없다고 가정) 약간의 마일이 있습니다.
그 위에.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -142960614
.

v1.1 이후 얼마 후 이것은 그것에 약간의 마일이 있습니다.

아야. 우리는 1.1을 위해 그것을 정말로 기대하고있었습니다 ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

@bgrieder 여전히 매개변수를 통해 활성화할 수 있습니다.

IN이지만 기본적으로 켜져 있지 않습니다. 당 하나의 주석으로 옵트인할 수 있습니다.
노드(및 kube-proxy 재시작)

2015년 9월 24일 목요일 오전 8시 27분에 Bruno G. [email protected]이 다음과 같이 썼습니다.

v1.1 이후 얼마 후 이것은 그것에 약간의 마일이 있습니다.

아야. 우리는 1.1을 위해 그것을 정말로 기대하고있었습니다 ....
https://github.com/kubernetes/kubernetes/blob/master/docs/roadmap.md

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -142962932
.

@thockin @bnprss ok 하지만 버전 1.1은 출시 후 Google Container Engine에서 실행될 것으로 예상합니다. '노드당 단일 주석으로 선택'하는 데 어떤 종류의 유연성이 필요한지 궁금합니다. 절차가 어떻게 되는지에 대한 세부 정보를 알려주시거나 문서를 알려주시겠습니까?

1.1로 업그레이드되면:

$ for node in $(kubectl get nodes -o name); do kubectl annotate $node net.beta.kubernetes.io/proxy-mode=iptables; done

그런 다음 각 노드에 SSH를 사용하고 kube-proxy를 다시 시작합니다(또는 각 노드를 재부팅).

좀 더 신중하게 하고 싶다면 1~2노드 해보고 해보세요 :)

1.1 문서에 매직 루프를 포함하는 것을 잊지 않도록 이 문제를 "릴리스 노트"로 표시했습니다.

@RichieEscarez

(그냥 한 주 동안 iptables 프록시를 사용해 왔으며 모든 것이 괜찮은 것 같습니다!)

@thockin 이것은 폐쇄되어야 합니까, 아니면 1.1 마일스톤에서 제거되어야 합니까?

기본 활성화를 위해 1.2로 이동하겠습니다.

잠재적으로 어리석은 질문에 대해 사과하지만 클라이언트 IP의 보존과 관련하여:

@thockin 9월 2일의 또 다른 문제에서 "클러스터 내 트래픽만 클라이언트 IP를 유지합니다"라는 내용을 보았습니다. 이것이 1.2 알파에서도 여전히 사실입니까?

새로운 1.2 클러스터를 시작하고 노드 주석을 적용하고 다시 시작했지만 여전히 HAProxy를 실행하는 포드에 대한 모든 요청의 소스 주소로 10.244.0.1이 표시됩니다.

이 시점에서 저는 우리가 설정을 놓쳤는지 여부를 알아 내려고 노력하고 있거나 아직 가능하지 않은 것을 달성하려고 노력하고 있습니다. 즉, 요청을 보내는 실제 클라이언트의 공개 IP 주소를 보는 것입니다. 클러스터 외부.

기본값은 여전히 ​​사용자 공간 모드를 사용합니다. 주석을 설정해야 합니다.
노드(net.beta.kubernetes.io/proxy-mode=iptables) 및 다시 시작
대리. 그러나 외부 클라이언트 IP는 노출되지 않고 클러스터 내부만 노출됩니다.
IP.
2015년 10월 23일 오후 5시 9분에 "Ben Hundley" [email protected]이 다음과 같이 썼습니다.

잠재적으로 어리석은 질문에 대해 사과하지만 보존과 관련하여
클라이언트 IP:

@thockin https://github.com/thockin 9월 2일 다른 호에서 봤습니다
"클러스터 내 트래픽만 클라이언트 IP를 유지합니다" -- 여전히
1.2 알파에 대해 사실입니까?

새로운 1.2 클러스터를 시작하고 노드 주석을 적용하고 다시 시작했습니다.
그리고 여전히 10.244.0.1을 모든 요청에 ​​대한 소스 주소로 봅니다.
HAProxy를 실행하는 포드.

이 시점에서 나는 우리가 놓쳤는지 여부를 알아 내려고 노력하고 있습니다.
설정하거나 아직 가능하지 않은 것을 달성하려고 합니다.
요청을 하는 실제 클라이언트의 공용 IP 주소를 보고 있습니다.
클러스터 외부에서.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150725513
.

외부 트래픽을 DNAT + kube-proxy를 통한 라우팅으로 외부 클라이언트 IP를 유지할 수 있습니다. 예를 들어, 서비스 네트워크가 10.42.0.0/16이고 IP 10.10.1.1에 고가용성 kube-proxy가 있는 경우 다음 iptable 규칙을 가질 수 있습니다.

-A PREROUTING -i public -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.42.12.34

및 다음 경로:

10.42.0.0/16 via 10.10.1.1 dev edge 

그러면 뒤에 있는 포드가 실제 IP를 확인합니다.

Oct 24 02:41:39 email-0yr7n mail.info postfix/smtpd[469]: connect from zed.yyy.ru.[94.102.51.96]

물론 패킷의 반환 경로가 정확해야 합니다.

예, 이 DNAT가 오프머신 백엔드에 연결되면
SNAT. 이것이 근본적인 문제입니다.

2015년 10월 23일 금요일 오후 8시 12분, Mikaël Cluseau [email protected]
썼다:

외부 트래픽을 DNAT로 처리하여 외부 클라이언트 IP를 유지할 수 있습니다.
kube-proxy를 통한 라우팅. 예를 들어 서비스 네트워크가
10.42.0.0/16이고 IP에 고가용성 kube-proxy가 있습니다.
10.10.1.1에서 다음 iptable 규칙을 가질 수 있습니다.

-A PREROUTING -i public -p tcp -m tcp --dport 25 -j DNAT --to-destination 10.42.12.34

및 다음 경로:

10.10.1.1 dev edge를 통한 10.42.0.0/16

그러면 뒤에 있는 포드가 실제 IP를 확인합니다.

10월 24일 02:41:39 이메일-0yr7n mail.info postfix/smtpd[469]: zed.yyy.ru.[94.102.51.96]에서 연결

물론 패킷의 반환 경로가 정확해야 합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150747217
.

흥미롭게 들립니다. 어떤 링크가 있습니까? :-) 패킷이 올바른 conntrack 규칙을 통과하는지 확인하는 방법을 찾고 있습니다. 클러스터를 통해 conntrack 상태를 복제하는 것에 대해 생각하고 있었습니다.

나는 당신이 달성하려는 것을 약간 잃어 버렸습니다.

현재 iptables 프록시가 작동해야 하는 방식은 패킷
노드에 도착하면 로컬에서 생성되지 않았음을 감지하고 플래그를 지정합니다.
SNAT, 백엔드 선택, SNAT가 있는 백엔드로 전달, 백엔드 응답
우리는 SNAT를 해제하고 DNAT를 해제하고 외부 사용자에게 응답합니다.

2015년 10월 23일 금요일 오후 9시 32분, Mikaël Cluseau [email protected]
썼다:

흥미롭게 들립니다. 어떤 링크가 있습니까? :-) 나는 확실한 방법을 찾으려고 노력하고 있습니다.
패킷은 올바른 conntrack 규칙을 거칩니다. 나는 생각하고 있었다
클러스터를 통해 conntrack 상태를 복제합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150753147
.

아, 제가 명확하지 않다면 죄송합니다. SNAT가 없는 경우에 대해 이야기하고 있었습니다. 모든 kube-proxy에 동일한 conntrack 목록이 있는 경우 컨테이너가 고객에게 응답할 때 모든 kube-proxy가 DNAT를 올바르게 해제할 수 있어야 합니다.

다음과 같은 선 모양의 구조를 유지하기 위해 HA를 포함하지 않는 복제가 없는 것을 볼 수 없었습니다.

[client] ----- [proxy in HA] ------ [node1]
                           `------- [node2]

그러나 삼각형 모양의 것이 작동한다면 더 많은 가능성을 열어야 합니다.

[client] ----- [proxy1] ------ [node1]
       `------ [proxy2] ------ [node2]

귀여울텐데 미친듯이 복잡해

2015년 10월 25일 일요일 오후 11:20, Mikaël Cluseau [email protected]
썼다:

아, 제가 명확하지 않다면 죄송합니다. SNAT가 없는 경우에 대해 이야기하고 있었습니다. 만약에
모든 kube-proxy는 동일한 conntrack 목록을 가지며, 그 중 어느 것이든 다음을 수행할 수 있어야 합니다.
컨테이너가 고객에게 응답할 때 DNAT를 올바르게 해제합니다.

유지하기 위해 HA를 포함하지 않는 복제가 없는 것을 볼 수 없었습니다.
다음과 같은 선 모양의 구조:

[클라이언트] ----- [HA의 프록시] ------ [노드1]
`--------- [노드2]

그러나 삼각형 모양의 것이 작동한다면 더 많은 가능성을 열어야 합니다.

[클라이언트] ----- [프록시1] ------ [노드1]
`------ [프록시2] ------ [노드2]

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -151037663
.

내가 탐색해야 하는 방법(적절한 조사를 하기 전에 묻고 싶지 않지만 서브젯이 이제 열려 있기 때문에...)은 여기에서 볼 수 있는 "비대칭 다중 경로 라우팅"입니다. http:// conntrack-tools.netfilter.org/manual.html#sync-aa . 그리고 네, 정말 정말 좋을 것입니다 :-)

작동할 수 있는 가장 간단한 것은...

1. proxy1은 iptables 후크를 통해 새 연결을 수신하고(어디선가 본 적이 있다고 생각합니다) 해당 LB는 이를 proxy2의 노드에 할당합니다.
2. proxy1은 "setup conntrack entry for {src-ip}:{src-port} -> {pod-ip}:{pod-port}"와 같은 요청을 보냅니다.
3. proxy2는 요청을 수신하고 conntrack 항목을 설정하고 이를 proxy1에 ACK합니다.
4. proxy1은 패킷이 DNAT 규칙을 통과하도록 합니다(이는 proxy1에도 conntrack 항목을 넣음).
5. 포드가 응답하면 이에 따라 proxy2의 호스트가 DNAT를 해제합니다.
6. 클라이언트가 proxy1을 통해 이 흐름에서 다른 패킷을 보낼 때 conntrack 항목도 올바른 DNAT를 수행합니다.

이런 식으로 오버헤드는 새 연결당 2개의 패킷이고 un-SNAT + 추가 라우팅을 피함으로써 신속하게 상환됩니다(그렇지 않으면 패킷이 proxy1을 통해 되돌아가야 하기 때문에).

나는 네트워크 사람이 아니므로 너무 많이 가정 할 수 있지만 합리적으로 보입니다.

제 경우에는 NodePort 서비스별로 방화벽 규칙을 설정하는 것을 목표로 했습니다.

다음과 같이 INPUT 체인에서 다른 모든 규칙을 간단한 ALLOW IP / DROP 추가할 수 있는 것 같습니다.

iptables -A INPUT -s $WHITELISTED_IP -p tcp --dport $CONTAINER_PORT -j ACCEPT
iptables -A INPUT -p tcp --dport $CONTAINER_PORT -j DROP

이러한 규칙을 적용하기 위해 내가 구상한 것은 NodePort 서비스에서 주석을 사용하는 것이었습니다. 주석은 화이트리스트에 있는 IP를 보유합니다.

이러한 규칙이 적용될 때까지 조금 기다릴 수 있기 때문에 모든 서비스 주석에서 미니언의 INPUT 체인을 업데이트하고 각 미니언에 대한 미세한 크론 작업을 상상했습니다.

여기에 문제를 일으킬 수 있는 것이 있습니까? 내가 미쳤어?

@thockin 은 나보다 더 나은 견해를 가지고 있지만 이에 대한 주석을 사용하지 않을 것입니다. 보안은 직교적이며 시스템이나 네트워크/프록시 플러그인에 따로 보관해야 한다고 생각합니다. Kubernetes가 있는 경우 etcd가 있으므로 키에 규칙 세트를 저장하고 etcdctl watch/exec로 업데이트하면 됩니다.

# while true; do etcdctl watch "/iptables/$(hostname)" && etcdctl get /iptables/$(hostname) |iptables-restore --noflush; done &
# iptables -F my-filter
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination      
# ~nwrk/go/bin/etcdctl set /iptables/$(hostname) >/dev/null <<EOF
*filter
:my-filter -
-A my-filter -j ACCEPT -s 1.2.3.4 -p tcp --dport 80
-A my-filter -j DROP -p tcp --dport 80
COMMIT
EOF
# iptables -nvL my-filter
Chain my-filter (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       1.2.3.4              0.0.0.0/0            tcp dpt:80
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80

당신이 원하는 것 같아요 #14505

2015년 10월 26일 월요일 오전 8시 53분, Ben Hundley [email protected]
썼다:

제 경우에는 NodePort 서비스별로 방화벽 규칙을 설정하는 것을 목표로 했습니다.

다른 모든 규칙에 간단한 ALLOW IP / DROP을 추가할 수 있는 것 같습니다.
INPUT 체인은 다음과 같습니다.

iptables -A INPUT -s $WHITELISTED_IP -p tcp --dport $CONTAINER_PORT -j ACCEPT
iptables -A 입력 -p tcp --dport $CONTAINER_PORT -j DROP

이 규칙을 적용하기 위해 내가 구상했던 것은 주석을 사용하는 것이었습니다.
NodePort 서비스. 주석은 화이트리스트에 있는 IP를 보유합니다.

이 규칙이 적용될 때까지 조금 기다릴 수 있기 때문에 잠시 상상했습니다.
각 미니언에 대한 cron 작업을 통해 미니언의 INPUT 업데이트
모든 서비스 주석에서 체인.

여기에 문제를 일으킬 수 있는 것이 있습니까? 내가 미쳤어?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -151181267
.

이것이 로드 밸런서에 보안 그룹이 연결된 초기 접근 방식이었습니다. AWS에서 네트워크 인터페이스당 리스너 한도에 매우 빠르게 도달했고, 단일 kube 클러스터에 대해 여러 SG와 여러 ELB에 방화벽 규칙을 분산시키려는 털이 많은 로직에 부딪쳤습니다.

다행스럽게도 우리는 iptables를 사용하지 않는 더 나은 솔루션을 찾고 있습니다.

방금 가입하셨다면 요약해 드리겠습니다. 클라이언트 IP를 가져올 수 없음과 관련된 모든 문제가 이 문제에 병합되었지만 제안된(및 구현된) 솔루션으로는 해결되지 않습니다. 현재 클라이언트의 IP에 액세스할 수 있는 방법이 없습니다. 하아.

@shaylev2 현재 클라우드 LB를 통해 nodePort로 수신 거부하는 동안 클라이언트 IP를 얻는 좋은 방법이 없습니다. 클라우드 LB가 따라잡으면 바로 실행하겠습니다. 그러나 이것은 클러스터 내에서 클라이언트 IP를 보존합니다.

그러나 이것은 클러스터 내에서 클라이언트 IP를 보존합니다.

이는 클러스터 네트워킹이 설정되는 방식에 따라 다릅니다. 예를 들어, iptables 규칙이 OVS 내부 트래픽에서 실행되지 않기 때문에 현재 OpenShift에서는 제대로 작동하지 않습니다. 따라서 패킷은 서비스 끝점으로 이동하는 DNAT'를 받지만 소스 IP가 클러스터 내부이므로 응답이 OVS 내에 유지되므로 iptables에 다시 도달하지 않으므로 DNAT'가 되돌려지지 않습니다. 따라서 클라이언트 포드는 패킷을 인식하지 못합니다. 현재 이 문제에 대한 가장 간단한 해결 방법은 끝점으로 들어가는 패킷을 완전히 가장하여 나가는 도중에 OVS에서 다시 바운스되도록 하는 것입니다. (이 문제를 해결할 방법을 찾고 있습니다.)

OVS에는 내부적으로 VIP 개념이 있습니까? 당신은 그냥 제거할 수 있습니다
kube-proxy(오픈콘트레일 참조)

2015년 11월 20일 금요일 오전 7:09, Dan Winship [email protected]
썼다:

그러나 이것은 클러스터 내에서 클라이언트 IP를 보존합니다.

이는 클러스터 네트워킹이 설정되는 방식에 따라 다릅니다. 예를 들어, 그렇지 않습니다
iptables 규칙이 실행되지 않기 때문에 현재 OpenShift에서 바로 작동합니다.
OVS 내부 트래픽에서. 따라서 패킷은 서비스에 들어가는 DNAT를 얻습니다.
끝점이지만 소스 IP가 클러스터 내부이므로 응답은
OVS 내에 머무르므로 iptables를 다시 치지 않으므로 DNAT'ing이 발생하지 않습니다.
반대로 되어 클라이언트 포드가 패킷을 인식하지 못합니다. 에서
순간, 이것에 대한 가장 간단한 해결 방법은 패킷을 완전히 가장하는 것입니다.
끝점으로 이동하여 OVS에서 다시 튀어 나오도록
나가는 길. (이 문제를 해결할 방법을 찾고 있습니다.)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -158426296
.

우리는 본질적으로 OVS 내에서 순수 iptables-proxying과 완전히 동등한 작업을 수행하는 것에 대해 이야기했지만, 이를 위해서는 OVS conntrack 지원이 필요합니다. 여기에는 우리가 아직 의존하고 싶지 않은 최신 커널이 필요합니다. 그것은 아마도 장기적인 계획일 것입니다.

(현재로서는 컨테이너 인터페이스에서 오는 알려진 서비스 끝점과 일치하는 소스 IP+포트가 있는 패킷에 대해 OVS에서 불필요한 추가 홉을 추가하여 작동하게 할 수 있는 것처럼 보입니다. 그러면 노드가 DNAT를 해제할 수 있습니다. , 그런 다음 클라이언트 포드에 올바르게 다시 전달할 수 있는 OVS로 다시 바운스합니다.)

서비스 VIP 추상화에 대한 문서를 작성하고 만들고 싶습니다.
대체할 수 있는 추상화라는 점을 분명히 합니다.
경우).

2015년 11월 23일 월요일 오전 6시 54분, Dan Winship [email protected]
썼다:

우리는 본질적으로 다음과 같은 일을 하는 것에 대해 이야기했습니다.
pure-iptables-proxying은 완전히 OVS 내부에서 수행되지만 OVS conntrack이 필요합니다.
우리가 의존하고 싶지 않은 최신 커널이 필요한 지원
아직. 그것은 아마도 장기적인 계획일 것입니다.

(지금은 무료 추가 기능을 추가하여 작동하게 할 수 있는 것 같습니다.
알려진 서비스와 일치하는 소스 IP+포트가 있는 패킷에 대해 OVS에서 홉 아웃
컨테이너 인터페이스에서 오는 끝점; 그러면 노드는
아마도 DNAT를 해제한 다음 얻을 수 있는 OVS로 다시 바운스합니다.
클라이언트 포드에 올바르게 다시 전달됩니다.)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -158959014
.

iptables/nftables가 TCP 및 UDP 로드 밸런싱 사용 사례를 모두 해결할 수 있지만, 저는 개인적으로 IPVS https://github.com/kubernetes/kubernetes/issues/17470 이 로드 밸런싱을 위해 특별히 제작되었기 때문에 훨씬 더 적합할 것이라고 생각합니다. (읽기: k8s 팀을 위한 덜 지속적인 변경/유지 관리), 더 풍부한 로드 밸런싱 알고리즘 세트를 제공하고, 거의 라인 속도의 속도로 안정성이 입증되었으며, amd는 규칙을 조작할 준비가 된 golang 라이브러리도 보유하고 있습니다.

@thockin , 기타 https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158 에 따라 주석을 달았지만 올바르게 언급했듯이 외부 클라이언트 IP는 여전히 컨테이너에 있는 앱에서 볼 수 없습니다. .

이를 달성하는 방법 즉, 외부 클라이언트 IP를 얻는 방법은 무엇입니까? 내 설정에는 외부 LB가 없고 서비스가 노드 포트로 노출되고 클라이언트가 컨테이너화된 애플리케이션에 대한 일반 TCP(http/Websocket 아님) 연결을 만들고 있습니다.

@ashishvyas 실행 중인 kube-proxy 버전은 무엇입니까?

v1.1.3을 실행 중입니다.

https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584 및 https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158의 지침을 따르되 이라는 주석을 사용하는 대신 net.beta.kubernetes.io/proxy-mode , net.experimental.kubernetes.io/proxy-mode 라는 주석을 사용합니다.

for node in $(kubectl get nodes -o name); do
  kubectl annotate $node net.experimental.kubernetes.io/proxy-mode=iptables;
done

'Found Experimental annotation' 및 'Annotation 허용 iptables 프록시'와 같은 kube-proxy 시작 시작 부분에 로그 문이 표시되어야 합니다.

https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16이 만든 첫 번째 릴리스는 1.1.4이므로 net.beta.kubernetes.io/proxy-mode 가 많은 사람들에게 작동하지 않습니다. 당신은 이 일을 처음 겪는 사람이 아닙니다.

프록시가 작동하는 방식으로 인해 클라이언트 IP가 통과할 때 손실됩니다.
노드 포트. 나는 이것이 좋지 않다는 것을 알고 있습니다. 어떻게 해야할지 매우 마음에 든다
이 문제를 올바르게 수정하지만 대부분
로드 밸런서(또는 트래픽이 노드에 도달하는 다른 방법,
DNS-RR로)

2016년 1월 13일 수요일 오전 10시 25분, Mike Danese [email protected]
썼다:

#3760(댓글)의 지침을 따르세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -143280584
및 #3760(댓글)
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -150743158
그러나 이름이 지정된 주석을 사용하는 대신
net.beta.kubernetes.io/proxy-mode, 명명된 주석 사용
net.experimental.kubernetes.io/proxy-mode.

$(kubectl get nodes -o name)의 노드에 대해; ~하다
kubectl 주석 $node net.experimental.kubernetes.io/proxy-mode=iptables;
완료

kube-proxy 시작이 시작될 때 로그 문이 표시되어야 합니다.
'실험적 주석 발견' 및 '주석에서 iptables 프록시 허용'과 같은

da9a9a9의 첫 번째 릴리스
https://github.com/kubernetes/kubernetes/commit/da9a9a94d804c5bfdf3cc86ee76a2bc1a2742d16
1.1.4로 만들었습니다. 당신은 이 일을 처음 겪는 사람이 아닙니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171387997
.

@thockin , 일시적으로 이 문제를 해결할 수 있는 해결 방법이 지금 당장 가능합니까? 그렇다면 저와 이 스레드의 다른 사람들에게 자세한 단계를 제공하는 것이 좋습니다.

아니요, 현재로서는 실제 해결 방법이 없습니다. 문제는 다음으로 귀결된다.
각 kube-proxy가 다른 노드에서 백엔드를 선택할 수 있다는 사실.
원래 클라이언트 IP로 트래픽을 전달하면 다른 노드가 있습니다.
분명히 작동하지 않을 직접 응답합니다.

"수정"은 _only_ 서비스 S에 대한 트래픽을 다음 위치에 있는 노드로 보내는 것입니다.
S _and_에 대해 최소 1개의 백엔드가 트래픽을 얼마나 많이 전송하는지
각 노드가 가지고 있는 백엔드. 그러면 Kube-proxy가 로컬 백엔드를 선택할 수 있습니다.
독점적으로.

2개의 노드와 3개의 백엔드를 고려하십시오. 하나의 노드는 반드시 2로 끝납니다.
백엔드. 어떤 경로의 트래픽이든 하나의 노드에 2배만큼 많은 트래픽을 보내야 합니다.
다른 노드에 수행합니다. 우리는 아직 그 문제를 다루지 않았습니다.
클라우드 로드 밸런서는 이를 지원하므로 일종의 추측이고
따라서 작업을 시작하는 것은 매우 위험합니다.

2016년 1월 13일 수요일 오후 12시 17분, Ashish Vyas [email protected]
썼다:

@thockin https://github.com/thockin , 일시적인 해결 방법
지금 가능한가요? 그렇다면 제공하는 것이 좋습니다.
이 스레드의 나와 다른 사람들을 위한 자세한 단계가 도움이 될 것입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171420567
.

@mikedanese ,

$ sudo docker pull gcr.io/google_containers/ hyperkube:v1.1.4
저장소 gcr.io/google_containers/hyperkube 가져오기
gcr.io/google_containers/hyperkube 저장소에서 태그 v1.1.4를 찾을 수 없습니다.
$ sudo docker pull gcr.io/google_containers/ hyperkube:v1.1.3
v1.1.3: google_containers/hyperkube에서 가져오기
다이제스트: sha256:004dde049951a4004d99e12846e1fc7274fdc5855752d50288e3be4748778ca2
상태: gcr.io/google_containers/ hyperkube:v1.1.3의 이미지가 최신 상태입니다.

@thockin 긴 응답에 대해 사과드립니다. 다른 사람들이 우리가 직면한 문제를 이해할 수 있도록 이 문제를 해결하기 위해 시도한 두 가지 방법을 모두 다루고 싶었습니다.

약간의 배경 지식으로 우리의 주요 애플리케이션은 매우 고성능의 스마트 DNS 플랫폼(즉, UDP가 필요하고 포드당 최소 100,000개 이상의 요청/초를 수행해야 함)과 클라이언트의 실제 모습을 확인해야 하는 SNI 프록시의 지원 애플리케이션입니다. IP 주소(이것은 우리를 위한 쇼 스토퍼입니다). 우리는 다른 응용 프로그램에 대해 다른 네트워킹 접근 방식을 사용하고 싶지 않았기 때문에 모두를 위한 단일 네트워크 방법으로 표준화하기로 결정했으며 위에서 언급한 이유(성능/안정성/유연성/목적 빌드 SLB) 때문에 IPVS를 사용하기로 결정했습니다. , 하지만 같은 줄을 따라 iptables만 사용하여 무언가를 함께 해킹할 수도 있습니다. 우리는 vxlan(빠르고, 쉽고, 사이트 간 작동)을 사용하지만 이 두 가지 방법 모두 OVS가 있는 GRE/VXLAN 또는 표준 레이어 2 호스트 네트워킹에서도 작동해야 합니다(호스트가 모두 동일한 L2 네트워크에 있다고 가정).

장애 조치 속도 요구 사항 또는 특정 유형의 서비스에 가장 적합한 항목에 따라 애니캐스트와 DNS를 혼합하여 들어오는 최종 사용자 트래픽을 분산하므로 노드로 들어오는 최종 사용자 트래픽이 상당히 고르게 분포되지만 지적한 대로 문제는 포드 위치에 관계없이 포드 간에 트래픽이 고르게 분산되는 것입니다. 다른 문제는 다른 서비스와 통신하는 서비스가 효과적으로 로드 밸런싱되는지 확인하는 것입니다.

우리는 이 문제를 해결하기 위해 두 가지 모델을 시도했습니다.

우리가 시도한 첫 번째 방법은 VIP의 2 레이어였습니다. 노드에 트래픽을 분산하는 외부 VIP(서비스당 1개)(노드의 해당 서비스에 대한 포드 수를 기반으로 함) 및 노드 내에서 로드를 분산하는 내부 VIP(포드가 있는 노드에서 실행)(일반적으로 포드에 고르게). 이 모델의 한계는 외부 VIP를 실행하는 노드가 두 개의 서로 다른 네트워크 네임스페이스를 실행하거나 자체 물리적 노드를 실행해야 한다는 것이었습니다. DSR 모드(직접 서버 반환) 모드에서 IPVS의 좋은 점은 반환 트래픽을 볼 필요가 없으며 트래픽은 다음과 같이 진행된다는 것입니다.

Consumer >> (over L3) >> External VIP node >> (1) >> Internal VIP node >> (2) >> Container >> (any which way you want) >> Consumer

(1) 외부 VIP가 있는 호스트의 IPVS(DSR 모드)는 트래픽을 보낼 _node_를 선택하고(IPVS 용어로 "실제 서버") 패킷의 DST MAC 주소만 변경합니다(즉, IP 패킷은 k8s 노드). 노드에서 해당 서비스를 실행하는 포드 수를 기반으로 노드 간에 로드 밸런싱합니다.
(2) k8s 노드의 IPVS(DSR 모드에서도)는 포드 간에 트래픽을 로드 밸런싱합니다(노드에 대한 veth를 통해). 컨테이너(TCP 및 UDP)의 응답은 서비스 소비자에게 직접 전달됩니다.

이 모델의 장점은 실행이 정말 간단하고 규칙 집합이 관리하기가 매우 쉽다는 것입니다. 이 모델의 단점은 외부 VIP를 실행하는 여러 노드를 통해 모든 서비스 요청(응답 제외)을 집중한다는 것입니다. 우리는 "shared-nothing"을 좋아하므로 버전 2를 입력합니다.

두 번째 모델은 이제 더 스마트한 IPVS 및 iptables 구성이 포함된 VIP의 단일 계층입니다.

Consumer >> Any node/local node >> (1) >> Container >> (any which way you want) >> Consumer
또는 다른 노드로 이동할 수 있습니다.
Consumer >> Any node/local node >> (1) >> Remote Node >> (2) >> Container >> (any which way you want) >> Consumer

(1) 트래픽이 기본 VIP에 도달하면 트래픽이 클러스터의 모든 포드에서 로드 밸런싱됩니다.
(2) 트래픽이 보조 VIP에 도달하면 트래픽은 모든 로컬 포드에서만 로드 밸런싱됩니다. 이 보조 VIP는 네트워크의 다른 호스트(FWMARK VIP)에서 들어오는 트래픽에만 사용됩니다. 외부 인터페이스로 들어오는 트래픽을 FWMARK=1234로 표시하면 트래픽이 강제로 다른 규칙 집합으로 이동하여 노드 간의 루프가 방지됩니다.

기본 VIP에는 로컬 포드 및 포드가 있는 원격 호스트 목록이 있습니다(가중치는 각 로컬 포드에 대해 100이고 100 * 원격 노드에 대해 포드 수). 예를 들어 3개의 포드가 nodeA에서 로컬로 실행되고 있고 2개의 포드가 nodeB에서 실행 중인 경우 nodeA의 규칙 집합은 다음과 같습니다.

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> interfaceip.of.nodeB:80 Route 200 0 0
FWM 1234 rr
-> pod1.on.nodeA.ip:80 Route 100 0 0
-> pod2.on.nodeA.ip:80 Route 100 0 0
-> pod3.on.nodeA.ip:80 Route 100 0 0

그러나 nodeB에서 IPVS 구성은 nodeA에 2개의 로컬 포드와 3개의 원격 포드만 있기 때문에 약간 다르게 보일 것입니다.

Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP service.ip.address:0 rr persistent 360
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0
-> interfaceip.of.nodeA:80 Route 300 0 0
FWM 1234 rr
-> pod1.on.nodeB.ip:80 Route 100 0 0
-> pod2.on.nodeB.ip:80 Route 100 0 0

또 다른 방법은 FWMARK를 전환하고 iptables를 사용하여 veth+ 인터페이스(와일드카드 일치)의 모든 항목을 FWMARK하고 FWMARK 일치가 로컬 로드 밸런싱에만 사용되도록 하는 것입니다.

여기에 관련된 NAT가 없기 때문에 각 포드를 시작할 때 환경의 SVC_XXX_YYY IP를 루프백 또는 더미 인터페이스에 추가해야 하지만 IPVS VIP도 DNAT를 수행하도록 변경할 수도 있습니다. 작동하지 않는 이유.

최종 결과는 요청 처리/라우팅을 중앙 집중화할 필요가 없는 가장 직접적인 네트워킹이므로 훨씬 더 잘 확장됩니다. 단점은 IPVS 규칙을 생성할 때 몇 가지 추가적인 영리함입니다. 우리는 이 모든 작업을 수행하기 위해 작은 (golang) 데몬을 사용하지만 시간이 있고 관심이 충분하다면 이를 위한 k8s 모듈을 작성하는 것을 고려할 것입니다.

나는 이 문제를 늦게 다루었고 아마도 전체 흔적을 충분히 자세히 읽지 않았을 것입니다. 그러나 도움이 되는 경우를 대비하여: 위의 @qoke 의 게시물을 이해

@lxpollitt 맞습니다. IPVS를 사용할 때 소스 IP가 유지 관리되지만 이 방법을 사용하면 IPVS 구성이 kube-proxy에서 지원되지 않기 때문에 거의 모든 네트워킹을 직접 해야 한다는 점을 명심하십시오. iptables를 사용하여 소스 IP를 유지할 수도 있지만 돌아오는 길에 트래픽을 "un-nat"할 수 있도록 두 개의 IPtables DNAT 레이어가 필요합니다.

내 측면에서, 내 컨테이너 네트워크를 관리하는 flannel(vxlan 모드에서)과 함께, 내 라우팅 노드의 네임스페이스에서 kube-proxy(iptables 모드에서, 매스커레이딩이 아님) + flannel을 사용합니다. 외부 요청은 서비스 IP로 DNATed된 다음 kube-proxy와 함께 네임스페이스를 통해 전달됩니다. 활성/활성 라우터 클러스터 테스트를 수행하지 않았지만 이 설정을 통해 외부 IP를 유지할 수 있습니다. FWIW에서 언급했지만 "가장 직접적인 네트워킹"이 아니라는 것을 이해합니다.

kube-proxy가 관리할 수 있다면 좋겠지만 특정 요구 사항과 특히 로드 밸런싱이 이미 kube-proxy 외부에 있다는 사실을 감안할 때 고객 iptables-rules 관리자를 코딩하는 것이 합리적이지 않을까요? kubernetes 클러스터 상태를 보고 실행 중인 호스트의 포드에만 DNAT VIP에 대한 규칙을 설정합니까? 이것은 kube-proxy를 위한 모드일 수도 있지만, 예를 들어... 음.. 이름을 잘 몰라요... --proxy-mode=iptables-to-node-pods-only.

자세한 작성 감사합니다. 귀하의 솔루션은 흥미롭고 저는
오늘 그것에 대해 생각하는 좋은 시간. 불행히도 당신은
일반적인 의미에서 작동하지 않는 매우 특정한 영역으로 넘어갔습니다.
GCE와 같은 클라우드는 라우팅되기 때문에 IPVS 게이트웨이 모드를 사용할 수 없습니다.
회로망. 게이트웨이가 작동하더라도 포트 재매핑을 지원하지 않으며,
Kubernetes가 수행하므로 서비스 포트 == 대상인 경우에만 적용됩니다.
포트.

쿠버네티스의 핵심 과제는 여러분의
일반적으로 상황의 종류 또는 당신의 방식에서 벗어나 당신에게 권한을 부여
스스로 설정하십시오. 아마도 우리는 ipvs encap 모드로 뭔가를 할 수 있을 것입니다.
그러나 나는 그것의 성능적 의미를 모릅니다.

2016년 1월 14일 목요일 오전 3시 37분에 qoke [email protected]에서 다음과 같이 썼습니다.

@thockin https://github.com/thockin 긴 응답에 대해 사과드립니다.
다른 사람들이 할 수 있도록 이 문제를 해결하기 위해 시도한 두 가지 방법을 모두 다루고 싶었습니다.
두 가지 모두에 직면한 문제를 이해합니다.

약간의 배경지식으로 우리의 주요 응용 프로그램은 매우 고성능입니다.
스마트 DNS 플랫폼(즉, UDP가 필요하고 최소 100k+
포드당 요청/초) 및 SNI 프록시의 지원 애플리케이션
클라이언트의 실제 IP 주소를 확인해야 하는
우리를). 서로 다른 네트워크 접근 방식을 사용하고 싶지 않았습니다.
그래서 우리는 단일 네트워크 방식으로 표준화하기로 결정했습니다.
우리는 위에서 언급한 이유로 IPVS를 사용하기로 결정했습니다.
(성능/안정성/유연성/용도 빌드 SLB)
아마도 이 같은 줄을 따라 iptables를 사용하여 함께 무언가를 해킹할 것입니다.
도. 우리는 vxlan(빠르고, 쉽고, 사이트 간 작동)을 사용하지만 이 두 가지 모두
방법은 OVS 또는 표준 레이어 2가 있는 GRE/VXLAN에서도 작동해야 합니다.
호스트 네트워킹도 가능합니다(호스트가 모두 동일한 L2 네트워크에 있다고 가정).

애니캐스트와
장애 조치 속도 요구 사항 또는 가장 잘 작동하는 항목에 따라 DNS
특정 유형의 서비스를 제공하므로
노드로 들어오는 최종 사용자 트래픽이 있지만 문제는 지적하신 대로
그러면 팟(Pod) 간에 트래픽이 고르게 분포됩니다.
포드 위치. 다른 문제는 서비스가 다른
서비스는 효과적으로 로드 밸런싱됩니다.

우리는 이 문제를 해결하기 위해 두 가지 모델을 시도했습니다.

우리가 시도한 첫 번째 방법은 VIP의 2 레이어였습니다. 외부 VIP(당 1명
노드 간에 트래픽을 분산하는 서비스)
노드의 해당 서비스), 내부 VIP(노드에서 실행되는)
노드 내에서 부하를 분산(일반적으로 균등하게
포드에 걸쳐). 이 모델의 한계는 외부에서 실행되는 노드가
두 개의 서로 다른 네트워크 네임스페이스를 실행하거나 자체적으로 실행하는 데 필요한 VIP
물리적 노드. DSR 모드에서 IPVS의 좋은 점(직접 서버 반환)
모드는 반환 트래픽을 볼 필요가 없다는 것입니다. 트래픽은 다음과 같습니다.

소비자 >> (L3 이상) >> 외부 VIP 노드 >> (1) >> 내부 VIP 노드 >>
(2) >> 컨테이너 >> (원하는 방식으로) >> 소비자

(1) 외부 VIP가 있는 호스트의 IPVS(DSR 모드)는 _node_를 선택하여
(IPVS 용어로 "실제 서버")로 트래픽을 보내고 DST MAC만 변경
패킷의 주소(즉, IP 패킷은 변경되지 않고 k8s 노드에 도착함). 그것은로드
해당 서비스를 실행하는 포드 수를 기반으로 노드 간에 균형을 유지합니다.
노드.
(2) k8s 노드의 IPVS(DSR 모드에서도)는 트래픽을 로드 밸런싱합니다.
포드(노드에 대한 veth를 통해). 컨테이너(TCP 및 UDP)의 응답 이동
서비스 소비자에게 직접 돌아갑니다.

이 모델의 장점은 시작하기가 정말 간단하고
규칙 세트는 관리하기가 매우 쉬웠습니다. 이 모델의 단점은
를 통해 모든 서비스 요청(회신 제외)을 집중합니다.
외부 VIP를 실행하는 노드의 수입니다. 우리는 "비공유"를 좋아하므로,
버전 2 입력:

두 번째 모델은 이제 재미 있는 단일 계층의 VIP입니다.
더 똑똑한 IPVS 및 iptables 구성.

소비자 >> 모든 노드/로컬 노드 >> (1) >> 컨테이너 >> (어떤 방식으로든
원) >> 소비자
또는 다른 노드로 이동할 수 있습니다.
소비자 >> 모든 노드/로컬 노드 >> (1) >> 원격 노드 >> (2) >> 컨테이너

(원하는 방식으로) >> 소비자

(1) 트래픽이 기본 VIP에 도달하면 트래픽이 모든 포드에 걸쳐 로드 밸런싱됩니다.
클러스터.
(2) 트래픽이 2차 VIP에 도달하면 트래픽은 모든 트래픽에 대해서만 로드 밸런싱됩니다.
로컬 포드. 이 보조 VIP는 다음에서 들어오는 트래픽에만 사용됩니다.
네트워크의 다른 호스트(FWMARK VIP). 우리는 들어오는 트래픽을 표시합니다
FWMARK=1234인 모든 외부 인터페이스 및 트래픽을 강제로 이동
노드 간의 루프를 방지하는 다른 규칙 집합으로

기본 VIP에는 로컬 포드 및 포드가 있는 원격 호스트 목록이 있습니다(
가중치는 각 로컬 포드에 대해 100이고 100 * 포드 수입니다.
원격 노드). 예를 들어 3개의 포드가 nodeA에서 로컬로 실행되고 있고
nodeB에서 실행 중인 두 개의 포드가 있으며 nodeA의 규칙 집합은 다음과 같습니다.
이것:

Prot LocalAddress:포트 스케줄러 플래그
-> RemoteAddress: 포트 포워드 가중치 ActiveConn InActConn
TCP service.ip.address:0 rr 영구 360
-> pod1.on.nodeA.ip:80 경로 100 0 0
-> pod2.on.nodeA.ip:80 경로 100 0 0
-> pod2.on.nodeA.ip:80 경로 100 0 0
-> interfaceip.of.nodeB:80 경로 200 0 0
FWM 1234 rr
-> pod1.on.nodeA.ip:80 경로 100 0 0
-> pod2.on.nodeA.ip:80 경로 100 0 0
-> pod3.on.nodeA.ip:80 경로 100 0 0

그러나 nodeB에서는 IPVS 구성이 약간 다르게 보일 것입니다.
nodeA에는 2개의 로컬 포드와 3개의 원격 포드만 있습니다.

Prot LocalAddress: 포트 스케줄러 플래그
-> RemoteAddress: 포트 포워드 가중치 ActiveConn InActConn
TCP service.ip.address:0 rr 영구 360
-> pod1.on.nodeB.ip:80 경로 100 0 0
-> pod2.on.nodeB.ip:80 경로 100 0 0
-> interfaceip.of.nodeA:80 루트 300 0 0
FWM 1234 rr
-> pod1.on.nodeB.ip:80 경로 100 0 0
-> pod2.on.nodeB.ip:80 경로 100 0 0

또 다른 방법은 FWMARK를 전환하고 iptables를 사용하여
veth+ 인터페이스(와일드카드 일치)의 모든 항목을 FWMARK하고 FWMARK
로컬 로드 밸런싱에만 사용되는 match.

최종 결과는 중앙 집중화할 필요가 없는 가장 직접적인 네트워킹입니다.
요청 처리/라우팅이 훨씬 더 잘 확장됩니다. 단점은 좀
IPVS 규칙을 생성할 때 추가 스마트.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171619663
.

iptables-to-node-pods-only 모드를 시도해 보면 재미있을 것 같습니다.
그러나 그것은 많은 파문을 가지고 있습니다. 불균형의 가능성은 매우 현실적이며
최소한 서비스 컨트롤러는 프로그래밍 방법을 알아야 합니다.
외부 로드 밸런서.

2016년 1월 14일 목요일 오후 3시 59분, Mikaël Cluseau [email protected]
썼다:

내 측면에서 내 컨테이너 네트워크를 관리하는 flannel(vxlan 모드에서)을 사용하여
kube-proxy(iptables 모드 및 masquerading 아님) + flannel 사용
내 라우팅 노드의 네임스페이스 외부 요청은 서비스를 위해 DNATed됩니다.
kube-proxy를 사용하여 네임스페이스를 통해 IP를 전달합니다. 나는하지 않았다
활성/활성 라우터 클러스터 테스트를 완료했지만 이 설정을 통해
외부 IP. 나는 그것을 FWIW에서 언급하지만 그것이 "가장
직접 네트워킹".

kube-proxy가 관리할 수 있다면 좋겠지만
특정 요구 사항과 특히 로드 밸런싱이
이미 kube-proxy 외부에 있습니다. 고객을 코딩하는 것이 합리적이지 않습니까?
kubernetes 클러스터 상태를 보고 설정하는 iptables-rules 관리자
실행 중인 호스트의 포드에만 DNAT VIP에 대한 규칙이 있습니까? 이럴수있다
kube-proxy의 모드이기도 하지만... 글쎄요.
이름... --proxy-mode=iptables-to-node-pods-only.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -171821603
.

@thockin 예를 들어 2개의 복제본이 동일한 노드에 있는 경우를 의미합니까? 여러 인스턴스가 있고 외부 LB 프로그래머는 아마도 "단일 마스터" 모드에 있어야 하기 때문에 "외부 로드 밸런서 프로그래밍" 사례를 kube-proxy의 범위 밖에 둘 수 있다고 생각합니다. 따라서 kube-proxy 모드 "iptables-to-node-pods-only"를 허용하는 것은 2단계 프로세스 중 첫 번째 단계일 뿐입니다.

내일은 kube-proxy의 "iptables-to-node-pods-only" 모드와 서비스당 하나의 경로로 Linux 라우팅 테이블을 유지 관리하는 contrib/ip-route-elb와 같은 것을 구현하려고 할 수 있다고 생각합니다. , 주어진 서비스에 대해 노드가 보유한 엔드포인트 수를 기반으로 각 노드에 대한 올바른 가중치를 사용합니다.

@thockin 예를 들어 2개의 복제본이 동일한 노드에 있다는 것을 의미합니까? 나는 우리가 "프로그램
여러 인스턴스와 외부 LB가 있으므로 kube-proxy의 범위를 벗어난 외부 로드 밸런서"
프로그래머는 아마도 "단일 마스터" 모드에 있어야 합니다. 따라서 kube-proxy 모드 "iptables-to-node-
pods-only'는 2단계 프로세스 중 첫 번째 단계일 뿐입니다.

"로컬 포드에 대한 프록시만"은 프로세스의 2단계여야 합니다. 1 단계
로드 밸런서만 보내도록 서비스 컨트롤러를 변경해야 합니다.
주어진 서비스에 대해 1개 이상의 백엔드가 있는 노드에. 그 단계
그것만으로도 충분히 합리적이지만, 많은 테스트가 필요합니다.
올바른지 확인하십시오. 나는 우리가 결국 이것을 하고 싶다고 생각한다.
그래도.

완료되면 노드 포트가 로컬을 선호하도록 하는 것에 대해 이야기할 수 있습니다.
가능하면 백엔드를 사용하지만 이 단계에서는 훨씬 더 주의가 필요합니다.
생각.. 그게 _항상_을 의미합니까? (즉, 리모콘을 선택하지
백엔드를 사용할 수 있는 경우) 또는 확률적입니까? 우리는해야합니까
동일한 노드 포트를 통해(다른 노드는 매우
다른 동작) 또는 사용되는 다른 포트를 할당합니까?
이 노드에 1개 이상의 백엔드가 있는 경우에만? 우리는 어떻게 처리합니까
불균형 문제?

나는 내일 kube-proxy에서 "iptables-to-node-pods-only" 모드와 같은 것을 구현하려고 시도할 수 있다고 생각합니다.
또한 적절한 가중치로 서비스당 하나의 경로로 Linux 라우팅 테이블을 유지하는 contrib/ip-route-elb
노드가 주어진 서비스에 대해 얼마나 많은 엔드포인트를 가지고 있는지를 기반으로 각 노드에 대해.

ELB가 가중치를 지원하면
GCE는 그렇지 않습니다. 그렇군요 지원안되는줄 알았는데
무게. 나는 그것이 기여할 수 있다고 생각하지 않습니다.
시스템의 기본적인 부분.

2016년 1월 16일 오전 5시 19분에 Tim Hockin은 다음과 같이 썼습니다.

"로컬 포드에 대한 프록시만"은 프로세스의 2단계여야 합니다. 1 단계
로드 밸런서만 보내도록 서비스 컨트롤러를 변경해야 합니다.
주어진 서비스에 대해 1개 이상의 백엔드가 있는 노드에. 그 단계
그것만으로도 충분히 합리적이지만, 많은 테스트가 필요합니다.
올바른지 확인하십시오. 나는 우리가 결국 이것을 하고 싶다고 생각한다.
그래도.

그것은 의미가 있습니다.

일단 완료되면 [...]

그럼 완성된 모습을 한번 보실까요 :-)

ELB가 가중치를 지원하면
GCE는 그렇지 않습니다. 그렇군요 지원안되는줄 알았는데
무게.

매뉴얼에서 나온 것이기 때문에 아마도 내 10배 이상을 가지고 있을 것입니다.
이런 종류의 네트워킹 경험이 있는 경우 캐치를 완전히 무시해야 합니다.
남자 ip-route는 다음과 같이 말합니다.

           nexthop NEXTHOP
                  the nexthop of a multipath route.  NEXTHOP is a 

최상위 인수 목록과 유사한 자체 구문을 가진 복잡한 값:

                          via [ FAMILY ] ADDRESS - is the nexthop 

라우터.

                          dev NAME - is the output device.

                          weight NUMBER - is a weight for this 

상대 대역폭 또는 품질을 반영하는 다중 경로 경로의 요소입니다.

나는 그것이 기여할 수 있다고 생각하지 않습니다.
시스템의 기본적인 부분.

'E'는 '외부'의 약자라서 거기서 시작하는 것 같았는데,
적어도 아이디어를 지원하는 코드를 얻으려면.

2016년 1월 15일 금요일 오후 2시 55분, Mikaël Cluseau
[email protected] 은 다음과 같이 썼습니다.

2016년 1월 16일 오전 5시 19분에 Tim Hockin은 다음과 같이 썼습니다.

"로컬 포드에 대한 프록시만"은 프로세스의 2단계여야 합니다. 1 단계
로드 밸런서만 보내도록 서비스 컨트롤러를 변경해야 합니다.
주어진 서비스에 대해 1개 이상의 백엔드가 있는 노드에. 그 단계
그것만으로도 충분히 합리적이지만, 많은 테스트가 필요합니다.
올바른지 확인하십시오. 나는 우리가 결국 이것을 하고 싶다고 생각한다.
그래도.

그것은 의미가 있습니다.

나는 오늘 이것에 대해 더 많이 생각했다. 나는 그것이 별로 어렵지 않을 것이라고 생각한다.
그냥 미디엄 하드.

일단 완료되면 [...]

그럼 완성된 모습을 한번 보실까요 :-)

공정하게, 나는 일련의 변경 사항이 어디로 가는지 알고 싶습니다. :)

ELB가 가중치를 지원하면
GCE는 그렇지 않습니다. 그렇군요 지원안되는줄 알았는데
무게.

매뉴얼에서 나온 것이기 때문에 아마도 내 10배 이상을 가지고 있을 것입니다.
이런 종류의 네트워킹 경험이 있는 경우 캐치를 완전히 무시해야 합니다.
남자 ip-route는 다음과 같이 말합니다.

넥스트홉 넥스홉
다중 경로 경로의 다음 홉. 넥스탑은
최상위 인수 목록과 유사한 자체 구문을 가진 복잡한 값:

via [ FAMILY ] ADDRESS - is the nexthop
라우터.

dev NAME - 출력 장치입니다.

weight NUMBER - 이것에 대한 가중치
상대 대역폭 또는 품질을 반영하는 다중 경로 경로의 요소입니다.

우리는 실제로 리눅스의 IP 라우팅 개념을 사용하지 않습니다. 어느 것도
어쨌든 사용하는 것으로 알고 있는 LB 구현. GCE는 Google의 클라우드를 사용합니다.
무게가 없는 밸런서. 나는 아마존 ELB인지 모른다
하다.

나는 그것이 기여할 수 있다고 생각하지 않습니다.
시스템의 기본적인 부분.

'E'는 '외부'의 약자라서 거기서 시작하는 것 같았는데,
적어도 아이디어를 지원하는 코드를 얻으려면.

물론, 우리는 기여에서 시작할 수 있습니다 :)

또한 이것을 추구하려면 다음과 같은 2개의 버그를 열어야 합니다.

1) 서비스의 로드 밸런서는 실제로
해당 서비스에 대한 백엔드가 있습니다.

2) 로드 밸런서에서 클라이언트 IP를 보존하려면 kube-proxy가
존재하는 경우 항상 로컬 백엔드를 선호합니다(xref #1).

그런 다음 의도와 방향을 설명하십시오.

2016년 1월 15일 금요일 오후 5시 11분에 Tim Hockin [email protected]이 다음과 같이 썼습니다.

2016년 1월 15일 금요일 오후 2시 55분, Mikaël Cluseau
[email protected] 은 다음과 같이 썼습니다.

2016년 1월 16일 오전 5시 19분에 Tim Hockin은 다음과 같이 썼습니다.

"로컬 포드에 대한 프록시만"은 프로세스의 2단계여야 합니다. 1 단계
로드 밸런서만 보내도록 서비스 컨트롤러를 변경해야 합니다.
주어진 서비스에 대해 1개 이상의 백엔드가 있는 노드에. 그 단계
그것만으로도 충분히 합리적이지만, 많은 테스트가 필요합니다.
올바른지 확인하십시오. 나는 우리가 결국 이것을 하고 싶다고 생각한다.
그래도.

그것은 의미가 있습니다.

나는 오늘 이것에 대해 더 많이 생각했다. 나는 그것이 별로 어렵지 않을 것이라고 생각한다.
그냥 미디엄 하드.

일단 완료되면 [...]

그럼 완성된 모습을 한번 보실까요 :-)

공정하게, 나는 일련의 변경 사항이 어디로 가는지 알고 싶습니다. :)

ELB가 가중치를 지원하면
GCE는 그렇지 않습니다. 그렇군요 지원안되는줄 알았는데
무게.

매뉴얼에서 나온 것이기 때문에 아마도 내 10배 이상을 가지고 있을 것입니다.
이런 종류의 네트워킹 경험이 있는 경우 캐치를 완전히 무시해야 합니다.
남자 ip-route는 다음과 같이 말합니다.

넥스트홉 넥스홉
다중 경로 경로의 다음 홉. 넥스탑은
최상위 인수 목록과 유사한 자체 구문을 가진 복잡한 값:

via [ FAMILY ] ADDRESS - is the nexthop
라우터.

dev NAME - 출력 장치입니다.

weight NUMBER - 이것에 대한 가중치
상대 대역폭 또는 품질을 반영하는 다중 경로 경로의 요소입니다.

우리는 실제로 리눅스의 IP 라우팅 개념을 사용하지 않습니다. 어느 것도
어쨌든 사용하는 것으로 알고 있는 LB 구현. GCE는 Google의 클라우드를 사용합니다.
무게가 없는 밸런서. 나는 아마존 ELB인지 모른다
하다.

나는 그것이 기여할 수 있다고 생각하지 않습니다.
시스템의 기본적인 부분.

'E'는 '외부'의 약자라서 거기서 시작하는 것 같았는데,
적어도 아이디어를 지원하는 코드를 얻으려면.

물론, 우리는 기여에서 시작할 수 있습니다 :)

문서가 없는 PR의 위험은 잘못된 방향에 있다는 것입니다. 그것은이다
제안으로 무언가를 검토하는 것이 훨씬 쉽습니다. 나는 당신을 살펴볼 것입니다
기회가 되면 PR을 하고 싶습니다.
2016년 1월 15일 오후 7시 2분에 "Mikaël Cluseau" [email protected]이 다음과 같이 썼습니다.

이 이름과 일부를 사용하여 (1)에 대한 풀 요청을 직접 여는 것이 괜찮습니까?
설명?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172149777
.

불행히도 당신은 일반적인 의미에서 작동하지 않는 매우 특정한 영역을 넘었습니다.
GCE와 같은 클라우드는 라우팅된 네트워크 때문에 IPVS 게이트웨이 모드를 사용할 수 없습니다. 게이트웨이가 작동하더라도 Kubernetes가 지원하는 포트 재매핑을 지원하지 않으므로 서비스 포트 == 대상 포트인 경우에만 적용됩니다.

게이트웨이 측에서 이것은 레이어 3 네트워크(우리는 오버레이 사용)를 통해 잘 작동하며 오버레이 네트워크 없이는 벗어날 수 있었지만 우리가 사용하는 접근 방식이 이식 가능하고 작동하기를 원했기 때문에 이러한 방식으로 구축했습니다. 타사 클라우드(예: GCE).

DSR 모드의 제한 사항을 수정하면 서비스 포트 == 대상 포트이지만 동일한 포트에서 실행해야 하는 _동일한 컨테이너에_ 있는 두 개의 애플리케이션이 있지 않는 한 이것은 실제로 문제가 되지 않습니다. 이것은 "컨테이너당 1개의 애플리케이션" 가이드라인을 가정할 때 이에 대한 단일 사용 사례를 찾을 수 없습니다. 우리는 많은 컨테이너가 모두 동일한 노드에서 실행되고 내부에 서비스가 모두 동일한 포트에 있고 모든 로드 밸런싱이 잘 되어 있습니다. 포트를 다시 매핑해야 하는 _정말_ 필요한 경우(그 이유 뒤에 숨겨진 실제 이유를 알고 싶습니다) "ROUTE" 모드 대신 IPVS NAT 모드를 사용할 수 있습니다.

kubernetes의 핵심에 대한 도전은 일반적으로 상황을 처리하거나 방해를 받지 않고 스스로 설정할 수 있는 권한을 부여하는 방법을 찾는 것입니다. 아마도 우리는 ipvs encap 모드로 뭔가를 할 수 있을 것입니다. 그러나 나는 그것의 성능적 의미를 모릅니다.

우리가 한 일은 가능한 한 일반적으로 만들었습니다(여기서 작동하고 Amazon에서 작동하며 확장해야 할 때 GCE에서 작동할 것이라고 확신합니다). DSR의 유일한 제한은 애플리케이션 포드/컨테이너에서 실행하려면 서비스와 동일한 포트에서 실행해야 하며 많은 내부 논의 끝에 E2E 애플리케이션 스택 관점에서 이것이 제한되는 시나리오를 아무도 찾지 못했습니다.

즉, 방정식에서 DSR(IPVS 경로 모드)을 제거하고 대신 IPVS의 "NAT 모드"를 사용하면 포트를 다시 매핑할 수 있으며 여전히 IPVS 기능/성능 등의 이점을 얻을 수 있습니다. 유일한 단점은 NAT가 약간의 성능 세금을 추가하지만 (a) UDP를 지원하고 (b) 사용자 공간 솔루션에 비해 여전히 번개처럼 빠르다는 것입니다.

@brendandburns @thockin 이전 스레드에서 성능 수치를 요청했습니다. 이것을 가장 포괄적인 테스트 세트라고 부르지는 않겠지만 HTTP는 컨테이너에서 가장 일반적인 워크로드 중 하나이므로 시작점으로 몇 가지 apache-bench 숫자가 있습니다.

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

다른 두 솔루션과의 공정한 비교를 위해 IPVS에서 DNAT가 활성화되었습니다(이는 또한 서비스 포트가 대상 서비스 포트와 다를 수 있음을 의미함). 우리의 작업 부하가 일부 사람들에게는 다소 이상하게 보일 수 있지만 우리의 성능 목표는 아마도 다른 사람들과 다르지 않을 것입니다(즉, 하드웨어를 최대한 활용하여 얻을 수 있음).

감사 해요!

kube-proxy가 UDP를 수행하지 않는다는 아이디어가 어디에서 왔는지 잘 모르겠습니다.
완벽하지는 않지만 절대적으로 가능합니다(연결 없이는
시간 초과까지).

또한 iptables (new) kube-proxy와 userspace를 명확히 할 가치가 있습니다.
(레거시) 모드.

2016년 1월 16일 토요일 오후 9시 45분에 qoke [email protected]에서 다음과 같이 썼습니다.

@thockin https://github.com/thockin 이전에 요청한 스레드에서
일부 성능 수치. 나는 이것을 가장 포괄적인 세트라고 부르지 않을 것이다.
테스트 중 HTTP가 더 일반적인 워크로드 중 하나일 것으로 예상
다음은 시작점으로 몇 가지 apache-bench 번호입니다.

https://docs.google.com/presentation/d/1vv5Zszt4HDGbuyVlvOe76unHskxPuZQseQnarNbhQVc

다른 두 솔루션과의 공정한 비교를 위해 IPVS에서 DNAT가 활성화되었습니다.
(이는 또한 서비스 포트가 대상 서비스 포트와 다를 수 있음을 의미합니다). 우리의
일부 사람들에게는 워크로드가 다소 이상하게 보일 수 있지만 우리의 성능 목표는
아마도 다른 사람들과 다르지 않을 것입니다(즉, 모든 하드웨어를
얻을 수 있습니다).

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172293881
.

새로운 모드와 레거시 모드에 대한 좋은 소식 - 언급 및 업데이트되었습니다.

또한 UDP 측면에서도 설명해주셔서 감사합니다. 지금까지 UDP가 kube-proxy에서 완전히 지원되는지 몰랐습니다. UDP로 kube-proxy를 처음 시도했을 때 많은 중단이 발생했습니다. 이유는 확실하지 않지만 시간 초과를 늘렸지만 여전히 문제가 있었습니다. 우리는 솔루션을 빨리 찾아야 했기 때문에 디버깅보다는 IPVS로 문제를 해결했습니다. 당시에는 상당히 낮은 초당 패킷 워크로드(1k pps 미만)에서만 작동했지만 최근에 다시 테스트하지 않았습니다.

iptables 및 고속 UDP 서비스의 주요 문제는 netfilter conntrack 테이블이 채워지는 것입니다. conntrack 크기를 100만 개로 늘리더라도 일부 맬웨어에 감염된 최종 사용자 DDoS가 사용자이거나 사용자를 DNS 증폭 공격에 사용하려고 시도하면 conntrack 테이블이 다시 채워집니다. 일반적으로 DNS 서버(또는 모든 고속 UDP 서비스)에 대한 모범 사례는 conntrack을 비활성화하는 것입니다(원시 테이블에서 -j NOTRACK 사용). conntrack을 비활성화하면 iptables NAT 및 상태 저장 항목(-m state)이 중단됩니다.

GIT 리포지토리 외에 "k8s.io/kubernetes/pkg/proxy/ipvs" 모듈/패키지를 만들기 전에 어디를 살펴보는 것이 가장 좋을까요? 아니면 코드 기반을 더 잘 아는 사람에게 이것이 최선입니까?

또한 특정 벤치마크를 실행하고 싶다면 알려주시면 제가 무엇을 할 수 있는지 알아보겠습니다.

2016년 1월 17일 오후 8시 50분에 qoke는 다음과 같이 썼습니다.

GIT repo를 제외하고 가장 먼저 살펴볼 곳은 어디입니까?
"k8s.io/kubernetes/pkg/proxy/ipvs" 모듈/패키지를 생성하려고 합니까?

나는 당신도 기여에서 시작할 수 있다고 믿습니다.

FWIW... 목록 시계와 언델타 스토어를 사용하여 독립
클러스터의 상태에 반응하는 Binay
https://github.com/kubernetes/kubernetes/pull/19755. 만약 정보가
~에
https://github.com/kubernetes/kubernetes/pull/19755/files#diff -0becc97ac222c3f2838fbfe8446d5375R26
충분합니다. 아래의 몇 줄만 호출하면 됩니다.
(https://github.com/kubernetes/kubernetes/pull/19755/files#diff-0becc97ac222c3f2838fbfe8446d5375R44).

이 PoC에서는 clusterIP 서비스만 지원합니다.

불행히도 당신은 일반적인 의미에서 작동하지 않는 매우 특정한 영역을 넘었습니다.
GCE와 같은 클라우드는 라우팅된 네트워크 때문에 IPVS 게이트웨이 모드를 사용할 수 없습니다. 게이트웨이가 작동하더라도
Kubernetes가 수행하는 포트 재매핑을 지원하므로 서비스 포트 == 대상 포트인 경우에만 적용됩니다.

게이트웨이 측에서 이것은 레이어 3 네트워크(우리는 오버레이 사용)를 통해 잘 작동하며
오버레이 네트워크 없이, 우리는 우리가 사용하는 접근 방식을 이식 가능하고 타사에서 작동하기를 원했기 때문에 이 방식으로 구축했습니다.
클라우드(예: GCE).

어떻게 작동하는지 잘 모르겠습니다. 시스템 수준의 정적 경로가 작동하지 않음
GCE에서. 어쩌면 나는 당신이 적용한 몇 가지 기술을 놓치고 있습니다. NS
나는 이것의 전문가가 아님을 자유롭게 인정하십시오 :)

서비스 포트 == 대상 포트라는 제한을 수정하지만 두 개의 애플리케이션이 있는 경우가 아니면 실제로 문제가 되지 않습니다.
동일한 포트에서 실행해야 하는 동일한 컨테이너(우리는 이에 대해 많은 시간을 생각하고 "1 애플리케이션
컨테이너당" 지침에 따르면 이에 대한 단일 사용 사례를 찾을 수 없습니다. 동일한 노드에서 모두 실행되는 많은 컨테이너가 있습니다.
내부 서비스가 모두 동일한 포트에 있고 모든 부하가 잘 분산됩니다. 요컨대, 우리가 사용하는 접근 방식은 당신을 멈추지 않습니다
동일한 노드의 동일한 포트에서 여러 서비스를 실행하지 못하도록 합니다.

버전을 변경하는 백엔드가 있는 경우에도 적용됩니다(예:
etcd1과 etcd2 사이의 전환) 또는 다음과 같은 기타 상황
백엔드 포트만 달라야 합니다. 문제는 그
Kubernetes는 이를 표현할 수 있으므로 사람들이
실제로 사용할 수 있습니다(또는 더 이상 사용되지 않으며
가능성은 낮아 보입니다).

kubernetes의 핵심에 대한 도전은 일반적으로 상황을 처리하거나 방해가 되지 않는 방법을 찾는 것입니다.
스스로 설정할 수 있도록 권한을 부여합니다. ipvs encap 모드로 뭔가를 할 수 있을지도 모르지만 성능은 모르겠습니다
그것의 의미.

우리가 한 일은 가능한 한 일반적으로 만들었습니다(여기서 작동하고 Amazon에서 작동하며 다음에서 작동할 것이라고 확신합니다.
확장해야 할 때 GCE), 포드/컨테이너에서 실행되는 애플리케이션이 > 서비스와 동일한 포트에서 실행되어야 하는 유일한 제한 사항은 많은 내부 논의 끝에 아무도 찾을 수 없었습니다. 시나리오
이것은 E2E 애플리케이션 스택 관점에서 제한적일 것입니다.

나는 정말로 어떻게 이해하고 싶다. 더 단계적으로 뭔가가 있습니까?

또한 UDP 측면에서도 설명해주셔서 감사합니다. 지금까지 UDP가 kube-proxy에서 완전히 지원되는지 몰랐습니다.
UDP로 kube-proxy를 처음 시도했을 때 많은 중단이 발생했습니다. 이유는 확실하지 않지만 시간 초과를 늘렸고
여전히 문제가 있었습니다. 우리는 솔루션을 빨리 찾아야 했기 때문에 디버깅보다는 IPVS로 문제를 해결했습니다. 에서
매우 낮은 초당 패킷 워크로드(1k pps 미만)에서만 작동했지만 최근에 다시 테스트하지 않았습니다.

iptables 및 고속 UDP 서비스의 주요 문제는 netfilter conntrack 테이블이 채워지는 것입니다. 증가시켜도
규모를 100만까지 추적한 다음 일부 맬웨어에 감염된 최종 사용자 DDoS가 귀하를 공격하거나 DNS 증폭에 귀하를 사용하려고 시도합니다.
공격하면 conntrack 테이블이 다시 채워집니다. 일반적으로 말해서 DNS 서버(또는 모든 고속
UDP 서비스)는 conntrack(원시 테이블에서 -j NOTRACK 사용)을 비활성화하고 conntrack을 비활성화하면 iptables NAT 및
상태 저장 항목(-m 상태)이 중단됩니다.

네, UDP용 NAT는 정말 불행합니다. non-conntrack 찾기
솔루션은 훌륭하지만 모든
환경 또는 플랫폼에 의해 매개변수화됨(자체적으로 어려운
방법).

GIT 리포지토리를 제외하고 생성을 시도하기 전에 살펴봐야 할 가장 좋은 곳은 어디입니까?
"k8s.io/kubernetes/pkg/proxy/ipvs" 모듈/패키지? 아니면 코드 기반을 더 잘 아는 사람에게 이것이 최선입니까?

IPVS에 대한 github 문제를 열었지만 가장 무도회(NAT)를 사용하고 있었습니다.
모드 없이는 GCE에서 작동하도록 할 수 없었기 때문입니다.
포트 재매핑 기능). 포트 재매핑이 덜 이상적일 경우
밸런싱 모드, 아마 그걸로 살 수 있고 그냥 문서화 할 수 있습니다.
그대로.

이 대화를 그곳으로 옮겨야 합니다. 여기서 길을 잃을 것입니다.

2016년 1월 18일 오후 12시 34분에 Tim Hockin은 다음과 같이 썼습니다.

네, UDP용 NAT는 정말 불행합니다. non-conntrack 찾기
솔루션은 훌륭하지만 모든
환경 또는 플랫폼에 의해 매개변수화됨(자체적으로 어려운
방법).

(포드, 포트) 커플이
대부분의 하나의 서비스(하나의 서비스에 여러 포드)?

이것은 다음과 같이 보일 것입니다:

{from: clientIP:clientPort, to: externalIP:externalPort} ---[proxy가 임의의 포드를 선택함]---> {from: clientIP:clientPort, to: podIP:targetPort} ---> [올바른 호스트를 통해 라우팅됨 ...]

돌아오는 길에 방화벽에는 {from:
podIP:targetPort , to: any}는 {from:
e xternalIP:externalPort , 대상: 변경되지 않음}.

iptables 방언으로 표현하려면:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in  -j DNAT -s 1.2.3.4  -p udp --dport 53 --to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53 --to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53 --to-source 1.2.3.4

패킷이 외부에서 올 때 이것이 작동하지 않는 곳을 보지 못합니다.
클러스터.

서비스가 Kubernetes에서 표현되는 방식은 단일 포드가
많은 서비스가 앞에 있으므로 이것은 분해됩니다 - 우리는 무엇을 모릅니다
SNAT에.

2016년 1월 17일 일요일 오후 6:13, Mikaël Cluseau [email protected]
썼다:

2016년 1월 18일 오후 12시 34분에 Tim Hockin은 다음과 같이 썼습니다.

네, UDP용 NAT는 정말 불행합니다. non-conntrack 찾기
솔루션은 훌륭하지만 모든
환경 또는 플랫폼에 의해 매개변수화됨(자체적으로 어려운
방법).

(포드, 포트) 커플이
대부분의 하나의 서비스(하나의 서비스에 여러 포드)?

이것은 다음과 같이 보일 것입니다:

{from: clientIP:clientPort, to: externalIP:externalPort} ---[프록시 선택
임의의 포드]---> {from: clientIP:clientPort, to: podIP:targetPort} --->
[올바른 호스트를 통해 라우팅됨...]

돌아오는 길에 방화벽에는 {from:
podIP:targetPort , to: any}는 {from:
e xternalIP:externalPort , 대상: 변경되지 않음}.

iptables 방언으로 표현하려면:

iptables -t nat -N stateless-svc-in

iptables -t nat -N stateless-svc-out

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.1.0.1 -m statistic --mode random --probability 0.3333

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.1 -m statistic --mode random --probability 0.5

iptables -t nat -A stateless-svc-in -j DNAT -s 1.2.3.4 -p udp --dport 53
--to-destination 10.2.0.2 -m statistic --mode random --probability 1

iptables -t nat -A stateless-svc-out -j SNAT -s 10.1.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.1 -p udp --sport 53
--to-source 1.2.3.4

iptables -t nat -A stateless-svc-out -j SNAT -s 10.2.0.2 -p udp --sport 53
--to-source 1.2.3.4

패킷이 외부에서 올 때 이것이 작동하지 않는 곳을 보지 못합니다.
클러스터.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172408290
.

2016년 1월 18일 오후 3시 31분에 Tim Hockin은 다음과 같이 썼습니다.

서비스가 Kubernetes에서 표현되는 방식은 단일 포드를 허용합니다.
되려고
여러 서비스가 앞에 있으므로 이것은 분해됩니다 - 우리는 모릅니다
뭐라고 요
SNAT에.

그렇기 때문에 이 경우를 다대일(제 첫 번째 문장 :-))으로 제한했습니다.
나는 단지 무엇을 할 수 있는지 여부에 대해 선을 긋고자 노력할 뿐입니다.

물론, 나는 그것이 왜 그렇지 않은지를 지적하는 불행한 일을 가지고 있습니다.
일반적으로 충분한 솔루션 :(

2016년 1월 17일 일요일 오후 8시 34분, Mikaël Cluseau [email protected]
썼다:

2016년 1월 18일 오후 3시 31분에 Tim Hockin은 다음과 같이 썼습니다.

서비스가 Kubernetes에서 표현되는 방식은 단일 포드를 허용합니다.
되려고
여러 서비스가 앞에 있으므로 이것은 분해됩니다 - 우리는 모릅니다
뭐라고 요
SNAT에.

그렇기 때문에 이 경우를 다대일(제 첫 번째 문장 :-))으로 제한했습니다.
나는 단지 무엇을 할 수 있는지 여부에 대해 선을 긋고자 노력할 뿐입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172421828
.

2016년 1월 18일 오후 3시 46분에 Tim Hockin은 다음과 같이 썼습니다.

물론, 나는 그것이 왜 그렇지 않은지를 지적하는 불행한 일을 가지고 있습니다.
일반적으로 충분한 솔루션 :(

예... 하지만 FAQ입니다. 우리는 또한 어딘가에 "if len(services)
== 1 { 상태 비저장 구현 } else { 상태 저장 구현 }". 그러나 이것은
뉴비에게는 엉망으로 보입니다. 나는 또한 기여/엘프/무언가가 될 수 있습니다...

우리가 현재 추적하고 있는 것도 아닙니다(서비스가
주어진 포드 앞에). 우리는 할 수 있다고 생각합니다. 나는 반대하지 않는다(그렇더라도
틈새). 그렇게 하기 위해 상당한 변화를 가져온 것처럼 들립니다.
많은 주의사항. 그래도 더 나은 답변을 생각하고 싶습니다.

2016년 1월 17일 일요일 오후 8시 51분, Mikaël Cluseau [email protected]
썼다:

2016년 1월 18일 오후 3시 46분에 Tim Hockin은 다음과 같이 썼습니다.

물론, 나는 그것이 왜 그렇지 않은지를 지적하는 불행한 일을 가지고 있습니다.
일반적으로 충분한 솔루션 :(

예... 하지만 FAQ입니다. 우리는 또한 어딘가에 "if len(services)
== 1 { 상태 비저장 구현 } else { 상태 저장 구현 }". 그러나 이것은
뉴비에게는 엉망으로 보입니다. 나도 될 수 있어
기여/elbs/뭔가...

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172425404
.

2016년 1월 18일 04:07 PM에 Tim Hockin은 다음과 같이 썼습니다.

우리가 현재 추적하고 있는 것도 아닙니다(서비스가
주어진 포드 앞에). 우리는 할 수 있다고 생각합니다. 나는 반대하지 않는다(그렇더라도
틈새). 그렇게 하기 위해 상당한 변화를 가져온 것처럼 들립니다.
많은 주의사항. 그래도 더 나은 답변을 생각하고 싶습니다.

동의하지만 현재로서는 더 나은 아이디어가 없습니다 :-(

목적에 맞게 구축된 SDN조차도 내가 생각하는 것을 추적해야 합니다. 아마도
MPLS와 같은 레이블 기반 솔루션..?

2016년 1월 18일 오후 4시 18분에 Mikaël Cluseau는 다음과 같이 썼습니다.

목적에 맞게 구축된 SDN조차도 내가 생각하는 것을 추적해야 합니다.
MPLS와 같은 레이블 기반 솔루션..?

사물에 레이블을 지정한다는 아이디어에서... 서비스당 하나의 IP + 하나를 할당하면
엔드포인트당 IP(서비스+포드 커플), 이러한 엔드포인트 IP를
포드는 완전히 상태 비저장 방식으로 작동해야 합니다.

``````

• 호스트 외부:{from: clientIP:clientPort, to: externalIP:servicePort} -----[ELB
  하나의 끝점을 선택]--------> {from: clientIP:clientPort, to:
  endpointServiceIP:podPort} --> 호스트로의 경로

• 호스트에서 포드로:{from: clientIP:clientPort, to: endpointServiceIP:podPort} --[표준
  컨테이너로 라우팅]--> {from: clientIP:clientPort , to:
  끝점 ServiceIP:podPort }

• 포드에서 호스트로:{from: endpointServiceIP:podPort, to: clientIP:clientPort}
  --------[라우터에 대한 표준 라우팅]-----> {from:
  endpointServiceIP:podPort, to: clientIP:clientPort} - 호스트에서 외부로:{from: endpointServiceIP:podPort, to: clientIP:clientPort} --------[ELB
  SNATs back]------------------> {from: clientIP:clientPort , to:
  e xternalIP:servicePort } ```

clusterIP에서도 이 작업을 수행할 수 있다고 생각합니다.
``````

GCE에서는 이 작업을 수행할 수 없으며 AWS에 대해서는 잘 모르겠습니다.
제한된 수의 정적 경로를 사용할 수 있습니다.

하나의 IP 범위 2개를 함께 피기백하여 수행할 수 있는지 궁금합니다.
노선. 지출해야 할 IP가 많지만 UDP에만 중요하다고 생각합니다.
나는 그것을 밖으로 시도해야합니다.

편집 : 나는 그것을 시도했지만 작동하지 않았지만 무언가를 놓치고 있습니다.
오는 서비스에 대한 응답으로 컨테이너의 IP를 추가/제거해야 합니다.
가고 있지만 컨테이너 작업에서 "추가" IP를 만들 수 없었습니다.
ping하지만 TCP 또는 UDP가 아닌 이유는 확실하지 않음).

언젠간 다시 해봐야겠네요.

2016년 1월 17일 일요일 오후 10시 22분, Mikaël Cluseau [email protected]
썼다:

2016년 1월 18일 오후 4시 18분에 Mikaël Cluseau는 다음과 같이 썼습니다.

목적에 맞게 구축된 SDN조차도 내가 생각하는 것을 추적해야 합니다.
MPLS와 같은 레이블 기반 솔루션..?

사물에 레이블을 지정한다는 아이디어에서... 서비스당 하나의 IP + 하나를 할당하면
엔드포인트당 IP(서비스+포드 커플), 이러한 엔드포인트 IP를
포드는 완전히 상태 비저장 방식으로 작동해야 합니다.

``````

• 호스트 외부:{from: clientIP:clientPort, to: externalIP:servicePort}
  ------[엘비]
  하나의 끝점을 선택]--------> {from: clientIP:clientPort, to:
  endpointServiceIP:podPort} --> 호스트로의 경로

• 호스트에서 포드로:{from: clientIP:clientPort, to: endpointServiceIP:podPort}
  --[기준
  컨테이너로 라우팅]--> {from: clientIP:clientPort , to:
  끝점 ServiceIP:podPort }

• 포드에서 호스트로:{from: endpointServiceIP:podPort, to: clientIP:clientPort}
  --------[라우터에 대한 표준 라우팅]-----> {from:
  endpointServiceIP:podPort, 대상: clientIP:clientPort} - 호스트 대상
  외부:{from: endpointServiceIP:podPort, to: clientIP:clientPort}
  --------[엘비]
  SNATs back]------------------> {from: clientIP:clientPort , to:
  e xternalIP:servicePort } ```

clusterIP에서도 이 작업을 수행할 수 있다고 생각합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment-172438133
.

``````

나는 무언가를 얻기 위해 내 편에서 노력하고 있습니다 (내 로컬 호스트에 순수한 netns 사용
지금은).

호스트에 대한 서비스 IP 범위에 영향을 미치는 접근 방식을 시도하고 있습니다.
라우팅 항목의 수를 줄이십시오.

cli -- elb -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

ping ATM 없음(PREROUTING 체인을 거치지 않는 패킷...),
잠이 필요. 자세한 내용은 내일 ;)

2016년 1월 18일 오후 6시 28분에 Tim Hockin은 다음과 같이 썼습니다.

GCE에서는 이 작업을 수행할 수 없으며 AWS에 대해서는 잘 모르겠습니다.
제한된 수의 정적 경로를 사용할 수 있습니다.

하나의 IP 범위 2개를 함께 피기백하여 수행할 수 있는지 궁금합니다.
노선. 지출해야 할 IP가 많지만 UDP에만 중요하다고 생각합니다.
나는 그것을 밖으로 시도해야합니다.

편집 : 나는 그것을 시도했지만 작동하지 않았지만 무언가를 놓치고 있습니다.
오는 서비스에 대한 응답으로 컨테이너의 IP를 추가/제거해야 합니다.
가고 있지만 컨테이너 작업에서 "추가" IP를 만들 수 없었습니다.
ping하지만 TCP 또는 UDP가 아닌 이유는 확실하지 않음).

언젠간 다시 해봐야겠네요.

나는 조금 더 나아갔지만, 내가 예상했어야 하는 일이 일어났다.

기본 인터페이스로 10.244.2.8/25와 10.244.2.250/25를 사용하여 포드를 설정했습니다.
"서비스 내" 인터페이스로 사용됩니다. UDP를 보낼 수 있기를 바랐습니다.
.250 및 SNAT에 대한 응답을 감지합니다. 하지만 물론 클라이언트가
동일한 /25에 있지 않음(일 수 없음) 기본 경로가 시작됩니다.
.8 주소에서 옵니다. tcpdump는 응답이 .8에서 왔는지 확인합니다.
UDP를 사용할 때.

나는 그것을 작동시키는 방법을 확신하지 못하는 곳에서 다시. 생각할 예정이다
그것에 대해 더.

2016년 1월 18일 월요일 오전 2시 59분, Mikaël Cluseau [email protected]
썼다:

나는 무언가를 얻기 위해 내 편에서 노력하고 있습니다 (내 로컬 호스트에 순수한 netns 사용
지금은).

호스트에 대한 서비스 IP 범위에 영향을 미치는 접근 방식을 시도하고 있습니다.
라우팅 항목의 수를 줄이십시오.

cli -- elb -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

ping ATM 없음(PREROUTING 체인을 거치지 않는 패킷...),
잠이 필요. 자세한 내용은 내일 ;)

2016년 1월 18일 오후 6시 28분에 Tim Hockin은 다음과 같이 썼습니다.

GCE에서는 이 작업을 수행할 수 없으며 AWS에 대해서는 잘 모르겠습니다.
제한된 수의 정적 경로를 사용할 수 있습니다.

2개의 IP 범위를 함께 피기백하여 수행할 수 있는지 궁금합니다.
하나의
노선. 지출해야 할 IP가 많지만 UDP에만 중요하다고 생각합니다.
나는 그것을 밖으로 시도해야합니다.

편집 : 시도했지만 작동하지 않았지만 누락되었습니다.
무엇.
오는 서비스에 대한 응답으로 컨테이너의 IP를 추가/제거해야 합니다.
가고 있지만 컨테이너 작업에서 "추가" IP를 만들 수 없었습니다.
ping하지만 TCP 또는 UDP가 아닌 이유는 확실하지 않음).

언젠간 다시 해봐야겠네요.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172497456
.

이것이 효과가 있더라도 (Abhishek을 통해) 우리는 여전히
track은 어딘가에 흐르므로 결국에는 stateless가 아닙니다.

2016년 1월 18일 월요일 오후 9시 50분에 Tim Hockin [email protected]이 다음과 같이 썼습니다.

나는 조금 더 나아갔지만, 내가 예상했어야 하는 일이 일어났다.

10.244.2.8/25를 기본 인터페이스로 사용하여 포드를 설정하고
10.244.2.250/25를 "서비스 내" 인터페이스로 사용합니다. 나는 내가
UDP를 .250으로 보내고 응답을 감지하여 SNAT로 보낼 수 있습니다. 하지만 물론,
클라이언트가 동일한 /25(일 수 없음)에 있지 않은 경우 기본값
.8 주소에서 오는 경로가 시작됩니다. tcpdump는 다음을 확인합니다.
응답은 UDP를 사용할 때 .8에서 나옵니다.

나는 그것을 작동시키는 방법을 확신하지 못하는 곳에서 다시. 생각할 예정이다
그것에 대해 더.

2016년 1월 18일 월요일 오전 2시 59분, Mikaël Cluseau [email protected]
썼다:

나는 무언가를 얻기 위해 내 편에서 노력하고 있습니다 (내 로컬 호스트에 순수한 netns 사용
지금은).

호스트에 대한 서비스 IP 범위에 영향을 미치는 접근 방식을 시도하고 있습니다.
라우팅 항목의 수를 줄이십시오.

cli -- elb -- h1 -- c1

| `--- c2

`--- h2 -- c2

h1_ep_ip_ranges=( 10.1.1.0/24 10.1.2.0/24 )
h2_ep_ip_ranges=( 10.1.3.0/24 )

ping ATM 없음(PREROUTING 체인을 거치지 않는 패킷...),
잠이 필요. 자세한 내용은 내일 ;)

2016년 1월 18일 오후 6시 28분에 Tim Hockin은 다음과 같이 썼습니다.

GCE에서는 이 작업을 수행할 수 없으며 AWS에 대해서는 잘 모르겠습니다.
제한된 수의 정적 경로를 사용할 수 있습니다.

2개의 IP 범위를 함께 피기백하여 수행할 수 있는지 궁금합니다.
하나의
노선. 지출해야 할 IP가 많지만 UDP에만 중요하다고 생각합니다.
나는 그것을 밖으로 시도해야합니다.

편집 : 시도했지만 작동하지 않았지만 누락되었습니다.
무엇.
서비스에 대한 응답으로 컨테이너에 IP를 추가/제거해야 합니다.
오는
그리고 가고 있지만 컨테이너 작업에서 "추가" IP를 만들 수 없었습니다.
~ 할 수 있었다
ping하지만 TCP 또는 UDP가 아닌 이유는 확실하지 않음).

언젠간 다시 해봐야겠네요.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -172497456
.

그것은 불행한 일입니다 :-(왜 그런지 잘 모르겠습니다. 그러면 MPLS로 무언가를 시도 할 것입니다. 어쨌든 배우고 싶습니다.

서비스에 2개의 백엔드가 있고 하나 이상의 백엔드를 보내려는 경우
패킷, 어떤 방식으로든 흐름을 추적해야 하지 않습니까? 아니면 당신은
다른 백엔드에서 패킷을 분무하는 것이 안전하다고 가정합니까?

2016년 1월 20일 수요일 오후 12시 24분, Mikaël Cluseau [email protected]
썼다:

그것은 불행한 일입니다 :-(그런데 왜 그런지 잘 모르겠습니다.
MPLS 그렇다면 어쨌든 배우고 싶습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -173348973
.

UDP 워크로드의 경우 예라고 가정했습니다. UDP에 대해서도 상태 비저장으로 전환하는 것은 선택 사항일 수 있습니다. @qoke 이에 대한 의견이

또한 클라이언트 IP 해싱과 같은 것을 사용하여 균형을 유지하면서 흐름을 보다 안정적으로 만들 수 있습니다(이를 "일종의 추적"이라고 부를 수 있는지 모르겠습니다 :-)).

@MikaelCluseau 우리는 매우 가벼운 UDP "

UDP 데이터그램 스케줄링을 위해 IPVS 로드 밸런서는 구성 가능한 시간 초과로 UDP 데이터그램 스케줄링을 기록하고 기본 UDP 시간 초과는 300초입니다. UDP 연결 시간이 초과되기 전에 동일한 소켓(프로토콜, IP 주소 및 포트)의 모든 UDP 데이터그램이 동일한 서버로 전달됩니다.

-- http://kb.linuxvirtualserver.org/wiki/IPVS 에서 인용

물론 이것은 단일 서비스와 통신하는 클라이언트가 많거나 소스 포트가 다양한 단일 클라이언트가 있는 경우에만 작동합니다. 단일 대용량 클라이언트가 있고 모든 트래픽이 동일한 소스 포트에서 전송되고 이를 여러 백엔드에 걸쳐 로드 밸런싱하려는 경우 상태 비저장/분무 및 기도 접근 방식을 선호할 수 있습니다.

우리는 많은 DNS 및 RADIUS 트래픽을 로드 밸런싱합니다. DNS는 일반적으로 첫 번째 범주(많은 클라이언트 또는 많은 소스 포트가 있는 클라이언트)에 속하고 RADIUS는 일반적으로 나중 범주(적은 클라이언트, 많은 패킷 모두에서 동일한 IP/포트). RADIUS에 대해 상태 비저장 해시를 사용하는 대신 소스 포트를 무작위로 지정하여 균등하게 분산하기로 결정했습니다.

전체 스레드를 읽은 후에도 kube-proxy에 대한 iptables 모드를 활성화하면 외부 IP가 숨겨지는 문제(#10921)를 해결해야 하는지 여부를 알 수 없습니다. 여기에 제안된 대로 v1.1에서 iptables 모드를 활성화했지만 사용자의 실제 IP가 아닌 클러스터의 IP가 여전히 표시됩니다.

우리 클러스터는 GCE에 있으며 우리는 라이브를 시작하기 전에 HTTPS를 지원하는 로드 밸런서만 있으면 됩니다. GCE는 v.1.2 알파를 지원하지 않기 때문에 새로운 Ingress(AFAIK가 HTTPS 로드 밸런서를 지원함)를 사용할 수 없으므로 Network Load Balancer가 유일한 옵션입니다. 그러나 분명히 우리는 사용자의 실제 IP를 로깅하는 기능 없이는 라이브를 시작할 수 없습니다.

이에 대한 신규 사용자를 위한 몇 가지 설명을 해주시면 감사하겠습니다. HTTPS 지원은 우리 중 많은 사람들에게 필수입니다. 감사 해요!

나는 꽤 오랫동안 iptables 프록시를 켜고 끄는 것을 사용해 왔으며 클라이언트의 외부 IP가 여전히 숨겨져 있음을 확인할 수 있습니다/클러스터 IP를 표시합니다.

지금까지 호스트 네트워크 모드에서 실행되는 프론트엔드 HTTP/HTTPS 프록시를 실행하여 소스 IP 주소를 확인함으로써 이 문제를 해결했습니다.

@macof 피드백 주셔서 감사합니다. 해결 방법에 대한 자세한 정보를 공유할 수 있습니까? 호스트 네트워크에서 실행되는 HTTP/HTTPS는 무엇을 의미합니까?

@javiercr 우리는 다음과 같은 포드 사양을 사용합니다. http://pastie.org/private/zpdelblsob654zif7xus5g

호스트 네트워크를 사용한다는 것은 포드가 클러스터 IP를 할당받는 대신 호스트 시스템 네트워크에서 실행된다는 것을 의미합니다.

즉, nginx 서버가 포트 80/443에 바인딩되면 호스트 IP에서 수신 대기하고 소스 IP 주소를 볼 수 있습니다.

나는 kubernetes 1.1, /opt/bin/kube-proxy ... --proxy-mode=iptables --masquerade-all=false 를 사용하고 kube-proxy가 있는 호스트를 통해 클러스터 IP 네트워크를 라우팅하고 있습니다. 이 설정에서 내 서비스는 외부 IP를 보고 있습니다. 외부 IP와 호스트 경로가 있는 고가용성 네트워크 네임스페이스를 사용합니다.

I0221 01:20:32.695440       1 main.go:224] <A6GSXEKN> Connection from 202.22.xxx.yyy:51954 closed.

이 스레드를 읽고 많은 것을 배웠습니다!

참고로 이 문서에서는 AWS ELB가 TCP 연결에 라운드 로빈을 사용하고 http/https에 대해 최소 연결을 사용한다고 명시합니다. http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/how-elb-works.html# 요청 라우팅

포드를 실행하는 노드에만 요청을 받고 로컬 포드를 제공하는 데 초점을 맞추는 것이 최선의 방법이라는 데 동의합니다. 이것의 좋은 부수적 이점은 클러스터 내에서 노드 간 트래픽이 적고 서비스에서 포드로 항상 로컬 요청을 처리함으로써 지연 시간이 개선된다는 것입니다. 동일한 클러스터의 여러 가용 영역).

가중치를 지원하지 않는 로드 밸런서로 작업하는 경우 노드에 항상 동일한 수의 포드를 유지하려고 시도한 다음(노드당 1개 이상인 경우) 다음 사이에 균등하게 분배하여 복제 컨트롤러로 이 문제를 해결할 수 있습니다. 특정 상황에서 노드에서 포드를 이동해야 하고 특정 복제본 수만 허용하는 경우에도 마찬가지입니다. 예를 들어 로드 밸런서에 연결된 서비스가 있는 4노드 클러스터의 경우 허용되는 포드 복제본의 유일한 수는 1,2,3,4,6,8,9,12,16,20 등입니다.

또한 트래픽이 로컬 포드로만 라우팅되는 문제를 해결하려고 합니다. 서비스에 대한 포드가 로컬에 없을 때 노드에서 노드 포트가 사라지는 것이 좋습니다. 이렇게 하면 간단한 로드 밸런서 TCP 상태 확인을 통해 요청이 해당 노드로 이동하는 것을 방지할 수 있습니다. 적어도 이것의 iptables\kube-proxy 부분에 대해 해결할 수 있다면 포드가 클러스터 전체에서 균형을 이루지 않을 때 로드 밸런싱이 의미하는 바를 알게 될 것이라고 생각합니다. API 호출을 통해 각 노드에 가중치를 설정하지 않고도 로드 밸런서에서 해결할 수 있는 방법이 있다고 생각합니다.

로드 밸런서는 이미 다른 동적 방법을 사용하여 이를 처리합니다. 또한 실행 중인 서비스가 각 API 호출에 대해 해당 컨테이너 내에서 실제로 수행하는 작업에 따라 어쨌든 노드에 2개의 포드가 있는 경우 1개의 포드가 있는 경우 2배 트래픽을 지원하지 못할 수 있습니다. Kubernetes 제한이 설정되고 포드노드에서 최대 사용량 수준에 도달하면 외부 로드 밸런서에서 올바른 가중치 설정을 찾는 데 또 다른 복잡성 계층이 추가될 수 있습니다.

그런 수준의 복잡성을 피하고 kubernetes에서 로드 밸런서 가중치를 설정하려고 하지 마십시오.

@yoshiwaan 이 문제가 이제 종료되었으므로 노드 간 트래픽 제안에 대한 새 문제를 여는 것을 제안할 수 있습니까? 개인적으로 좋은 첫 번째 단계는 _if_ 포드가 로컬 노드에서 실행되고 있는지 확인하고 로컬 포드로 라우팅하는 것이라고 생각합니다. 모든 노드에 포드가 있도록 RC를 확장할 수 있기 때문에 이것이 충분할 것이라고 생각합니다.

@justinsb +1, 또한 클라이언트 IP를 확인해야 하는 문제가 발생하고 있으며 현재 설정에서는 기본적으로 불가능합니다.

이것은 너무 순진할 수 있지만 사용자 공간 모드와 iptables의 차이점이 무엇인지 궁금합니다. 나는 정말로 사용자 문서 에서 말할 수 없습니다.

Userland 모드는 kube-proxy가 클라이언트로부터 연결 요청을 수신하고 서버에 대한 소켓을 열어 연결 자체를 처리함을 의미합니다. 이는 (1) 훨씬 더 많은 CPU와 메모리를 소비하고 (2) 단일 포트 수로 제한됩니다. 열려 있습니다(<65k). iptables 모드는 커널의 낮은 수준에서 작동하며 대신 연결 추적을 사용하므로 훨씬 가볍고 더 많은 연결을 처리합니다*.

(편집) (*) SNAT 패킷이 통과하지 않는 한, 패킷이 연결된 연결 추적 규칙을 통과할 것이라고 확신하는 설정이 필요합니다. 예를 들어, 라우팅된 액세스 디자인을 사용하면 SNAT를 피할 수 있습니다. 즉, 서비스의 끝점이 실제 클라이언트의 IP를 볼 수 있음을 의미합니다.

@MikaelCluseau
즉, kube-proxy는 iptables 규칙을 설정하고 유지 관리하는 역할만 하며 더 이상 iptables 모드에서 각 서비스에 대해 임의의 로컬 포트를 얻지 못합니다.

2016년 4월 19일 오후 10시 51분에 Emma He는 다음과 같이 썼습니다.

kube-proxy는 설정 및 유지 관리에만 책임이 있음을 의미합니다.
iptables 및 우리는 더 이상 각 서비스에 대한 임의의 로컬 포트를 얻지 않습니다.
iptables 모드 맞죠?

예.

미안하지만 나는 이것을 더 일찍 절대적으로 놓쳤다.

(편집) (*) SNAT 패킷이 통과하지 않는 한, 패킷이 연결된 연결 추적 규칙을 통과할 것이라고 확신하는 설정이 필요합니다. 예를 들어, 라우팅된 액세스 디자인을 사용하면 SNAT를 피할 수 있습니다. 즉, 서비스의 끝점이 실제 클라이언트의 IP를 볼 수 있음을 의미합니다.

@MikaelCluseau 나는 iptables가 SNAT와 DNAT를 채택

2016년 4월 20일 오후 1시 59분에 Emma He는 다음과 같이 썼습니다.

@MikaelCluseau https://github.com/MikaelCluseau 생각하고 있었는데
iptables는 SNAT 및 DNAT를 채택하지만 귀하의 경우는 그렇지 않습니다.
저를 위해 이것을 명확히 해 주시겠습니까?

까다로운 부분입니다.

(1) 서비스/외부 IP를 이용하기 위해서는 DNAT가 필요합니다.
(2) 응답 패킷이 동일한 conntrack을 통과할 것이라고 확신하는 경우
규칙(즉, 동일한 네트워크 스택 또는 복제된 conntrack 테이블),
SNAT 부분을 건너뛸 수 있습니다(즉, MASQUERADE 규칙).

(2)의 조건은 일반적으로 라우팅된 액세스 네트워크 설계에서 양호합니다.
(내가 생각할 수있는 가장 간단한 디자인).

예를 들어, 주어진

• 클라이언트 1.0.1.1,
• 서비스 1.0.2.1,
• 서비스를 구현하는 포드 1.0.3.1.

그 다음에,

1. 라우터/방화벽/로드 밸런서/호스트/패킷을 수신하는 모든 것
   서비스의 경우 "1.0.1.1 -> 1.0.2.1" 패킷이 표시됩니다.
2. 패킷이 "1.0.1.1 ->이 되도록 엔드포인트(포드)에 DNAT를 지정합니다.
   클러스터 네트워크에서 1.0.3.1";
3. 포드는 "1.0.3.1 -> 1.0.1.1" 패킷으로 응답합니다.
4. 패킷은 라우터/방화벽/로드 밸런서/호스트/무엇이든 통과합니다.
   conntrack 규칙이 있는 경우 conntrack 시스템은 패킷을 다시 작성합니다.
   클라이언트로 다시 보내기 전에 "1.0.2.1 -> 1.0.1.1"로 변경합니다.

(2)의 조건이 충족되지 않으면 SNAT/MASQUERADING을 사용해야 합니다.
패킷이
라우터/방화벽/로드 밸런서/호스트/연결 추적.

@MikaelCluseau - google.com에서 내 github 이름으로 이메일을 보내주세요.
당신을 위해 뭔가

2016년 4월 19일 화요일 오후 8:20, Mikaël Cluseau [email protected]
썼다:

2016년 4월 20일 오후 1시 59분에 Emma He는 다음과 같이 썼습니다.

@MikaelCluseau https://github.com/MikaelCluseau 생각하고 있었는데
iptables는 SNAT 및 DNAT를 채택하지만 귀하의 경우는 그렇지 않습니다.
저를 위해 이것을 명확히 해 주시겠습니까?

까다로운 부분입니다.

(1) 서비스/외부 IP를 이용하기 위해서는 DNAT가 필요합니다.
(2) 응답 패킷이 동일한 conntrack을 통과할 것이라고 확신하는 경우
규칙(즉, 동일한 네트워크 스택 또는 복제된 conntrack 테이블),
SNAT 부분을 건너뛸 수 있습니다(즉, MASQUERADE 규칙).

(2)의 조건은 일반적으로 라우팅된 액세스 네트워크 설계에서 양호합니다.
(내가 생각할 수있는 가장 간단한 디자인).

예를 들어, 주어진

• 클라이언트 1.0.1.1,
• 서비스 1.0.2.1,
• 서비스를 구현하는 포드 1.0.3.1.

그 다음에,

1. 라우터/방화벽/로드 밸런서/호스트/패킷을 수신하는 모든 것
   서비스의 경우 "1.0.1.1 -> 1.0.2.1" 패킷이 표시됩니다.
2. 패킷이 "1.0.1.1 ->이 되도록 엔드포인트(포드)에 DNAT를 지정합니다.
   클러스터 네트워크에서 1.0.3.1";
3. 포드는 "1.0.3.1 -> 1.0.1.1" 패킷으로 응답합니다.
4. 패킷은 라우터/방화벽/로드 밸런서/호스트/무엇이든 통과합니다.
   conntrack 규칙이 있는 경우 conntrack 시스템은 패킷을 다시 작성합니다.
   클라이언트로 다시 보내기 전에 "1.0.2.1 -> 1.0.1.1"로 변경합니다.

(2)의 조건이 충족되지 않으면 SNAT/MASQUERADING을 사용해야 합니다.
패킷이
라우터/방화벽/로드 밸런서/호스트/연결 추적.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/3760#issuecomment -212230959

@justinsb @yoshiwaan는 누구도 이것에 대한 문제를 창조 하셨 는가? 내 검색 fu는 나를 실패하고 나도 비슷한 필요가 있습니다.

이 문제는 이제 종료되었으므로 노드 간 트래픽 제안에 대한 새 문제를 여는 것을 제안할 수 있습니까? 개인적으로 좋은 첫 번째 단계는 포드가 로컬 노드에서 실행 중인 경우 로컬 포드로 라우팅하도록 하는 것입니다. 모든 노드에 포드가 있도록 RC를 확장할 수 있기 때문에 이것이 충분할 것이라고 생각합니다.

내가 직접 키운게 아니라

Ahhhhh, 찾은 것 같아요. 이것은 기능/수정인 것 같습니다: https://github.com/kubernetes/features/issues/27

1.5.x의 베타 버전인 것 같습니다.