Kubernetes: Kubelet/Kubernetes는 Swap Enabled와 함께 작동해야 합니다.

스왑 지원은 중요하지 않습니다. 보장된 포드는 스왑이 필요하지 않습니다. 버스트 가능한 포드는 스왑 없이 요청을 충족해야 합니다. BestEffort 포드는 보증하지 않습니다. kubelet은 현재 여기에서 포드 전반에 걸쳐 예측 가능한 적절한 양의 동작을 제공할 수 있는 영리함이 부족합니다.

우리는 올해 초 리소스 관리에서 이 주제를 직접 대면하여 논의했습니다. 우리는 실현할 수 있는 이익에 비해 단기간에 이 문제를 해결하는 데 큰 관심이 없습니다. 우리는 압력 감지에 대한 안정성을 개선하고 스왑에 대한 최적화를 시도하기 전에 대기 시간과 관련된 문제를 최적화하는 것을 선호하지만 이것이 귀하에게 더 높은 우선순위라면 도움을 드리겠습니다.

/종류 기능

@derekwaynecarr 설명 감사합니다! kubernetes에 대해 스왑을 비활성화해야 하는 정보/문서를 얻기가 어려웠습니다. 이것이 제가 이 주제를 열게 된 주된 이유였습니다. 현시점에서 저는 이 문제에 대해 높은 우선순위를 갖고 있지 않습니다. 단지 논의할 수 있는 장소가 있는지 확인하고 싶었을 뿐입니다.

https://github.com/kubernetes/kubernetes/issues/7294 토론에 더 많은 컨텍스트가 있습니다. 스왑을 사용할 수 있다는 것은 메모리 제한과 매우 이상하고 나쁜 상호 작용을 합니다. 예를 들어, 메모리 제한에 도달한 컨테이너는 스왑으로 넘치기 시작합니다(이는 f4edaf2b8c32463d6485e2c12b7fd776aef948bc 이후로 수정된 것으로 보입니다. 스왑이 있든 없든 간에 스왑을 사용할 수 없음).

이것은 우리에게도 중요한 사용 사례입니다. 때때로 높은 메모리 사용량(>30GB)에 도달하는 cron 작업이 있으며 40GB 이상의 노드를 영구적으로 할당하고 싶지 않습니다. 또한 3개의 영역(GKE)에서 실행한다고 가정하면 3개의 이러한 머신(각 영역에 1개)이 할당됩니다. 그리고 이 구성은 3개 이상의 프로덕션 인스턴스와 10개 이상의 테스트 인스턴스에서 반복되어야 하므로 K8을 사용하는 데 비용이 많이 듭니다. 우리는 엄청난 비용을 발생시키는 25개 이상의 48GB 노드를 가질 수 밖에 없습니다!.
스왑을 활성화하십시오!.

정말로 스왑을 원하는 사람들을 위한 해결 방법입니다. 만약 너라면

• --fail-swap-on=false kubelet 시작
• 노드에 스왑 추가
• 메모리 요구 사항을 지정하지 않는 컨테이너는 기본적으로 스왑을 포함한 모든 머신 메모리를 사용할 수 있습니다.

그게 우리가 하는 일입니다. 또는 적어도 개인적으로 실제로 구현하지는 않았지만 그것이 내가 수집하는 것이라고 확신합니다.

이것은 컨테이너 중 어느 것도 명시적 메모리 요구 사항을 지정하지 않는 경우에만 실제로 실행 가능한 전략일 수 있습니다.

우리는 GKE에서 실행되며 이러한 옵션을 설정하는 방법을 모르겠습니다.

누군가가 kubelet에서 메모리 제거에 대한 영향을 평가할 수 있다면 zswap 채택을 고려할 수 있습니다.

로컬 Ubuntu 노트북에서 Kubernetes를 실행 중이며 다시 시작할 때마다 스왑을 꺼야 합니다. 또한 스왑이 꺼져 있으므로 메모리 제한에 근접하지 않도록 걱정해야 합니다.

다시 시작할 때마다 기존 설치의 일부 구성 파일 변경과 같이 스왑을 끌 필요가 없는 방법이 있습니까?

클러스터에서 실행되는 노드에서 스왑이 필요하지 않습니다.

스왑을 켜야 하는 Kubernetes Local Dev 클러스터가 아닌 내 랩톱의 다른 애플리케이션입니다.

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T10:09:24Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

지금은 플래그가 작동하지 않습니다.

# systemctl restart kubelet --fail-swap-on=false
systemctl: unrecognized option '--fail-swap-on=false'

다음 Kubelet 플래그를 설정합니다. --fail-swap-on=false

2018년 1월 30일 화요일 오후 1시 59분에 icewheel [email protected]에서 다음과 같이 썼습니다.

로컬 Ubuntu 노트북에서 Kubernetes를 실행 중이며 다시 시작할 때마다
스왑을 꺼야합니다. 기억에 가까이 가지 않는 것도 신경써야 해
스왑이 꺼져 있으면 제한합니다.

다시 시작할 때마다 스왑을 끌 필요가 없는 방법이 있습니까?
기존 설치에서 구성 파일 변경?

클러스터에서 실행되는 노드에서 스왑이 필요하지 않습니다.

Kubernetes Local Dev 이외의 랩톱에 있는 다른 애플리케이션일 뿐입니다.
스왑을 켜야 하는 클러스터.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/53533#issuecomment-361748518 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AA3JwQdj2skL2dSqEVyV46iCllzT-sOVks5tP5DSgaJpZM4PwnD5
.

--
마이클 타우펜
구글 SWE

@mtaufen 감사

terraform과 같이 클러스터를 부트스트랩하는 시스템의 경우 서비스 파일을 수정해야 할 수 있습니다.

이것은 나를 위해 일했습니다.

sudo sed -i '/kubelet-wrapper/a \ --fail-swap-on=false \\\' /etc/systemd/system/kubelet.service

기본적으로 스왑을 지원하지 않습니까? 이 말을 듣고 놀랐습니다. Kubernetes가 전성기를 맞이할 준비가 되었다고 생각했나요? 스왑은 그 기능 중 하나입니다.

이것은 대부분의 개방형 사용 사례에서 실제로 선택 사항이 아닙니다. VMM이 비활성 페이지를 전환하면서 Unix 에코시스템이 실행되도록 설계된 방식입니다.

스왑이 없거나 메모리 제한이 없는 선택이 있는 경우에는 언제든지 스왑을 유지하고 페이징을 시작할 때 더 많은 호스트를 스핀업하여 비용을 절약할 것입니다.

누군가 명확히 할 수 있습니까? 메모리 제거 문제는 포드 정의에서 메모리 제한을 사용하는 경우에만 문제이지만 그렇지 않으면 괜찮습니까?

응용 프로그램 메모리가 작동하는 방식을 제어할 수 있는 환경에서 작업하는 것이 좋으므로 메모리 사용량이 낮아 걱정할 필요가 없지만 대부분의 응용 프로그램에는 비활성 메모리 공간이 많이 있습니다.

솔직히 말해서 최근 스왑 없이 서버를 실행하려는 이러한 움직임은 40년 간의 메모리 관리 설계를 무시하면서 사람들을 더 큰 메모리 인스턴스로 강제하려는 PaaS 제공업체에 의해 주도되었다고 생각합니다. 실제로 커널은 어떤 메모리 페이지가 활성 상태인지 아닌지를 아는 데 매우 능숙합니다.

이것은 또한 노드에서 메모리가 고갈되면 잠재적으로 완전히 잠기게 되는 효과가 있습니다. 잠시 후 속도를 늦추고 복구하는 대신 노드를 다시 시작해야 합니다.

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

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

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

클러스터 노드( K8s Version - v1.11.2 )에 많은 수의 디스크 읽기가 있습니다. 스왑 메모리를 비활성화했기 때문일 수 있습니까?

https://stackoverflow.com/questions/51988566/high-number-of-disk-reads-in-kubernetes-nodes

@srevenant 클러스터 세계에서 다른 노드의 RAM은 새로운 스왑입니다. 즉, 스왑이 의미가 있는 두 개의 1노드 K8 인스턴스를 실행합니다. 그러나 이것은 K8의 일반적인 사용 사례가 아닙니다.

@srevenant 전적으로 동의합니다. SWAP은 Unix와 Linux가 태어날 때부터 기본적으로 사용됩니다. Linux에서 15년 동안 작업하면서 SWAP을 해제하도록 요청하는 앱을 본 적이 없는 것 같습니다.
문제 SWAP는 Linux 배포판을 설치할 때 기본적으로 항상 켜져 있으므로 K8을 설치하기 전에 이를 해제해야 하고 그것은 놀라운 일이었습니다.
Linux 커널은 특히 서버가 RAM 한계에 도달하려고 할 때 일시적으로 서버의 성능을 향상시키기 위해 SWAP을 관리하는 방법을 잘 알고 있습니다.
K8이 제대로 작동하려면 SWAP를 꺼야 한다는 뜻인가요?

나는 이 일을 하는 데 관심이 있고 테스트할 기술과 많은 기계를 가지고 있습니다. 기여하고 싶다면 어디에서 시작하는 것이 가장 좋을까요?

@superdave 는 kubernetes/community에 스왑을 지원하는 방법을 설명하는 KEP를 구성하고 sig-node에 제시하십시오. 우리는 당신의 도움을 받고 싶습니다.

나는 Kubernetes의 포드에서 스왑을 적절하게 활성화하는 것을 지지합니다. 거의 모든 컨테이너가 사용자 정의 Linux 인스턴스이고 기본적으로 스왑을 지원하기 때문에 스왑이 없다는 것은 실제로 의미가 없습니다.
기능을 구현하기가 복잡한 것은 이해할 수 있지만 언제부터 그것이 우리가 앞으로 나아가지 못하게 막았습니까?

스왑을 비활성화하면 노드의 메모리가 부족할 때 노드 오류가 발생하므로 스왑 문제를 Kubernetes에서 해결해야 한다는 데 동의해야 합니다. 예를 들어 3개의 작업자 노드(각각 20GB의 램)가 있고 램 제한에 도달하여 하나의 노드가 다운되는 경우 2개의 다른 작업자 노드도 해당 시간에 모든 팟(Pod)을 해당 노드로 전송한 후 다운됩니다.

실제 데이터에 따라 메모리 요청을 설정하여 이를 방지할 수 있습니다.
응용 프로그램의 필요.

애플리케이션 메모리의 3분의 1이 2배 정도인 경우
저장 속도가 느리면 유용한 작업을 수행할 수 있습니까?

2018년 9월 26일 수요일 오전 6시 51분에 vasicvuk [email protected]에서 다음과 같이 썼습니다.

나는 스왑 문제가 Kubernetes에서 해결되어야 한다는 데 동의해야 합니다.
스왑을 비활성화하면 노드의 메모리가 부족할 때 노드 오류가 발생합니다. 을위한
예를 들어 3개의 작업자 노드(각각 20GB의 램)가 있고 하나의 노드가 작동하는 경우
램의 한계에 도달했기 때문에 다운됨 2개의 다른 작업자 노드도 이동합니다.
그 시간에 그들에게 모든 포드를 전송한 후 다운.

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

@matthiasr 10-50 서비스가 있을 때 그렇게 할 수 있습니다. 그러나 200개 이상의 서비스를 실행하는 클러스터가 있고 그 중 절반이 메모리 요청 없이 공식 Helm 차트를 사용하여 배포되는 경우 손이 많이 갑니다.

그러나 누락된 메모리가 해결해야 할 문제를 요청하지 않습니까?

많은 경우 @matthiasr 메모리는 한 번만 사용되거나 실제로 사용되지 않는 프로세스에 매핑됩니다. 이는 유효한 경우이며 메모리 누수가 아닙니다. 스왑하면 해당 페이지가 결국 스왑되고 다시는 스왑 인되지 않을 수 있지만 더 나은 사용을 위해 빠른 램을 해제합니다.

또한 응답을 보장하기 위해 스왑을 해제하는 것도 좋지 않습니다. 메모리에 파일을 고정하지 않는 한(적어도 K8이 실행 파일에 대해 가져야 하는 기능), 커널은 메모리 부족 또는 단순히 사용 부족에 대한 응답으로 모든 파일 지원 페이지를 계속 교체합니다.

스왑을 활성화해도 커널 동작이 크게 변경되지는 않습니다. COW 매핑된 파일에서 로드된 수정된 페이지나 익명 페이지를 교체할 공간을 제공하기만 하면 됩니다.

스와핑을 완전히 끌 수는 없으므로 K8은 특별한 경우의 익명 메모리 스와핑이 활성화 되었는지 여부에 관계없이 그 존재를 유지해야 합니다.

이것은 이것을 버그로 만듭니다. 실제로 끌 수 없는 커널 기능을 지원하지 못하고 있습니다.

@본

커널은 여전히 ​​메모리 부족 또는 단순히 사용 부족에 대한 응답으로 모든 파일 지원 페이지를 교체합니다. 스왑을 활성화해도 커널 동작이 크게 변경되지는 않습니다.

스와핑을 완전히 끌 수는 없습니다.

나 자신을 교육할 수 있도록 이에 대한 참고 자료를 제공할 수 있습니까?

메모리에 파일을 고정하지 않는 한(K8에는 최소한 실행 파일에 대한 기능이 있어야 함)

k8이 사용하기를 원하는 기능은 무엇입니까? 바이너리가 정적 이면 포드의 tmpfs로 복사하면 페이징 대기 시간에 도움이 됩니다.

@adityakali 스왑이 꺼져 있을 때 커널에서 스왑의 영향에 대한 생각은 무엇입니까?

나 자신을 교육할 수 있도록 이에 대한 참고 자료를 제공할 수 있습니까?

모든 최신 가상 메모리 OS와 마찬가지로 Linux는 디스크에서 메모리로 실행 가능한 페이지를 요구합니다. 메모리 부족 상태에서 커널 은 다른 메모리 페이지와 마찬가지로 "스왑 비활성화"로 비활성화하는 _only_ 스와핑은 "익명 메모리" - 파일과 연결되지 _않은_ 메모리입니다(가장 좋은 예는 "스택" 및 "힙" 데이터 구조입니다).

물론 위의 설명에서 건너뛰는 세부 정보가 많이 있습니다. 특히, 실행 파일은 램에 자신의 메모리 공간의 "잠금"부분은 사용 할 수 mlock 를 통해 현명한 일 콜의 가족을 madvise() , 동일한 페이지를 여러 프로세스가 공유하는 경우가 복잡해진다 (예: libc.so) 등. 해당 맨페이지나 교과서 또는 Linux 커널 소스/문서/메일링 목록과 같은 일반적인 내용 외에 더 많이 읽을 수 있는 유용한 포인터가 없습니다.

따라서 위의 실제 효과는 프로세스가 메모리 한계에 가까워지면 커널이 램에서 _code_ 부분과 상수를 강제로 제거해야 한다는 것입니다. 다음에 해당 비트의 코드 또는 상수 값이 필요할 때 프로그램은 일시 중지되어 디스크에서 다시 가져오기를 기다리고 다른 것을 제거합니다. 따라서 "스왑 비활성화"를 사용하더라도 작업 집합이 사용 가능한 메모리를 초과하면 여전히 동일한 성능 저하가 발생합니다.

사람들이 위의 내용을 읽고 스왑 방지 마녀 사냥의 일환으로 모든 것을 메모리에 mlock하거나 모든 것을 ramdrive에 복사하기 위해 호출을 시작하기 전에 여기서 관심 있는 실제 리소스는 전체 크기가 아니라 작업 세트 크기 라는 점을 반복하고 싶습니다. . 램에 있는 기가바이트의 데이터를 통해 선형으로 작동하는 프로그램은 한 번에 해당 데이터의 좁은 창에서만 작동할 수 있습니다. 이 가상의 프로그램은 많은 양의 스왑과 작은 램 제한으로 잘 작동합니다. 그리고 모든 것을 실제 램에 잠그는 것은 매우 비효율적입니다. 위의 설명에서 배웠듯이 이것은 많은 양의 _code_를 가지고 있지만 특정 순간에 소량만 실행하는 프로그램과 정확히 동일합니다.

이와 같은 나의 최근 개인 실세계 예는 kubernetes 실행 파일을 연결하는 것입니다. 나는 현재 (아이러니하게도) kubernetes 클러스터에서 kubernetes를 컴파일할 수 없습니다. go link 단계에는 작업 세트가 훨씬 더 작음에도 불구하고 몇 기가바이트의 (익명) 가상 메모리가 필요하기 때문입니다.

"가상 메모리가 아니라 작업 집합에 관한 것"이라는 점을 실제로 다루려면 많은 일반 파일 I/O를 수행하고 mmap과 아무 관련이 없는 프로그램을 고려하십시오. 램이 충분하면 커널은 반복적으로 사용되는 디렉토리 구조와 파일 데이터를 램에 캐시하고 디스크로 이동하지 않으며 디스크 쓰기를 최적화하기 위해 일시적으로 램에 쓰기가 버스트되도록 합니다. 이와 같은 "순진한" 프로그램조차도 작업 세트 크기와 사용 가능한 램에 따라 램 속도에서 디스크 속도로 저하됩니다. 무언가를 램에 불필요하게 고정하면(예: mlock 사용 또는 스왑 비활성화) 커널이 실제로 유용한 무언가를 위해 물리적 램의 해당 페이지를 사용하는 것을 방지하고 (작업 세트를 위한 램이 충분하지 않은 경우) 디스크 I/O를 더 비싼 곳으로 옮겼습니다.

@superdave : 저도 여기서 현상태를 개선하는 데 관심이 있습니다. 다른 사람이 문서를 검토하거나 키보드에서 손을 보도록 하려면 저를 포함시켜 주세요.

이와 같은 나의 최근 개인 실세계 예는 kubernetes 실행 파일을 연결하는 것입니다. 나는 현재 (아이러니하게도) kubernetes 클러스터에서 kubernetes를 컴파일할 수 없습니다. go link 단계에는 작업 세트가 훨씬 더 작음에도 불구하고 몇 기가바이트의 (익명) 가상 메모리가 필요하기 때문입니다.

@superdave : 저도 여기서 현상태를 개선하는 데 관심이 있습니다. 다른 사람이 문서를 검토하거나 키보드에서 손을 보도록 하려면 저를 포함시켜 주세요.

당면한 문제에 대한 좋은 요약! 스왑 스래싱은 실제로 여기서 핵심 문제입니다. 합리적으로 해결하기를 바라는 것입니다. 충분히 생각해 볼 시간이 없었지만, 스와핑 활동(주어진 시간 프레임에 대한 페이지인/아웃, 아마도 너무 열심인 경우 프로세스가 일시적으로 급증함) 스왑이 활성화된 경우 제거 대상을 평가하는 좋은 방법일 수 있습니다. 많은 메트릭이 있으며 가능한 사용 사례를 신중하게 평가할 뿐만 아니라 만질 수 있는 많은 손잡이를 제공하고 싶습니다. 또한 가상 메모리 상호 작용을 위해 포드를 계측할 수 있으면 사람들이 더 잘 조정하는 데 도움이 될 것이라고 생각합니다. 나는 지금 거기에 무엇이 있는지 말하기 위해 이미 제안된 것에 대해 충분히 익숙하지 않지만, 나는 내가 알아낼 것이라고 생각합니다.

또한 개별 포드/컨테이너에서 스와핑 동작을 얼마나 잘 제어할 수 있는지 알아야 하는 컨트롤에 익숙하지 않습니다. 보존 또는 교환을 위해 사물을 "수정"할 수 있으면 도움이 될 것이지만, 개발자는 분명히 상주할 것을 절대적으로 보장해야 할 때 mlock()을 자유롭게 시도할 수 있습니다.

어쨌든, 네, 저는 절대적으로 이 일을 진행하고 싶습니다. 나는 최근에 직장에서 붐볐다(누군가가 부적절하게 큰 용량을 만들지 않는 한 99%의 시간이 RAM을 필요로 하지 않기 때문에 부하 상태에서 스왑할 수 있는 이점이 있는 k8s에서 자체 마이크로서비스로 일부 OOM 문제를 처리합니다. 요청), 하지만 그것에 대해 계속 저에게 말씀해 주십시오. 나는 전에 KEP 프로세스에 참여한 적이 없으므로 꽤 친환경적일 것입니다. 하지만 요즘은 폴링 방식보다 인터럽트 방식으로 훨씬 더 잘 작동합니다. :-)

저는 zram이 스왑에 편승하여 작동한다는 점을 지적하고 싶습니다. k8에 스왑이 없으면 대부분의 비 Linux OS가 기본적으로 활성화되어 있는 메모리 압축이 없습니다(Windows, MacOS 큐).

우리는 매일 밤 많은 메모리를 소모하는 대규모 배치 작업을 실행하는 Ubuntu 인스턴스를 k8에 가지고 있습니다. 작업 부하가 미리 결정되지 않았기 때문에 OOM을 피하기 위해 실제 메모리 소비에 관계없이 노드에 16GB를 (비싸게) 할당해야 합니다. 로컬 개발 서버에서 메모리 압축을 사용하면 작업이 최대 3GB에 불과합니다. 그렇지 않으면 낮에는 1GB의 메모리만 사용합니다. 스왑을 금지하고 따라서 메모리 압축을 금지하는 것은 매우 어리석은 행동입니다.

여기에서 가장 큰 관심사는 아마도 고립이라고 생각합니다. 일반적인 시스템은 수많은 포드를 호스팅할 수 있으며 메모리가 부족하면 스와핑을 시작하여 서로의 성능을 완전히 파괴할 수 있습니다. 스왑이 없으면 격리가 훨씬 쉽습니다.

여기에서 가장 큰 관심사는 아마도 고립이라고 생각합니다. 일반적인 시스템은 수많은 포드를 호스팅할 수 있으며 메모리가 부족하면 스와핑을 시작하여 서로의 성능을 완전히 파괴할 수 있습니다. 스왑이 없으면 격리가 훨씬 쉽습니다.

그러나 이전에 설명했듯이 스왑을 비활성화해도 여기에서는 아무 것도 사지 않습니다. 사실, 전체적으로 메모리 압력을 증가시키므로 커널이 사용하지 않는 데이터를 교체할 수 있는 경우 작업 집합의 일부를 삭제하도록 강제할 수 있으므로 상황이 악화 됩니다.

스왑을 활성화하면 실제로 격리가 향상됩니다.

하지만 예상대로(그리고 Google이 Borg에서 작업을 실행하는 방식) 실행하는 경우 많은 비용이 듭니다. 모든 컨테이너는 메모리 상한을 지정해야 합니다. Borg는 Google 인프라를 활용하고 원하는 경우 제한을 학습하지만(과거 리소스 사용량 및 OOM 동작에서) 그럼에도 불구하고 제한이 있습니다.

나는 실제로 K8S 사람들이 메모리 제한을 선택 사항으로 허용했다는 사실에 당황했습니다. CPU와 달리 메모리 압력은 시스템 성능에 매우 비선형적인 영향을 미칩니다. 스와핑으로 인해 시스템이 완전히 잠기는 것을 본 사람이 증명할 것이기 때문입니다. 기본적으로 실제로 필요하며 비활성화하도록 선택하면 경고를 표시합니다.

하지만 예상대로(그리고 Google이 Borg에서 작업을 실행하는 방식) 실행하는 경우 많은 비용이 듭니다. 모든 컨테이너는 메모리 상한을 지정해야 합니다. Borg는 Google 인프라를 활용하고 원하는 경우 제한을 학습하지만(과거 리소스 사용량 및 OOM 동작에서) 그럼에도 불구하고 제한이 있습니다.

나는 실제로 K8S 사람들이 메모리 제한을 선택 사항으로 허용했다는 사실에 당황했습니다. CPU와 달리 메모리 압력은 시스템 성능에 매우 비선형적인 영향을 미칩니다. 스와핑으로 인해 시스템이 완전히 잠기는 것을 본 사람이 증명할 것이기 때문입니다. 기본적으로 실제로 필요하며 비활성화하도록 선택하면 경고를 표시합니다.

이것이 해결하지 못하는 문제는 상한이 가변적이며 일부 프로세스에 대해 항상 알려진 것은 아니라는 것입니다. 제가 다루고 있는 문제는 특히 k8을 사용하여 3d 모델 렌더러 노드를 관리하는 데 중점을 둡니다. 렌더링되는 모델 및 장면의 자산에 따라 필요한 램의 양이 상당히 다를 수 있으며 대부분의 렌더링은 작지만 _일부_가 클 수 있다는 사실은 우리의 요청과 제한이 훨씬 더 많은 메모리를 예약해야 함을 의미합니다 포드가 때때로 구성된 제한을 초과하여 스왑 공간으로 넘길 수 있는 것보다 OOM을 피하기 위해 실제로 시간의 90%가 필요합니다.

예, 그 경우 상한선을 "없음" 또는 그 효과로 설정합니다. 제 요점은 기본값이 되어서는 안 된다는 것입니다. 아무것도 설정하지 않으면 마스터가 "배낭"(kubelet)에 넣을 "항목"(작업)의 크기를 단순히 알지 못하기 때문에 모든 종류의 지능형 워크로드 스케줄링을 완전히 무효화합니다.

여기서 문제는 작업이 스왑으로 유출된다는 것이 아니라 해당 노드에서 실행 중인 다른 모든 작업도 마찬가지라는 것입니다. 그리고 그들 중 일부(대부분?)는 그것을 전혀 좋아하지 않을 것입니다.

Borg의 프로그램은 데이터 무결성에 영향을 미치지 않고 언제든지 선점형(전문 용어에 익숙하지 않은 사용자를 위해 종료 가능)으로 작성됩니다. 이것은 실제로 Google 외부에서 많이 볼 수 없는 것이며 프로그램의 잠재적인 갑작스러운 사망을 인정하면 훨씬 더 안정적인 소프트웨어를 작성할 수 있습니다. 그러나 나는 빗나간다.

이러한 프로그램으로 구축된 시스템은 초과 가입된 노드에서 계속 고통을 받는 것보다 해당 프로그램이 죽고 셀(보그 클러스터)의 다른 곳에서 다시 태어나는 것을 훨씬 선호합니다. 그렇지 않으면 특히 작업의 작업 수가 많은 경우 테일 대기 시간이 실제로 문제가 될 수 있습니다.

저를 오해하지 마십시오. 이것이 일을 실행하는 유일한 "올바른"방법이라고 말하는 것이 아닙니다. 나는 단지 디자인에 들어간 가능한 근거를 설명하려고 노력할 뿐입니다.

면책 조항: 저는 Borg를 사용하여 여러 개의 초대형 서비스를 실행한 전 Google 직원이므로 잘 알고 있으며 그 지식은 대부분 Kubernetes로 변환됩니다. 저는 현재 Google에 소속되어 있지 않으며 여기에 쓰는 모든 내용은 제 생각입니다.

@1e100 : "총 VM" 크기와 "작업 집합" 크기를

(저는 또한 전 Google-SRE이고 이러한 일반적인 Google 신화가 k8에서도 스왑을 비활성화하는 것이 좋습니다(또는 심지어 바람직함)라는 결정에 거의 확실하게 영향을 미쳤다는 데 동의합니다. 여러 Google 팀이 스왑을 비활성화해도 스와핑이 비활성화되지 않는다는 학습과 메모리에 대한 "하드"(oom-kill) 제한을 설명하는 데 따르는 총 메모리 낭비 - 이것들은 정확히 제가 k8로 개선하고 싶은 것들 중 일부입니다. borg 리소스 모델이 처음 설계되었을 때는 없었지만 지금은 사용할 수 있는 cgroup/swap 조정 가능한 노브가 많이 있으며 목욕물에 아기를 던지지 않고도 원하는 결과를 얻을 수 있다고 확신합니다. . 또한 Google 절충안은 더 나은/알려진 최악의 경우(즉, 실시간 동작)를 달성하기 위해 평균적으로 덜 효율적이며 _종종_ Google 외부에서 원하는 선택이 아닌 경우가 많습니다. 더 적은 수의 호스트, 더 완화된 SLO, 더 낮은 예산, 더 열악한 정의 ed 배치 작업, 컴파일되지 않은 힙 비효율적인 언어의 더 많은 사용 등)

익명 메모리의 스와핑은 발생하지 않습니다. 메모리에 매핑된 모든 것(프로그램 코드 및 데이터 포함)은 메모리 부족이 있는 경우 여전히 스왑할 수 있고 여전히 스왑될 것이므로 RAM 제한이 기본적으로 요구되어야 한다고 제안한 이유는 처음부터 메모리 부족이 발생할 가능성을 줄이기 위해서입니다. 더 엄격한 보증이 필요한 워크로드의 경우 mlockall() 및 낮은 swappiness 값도 있습니다.

이전 Google SRE로서 상한 RAM 제한을 지정하지 않거나 작업이 변덕스럽게 원하는 대로 교환할 수 있도록 하는 것이 반대자가 되고 싶지 않다면 좋은 일이라고 주장할 수 없습니다. 메모리 매핑된 파일을 스와핑하는 것은 충분히 나쁩니다. 더 많은 잠재적인 성능 절벽을 믹스에 도입하는 것은 좋지 않습니다.

이러한 환경은 설계상 공유된 환경이며 새로운 환경을 추가하는 것이 아니라 프로그램이 서로의 성능을 예측할 수 없도록 만드는 방법을 제거하려고 합니다. Google SRE는 "희망은 전략이 아닙니다"라고 말합니다. 스왑 스래싱은 SSD로 교체하더라도 Linux 시스템을 완전하고 복구 불가능하게 잠그는 가장 쉬운 방법입니다. 수십 개는 고사하고 머신에서 하나의 워크로드만 실행하는 경우에도 좋지 않습니다. 연관된 오류는 태스크/포드가 거의 없는 소규모 클러스터에서 특히 고통스러울 수 있습니다.

원하는 경우 오늘날에도 스왑 확인을 무시할 수 있지만 이 경우 모든 베팅이 취소된다는 명시적인 이해가 있습니다.

예, 일정을 잡고 (의도하지 않은) 오버 커밋을 피하기 위해 사용하는 "크기"가 필요하다는 데 전적으로 동의합니다. 또한 Linux가 복구하는 데 시간이 걸리기 때문에 글로벌 VM 스래시를 피하고 싶습니다. 우리가 원하는 것은 커널이 익명 메모리를 교체하고 그 램을 다른 용도로 재사용하는 _가능_하는 것입니다. 이것이 의미가 있는 경우에는 그렇게 할 수 없는 시스템보다 엄격하게 우수하기 때문입니다. 이상적으로는 개별 컨테이너가 램/디스크 트레이드오프를 관리할 수 있도록 하고 다른 컨테이너에 대한 영향을 최소화하면서 자체 리소스(과다/과소 할당) 선택의 결과에 직면할 수 있기를 바랍니다.

내가 이것을 가지고 어디로 가고 있는지 보여주기 위해 현재의 스트로우맨 제안은 다음과 같습니다.

• 은유는 각 컨테이너가 특정 양의 램( limits.memory 의해 제공됨)과 스왑이 있는 머신에 있는 것처럼 작동한다는 것입니다.
• 다른 리소스와 동일: requests.memory 기반 일정 , limits.memory 기반 제한 적용. 이 경우 "메모리"는 "램"을 의미합니다. 스왑 사용량은 무료입니다.
• 특히 k8s requests.memory -> cgroup memory.low (오버커밋 요인에 의해 축소됨); k8s limits.memory -> cgroup memory.high .
• 컨테이너가 구성된 메모리 제한을 초과하면 사용 가능한 여유 램의 양에 관계없이 _무관하게_ 교환을 시작합니다. cgroups 덕분에 이것은 단지 VM 사용이 아니라 컨테이너에 기인하는 블록 캐시, 소켓 버퍼 등을 포함합니다. 이것은 다른 컨테이너(또는 호스트 프로세스)에 메모리 압력을 가하는 것을 방지합니다. 제거할 페이지를 찾을 때 커널은 메모리 요청 크기를 초과하는 컨테이너를 찾습니다.
• k8이 호스트에 대한 새 포드 예약을 중지하는 전체 스왑 사용량 kubelet 소프트 제한을 도입합니다(imagefs와 같은 다른 "공유 파일 시스템"과 동일).
• 전체 스왑 사용량 하드 제한에 도달하면 qos-class/priority 및 "요청" 위의 VM 크기를 기반으로 포드 축출을 시작합니다(imagefs와 같은 다른 "공유 파일 시스템"과 동일).
• 컨테이너가 작업 세트( requests.memory )를 크게 초과하면 스래싱될 수 있습니다( limits.memory 초과하거나 호스트에서 사용 가능한 램이 충분하지 않은 경우). 리소스 메커니즘을 통해 이에 대해 명시적으로 _하지 않습니다_. 컨테이너가 스왑 스레싱이면 활성/준비 상태 프로브 검사에 실패하고 해당 메커니즘을 통해 종료됩니다(예: 구성된 응답 SLA가 없는 경우 스왑 스레싱은 괜찮음).

최종 결과는 관리자가 각 시스템에서 "충분한" 스왑을 구성할 책임이 있다는 것입니다. 응용 프로그램 구성해야합니다 limits.memory 그들도 사용할 램 _max_로, 그리고 requests.memory (등, 커널 버퍼 포함) 의도 된 작업 세트. 다른 리소스와 마찬가지로 보장된 qos 클래스(limit==request), burstable(limit undefined 또는 !=request), best-effort(제한 또는 요청 없음)가 계속 적용됩니다. 특히 이것은 버스트 가능한 프로세스가 의도한 작업 세트(큰 안전 버퍼 없음)에 가깝게 선언하도록 장려하여 효율적인 할당(이상적으로는 작업 세트에 할당된 램의 정확히 100%)을 허용하고 컨테이너가 이를 초과할 때 원활한 성능 저하를 제공합니다. CPU와 같은 다른 "용서" 리소스와 마찬가지로.

나는 이것이 Linux cgroups 내에서 구현 가능하고, 격리 문제를 해결하고, 다른 k8s 리소스에 의해 설정된 개념적 선례를 계속하고, 스왑이 비활성화되면 기존 동작으로 저하된다고 생각합니다(마이그레이션을 쉽게 만듭니다). 내가 가지고 있는 유일한 질문은 이것이 _이미_ 구현된 것인지 여부입니다("swapfs" kubelet 소프트/하드 제한 제외) - 구체적인 제안 및 작업 항목을 작성하기 전에 실제 kubelet/CRI cgroups 코드를 읽어야 합니다. .

위의 의견/토론은 아마도 이 github 문제에서 적절하지 않을 것입니다(그것은 빈약한 토론 포럼입니다). 위의 내용에 심각한 문제가 있는 경우 k8s slack에 대한 guslees의 피드백을 환영합니다. 그렇지 않으면 적절한 문서를 작성하고 어느 시점에서 일반적인 디자인 토론을 진행할 것입니다.

토론을 위한 더 나은 포럼을 가질 수 있도록 공식 문서를 작성하는 것이 좋습니다.

동의. 이에 대한 몇 가지 확실한 아이디어가 있기 때문에 KEP를 작성하는 데 도움을 드릴 수 있어 기쁩니다.

그러나 또한 여가 시간에 Slack 채널을 따라잡을 대역폭이 없습니다. 좀 더 비동기적인 조정 방법이 있다면 알려주세요.

계속 유지하기 위해: 저는 여전히 KEP 및/또는 이를 위한 구현 작업에 매우 관심이 있습니다. 일단 상황이 안정되면(다음 주말을 위해 준비할 워크샵이 있습니다), Slack 채널에 참여하려고 합니다.

안녕하세요 현재 진행 중인 이 문제에 대한 공개 토론이 있습니까? (k8s slack은 현재 모든 사람에게 열려 있지 않으며 당분간은 그렇지 않을 것이라고 생각합니다.)

@leonaves 현재 AFAIK에서 진행 중인 여유에 대한 논의가 없습니다. @guslees 의 마지막 댓글은 토론의 마지막입니다. kubernetes/enhancements repo에 세부 정보가 포함된 KEP가 있어야 일을 시작하고 메일링 리스트 스레드도 시작할 수 있습니다.

곧 재개장을 위한 터널의 끝도 있는 것 같습니다. 내 손가락을 교차.

알고 보니 아직 다른 Slack 채널에 가입할 정신적 여유가 없습니다. 나는 여전히 이메일을 통해 이 문제에 대해 협력하는 것을 주저하고 있습니다.

정말로 스왑을 원하는 사람들을 위한 해결 방법입니다. 만약 너라면

• --fail-swap-on=false kubelet 시작
• 노드에 스왑 추가
• 메모리 요구 사항을 지정하지 _않은_ 컨테이너는 기본적으로 스왑을 포함하여 모든 머신 메모리를 사용할 수 있습니다.

그게 우리가 하는 일입니다. 또는 적어도 개인적으로 실제로 구현하지는 않았지만 그것이 내가 수집하는 것이라고 확신합니다.

이것은 컨테이너 중 어느 것도 명시적 메모리 요구 사항을 지정하지 않는 경우에만 실제로 실행 가능한 전략일 수 있습니다.

이 방법은 더 이상 작동하지 않습니다!? 스왑을 켜고 메모리 설정 없이 포드를 배포하고 이 컨테이너를 얻었습니다.

$ docker inspect <dockerID> | grep Memory
            "Memory": 0,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": -1

MemorySwap은 "0"이며, 이는 이 컨테이너가 스왑에 액세스할 수 없음을 의미합니다.

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

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

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

/remove-lifecycle 부실.

/remove-lifecycle 부실

이 문제의 독자를 위한 또 다른 참조로 여기에서 삭제합니다: https://chrisdown.name/2018/01/02/in-defence-of-swap.html

관련: https://serverfault.com/questions/881517/why-disable-swap-on-kubernetes

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

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

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

/remove-lifecycle 부실

이 기능은 일부 사용 사례에서 실제로 필요합니다. 현재 우리는 기계 학습을 위해 k8을 사용하고 있으며 때로는 메모리에 큰 모델을 로드해야 하며(이 경우 때때로 API 요청당 500MB!) 물리적 메모리의 한계로 인해 심각한 문제가 발생합니다. 수평 확장은 기술적인 관점에서 작동하지만 비용은 천정부지로 치솟을 것입니다. 가상 메모리가 옵션으로 있다면 좋을 것입니다.

이 티켓이 다시 로드맵으로 돌아올 가능성이 있습니까?

mmap의 경우처럼 들립니다.

저도 이 기능에 관심이 많습니다. 이에 대한 소식이 있습니까?

나는 시간이 있을 때 이것에 대해 조사를 시작하게 되어 기쁩니다. 지금 당장은 공급이 부족하지만, 문제를 더욱 완벽하게 특성화할 수 있도록 문제를 악화시키는 한두 가지 정식 사례가 있으면 좋을 것입니다. 스래싱을 시작하고 모든 것이 지옥으로 갑니다.") 궁극적인 접근 방식과 수정 사항이 검증되었습니다.

모든 예상 솔루션은 스왑의 보안 영향도 고려해야 합니다. 이것은 분명히 유닉스 환경에서 실행되는 모든 것에 해당되지만 사람들이 스왑이 없다는 의사 보장으로 k8s 포드를 실행하는 데 익숙해지고 메모리 규율에 게으르면 이것이 활성화되면 꽤 무례한 놀라움이 될 수 있습니다. 기본.

문제를 악화시켜 보다 완벽하게 특성화할 수 있는 표준 사례 한두 개를 갖는 것이 좋습니다.

그것은 KEP 처럼 들립니다.

모든 예상 솔루션은 스왑의 보안 영향도 고려해야 합니다. 이것은 분명히 유닉스 환경에서 실행되는 모든 것에 해당되지만 사람들이 스왑이 없다는 의사 보장으로 k8s 포드를 실행하는 데 익숙해지고 메모리 규율에 게으르면 이것이 활성화되면 꽤 무례한 놀라움이 될 수 있습니다. 기본.

이 논리는 Kubernetes 사용 여부에 관계없이 여러 컨테이너에서 실행되는 모든 프로세스에 적용됩니다.

동의! 그러나 Docker는 이미 스왑 실행을 명시적으로 지원합니다. Kubernetes는 명시적으로 그렇지 않습니다(강제로 할 수는 있지만). 내 주장은 모든 사람의 위협 모델이 아니기 때문에, 특히 이전에 이에 대해 생각할 필요가 없는 경우에 적어도 호출되어야 한다는 것입니다.

또한 예, @sftim 입니다. :-) 내 말은 내가 KEP를 작성/기고하고 싶다는 것입니다. 하지만 모험을 하기 전에 주어진 테스트 시스템에서 문제를 안정적으로 실행하는 최소한의 테스트 케이스 한두 개를 보고 싶습니다. 올바른 문제를 해결하고 있는지 확인할 수 있습니다.

@superdave 어떤 종류의 테스트 케이스를 염두에 두고 계십니까?

다음은 간단한 테스트입니다.

1. 노드 1개, RAM 16GiB 및 페이지 파일 64GiB로 클러스터를 설정합니다.
2. 각각 1GiB 메모리 요청과 1GiB 메모리 제한이 있는 20개의 Pod를 예약하십시오.
3. 모든 일정이 아니므로 주의하십시오.

여기 또 하나:

1. 각각 16GiB의 RAM과 64GiB의 페이지 파일이 있는 6개의 시스템을 설정합니다.
2. kubeadm 를 기본 옵션과 함께 사용하여 이러한 머신을 Kubernetes 클러스터로 구성해 보십시오.
3. kubeadm 이 사용 중인 스왑에 대해 만족하지 않는 것을 관찰하십시오.

현재 대부분의 존경할 만한 클라우드 플랫폼에서 SSD에 대한 엄청난 변화가 있으며 Linux가 추가 압축 가능성과 함께 SSD https://lwn.net/Articles/704478/ 에서 스와핑을 위한 전용 최적화를 고려하면 이 상황은 스왑을 다음과 같이 활용할 수 있는 완전히 새로운 기회를 만듭니다. 메모리 부족 시 추가 RAM에 대한 예측 가능하고 빠른 리소스.
비활성화된 스왑은 I/O 버퍼에 사용되지 않는 경우 사용하지 않은 RAM이 낭비되는 것과 같은 방식으로 낭비되는 리소스가 됩니다.

@superdave

동의! 그러나 Docker는 이미 스왑 실행을 명시적으로 지원합니다. Kubernetes는 명시적으로 그렇지 않습니다(강제로 할 수는 있지만). 내 주장은 모든 사람의 위협 모델이 아니기 때문에, 특히 이전에 이에 대해 생각할 필요가 없는 경우에 적어도 호출되어야 한다는 것입니다.

이 경우 kubelet 이 메모리 공간을 mlock() 하고 OOM 종료 우선 순위를 낮게 설정하여 스왑 아웃되거나 OOM이 종료되는 것을 방지하고 swapiness 로 cgroup의 모든 컨테이너를 실행합니다. 0 로 설정됩니다. 누군가가 양식 스와핑의 이점을 얻으려면 포드의 특정 컨테이너에 대해 enableSwapiness: 50 와 같은 옵션을 사용하여 옵트인할 수 있습니다.
놀라움이 없습니다. 배터리가 포함되어 있습니다.

@sftim 이는 a) Kubelet이 컨테이너를 예약하고 싶지 않고 b) Kubelet이 기본적으로 스왑을 사용하여 실행되지 않음을 보여줍니다. 내가 운동하려고 하는 것은 @derekwaynecarr 의 스레드 상단에 있는 상황입니다.

스왑 지원은 중요하지 않습니다. 보장된 포드는 스왑이 필요하지 않습니다. 버스트 가능한 포드는 스왑 없이 요청을 충족해야 합니다. BestEffort 포드는 보증하지 않습니다. kubelet은 현재 여기에서 포드 전반에 걸쳐 예측 가능한 적절한 양의 동작을 제공할 수 있는 영리함이 부족합니다.

우리는 올해 초 리소스 관리에서 이 주제를 직접 대면하여 논의했습니다. 우리는 실현할 수 있는 이익에 비해 단기간에 이 문제를 해결하는 데 큰 관심이 없습니다. 우리는 압력 감지에 대한 안정성을 개선하고 스왑에 대한 최적화를 시도하기 전에 대기 시간과 관련된 문제를 최적화하는 것을 선호하지만 이것이 귀하에게 더 높은 우선순위라면 도움을 드리겠습니다.

그리고 바로 아래 @matthiasr에서 :

여기에 토론에 더 많은 컨텍스트가 있습니다. #7294 – 사용 가능한 스왑을 갖는 것은 메모리 제한과 매우 이상하고 나쁜 상호 작용을 합니다. 예를 들어, 메모리 제한에 도달한 컨테이너는 _그러면_ 스왑으로 f4edaf2 이후로 수정된 것으로 보입니다. 스왑이

둘 다 이미 본 문제에 대한 좋은 견해를 제공하지만 문제를 악화시킬 수 있는 알려진 재현 가능한 시나리오를 파악하는 것이 좋습니다. 내가 직접 생각해낼 수 있지만 다른 사람이 이미 그렇게 했다면 재발명하지 않아도 괜찮을 것입니다.

@superdave

동의! 그러나 Docker는 이미 스왑 실행을 명시적으로 지원합니다. Kubernetes는 명시적으로 그렇지 않습니다(강제로 할 수는 있지만). 내 주장은 모든 사람의 위협 모델이 아니기 때문에, 특히 이전에 이에 대해 생각할 필요가 없는 경우에 적어도 호출되어야 한다는 것입니다.

이 경우 kubelet 이 메모리 공간을 mlock() 하고 OOM 종료 우선 순위를 낮게 설정하여 스왑 아웃되거나 OOM이 종료되는 것을 방지하고 swapiness 로 cgroup의 모든 컨테이너를 실행합니다. 0 로 설정됩니다. 누군가가 양식 스와핑의 이점을 얻으려면 포드의 특정 컨테이너에 대해 enableSwapiness: 50 와 같은 옵션을 사용하여 옵트인할 수 있습니다.
놀라움이 없습니다. 배터리가 포함되어 있습니다.

나는 여기 모든 것에 동의한다고 생각합니다. 불쾌한 놀라움을 피하기 위해 현재 동작을 기본으로 합니다.

다음은 어떤 이유로 메모리의 많은 부분이 할당되었지만 다시는 액세스되지 않는 간단한 응용 프로그램이 어떻게 생겼는지에 대한 예입니다. 사용 가능한 모든 메모리가 채워지면 응용 프로그램이 중단되거나 기본적으로 리소스를 차단하거나 메모리 부족 킬러를 강제 실행하는 끝없는 루프에 빠지게 됩니다.

#include <iostream>
#include <vector>
#include <unistd.h>
int main() {
  std::vector<int> data;
  try
    {
        while(true) { data.resize(data.size() + 200); };
    }
    catch (const std::bad_alloc& ex)
    {
        std::cerr << "Now we filled up memory, so assume we never access that stuff again and just moved on, or we're stuck in an endless loop of some sort...";
        while(true) { usleep(20000); };
    }
  return 0;
}

정말로 스왑을 원하는 사람들을 위한 해결 방법입니다. 만약 너라면

• --fail-swap-on=false kubelet 시작
• 노드에 스왑 추가
• 메모리 요구 사항을 지정하지 _않은_ 컨테이너는 기본적으로 스왑을 포함하여 모든 머신 메모리를 사용할 수 있습니다.

그게 우리가 하는 일입니다. 또는 적어도 개인적으로 실제로 구현하지는 않았지만 그것이 내가 수집하는 것이라고 확신합니다.

이것은 컨테이너 중 어느 것도 명시적 메모리 요구 사항을 지정하지 않는 경우에만 실제로 실행 가능한 전략일 수 있습니다.

안녕하세요 @hjwp님 , 정보 감사합니다. 정말 많은 도움이 됩니다!

이 다음에 질문해도 될까요?

당신이 말한대로 모든 것을 설정 한 후 컨테이너의 스왑 메모리 사용을 제한하는 방법이 있습니까?

Docker의 --memory-swap 매개변수 설정에 대해 생각하고 있었습니다.
https://docs.docker.com/config/containers/resource_constraints/# --memory-swap-details
현재 내 컨테이너에는 스왑 사용량에 대한 제한이 없습니다( "MemorySwap": -1 ).

sudo docker inspect 482d70f73c7c | grep Memory
            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

그러나 k8에서 노출된 이 매개변수를 찾을 수 없습니다.

그건 그렇고, 포드 메모리의 제한 도 스왑 사용량을 제한합니까?

내 VM 관련 설정

vm.overcommit_kbytes = 0
vm.overcommit_memory = 1
vm.overcommit_ratio = 50
vm.swappiness = 20
vm.vfs_cache_pressure = 1000

감사합니다!

@pai911 그건 불가능할 것 같은데,

현재 CRI는 이를 지원하지 않습니다. 이것을 참조하십시오. docker에는 --memory-swap 와 같은 옵션이 없습니다.

이것은 CRI 제한 사항이지만 OCI 사양은 이 옵션을 지원하지만 CRI 레이어로 내보내지는 않습니다.

가능한 (이론적으로) 솔루션 중 하나는 권한 있는 DaemonSet을 생성하여 포드에서 주석 데이터를 읽은 다음 DaemonSet가 cgroup 값을 수동으로 편집하는 것입니다.

cgroup

안녕하세요 @win-t 입니다.

피드백 주셔서 감사합니다!

현재로서는 이 옵션이 내부용으로만 사용됩니까?

이 --memory-swap 옵션에 어떤 cgroup 값이 매핑되는지 알고 있습니까?

현재로서는 이 옵션이 내부용으로만 사용됩니까?

예, k8에서 노출되지 않으므로 이 옵션을 설정할 수 없습니다.

btw, docker inspect의 MemorySwap 는 이것 에 따라 Memory 와 동일해야 합니다. docker inspect에서 -1 를 어떻게 얻을 수 있는지 모르겠습니다.

이 --memory-swap 옵션에 어떤 cgroup 값이 매핑되는지 알고 있습니까?

• --memory 에 고정 표시기지도 memory.limit_in_bytes cgroup에 v1을의
• --memory-swap 에 고정 표시기지도 memory.memsw.limit_in_bytes cgroup에 v1을의

@win- 정말 감사합니다!

나는 다음 버전을 사용하고 있습니다

Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.5", GitCommit:"20c265fef0741dd71a66480e35bd69f18351daea", GitTreeState:"clean", BuildDate:"2019-10-15T19:16:51Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.10", GitCommit:"1bea6c00a7055edef03f1d4bb58b773fa8917f11", GitTreeState:"clean", BuildDate:"2020-02-11T20:05:26Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

그리고 나는 역사를 보았다. 이 커밋 에 수정 사항이 추가 된 것 같습니다.

내가 실행하는 버전에 포함되어 있지 않을 수 있습니까?

현재로서는 이 옵션이 내부용으로만 사용됩니까?

예, k8에서 노출되지 않으므로 이 옵션을 설정할 수 없습니다.

btw, docker inspect의 MemorySwap 는 이것 에 따라 Memory 와 동일해야 합니다. docker inspect에서 -1 를 어떻게 얻을 수 있는지 모르겠습니다.

이 --memory-swap 옵션에 어떤 cgroup 값이 매핑되는지 알고 있습니까?

• --memory 에 고정 표시기지도 memory.limit_in_bytes cgroup에 v1을의
• --memory-swap 에 고정 표시기지도 memory.memsw.limit_in_bytes cgroup에 v1을의

이상하다.

나는 kops + Debian을 사용하고 있었고 Docker 검사는 스왑 메모리에 제한이 없음을 보여줍니다
(도커는 이전에 게시한 정보를 검사합니다)

그러나 Amazon Linux 이미지로 전환했고 이것이 내가 얻은 것입니다.

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

좀 더 조사해보고 이것이 버그인지 확인하겠습니다

현재로서는 이 옵션이 내부용으로만 사용됩니까?

예, k8에서 노출되지 않으므로 이 옵션을 설정할 수 없습니다.
btw, docker inspect의 MemorySwap 는 이것 에 따라 Memory 와 동일해야 합니다. docker inspect에서 -1 를 어떻게 얻을 수 있는지 모르겠습니다.

이 --memory-swap 옵션에 어떤 cgroup 값이 매핑되는지 알고 있습니까?

• --memory 에 고정 표시기지도 memory.limit_in_bytes cgroup에 v1을의
• --memory-swap 에 고정 표시기지도 memory.memsw.limit_in_bytes cgroup에 v1을의

이상하다.

나는 kops + Debian을 사용하고 있었고 Docker 검사는 스왑 메모리에 제한이 없음을 보여줍니다
(도커는 이전에 게시한 정보를 검사합니다)

그러나 Amazon Linux 이미지로 전환했고 이것이 내가 얻은 것입니다.

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

좀 더 조사해보고 이것이 버그인지 확인하겠습니다

이제 kops의 공식 데비안 이미지에 있는 문제를 재현할 수 있습니다.

이 kops 공식 이미지는 스왑 메모리를 무제한으로 만드는 것 같습니다
kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17

번식 단계:

내 kops 인스턴스 그룹은 다음과 같이 정의됩니다.

apiVersion: kops.k8s.io/v1alpha2
kind: InstanceGroup
metadata:
  creationTimestamp: "2020-03-12T06:33:09Z"
  generation: 5
  labels:
    kops.k8s.io/cluster: solrcluster.k8s.local
  name: node-2
spec:
  additionalUserData:
  - content: |
      #!/bin/sh
      sudo cp /etc/fstab /etc/fstab.bak
      sudo mkfs -t ext4 /dev/nvme1n1
      sudo mkdir /data
      sudo mount /dev/nvme1n1 /data
      echo '/dev/nvme1n1       /data   ext4    defaults,nofail        0       2' | sudo tee -a /etc/fstab
      sudo fallocate -l 2G /data/swapfile
      sudo chmod 600 /data/swapfile
      sudo mkswap /data/swapfile
      sudo swapon /data/swapfile
      echo '/data/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
      sudo sysctl vm.swappiness=10
      sudo sysctl vm.overcommit_memory=1
      echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
      echo 'vm.overcommit_memory=1' | sudo tee -a /etc/sysctl.conf
    name: myscript.sh
    type: text/x-shellscript
  image: kope.io/k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  instanceProtection: true
  kubelet:
    failSwapOn: false
  machineType: t3.micro

단계:

1. 클러스터가 가동되고 실행된 후.

2. 다음 리소스 설정으로 Solr Helm 차트 를 배포합니다.

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

** 다른 모든 Pod도 작동해야 합니다.

1. 컨테이너 ID를 찾기 위해 컨테이너 나열
   sudo docker container ls

2. 컨테이너의 메모리 매개변수 검사
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

문제를 어딘가에 제출해야 합니까? k8s 또는 kops?

단계:

1. 클러스터가 가동되고 실행된 후.
2. 다음 리소스 설정으로 Solr Helm 차트 를 배포합니다.

resources:
  limits:
    cpu: "1"
    memory: 640Mi
  requests:
    cpu: 100m
    memory: 256Mi

** 다른 모든 Pod도 작동해야 합니다.

1. 컨테이너 ID를 찾기 위해 컨테이너 나열
   sudo docker container ls
2. 컨테이너의 메모리 매개변수 검사
   sudo docker inspect d67a72bba427 | grep Memory

            "Memory": 671088640,
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": -1,
            "MemorySwappiness": null,

문제를 어딘가에 제출해야 합니까? k8s 또는 kops?

Amazon Linux에서만 올바른 동작을 볼 수 있음을 확인할 수 있습니다.
ami-0cbc6aae997c6538a : amzn2-ami-hvm-2.0.20200304.0-x86_64-gp2

            "Memory": 671088640,
            "CpusetMems": "",
            "KernelMemory": 0,
            "MemoryReservation": 0,
            "MemorySwap": 671088640,
            "MemorySwappiness": null,

즉: "MemorySwap" == "메모리"

다른 두 이미지는 모두 "MemorySwap": -1 같은 설정을 사용하므로 무제한 스왑 사용이 가능합니다.

• 데비안
  
  
  
  • ami-075e61ad77b1269a7 : k8s-1.15-debian-stretch-amd64-hvm-ebs-2020-01-17
  
  
• 우분투
  
  
  
  • ami-09a4a9ce71ff3f20b : 우분투/이미지/hvm-ssd/우분투-바이오닉-18.04-amd64-server-20200112
  
  

그래서 k8의 문제가 아닐까?

사용자 스토리:

(1) 내 공급업체에서 제공한 프로그램은 프로그램 코드 소스에 대한 액세스를 의무화하는 언어 런타임을 사용합니다. 이로 인해 초기화 시 모든 프로그램 소스 코드는 별도의 메모리 영역에 정리됩니다. 프로그램이 초기화되고 컨테이너가 준비 상태가 되면 이 메모리에 액세스할 수 없습니다(이를 증명할 수는 없지만 그렇지 않습니다). 또한 프로그램은 사용자 지정 OOM 처리를 위해 예약할 몇 페이지를 할당합니다. 이 메모리는 교체할 수 있습니다. 이 "데드 메모리"가 다른 클러스터 응용 프로그램을 밀어내는 것을 원하지 않습니다. 나는 죽게 될 메모리의 양을 정확하게 계산할 수 있고 그것을 Pod 사양에 스왑 요청으로 나열할 수 있습니다.

(2) 메모리 사용량이 갑자기 늘어나거나 줄어들 수 있는 기계 학습 또는 데이터 분석 워크로드를 실행하고 있습니다. 이러한 응용 프로그램이 종료되지 않고 결국 종료되지 않는 한 속도가 느려져도 괜찮습니다. 이러한 메모리 풍선이 발생할 때 축출을 완화하기 위해 스왑으로 클러스터를 프로비저닝하고 싶습니다. 이러한 Pod는 메모리 및 스왑에 대한 낮은 요청, 중간 메모리 제한(베이스라인 + 하나의 작업 세트에 충분할 수 있음) 및 큰 스왑 제한을 갖습니다.

(3) 때때로 fork+exec가 필요한 인터프리터(예: Ruby on Rails)에서 웹 서버를 실행하고 있습니다. 엄격한 메모리 계정은 허용할 수 없는 포크 실패를 초래합니다. 커널이 fork와 exec 호출 사이의 프로세스 동작을 처리하기 위해 보장된 메모리 헤드룸을 갖도록 스왑을 프로비저닝하고 싶습니다. vm.swappiness 값은 스와핑을 극도로 억제하도록 설정할 수 있으며 프로덕션 중에 스왑이 실제로 사용되는 경우 작업을 알리도록 경고를 설정했습니다. 포드 사양은 스왑 요청을 설정하고 동일한 값으로 제한합니다.

최근에 우리는 모든 도커 기반 서비스를 Kubernetes로 마이그레이션하려고 시도했지만 지원되지 않는 스왑으로 인해 프로젝트를 포기해야 했습니다.

스왑이 활성화된 상태에서 현재 실행 중인 것과 똑같은 수의 컨테이너를 지원하려면 하드웨어 양의 3배를 프로비저닝해야 한다는 것을 알았습니다.

주요 문제는 작업 부하가 최대 1Gb 정도의 메모리(또는 스왑)를 사용할 수 있는 여러 컨테이너로 구성되어 있지만 정상적으로 작동할 때 일반적으로 약 50Mb 정도를 사용한다는 것입니다.

스왑을 할 수 없다는 것은 큰 '작업'을 처리해야 할 때 스왑 블록을 사용할 수 있는 대신 처리해야 할 수 있는 가능한 가장 큰 로드를 위해 모든 것을 설계해야 한다는 것을 의미했습니다.

우리는 결국 Kubernetes로의 마이그레이션을 포기하고 스왑이 향후 지원될 것이라는 희망으로 당분간 모든 것을 Swarm으로 이동했습니다.

주요 문제는 작업 부하가 최대 1Gb 정도의 메모리(또는 스왑)를 사용할 수 있는 여러 컨테이너로 구성되어 있지만 정상적으로 작동할 때 일반적으로 약 50Mb 정도를 사용한다는 것입니다.

이러한 컨테이너에서 실행되는 응용 프로그램은 믿을 수 없을 정도로 제대로 작성되지 않았다고 감히 말할 수 있습니다.

이러한 컨테이너에서 실행되는 응용 프로그램은 믿을 수 없을 정도로 제대로 작성되지 않았다고 감히 말할 수 있습니다.

이것은 일종의 관련성이 없으며 손가락으로 가리키는 것은 거의 건설적이지 않습니다. Kubernetes 에코시스템은 광범위한 애플리케이션 프로필을 지원하도록 구축되었으며 이러한 프로필 중 하나를 선택하는 것은 의미가 없습니다.

주요 문제는 작업 부하가 최대 1Gb 정도의 메모리(또는 스왑)를 사용할 수 있는 여러 컨테이너로 구성되어 있지만 정상적으로 작동할 때 일반적으로 약 50Mb 정도를 사용한다는 것입니다.

이러한 컨테이너에서 실행되는 응용 프로그램은 믿을 수 없을 정도로 제대로 작성되지 않았다고 감히 말할 수 있습니다.

lol, 이것은 커널 기능이며 응용 프로그램은 shm 파일에서 madvise(2) 를 사용할 수 있으며 madvise syscall을 차단하지 않습니다.
따라서 사용자가 디자인에서 이 기능을 활용할 수 있으므로 "매우 형편없이 작성되었습니다"라고 말할 수 없습니다.

주요 문제는 작업 부하가 최대 1Gb 정도의 메모리(또는 스왑)를 사용할 수 있는 여러 컨테이너로 구성되어 있지만 정상적으로 작동할 때 일반적으로 약 50Mb 정도를 사용한다는 것입니다.

이러한 컨테이너에서 실행되는 응용 프로그램은 믿을 수 없을 정도로 제대로 작성되지 않았다고 감히 말할 수 있습니다.

귀하의 응답은 많은 개발자가 작업하는 작업 부하를 이해하지 못한다는 것을 나타냅니다.

내가 언급한 워크로드는 사용자가 제공하는 다양한 크기의 데이터 세트를 다루므로 광범위한 리소스 요구 사항이 필요합니다.

물론 메모리 사용을 일관되게 유지하기 위해 메모리 매핑된 파일을 _할 수 있습니다_. 그런 다음 메모리 매핑 자체를 사용하도록 라이브러리를 다시 작성해야 합니다. 여기에는 거의 모든 기존 라이브러리가 포함됩니다.

그러나 우리는 본질적으로 커널에서 관리하는 것보다 성능이 떨어지는 애플리케이션 특정 페이지 파일을 생성했을 것입니다.

일부 Kubernetes 배포에는 스왑이 필요합니다.

유효한 사용 사례가 있습니다. kubeadm에 포함된 온프레미스 제품인 Linux 배포판을 개발 중입니다. 설계상 수평적 확장이 없습니다. 기회주의적 메모리 피크에서 살아남고 여전히 기능(그러나 느림) 하려면 확실히 swap 이 필요합니다 .

스왑이 활성화된 상태에서 kubeadm 를 설치하려면

1. 다음 내용으로 /etc/systemd/system/kubelet.service.d/20-allow-swap.conf 파일을 만듭니다.

   [Service]
   Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false"
   

2. 운영

   sudo systemctl daemon-reload
   

3. --ignore-preflight-errors=Swap 플래그로 kubeadm 초기화

   kubeadm init --ignore-preflight-errors=Swap
   

https://stackoverflow.com/a/62158455/3191896

순진한 소프트웨어 개발자로서, 시간에 민감한 워크로드가 있는 시스템 포드가 스왑이 아닌 동작을 요청하고 다른 워크로드(기본적으로)가 최선의 범주로 푸시되는 것이 완벽하게 합리적으로 보입니다. 모든 고민이 해결되지 않을까요?

내 자신의 필요에 따라 많은 앱이 캐시의 이점을 얻습니다. 즉, 앱이 갑자기 많은 메모리를 필요로 하는 경우 해당 앱이 새로운 워크로드의 메모리 부족을 허용하는 것보다 더 낮은 메모리 압력에 대한 요청에 응답하지 않는 경우 가장 오래된 캐시를 디스크에 푸시하는 것이 좋습니다. 물리적 메모리로 버스트를 지원하고 롤링 배포를 위한 추가 기능과 잠재적인 노드 오류에 대한 추가 기능.

@metatic 은 다음과

물론, 우리는 일관성있는 메모리 사용을 유지하기 위해 메모리 매핑 된 파일을 사용할 수 있습니다. 그런 다음 메모리 매핑 자체를 사용하도록 라이브러리를 다시 작성해야 합니다. 여기에는 거의 모든 기존 라이브러리가 포함됩니다.

Linux 표준 C 라이브러리는 메모리 할당자를 대체하도록 설계되었습니다. malloc , realloc 및 free 는 해당 목적을 위해 포인터를 통해 호출됩니다. 따라서 mmapped 파일에서 할당하도록 라이브러리를 재정의하는 라이브러리를 LD_PRELOAD할 수 있습니다.

그러나 우리는 본질적으로 커널에서 관리하는 것보다 성능이 떨어지는 애플리케이션 특정 페이지 파일을 생성했을 것입니다.

커널에서 매우 동일한 코드로 관리되기 때문에 실제로 정상적인 스왑과 똑같이 수행됩니다. 유일한 차이점은 우선 순위를 조정하기 위한 swappiness 매개변수가 없다는 것입니다.

내가 가지고 있는 유일한 공개 질문은 이것이 이미 구현된 것인지 여부입니다("swapfs" kubelet soft/hard 제한 제외) - 구체적인 제안 및 조치 항목을 작성하기 전에 실제 kubelet/CRI cgroups 코드를 읽어야 합니다. .

@앵거슬리스 ,
행동을 확인하기 위해 주변을 둘러본 적이 있습니까? 그렇다면 해상도나 링크를 추가할 수 있습니까?

감사 해요,
1월

행동을 확인하기 위해 주변을 둘러본 적이 있습니까? 그렇다면 해상도나 링크를 추가할 수 있습니까?

나는하지 않았다. (도커 코드를 조금 파고 들었지만 지금쯤이면 모든 것을 잊어버렸고 다시 시작해야 할 것입니다)

다른 자원봉사자들도 환영합니다! 내가 이 일을 하겠다고 말하면서 누군가에게서 산소를 훔치지 않았으면 좋겠다.

@metick 의 스토리에 추가하려면:

현재 Kubernetes에서 실행되는 Gigalixir를 호스트로 사용하고 있습니다. 웹앱입니다. 때로는 클라이언트가 사진을 일괄 업로드하므로 내 앱에서 여러 ImageMagick 프로세스를 실행하여 크기를 조정합니다. 메모리 사용량이 급증하고 OOM 킬러가 실행되고 내 앱이 다운되고(잠시) 업로드가 중단됩니다.

나는 스파이크 사용량 때문에 Gigalixir에 내가 해야 하는 것보다 훨씬 더 많은 비용을 지불해야 합니다. 다른 사람들이 언급했듯이.

디자인 관점에서 스왑을 좋아하지 않을 수도 있지만 귀하의 결정은 사업가들에게 비용을 초래하고 있습니다. 이는 낭비입니다.

수정하세요. :)

이것은 저에게도 매우 큰 문제입니다. 제 사용 사례에서는 대부분 ~100MB를 사용하는 포드를 실행해야 하지만 때때로 사용자가 특정 이벤트를 트리거하면 다시 드롭백하기 전에 몇 분 동안 최대 2GB의 RAM을 버스트할 수 있습니다. 아니요, 잘못 작성되었기 때문이 아니라 작업 부하의 현실입니다.)
저는 스왑이 있는 16GB 시스템에서 한 번에 거의 100개의 이러한 워크로드를 실행합니다. 전혀 작동하지 않기 때문에 해당 워크로드를 Kubernetes로 이동할 수 없습니다. 그래서 지금은 내 메인 앱이 Kubernetes에서 실행되는 동안 비-kubernetes 시스템에서 이러한 워크로드를 실행하는 자체 오케스트레이터가 있으며, 이는 k8s로의 마이그레이션 목적을 무효화합니다. 스왑이 없으면 앱이 종료되거나 앱이 버스트할 수 있는(또는 그렇지 않을 수 있는) 몇 분 동안 사용 가능한 RAM을 항상 많이 낭비해야 합니다.

포드의 CPU를 조절하는 CPU 제한을 설정할 수 있는 경우 포드에서 사용하는 메모리를 조절하는 메모리 제한을 설정할 수 있어야 합니다. 메모리 제한에 도달했을 때 포드를 죽이는 것은 설정된 CPU 제한보다 더 많은 CPU 리소스를 사용하는 경우 하나를 죽이는 것만큼이나 터무니 없습니다(죄송하지만 모든 포드가 결과 없이 중단될 수 있는 복제본은 아닙니다).

Kubernetes는 전체 클러스터의 전체 성능에 영향을 줄 수 있기 때문에 노드의 스왑 세트와 함께 작동할 수 없습니다. 이상적으로는 포드 자체에 해당 컨테이너 내의 프로세스만 스왑되는 포드 수준 스왑 파일이 있어야 합니다. 이것은 이론적으로 CPU 제한이 제한하는 것처럼 메모리 제한을 초과하는 포드의 RAM 사용량 및 성능(스와핑으로 인해)을 제한합니다.
불행히도 cgroup이 스왑 파일을 지정할 수 있는 것 같지는 않고 스왑 상태만 지정할 수 있으며 커널이 "mem 사용량이 이 한도를 초과하면 스왑"하도록 지시할 수 없습니다. 액세스 및 기타 측정항목.

그러나 그 동안 노드에 스왑이 존재하지 않도록 하고 제한이 설정되지 않은 포드에 대해 swappiness를 0으로 설정하고 제한이 설정되면(또는 "swapInsteadOfKill"이라고 말하는 일부 다른 사양 필드) 다음을 설정합니다. 0이 아닌 값으로의 스왑 가능성?

"스왑 여부"에 대한 논의 외에도 @pai911 이 설명한 동작이 k8 팀에서 더 이상 해결되지

kubelet이 docker 데몬 메모리 설정과 관련하여 다르게 동작하는 것(그리고 위에서 언급한 코드를 따르지 않는 일부 OS에서)을 확인할 수 있습니다. 우리 클러스터는 SUSE Linux에서 실행되며 https://github.com/kubernetes/kubernetes/issues/53533#issuecomment -598056151에서 언급한 것과 동일한 무제한 스왑 사용을 경험하고 있습니다.

OS 세부 정보: SUSE Linux Enterprise Server 12 SP4 - Linux 4.12.14-95.45-default

어쨌든 k8s에서 Swap에 대한 적절한 지원이 없으면 기본 OS에 관계없이 kubelet이 Docker 메모리 설정을 일관되게 처리하기를 바랍니다.

나는 1.21에서 이것을 추진하는 데 도움이 되는 커뮤니티의 욕구나 자원 봉사자가 있는지 확인하기 위해 의제에 스왑을 설정했습니다. 2017년에 언급했듯이 스왑을 지원하는 데 이의가 없습니다. kubelet 제거, 포드 우선 순위, 포드 서비스 품질을 혼동하지 않도록 해야 하며, 중요하게는 포드가 스왑을 허용하는지 여부를 말할 수 있어야 합니다. 이러한 모든 사항은 포드를 휴대할 수 있도록 하는 데 중요합니다.

최근에는 NUMA 정렬 메모리와 같은 작업을 만드는 데 많은 에너지가 집중되어 있지만 성능에 덜 민감하고 이 공간을 앞으로 나아가는 데 도움이 되도록 동기를 부여하는 사람들이 있다면 설계를 시작하는 데 도움이 되었으면 합니다. 이 공간에서 자세한 KEP.

최근에 일이 너무 바빠서 커뮤니티 프로세스를 끔찍하게 잘 따라가지 못했습니다. Slack 채널에 가입하지 않고도 참여할 수 있는 방법이 있습니까?