/sig 노드
/종류 기능
cc @ConnorDoyle @balajismaniam @nolancon

나는 Borg에서 배운 것을 바탕으로 이 디자인을 알리는 데 도움을 줄 수 있습니다. 따라서 저를 검토자/승인자로 간주하십시오.

나는 Borg에서 배운 것을 바탕으로 이 디자인을 알리는 데 도움을 줄 수 있습니다. 따라서 저를 검토자/승인자로 간주하십시오.

이 기능이 borg에서 작동하는 방식에 대한 공개 문서가 있습니까?

NUMA AFAIK에 관한 것이 아닙니다.

2019년 2월 11일 월요일 오전 7:50 Jeremy Eder < [email protected] 작성:

나는 Borg에서 배운 것을 바탕으로 이 디자인을 알리는 데 도움을 줄 수 있습니다. 그러니 나를 세어봐
검토자/승인자로

이 기능이 borg에서 작동하는 방식에 대한 공개 문서가 있습니까?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/enhancements/issues/693#issuecomment-462378195 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AGvIKPfanjb9Q5DxXAiBgv9C6Y809JX0ks5vMZFZgaJpZM4aE3uz
.

참고로 @claurence

이 추적 문제와 KEP(https://github.com/kubernetes/enhancements/pull/781)는 v1.14 개선 사항이 중단되거나 연장된 기한에 이르지 못했습니다. 마감일 전에 열어주셔서 감사하지만 충분한 검토나 승인을 받지 못한 것 같습니다. 예외 처리를 거쳐야 합니다.

이것이 예외적 가치가 있는지 여부를 결정할 때까지 저는 이 개선 사항과 관련된 모든 PR을 보류하려고 합니다.

참조: https://github.com/kubernetes/kubernetes/issues/72828

/cc @jiayingz @dchen1107

@lmdaly 설명에 1.14가 알파 마일스톤으로 나열되어 있는 것을 알 수 있습니다. 구현 가능한 병합된 KEP가 없었기 때문에 이 문제는 1.14에 대해 추적되지 않습니다. 해당 릴리스에 포함될 의도가 있는 경우 예외 요청을 제출하십시오.

@lmdaly 설명에 1.14가 알파 마일스톤으로 나열되어 있는 것을 알 수 있습니다. 구현 가능한 병합된 KEP가 없었기 때문에 이 문제는 1.14에 대해 추적되지 않습니다. 해당 릴리스에 포함될 의도가 있는 경우 예외 요청을 제출하십시오.

@claurence KEP가 이제 병합되었습니다(KEP는 이전에 커뮤니티

디자인 및 WIP PR을 꼼꼼히 읽은 후 현재 구현이 https://github.com/kubernetes/enhancements/pull/781 에서 제안한 원래 토폴로지 디자인처럼 일반적이지 않다는 우려가

여기에 추가 토론을 위해 몇 가지 의견을 남겼습니다. https://github.com/kubernetes/kubernetes/pull/74345#discussion_r264387724

현재 구현은 일반적이지 않습니다

그것에 대해 같은 우려를 공유하십시오 :) 다른 사람들은 어떻습니까, 예를 들어 장치 간의 링크(GPU의 경우 nvlink)?

@resouer @k82cn 초기 제안은 컨테이너가 실행되는 CPU와 장치의 근접성을 보장하기 위해 CPU 관리자와 장치 관리자가 내린 결정을 조정하는 것뿐입니다. 장치 간 친화성을 만족시키는 것은 제안의 목표가 아니었습니다.

그러나 현재 구현이 향후 장치 간 선호도 추가를 차단하는 경우 구현 방식을 이해하면 구현을 변경하게 되어 기쁩니다.

현재 구현과 장치 간 선호도를 지원하는 기능에서 볼 수 있는 주요 문제는 다음과 같습니다.

장치 간 선호도를 지원하려면 일반적으로 컨테이너에 어떤 소켓 선호도를 갖기를 원하는지 결정하기 _전에_ 컨테이너에 할당하려는 장치를 먼저 파악해야 합니다.

예를 들어 Nvidia GPU의 경우 최적의 연결을 위해 가장 많이 연결된 NVLINK가 있는 GPU 세트를 찾아 할당해야 합니다.

현재 제안에서 말할 수 있는 것에서 가정은 이러한 작업이 역순으로 발생한다는 것입니다. 즉, 장치 할당을 수행하기 전에 소켓 선호도가 결정됩니다.

그것이 반드시 사실은 아닙니다. @klueska. 토폴로지 힌트가 지점간 장치 토폴로지를 인코딩하도록 확장된 경우 장치 관리자는 소켓 선호도를 보고할 때 이를 고려할 수 있습니다. 즉, 교차 장치 토폴로지가 장치 관리자의 범위를 벗어날 필요가 없습니다. 그것이 실현 가능한 것 같습니까?

왠지 흐름이 헷갈릴 수도 있어요. 내가 이해하는 방법은 다음과 같습니다.

1) 초기화 시 장치 플러그인( devicemanager 아님)은 나중에 콜백을 실행할 수 있도록 topologymanager 자신을 등록합니다.

포드가 제출되면 2) kubelet는 호출 lifecycle.PodAdmitHandler 온 topologymanager .

3) lifecycle.PodAdmitHandler 는 등록된 각 장치 플러그인에서 GetTopologyHints 를 호출합니다.

4) 그런 다음 이러한 힌트를 병합하여 포드와 연결된 통합 TopologyHint 을 생성합니다.

5) Pod를 승인하기로 결정했다면 Pod에 대한 통합 TopologyHint 을 로컬 state store에 저장한 lifecycle.PodAdmitHandler 에서 성공적으로 반환됩니다.

6) 미래의 어떤 시점에서 cpumanager 와 devicemanager 는 topology 매니저에서 GetAffinity(pod) 를 호출하여 연관된 TopologyHint 를 검색합니다. 포드와 함께

7) cpumanager 는 이 TopologyHint`를 사용하여 CPU를 할당합니다.

8) devicemanager 는 이 TopologyHint`를 사용하여 장치 세트를 할당합니다.

9) Pod 초기화 계속...

이것이 맞다면 장치 플러그인이 TopologyHints 보고하는 시점과 devicemanager 가 실제 할당을 수행하는 시점 사이에 무슨 일이 일어나는지 고민하고 있는 것 같습니다.

이러한 힌트가 할당에 대한 "기본 설정"을 인코딩하기 위한 것이라면 다음과 같은 구조를 갖고 있다고 생각합니다.

type TopologyHints struct {
    hints []struct {
        SocketID int
        DeviceIDs []int
    }
}

소켓 선호도 기본 설정 목록을 전달할 뿐만 아니라 해당 소켓 선호도 기본 설정이 할당 가능한 GPU 기본 설정과 쌍을 이루는 방식입니다.

이것이 당신이 생각하는 방향이라면 우리가 그것을 작동시킬 수 있다고 생각하지만 cpumanager 와 devicemanager 사이를 어떻게든 조정하여 그들이 동일하게 "수락"했는지 확인해야 합니다. 할당할 때 힌트를 줍니다.

내가 놓친 이미 이것을 허용하는 무언가가 있습니까?

@klueska

흐름을 _사소하게_ 수정하면 어떤 일이 발생하는지 생각합니다.

1. 초기화 시 장치 플러그인은 나중에 콜백을 실행할 수 있도록 devicemanager 자신을 등록합니다.

2. lifecycle.PodAdmitHandler 는 현재 devicemanager 및 cpumanager Kubelet의 각 토폴로지 인식 구성 요소에서 GetTopologyHints 를 호출합니다.

이 경우 Kubelet에서 토폴로지 인식으로 표시되는 것은 cpumanager 및 devicemanager 입니다. 토폴로지 관리자는 토폴로지 인식 구성 요소 간의 할당을 조정하기 위한 용도로만 사용됩니다.

이를 위해:

그러나 우리는 cpumanager와 devicemanager가 할당할 때 동일한 힌트를 "수락"했는지 확인하기 위해 어떻게든 조정해야 합니다.

이것이 topologymanager 자체가 달성하기 위해 도입된 것입니다. 이전 초안 중 하나에서 ,

이러한 구성 요소는 교차 NUMA 할당을 피하기 위해 조정되어야 합니다. 이 조정과 관련된 문제는 까다롭습니다. "할당된 NIC와 동일한 NUMA 노드에 있는 독점 코어"와 같은 도메인 간 요청에는 CNI와 CPU 관리자가 모두 포함됩니다. CPU 관리자가 먼저 선택하면 사용 가능한 NIC가 없는 NUMA 노드에서 코어를 선택할 수 있으며 그 반대의 경우도 마찬가지입니다.

내가 참조.

이렇게 devicemanager 및 cpumanager 모두 구현 GetTopologyHints() 아니라 통화로 GetAffinity() 상기 행 방향으로 작용 회피 topologymanager 되는 하부 디바이스 플러그인으로 . 코드를 더 자세히 살펴보면 devicemanager 가 TopologyHints 채우는 데 도움이 되도록 플러그인에 제어를 위임한다는 것을 알 수 있습니다. 이는 결국 더 합리적입니다.

내가 제기 한 원래 질문 / 문제로 돌아가서 ....

Nvidia의 관점에서 볼 때 TopologyHints 구조체(결과적으로 장치 플러그인 인터페이스)에 더 많은 정보가 추가되어 향후 지점 간 링크 정보를 보고한다고 가정하면 이 제안된 흐름으로 모든 것이 작동하도록 할 수 있다고 생각합니다. .

그러나, 나는으로 시작 생각 SocketMask 확장 할 수있는 능력이 제한 될 수 광고 소켓 선호도에 대한 기본 데이터 구조로 TopologyHints 기존의 인터페이스를 파괴하지 않고 미래와 포인트 - 투 - 포인트 정보를 표시합니다. 주된 이유는 (적어도 Nvidia GPU의 경우) 기본 소켓이 결국 실제로 할당될 GPU에 달려 있기 때문입니다.

예를 들어 최적의 연결성을 가진 포드에 2개의 GPU를 할당하려고 할 때 아래 그림을 고려하십시오.

(2, 3) 및 (6, 7)의 GPU 조합에는 둘 다 2개의 NVLINK가 있고 동일한 PCIe 버스에 상주합니다. 따라서 포드에 2개의 GPU를 할당하려고 할 때 동일한 후보로 간주되어야 합니다. 그러나 선택되는 조합에 따라 (2, 3)이 소켓 0에 연결되고 (6, 7)이 소켓 1에 연결되므로 다른 소켓이 분명히 선호됩니다.

이 정보는 devicemanager 가 결국 원하는 할당 중 하나를 수행할 수 있도록 TopologyHints 구조체에 인코딩해야 합니다(즉, topologymanager 중 하나가 힌트를 통합하는 아래로). 마찬가지로 기본 장치 할당과 기본 소켓 간의 종속성은 TopologyHints 로 인코딩되어야 cpumanager 가 올바른 소켓에서 CPU를 할당할 수 있습니다.

이 예에서 Nvidia GPU와 관련된 잠재적 솔루션은 다음과 같습니다.

type TopologyHint struct {
    SocketID int
    DeviceIDs []int
}

type TopologyHints []TopologyHint

devicemanagerhints := &TopologyHints{
    {SocketID: 0, DeviceIDs: []int{2, 3}},
    {SocketID: 1, DeviceIDs: []int{6, 7}},
}

cpumanagerhints := &TopologyHints{
    {SocketID: 1},
}

여기서 topologymanager 는 devicemanager 및 cpumanager 나중에 GetAffinity() 호출할 때 기본 힌트로 {SocketID: 1, DeviceIDs: []int{6, 7}} 를 반환하도록 이러한 힌트를 통합합니다.

하면서 수도 있고 교체, 모든 가속기에 대한 일반적인 충분한 해결책을 제공하지 않을 수 있습니다 SocketMask 에서 TopologyHints 구조체 우리가 더 필드 각각의 힌트를 확장 할 수있는 것보다 다음과 같은 구조 뭔가 미래:

하는 것으로 GetTopologyHints() 여전히 반환 TopologyHints 하면서, GetAffinity() 단일 반환하도록 수정되었습니다 TopologyHint 보다는 TopologyHints .

type TopologyHint struct {
    SocketID int
}

type TopologyHints []TopologyHint

&TopologyHints{
    {SocketID: 0},
    {SocketID: 1},
}

type HintProvider interface {
    GetTopologyHints(pod v1.Pod, container v1.Container) TopologyHints
}

type Store interface {
    GetAffinity(podUID string, containerName string) TopologyHint
}

생각?

@klueska 어쩌면 내가 뭔가를 놓치고

장치 플러그인 API가 @ConnorDoyle이 제안한 대로 장치가 지점 간 장치 연결에 대한 정보를 다시 보낼 수 있도록 확장된 경우 장치 관리자는 이를 기반으로 소켓 정보를 다시 보낼 수 있습니다.

귀하의 예에서 devicemanagerhints 는 장치 플러그인이 devicemanager로 다시 보낸 정보일 수 있습니다. 그런 다음 장치 관리자는 소켓 정보를 현재와 같이 TopologyManager에 다시 보내고 TopologyManager는 선택한 소켓 힌트를 저장합니다.

할당 시 devicemanager는 GetAffinity를 호출하여 원하는 소켓 할당(이 경우 소켓이 1이라고 가정함)을 가져오고 이 정보와 장치 플러그인에서 다시 보낸 정보를 사용하여 소켓 1에서 장치를 할당해야 함을 알 수 있습니다( 6,7) NV Link 장치이기 때문입니다.

그게 말이 됩니까 아니면 제가 놓치고 있는 것이 있습니까?

시간을 내어 이 문제를 해결해 주셔서 감사합니다. @ConnorDoyle 의 원래 제안을 잘못 해석

토폴로지 힌트가 지점간 장치 토폴로지를 인코딩하도록 확장된 경우 장치 관리자는 소켓 선호도를 보고할 때 이를 고려할 수 있습니다.

TopologyHints 구조체를 point-to-point 정보로 직접 확장하고 싶다고 읽었습니다.

devicemanager 포인트-투-포인트 정보를 제공하기 위해 장치 플러그인 API만 확장되어야 한다고 제안하는 것 같습니다. 그래야 이 정보를 사용하여 SocketMask 에 알릴 수 있습니다 GetTopologyHints() 가 호출될 때마다 TopologyHints 구조체에 설정합니다.

장치 플러그인에 대한 API 확장이 위의 예에서 설명한 것과 유사한 정보를 제공하도록 설계되고 devicemanager 가 확장되어 포드 승인과 장치 사이에 이 정보를 저장하는 한 이것이 작동할 것이라고 생각합니다. 할당 시간.

지금 우리는 Nvidia에서 kubelet 를 패치하여 귀하가 제안한 것을 본질적으로 수행하는 맞춤형 솔루션을 보유하고 있습니다(단, 장치 플러그인에 대한 결정을 devicemanager GPU를 인식하고 토폴로지 기반 GPU 할당 결정을 자체적으로 내림).

우리는 장기적인 해결책이 무엇이든 앞으로 이러한 사용자 지정 패치를 제거할 수 있도록 하고 싶습니다. 이제 여기의 흐름이 어떻게 작동하는지 더 잘 알게 되었기 때문에 우리를 방해할 만한 어떤 것도 보이지 않습니다.

시간을 내어 모든 것을 명확히 해 주셔서 다시 한 번 감사드립니다.

안녕하세요 @lmdaly , 저는 1.15의 Enhancement Lead입니다. 이 기능이 1.15에서 알파/베타/안정 단계를 졸업하게 됩니까? 제대로 추적하고 스프레드시트에 추가할 수 있도록 알려주세요.

코딩이 시작되면 이 호에 있는 모든 관련 k/k PR을 나열하여 올바르게 추적할 수 있도록 하십시오.

이 기능은 자체 기능 게이트가 되며 알파가 됩니다.

/마일스톤 1.15

@derekwaynecarr : 제공된 이정표가 이 저장소에 유효하지 않습니다. 이 저장소의 이정표: [ keps-beta , keps-ga , v1.14 , v1.15 ]

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

/마일스톤 v1.15

/할당 @lmdaly

https://github.com/kubernetes/kubernetes/issues/72828

코드 PR

@lmdaly
https://github.com/kubernetes/kubernetes/issues/72828
우리 팀과 나는 숫자에 민감한 응용 프로그램에 대해 토폴로지 관리자를 테스트하는 것을 고려합니다.
질문이 있습니다.
PR 위에 토폴로지 관리자를 위한 완전한 의미가 있습니까?
그리고 지금 테스트했거나 안정적입니까?

@bg-chun 우리도 Nvidia에서 같은 일을 하고 있습니다. 이러한 WIP PR을 내부 스택으로 가져오고 주변의 CPU/GPU에 대한 토폴로지 인식 할당 전략을 구축했습니다. 그렇게 함으로써 우리는 몇 가지 문제를 발견하고 이러한 PR에 대한 몇 가지 구체적인 피드백을 제공했습니다.

자세한 내용은 여기에서 토론 스레드를 참조하십시오.
https://kubernetes.slack.com/archives/C0BP8PW9G/p1556371768035800

안녕하세요, @lmdaly 저는 v1.15 문서 릴리스 섀도우입니다.

1.15 릴리스에 대한 이 개선 사항의 알파 버전을 목표로 하고 있는 것으로 나타났습니다. 새로운 문서(또는 수정)가 필요합니까?

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

@lmdaly 5월 30일 목요일까지 k/website (branch dev-1.15)에 대한 PR을 찾고 있음을

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

https://github.com/kubernetes/kubernetes/issues/72828 에서 모두 병합되었는지 확인합니다.

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

@daminisatya 문서 PR을 푸시했습니다. https://github.com/kubernetes/website/pull/14572

올바르게 수행되었는지 그리고 추가로 수행해야 할 항목이 있으면 알려주십시오. 알림 주셔서 감사합니다!

@lmdaly 감사합니다 ✨

@lmdaly 안녕하세요. 오늘은 1.15 릴리스 주기의 코드 동결입니다. 추적 문제 https://github.com/kubernetes/kubernetes/issues/72828 에서 아직 병합되지 않은 k/k PR이 여전히 꽤 1.15 개선 사항 추적 시트 에서 위험에 처한 것으로 표시됩니다. 이것이 오늘 EOD PST에 의해 병합될 것이라는 확신이 있습니까? 이 시점 이후에는 예외를 제외하고 릴리스 차단 문제와 PR만 마일스톤에서 허용됩니다.

/마일스톤 클리어

안녕하세요 @lmdaly @derekwaynecarr , 저는 1.16 Enhancement Lead입니다. 이 기능이 1.16에서 알파/베타/안정 단계를 졸업하게 됩니까? 1.16 추적 스프레드시트에 추가할 수 있도록 알려주십시오. 졸업하지 않은 경우 이정표에서 제거하고 추적 레이블을 변경합니다.

코딩이 시작되거나 이미 코딩이 시작되면 이 호에 있는 모든 관련 k/k PR을 나열하여 올바르게 추적할 수 있도록 하십시오.

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

감사합니다.

@kacole2 알림 주셔서 감사합니다. 이 기능은 1.16에서 알파로 포함될 예정입니다.

진행 중인 PR 목록은 https://github.com/kubernetes/kubernetes/issues/72828 에서 확인할 수 있습니다.

감사 해요!

이것이 1.16용 알파 버전에 포함될 것이라는 데 동의하고 이전에 1.15용으로 병합된 kep에서 시작되고 캡처된 작업을 종료합니다.

안녕하세요 @lmdaly , 저는 v1.16 문서 릴리스 섀도우입니다.

이 개선 사항에 새로운 문서(또는 수정 사항)가 필요합니까?

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

감사 해요!

문서 홍보: https://github.com/kubernetes/website/pull/15716

@lmdaly 토폴로지 관리자는 주어진 포드에 대한 NUMA 구성을 사용자에게 알려주는 정보나 API를 제공합니까?

@mJace kubectl을 통해 볼 수 있는 무언가가 포드에 대해 설명합니까?

@lmdaly 네, kubectl describe 좋습니다. 또는 관련 정보를 반환하는 일부 API.
포드에 대한 CPU 고정 상태 및 통과된 VF에 대한 numa 노드와 같은 포드에 대한 토폴로지 관련 정보를 제공하는 서비스를 개발 중이기 때문입니다.
그리고 weave 스코프와 같은 일부 모니터 도구는 API를 호출하여 멋진 작업을 수행할 수 있습니다.
예를 들어 관리자는 VNF가 적절한 numa 구성에 있는지 알 수 있습니다.

Topology Manager가 이 부분을 다룰 것인지 알고 싶습니다.
또는 Topology Manager가 이러한 종류의 기능을 지원할 계획이라면 우리가 할 수 있는 일이 있다면.

@mJace 알겠습니다. 현재 Topology Manager와 같은 API는 없습니다. CPU 및 장치 관리자의 경우 실제로 포드에 할당된 항목에 대한 가시성이 없기 때문에 이에 대한 우선 순위가 없다고 생각합니다.

그래서 이에 대한 논의를 시작하고 유저들에게 어떤 시각을 줄 수 있을지 생각해 보는 것이 좋을 것 같습니다.

CPU 및 장치 관리자가 이 정보를 볼 수 있다고 생각했습니다.

아마도 캐드바이저는 이 정보를 제공하는 좋은 역할일 것입니다.
기본적으로 cadvisor는 ps ls PID 등의 컨테이너 정보를 가져오기 때문입니다.
그리고 컨테이너의 토폴로지 관련 정보를 확인하는 것과 같은 방식입니다.
나는 이것을 cadvisor에서 구현하고 pr을 만들 것입니다.

cadvisor에서 관련 문제를 만들었습니다.
https://github.com/google/cadvisor/issues/2290

/양수인

@mJace cadvisor 제안에 +1.

CPU Manager 및 Topology Manager 컨테이너 내부에서 DPDK 라이브러리를 사용하려면 컨테이너의 CPU 선호도를 구문 분석한 다음 dpdk 라이브러리에 전달하는 두 가지 모두 DPDK 라이브러리의 스레드 고정에 필요합니다.

자세한 내용은 컨테이너의 cgroup cpuset 하위 시스템에서 CPU가 허용되지 않는 경우 CPU에서 프로세스를 고정하기 위해 sched_setaffinity 에 대한 호출이 필터링됩니다.
DPDK lib는 스레드 고정에 pthread_setaffinity_np 를 사용하고 pthread_setaffinity_np 는 sched_setaffinity 의 스레드 수준 래퍼입니다.
그리고 Kubernetes의 CPU Manager는 컨테이너의 cgroup cpuset 하위 시스템에 독점적인 CPU를 설정합니다.

@bg-chun cadvisor 변경은 모니터링이라는 다른 목적을 제공하는 것으로 이해했습니다. 요구 사항에 따라 '/proc/self/status'에서 'Cpus_Allowed' 또는 'Cpus_Allowed_List'를 구문 분석하여 컨테이너 내부에서 할당된 CPU를 읽을 수 있습니다. 그 접근 방식이 효과가 있습니까?

Cpus_Allowed 와 같은 /proc/*/status 의 @ConnorDoyle 정보는 sched_setaffinity 영향을 받습니다. 따라서 애플리케이션이 무언가를 설정하면 Cgroup의 cpuset 컨트롤러에서 실제로 허용하는 것의 하위 집합이 됩니다.

@kad , 나는 컨테이너 내의 실행기가 DPDK 프로그램에 전달할 cpu id 값을 찾는 방법을 제안하고 있었습니다. 따라서 이것은 스레드 수준 선호도가 설정되기 전에 발생합니다.

@ConnorDoyle
제안해 주셔서 감사합니다. 고려해 보겠습니다.
내 계획은 dpdk-container에 독점적인 CPU 할당 정보를 알려주기 위해 tiny-rest-api 서버를 배포하는 것이었습니다.

변경 사항에 대해서는 아직 cadvisor 변경 사항을 보지 못하고 제안서 만 봅니다.
제안서에는 목표에 able to tell if there is any cpu affinity set for the container. to tell if there is any cpu affinity set for the container processes. , 향후 작업에

제안서를 읽은 후 cadvisor가 cpu 고정 정보를 구문 분석하고 kubelet이 이를 status.podIP , metadata.name 및 limits.cpu 와 같은 환경 변수 로 컨테이너에 전달할 수 있다면 좋을 것이라고 생각했습니다 status.podIP limits.cpu .
그것이 내가 +1을 남긴 주된 이유입니다.

@bg-chun cadvisor에서 나의 첫 홍보를 확인하실 수 있습니다
https://github.com/google/cadvisor/pull/2291

에서 비슷한 기능을 완료했습니다.
https://github.com/mJace/numacc
하지만 cadvisor에서 구현하는 적절한 방법이 무엇인지 잘 모르겠습니다.
그렇기 때문에 하나의 새로운 기능으로 PR을 작성 -> PSR 표시.

하지만 cadvisor에서 구현하는 적절한 방법이 무엇인지 잘 모르겠습니다.

그 제안에 따라 이 문제를 논의할 수 있을까요? 전문가가 이 기능이 필요하다고 생각한다면 :)

@lmdaly 1.16에 대한 코드 동결은 8/29 목요일에 있습니다. 나머지 k/k PR에 대해 https://github.com/kubernetes/kubernetes/issues/72828 을 추적할 예정입니다.

@kacole2 이 기능에 필요한 모든 PR이 병합되거나 병합 대기열에 있습니다.

안녕하세요 @lmdaly -- 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을 나열하여 제대로 추적할 수 있도록 하십시오. 👍

감사 해요!

/마일스톤 클리어

@lmdaly RDMA 토론과 함께 GPU 직접 링크가 있습니까?

@nickolaev , 우리는 또한 이 사용 사례를 찾고 있습니다. 이 작업을 수행하는 방법에 대해 내부적으로 몇 가지 생각을 시작했지만 이 작업에 대해 협력하고 싶습니다.

@moshe010 @nickolaev @lmdaly , 우리도 RDMA 및 GPU 다이렉트와 관련된 이 사용 사례를 조사하고 있습니다. 이에 협력하고자 합니다. 이것에 대한 스레드/토론을 시작할 수 있습니까?

여보세요! NTM과 스케줄러에 대해 질문이 있습니다. 내가 이해하는 바와 같이 스케줄러는 NUMA에 대해 알지 못하며 원하는 NUMA에 리소스(cpu, 메모리 및 장치)가 없다는 노드를 선호할 수 있습니다. 따라서 토폴로지 관리자는 해당 노드에서 리소스 할당을 거부합니다. 사실이야?

@nickolaev @Deepthidharwar , 사용 사례로 Google 문서를 시작하고 토론을 해당 문서로 이동할 수 있습니다. 나는 다음 주에 무언가를 게시할 것이다. 괜찮으시다면.

이 기능을 보게 되어 정말 기쁩니다. 또한 단일 NUMA 노드에 CPU, Hugepage, SRIOV-VF 및 기타 하드웨어 리소스가 필요합니다.
하지만 hugepage는 device plugin에 의해 스칼라 리소스로 인식되지 않습니다. 이 기능이 k8s에서 hugepage 기능을 변경해야 합니까?
@iamneha

@ConnorDoyle 확인을 위해 이 기능에는 CPU 관리자와 장치 관리자 모두의 토폴로지 힌트가 필요합니까? 1.16에서 테스트했지만 작동하지 않았습니다. cpu 관리자에서만 힌트를 얻었지만 장치 쪽에서는 힌트를 얻지 못한 것 같습니다.

@ConnorDoyle에 대한 자세한 내용은 다음과 같습니다.
https://gist.githubusercontent.com/jianzzha/c2a66a2514c178cca76a432029ff3387/raw/264f13dfcd06f1f80c48c113aa235fab7c33d81e/hyperenabled%25252th

@jianzzha , 어떤 장치 플러그인을 사용하고 있습니까? 예를 들어 SR-IOV 장치 플러그인을 사용하는 경우 NUMA 노드를 보고하는지 확인해야 합니다. [1]

[1] https://github.com/intel/sriov-network-device-plugin/commit/000db15405f3ce3b7c2f9feb180c3051aa3f7aea.

@andyzheung 거대한 페이지 통합은 현재 논의 중이며 지난 2주 동안 시그노드 회의에서 발표되었습니다. 다음은 몇 가지 관련 링크입니다.

https://docs.google.com/presentation/d/1H5xhCjgCZJjdTm-mGUFwqoz8XmoVd8xTCwJ1AfVR_54/edit?usp=sharing
https://github.com/kubernetes/enhancements/pull/1245
https://github.com/kubernetes/enhancements/pull/1199

@jianzzha 힌트를 제공하지 않는 장치 플러그인과 관련하여. 열거하는 장치에 대한 NUMA 정보를 보고하도록 플러그인이 업데이트되었습니까? 장치 메시지 https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/deviceplugin/v1beta1/api.proto#L100에 이 필드를 추가해야 합니다.

고마워 얘들아. 수정되어 지금 작동합니다.

@klueska
nvidia-gpu-device-plugin 관련..
Topology Manger용 nvidia-gpu-device-plugin을 업데이트하는 활성 PR(WIP) 이 하나만 표시됩니다.
nvidia-gpu-divice-plugin이 위의 PR과 함께 토폴로지 힌트를 제공하도록 업데이트됩니까? 또는 내가 놓친 것이 있습니까?

@bg-chun 네 그래야 합니다. 방금 작성자에게 핑을 보냈습니다. 그가 다음 날쯤에 돌아오지 않는다면, 내가 직접 플러그인을 업데이트할 것입니다.

@bg-chun @klueska 패치를 업데이트했습니다.

@klueska @carmark
업데이트 및 알림 감사합니다.
내 작업 공간의 사용자에게 sr-iov-plugin 업데이트 및 gpu-plugin 업데이트를 소개합니다.

다음 릴리스에 대한 개선 사항을 제안합니다.
기본적으로 "파드가 QoS 보장에 있는 경우에만 토폴로지 정렬이 발생합니다" 제한을 제거하는 것입니다.
이러한 제한으로 인해 현재로서는 토폴로지 관리자를 사용할 수 없습니다. K8에서 전용 CPU를 요청하고 싶지 않기 때문입니다. 그러나 여러 풀(예: GPU + SR)에서 오는 여러 장치의 소켓을 정렬하고 싶습니다. -IOV VF 등)
또한 내 워크로드가 메모리에 민감하지 않거나 메모리 사용량을 제한하고 싶지 않은 경우(QoS 보장의 또 다른 기준)
미래에 거대 페이지도 정렬될 때 이 제한은 IMO를 훨씬 더 제한적으로 느낄 것입니다.

"정렬 가능한" 자원을 개별적으로 정렬하는 것에 반대하는 주장이 있습니까? 물론 전용 CPU를 사용하는 경우에만 CPU 관리자에서 힌트를 수집 하지만 소켓 정보가 있는 장치가 필요한 경우 장치 관리자에서, 또는 사용자가 거대한 페이지 등을 요청할 때 메모리 관리자에서 독립적으로 힌트를 수집합시다.

이 중 하나 또는 Pod 시작 중 불필요한 추가 계산 부하가 우려되는 경우 원래 Pod 수준 구성 플래그를 가져와서 정렬이 발생하는지 여부를 제어할 수 있습니다(구현 중 스크랩되는 것을 보고 놀랐습니다)

다음 릴리스에 대한 개선 사항을 제안합니다.
기본적으로 "파드가 QoS 보장에 있는 경우에만 토폴로지 정렬이 발생합니다" 제한을 제거하는 것입니다.

이것은 1.17의 TODO 목록에 있는 항목 번호 8입니다.
https://docs.google.com/document/d/1YTUvezTLGmVtEF3KyLOX3FzfSDw9w0zB-s2Tj6PNzLA/edit#heading =h.xnehh6metosd

"정렬 가능한" 자원을 개별적으로 정렬하는 것에 반대하는 주장이 있습니까? 물론 전용 CPU를 사용하는 경우에만 CPU 관리자에서 힌트를 수집 하지만 소켓 정보가 있는 장치가 필요한 경우 장치 관리자에서, 또는 사용자가 거대한 페이지 등을 요청할 때 메모리 관리자에서 독립적으로 힌트를 수집합시다.

kubelet에 정렬할 리소스와 정렬하지 않을 리소스를 선택적으로 알려주는 메커니즘이 있다고 제안하십니까? 이에 반대하는 사람은 없을 것 같지만, 노드 수준에서 계속 정렬을 플래그로 지정하면 정렬할 리소스와 정렬하지 않을 리소스를 선택적으로 결정하는 인터페이스가 지나치게 복잡해질 수 있습니다.

이 중 하나 또는 Pod 시작 중 불필요한 추가 계산 부하가 우려되는 경우 원래 Pod 수준 구성 플래그를 가져와서 정렬이 발생하는지 여부를 제어할 수 있습니다(구현 중 스크랩되는 것을 보고 놀랐습니다)

포드 사양을 업데이트하자는 제안을 보증할 만큼 포드 수준 플래그에 대한 지원이 충분하지 않았습니다. 일부 포드는 정렬이 필요/원하고 일부는 필요하지 않지만 모든 사람이 동의한 것은 아니므로 이 결정을 포드 수준으로 푸시하는 것이 합리적입니다.

토폴로지 정렬에 대한 QoS 클래스 제한을 제거하기 위해 +1(목록에 추가했습니다:스마일:). @Levovar 가 리소스별로 토폴로지를 활성화할 것을 요청하고 있다는 것을 이해하지 못했습니다. 단지 주어진 컨테이너에서 사용하는 정렬 가능한 모든 리소스를 정렬해야 한다는 것뿐입니다.

내가 기억하는 한, KEP에는 토폴로지에 옵트인하기 위한 포드 수준 필드가 없었습니다. 처음부터 도입하지 않은 이유는 배타적 코어를 묵시적으로 남겨두는 것과 같은 이유였습니다. Kubernetes는 프로젝트로서 노드 수준 성능 관리 측면에서 포드 사양을 자유롭게 해석하기를 원합니다. 이러한 입장이 커뮤니티의 일부 구성원에게 만족스럽지 않다는 것을 알고 있지만 언제든지 다시 주제를 제기할 수 있습니다. 소수의 고급 기능을 활성화하는 것과 대부분의 사용자를 위한 인지 부하 조정 사이에는 자연스러운 긴장이 있습니다.

IMO는 설계 초기 단계에서 최소한 Pod 수준 플래그가 있었습니다. 제 기억이 잘 맞는다면 1.13 정도였습니다. :D
나는 개인적으로 항상 모든 리소스를 정렬하려고 노력하는 것이 좋지만 "그 시절"에는 일반적으로 시작이 지연되거나 모든 Pod의 일정 결정이 지연되는 기능에 대해 커뮤니티에서 반발이 있었습니다. 그들은 정말로 개선이 필요하거나 필요하지 않습니다.

그래서 저는 두 가지 옵션으로 이러한 문제를 "사전 처리"하려고 했습니다. 몇 가지 기준에 따라 리소스 그룹의 정렬을 미리 제어합니다(CPU에 대해서는 정의하기 쉽고 다른 경우에는 더 어렵습니다). 또는 일부 구성 플래그를 도입하십시오.

그러나 일반적인 개선 사항에 대해 지금 푸시백이 없다면 저는 그것에 대해 완전히 멋집니다. :)

@mrbobbytables 우리는 TopologyManager 를 beta 로 졸업할 계획입니다. 추적 문제는 여기: https://github.com/kubernetes/kubernetes/issues/83479

@bg-chun @klueska 패치를 업데이트했습니다.

패치 병합:
https://github.com/NVIDIA/k8s-device-plugin/commit/cc0aad87285b573127add4e487b13434a61ba0d6

패치로 새 릴리스 생성:
https://github.com/NVIDIA/k8s-device-plugin/releases/tag/1.0.0-beta2

v1.17용 추적 베타

굉장합니다, @derekwaynecarr 감사합니다. 시트에 추가할게요 :)
/스테이지 베타

@lmdaly

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

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

감사 해요!

@VineethReddy02 네, 트래커 시트를 업데이트할 수 있다면 1.17에 대한 문서 업데이트를 계획했습니다.

그 전에 그 PR을 열도록 하겠습니다. 미리 알려주셔서 감사합니다.

이에 대한 문서 추적 문제는 https://github.com/kubernetes/kubernetes/issues/83482입니다.

https://github.com/kubernetes/enhancements/pull/1340
얘들 아, 나는 Topology Manager에 대한 내장 노드 레이블( beta.kubernetes.io/topology )을 추가하기 위해 KEP 업데이트 PR을 열었습니다.
레이블은 노드의 정책을 노출합니다.
동일한 클러스터에 여러 정책이 있는 노드가 있을 때 특정 노드에 포드를 예약하는 데 도움이 될 것이라고 생각합니다.
리뷰를 부탁드려도 될까요?

안녕하세요 @lmdaly @derekwaynecarr

여기 👋 1.17 개선 팀의 Jeremy가 있습니다. 추적할 수 있도록 현재 진행 중인 k/k PR을 나열해 주시겠습니까? #83492가 병합되었지만 전체 추적 항목에 몇 가지 더 많은 관련 문제가 있는 것으로 보입니다. 우리는 11월 14일에 Code Freeze를 마감할 예정이므로 그 전에 이것이 어떻게 진행되고 있는지 알고 싶습니다! 정말 고마워!

@jeremyrickard 위에서 언급한 1.17의 추적 문제입니다. https://github.com/kubernetes/enhancements/issues/693#issuecomment -538123786

@mdaly @derekwaynecarr

11월 8일 금요일까지 k/website(branch dev-1.17)에 대한 Docs용 자리 표시자 PR을 찾고 있음을 알려드립니다. 이 마감일이 2일 남았습니다.

문서 PR은 여기 btw: https://github.com/kubernetes/website/pull/17451

@klueska 일부 작업이 1.18로 충돌한 것을 봅니다. 아직 1.17에서 베타로 전환할 계획입니까, 아니면 알파로 유지되지만 변경될 예정입니까?

신경 쓰지 마세요. https://github.com/kubernetes/kubernetes/issues/85093 에서 1.17의 일부가 아니라 1.18의 베타로 이동할 예정임을 확인했습니다. 이것을 1.17 마일스톤 @klueska의 일부로 알파 버전의 주요 변경 사항으로 추적하기를 원하십니까? 아니면 졸업을 1.18로 연기하시겠습니까?

/마일스톤 v1.18

안녕하세요 @klueska

1.18 개선팀 체크인! 아직 1.18에서 베타로 전환할 계획이 있습니까? KEP에 업데이트가 필요한 경우 Enhancement Freeze는 1월 28일이고 Code Freeze는 3월 5일입니다.

감사합니다!

예.

@klueska 업데이트 주셔서 감사합니다! 추적 시트 업데이트.

@klueska 이번 릴리스에 대한 KEP를 검토하는 동안 테스트 계획이 누락되었음을 확인했습니다. 릴리스에서 베타로 전환하려면 테스트 계획을 추가해야 합니다. 지금은 이정표에서 제거할 것이지만 예외 요청 을 제출하고 KEP에 테스트 계획을 추가하면 다시 추가할 수 있습니다. 공지가 늦어 죄송합니다.

/마일스톤 클리어

@vpickard 는 위를 참조하십시오

@vpickard 는 위를 참조하십시오

@klueska 알려 주셔서 감사합니다. KEP에 테스트 계획을 추가하고 예외 요청을 제출하는 작업을 합니다. 우리는 테스트 사례를 적극적으로 개발하고 있으며 일부 테스트 PR을 완료했으며 다음을 포함하여 일부는 진행 중입니다.

https://github.com/kubernetes/kubernetes/pull/87645

@jeremyrickard 참고할 수 있는 테스트 계획 템플릿이 있습니까?

@vpickard 다음을 볼 수 있습니다.

https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190530-pv-health-monitor.md#test - 계획
그리고
https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20200120-skip-permission-change.md#test -plan

단위 테스트 및 e2 테스트에 대한 개요를 포함합니다.

테스트 그리드에 표시되는 것이 있으면 포함하는 것이 좋습니다.

예외가 승인되었습니다.

/마일스톤 v1.18

@jeremyrickard 테스트 계획 병합: https://github.com/kubernetes/enhancements/pull/1527

@klueska @vpickard 님 , 안녕하세요, 코드 동결 이 3월 5일 목요일에 발효될 것임을 알려드립니다.

이 향상을 위해 추적해야 하는 모든 k/k PR 또는 기타 PR을 링크할 수 있습니까?

감사합니다 :)

안녕하세요 @palnabarun

1.18의 추적 문제:
https://github.com/kubernetes/kubernetes/issues/85093

현재 진행 중인 PR:
https://github.com/kubernetes/kubernetes/pull/87758 (승인된, 플레이킹 테스트)
https://github.com/kubernetes/kubernetes/pull/87759 (WIP)
https://github.com/kubernetes/kubernetes/pull/87650 (검토됨, 승인 필요)

https://github.com/kubernetes/kubernetes/pull/87645 (e2e 테스트 PR, 승인 필요)

@vpickard 내가 놓친 e2e PR을 추가할 수 있습니다.

감사 해요

여기에서 PR과 우산 문제를 연결해 주신 @nolancon 에게 감사드립니다. 추적 시트에 PR을 추가했습니다.

안녕하세요 @palnabarun , @nolancon ,

E2E 테스트와 관련된 몇 가지 추가 공개 PR:
https://github.com/kubernetes/test-infra/pull/16062 (검토 및 승인 필요)
https://github.com/kubernetes/test-infra/pull/16037 (검토 및 승인 필요)

추가 업데이트에 대해 @vpickard 에게 감사드립니다. :)

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

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

안녕하세요 @irvifa ,
감사 해요.

안녕하세요 @nolancon 빠른 응답에 감사드립니다. 지금 상태를 Placeholder PR로 변경합니다.. 감사합니다!

@palnabarun 참고로 이 PR https://github.com/kubernetes/kubernetes/pull/87759 를 두 개의 PR로 나누어 검토 과정을 쉽게 했습니다. 두 번째는 https://github.com/kubernetes/kubernetes/pull/87983 이며 추적해야 합니다. 감사 해요.

@nolancon 업데이트 감사합니다.

일부 PR이 아직 병합 대기 중인 것으로 나타났습니다. 검토자와 승인자를 PR에 연결하는 데 릴리스 팀의 도움이 필요한지 알고 싶었습니다. 필요한 것이 있으면 알려주십시오.

참고로, 우리는 3월 5일 코드 동결에 매우 가깝습니다.

@nolancon 업데이트 감사합니다.

일부 PR이 아직 병합 대기 중인 것으로 나타났습니다. 검토자와 승인자를 PR에 연결하는 데 릴리스 팀의 도움이 필요한지 알고 싶었습니다. 필요한 것이 있으면 알려주십시오.

참고로, 우리는 3월 5일 코드 동결에 매우 가깝습니다.

@palnabarun 또 하나의 업데이트인 https://github.com/kubernetes/kubernetes/pull/87983 이 종료되었으며 추적할 필요가 없습니다. 필요한 변경 사항은 검토 중인 원본 PR https://github.com/kubernetes/kubernetes/pull/87759에 포함되어 있습니다.

@nolancon 쿨. 또한 위에서 공유한 우산 추적기 문제를 추적하고 있습니다. :)

@nolancon 님 , 안녕하세요. 3월 5일 Code Freeze가 이틀 앞으로 다가왔습니다.

코드 동결을 통해 모든 관련 PR을 병합해야 하며 그렇지 않으면 예외 요청을 제출해야 합니다.

안녕하세요 @nolancon 입니다 .

오늘 EOD는 코드 프리즈 입니다.

https://github.com/kubernetes/kubernetes/pull/87650 이 마감일까지 검토될 것이라고 생각하십니까?

그렇지 않은 경우 예외 요청을 제출하십시오 .

안녕하세요 @nolancon 입니다 .

오늘 EOD는 코드 프리즈 입니다.

kubernetes/kubernetes#87650 이 마감일까지 검토될 것이라고 생각하십니까?

그렇지 않은 경우 예외 요청을 제출하십시오 .

@palnabarun님 , 안녕하세요.

명확히하기 위해 EOD는 오후 5시 또는 자정 PST를 의미합니까? 감사 해요

명확히하기 위해 EOD는 오후 5시 또는 자정 PST를 의미합니까? 감사 해요

오후 5시(태평양 표준시)

PR이 승인되었지만 병합을 위해 서명 노드를 추가해야 하는 마일스톤이 누락되었습니다. 나는 슬랙에서 그들을 핑(ping)했고, 잘만되면 그것이 풀리고 예외가 필요하지 않습니다. =)

이 kep에 대한 모든 PR이 병합된 것으로 보이며(마감일까지 승인됨) 개선 사항 추적 시트를 업데이트했습니다. :웃다:

/마일스톤 클리어

(이정표가 완료되면 v1.18 이정표에서 이 개선 문제 제거)

안녕하세요 @nolancon @lmdaly , 여기 1.19에 대한 개선 사항 섀도우입니다. 1.19에서 이에 대한 계획이 있습니까?

1.19에 대해 계획된 유일한 개선 사항은 다음과 같습니다.
https://github.com/kubernetes/enhancements/pull/1121

나머지 작업은 필요에 따라 코드 리팩토링/버그 수정에 관한 것입니다.

어쨌든 이 문제의 소유자를 @lmdaly 대신 나로 변경할 수 있습니까?

감사합니다. 연락처를 업데이트하겠습니다.

/마일스톤 v1.19

/assign @klueska
/할당 해제 @lmdaly

여기 있습니다, Kevin https://prow.k8s.io/command-help

안녕하세요 케빈입니다. 최근에 KEP 형식이 변경되었으며 #1620도 지난 주에 병합되어 KEP 템플릿에 생산 준비 검토 질문이 추가되었습니다. 가능하면 시간을 내어 KEP를 다시 포맷하고 템플릿에 추가하는 질문에 답하십시오. 이러한 질문에 대한 답변은 기능(특히 이 단계에서 모니터링 부분)을 사용하고 문제를 해결하는 운영자에게 도움이 될 것입니다. 감사 해요!

@klueska ^^

@deekwaynecarr @klueska @johnbelamaric
또한 1.19 rel에 새로운 토폴로지 정책을 추가할 계획입니다.
그러나 아직 소유자와 유지 관리자의 검토를 받지 못했습니다.
(1.19에서 만들기 어려울 것 같으면 알려주세요.)

• KEP 업데이트 홍보: https://github.com/kubernetes/enhancements/pull/1752
• kubelet에 대한 PR: WIP

안녕하세요 @klueska 👋 1.19 docs shadow입니다! 1.19에 대해 계획된 이 개선 작업에 문서를 새로 추가하거나 수정해야 합니까?

문서에 대한 신규/수정이 필요한 경우 6월 12일 금요일까지 k/website(branch dev-1.19 )에 대한 자리 표시자 PR이 필요하다는 친절한 알림입니다.

안녕하세요 @klueska 는 잘

안녕하세요 @annajung입니다. 문서 변경이 필요한 2개의 보류 중인 개선 사항이 있습니다.

1121

1752

이것이 1.19에 포함될 것인지 1.20으로 푸시될 것인지 우리는 여전히 결정하고 있습니다. 1.19로 유지하기로 결정하면 6월 12일까지 문서에 대한 자리 표시자 PR을 만들겠습니다.

엄청난! 업데이트해주셔서 감사합니다. 그에 따라 추적 시트를 업데이트하겠습니다! 자리 표시자 PR이 만들어지면 알려주세요. 감사합니다!

@lmdaly @ConnorDoyle
여기에 질문하고 피드백을 제공할 수 있는 올바른 장소가 되길 바랍니다.

내 k8s 클러스터 v1.17에서 TopologyManager 및 CPUManager 를 켭니다.
정책은 best-effort 및 static
다음은 내 포드의 리소스입니다.

      resources:
        requests:
          cpu: 2
          intel.com/sriov_pool_a: '1'
        limits:
          cpu: 2
          intel.com/sriov_pool_a: '1'

sriov_pool_a의 PF는 NUMA 노드 0에 있으므로 내 포드가 NUMA 노드 0의 CPU에서도 실행되어야 합니다.
그러나 내 포드의 프로세스가 NUMA 노드 1의 CPU에서 실행되고 있음을 발견했습니다.
또한 taskset -p <pid> 의 결과에 따라 설정된 CPU 선호도 마스크가 없습니다.

문제가 있습니까? 컨테이너에 numa 노드 0의 cpu에 대해 cpu 선호도 마스크가 설정되어 있어야 합니다.

내 TopoloyManager 가 올바르게 작동하는지 알아보기 위해 수행할 수 있는 예제나 테스트가 있습니까?

@annajung 자리 표시자 문서 PR 추가: https://github.com/kubernetes/website/pull/21607

안녕하세요 @klueska ,

월요일에 k-dev에 보낸 이메일에 대한 후속 조치로 Code Freeze가 7월 9일 목요일까지 연장되었음을 알려드립니다. 수정된 일정은 https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19 에서 확인할 수 있습니다.
그때까지 모든 PR이 병합될 것으로 예상합니다. 질문이 있으면 알려주세요. 😄

최상의,
커스틴

안녕하세요 @klueska님 , 다음 마감일이 다가오고 있음을 친절하게
자리 표시자 문서 PR을 채우고 7월 6일 월요일까지 검토할 수 있도록 준비하세요.

@annajung 감사

안녕하세요 @klueska , 좋은 지적입니다! 모든 문서 기한도 새 릴리스 날짜와 함께 일주일 연기되었지만 유효한 포인트가 있다고 생각합니다. 릴리스에 대한 문서 책임자에게 연락하여 다시 연락드리겠습니다! 지적해주셔서 감사합니다!

@klueska님 , 이 문제를 알려주셔서 다시 한 번 감사드립니다. 릴리스의 문서 날짜와 혼동이 있었습니다. 언급했듯이 "검토 준비가 된 PR"은 코드 동결 이후에 와야 하며 이전 릴리스에 있었습니다.

그러나 릴리스 팀과 논의한 후 "PR 검토 준비"를 소프트 기한으로 지정하여 이 1.19 릴리스의 날짜를 그대로 유지하기로 결정했습니다. 문서 팀은 유연하며 문서가 코드와 동기화되었는지 확인하기 위해 추가 시간이 필요할 수 있는 귀하/다른 사람과 협력합니다. "PR 검토 준비 완료" 기한은 적용되지 않지만 "PR 검토 및 병합 읽기"는 적용됩니다.

귀하의 우려 사항에 대한 답변이 도움이 되었기를 바랍니다. 더 궁금한 점이 있으면 알려주세요!

또한 날짜를 친절하게 알려줍니다.
"문서 마감일 - PR 검토 준비"는 7월 6일까지입니다.
"문서 완료 - 모든 PR이 검토되었으며 병합할 준비가 됨"은 7월 16일까지입니다.

안녕하세요 @klueska :wave: -- 1.19 Enhancements Lead,

릴리스 팀에서 추적할 수 있도록 여기에서 모든 구현 PR에 연결할 수 있습니까? :약간_웃는_얼굴:

감사합니다.

@palnabarun
PR 추적 https://github.com/kubernetes/enhancements/pull/1121 은 다음에서 찾을 수 있습니다.
https://github.com/kubernetes/kubernetes/pull/92665

불행히도 개선 사항 #1752는 릴리스에 포함되지 않으므로 추적할 PR이 없습니다.

@klueska :wave: 안녕하세요. https://github.com/kubernetes/enhancements/pull/1752 가 베타 졸업 요구 사항을 확장하고 릴리스에 포함되지 않기 때문에 1.19에서 예상되는 추가 변경 사항이 없다고 가정할 수 있습니까?

감사합니다. :약간_웃는_얼굴:

코드 동결은 7월 9일 목요일 EOD PST에 시작됩니다.

@palnabarun 이것은 오늘 또는 내일 상륙해야 하는 #92665에 대한 후속 PR입니다: https://github.com/kubernetes/kubernetes/pull/92794

그 후에는 예상치 못한 버그가 보류 중인 이 릴리스에 대한 PR이 더 이상 없어야 합니다.

엄청난! 업데이트 해주셔서 감사합니다. :+1:

우리는 https://github.com/kubernetes/kubernetes/pull/92794를 주시할 것

@annajung https://github.com/kubernetes/website/pull/21607 이제 검토할 준비가 되었습니다.

축하합니다 @klueska kubernetes/kubernetes#92794가 마침내 병합되었습니다. 그에 따라 추적 시트를 업데이트하겠습니다 😄

/마일스톤 클리어

(이정표가 완료되면 v1.19 이정표에서 이 개선 문제 제거)

안녕하세요 @klueska

개선 사항은 여기로 연결됩니다. 1.20에 졸업할 계획이 있나요?

감사 해요!
커스틴

졸업할 계획은 없지만 이 개선 사항과 관련하여 1.20에 대해 추적해야 하는 PR이 있습니다.
https://github.com/kubernetes/kubernetes/pull/92967

1.20에서 졸업하지 않더라도 방금 한 것처럼 관련 PR을 이 문제에 계속 연결하십시오.

@kikisdeliveryservice 프로세스를 이해하는 데 도움을 주시겠습니까? Topology Manager 기능은 1.20에서 종료되지 않지만 새 기능이 추가되어 현재 작업 중입니다. https://github.com/kubernetes/enhancements/pull/1752 k/k: https://github. com/kubernetes/kubernetes/pull/92967. 출시 팀과 함께 추적해야 하는 사항입니까? 1.20에 대한 문서 업데이트 또는 추적 중인 다른 항목의 추적을 단순화할 수 있습니다.

변경 사항은 추가되므로 beta2 또는 기타라고 부를 이유가 많지 않습니다.

추가 기능이 1.19에서 제공되지 않은 현실을 반영하는 관련 범프 PR: https://github.com/kubernetes/enhancements/pull/1950

범위 기능을 포함하도록 토폴로지 관리자 웹 문서 업데이트 PR: https://github.com/kubernetes/website/pull/24781

1.20으로 추적할 수 있으며 반드시 졸업할 필요는 없다고 생각합니다. @kikisdeliveryservice 정확하지 않은 경우

안녕하세요 @SergeyKanzhelev

역사를 보면 사실 그렇지 않습니다. 나는 이것이 위에서 졸업하지 않을 것이라고 들었는데, 괜찮고 이 KEP가 추적되지 않는 이유입니다. 그러나 이 개선 사항(향상 팀에 알려지지 않음)은 최근 @k-wiatrzyk에 의해 1.20 베타로 대상이 변경되었습니다(https://github.com/kubernetes/enhancements/pull/1950).

릴리스 프로세스를 활용하려면 개선 사항 추적, 릴리스 이정표의 일부가 되고 문서 팀이 이를 추적하거나 1.20 릴리스에 문서가 포함되도록 하려면 개선 사항 예외 요청을 최대한 빨리 제출해야 합니다.

기능은 이미 (기존) KEP에 병합되었습니다(개선 기한 전).
https://github.com/kubernetes/enhancements/pull/1752

구현 시 PR은 이미 이정표의 일부입니다.
https://github.com/kubernetes/kubernetes/pull/92967

더 할 일이 더 있는지 몰랐습니다.

누구와 함께 예외를 제출해야 하며 정확히 무엇을 위해 제출해야 합니까?

안녕하세요 @klueska은 1.19에서 KEP으로 베타를 추가하는 6 월에 합병되었다 참조하는 홍보 : https://github.com/bg-chun/enhancements/blob/f3df83cc997ff49bfbb59414545c3e4002796f19/keps/sig-node/0035-20190130-topology -manager.md#베타 -v119

1.20의 개선 사항 마감일은 10월 6일이었지만 베타를 1.20으로 이동하고 1.19에 대한 참조를 제거하는 변경 사항은 https://github.com/kubernetes/enhancements/pull/1950을 통해 3일 전에 병합되었습니다.

예외 요청을 보내기 위한 지침은 https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md 에서 찾을 수 있습니다.

죄송합니다. 예외를 신청할 대상에 대해 여전히 혼란스럽습니다.
나는 그것을 하게 되어 기쁩니다. 다만 거기에 무엇을 포함시켜야 할지 잘 모르겠습니다.

"노드 토폴로지 관리자" 기능은 이미 1.18에서 베타로 전환되었습니다.
1.20에서 GA로 전환되지 않습니다(베타 상태에 있음).

1.20용으로 병합되는 PR(예: kubernetes/kubernetes#92967)은 토폴로지 관리자에 대한 기존 코드의 개선 사항이지만 alpha/beta/ga 등의 상태 측면에서 "범프"와 관련이 없습니다.

기한이 오늘 (단지 경우)와 같이 내가 예외 메일의 전화 (를) 다음 사용자에게 전송했습니다 https://groups.google.com/g/kubernetes-sig-node/c/lsy0fO6cBUY/m/_ujNkQtCCQAJ

@kikisdeliveryservice @klueska @annajung
예외 요청이 승인되었습니다. 확인은 https://groups.google.com/g/kubernetes-sig-release/c/otE2ymBKeMA/m/ML_HMQO7BwAJ 에서 확인할 수 있습니다.

@k-wiatrzyk & @klueska 감사합니다. 추적 시트를 업데이트했습니다.

참조: @annajung

안녕하세요 @k-wiatrzyk @klueska

kubernetes/kubernetes#92967이 승인되었지만 리베이스가 필요한 것 같습니다.

Code Freeze 가 11월 12일 목요일 에 2일 후에 온다는 사실을 상기시켜 주십시오. 모든 PR은 해당 날짜까지 병합되어야 합니다. 그렇지 않으면 예외 가 필요합니다.

최상의,
커스틴

PR 병합, 시트 업데이트 - 예! :미소고양이: