[ko] Update outdated files in dev-1.26-ko.1 (M45-M57)

Signed-off-by: jongwooo <[email protected]>
kubernetes · Mar 21, 2023 · 7204634 · 7204634
1 parent 47c624c
commit 7204634
Show file tree

Hide file tree

Showing 13 changed files with 52 additions and 49 deletions.
diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md
@@ -1,6 +1,6 @@
 ---
 title: "스케줄링, 선점(Preemption), 축출(Eviction)"
-weight: 90
+weight: 95
 content_type: concept
 description: >
   쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 
@@ -26,8 +26,10 @@ no_list: true
 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)
 * [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)
 * [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/)
+* [동적 리소스 할당](/docs/concepts/scheduling-eviction/dynamic-resource-allocation)
 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/)
+* [파드 스케줄링 준비성(readiness)](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/)
 
 ## 파드 중단(disruption)
 

diff --git a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md
@@ -1,7 +1,7 @@
 ---
 title: API를 이용한 축출(API-initiated Eviction)
 content_type: concept
-weight: 70
+weight: 110
 ---
 
 {{< glossary_definition term_id="api-eviction" length="short" >}} </br>

diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -2,7 +2,7 @@
 # reviewers:
 # - davidopp
 # - kevin-wangzefeng
-# - bsalamat
+# - alculquicondor
 title: 노드에 파드 할당하기
 content_type: concept
 weight: 20
@@ -144,13 +144,13 @@ kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을
 `nodeSelector`와 `nodeAffinity`를 모두 사용하는 경우, 
 파드가 노드에 스케줄링되려면 두 조건 *모두* 만족되어야 한다.
 
-`nodeAffinity`에 연결된 `nodeSelectorTerms`를 여러 개 명시한 경우, 
-명시된 `nodeSelectorTerms` 중 하나를 만족하는 노드에도 
-파드가 스케줄링될 수 있다.
+`nodeAffinity`의 `nodeSelectorTerms`에 여러 조건(term)을 명시한 경우,
+노드가 명시된 조건 중 하나만 만족해도 파드가
+해당 노드에 스케줄링될 수 있다. (조건들은 OR 연산자로 처리)
 
-단일 `nodeSelectorTerms`와 연결된 `matchExpressions`를 여러 개 명시한 경우, 
-모든 `matchExpressions`를 만족하는 노드에만 
-파드가 스케줄링될 수 있다.
+`nodeSelectorTerms`의 조건으로 단일 `matchExpressions` 필드에 여러 표현식(expression)을 명시한 경우,
+모든 표현식을 동시에 만족하는 노드에만
+파드가 스케줄링될 수 있다. (표현식들은 AND 연산자로 처리)
 {{</note>}}
 
 [노드 어피니티를 사용해 노드에 파드 할당](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)에서 

diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -32,11 +32,11 @@ weight: 10
 kube-scheduler는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를
 만들고 대신 사용할 수 있도록 설계되었다.
 
-새로 생성된 모든 파드 또는 예약되지 않은 다른 파드에 대해 kube-scheduler는
-실행할 최적의 노드를 선택한다. 그러나 파드의 모든 컨테이너에는
-리소스에 대한 요구사항이 다르며 모든 파드에도
-요구사항이 다르다. 따라서 기존 노드들은
-특정 스케줄링 요구사항에 따라 필터링 되어야 한다.
+kube-scheduler는 새로 생성되었거나 아직 
+예약되지 않은(스케줄링되지 않은) 파드를 실행할 최적의 노드를 선택한다. 파드의 컨테이너와 파드 자체는 
+서로 다른 요구사항을 가질 수 있으므로, 스케줄러는 파드의 특정 스케줄링 요구사항을 
+충족하지 않는 모든 노드를 필터링한다. 또는 API를 사용하면 파드를 생성할 때 노드를 지정할 수 있지만, 이는 드문 경우이며 
+특별한 경우에만 수행된다.
 
 클러스터에서 파드에 대한 스케줄링 요구사항을 충족하는 노드를
 _실행 가능한(feasible)_ 노드라고 한다. 적합한 노드가 없으면 스케줄러가

diff --git a/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md
@@ -1,13 +1,13 @@
 ---
 title: 노드-압박 축출
 content_type: concept
-weight: 60
+weight: 100
 ---
 
 {{<glossary_definition term_id="node-pressure-eviction" length="short">}}</br>
 
 {{<glossary_tooltip term_id="kubelet" text="kubelet">}}은 
-클러스터 노드의 CPU, 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다.
+클러스터 노드의 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다.
 이러한 자원 중 하나 이상이 특정 소모 수준에 도달하면, 
 kubelet은 하나 이상의 파드를 능동적으로 중단시켜 
 자원을 회수하고 고갈 상황을 방지할 수 있다.
@@ -154,6 +154,12 @@ kubelet은 다음과 같은 하드 축출 임계값을 기본적으로 설정하
 * `imagefs.available<15%`
 * `nodefs.inodesFree<5%` (리눅스 노드)
 
+이러한 하드 축출 임계값의 기본값은 
+매개변수가 변경되지 않은 경우에만 설정된다. 어떤 매개변수의 값을 변경한 경우,
+다른 매개변수의 값은 기본값으로 상속되지 않고
+0으로 설정된다. 사용자 지정 값을 제공하려면,
+모든 임계값을 각각 제공해야 한다.
+
 ### 축출 모니터링 시간 간격
 
 kubelet은 `housekeeping-interval`에 설정된 시간 간격(기본값: `10s`)마다 

diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
@@ -4,7 +4,7 @@
 # - wojtek-t
 title: 파드 우선순위(priority)와 선점(preemption)
 content_type: concept
-weight: 70
+weight: 90
 ---
 
 <!-- overview -->

diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@@ -3,7 +3,7 @@
 # - bsalamat
 title: 스케줄러 성능 튜닝
 content_type: concept
-weight: 100
+weight: 70
 ---
 
 <!-- overview -->

diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -5,7 +5,7 @@
 # - bsalamat
 title: 테인트(Taints)와 톨러레이션(Tolerations)
 content_type: concept
-weight: 40
+weight: 50
 ---
 
 

diff --git a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md
@@ -45,7 +45,6 @@ weight: 40
 
 파드 토폴로지 분배 제약 조건은 이러한 설정을 할 수 있도록 하는 선언적인 방법을 제공한다.
 
-
 ## `topologySpreadConstraints` 필드
 
 파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 이 필드는 다음과 같이 
@@ -66,8 +65,8 @@ spec:
       whenUnsatisfiable: <string>
       labelSelector: <object>
       matchLabelKeys: <list> # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
-      nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
-      nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
+      nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다.
+      nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.26에서 베타 기능으로 도입되었다.
   ### 파드의 다른 필드가 이 아래에 오게 된다.
 ```
 
@@ -99,7 +98,7 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
 
   {{< note >}}
   `minDomains` 필드는 1.25에서 기본적으로 사용하도록 설정된 베타 필드이다. 사용을 원하지 않을 경우 
-  `MinDomainsInPodToplogySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다.
+  `MinDomainsInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다.
   {{< /note >}}
 
   - `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다. 
@@ -158,9 +157,9 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
   옵션의 값이 null일 경우, Honor 정책과 동일하게 동작한다.
 
   {{< note >}}
-  `nodeAffinityPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면
+  `nodeAffinityPolicy` 필드는 베타 필드이고 1.26에서 기본적으로 활성화되어 있다. 이 필드를 비활성화하려면
   `NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-  를 활성화시켜야 한다.
+  를 비활성화하면 된다.
   {{< /note >}}
 
 - **nodeTaintsPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때 노드 테인트(taint)를 
@@ -172,9 +171,9 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
   옵션의 값이 null일 경우, Ignore 정책과 동일하게 동작한다.
 
   {{< note >}}
-  `nodeTaintsPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면
+  `nodeTaintsPolicy` 필드는 베타 필드이고 1.26에서 기본적으로 활성화되어 있다. 이 필드를 비활성화하려면
   `NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-  를 활성화시켜야 한다.
+  를 비활성화하면 된다.
   {{< /note >}}
 
 파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 
@@ -202,7 +201,6 @@ kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노
 모두 우리의 생각과 같을 것이라고 가정할 수는 없다.
 {{< /note >}}
 
-
 각각 다음과 같은 레이블을 갖는 4개의 노드로 구성된 클러스터가 있다고 가정한다.
 
 ```
@@ -496,7 +494,7 @@ class zoneC cluster;
 
 기본 제약 조건은 
 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)내의 플러그인 인자 중 하나로 설정할 수 있다. 
-제약 조건은 [위에서 설명한 것과 동일한 API](#api)를 이용하여 정의되는데, 
+제약 조건은 [위에서 설명한 것과 동일한 API](#topologyspreadconstraints-필드)를 이용하여 정의되는데,
 다만 `labelSelector`는 비워 두어야 한다. 
 셀렉터는 파드가 속한 서비스, 레플리카셋, 스테이트풀셋, 또는 레플리케이션 컨트롤러를 바탕으로 계산한다.
 
@@ -581,6 +579,7 @@ profiles:
 `podAffinity`
 : 파드를 끌어당긴다. 조건이 충족되는 토폴로지 도메인에는
   원하는 수의 파드를 얼마든지 채울 수 있다.
+
 `podAntiAffinity`
 : 파드를 밀어낸다. 
   이를 `requiredDuringSchedulingIgnoredDuringExecution` 모드로 설정하면 
@@ -616,7 +615,6 @@ profiles:
   전반적인 토폴로지 도메인 집합에 대한 정보를 인지하고 동작하는 
   클러스터 오토스케일링 도구를 이용할 수 있다.
 
-
 ## {{% heading "whatsnext" %}}
 
 - [블로그: PodTopologySpread 소개](/blog/2020/05/introducing-podtopologyspread/)에서는

diff --git a/content/ko/docs/concepts/security/_index.md b/content/ko/docs/concepts/security/_index.md
@@ -1,6 +1,6 @@
 ---
 title: "보안"
-weight: 81
+weight: 85
 description: >
   클라우드 네이티브 워크로드를 안전하게 유지하기 위한 개념
 ---
diff --git a/content/ko/docs/concepts/security/multi-tenancy.md b/content/ko/docs/concepts/security/multi-tenancy.md
@@ -1,7 +1,7 @@
 ---
 title: 멀티 테넌시(multi-tenancy)
 content_type: concept
-weight: 70
+weight: 80
 ---
 
 <!-- overview -->
@@ -27,7 +27,7 @@ _멀티 테넌시_ 라는 포괄적 용어로 통칭한다.
 사용 가능한 패턴과 툴을 산정하기 위해 유스케이스를 이해하는 것이다. 일반적으로 쿠버네티스에서의 멀티 테넌시는 
 다양한 형태로 변형 또는 혼합이 가능하지만, 넓게는 두 가지 범주로 분류된다.
 
-### 다수의 팀 
+### 다수의 팀
 
 흔히 사용하는 멀티 테넌시의 형태는 하나 또는 그 이상의 워크로드를 
 운영하는 한 조직 소속의 여러 팀이 하나의 클러스터를 공유하는 형태이다. 이러한 워크로드는 
@@ -39,7 +39,7 @@ GitOps 컨트롤러 혹은 다른 종류의 배포 자동화 툴을 통해 간
 안전하고 공평한 클러스터 공유를 위해서는 
 RBAC, 쿼터(quota), 네트워크 정책과 같은 쿠버네티스 정책이 필수이다.
 
-### 다수의 고객 
+### 다수의 고객
 
 다른 주요 멀티 테넌시 형태로는 서비스형소프트웨어(SaaS) 사업자가 
 여러 고객의 워크로드 인스턴스를 실행하는 것과 관련이 있다. 
@@ -217,8 +217,10 @@ _소란스러운 이웃_ 문제를 예방하기 위한 목적을 가지고 있
 의해 제어될 수 있다. 테넌트 간의 엄격한 네트워크 격리가 필요한 멀티 테넌트 환경에서는, 
 파드 간의 통신을 거부하는 기본 정책과 모든 파드가 네임 해석(name resolution)을 위해 
 DNS 서버를 쿼리하도록 하는 규칙을 시작에 설정하는 것을 권고한다. 이러한 기본 정책을 
-기반으로 하여, 네임스페이스 내에서 통신을 허용하는 관대한 규칙을 추가할 수 있다. 이러한 
-방식은 요구에 따라 한 단계 더 정제할 수 있다. 이는 하나의 컨트롤 플레인 내의 파드에 
+기반으로 하여, 네임스페이스 내에서 통신을 허용하는 관대한 규칙을 추가할 수 있다.
+또한 네임스페이스 간에 트래픽을 허용해야 하는 경우 네트워크 정책 정의의 
+namespaceSelector 필드에 빈 레이블 셀렉터 '{}'를 사용하지 않는 것이 좋다.
+이러한 방식은 요구에 따라 한 단계 더 정제할 수 있다. 이는 하나의 컨트롤 플레인 내의 파드에 
 대해서만 적용된다는 것을 알아두어야 한다. 서로 다른 가상의 컨트롤 플레인에 소속된 파드는 
 쿠버네티스 네트워킹을 통해 통신할 수 없다. 
 
@@ -513,4 +515,3 @@ _가상 컨트롤 플레인_ 이라고 부른다.
 
 * [Kamaji](https://github.com/clastix/kamaji)
 * [vcluster](https://github.com/loft-sh/vcluster)
-
diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md
@@ -56,13 +56,13 @@ weight: 1
 IaaS 공급자        | 링크 |
 -------------------- | ------------ |
 Alibaba Cloud | https://www.alibabacloud.com/trust-center |
-Amazon Web Services | https://aws.amazon.com/security/ |
-Google Cloud Platform | https://cloud.google.com/security/ |
-Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html |
+Amazon Web Services | https://aws.amazon.com/security |
+Google Cloud Platform | https://cloud.google.com/security |
+Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety |
 IBM Cloud | https://www.ibm.com/cloud/security |
 Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
-Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
-VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
+Oracle Cloud Infrastructure | https://www.oracle.com/security |
+VMware vSphere | https://www.vmware.com/security/hardening-guides.html |
 
 {{< /table >}}
 

diff --git a/content/ko/docs/concepts/security/pod-security-policy.md b/content/ko/docs/concepts/security/pod-security-policy.md
@@ -1,19 +1,16 @@
 ---
-# reviewers:
-# - liggitt
-# - tallclair
 title: 파드 시큐리티 폴리시
 content_type: concept
 weight: 30
 ---
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
-
-{{< note >}}
+{{% alert title="제거된 기능" color="warning" %}}
 파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 1.21 버전부터 [사용 중단(deprecated)](/blog/2021/04/08/kubernetes-1-21-release-announcement/#podsecuritypolicy-deprecation)되었으며, 
 v1.25 버전 때 쿠버네티스에서 제거되었다. 
+{{% /alert %}}
+
 파드시큐리티폴리시를 사용하는 것 대신, 다음 중 하나를 사용하거나 둘 다 사용하여 파드에 유사한 제한을 
 적용할 수 있다.
 
@@ -26,4 +23,3 @@ v1.25 버전 때 쿠버네티스에서 제거되었다.
 
 쿠버네티스 v{{< skew currentVersion >}} 이외의 버전을 실행 중이라면,
 해당 쿠버네티스 버전에 대한 문서를 확인한다.
-{{< /note >}}