Forth Korean l10n work for release-1.19

- Fix ko glossary managed service title (#24621) - Translate reference/glossary/service-broker.md in Korean (#24632) - Translate reference/command-line-tools-reference/kubelet-authentication-authorization.md into korean (#24623) - Update outdated files in the dev-1.19-ko.4 branch (#24622) - Translate setup/production-environment/tools/kubeadm/self-hosting/ into Korean (#24655) - Translate reference/kubectl/kubectl.md into Korean (#24482) - docs: fix typo (#24713) - Translate connecting-frontend-backend to Korean (#24422) - Translate reference/kubectl/conventions.md into Korean (#24614) - Translate k8s 1.19 relaese note in korean (#24633) Co-authored-by: seokho-son <shsongist@gmail.com> Co-authored-by: santachopa <santachopa@naver.com> Co-authored-by: kosehy@gmail.com <kosehy@gmail.com> Co-authored-by: Jerry Park <jaehwa@gmail.com> Co-authored-by: markruler <csu0414@gmail.com> Co-authored-by: noel <neutiyoo@gmail.com> Co-authored-by: coolguyhong <podolsmith@naver.com> Co-authored-by: chhanz <han0495@gmail.com> Co-authored-by: bluefriday <bluefriday86@gmail.com>
kubernetes · Nov 1, 2020 · 6d27247 · 6d27247
1 parent 253eff2
commit 6d27247
Show file tree

Hide file tree

Showing 69 changed files with 3,997 additions and 983 deletions.
diff --git a/content/ko/_index.html b/content/ko/_index.html
@@ -2,11 +2,13 @@
 title: "운영 수준의 컨테이너 오케스트레이션"
 abstract: "자동화된 컨테이너 배포, 스케일링과 관리"
 cid: home
+sitemap:
+  priority: 1.0
 ---
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-### [쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
+[쿠버네티스(K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
 
 애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
 {{% /blocks/feature %}}

diff --git a/content/ko/docs/_index.md b/content/ko/docs/_index.md
@@ -1,4 +1,6 @@
 ---
 linktitle: 쿠버네티스 문서
 title: 문서
+sitemap:
+  priority: 1.0
 ---
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
@@ -12,7 +12,7 @@ weight: 10
 {{< glossary_tooltip text="파드" term_id="pod" >}}를
 실행하는데 필요한 서비스가 포함되어 있다.
 
-일반적으로 클러스터에는 여러개의 노드가 있으며, 학습 또는 리소스가 제한되는
+일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는
 환경에서는 하나만 있을 수도 있다.
 
 노드의 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에는

diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md
@@ -16,33 +16,45 @@ weight: 20
 {{< /caution >}}
 
 
-
 <!-- body -->
 ## 사용 동기
 
 애플리케이션 코드와 별도로 구성 데이터를 설정하려면 컨피그맵을 사용하자.
 
 예를 들어, 자신의 컴퓨터(개발용)와 클라우드(실제 트래픽 처리)에서
 실행할 수 있는 애플리케이션을 개발한다고 가정해보자.
-`DATABASE_HOST` 라는
-환경 변수를 찾기 위해 코드를 작성한다. 로컬에서는 해당 변수를
-`localhost` 로 설정한다. 클라우드에서는, 데이터베이스
-컴포넌트를 클러스터에 노출하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}를 참���하도록
-설정한다.
-
+`DATABASE_HOST` 라는 환경 변수를 찾기 위해 코드를 작성한다.
+로컬에서는 해당 변수를 `localhost` 로 설정한다. 클라우드에서는, 데이터베이스
+컴포넌트를 클러스터에 노출하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}를
+참조하도록 설정한다.
 이를 통해 클라우드에서 실행 중인 컨테이너 이미지를 가져와
 필요한 경우 정확히 동일한 코드를 로컬에서 디버깅할 수 있다.
 
+컨피그맵은 많은 양의 데이터를 보유하도록 설계되지 않았다. 컨피그맵에 저장된
+데이터는 1MiB를 초과할 수 없다. 이 제한보다 큰 설정을
+저장해야 하는 경우, 볼륨을 마운트하는 것을 고려하거나 별도의
+데이터베이스 또는 파일 서비스를 사용할 수 있다.
+
 ## 컨피그맵 오브젝트
 
 컨피그맵은 다른 오브젝트가 사용할 구성을 저장할 수 있는
 API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)이다.
-`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리,
-컨피그맵에는 항목(키)과 해당 값을 저장하는 `data` 섹션이 있다.
+`spec` 이 있는 대부분의 쿠버네티스 오브젝트와 달리, 컨피그맵에는 `data` 및 `binaryData`
+필드가 있다. 이러한 필드는 키-값 쌍을 값으로 허용한다. `data` 필드와
+`binaryData` 는 모두 선택 사항이다. `data` 필드는
+UTF-8 바이트 시퀀스를 포함하도록 설계되었으며 `binaryData` 필드는 바이너리 데이터를
+포함하도록 설계되었다.
 
 컨피그맵의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
+`data` 또는 `binaryData` 필드 아래의 각 키는
+영숫자 문자, `-`, `_` 또는 `.` 으로 구성되어야 한다. `data` 에 저장된 키는
+`binaryData` 필드의 키와 겹치지 않아야 한다.
+
+v1.19부터 컨피그맵 정의에 `immutable` 필드를 추가하여
+[변경할 수 없는 컨피그맵](#configmap-immutable)을 만들 수 있다.
+
 ## 컨피그맵과 파드
 
 컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를
@@ -62,7 +74,7 @@ data:
   # 속성과 비슷한 키; 각 키는 간단한 값으로 매핑됨
   player_initial_lives: "3"
   ui_properties_file_name: "user-interface.properties"
-  #
+
   # 파일과 비슷한 키
   game.properties: |
     enemy.types=aliens,monsters
@@ -94,6 +106,7 @@ data:
 기술을 사용하여 다른 네임스페이스의 컨피그맵에 접근할 수도 있다.
 
 다음은 `game-demo` 의 값을 사용하여 파드를 구성하는 파드 예시이다.
+
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -102,7 +115,8 @@ metadata:
 spec:
   containers:
     - name: demo
-      image: game.example/demo-game
+      image: alpine
+      command: ["sleep", "3600"]
       env:
         # 환경 변수 정의
         - name: PLAYER_INITIAL_LIVES # 참고로 여기서는 컨피그맵의 키 이름과
@@ -134,7 +148,6 @@ spec:
           path: "user-interface.properties"
 ```
 
-
 컨피그맵은 단일 라인 속성(single line property) 값과 멀티 라인의 파일과 비슷한(multi-line file-like) 값을
 구분하지 않는다.
 더 중요한 것은 파드와 다른 오브젝트가 이러한 값을 소비하는 방식이다.
@@ -153,7 +166,6 @@ spec:
 노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
 컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
 
-{{< note >}}
 컨피그맵을 사용하는 가장 일반적인 방법은 동일한 네임스페이스의
 파드에서 실행되는 컨테이너에 대한 설정을 구성하는 것이다. 컨피그맵을
 별도로 사용할 수도 있다.
@@ -162,16 +174,23 @@ spec:
 컨피그맵에 기반한 동작을 조정하는 {{< glossary_tooltip text="애드온" term_id="addons" >}}이나
 {{< glossary_tooltip text="오퍼레이터" term_id="operator-pattern" >}}를
 사용할 수도 있다.
-{{< /note >}}
 
 ### 파드에서 컨피그맵을 파일로 사용하기
 
 파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.
 
-1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다.
-1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name` 필드를 설정한다.
-1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
-1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다.
+1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을
+   참조할 수 있다.
+1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은
+   원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name`
+   필드를 설정한다.
+1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를
+   추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고
+   컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로
+   `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
+1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을
+   수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의
+   파일 이름이 된다.
 
 다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다.
 
@@ -225,12 +244,14 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최
 데이터 변경을 방지하면 다음과 같은 이점이 있다.
 
 - ��플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
-- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
+- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써
+  클러스터의 성능을 향상시킴
+
+이 기능은 `ImmutableEphemeralVolumes`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 의해 제어된다.
+`immutable` 필드를 `true` 로 설정하여 변경할 수 없는 컨피그맵을 생성할 수 있다.
+다음은 예시이다.
 
-이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
-의해 제어된다. `immutable` 필드를 `true` 로 설정하여
-변경할 수 없는 컨피그맵을 생성할 수 있다. 다음은 예시이다.
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -242,15 +263,14 @@ immutable: true
 ```
 
 {{< note >}}
-컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나
-`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다.
-기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는
-것을 권장한다.
+컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나
+`data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만
+삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을
+유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다.
 {{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
-
 * [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 읽어본다.
 * [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)�� 읽어본다.
 * 코드를 구성에서 분리하려는 동기를 이해하려면

diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md
@@ -47,6 +47,13 @@ feature:
 또는 강제적(시스템이 컨테이너가 제한을 초과하지 않도록 방지)으로 구현할 수 있다. 런타임마다
 다른 방식으로 동일한 제약을 구현할 수 있다.
 
+{{< note >}}
+컨테이너가 자체 메모리 제한을 지정하지만, 메모리 요청을 지정하지 않는 경우, 쿠버네티스는
+제한과 일치하는 메모리 요청을 자동으로 할당한다. 마찬가지로, 컨테이너가 자체 CPU 제한을
+지정하지만, CPU 요청을 지정하지 않는 경우, 쿠버네티스는 제한과 일치하는 CPU 요청을 자동으로
+할당한다.
+{{< /note >}}
+
 ## 리소스 타입
 
 *CPU* 와 *메모리* 는 각각 *리소스 타입* 이다. 리소스 타입에는 기본 단위가 있다.

diff --git a/content/ko/docs/concepts/containers/container-lifecycle-hooks.md b/content/ko/docs/concepts/containers/container-lifecycle-hooks.md
@@ -6,7 +6,7 @@ weight: 30
 
 <!-- overview -->
 
-이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서 
+이 페이지는 kubelet이 관리하는 컨테이너가 관리 라이프사이클 동안의 이벤트에 의해 발동되는 코드를 실행하기 위해서
 컨테이너 라이프사이클 훅 프레임워크를 사용하는 방법에 대해서 설명한다.
 
 
@@ -16,9 +16,9 @@ weight: 30
 
 ## 개요
 
-Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게, 
+Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로그래밍 언어 프레임워크와 유사하게,
 쿠버네티스도 컨테이너에 라이프사이클 훅을 제공한다.
-훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는 
+훅은 컨테이너가 관리 라이프사이클의 이벤트를 인지하고 상응하는
 라이프사이클 훅이 실행될 때 핸들러에 구현된 코드를 실행할 수 있게 한다.
 
 ## 컨테이너 훅
@@ -33,12 +33,12 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 
 `PreStop`
 
-이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다. 
-그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로, 
-컨테이너를 삭제하기 위한 호출이 전송되기 전에 완료되어야한다.
+이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다.
+그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로,
+컨테이너를 중지하기 위한 신호가 전송되기 전에 완료되어야 한다.
 파라미터는 핸들러에 전달되지 않는다.
 
-종료 동작에 더 자세한 대한 설명은 
+종료 동작에 더 자세한 대한 설명은
 [파드의 종료](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료)에서 찾을 수 있다.
 
 ### 훅 핸들러 구현
@@ -52,34 +52,46 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 
 ### 훅 핸들러 실행
 
-컨테이너 라이프사이클 관리 훅이 호출되면, 
-쿠버네티스 관리 시스템은 해당 훅이 등록된 컨테이너에서 핸들러를 실행한다.
+컨테이너 라이프사이클 관리 훅이 호출되면,
+쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고,
+`exec` 와 `tcpSocket` 은 컨테이너에서 실행되고, `httpGet` 은 kubelet 프로세스에 의해 실행된다.
 
-훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 맥락과 동기적으로 동작한다. 
-이것은 `PostStart` 훅에 대해서, 
+훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다.
+이것은 `PostStart` 훅에 대해서,
 훅이 컨테이너 엔트리포인트와는 비동기적으로 동작함을 의미한다.
-그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면, 
+그러나, 만약 해당 훅이 너무 오래 동작하거나 어딘가에 걸려 있다면,
 컨테이너는 `running` 상태에 이르지 못한다.
 
-이러한 동작은 `PreStop` 훅에 대해서도 비슷하게 일어난다.
-만약 훅이 실행되던 도중에 매달려 있다면, 
-파드의 단계(phase)는 `Terminating` 상태에 머물고 해당 훅은 파드의 `terminationGracePeriodSeconds`가 끝난 다음에 종료된다.
+`PreStop` 훅은 컨테이너 중지 신호에서 비동기적으로
+실행되지 않는다. 훅은 신호를 보내기 전에 실행을
+완료해야 한다.
+실행 중에 `PreStop` 훅이 중단되면,
+파드의 단계는 `Terminating` 이며 `terminationGracePeriodSeconds` 가
+만료된 후 파드가 종료될 때까지 남아 있다.
+이 유예 기간은 `PreStop` 훅이 실행되고 컨테이너가
+정상적으로 중지되는 데 걸리는 총 시간에 적용된다.
+예를 들어, `terminationGracePeriodSeconds` 가 60이고, 훅이
+완료되는 데 55초가 걸리고, 컨테이너가 신호를 수신한 후
+정상적으로 중지하는 데 10초가 걸리면, `terminationGracePeriodSeconds` 이후
+컨테이너가 정상적으로 중지되기 전에 종료된다. 이 두 가지 일이 발생하는 데
+걸리는 총 시간(55+10)보다 적다.
+
 만약 `PostStart` 또는 `PreStop` 훅이 실패하면,
 그것은 컨테이너를 종료시킨다.
 
 사용자는 훅 핸들러를 가능한 한 가볍게 만들어야 한다.
-그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이, 
+그러나, 컨테이너가 멈추기 전 상태를 저장하는 것과 같이,
 오래 동작하는 커맨드가 의미 있는 경우도 있다.
 
 ### 훅 전달 보장
 
-훅 전달은 *한 번 이상* 으로 의도되어 있는데, 
-이는 `PostStart` 또는 `PreStop`와 같은 특정 이벤트에 대해서, 
+훅 전달은 *한 번 이상* 으로 의도되어 있는데,
+이는 `PostStart` 또는 `PreStop`와 같은 특정 이벤트에 대해서,
 훅이 여러 번 호출될 수 있다는 것을 의미한다.
 이것을 올바르게 처리하는 것은 훅의 구현에 달려 있다.
 
 일반적으로, 전달은 단 한 번만 이루어진다.
-예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도, 
+예를 들어, HTTP 훅 수신기가 다운되어 트래픽을 받을 수 없는 경우에도,
 재전송을 시도하지 않는다.
 그러나, 드문 경우로, 이중 전달이 발생할 수 있다.
 예를 들어, 훅을 전송하는 도중에 kubelet이 재시작된다면,
@@ -88,8 +100,8 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
 ### 디버깅 훅 핸들러
 
 훅 핸들러의 로그는 파드 이벤트로 노출되지 않는다.
-만약 핸들러가 어떠한 이유로 실패하면, 핸들러��� 이벤트를 방송한다. 
-`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며, 
+만약 핸들러가 어떠한 이유로 실패하면, 핸들러는 이벤트를 방송한다.
+`PostStart`의 경우, 이것은 `FailedPostStartHook` 이벤트이며,
 `PreStop`의 경우, 이것은 `FailedPreStopHook` 이벤트이다.
 이 이벤트는 `kubectl describe pod <파드_이름>`를 실행하면 볼 수 있다.
 다음은 이 커맨드 실행을 통한 이벤트 출력의 몇 가지 예다.
@@ -117,5 +129,3 @@ Events:
 * [컨테이너 환경](/ko/docs/concepts/containers/container-environment/)에 대해 더 배우기.
 * [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)
   실습 경험하기.
-
-
diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md
@@ -178,7 +178,7 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/referenc
 ## {{% heading "whatsnext" %}}
 
 
-- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)
-- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)
+- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
+- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
 - [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)