kubernetes/kubernetes와의 상호 참조: 문제 번호 62822

업데이트해주셔서 감사합니다!

/할당 @leblancd
/종류 기능
/시그 네트워크
/마일스톤 1.11

@leblancd 사용 가능한 디자인 문서가 있습니까?

/cc @thockin @dcbw @luxas @kubernetes/sig-network-feature-requests

@idvoretskyi - 아직 디자인 문서가 없지만 곧 공동 작업을 시작할 것입니다.

이것은 Kubernetes Ingress가 Dual-Stack을 지원한다는 것을 의미합니까?
이것은 CNI(Calico)가 듀얼 스택(예: BIRD 및 BIRD6 데몬 모두)을 실행해야 함을 의미합니까?

@sb1975 - 이중 스택 수신 지원과 관련하여

• 이중 스택 수신 지원은 주로 사용하는 수신 컨트롤러(지원 여부 및 구현 방법)에 따라 다릅니다. 기존 수신 컨트롤러는 이중 스택을 지원하기 위해 약간의 변경이 필요할 수 있습니다.
• 일반적인 수신 컨트롤러에 대한 수신 구성 이 변경되지 않을 것으로 예상합니다(예: 구성은 V4/V6 제품군에 대한 언급 없이 여전히 L7 주소를 서비스 이름/서비스 포트에 매핑할 수 있음).
• 서비스에 이중 스택인 엔드포인트 포드가 있는 경우 수신 컨트롤러는 패킷 패밀리를 기반으로 수신 패킷을 매핑하기 위해 변경이 필요할 수 있습니다. 즉, IPv4 수신 패킷을 IPv4 엔드포인트에 매핑하고 IPv6 수신 패킷을 매핑해야 합니다. IPv6 끝점에. 로드 밸런싱 가중치를 위해 이중 스택 엔드포인트는 단일 엔드포인트 대상으로 계산되어야 합니다.

- 우리는 V4/V6 제품군에 걸쳐 인그레스 컨트롤러 맵(인그레스 IPv4 패킷을 IPv6 백엔드에 또는 그 반대로 매핑)을 갖는 것에 대한 FUTURE 지원을 고려할 수 있지만 초기 개발은 엄격한 이중 스택(즉, 개별, 독립 스택).

Calico 및 기타 CNI 플러그인 관련:

• CNI 플러그인은 여전히 IPv4 전용 또는 IPv6 전용 (경우 플러그인 지원을)를 실행 할 수 있어야한다, 클러스터 시나리오는 듀얼 스택을 필요로하지 않는 경우 듀얼 스택 모드에서 실행 할 필요가 없습니다.
• 듀얼 스택 지원에는 다양한 CNI 플러그인의 변경이 필요할 수 있지만 해당 작업은 이 Kubernetes 문제의 범위를 벗어나는 것으로 간주됩니다. 참고), CNI 작업은 사례별로 별도로 진행됩니다.
• 특히 Calico의 경우 전문가는 아니지만 IPv4 및 IPv6 경로를 모두 처리하도록 단일 BIRD 데몬을 구성할 수 있다고 생각합니다(여기에서 "템플릿 bgp" 검색: http://bird.network.cz/?get_doc&v= 20&f=bird-3.html#ss3.1). 즉, Calico는 이미 포드에서 이중 스택 주소를 지원하지만 BGP 라우팅이 두 제품군 모두에서 작동하도록 하려면 변경이 필요할 수 있습니다.

@leblancd : 시나리오는 다음과 같습니다.

1. NGINX 수신 컨트롤러를 사용한다고 가정해 보겠습니다.
2. Ingress를 통해 내 서비스를 노출하고 있습니다.
3. 듀얼 스택에 구성된 포드를 실행 중입니다.
4. A 및 AAAA DNS 레코드를 사용하여 원격으로 서비스에 연결하려고 합니다.
   이 모든 것을 바랍니다.
5. 요약: 포드 서비스 이름에 대한 A 및/또는 AAAA 레코드에 대한 자체 쿼리로 해결된 대로 IPv4 또는 IPv6 주소를 사용하여 포드 인터페이스에 연결하고 싶습니다.
   테스트, 문서화, 아키텍처를 위해 이 이니셔티브에 참여할 수 있습니까? 하지만 몇 가지 지침이 필요합니다.
   이 진행 상황을 어떻게 알 수 있습니까?

@sb1975 - 좋은 질문입니다. 듀얼 스택이 있는 NGINX 인그레스 컨트롤러. 저는 NGINX 인그레스 컨트롤러의 전문가는 아니지만(더 친숙한 사람이 참여할 수 있음) 작업 흐름을 보는 방법은 다음과 같습니다.

• 외부에서 Kube 서비스에 연결하려고 하면 DNS 컨트롤러가 수신 컨트롤러에 대한 A 및 AAAA DNS 레코드를 사용하여 서비스를 확인해야 합니다. 수신 컨트롤러에 도달하기 위해 A 대 AAAA 레코드를 사용하는 것은 클라이언트/앱의 선택입니다. 따라서 인그레스 컨트롤러에 대한 외부 액세스는 이중 스택이 됩니다.
• NGINX 수신 컨트롤러에서 NGINX는 L7 URL(IPv4 또는 IPv6 패킷에 있는 요청에 관계없이)을 확인하고 이를 업스트림 엔드포인트로 로드 밸런싱합니다. 수신 컨트롤러 로드 밸런서가 ipv6=on으로 구성된 경우(기본값, https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load 참조) -balancing-using-dns) 및 서비스 엔드포인트가 이중 스택인 경우 업스트림 구성에는 각 이중 스택 엔드포인트에 대한 IPv4 및 IPv6 항목이 모두 있어야 합니다. 설계된 대로 NGINX 로드 밸런서는 엔드포인트에 대한 IPv4 항목과 IPv6 항목을 별도의 서버로 취급합니다 . (앞서 언급한 문서의 "도메인 이름이 여러 IP 주소로 확인되면 주소가 업스트림 구성에 저장되고 로드 밸런싱됩니다."의 줄을 참조하십시오.) 이것은 좋은 소식이나 나쁜 소식으로 간주될 수 있습니다. 좋은 소식은 IPv4 및 IPv6 끝점에서 로드 균형 조정이 수행된다는 것입니다(예: 들어오는 IPv4 요청이 IPv4 또는 IPv6 끝점에 매핑될 수 있음). 그러나 잠재적인 나쁜 소식은 로드 밸런싱 세분성입니다. IPv4 엔드포인트에 대한 연결 및 해당 IPv6 엔드포인트에 대한 연결은 (로드 밸런싱 고려 사항을 위해) 동일한 엔드포인트에 대한 2개의 개별 로드가 아니라 별도의 엔드포인트에 대한 2개의 로드로 처리됩니다. . 이 로드 밸런싱 세분성이 우려되는 경우 누군가 가 IPv6(또는 이에 대한 구성 노브가 있는 경우 IPv4)에 대한 로드 밸런싱을 비활성화하여 로드 밸런싱이 IPv4 전용 엔드포인트에 있도록 할 수 있습니다. 또는 NGINX 로드 밸런서를 수정하여 IPv4 주소에 대한 연결과 해당 IPv6 주소에 대한 연결을 동일한 엔드포인트에 대한 2개의 로드로 처리할 수 있습니다.

도움과 참여에 관해서는 대단히 감사하겠습니다! 이제 본격적으로 듀얼 스택 작업을 시작하려고 합니다(CI가 IPv6 전용으로 작동하도록 하는 작업으로 인해 약간 지연되었습니다). 사양에 대한 개요(Google 문서 또는 KEP WIP 문서)가 곧 나오길 바라며 검토하고 일부 섹션을 작성하는 데 도움이 필요할 것입니다. 또한 공식 문서(설계 사양 이상)와 이중 스택 E2E 테스트 정의 및 구현에 대한 도움이 확실히 필요합니다. 디자인에 대해 아직 약간 스케치한 영역은 다음과 같습니다.

• 상태/활성/준비 상태 프로브가 이중 스택에 영향을 받거나 처리되는 방식
• 네트워크 정책에 영향이 있습니까?
• 로드 밸런서 문제?
• 클라우드 공급자 플러그인 문제?
• L3/L4 유입 우려?
  이러한 부분에 대해 생각해 본 적이 있다면 해당 부분에 대해 도움을 줄 수 있을까요?

우리는 또한 클러스터 외부에서 K8s 서비스로의 액세스가 이중 스택이지만 매핑되는(예: NGINX를 통해) 중간 "에지에서 이중 스택"(클러스터 내부 IPv6 전용) 접근 방식을 고려하고 있습니다. 인그레스 컨트롤러)를 클러스터 내부의 IPv6 전용 엔드포인트로 연결합니다(또는 상태 비저장 NAT46 사용). 클러스터의 포드 및 서비스는 모두 IPv6이어야 하지만 가장 큰 장점은 출시 시간 관점에서 듀얼 스택 외부 액세스를 훨씬 더 빠르게 사용할 수 있다는 것입니다.

/마일스톤 1.12

@leblancd / @caseydavenport - 여기에서 많은 논의와 이정표가 변경
이것은 1.11 이정표에서 가져와야합니까?

@justaugustus - 예, 1.12로 옮겨야 합니다. 출시 스프레드시트에서 행을 삭제해야 합니까, 아니면 변경하기 위해 해야 할 일이 있습니까?

@leblancd 제가 해결했습니다. 팔로우해주셔서 감사합니다! :)

@leblancd @kubernetes/sig-network-feature-requests --

이 기능은 이전 마일스톤에서 제거되었으므로 Kubernetes 1.12에서 이에 대한 계획이 있는지 확인하고 확인하고 싶습니다.

그렇다면 다음 정보를 모두 포함하여 이 문제가 최신 상태인지 확인하십시오.

• 한 줄로 된 기능 설명(릴리스 노트로 사용할 수 있음):
• 기본 연락처(담당자):
• 책임 있는 SIG:
• 디자인 제안 링크(커뮤니티 리포지토리):
• e2e 및/또는 단위 테스트에 대한 링크:
• 검토자 - (LGTM의 경우) 2명 이상의 검토자(코드 영역 OWNERS 파일에서 최소 한 명)가 검토에 동의하도록 권장합니다. 여러 회사의 리뷰어 선호:
• 승인자(기능이 속한 SIG/영역에서 가능):
• 기능 목표(어떤 목표가 어떤 이정표와 같음):
  
  
  
  • 알파 릴리스 대상(xy)
  
  
  • 베타 출시 대상(xy)
  
  
  • 안정 출시 목표(xy)
  
  

다음을 설정합니다.

• 설명
• 양수인
• 라벨:
  
  
  
  • 단계/{알파,베타,안정}
  
  
  • 시그/*
  
  
  • 종류/특징
  
  

기능 동결은 7월 31일이며, 그 이후에는 불완전한 기능 문제가 있는 경우 예외 요청 을 마일스톤으로 수락해야 합니다.

또한 다음과 같은 관련 마감일에 유의하십시오.

• 문서 마감일(열린 자리 표시자 PR): 8/21
• 테스트 케이스 동결: 8/28

기능에 대한 모든 PR에 관련 릴리스 정보도 포함되어 있는지 확인하십시오.

행복한 배송!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

@르블랑 --
기능 동결이 오늘입니다. Kubernetes 1.12에서 이를 베타로 전환할 계획입니까?
그렇다면 1.12 기능 추적 스프레드시트에 포함할 수 있도록 모든 것이 최신 상태인지 확인할 수 있습니까?

@justaugustus 님 안녕하세요. 베타 상태는 Kubernetes 1.13으로 전환되어야 합니다. 우리는 설계 KEP(https://github.com/kubernetes/community/pull/2254)에서 (느리긴 하지만) 진전을 이루고 있으며 CI 테스트 PR에 다시 참여하는 데 가까워지고 있지만 Kubernetes 1.12 목표가 너무 낙관적이었습니다.

앞서 요청하신 정보로 위의 설명/요약을 업데이트하겠습니다. 기다려 주셔서 감사합니다.

/제거 단계 알파
/스테이지 베타

걱정 마, @leblanc. 업데이트해주셔서 감사합니다!

안녕하세요, @justaugustus @leblancd

방금 베타가 듀얼 스택의 경우 1.13으로 이동되었다는 업데이트를 읽었습니다. 1.13의 예상 출시일은 언제인가요? 우리는 실제로 듀얼 스택 지원을 찾고 있습니다. 우리 제품을 컨테이너로 옮기는 것은 무의미한 결정입니다.

@navjotsingh83 - Kubernetes 1.13의 출시 날짜가 확정되지 않은 것 같습니다. Kubernetes 릴리스 문서 에 1.13이 나열되지 않습니다.

@navjotsingh83 @leblancd 1.13 출시 일정이 공개되었습니다 . 11월 15일에 코드가 정지된 짧은 릴리스 주기입니다. 이 기능을 베타로 전환하기에 충분한 시간이라고 생각하십니까? 코드, 테스트 및 문서 완성과 관련하여 귀하의 자신감 수준으로 이 문제를 업데이트할 수 있습니까?

SIG 네트워크 회의에서 논의된 대로 1.13에서 이 기능에 대한 상당한 작업이 수행되지만 1.13에서 베타로 이동하지 않을 것으로 예상됩니다. 그에 따라 이정표를 제거합니다.

/마일스톤 클리어

@kacole2 는 1.13 개선 스프레드시트에서 이것을 제거합니다.

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

@leblancd 안녕하세요 - 저는 1.14에 대한 개선 사항의 리더이며 1.14 릴리스에 대해 어떤 작업(있는 경우)이 계획되고 있는지 확인하기 위해 이 문제를 확인하고 있습니다. 개선 사항 동결은 1월 29일이며 모든 개선 사항에는 KEP가 있어야 함을 상기시키고 싶습니다.

@leblancd IPv4/IPv6용 클러스터 에지에서 설명 생성과 관련된 이전 의견에 대한 후속

"우리는 또한 클러스터 외부에서 K8s 서비스로의 액세스가 이중 스택이지만 이것은 매핑될 것인 중간 "에지에서의 이중 스택"(클러스터 내부의 IPv6 전용) 접근 방식을 고려하고 있습니다(예: NGINX 수신 컨트롤러)를 클러스터 내부의 IPv6 전용 엔드포인트로 연결합니다(또는 상태 비저장 NAT46 사용). 클러스터의 포드와 서비스는 모두 IPv6이어야 하지만 가장 큰 장점은 시장 출시 시점에서 듀얼 스택 외부 액세스를 훨씬 더 빠르게 사용할 수 있다는 것입니다.”

이 사용 사례는 현재 프로젝트에 좋은 것이므로 시간 프레임에 대한 귀하의 생각을 보고 싶고 나 자신이나 우리 그룹의 누군가가 이 빠른 시장 출시 경로에 도움이 될 수 있는 것이 있는지 확인하고 싶었습니다.

@KevinAtDesignworx edge-dual-stack이지만 내부 ipv6 전용 접근 방식이 여전히 컨테이너 내부에서 외부 ipv4 요청에 도달할 수 있다면(예: curl -v 93.184.216.34 -H "Host: example.com" ), 진정으로 이것이 최선의 접근 방식이라고 생각합니다. 인프라에서 ipv6을 사용할 수 있다면 호환성을 위해 에지를 제외하고 ipv4를 사용하는 것이 좋습니다. 그러나 이 접근 방식이 클러스터 내부에서 ipv4만을 사용하여 레거시 웹 사이트에 연결할 수 없다는 것을 의미한다면 더 이상 확신할 수 없습니다.

464XLAT가 있으므로 컨테이너 내부에만 ipv6이 실행 가능합니다.

@KevinAtDesignworx - 인그레스 컨트롤러를 사용하는 것이 시나리오에서 작동하는 경우 외부에서 이중 스택 작업을 위해 NGINX 인그레스 컨트롤러를 구성할 수 있습니다(클러스터 내부의 단일 제품군에 프록시): https://github.com/leblancd/ kube-v6#installing -a-dual-stack-ingress-controller-on-an-ipv6-only-kubernetes-cluster

수신 컨트롤러는 각 노드의 호스트 네트워크에서 실행되어야 하므로 컨트롤러를 데몬 세트(각 노드에 하나의 수신 컨트롤러)로 설정해야 합니다. 이것은 다음을 가정합니다.

• 노드는 이중 스택입니다(단일 제품군인 포드 및 서비스와 반대).
• 각 노드의 /etc/hosts에는 IPv6 항목이 있고 해당 노드의 호스트 이름에 대한 IPv6 항목(IPv4 주소 없음)만 있습니다.

이는 클러스터 내부의 V6 클라이언트에서 외부 IPv4 전용 서버로의 연결을 위한 NAT64/DNS64에 추가됩니다.

Stateless NAT46도 옵션이지만 시도하지 않았으므로 이에 대한 구성 가이드가 없습니다.

@leblancd 1.15에 계획된 작업이 있습니까? 이 시점에서도 KEP가 아직 승인되지 않은 것 같습니다. 감사 해요!

@leblancd IPv4/IPv6용 클러스터 에지에서 설명 생성과 관련된 이전 의견에 대한 후속

"우리는 또한 클러스터 외부에서 K8s 서비스로의 액세스가 이중 스택이지만 이것은 매핑될 것인 중간 "에지에서의 이중 스택"(클러스터 내부의 IPv6 전용) 접근 방식을 고려하고 있습니다(예: NGINX 수신 컨트롤러)를 클러스터 내부의 IPv6 전용 엔드포인트로 연결합니다(또는 상태 비저장 NAT46 사용). 클러스터의 포드와 서비스는 모두 IPv6이어야 하지만 가장 큰 장점은 시장 출시 시점에서 듀얼 스택 외부 액세스를 훨씬 더 빠르게 사용할 수 있다는 것입니다.”

이 사용 사례는 현재 프로젝트에 좋은 것이므로 시간 프레임에 대한 귀하의 생각을 보고 싶고 나 자신이나 우리 그룹의 누군가가 이 빠른 시장 출시 경로에 도움이 될 수 있는 것이 있는지 확인하고 싶었습니다.

컬 요청(예: curl -v 93.184.216.34 -H "Host: example.com")을 클러스터 외부로 보내는 컨테이너(ipv6에만 해당) 내부에서. 컨테이너가 있는 호스트에 ipv4 경로가 없으면 알 수 없는 대상 또는 연결할 수 없는 대상 오류가 발생한다고 생각합니다.

@GeorgeGuo2018 k8s가 DNS64/NAT64를 구현하면 작동합니다. 그것은 k8이 464xlat/plat 솔루션에 얼마나 들어갈 것인지와 에지 라우터 등에서 처리해야 할 사항에 크게 의존합니다...

실제로 kube-system 네임스페이스 내부의 Tayga와 호스트 네트워킹을 사용하는 DaemonSet/Deployment를 사용하여 내부 DNS64가 네트워크 외부로 나가기 위해 tayga를 사용하면 가능할 것이라고 생각합니다.

나에게 해결책처럼 들린다.

우리는 내부적으로 IPv6 전용 네트워크를 운영하며 NAT64/DNS64는 우리에게 아주 잘 작동합니다. IPv6 지원이 전혀 없었던 일부 레거시 항목의 경우 필요한 위치에 직접 clatd를 사용하게 되었습니다. (우리의 경우 VM에서 직접.)

@kacole2 - 1.15에 대해 추적하고 싶습니다. 다음 PR을 병합하기 위해 노력하고 있습니다 - https://github.com/kubernetes/enhancements/pull/808

특히 1.15에서는 다음에 대한 지원을 추가합니다.

• API 유형 수정
  
  
  
  • Kubernetes 유형
  
  
  • CRI 유형
  
  
• 듀얼 스택 포드 네트워킹(다중 IP 포드)
• kubenet 다세대 지원

이정표 추적을 위한 cc @caseydavenport ^

@kacole2 이제 KEP가 병합되었습니다. 1.15에서 이것을 추적하는 데 필요한 다른 것이 있으면 알려주십시오.

Hey @leblancd @lachie83 5월 30일 목요일까지 k/website(branch dev-1.15)에 대한 PR을 찾고 있다는 친절한 알림입니다. 전체 문서의 시작이지만 자리 표시

@kacole2 이제 KEP가 병합되었습니다. 1.15에서 이것을 추적하는 데 필요한 다른 것이 있으면 알려주십시오.

@lachie83 안녕하세요, Lachie, 이번 KEP에서 IPv4/IPv6 듀얼 스택 지원이 종료되었다는 말씀이신가요?

@kacole2 이제 KEP가 병합되었습니다. 1.15에서 이것을 추적하는 데 필요한 다른 것이 있으면 알려주십시오.

사실 k8s 1.15에 듀얼스택 지원이 반드시 추가될지 궁금합니다.

@leblancd k8s.io dev-1.15에 대한 자리 표시자 PR은 5월 30일 목요일에 마감됩니다.

@leblancd k8s.io dev-1.15에 대한 자리 표시자 PR은 5월 30일 목요일에 마감됩니다.

릴리스 1.15에서 듀얼 스택 지원을 사용할 수 있다고 생각할 수 있습니까?

@GeorgeGuo2018 아직 1.15용 향상 시트에 있지만 향상 리드 @kacole2 만이 이에 대한 더 나은 세부 정보를 제공할 수 있습니다.

안녕하세요 @lachie83 @leblancd입니다. 코드 동결은 2019년 5월 30일 목요일 @ EOD PST 입니다. 릴리스에 포함되는 모든 개선 사항 은 테스트를 포함하여 완전한 코드여야 하며 문서 PR이 열려 있어야 합니다.

현재 k/k PR을 모두 나열하여 정지 상태로 가는 것을 추적할 수 있도록 하십시오. PR이 고정으로 병합되지 않으면 이 기능은 1.15 릴리스 주기 동안 미끄러집니다. 릴리스 차단 문제 및 PR만 마일스톤에서 허용됩니다.

원래 게시물에서 kubernetes/kubernetes#62822가 아직 열려 있는 것을 봅니다. 병합될 것으로 예상되는 다른 PR도 있습니까?

이것이 미끄러질 것이라는 것을 알고 있다면 회신하여 저희에게 알려주십시오. 감사 해요!

@simplytunde - 감사합니다. 이번 주에 문서 PR을 함께 모으기 위해 노력하고 있습니다.

@GeorgeGuo2018 - 이것은 다중 릴리스 KEP가 될 것입니다. 1.15에서 1단계 상륙을 계획하고 있습니다. 자세한 내용은 KEP의 구현 계획을 참조하십시오 -

@simplytunde - 여기에 WIP https://github.com/kubernetes/website/pull/14600을 사용하여 초기 자리 표시자 문서 PR을 만들었습니다

@kacole2 핑 주셔서 감사합니다. 우리가 추적 중인 k/k PR(https://github.com/kubernetes/kubernetes/pull/73977)과 초안 문서 PR(https://github.com/)로 1.15 개선 사항 스프레드시트를 업데이트했습니다. kubernetes/website/pull/14600). 우리는 현재 코드 동결 전에 이 PR을 병합하기 위해 계속 진행 중입니다. 내가 다른 것을 놓치면 LMK

@kacole2 @claurence 및 릴리스 팀과 논의한 후 1.15 마일스톤에서 이를 제거하기로 결정했습니다. 계속해서 제거하고 스프레드시트를 적절하게 업데이트하십시오. 지금까지 도와주셔서 감사합니다.

/마일스톤 클리어

@simplytunde 또한 문서 PR에 대해 언급했습니다. 1.15 마일스톤에서도 제거되었는지 확인해 주시겠습니까?

안녕하세요 @lachie83 @leblancd 1.16 인핸스 1.16 추적 스프레드시트에 추가할 수 있도록 알려주십시오.

이정표 날짜는 Enhancement Freeze 7/30 및 Code Freeze 8/29입니다.

감사합니다.

https://github.com/kubernetes/dns/issues/315 는 DNS 서비스 검색 사양에 IPv6/AAAA 추가를 다룹니다.

@lachie83 @leblancd 이것이 추적을 위해 1.16에서 졸업할 것인지 알 수 있습니까?

@evilgenius75 @kacole2 1.16에서 추적해야 합니다. 이 기능은 알파 상태가 됩니다. KEP에 정의된 대로 1단계 및 2단계를 구현합니다. 1.16

추적 KEP

• https://github.com/kubernetes/enhancements/pull/808

병합된 k/k PR(현재 마스터에 있음은 1.16에 있음)

• [통합] 1단계 - https://github.com/kubernetes/kubernetes/pull/73977
• [병합] 1단계 e2e 테스트 - https://github.com/kubernetes/kubernetes/pull/78801
• [병합] 1단계 e2e 테스트 정리 - https://github.com/kubernetes/kubernetes/pull/80001
• 2단계 서비스/엔드포인트 - https://github.com/kubernetes/kubernetes/pull/79386
• 2단계 kube-proxy - https://github.com/kubernetes/kubernetes/pull/79576

관련 PR

• IPv6 지원 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• 1단계 문서 – 도구 예제가 완성되면 다시 열립니다. - https://github.com/kubernetes/website/pull/14600
• [병합] 정리 - 노드 dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• 클러스터 cidrs에 대해 여러 마스크 크기 지원 - https://github.com/kubernetes/kubernetes/pull/79993
• 듀얼스택을 위한 E2e Prow Job https://github.com/kubernetes/test-infra/pull/12966

안녕하세요, @leblancd 저는 v1.16 문서 릴리스 책임자입니다.

이 개선 사항(또는 v1.16에 대해 계획된 작업)에 새로운 문서(또는 수정 사항)가 필요합니까?

8월 23일 금요일까지 k/website (branch dev-1.16)에 대한 PR을 찾고 있음을 알려드립니다. 전체 문서의 시작이라면 좋겠지만 자리 표시자 PR도 허용됩니다. 질문이 있으면 알려주세요!

@simplytunde 는 문서 PR입니다 - https://github.com/kubernetes/website/pull/16010

@lachie83 1.16에 대한 친절한 알림 코드 동결이 8/29 목요일에 있습니다. (당신이 그것을 몰랐던 것처럼). 다음 PR이 아직 미결인 것 같습니다.
2단계 서비스/엔드포인트 - kubernetes/kubernetes#79386
2단계 kube-proxy - kubernetes/kubernetes#79576

관련된:
클러스터 cidr에 대해 여러 마스크 크기 지원 - kubernetes/kubernetes#79993
듀얼스택 kubernetes/test-infra#12966용 E2e Prow Job

안녕하세요 @lachie83 @leblancd https://github.com/kubernetes/kubernetes/pull/79576 및 https://github.com/kubernetes/kubernetes/pull/79993 이 코드 동결 전에 병합되지 않은 것처럼 보입니다. 조수 병합 풀에서 . 이 기능은 v1.16부터 적용됩니다. 이것이 여전히 1.16 릴리스의 일부가 되도록 하려면 예외 를

@kacole2 답변이 늦어 죄송합니다. 주요 PR은 https://github.com/kubernetes/kubernetes/pull/79386 을 추적했습니다 https://github.com/kubernetes/kubernetes/pull/82091(sig-network 와 일치)에 초점을 맞추기로 결정했습니다. KEP에 규정되어 있다. 이 릴리스에서 추적된 다른 관련 PR은 https://github.com/kubernetes/kubernetes/pull/80485 로 병합되었습니다. kubernetes/kubernetes#79993도 1.17로 연기되었습니다.

안녕하세요 @lachie83 @leblancd -- 1.17 개선 사항이 여기에 있습니다. 이 개선 사항이 1.17에서 알파/베타/안정으로 전환될 것이라고 생각하는지 확인하고 싶었습니다.

현재 출시 일정은 다음과 같습니다.

• 9월 23일 월요일 - 출시 주기 시작
• 10월 15일 화요일, EOD PST - 개선 사항 동결
• 11월 14일 목요일, EOD PST - 코드 동결
• 11월 19일 화요일 - 문서를 작성하고 검토해야 합니다.
• 12월 9일 월요일 - Kubernetes 1.17.0 릴리스

그렇다면 이 호에 있는 모든 관련 k/k PR을 나열하여 제대로 추적할 수 있도록 하십시오. 👍

감사 해요!

/마일스톤 클리어

안녕 밥. 문의해 주셔서 감사합니다. 저는 여전히 이 개선 사항의 3단계를 계획하고 있으며 이 작업을 통해 개선 사항이 완성될 것입니다. 이 개선 사항은 이 릴리스가 끝날 때까지 여전히 알파 상태이지만 1.17의 일부로 k/k에 포함될 3단계 관련 작업이 있을 것입니다.

다음은 듀얼 스택용 1.17에 대한 높은 수준의 결과물 목록입니다. 나는 이 목록을 릴리스 내내 업데이트할 것입니다.

• IPtables 듀얼 스택 프록시 - https://github.com/kubernetes/kubernetes/pull/79576
• Pod.Status.PodIPs에 대한 하향 API 지원 - https://github.com/kubernetes/kubernetes/pull/83123
• e2e 테스트 하나의 CNI 플러그인
• 호스트 파일 변경(호스트 이름에 대한 IPv6 주소는 /etc/hosts에 추가해야 함) - https://github.com/kubernetes/kubernetes/pull/83123
• 종류 이중 스택 - https://github.com/kubernetes-sigs/kind/pull/692
• e2e 제품군 업데이트 - https://github.com/kubernetes/kubernetes/pull/80725
• 엔드포인트 슬라이스 지원
• Kubeadm에 대한 듀얼 스택 지원 - https://github.com/kubernetes/kubeadm/issues/1612

감사합니다 @lachie83 ❤️ 추적 시트에 추가하겠습니다.

/마일스톤 v1.17

@mrbobbytables 또한 sig-network를 통해 계획을 전달한 후 KEP의 3단계의 일부로 위에 나열된 작업을 자세히 설명하는 PR 을 추가했습니다. KEP 자체는 여전히 implementable 상태이며 이러한 변경 사항은 특히 1.17의 일부로 계획된 작업을 문서화할 뿐입니다.

어느 시점에서 https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ 가 IPv6 DNS를 다루고 있는지 확인하고 싶습니다. https://github.com/kubernetes/website/issues/15434 는 변경 사항을 추적합니다. 여기에서 언급하여 상호 참조를 기록합니다.

2단계 e2e 테스트를 추가하도록 KEP 업데이트 - https://github.com/kubernetes/enhancements/pull/1311

안녕하세요 @lachie83 저는 v1.17 문서 섀도우 중 한 명입니다.
이 개선 사항(또는 v1.17에 대해 계획된 작업)에 새 문서(또는 기존 문서에 대한 수정)가 필요합니까? 그렇지 않은 경우 1.17 Enhancement Tracker Sheet를 업데이트할 수 있습니까(또는 알려주시면 업데이트하겠습니다)

그렇다면 11월 8일 금요일까지 k/website(branch dev-1.17)에 대한 PR을 찾고 있으며 현재로서는 자리 표시자 PR일 ​​수 있습니다. 질문이 있으면 알려주세요!

@lachie83

문서도구 자리 표시자 PR 마감일이 11월 8일에 가까워지고 있기 때문입니다. k/website dev-1.17 분기에 대해 하나를 얻으십시오.

안녕하세요 @lachie83 , 당신이 계속 탭을 유지하고 있다는 것을 알고 있지만 어쨌든 팝업하여 언급해야합니다 🙈
코드 동결이 코앞에 다가왔습니다(11월 14일). 상황이 어떻습니까? 그 전에 모든 것이 병합될 예정입니까?

감사 해요!

안녕하세요 @mrbobbytables입니다! 핑 주셔서 감사합니다. 우리는 1.17에 도착하기 위해 다음 PR을 추적하고 있습니다. 이 변경 사항과 관련된 PR이 하나 또는 두 개 더 있을 수 있습니다. 이러한 변경에는 문서가 필요합니다. 자리 표시자 문서 PR을 올리겠습니다.

• kube-proxy iptables 모드 pr/82462에 대한 듀얼 스택 지원
• 듀얼스택 하향 API pr/82462
• ipvs metaproxier endpointslice 지원 pr/84089 추가
• kube-controller-manager pr/79993에서 다중 노드 cidr 마스크 허용

@irvifa - 여기에 자리 표시자 문서 PR이 있습니다. https://github.com/kubernetes/website/pull/17457

멋진 감사합니다🎉 @lachie83

@lachie83 내일은 1.17 릴리스 주기의 코드 동결입니다. k/k PR이 아직 병합되지 않은 것 같습니다. 😬 1.17 개선 사항 추적 시트에서 이것을 위험에 처한 것으로 표시하고 있습니다.
14일(목) EoD까지 합쳐질 것 같나요? 그 이후에는 릴리스 차단 문제 및 PR만 예외를 제외하고 마일스톤에서 허용됩니다.

감사합니다 Bob - 오늘 sig-network와 이 문제에 대해 논의하고 업데이트를 제공할 것입니다.

안녕하세요 @mrbobbytables입니다. 다음은 오늘 EoD에서 병합하기 위해 작업 중이며 sig-network에서 승인한 PR 목록입니다.

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

나머지 PR은 1.18로 펀트될 가능성이 가장 높습니다. - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables 는 위에서 언급한 모든 PR이 병합되었으며 실제로 kubernetes/kubernetes#82462를 1.18로 펀트할 것임을 확인했습니다. 이러한 PR이 1.17의 이중 스택 동작에 의미 변경 사항을 추가하므로 이 개선 사항을 계속 추적할 수 있습니다. 이제 문서 PR을 준비하기만 하면 됩니다! 우리는 1.18에서 kubernetes/kubernetes#82462를 출시하고 이 작업을 베타로 진행하기를 희망합니다.

감사합니다 @lachie83!

그리고 라이브입니다! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

우리는 이 개선 사항을 1.18에서 베타로 옮길 계획입니다. 강화 졸업 기준 및 시험 계획은 이 PR과 함께 KEP 에서 찾을 수 있습니다. - https://github.com/kubernetes/enhancements/pull/1429

/마일스톤 1.18

@lachie83 : 제공된 이정표가 이 저장소에 유효하지 않습니다. 이 저장소의 이정표: [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

/milestone clear 를 사용하여 이정표를 지우십시오.

/마일스톤 v1.18

우리는 이 개선 사항을 1.18에서 베타로 옮길 계획입니다. 강화 졸업 기준 및 시험 계획은 이 PR - #1429와 함께 KEP 에서 확인할 수 있습니다.

@lachie83 업데이트에 감사드립니다. 1.18 스프레드시트에서 이를 추적된 것으로 표시했습니다!

1.18에 착륙하는 작업의 일부로 다음 PR을 추적하십시오. https://github.com/kubernetes/kubernetes/pull/82462

추적을 위한 기타 관련 PR 추가:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

@lachie83 감사합니다!

@lachie83 님 , 위에서 언급한 것 외에 추적해야 할 다른 PR이 있습니까?

안녕하세요, @lachie83 @leblancd - 저는 1.18 릴리스 팀의 문서 섀도우입니다.

1.18에 대해 계획된 이 개선 작업에 새로운 문서나 기존 문서의 수정이 필요합니까?

그렇지 않은 경우 1.18 Enhancement Tracker Sheet를 업데이트할 수 있습니까(또는 알려주시면 업데이트하겠습니다)

문서 업데이트가 필요한 경우 k/website(branch dev-1.18)에 대한 자리 표시자 PR이 2월 28일 금요일까지 마감된다는 점을 상기하십시오.

질문이 있으면 알려주세요!

누군가 v1.18에 대한 IPV6 또는 이중 스택 항목을 문서화하는 데 도움이 필요하면 저에게 살짝 알려주세요. 내가 도울 수 있을지도 몰라.

안녕하세요 @lachie83 ,

kubernetes-sig/kind#692가 아직 병합되지 않은 것 같습니다. 그것이 베타 졸업에 중요합니까?

안녕하세요 @jeremyrickard @sethmccombs 이 PR https://github.com/kubernetes/kubernetes/pull/86895를 감안할 때 졸업에서 베타로 전환해야 합니다

/마일스톤 클리어

@ lachie83 업데이트해주셔서 감사합니다. 이 개선 사항을 이정표에서 제거했습니다. 1.19일을 기다립니다. :)

듀얼스택 강화 상태가 1.18.1에서도 alpha 로 유지되는 것을 확인하고 싶습니다. 저는 현재 커뮤니티와 협력하여 1.19에서 완료될 예정인 작업을 평가하고 있습니다. 이 개선 사항은 1.19에서도 여전히 알파 상태로 유지될 가능성이 높지만 확인하고 싶습니다. 또한 1.18 문서의 개선 상태를 반영하도록 문서를 업데이트하는 조치를 취하겠습니다.

웹사이트에 듀얼 스택 Kubernetes를 베타로 표시하는 페이지가 있는 경우 k/website 에 대해 우선순위/중요한 버그로 제출하십시오.

안녕하세요 @lachie83 -- 1.19 개선 사항 리드, 이 개선 사항이 1.19에서 종료될 것이라고 생각하는지 확인하고 싶었습니다.

현재 출시 일정은 다음과 같습니다.

• 4월 13일 월요일: 1주차 - 출시 주기 시작
• 5월 19일 화요일: 6주차 - 개선 사항 동결
• 6월 25일 목요일: 11주차 - 코드 동결
• 7월 9일 목요일: 14주차 - 문서를 작성하고 검토해야 합니다.
• 8월 4일 화요일: 17주차 - Kubernetes v1.19.0 릴리스

웹사이트에 듀얼 스택 Kubernetes를 베타로 표시하는 페이지가 있는 경우 k/website 에 대해 우선순위/중요한 버그로 제출하십시오.

@sftim 1.17과 1.18의 릴리스 레이블을 해결하기 위해 두 개의 PR을 올렸습니다.

@palnabarun 우리는 듀얼스택 KEP를 1.19 릴리스 기간에 업데이트하기 위해 노력하고 있지만 현재로서는 1.19 릴리스에서 코드 변경 사항을 상륙할 것이라고 생각하지 않습니다. 이미 완료된 작업에 차단 문제가 하나 있습니다( alpha 상태 덕분에). 차단 문제는 https://github.com/kubernetes/kubernetes/pull/86895입니다. 다음 KEP 업데이트 https://github.com/kubernetes/enhancements/pull/1679 를 통해 이 문제를 해결할 계획이지만 제안된 변경 사항에 대한 합의를 얻는 데 시간이 걸릴 것입니다. 이 단계에서 듀얼 스택 향상은 현재 구현에서 이 차단 문제를 해결할 때까지 alpha 상태로 유지됩니다. 진행 상황에 따라 업데이트를 제공하겠습니다.

업데이트에 대해 Lachie에게 감사드립니다. 모든 노력에 감사드립니다! :약간_웃는_얼굴:

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

이 개선 사항이 1.20에서 추적되기를 바랍니다. 업데이트된 kep( https://github.com/kubernetes/enhancements/pull/1679) 에 따라 알파 상태로 다시 구현됩니다 https://github.com/kubernetes/kubernetes/pull/91824. 검토를 완료하고 1.20 릴리스 주기의 초기에 PR을 병합할 계획입니다.

9월 17일 SIG 네트워크 회의에서 논의된 대로 집에서 함께 플레이하는 사람들을 위한 베타 상태로의 최신 듀얼 스택 졸업:

• kubelet 이중 스택 상태 확인 모호성을 해결해야 합니다. https://github.com/kubernetes/enhancements/pull/1975 를 통해
• 기존 이중 스택 서비스 PR을 완료하고 병합해야 합니다(활성 검토 중). https://github.com/kubernetes/kubernetes/pull/91824 를 통해
• 이중 스택 노드 IP의 동작을 완료해야 합니다. https://github.com/kubernetes/enhancements/pull/1665 를 통해
• 서비스의 Spec.LoadBalancerIPs 필드에 필요한 변경 사항(있는 경우)을 결정해야 합니다.

이 모든 항목은 적극적으로 작업 중이며 1.20은 여전히 ​​이중 스택 API 베타 졸업의 대상입니다. 그러나 우리의 최선의 노력에도 불구하고 제 시간에 해결되지 않을 가능성이 항상 있으며, 그렇다면 SIG Network는 공개 회의에서 베타로의 졸업을 계속할지 여부를 결정할 것입니다. 모두 가입을 환영합니다.

@dcbw 업데이트에 대해 대단히 감사합니다(전화를 걸 수 없어 죄송합니다). 이것을 1.20에서 베타로 개선하거나 단순히 알파로 유지하는 것이 의미가 있습니까? 베타로 가고 싶다면 이것이 재구현이라는 점을 감안할 때 KEP의 졸업 기준이 여전히 의미가 있습니다. https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#졸업 기준

@dcbw 업데이트에 대해 대단히 감사합니다(전화를 걸 수 없어 죄송합니다). 이것을 1.20에서 베타로 개선하거나 단순히 알파로 유지하는 것이 의미가 있습니까? 베타로 가고 싶다면 이것이 재구현이라는 점을 감안할 때 KEP의 졸업 기준이 여전히 의미가 있습니다. https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#졸업 기준

그러나 실제로 다시 구현하지는 않습니다. 이전 작업은 모두 여전히 유효하며 1.20의 작업은 확인된 마지막 변경 사항을 마무리하기 위해 그 위에 구축되고 있습니다. sig-network 토론에 대한 나의 해석은 @dcbw가 게시한 목록이 졸업을 위해 해결해야 하는 남아 있는 알려진 문제의 집합이라는 것입니다.

안녕하세요 여러분,

1.20 Enhancements Lead 여기에서 추적으로 설정하겠습니다. 변경 사항이 있으면 업데이트해 주세요. :)

참고로 Enhancements Freeze는 10월 6일입니다.

참고로 KEP는 https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template으로 업데이트한 이전 형식을 사용하고

최상의,
커스틴

/마일스톤 v1.20

안녕하세요, @russellb -

그러나 실제로 다시 구현하지는 않습니다. 이전 작업은 모두 여전히 유효하며 1.20의 작업은 확인된 마지막 변경 사항을 마무리하기 위해 그 위에 구축되고 있습니다.

https://github.com/kubernetes/kubernetes/pull/91824의 API 변경 사항을 감안할 때 듀얼 스택을 1.20용 알파로 표시하면 필요한 것으로 입증된 추가 재구현을 위한 공간이 허용될 만큼 충분히 다릅니다. 우리 모두가 베타를 열망한다는 것을 알고 있지만 먼저 +9,319 −3,261 PR을 시작하고 먼지가 가라앉도록 합시다. :)

kubernetes/kubernetes#91824 의 API 변경 사항을 감안할 때 듀얼 스택을 1.20용 알파로 표시하면 필요한 것으로 입증된 추가 재구현을 위한 공간이 허용될 만큼 충분히 다릅니다. 우리 모두가 베타를 열망한다는 것을 알고 있지만 먼저 +9,319 −3,261 PR을 시작하고 먼지가 가라앉도록 합시다. :)

@bridgetkromhout 예, API 준비 상태에 대한 결정을 내리기 전에 https://github.com/kubernetes/kubernetes/pull/91824 에 착륙해야 합니다. 최대한 빨리 할 수 ​​있기를 바랍니다.

안녕하세요 여러분,

1.20 인핸스먼트 섀도우 👋

이 개선 사항은 1.20에 있을 예정이므로 다음 중요 날짜를 염두에 두십시오.
11월 6일 금요일: 8주차 - 문서 자리 표시자 PR 마감
11월 12일 목요일: 9주차 - 코드 동결

다시 말씀드리지만 모든 k/k PR과 문서 PR을 이 문제에 연결하여 추적할 수 있도록 하십시오.

감사합니다!

안녕하세요 @kinarashah @kikisdeliveryservice - sig-network 호출에서 1.20에서 알파로 재분류되어야 함을 확인했습니다. 알파 단계에서 담그고 테스트하는 데 시간이 필요한 완전한 재구현입니다.

안녕하세요 @lachie83 , 1.20 문서도구 섀도우입니다.

1.20에 계획된 이 개선 작업에 새로운 문서나 기존 문서의 수정이 필요합니까?

그렇다면 여기 의 단계에 따라 k/website 리포지토리의 dev-1.20 분기에 대한 PR을 여십시오. 이 PR은 현재 자리 표시자일 수 있으며 11월 6일 이전에 생성되어야 합니다.

또한 릴리스 에 대한 문서 요구 사항에 익숙해지도록

감사합니다!

@reylejano-rxm 감사합니다 - kubernetes/website#24725를 열었습니다.

안녕하세요 @lachi83

문서 PR을 만들어 주셔서 감사합니다!

중요한 다가오는 날짜를 염두에 두십시오.

• 11월 6일 금요일: 8주차 - 문서 자리 표시자 PR 마감 완료!
• 11월 12일 목요일: 9주차 - 코드 동결
• 11월 23일 월요일: 11주차 - 문서 PR 검토 준비 완료

참고로 릴리스 팀에서 추적할 수 있도록 모든 k/k PR과 문서 PR을 이 문제에 연결하세요.

안녕하세요 @kinarashah @kikisdeliveryservice - sig-network 호출에서 1.20에서 알파로 재분류되어야 함을 확인했습니다. 알파 단계에서 담그고 테스트하는 데 시간이 필요한 완전한 재구현입니다.

안녕하세요 @lachie83

위의 내용을 감안할 때 이것이 여전히 알파를 그대로 사용한다고 가정합니까? 병합/작업이 이미 병합된 미해결 PR이 표시되지 않습니다.

_ 코드 프리즈(Code Freeze) 가 11월 12일(목) 2일 후에 온다는 사실을 알려드립니다. 모든 PR은 해당 날짜까지 병합되어야 합니다. 그렇지 않으면 예외 가 필요합니다._

감사 해요!
커스틴

안녕하세요, @kikisdeliveryservice - 예, IPv4/IPv6 이중 스택 지원(재구현)은 1.20의 알파 버전입니다.

이 개선 사항에 대한 진행 상황은 다음과 같습니다.

1) 코드는 https://github.com/kubernetes/kubernetes/pull/91824에서 병합됩니다 - 1.20의 알파 버전입니다.
2) 해당 코드 변경을 다루는 문서 업데이트는 https://github.com/kubernetes/website/pull/24725/ 에

이 개선 사항에 대해 완료하지 않은 1.20에 필요한 다른 것이 있습니까?

@bridgetkromhout 명확한 업데이트에 감사드립니다. 모두

ServiceSpec LoadBalancerIP 는 아직 이중 스택 구현의 일부가 아닌 것 같습니다. 지원할 계획이 있습니까 아니면 놓쳤습니까?

안녕하세요 @chenwng - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#load -

KEP를 수정해야 하는지 이해하고 결정하기 위해 사용 사례와 제안된 변경 사항을 제공하여 도움을 줄 수 있습니다.

@chenwng 이중 스택 클러스터에서 LoadBalancerIPs 에 대해 작업 중인 KEP가 있습니다 - https://github.com/kubernetes/enhancements/pull/1992

@aramase , @lachie83 정보 감사합니다.