From 52738ce04b9ccf0aa9bc5a3ea316a2d8b39a49b9 Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Fri, 27 May 2022 11:17:30 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.24-ko.1 M34-M48 --- .../scheduling-eviction/pod-overhead.md | 107 +++++++++--------- .../pod-priority-preemption.md | 6 +- .../resource-bin-packing.md | 25 ++-- .../concepts/security/controlling-access.md | 17 ++- .../services-networking/dns-pod-service.md | 11 -- .../services-networking/dual-stack.md | 2 +- .../services-networking/endpoint-slices.md | 14 ++- .../ingress-controllers.md | 3 +- .../concepts/services-networking/ingress.md | 14 ++- .../services-networking/network-policies.md | 39 +------ .../concepts/services-networking/service.md | 103 ++++++++++++----- .../topology-aware-hints.md | 6 + .../concepts/storage/ephemeral-volumes.md | 32 +++--- .../concepts/storage/persistent-volumes.md | 91 ++++++++++++--- .../service/networking/networkpolicy.yaml | 35 ++++++ 15 files changed, 317 insertions(+), 188 deletions(-) create mode 100644 content/ko/examples/service/networking/networkpolicy.yaml diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md index b0da80ceae..0feb96eb9a 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,4 +1,8 @@ --- + + + + title: 파드 오버헤드 content_type: concept weight: 30 @@ -6,17 +10,12 @@ weight: 30 -{{< feature-state for_k8s_version="v1.18" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} - -노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. +노드 상에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. -_파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 -소비되는 리소스를 계산하는 기능이다. - - - - +쿠버네티스에서, _파드 오버헤드_ 는 리소스 요청 및 상한 외에도 +파드의 인프라에 의해 소비되는 리소스를 계산하는 방법 중 하나이다. @@ -25,33 +24,30 @@ _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파 [어드미션](/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 이 수행될 때 지정된다. -파드 오버헤드가 활성화 되면, 파드를 노드에 스케줄링 할 때 컨테이너 리소스 요청의 합에 -파드의 오버헤드를 추가해서 스케줄링을 고려한다. 마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나 -파드의 축출 등급을 부여할 때에도 파드의 오버헤드를 포함하여 고려한다. +파드를 노드에 스케줄링할 때, 컨테이너 리소스 요청의 합 뿐만 아니라 파드의 오버헤드도 함께 고려된다. +마찬가지로, kubelet은 파드의 cgroups 크기를 변경하거나 파드의 축출 등급을 부여할 때에도 +파드의 오버헤드를 포함하여 고려한다. -## 파드 오버헤드 활성화하기 {#set-up} +## 파드 오버헤드 환경 설정하기 {#set-up} -기능 활성화를 위해 클러스터에서 -`PodOverhead` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있고(1.18 버전에서는 기본적으로 활성화), `overhead` 필드를 정의하는 `RuntimeClass` 가 사용되고 있는지 확인해야 한다. ## 사용 예제 -파드 오버헤드 기능을 사용하기 위하여, `overhead` 필드를 정의하는 런타임클래스가 필요하다. +파드 오버헤드를 활용하려면, `overhead` 필드를 정의하는 런타임클래스가 필요하다. 예를 들어, 가상 머신 및 게스트 OS에 대하여 파드 당 120 MiB를 사용하는 가상화 컨테이너 런타임의 런타임클래스의 경우 다음과 같이 정의 할 수 있다. ```yaml ---- -kind: RuntimeClass apiVersion: node.k8s.io/v1 +kind: RuntimeClass metadata: - name: kata-fc + name: kata-fc handler: kata-fc overhead: - podFixed: - memory: "120Mi" - cpu: "250m" + podFixed: + memory: "120Mi" + cpu: "250m" ``` `kata-fc` 런타임클래스 핸들러를 지정하는 워크로드는 리소스 쿼터 계산, @@ -68,7 +64,7 @@ spec: runtimeClassName: kata-fc containers: - name: busybox-ctr - image: busybox + image: busybox:1.28 stdin: true tty: true resources: @@ -88,13 +84,15 @@ spec: 파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가 `overhead` 를 포함하도록 변경한다. -런타임클래스의 어드미션 수행 후에, 파드의 스펙이 갱신된 것을 확인할 수 있다. +런타임클래스 어드미션 컨트롤러가 변경을 완료하면, +다음의 명령어로 업데이트된 파드 오버헤드 값을 확인할 수 있다. ```bash kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` 명령 실행 결과는 다음과 같다. + ``` map[cpu:250m memory:120Mi] ``` @@ -106,23 +104,26 @@ kube-scheduler 는 어떤 노드에 파드가 기동 되어야 할지를 정할 해당 파드에 대한 컨테이너의 리소스 요청의 합을 고려한다. 이 예제에서, 스케줄러는 리소스 요청과 파드의 오버헤드를 더하고, 2.25 CPU와 320 MiB 메모리가 사용 가능한 노드를 찾는다. -일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. +일단 파드가 특정 노드에 스케줄링 되면, 해당 노드에 있는 kubelet 은 +파드에 대한 새로운 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}을 생성한다. 기본 컨테이너 런타임이 만들어내는 컨테이너들은 이 파드 안에 존재한다. -만약 각 컨테이너에 대하여 QoS가 보장되었거나 향상이 가능하도록 QoS 의 리소스 상한 제한이 걸려있으면, -kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 -cgroup 의 상한선을 설정한다. 이 상한선은 컨테이너 리소스 상한과 PodSpec에 -정의된 `overhead` 의 합에 기반한다. +만약 각 컨테이너에 대하여 리소스 상한 제한이 걸려있으면 +(제한이 걸려있는 보장된(Guaranteed) Qos 또는 향상 가능한(Burstable) QoS), +kubelet 은 해당 리소스(CPU의 경우 cpu.cfs_quota_us, 메모리의 경우 memory.limit_in_bytes)와 연관된 파드의 cgroup 의 상한선을 설정한다. +이 상한선은 컨테이너 리소스 상한과 PodSpec에 정의된 `overhead` 의 합에 기반한다. -CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 -리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다. +CPU의 경우, 만약 파드가 보장형 또는 버스트형 QoS로 설정되었으면, +kubelet은 PodSpec에 정의된 `overhead` 에 컨테이너의 리소스 요청의 합을 더한 값을 `cpu.shares` 로 설정한다. 다음의 예제를 참고하여, 워크로드에 대하여 컨테이너의 리소스 요청을 확인하자. + ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` 컨테이너 리소스 요청의 합은 각각 CPU 2000m 와 메모리 200MiB 이다. + ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` @@ -133,19 +134,21 @@ map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] kubectl describe node | grep test-pod -B2 ``` -CPU 2250m와 메모리 320MiB 가 리소스로 요청되었으며, 이 결과는 파드의 오버헤드를 포함한다. +결과를 보면 2250 m의 CPU와 320 MiB의 메모리가 리소스로 요청되었다. 여기에는 파드 오버헤드가 포함되어 있다. + ``` - Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE - --------- ---- ------------ ---------- --------------- ------------- --- - default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE + --------- ---- ------------ ---------- --------------- ------------- --- + default test-pod 2250m (56%) 2250m (56%) 320Mi (1%) 320Mi (1%) 36m ``` ## 파드 cgroup 상한 확인하기 -워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인 해보자. 다음의 예제에서, [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, -CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. -파드의 오버헤드 동작을 보여주는 좋은 예이며, -사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. +워크로드가 실행 중인 노드에서 파드의 메모리 cgroup들을 확인해 보자. +다음의 예제에서, +[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)은 노드에서 사용되며, +CRI-호환 컨테이너 런타임을 위해서 노드에서 사용할 수 있는 CLI 를 제공한다. +파드 오버헤드 동작을 보여주는 좋은 예이며, 사용자가 노드에서 직접 cgroup들을 확인하지 않아도 된다. 먼저 특정 노드에서 파드의 식별자를 확인해 보자. @@ -155,39 +158,41 @@ POD_ID="$(sudo crictl pods --name test-pod -q)" ``` 여기에서, 파드의 cgroup 경로를 확인할 수 있다. + ```bash # 파드가 스케줄 된 노드에서 이것을 실행 sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` 명령의 결과로 나온 cgroup 경로는 파드의 `pause` 컨테이너를 포함한다. 파드 레벨의 cgroup은 하나의 디렉터리이다. + ``` - "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" + "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` -아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. 메모리의 파드 레벨 cgroup 설정을 확인하자. +아래의 특정한 경우에, 파드 cgroup 경로는 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2` 이다. +메모리의 파드 레벨 cgroup 설정을 확인하자. + ```bash # 파드가 스케줄 된 노드에서 이것을 실행. # 또한 사용자의 파드에 할당된 cgroup 이름에 맞춰 해당 이름을 수정. cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` -예상대로 320 MiB 이다. +예상한 것과 같이 320 MiB 이다. + ``` 335544320 ``` ### 관찰성 -`kube_pod_overhead` 항목은 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) -에서 사용할 수 있어, 파드 오버헤드가 사용되는 시기를 식별하고, -정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. -이 기능은 kube-state-metrics 의 1.9 릴리스에서는 사용할 수 없지만, 다음 릴리스에서는 가능할 예정이다. -그 전까지는 소스로부터 kube-state-metric 을 빌드해야 한다. - +몇몇 `kube_pod_overhead` 메트릭은 +[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 에서 사용할 수 있어, +파드 오버헤드가 사용되는 시기를 식별하고, 정의된 오버헤드로 실행되는 워크로드의 안정성을 관찰할 수 있다. ## {{% heading "whatsnext" %}} - -* [런타임클래스](/ko/docs/concepts/containers/runtime-class/) -* [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) +* [런타임클래스](/ko/docs/concepts/containers/runtime-class/)에 대해 알아본다. +* 더 자세한 문맥은 + [파드오버헤드 디자인](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) 향상 제안을 확인한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index f10ee8524c..778b9b5614 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -104,7 +104,7 @@ description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사 ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} `preemptionPolicy: Never` 를 가진 파드는 낮은 우선순위 파드의 스케줄링 대기열의 앞쪽에 배치되지만, @@ -203,9 +203,11 @@ spec: 정보를 제공한다. 파드 P는 반드시 "지정된 노드"로 스케줄링되지는 않는다. +The scheduler always tries the "nominated Node" before iterating over any other nodes. +스케줄러는 다른 노드에 스케줄링을 시도하기 전에 항상 "지정된 노드"부터 시도한다. 피해자 파드가 축출된 후, 그것은 정상적(graceful)으로 종료되는 기간을 갖는다. 스케줄러가 종료될 피해자 파드를 기다리는 동안 다른 노드를 사용할 수 -있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용한다. 그 결과, +있게 되면, 스케줄러는 파드 P를 스케줄링하기 위해 다른 노드를 사용할 수 있다. 그 결과, 파드 스펙의 `nominatedNodeName` 과 `nodeName` 은 항상 동일하지 않다. 또한, 스케줄러가 노드 N에서 파드를 축출했지만, 파드 P보다 우선순위가 높은 파드가 도착하면, 스케줄러가 노드 N에 새로운 우선순위가 높은 파드를 제공할 수 있다. 이러한 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 c3dcf84727..8c5f19b8ff 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -21,25 +21,24 @@ kube-scheduler를 미세 조정할 수 있다. ## RequestedToCapacityRatioResourceAllocation을 사용해서 빈 패킹 활성화하기 -쿠버네티스를 사용하면 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 -용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. 이를 -통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 -대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. -`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 -동작은 `RequestedToCapacityRatioArgs`라는 -구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` -두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과 -`score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 -조정할 수 있게 한다. `resources` 파라미터는 점수를 매길 때 고려할 -리소스의 `name` 과 각 리소스의 가중치를 지정하는 `weight` 로 -구성된다. +쿠버네티스는 사용자가 각 리소스에 대한 가중치와 함께 리소스를 지정하여 +용량 대비 요청 비율을 기반으로 노드의 점수를 매기는 것을 허용한다. +이를 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 +대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. +`RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 동작은 +`RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다. +이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. +`shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로 +최소 요청 또는 최대 요청된 대로 기능을 조정할 수 있게 한다. +`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과 +각 리소스의 가중치를 지정하는 `weight` 로 구성된다. 다음은 확장된 리소스 `intel.com/foo` 와 `intel.com/bar` 에 대한 `requestedToCapacityRatioArguments` 를 빈 패킹 동작으로 설정하는 구성의 예시이다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: # ... diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index cf2fc529ce..ad30adf3c6 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -1,7 +1,9 @@ --- + + + title: 쿠버네티스 API 접근 제어하기 content_type: concept -weight: 5 --- @@ -29,13 +31,16 @@ API 서버의 인증서에 대한 루트 인증서를 포함하며, 이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다. 클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다. +클라이언트는 이 단계에서 TLS 클라이언트 인증서를 제시할 수 있다. + ## 인증 TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다. 이는 다이어그램에 **1**단계로 표시되어 있다. 클러스터 생성 스크립트 또는 클러스터 관리자는 API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다. -인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다. +인증기에 대해서는 +[인증](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다. 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만 일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다. @@ -46,8 +51,6 @@ JWT 토큰(서비스 어카운트에 사용됨)을 포함한다. 여러 개의 인증 모듈을 지정할 수 있으며, 이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다. -GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다. - 요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다. 이 외에는 사용자가 특정 `username`으로 인증되며, 이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다. @@ -126,6 +129,12 @@ Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`cre 요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후 오브젝트 저장소에 기록(**4**단계)된다. +## 감사(Auditing) + +쿠버네티스 감사는 클러스터에서 발생하는 일들의 순서를 문서로 기록하여, 보안과 관련되어 있고 시간 순서로 정리된 기록을 제공한다. +클러스터는 사용자, 쿠버네티스 API를 사용하는 애플리케이션, 그리고 컨트롤 플레인 자신이 생성한 활동을 감사한다. + +더 많은 정보는 [감사](/docs/tasks/debug/debug-cluster/audit/)를 참고한다. ## API 서버 포트와 IP diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 75c1d14ccf..9b4521e2b7 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -323,17 +323,6 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화 쿠버네티스는 최대 32개의 탐색 도메인과 최대 2048자의 탐색 도메인 목록을 허용한다. -### 기능 가용성 - -파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다. - -| 쿠버네티스 버전 | 기능 지원 | -| :---------: |:-----------:| -| 1.14 | 안정 | -| 1.10 | 베타 (기본값으로 켜져 있음)| -| 1.9 | 알파 | - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index c17dca7ff9..1e8c9c2a03 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -43,7 +43,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 쿠버네티스 버전, 쿠버네티스 해당 버전에 대한 문서 참조 * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) - * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인 + * 이중 스택 네트워킹을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) ## IPv4/IPv6 이중 스택 구성 diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 4ea1281faa..7a3c2f0e0e 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -1,4 +1,6 @@ --- + + title: 엔드포인트슬라이스 content_type: concept weight: 45 @@ -144,12 +146,12 @@ endpoints: v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별 `topology` 가 효과적으로 제거되었다. -`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 -설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신, -v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한 -필드는 API 버전 간에 자동으로 번역된다. 예를 들어, -v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` -키 값은 v1 API의 `zone` 필드로 접근할 수 있다. +`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 설정하는 것은 +더 이상 사용되지 않으며 v1 API에서 지원되지 않는다. +대신, v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. +이러한 필드는 API 버전 간에 자동으로 번역된다. +예를 들어, v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` 키 값은 +v1 API의 `zone` 필드로 접근할 수 있다. {{< /note >}} ### 관리 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 72c68d0563..67073efa4c 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -23,7 +23,7 @@ weight: 40 {{% thirdparty-content %}} -* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다. +* [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com/azure/application-gateway/overview)를 구성하는 인그레스 컨트롤러다. * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. @@ -48,6 +48,7 @@ weight: 40 구동하는 인그레스 컨트롤러다. * [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/) 웹서버(프록시로 사용)와 함께 작동한다. +* [Pomerium 인그레스 컨트롤러](https://www.pomerium.com/docs/k8s/ingress.html)는 [Pomerium](https://pomerium.com/) 기반 인그레스 컨트롤러이며, 상황 인지 접근 정책을 제공한다. * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다. * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는 [Traefik](https://traefik.io/traefik/) 프록시 용 인그레스 컨트롤러다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index dff0437b00..ba281bf659 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -74,7 +74,7 @@ graph LR; {{< codenew file="service/networking/minimal-ingress.yaml" >}} -다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. +인그레스에는 `apiVersion`, `kind`, `metadata` 및 `spec` 필드가 명시되어야 한다. 인그레스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다. @@ -118,8 +118,14 @@ graph LR; ### DefaultBackend {#default-backend} -규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. `defaultBackend` 는 일반적으로 -[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다. +규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송하며, +`.spec.defaultBackend`는 이와 같은 경우에 요청을 처리할 백엔드를 지정한다. +`defaultBackend` 는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, +인그레스 리소스에 지정되어 있지 않다. +`.spec.rules` 가 명시되어 있지 않으면, +`.spec.defaultBackend` 는 반드시 명시되어 있어야 한다. +`defaultBackend` 가 설정되어 있지 않으면, 어느 규칙에도 해당되지 않는 요청의 처리는 인그레스 컨트롤러의 구현을 따른다(이러한 +경우를 어떻게 처리하는지 알아보려면 해당 인그레스 컨트롤러 문서를 참고한다). 만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은 기본 백엔드로 라우팅 된다. @@ -309,7 +315,7 @@ spec: controller: example.com/ingress-controller parameters: # 이 인그레스클래스에 대한 파라미터는 - # "external-configuration" 환경 설정 네임스페이스에 있는 + # "external-configuration" 네임스페이스에 있는 # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다. scope: Namespace apiGroup: k8s.example.com diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index a7d47701ac..f72d1f0cff 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -45,42 +45,7 @@ pod- 또는 namespace- 기반의 네트워크폴리시를 정의할 때, {{< glo 네트워크폴리시 의 예시는 다음과 같다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: test-network-policy - namespace: default -spec: - podSelector: - matchLabels: - role: db - policyTypes: - - Ingress - - Egress - ingress: - - from: - - ipBlock: - cidr: 172.17.0.0/16 - except: - - 172.17.1.0/24 - - namespaceSelector: - matchLabels: - project: myproject - - podSelector: - matchLabels: - role: frontend - ports: - - protocol: TCP - port: 6379 - egress: - - to: - - ipBlock: - cidr: 10.0.0.0/24 - ports: - - protocol: TCP - port: 5978 -``` +{{< codenew file="service/networking/networkpolicy.yaml" >}} {{< note >}} 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다. @@ -281,7 +246,7 @@ API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 ## 이름으로 네임스페이스 지정 -{{< feature-state state="beta" for_k8s_version="1.21" >}} +{{< feature-state for_k8s_version="1.22" state="stable" >}} 쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 871323ea2a..858c5ab09a 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -24,7 +24,7 @@ weight: 10 ## 동기 -쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 상태와 +쿠버네티스 {{< glossary_tooltip term_id="pod" text="파드" >}}는 클러스터 목표 상태(desired state)와 일치하도록 생성되고 삭제된다. 파드는 비영구적 리소스이다. 만약 앱을 실행하기 위해 {{< glossary_tooltip term_id="deployment" text="디플로이먼트" >}}를 사용한다면, 동적으로 파드를 생성하고 제거할 수 있다. @@ -108,13 +108,46 @@ spec: 필드와 같은 값으로 설정된다. {{< /note >}} -파드의 포트 정의에는 이름이 있고, 서비스의 `targetPort` 속성에서 이 이름을 -참조할 수 있다. 이것은 다른 포트 번호를 통한 가용한 동일 네트워크 프로토콜이 있고, -단일 구성 이름을 사용하는 서비스 내에 -혼합된 파드가 존재해도 가능하다. -이를 통해 서비스를 배포하고 진전시키는데 많은 유연성을 제공한다. -예를 들어, 클라이언트를 망가뜨리지 않고, 백엔드 소프트웨어의 다음 -버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다. +파드의 포트 정의에 이름이 있으므로, +서비스의 `targetPort` 속성에서 이 이름을 참조할 수 있다. +예를 들어, 다음과 같은 방법으로 서비스의 `targetPort`를 파드 포트에 바인딩할 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + app.kubernetes.io/name: proxy +spec: + containers: + - name: nginx + image: nginx:11.14.2 + ports: + - containerPort: 80 + name: http-web-svc + +--- +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app.kubernetes.io/name: proxy + ports: + - name: name-of-service-port + protocol: TCP + port: 80 + targetPort: http-web-svc +``` + + +이것은 서로 다른 포트 번호를 통해 가용한 동일 네트워크 프로토콜이 있고, +단일 구성 이름을 사용하는 서비스 내에 혼합된 파드가 존재해도 가능하다. +이를 통해 서비스를 배포하고 진전시키는 데 많은 유연성을 제공한다. +예를 들어, 클라이언트를 망가뜨리지 않고, +백엔드 소프트웨어의 다음 버전에서 파드가 노출시키는 포트 번호를 변경할 수 있다. 서비스의 기본 프로토콜은 TCP이다. 다른 [지원되는 프로토콜](#protocol-support)을 사용할 수도 있다. @@ -125,9 +158,9 @@ spec: ### 셀렉터가 없는 서비스 -서비스는 일반적으로 쿠버네티스 파드에 대한 접근을 추상화하지만, -다른 종류의 백엔드를 추상화할 수도 있다. -예를 들면 +서비스는 일반적으로 셀렉터를 이용하여 쿠버네티스 파드에 대한 접근을 추상화하지만, +셀렉터 대신 매칭되는(corresponding) 엔드포인트와 함께 사용되면 다른 종류의 백엔드도 추상화할 수 있으며, +여기에는 클러스터 외부에서 실행되는 것도 포함된다. 예시는 다음과 같다. * 프로덕션 환경에서는 외부 데이터베이스 클러스터를 사용하려고 하지만, 테스트 환경에서는 자체 데이터베이스를 사용한다. @@ -668,44 +701,38 @@ status: #### 프로토콜 유형이 혼합된 로드밸런서 -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} 기본적으로 로드밸런서 서비스 유형의 경우 둘 이상의 포트가 정의되어 있을 때 모든 포트는 동일한 프로토콜을 가져야 하며 프로토콜은 클라우드 공급자가 지원하는 프로토콜이어야 한다. -kube-apiserver에 대해 기능 게이트 `MixedProtocolLBService`가 활성화된 경우 둘 이상의 포트가 정의되어 있을 때 다른 프로토콜을 사용할 수 있다. +`MixedProtocolLBService` 기능 게이트(v1.24에서 kube-apiserver에 대해 기본적으로 활성화되어 있음)는 +둘 이상의 포트가 정의되어 있는 경우에 로드밸런서 타입의 서비스에 대해 서로 다른 프로토콜을 사용할 수 있도록 해 준다. {{< note >}} 로드밸런서 서비스 유형에 사용할 수 있는 프로토콜 세트는 여전히 클라우드 제공 업체에서 정의한다. +클라우드 제공자가 혼합 프로토콜을 지원하지 않는다면 이는 단일 프로토콜만을 제공한다는 것을 의미한다. {{< /note >}} #### 로드밸런서 NodePort 할당 비활성화 -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} `type=LoadBalancer` 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며, 이는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정하면 된다. 노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다. 기본적으로 `spec.allocateLoadBalancerNodePorts`는 `true`이며 로드밸런서 서비스 유형은 계속해서 노드 포트를 할당할 것이다. -노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 -해당 노드 포트는 자동으로 할당 해제되지 **않는다**. +노드 포트가 할당된 기존 서비스에서 `spec.allocateLoadBalancerNodePorts`가 `false`로 설정된 경우 해당 노드 포트는 자동으로 할당 해제되지 **않는다**. 이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다. -이 필드를 사용하려면 클러스터에 `ServiceLBNodePortControl` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. -쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있으므로, -`spec.allocateLoadBalancerNodePorts` 필드를 사용할 수 있다. -다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다. #### 로드 밸런서 구현 클래스 지정 {#load-balancer-class} -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} `spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. -이 필드를 사용하기 위해서는 클러스터에 `ServiceLoadBalancerClass` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. -쿠버네티스 v{{< skew currentVersion >}}에서, 이 기능 게이트는 기본적으로 활성화되어 있다. 다른 버전의 쿠버네티스를 실행하는 클러스터에 대해서는, 해당 릴리스의 문서를 참조한다. 기본적으로, `spec.loadBalancerClass` 는 `nil` 이고, 클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면 `LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다. @@ -1211,7 +1238,7 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일 충분해야 한다. 그러나, 이해가 필요한 부분 뒤에는 많은 일이 있다. -### 충돌 방지 +### 충돌 방지 {#avoiding-collisions} 쿠버네티스의 주요 철학 중 하나는 잘못한 것이 없는 경우 실패할 수 있는 상황에 노출되어서는 @@ -1219,9 +1246,10 @@ VIP용 유저스페이스 프록시를 사용하면 중소 규모의 스케일 충돌할 경우에 대비해 자신의 포트 번호를 선택하지 않아도 된다. 그것은 격리 실패이다. -서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, 두 개의 -서비스가 충돌하지 않도록 해야 한다. 쿠버네티스는 각 서비스에 고유한 IP 주소를 -할당하여 이를 수행한다. +서비스에 대한 포트 번호를 선택할 수 있도록 하기 위해, +두 개의 서비스가 충돌하지 않도록 해야 한다. +쿠버네티스는 API 서버에 설정되어 있는 `service-cluster-ip-range` CIDR 범위에서 +각 서비스에 고유한 IP 주소를 할당하여 이를 달성한다. 각 서비스가 고유한 IP를 받도록 하기 위해, 내부 할당기는 각 서비스를 만들기 전에 {{< glossary_tooltip term_id="etcd" >}}에서 @@ -1235,6 +1263,25 @@ IP 주소를 할당할 수 없다는 메시지와 함께 생성에 실패한다. 할당 (예: 관리자 개입으로)을 체크하고 더 이상 서비스에서 사용하지 않는 할당된 IP 주소를 정리한다. +#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range} + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} +그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데, +그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address). +이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면 +충돌이 발생할 수 있다. + +`ServiceIPStaticSubrange` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면, +할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진 +`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며, +여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다. +동적 IP 할당은 상위 대역에서 우선적으로 선택하며, +이를 통해 하위 대역에서 할당된 IP와의 충돌 위험을 줄인다. +이렇게 함으로써 사용자가 서비스의 고정 IP를 +`service-cluster-ip-range`의 하위 대역에서 할당하면서도 +충돌 위험을 줄일 수 있다. + ### 서비스 IP 주소 {#ips-and-vips} 실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리, diff --git a/content/ko/docs/concepts/services-networking/topology-aware-hints.md b/content/ko/docs/concepts/services-networking/topology-aware-hints.md index 7f086a5eee..bf0f1fb8c2 100644 --- a/content/ko/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ko/docs/concepts/services-networking/topology-aware-hints.md @@ -19,6 +19,12 @@ _토폴로지 인지 힌트(Topology Aware Hints)_ 는 클라이언트가 엔드 예를 들어, 비용을 줄이거나 네트워크 성능을 높이기 위해, 인접성을 고려하여 트래픽을 라우트할 수 있다. +{{< note >}} +"토폴로지 인지 힌트" 기능은 베타 단계이며 기본적으로 활성화되어 있지 **않다**. +이 기능을 사용해 보려면, +`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +{{< /note >}} + ## 동기(motivation) diff --git a/content/ko/docs/concepts/storage/ephemeral-volumes.md b/content/ko/docs/concepts/storage/ephemeral-volumes.md index ea3a05d74b..8a9f11b674 100644 --- a/content/ko/docs/concepts/storage/ephemeral-volumes.md +++ b/content/ko/docs/concepts/storage/ephemeral-volumes.md @@ -107,7 +107,7 @@ metadata: spec: containers: - name: my-frontend - image: busybox + image: busybox:1.28 volumeMounts: - mountPath: "/data" name: my-csi-inline-vol @@ -125,8 +125,19 @@ spec: 더 자세한 사항은 각 CSI 드라이버 문서를 참고한다. -클러스터 관리자는, [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)를 사용하여 파드 내에서 어떤 CSI 드라이버가 사용될 수 있는지를 제어할 수 있으며, -[`allowedCSIDrivers` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)에 기재하면 된다. +### CSI 드라이버 제한 사항 + +CSI 임시 볼륨은 사용자로 하여금 `volumeAttributes`를 +파드 스펙의 일부로서 CSI 드라이버에 직접 제공할 수 있도록 한다. +보통은 관리자만 사용할 수 있는 `volumeAttributes`를 허용하는 CSI 드라이버는 +내장(inline) 임시 볼륨 내에서 사용하는 것이 적합하지 않다. +예를 들어, 일반적으로 스토리지클래스 내에 정의되어 있는 파라미터들은 +내장 임시 볼륨 사용을 통해 사용자에게 노출되어서는 안 된다. + +클러스터 관리자가 이처럼 파드 스펙 내장 임시 볼륨 사용이 가능한 CSI 드라이버를 제한하려면 +다음을 수행할 수 있다. +- CSIDriver 스펙의 `volumeLifecycleModes`에서 `Ephemeral`을 제거하여, 해당 드라이버가 내장 임시 볼륨으로 사용되는 것을 막는다. +- [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 드라이버를 활용하는 방법을 제한한다. ### 일반 임시 볼륨 {#generic-ephemeral-volumes} @@ -158,7 +169,7 @@ metadata: spec: containers: - name: my-frontend - image: busybox + image: busybox:1.28 volumeMounts: - mountPath: "/scratch" name: scratch-volume @@ -239,16 +250,9 @@ PVC 이름 규칙에 따라 서로 다른 파드 간 이름 충돌이 발생할 GenericEphemeralVolume 기능을 활성화하면 사용자가 파드를 생성할 수 있는 경우 PVC를 간접적으로 생성할 수 있도록 허용하며, -심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. -클러스터 관리자는 이를 명심해야 한다. -이것이 보안 모델에 부합하지 않는다면, 다음의 두 가지 선택지가 있다. -- `volumes`의 목록 중에 `ephemeral` 볼륨 타입이 없는 경우, - [파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/)를 - 사용한다(쿠버네티스 - 1.21에서 사용 중단됨). -- 일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부하는 - [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 - 사용한다. +심지어 사용자가 PVC를 직접적으로 만들 수 있는 권한이 없는 경우에도 이를 허용한다. 클러스터 관리자는 이를 명심해야 한다. +이것이 보안 모델에 부합하지 않는다면, [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/)을 사용하여 +일반 임시 볼륨을 갖는 파드와 같은 오브젝트를 거부해야 한다. 일반적인 [PVC의 네임스페이스 쿼터](/ko/docs/concepts/policy/resource-quotas/#스토리지-리소스-쿼터)는 여전히 적용되므로, 사용자가 이 새로운 메카니즘을 사용할 수 있도록 허용되었어도, diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 8796d2fd50..857d25e8ae 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -175,6 +175,74 @@ spec: 그러나 `volumes` 부분의 사용자 정의 재활용 파드 템플릿에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 바뀐다. +### 퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer) {#persistentvolume-deletion-protection-finalizer} +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +퍼시스턴트볼륨에 파이널라이저를 추가하여, `Delete` 반환 정책을 갖는 퍼시스턴트볼륨이 +기반 스토리지(backing storage)가 삭제된 이후에만 삭제되도록 할 수 있다. + +새롭게 도입된 `kubernetes.io/pv-controller` 및 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 +동적으로 프로비전된 볼륨에만 추가된다. + +`kubernetes.io/pv-controller` 파이널라이저는 인-트리 플러그인 볼륨에 추가된다. 다음은 이에 대한 예시이다. + +```shell +kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Name: pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Labels: +Annotations: kubernetes.io/createdby: vsphere-volume-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: yes + pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume +Finalizers: [kubernetes.io/pv-protection kubernetes.io/pv-controller] +StorageClass: vcp-sc +Status: Bound +Claim: default/vcp-pvc-1 +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 1Gi +Node Affinity: +Message: +Source: + Type: vSphereVolume (a Persistent Disk resource in vSphere) + VolumePath: [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk + FSType: ext4 + StoragePolicyName: vSAN Default Storage Policy +Events: +``` + +`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 CSI 볼륨에 추가된다. +다음은 이에 대한 예시이다. +```shell +Name: pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d +Labels: +Annotations: pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com +Finalizers: [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer] +StorageClass: fast +Status: Bound +Claim: demo-app/nginx-logs +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 200Mi +Node Affinity: +Message: +Source: + Type: CSI (a Container Storage Interface (CSI) volume source) + Driver: csi.vsphere.vmware.com + FSType: ext4 + VolumeHandle: 44830fa8-79b4-406b-8b58-621ba25353fd + ReadOnly: false + VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com + type=vSphere CNS Block Volume +Events: +``` + +특정 인-트리 볼륨 플러그인에 대해 `CSIMigration` 기능을 활성화하면 `kubernetes.io/pv-controller` 파이널라이저는 제거되고, +`external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저가 추가된다. +이와 비슷하게, `CSIMigration` 기능을 비활성화하면 `external-provisioner.volume.kubernetes.io/finalizer` 파이널라이저는 제거되고, +`kubernetes.io/pv-controller` 파이널라이저가 추가된다. + ### 퍼시스턴트볼륨 예약 컨트롤 플레인은 클러스터에서 [퍼시스턴트볼륨클레임을 일치하는 퍼시스턴트볼륨에 바인딩](#바인딩)할 @@ -284,18 +352,13 @@ FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. #### 사용 중인 퍼시스턴트볼륨클레임 크기 조정 -{{< feature-state for_k8s_version="v1.15" state="beta" >}} - -{{< note >}} -사용 중인 PVC 확장은 쿠버네티스 1.15 이후 버전에서는 베타로, 1.11 이후 버전에서는 알파로 제공된다. `ExpandInUsePersistentVolumes` 기능을 사용하도록 설정해야 한다. 베타 기능의 경우 여러 클러스터에서 자동으로 적용된다. 자세한 내용은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참고한다. -{{< /note >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} 이 경우 기존 PVC를 사용하는 파드 또는 디플로이먼트를 삭제하고 다시 만들 필요가 없다. 파일시스템이 확장되자마자 사용 중인 PVC가 파드에서 자동으로 사용 가능하다. 이 기능은 파드나 디플로이먼트에서 사용하지 않는 PVC에는 영향을 미치지 않는다. 확장을 완료하기 전에 PVC를 사용하는 파드를 만들어야 한다. - 다른 볼륨 유형과 비슷하게 FlexVolume 볼륨도 파드에서 사용 중인 경우 확장할 수 있다. {{< note >}} @@ -329,7 +392,7 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다. {{< /note >}} -클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure` +클러스터에 `RecoverVolumeExpansionFailure` 기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면 이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다. 더 작은 크기를 지정하여 확장 시도를 요청하려면, @@ -849,17 +912,12 @@ spec: ## 볼륨 파퓰레이터(Volume populator)와 데이터 소스 -{{< feature-state for_k8s_version="v1.22" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} -{{< note >}} 쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다. -이 알파 기능은 쿠버네티스 1.18에서 도입되었으며 -1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다. -현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번 -확인한다. {{% version-check %}} -커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해 -`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. -{{< /note >}} +커스텀 볼륨 파퓰레이터를 사용하려면, +kube-apiserver와 kube-controller-manager에 대해 `AnyVolumeDataSource` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. 볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다. 다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는 @@ -877,6 +935,7 @@ spec: `dataSourceRef` 필드와 `dataSource` 필드 사이에는 사용자가 알고 있어야 할 두 가지 차이점이 있다. + * `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만, `dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다. 유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다. diff --git a/content/ko/examples/service/networking/networkpolicy.yaml b/content/ko/examples/service/networking/networkpolicy.yaml new file mode 100644 index 0000000000..e91eed2f67 --- /dev/null +++ b/content/ko/examples/service/networking/networkpolicy.yaml @@ -0,0 +1,35 @@ +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: test-network-policy + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Ingress + - Egress + ingress: + - from: + - ipBlock: + cidr: 172.17.0.0/16 + except: + - 172.17.1.0/24 + - namespaceSelector: + matchLabels: + project: myproject + - podSelector: + matchLabels: + role: frontend + ports: + - protocol: TCP + port: 6379 + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 5978 +