diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 40bea7b523..0fa8d8658a 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -24,7 +24,8 @@ cid: community 비디오      토론      이벤트와 모임들      -새소식 +새소식      +릴리즈

diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 7e67dd604f..270063a737 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -23,7 +23,7 @@ content_type: concept * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. * [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. * [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 21b3183b99..a0959f83dc 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -113,11 +113,13 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 {{% thirdparty-content %}} +* [Charmed Operator Framework](https://juju.is/) * [kubebuilder](https://book.kubebuilder.io/) 사용하기 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) * 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를 사용하여 직접 구현하기 * [오퍼레이터 프레임워크](https://operatorframework.io) +* [shell-operator](https://github.com/flant/shell-operator) ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 344c266d1e..5d2ef83d76 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -21,7 +21,7 @@ sitemap: 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. -쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. +쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. ## 여정 돌아보기 diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index 09f70af30c..c19ec0b3a9 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -32,14 +32,15 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다. -| Key | Description | Example | Type | +| 키 | 설명 | 예시 | 타입 | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 | | `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `mysql-abcxzy` | 문자열 | | `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 | | `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 | | `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 | -| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는데 사용되는 도구 | `helm` | 문자열 | +| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 | +| `app.kubernetes.io/created-by` | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 | 위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다. @@ -54,6 +55,7 @@ metadata: app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress app.kubernetes.io/managed-by: helm + app.kubernetes.io/created-by: controller-manager ``` ## 애플리케이션과 애플리케이션 인스턴스 @@ -76,7 +78,7 @@ WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비 `Deployment` 와 `Service` 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다. -`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는데 사용한다. +`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는 데 사용한다. ```yaml apiVersion: apps/v1 kind: Deployment @@ -102,9 +104,9 @@ metadata: Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. -다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다. +다음 식별자는 이 애플리케이션을 배포하는 데 사용하는 오브젝트의 시작을 보여준다. -WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다. +WordPress를 배포하는 데 다음과 같이 `Deployment` 로 시작한다. ```yaml apiVersion: apps/v1 @@ -152,7 +154,7 @@ metadata: ... ``` -`Service` 는 WordPress의 일부로 MySQL을 노출하는데 이용한다. +`Service` 는 WordPress의 일부로 MySQL을 노출하는 데 이용한다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index ef75f4f081..049b30a1f7 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -35,7 +35,7 @@ weight: 30 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. {{< note >}} - 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다. + `kube-` 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다. {{< /note >}} ### 네임스페이스 조회 diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index 5cd57c3a29..5ae3f5822e 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -1,7 +1,37 @@ --- -title: "스케줄링과 축출(eviction)" +title: "스케줄링, 선점(Preemption), 축출(Eviction)" weight: 90 +content_type: concept description: > - 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다. - 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다. + 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 + 파드를 노드에 할당하는 것을 말한다. + 선점은 우선순위가 높은 파드가 노드에 스케줄될 수 있도록 + 우선순위가 낮은 파드를 종료시키는 과정을 말한다. + 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다. +no_list: true --- + +쿠버네티스에서, 스케줄링은 {{}}이 파드를 실행할 수 있도록 +{{}}를 +{{}}에 할당하는 것을 말한다. +선점은 {{}}가 높은 파드가 노드에 스케줄될 수 있도록 +우선순위가 낮은 파드를 종료시키는 과정을 말한다. +축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다. + +## 스케줄링 + +* [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/) +* [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) +* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) +* [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/) +* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/) + +## 파드 중단(disruption) + +{{}} + +* [파드 우선순위와 선점](/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 86e67978c2..8c17269a64 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -80,7 +80,6 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 1. [스케줄링 정책](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다. 1. [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. - ## {{% heading "whatsnext" %}} * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md index 0f474338d9..b0da80ceae 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,7 +1,7 @@ --- title: 파드 오버헤드 content_type: concept -weight: 20 +weight: 30 --- diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md similarity index 100% rename from content/ko/docs/concepts/configuration/pod-priority-preemption.md rename to content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index d11b7fe2ae..34ff6f3108 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -5,7 +5,7 @@ title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) content_type: concept -weight: 30 +weight: 80 --- diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 9e049cd348..6be3e204c8 100644 --- 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 @@ title: 스케줄러 성능 튜닝 content_type: concept -weight: 80 +weight: 100 --- diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 3a85139cd2..c70b7413ad 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -540,11 +540,11 @@ spec: ### 접근 모드 -클레임은 특정 접근 모드로 저장소를 요청할 때 볼륨과 동일한 규칙을 사용한다. +클레임은 특정 접근 모드로 저장소를 요청할 때 [볼륨과 동일한 규칙](#접근-모드)을 사용한다. ### 볼륨 모드 -클레임은 볼륨과 동일한 규칙을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다. +클레임은 [볼륨과 동일한 규칙](#볼륨-모드)을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다. ### 리소스 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 94577ca182..0bec67ef8a 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -149,9 +149,9 @@ CSI | 1.14 (alpha), 1.16 (beta) ### 볼륨 바인딩 모드 `volumeBindingMode` 필드는 [볼륨 바인딩과 동적 -프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다. +프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다. 설정되어 있지 않으면, `Immediate` 모드가 기본으로 사용된다. -기본적으로, `Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨 +`Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨 바인딩과 동적 프로비저닝이 즉시 발생하는 것을 나타낸다. 토폴로지 제약이 있고 클러스터의 모든 노드에서 전역적으로 접근할 수 없는 스토리지 백엔드의 경우, 파드의 스케줄링 요구 사항에 대한 지식 없이 퍼시스턴트볼륨이 @@ -183,6 +183,36 @@ CSI | 1.14 (alpha), 1.16 (beta) 사전에 생성된 PV에서도 지원되지만, 지원되는 토폴로지 키와 예시를 보려면 해당 CSI 드라이버에 대한 문서를 본다. +{{< note >}} + `waitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다. + 만약 `nodeName`을 사용한다면, 스케줄러가 바이패스되고 PVC가 `pending` 상태로 있을 것이다. + + 대신, 아래와 같이 호스트네임을 이용하는 노드셀렉터를 사용할 수 있다. +{{< /note >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: task-pv-pod +spec: + nodeSelector: + kubernetes.io/hostname: kube-01 + volumes: + - name: task-pv-storage + persistentVolumeClaim: + claimName: task-pv-claim + containers: + - name: task-pv-container + image: nginx + ports: + - containerPort: 80 + name: "http-server" + volumeMounts: + - mountPath: "/usr/share/nginx/html" + name: task-pv-storage +``` + ### 허용된 토폴로지 클러스터 운영자가 `WaitForFirstConsumer` 볼륨 바인딩 모드를 지정하면, 대부분의 상황에서 diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index 56244fae26..02730d4306 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -79,13 +79,15 @@ weight: 60 ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에 애플리케이션을 분산해야 한다. -자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. +자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자동화된 자발적 중단은 발생하지 않는다(사용자가 지시한 자발적 중단만 발생한다). 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다. 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다. 또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. 클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. +파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션 +또한 자발적(+ 비자발적) 중단을 유발할 수 있다. ## 파드 disruption budgets diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index b7a1241fc2..c8c7055408 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -326,6 +326,5 @@ myapp-pod 1/1 Running 0 9m ## {{% heading "whatsnext" %}} - * [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성) * [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 9bb8cfba78..2601f5c871 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -13,7 +13,7 @@ obsolete --> 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. {{< note >}} -v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 +v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 [API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와 [스케줄러](/docs/reference/generated/kube-scheduler/)에서 `EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 6040ba514b..a658d58497 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -132,7 +132,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `IPv6DualStack` | `true` | 베타 | 1.21 | | | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | | | `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | -| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | | +| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | @@ -142,7 +142,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | | | `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | | | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | -| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | | +| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | | `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | 베타 | 1.19 | | | `PodDeletionCost` | `false` | 알파 | 1.21 | | @@ -164,7 +164,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | | | `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | | | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | -| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | | +| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | | `ServiceTopology` | `false` | 알파 | 1.17 | | | `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | | `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | | @@ -173,7 +173,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | | `SuspendJob` | `false` | 알파 | 1.21 | | -| `TTLAfterFinished` | `false` | 알파 | 1.12 | | +| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 | +| `TTLAfterFinished` | `true` | 베타 | 1.21 | | | `TopologyAwareHints` | `false` | 알파 | 1.21 | | | `TopologyManager` | `false` | 알파 | 1.16 | 1.17 | | `TopologyManager` | `true` | 베타 | 1.18 | | @@ -266,6 +267,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | | `EvenPodsSpread` | `true` | GA | 1.19 | - | | `ExecProbeTimeout` | `true` | GA | 1.20 | - | +| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | | `HugePages` | `false` | 알파 | 1.8 | 1.9 | @@ -286,11 +288,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | | `KubeletPodResources` | `true` | 베타 | 1.15 | | | `KubeletPodResources` | `true` | GA | 1.20 | | +| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | | `MountContainers` | `false` | 알파 | 1.9 | 1.16 | | `MountContainers` | `false` | 사용중단 | 1.17 | - | | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | - | +| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - | | `NodeLease` | `false` | 알파 | 1.12 | 1.13 | | `NodeLease` | `true` | 베타 | 1.14 | 1.16 | | `NodeLease` | `true` | GA | 1.17 | - | @@ -341,6 +345,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | +| `ServiceNodeExclusion` | `true` | GA | 1.21 | - | | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | | `StartupProbe` | `true` | 베타 | 1.18 | 1.19 | | `StartupProbe` | `true` | GA | 1.20 | - | @@ -636,6 +641,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. +- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 diff --git a/content/ko/docs/reference/glossary/pod-disruption.md b/content/ko/docs/reference/glossary/pod-disruption.md new file mode 100644 index 0000000000..93a473035c --- /dev/null +++ b/content/ko/docs/reference/glossary/pod-disruption.md @@ -0,0 +1,19 @@ +--- +id: pod-disruption +title: 파드 중단(Disruption) +full_link: /ko/docs/concepts/workloads/pods/disruptions/ +date: 2021-05-12 +short_description: > + 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차 + +aka: +related: + - pod + - container +tags: + - operation +--- + +[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다. + +자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다.