diff --git a/content/ko/_index.html b/content/ko/_index.html index 7f475ee51e..0925f2ef7e 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -30,7 +30,7 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 {{% blocks/feature image="suitcase" %}} #### K8s를 어디서나 실행 -쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. +쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는 데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. {{% /blocks/feature %}} diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 9666cd4a14..30ede236bc 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -19,6 +19,7 @@ cid: community
+기여자 커뮤니티      커뮤니티 가치      행동 강령       비디오      diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index e5e7d315c5..eccfe091ce 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -44,10 +44,10 @@ weight: 40 ### 노드 컨트롤러 노드 컨트롤러는 클라우드 인프라스트럭처에 새 서버가 생성될 때 {{< glossary_tooltip text="노드" term_id="node" >}} -오브젝트를 생성하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 +오브젝트를 업데이트하는 역할을 한다. 노드 컨트롤러는 클라우드 공급자의 사용자 테넌시 내에서 실행되는 호스트에 대한 정보를 가져온다. 노드 컨트롤러는 다음 기능들을 수행한다. -1. 컨트롤러가 클라우드 공급자 API를 통해 찾아내는 각 서버에 대해 노드 오브젝트를 초기화한다. +1. 클라우드 공급자 API를 통해 획득한 해당 서버의 고유 ID를 노드 오브젝트에 업데이트한다. 2. 클라우드 관련 정보(예를 들어, 노드가 배포되는 지역과 사용 가능한 리소스(CPU, 메모리 등))를 사용해서 노드 오브젝트에 어노테이션과 레이블을 작성한다. 3. 노드의 호스트 이름과 네트워크 주소를 가져온다. diff --git a/content/ko/docs/concepts/architecture/cri.md b/content/ko/docs/concepts/architecture/cri.md new file mode 100644 index 0000000000..69175432d1 --- /dev/null +++ b/content/ko/docs/concepts/architecture/cri.md @@ -0,0 +1,50 @@ +--- +title: 컨테이너 런타임 인터페이스(CRI) +content_type: concept +weight: 50 +--- + + + +컨테이너 런타임 인터페이스(CRI)는 클러스터 컴포넌트를 다시 컴파일하지 않아도 Kubelet이 다양한 +컨테이너 런타임을 사용할 수 있도록 하는 플러그인 인터페이스다. + +클러스터의 모든 노드에 동작 중인 +{{}}이 존재해야, +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}이 +{{< glossary_tooltip text="파드" term_id="pod" >}}들과 컨테이너들을 +구동할 수 있다. + +{{< glossary_definition term_id="container-runtime-interface" length="all" >}} + + + +## API {#api} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Kubelet은 gRPC를 통해 컨테이너 런타임과 연결할 때 클라이언트의 역할을 수행한다. +런타임과 이미지 서비스 엔드포인트는 컨테이너 런타임 내에서 사용 가능해야 하며, +이는 각각 Kubelet 내에서 `--image-service-endpoint`와 `--container-runtime-endpoint` +[커맨드라인 플래그](/docs/reference/command-line-tools-reference/kubelet) +를 통해 설정할 수 있다. + +쿠버네티스 v{{< skew currentVersion >}}에서는, Kubelet은 CRI `v1`을 사용하는 것을 권장한다. +컨테이너 런타임이 CRI `v1` 버전을 지원하지 않는다면, +Kubelet은 지원 가능한 이전 지원 버전으로 협상을 시도한다. +또한 v{{< skew currentVersion >}} Kubelet은 CRI `v1alpha2`버전도 협상할 수 있지만, +해당 버전은 사용 중단(deprecated)으로 간주한다. +Kubelet이 지원되는 CRI 버전을 협상할 수 없는 경우, +Kubelet은 협상을 포기하고 노드로 등록하지 않는다. + +## 업그레이드 + +쿠버네티스를 업그레이드할 때, Kubelet은 컴포넌트의 재시작 시점에서 최신 CRI 버전을 자동으로 선택하려고 시도한다. +이 과정이 실패하면 위에서 언급한 대로 이전 버전을 선택하는 과정을 거친다. +컨테이너 런타임이 업그레이드되어 gRPC 재다이얼이 필요하다면, +컨테이너 런타임도 처음에 선택된 버전을 지원해야 하며, +그렇지 못한 경우 재다이얼은 실패하게 될 것이다. 이 과정은 Kubelet의 재시작이 필요하다. + +## {{% heading "whatsnext" %}} + +- CRI [프로토콜 정의](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)를 자세히 알아보자. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index c71462d9b3..86a9856b47 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -385,7 +385,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. -## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown} +## 그레이스풀(Graceful) 노드 셧다운(shutdown) {#graceful-node-shutdown} {{< feature-state state="beta" for_k8s_version="v1.21" >}} @@ -402,7 +402,7 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 제어된다. 기본적으로, 아래 설명된 두 구성 옵션, -`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, +`shutdownGracePeriod` 및 `shutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, 그레이스풀 노드 셧다운 기능이 활성화되지 않는다. 기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다. @@ -412,32 +412,116 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다. 그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다. -* `ShutdownGracePeriod`: +* `shutdownGracePeriod`: * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다. -* `ShutdownGracePeriodCriticalPods`: - * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다. +* `shutdownGracePeriodCriticalPods`: + * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `shutdownGracePeriod` 보다 작아야 한다. -예를 들어, `ShutdownGracePeriod=30s`, -`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 +예를 들어, `shutdownGracePeriod=30s`, +`shutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의 유예 종료에 할당되고, 마지막 10초는 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다. {{< note >}} -그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다. -`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다. +그레이스풀 노드 셧다운 과정에서 축출된 파드는 셧다운(shutdown)된 것으로 표시된다. +`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Terminated`으로 표시된다. 그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다. ``` -Status: Failed -Reason: Shutdown -Message: Node is shutting, evicting pods +Reason: Terminated +Message: Pod was terminated in response to imminent node shutdown. ``` -실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다. -이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다. {{< /note >}} +### 파드 우선순위 기반 그레이스풀 노드 셧다운 {#pod-priority-graceful-node-shutdown} + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +그레이스풀 노드 셧다운 시 파드 셧다운 순서에 더 많은 유연성을 제공할 수 있도록, +클러스터에 프라이어리티클래스(PriorityClass) 기능이 활성화되어 있으면 +그레이스풀 노드 셧다운 과정에서 파드의 프라이어리티클래스가 고려된다. +이 기능으로 그레이스풀 노드 셧다운 시 파드가 종료되는 순서를 클러스터 관리자가 +[프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스) +기반으로 명시적으로 정할 수 있다. + +위에서 기술된 것처럼, [그레이스풀 노드 셧다운](#graceful-node-shutdown) 기능은 파드를 +중요하지 않은(non-critical) 파드와 +중요한(critical) 파드 2단계(phase)로 구분하여 종료시킨다. +셧다운 시 파드가 종료되는 순서를 명시적으로 더 상세하게 정해야 한다면, +파드 우선순위 기반 그레이스풀 노드 셧다운을 사용할 수 있다. + +그레이스풀 노드 셧다운 과정에서 파드 우선순위가 고려되기 때문에, +그레이스풀 노드 셧다운이 여러 단계로 일어날 수 있으며, +각 단계에서 특정 프라이어리티 클래스의 파드를 종료시킨다. +정확한 단계와 단계별 셧다운 시간은 kubelet에 설정할 수 있다. + +다음과 같이 클러스터에 커스텀 파드 +[프라이어리티 클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#프라이어리티클래스)가 있다고 +가정하자. + +|파드 프라이어리티 클래스 이름|파드 프라이어리티 클래스 값| +|-------------------------|------------------------| +|`custom-class-a` | 100000 | +|`custom-class-b` | 10000 | +|`custom-class-c` | 1000 | +|`regular/unset` | 0 | + +[kubelet 환경 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 안의 +`shutdownGracePeriodByPodPriority` 설정은 다음과 같을 수 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |10 seconds | +| 10000 |180 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + +이를 나타내는 kubelet 환경 설정 YAML은 다음과 같다. + +```yaml +shutdownGracePeriodByPodPriority: + - priority: 100000 + shutdownGracePeriodSeconds: 10 + - priority: 10000 + shutdownGracePeriodSeconds: 180 + - priority: 1000 + shutdownGracePeriodSeconds: 120 + - priority: 0 + shutdownGracePeriodSeconds: 60 +``` + +위의 표에 의하면 우선순위 값이 100000 이상인 파드는 종료까지 10초만 주어지며, +10000 이상 ~ 100000 미만이면 180초, +1000 이상 ~ 10000 미만이면 120초가 주어진다. +마지막으로, 다른 모든 파드는 종료까지 60초가 주어질 것이다. + +모든 클래스에 대해 값을 명시할 필요는 없다. +예를 들어, 대신 다음과 같은 구성을 사용할 수도 있다. + +|파드 프라이어리티 클래스 값|종료 대기 시간| +|------------------------|---------------| +| 100000 |300 seconds | +| 1000 |120 seconds | +| 0 |60 seconds | + + +위의 경우, custom-class-b에 속하는 파드와 custom-class-c에 속하는 파드는 +동일한 종료 대기 시간을 갖게 될 것이다. + +특정 범위에 해당되는 파드가 없으면, +kubelet은 해당 범위에 해당되는 파드를 위해 기다려 주지 않는다. +대신, kubelet은 즉시 다음 프라이어리티 클래스 값 범위로 넘어간다. + +기능이 활성화되어 있지만 환경 설정이 되어 있지 않으면, +순서 지정 동작이 수행되지 않을 것이다. + +이 기능을 사용하려면 `GracefulNodeShutdownBasedOnPodPriority` 기능 게이트를 활성화해야 하고, +kubelet 환경 설정의 `ShutdownGracePeriodByPodPriority`를 +파드 프라이어리티 클래스 값과 +각 값에 대한 종료 대기 시간을 명시하여 지정해야 한다. + ## 스왑(swap) 메모리 관리 {#swap-memory} {{< feature-state state="alpha" for_k8s_version="v1.22" >}} @@ -451,6 +535,11 @@ kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 [구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가 false로 지정되어야 한다. +{{< warning >}} +메모리 스왑 기능이 활성화되면, 시크릿 오브젝트의 내용과 같은 +tmpfs에 기록되었던 쿠버네티스 데이터가 디스크에 스왑될 수 있다. +{{< /warning >}} + 사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, 이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면, diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index c2613d86e6..75ccfabb2d 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -45,6 +45,11 @@ content_type: concept ## 인프라스트럭처 * [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)는 쿠버네티스에서 가상 머신을 실행하기 위한 애드온이다. 일반적으로 베어 메탈 클러스터에서 실행한다. +* [node problem detector](https://github.com/kubernetes/node-problem-detector)는 + 리눅스 노드에서 실행되며, + 시스템 이슈를 + [이벤트](/docs/reference/kubernetes-api/cluster-resources/event-v1/) 또는 + [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition) 형태로 보고한다. ## 레거시 애드온 diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 511afa9659..d916a09105 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -64,7 +64,7 @@ weight: 50 VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다. -이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. +이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다. 비슷하게, 사용자가 선택한 네트워킹 옵션이 [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/)을 지원할 수도 있으며, 구현 방법은 다양할 수 있다. `Pod` 로 전달하는 `Node` 자체의 포트(호스트 포트라고 함)를 요청할 수 있지만, 이는 매우 틈새 작업이다. 전달이 구현되는 방법은 @@ -169,49 +169,6 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네 충족하는 매우 간단한 오버레이 네트워크이다. 많은 경우에 쿠버네티스와 플라넬은 성공적으로 적용이 가능하다. -### Google 컴퓨트 엔진(GCE) - -Google 컴퓨트 엔진 클러스터 구성 스크립트의 경우, [고급 -라우팅](https://cloud.google.com/vpc/docs/routes)을 사용하여 -각 VM에 서브넷을 할당한다(기본값은 `/24` - 254개 IP). 해당 서브넷에 바인딩된 -모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이는 -아웃 바운드 인터넷 접근을 위해 NAT로 구성된 VM에 할당된 "기본" -IP 주소에 추가된다. 리눅스 브릿지(`cbr0`)는 해당 서브넷에 존재하도록 -구성되며, 도커의 `--bridge` 플래그로 전달된다. - -도커는 다음의 설정으로 시작한다. - -```shell -DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false" -``` - -이 브릿지는 노드의 `.spec.podCIDR`에 따라 Kubelet(`--network-plugin=kubenet` -플래그로 제어되는)에 의해 생성된다. - -도커는 이제 `cbr-cidr` 블록에서 IP를 할당한다. 컨테이너는 `cbr0` 브릿지를 -통해 서로 `Node` 에 도달할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크 -내에서 라우팅할 수 있다. - -그러나, GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로, 아웃 바운드 인터넷 트래픽을 위해 -IP를 NAT하지 않는다. 그것을 달성하기 위해 iptables 규칙을 사용하여 -GCE 프로젝트 네트워크(10.0.0.0/8) 외부의 IP에 바인딩된 트래픽을 -마스커레이드(일명 SNAT - 마치 패킷이 `Node` 자체에서 온 것처럼 -보이게 함)한다. - -```shell -iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE -``` - -마지막으로 커널에서 IP 포워딩이 활성화되어 있으므로, 커널은 브릿지된 컨테이너에 -대한 패킷을 처리한다. - -```shell -sysctl net.ipv4.ip_forward=1 -``` - -이 모든 것의 결과는 모든 `Pod` 가 서로에게 도달할 수 있고 인터넷으로 트래픽을 -송신할 수 있다는 것이다. - ### 재규어(Jaguar) [재규어](https://gitlab.com/sdnlab/jaguar)는 OpenDaylight 기반의 쿠버네티스 네트워크를 위한 오픈소스 솔루션이다. 재규어는 vxlan을 사용하여 오버레이 네트워크를 제공하고 재규어 CNI 플러그인은 파드별로 하나의 IP 주소를 제공한다. @@ -260,12 +217,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https:// [NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다. -### OpenVSwitch - -[OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만 -오버레이 네트워크를 구축하는 복잡한 방법이다. 이것은 네트워킹 분야의 몇몇 -"대형 벤더"에 의해 승인되었다. - ### OVN(오픈 버추얼 네트워킹) OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 @@ -274,10 +225,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 특정 쿠버네티스 플러그인 및 문서가 있다. -### 로마나 - -[로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. - ### Weaveworks의 위브넷 [위브넷](https://www.weave.works/products/weave-net/)은 diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index fa7ec69fc9..78e7ecfba6 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -74,8 +74,7 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 수량이다. 이것은 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및 [서비스](/ko/docs/concepts/services-networking/service/)와 같은 API 리소스는 -쿠버네티스 API 서버를 통해 읽고 수정할 수 -있는 오브젝트이다. +쿠버네티스 API 서버를 통해 읽고 수정할 수 있는 오브젝트이다. ## 파드와 컨테이너의 리소스 요청 및 제한 @@ -100,9 +99,10 @@ CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다. 쿠버네티스의 CPU 1개는 클라우드 공급자용 **vCPU/Core 1개** 와 베어메탈 인텔 프로세서에서의 **1개 하이퍼스레드** 에 해당한다. -분수의 요청이 허용된다. -`0.5` 의 `spec.containers[].resources.requests.cpu` 요청을 가진 -컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 +요청량을 소수점 형태로 명시할 수도 있다. 컨테이너의 +`spec.containers[].resources.requests.cpu`를 `0.5`로 설정한다는 것은, +`1.0` CPU를 요청했을 때와 비교하여 절반의 CPU 타임을 요청한다는 의미이다. +CPU 자원의 단위와 관련하여, `0.1` 이라는 표현은 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. `0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, @@ -115,12 +115,12 @@ CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. ### 메모리의 의미 `memory` 에 대한 제한 및 요청은 바이트 단위로 측정된다. -E, P, T, G, M, K와 같은 접미사 중 하나를 사용하여 메모리를 +E, P, T, G, M, k, m(millis) 와 같은 접미사 중 하나를 사용하여 메모리를 일반 정수 또는 고정 소수점 숫자로 표현할 수 있다. Ei, Pi, Ti, Gi, Mi, Ki와 같은 2의 거듭제곱을 사용할 수도 있다. 예를 들어, 다음은 대략 동일한 값을 나타낸다. ```shell -128974848, 129e6, 129M, 123Mi +128974848, 129e6, 129M, 128974848000m, 123Mi ``` 다음은 예제이다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 64b6bc3395..8b33e3322e 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -55,7 +55,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. - 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다. + 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 서비스를 사용하는 것을 고려할 수 있다. - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 73d48cd18b..d27faddc20 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -244,7 +244,7 @@ kubectl create secret docker-registry secret-tiger-docker \ `kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기 위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가 -다음의 두 키를 포함해야 한다. +다음의 두 키 중 하나를 포함해야 한다. - `username`: 인증을 위한 사용자 이름 - `password`: 인증을 위한 암호나 토큰 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 5ab09dd64a..d0c1d4bf7a 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -54,13 +54,15 @@ weight: 10 컨테이너에 대한 `imagePullPolicy`와 이미지의 태그는 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)이 특정 이미지를 풀(다운로드)하려고 할 때 영향을 준다. -다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 효과이다. +다음은 `imagePullPolicy`에 설정할 수 있는 값의 목록과 +효과이다. `IfNotPresent` : 이미지가 로컬에 없는 경우에만 내려받는다. `Always` -: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 이미지 레지스트리에 이름과 이미지의 +: kubelet이 컨테이너를 기동할 때마다, kubelet이 컨테이너 + 이미지 레지스트리에 이름과 이미지의 [다이제스트](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)가 있는지 질의한다. 일치하는 다이제스트를 가진 컨테이너 이미지가 로컬에 있는 경우, kubelet은 캐시된 이미지를 사용한다. 이외의 경우, kubelet은 검색된 다이제스트를 가진 이미지를 내려받아서 @@ -78,7 +80,8 @@ weight: 10 {{< note >}} 프로덕션 환경에서 컨테이너를 배포하는 경우 `:latest` 태그 사용을 지양해야 하는데, -이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 제대로 롤백하기 어렵게 되기 때문이다. +이미지의 어떤 버전이 기동되고 있는지 추적이 어렵고 +제대로 롤백하기 어렵게 되기 때문이다. 대신, `v1.42.0`과 같이 의미있는 태그를 명기한다. {{< /note >}} @@ -90,7 +93,8 @@ weight: 10 이미지 태그를 사용하는 경우, 이미지 레지스트리에서 한 이미지를 나타내는 태그에 코드를 변경하게 되면, 기존 코드와 신규 코드를 구동하는 파드가 섞이게 되고 만다. 이미지 다이제스트를 통해 이미지의 특정 버전을 유일하게 식별할 수 있기 때문에, 쿠버네티스는 매번 해당 이미지 이름과 다이제스트가 명시된 컨테이너를 기동해서 같은 코드를 구동한다. 이미지를 명시하는 것은 구동할 코드를 고정시켜서 레지스트리에서의 변경으로 인해 버전이 섞이는 일이 발생하지 않도록 해준다. -파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 +파드(및 파드 템플릿)가 생성될 때 구동 중인 워크로드가 +태그가 아닌 이미지 다이제스트를 통해 정의되도록 조작해주는 서드-파티 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)가 있다. 이는 레지스트리에서 태그가 변경되는 일이 발생해도 구동 중인 워크로드가 모두 같은 코드를 사용하고 있다는 것을 보장하기를 원하는 경우 유용할 것이다. @@ -104,7 +108,9 @@ weight: 10 `:latest`인 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. - `imagePullPolicy` 필드를 생략하고 컨테이너 이미지의 태그를 명기하지 않은 경우, `imagePullPolicy`는 자동으로 `Always`로 설정된다. -- `imagePullPolicy` 필드를 생략하고, 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. +- `imagePullPolicy` 필드를 생략하고, + 명기한 컨테이너 이미지의 태그가 `:latest`가 아니면, + `imagePullPolicy`는 자동으로 `IfNotPresent`로 설정된다. {{< note >}} 컨테이너의 `imagePullPolicy` 값은 오브젝트가 처음 _created_ 일 때 항상 @@ -127,6 +133,7 @@ weight: 10 그러면 사용자가 파드를 요청할 때 쿠버네티스가 정책을 `Always`로 설정한다. - [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) 어드미션 컨트롤러를 활성화 한다. + ### 이미지풀백오프(ImagePullBackOff) kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, @@ -258,6 +265,73 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' 프라이빗 레지스트리 키가 `.docker/config.json`에 추가되고 나면 모든 파드는 프라이빗 레지스트리의 이미지에 읽기 접근 권한을 가지게 될 것이다. +### config.json 파일 해석 {#config-json} + +`config.json` 파일의 해석에 있어서, 기존 도커의 구현과 쿠버네티스의 구현에 차이가 있다. +도커에서는 `auths` 키에 특정 루트 URL만 기재할 수 있으나, +쿠버네티스에서는 glob URL과 접두사-매칭 경로도 기재할 수 있다. +이는 곧 다음과 같은 `config.json`도 유효하다는 뜻이다. + +```json +{ + "auths": { + "*my-registry.io/images": { + "auth": "…" + } + } +} +``` + +루트 URL(`*my-registry.io`)은 다음 문법을 사용하여 매치된다. + +``` +pattern: + { term } + +term: + '*' 구분자가 아닌 모든 문자와 매치됨 + '?' 구분자가 아닌 문자 1개와 매치됨 + '[' [ '^' ] { character-range } ']' + 문자 클래스 (비어 있으면 안 됨)) + c 문자 c에 매치됨 (c != '*', '?', '\\', '[') + '\\' c 문자 c에 매치됨 + +character-range: + c 문자 c에 매치됨 (c != '\\', '-', ']') + '\\' c 문자 c에 매치됨 + lo '-' hi lo <= c <= hi 인 문자 c에 매치됨 +``` + +이미지 풀 작업 시, 모든 유효한 패턴에 대해 크리덴셜을 CRI 컨테이너 런타임에 제공할 것이다. +예를 들어 다음과 같은 컨테이너 이미지 이름은 +성공적으로 매치될 것이다. + +- `my-registry.io/images` +- `my-registry.io/images/my-image` +- `my-registry.io/images/another-image` +- `sub.my-registry.io/images/my-image` +- `a.sub.my-registry.io/images/my-image` + +kubelet은 인식된 모든 크리덴셜을 순차적으로 이용하여 이미지 풀을 수행한다. 즉, +`config.json`에 다음과 같이 여러 항목을 기재할 수도 있다. + +```json +{ + "auths": { + "my-registry.io/images": { + "auth": "…" + }, + "my-registry.io/images/subpath": { + "auth": "…" + } + } +} +``` + +이제 컨테이너가 `my-registry.io/images/subpath/my-image` +이미지를 풀 해야 한다고 명시하면, +kubelet은 크리덴셜을 순차적으로 사용하여 풀을 시도한다. + ### 미리 내려받은 이미지 {#pre-pulled-images} {{< note >}} @@ -383,3 +457,4 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config. * [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기. * [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기. +* [프라이빗 레지스트리에서 이미지 받아오기](/ko/docs/tasks/configure-pod-container/pull-image-private-registry) diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index 79466e8df3..f6be1ea390 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -77,7 +77,7 @@ no_list: true 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. 바이너리 플러그인은 kubelet(예: -[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과 +[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 kubectl에서 사용한다. @@ -145,7 +145,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### 인가 -[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. +[인가](/docs/reference/access-authn-authz/authorization/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. ### 동적 어드미션 컨트롤 @@ -163,6 +163,8 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. +FlexVolume은 쿠버네티스 v1.23부터 사용 중단(deprecated)되었다. Out-of-tree CSI 드라이버가 쿠버네티스에서 볼륨 드라이버를 작성할 때 추천하는 방식이다. 자세한 정보는 [스토리지 업체를 위한 쿠버네티스 볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors)에서 찾을 수 있다. + ### 장치 플러그인 diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index e6e0203eb9..d5179790aa 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -37,7 +37,8 @@ _선언적(declarative) API_ 를 제공하게 된다. 쿠버네티스 [선언적 API](/ko/docs/concepts/overview/kubernetes-api/)는 책임의 분리를 강제한다. 사용자는 리소스의 의도한 상태를 선언한다. -쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 선언한 의도한 상태에 동기화 되도록 한다. +쿠버네티스 컨트롤러는 쿠버네티스 오브젝트의 현재 상태가 +선언한 의도한 상태에 동기화 되도록 한다. 이는 서버에 무엇을 해야할지 *지시하는* 명령적인 API와는 대조된다. 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고 @@ -146,9 +147,9 @@ CRD 오브젝트의 이름은 유효한 일반적으로 쿠버네티스 API의 각 리소스에는 REST 요청을 처리하고 오브젝트의 퍼시스턴트 스토리지를 관리하는 코드가 필요하다. 주요 쿠버네티스 API 서버는 *파드* 및 *서비스* 와 같은 빌트인 리소스를 처리하고, 일반적으로 [CRD](#커스텀리소스데피니션)를 통해 커스텀 리소스를 처리할 수 ​​있다. -[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 독립형 API 서버를 +[애그리게이션 레이어](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용하면 자체 API 서버를 작성하고 배포하여 커스텀 리소스에 대한 특수한 구현을 제공할 수 있다. -기본 API 서버는 처리하는 커스텀 리소스에 대한 요청을 사용자에게 위임하여 +주(main) API 서버는 사용자의 커스텀 리소스에 대한 요청을 사용자의 자체 API 서버에 위임하여 모든 클라이언트가 사용할 수 있게 한다. ## 커스텀 리소스를 추가할 방법 선택 diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 9d4ad5525c..1d9b23b3aa 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -197,6 +197,8 @@ service PodResourcesLister { } ``` +### `List` gRPC 엔드포인트 {#grpc-endpoint-list} + `List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며, 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID, 이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다. @@ -246,10 +248,35 @@ message ContainerDevices { TopologyInfo topology = 3; } ``` +{{< note >}} +`List` 엔드포인트의 `ContainerResources` 내부에 있는 cpu_ids은 특정 컨테이너에 할당된 +독점 CPU들에 해당한다. 만약 공유 풀(shared pool)에 있는 CPU들을 확인(evaluate)하는 것이 목적이라면, 해당 `List` +엔드포인트는 다음에 설명된 것과 같이, `GetAllocatableResources` 엔드포인트와 함께 사용되어야 +한다. +1. `GetAllocatableResources`를 호출하여 할당 가능한 모든 CPU 목록을 조회 +2. 시스템의 모든 `ContainerResources`에서 `GetCpuIds`를 호출 +3. `GetAllocateableResources` 호출에서 `GetCpuIds` 호출로 얻은 모든 CPU를 빼기 +{{< /note >}} + +### `GetAllocatableResources` gRPC 엔드포인트 {#grpc-endpoint-getallocatableresources} + +{{< feature-state state="beta" for_k8s_version="v1.23" >}} GetAllocatableResources는 워커 노드에서 처음 사용할 수 있는 리소스에 대한 정보를 제공한다. kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다. +{{< note >}} +`GetAllocatableResources`는 [할당 가능(allocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 리소스를 확인(evaluate)하기 위해서만 +사용해야 한다. 만약 목적이 free/unallocated 리소스를 확인하기 위한 것이라면 +List() 엔드포인트와 함께 사용되어야 한다. `GetAllocableResources`로 얻은 결과는 kubelet에 +노출된 기본 리소스가 변경되지 않는 한 동일하게 유지된다. 이러한 변경은 드물지만, 발생하게 된다면 +(예를 들면: hotplug/hotunplug, 장치 상태 변경) 클라이언트가 `GetAlloctableResources` 엔드포인트를 +호출할 것으로 가정한다. +그러나 CPU 및/또는 메모리가 갱신된 경우 `GetAllocateableResources` 엔드포인트를 호출하는 것만으로는 +충분하지 않으며, Kubelet을 다시 시작하여 올바른 리소스 용량과 할당 가능(allocatable) 리소스를 반영해야 한다. +{{< /note >}} + + ```gRPC // AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다. message AllocatableResourcesResponse { @@ -259,6 +286,13 @@ message AllocatableResourcesResponse { } ``` +쿠버네티스 v1.23부터, `GetAllocatableResources`가 기본으로 활성화된다. +이를 비활성화하려면 `KubeletPodResourcesGetAllocatable` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 +끄면 된다. + +쿠버네티스 v1.23 이전 버전에서 이 기능을 활성화하려면 `kubelet`이 다음 플래그를 가지고 시작되어야 한다. + +`--feature-gates=KubeletPodResourcesGetAllocatable=true` `ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다. NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은 diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index d3ac7a4212..36b217db9c 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -31,9 +31,7 @@ weight: 30 및 실행을 자동화할 수 있고, *또한* 쿠버네티스가 수행하는 방식을 자동화할 수 있다. -쿠버네티스의 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} -개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 클러스터의 동작을 -확장할 수 있다. +쿠버네티스의 {{< glossary_tooltip text="오퍼레이터 패턴" term_id="operator-pattern" >}} 개념을 통해 쿠버네티스 코드 자체를 수정하지 않고도 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 하나 이상의 사용자 정의 리소스(custom resource)에 연결하여 클러스터의 동작을 확장할 수 있다. 오퍼레이터는 [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)의 컨트롤러 역할을 하는 쿠버네티스 API의 클라이언트이다. diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md index 8d1cb3ee05..fa3d50aeb6 100644 --- a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md @@ -227,7 +227,7 @@ spec: ## {{% heading "whatsnext" %}} -* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다. +* 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/ko/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다. * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 * [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 * [svc-cat.io](https://svc-cat.io/docs/) 살펴보기 diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 919d59b459..cc043139c4 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -1,4 +1,6 @@ --- + + title: 쿠버네티스 API content_type: concept weight: 30 @@ -35,36 +37,39 @@ card: 완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. -다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다. +### OpenAPI V2 + +쿠버네티스 API 서버는 `/openapi/v2` 엔드포인트를 통해 +통합된(aggregated) OpenAPI v2 스펙을 제공한다. +요청 헤더에 다음과 같이 기재하여 응답 형식을 지정할 수 있다. - + - - - + + + - + - + - + - +
Valid request header values for OpenAPI v2 queries OpenAPI v2 질의에 사용할 수 있는 유효한 요청 헤더 값
HeaderPossible valuesNotes헤더사용할 수 있는 값참고
Accept-Encoding gzipnot supplying this header is also acceptable이 헤더를 제공하지 않는 것도 가능
Accept application/com.github.proto-openapi.spec.v2@v1.0+protobufmainly for intra-cluster use주로 클러스터 내부 용도로 사용
application/jsondefault기본값
*serves application/jsonJSON으로 응답
@@ -75,6 +80,55 @@ Protobuf에 기반한 직렬화 형식을 구현한다. 이 형식에 대한 API 오브젝트를 정의하는 Go 패키지에 들어있는 각각의 스키마에 대한 IDL(인터페이스 정의 언어) 파일을 참고한다. +### OpenAPI V3 + +{{< feature-state state="alpha" for_k8s_version="v1.23" >}} + +쿠버네티스 v1.23은 OpenAPI v3 API 발행(publishing)에 대한 초기 지원을 제공한다. +이는 알파 기능이며 기본적으로 비활성화되어 있다. +kube-apiserver 구성 요소에 +`OpenAPIV3` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 +이 알파 기능을 활성화할 수 있다. + +이 기능이 활성화되면, 쿠버네티스 API 서버는 +통합된(aggregated) OpenAPI v3 스펙을 쿠버네티스 그룹 버전별로 +`/openapi/v3/apis//` 엔드포인트에 제공한다. +사용할 수 있는 요청 헤더는 아래의 표를 참고한다. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OpenAPI v3 질의에 사용할 수 있는 유효한 요청 헤더 값
헤더사용할 수 있는 값참고
Accept-Encodinggzip이 헤더를 제공하지 않는 것도 가능
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobuf주로 클러스터 내부 용도로 사용
application/json기본값
*JSON으로 응답
+ +`/openapi/v3` 디스커버리 엔드포인트는 사용 가능한 모든 +그룹/버전의 목록을 제공한다. 이 엔드포인트는 JSON 만을 반환한다. + ## 지속성 쿠버네티스는 오브젝트의 직렬화된 상태를 diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 1c4424a047..0ab5b4b76f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 -* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기 +* [kube-scheduler 구성(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 레퍼런스 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 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 e2fb1cdcf9..5fd12dc521 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 마치 100을 설정한 것처럼 작동한다. 값을 변경하려면, -[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을 +[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta3/)을 편집한 다음 스케줄러를 재시작한다. 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다. @@ -161,4 +161,4 @@ percentageOfNodesToScore: 50 ## {{% heading "whatsnext" %}} -* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인 +* [kube-scheduler 구성 레퍼런스(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) 확인 diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index f6d8c13a19..f6321e4aa7 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -203,7 +203,7 @@ tolerations: * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된 시간 동안 바인딩된 상태로 유지된다. -노드 컨트롤러는 특정 조건이 참일 때 자동으로 +노드 컨트롤러는 특정 컨디션이 참일 때 자동으로 노드를 테인트시킨다. 다음은 빌트인 테인트이다. * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition @@ -264,19 +264,19 @@ tolerations: 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다. -## 조건(condition)을 기준으로 노드 테인트하기 +## 컨디션(condition)을 기준으로 노드 테인트하기 컨트롤 플레인은 노드 {{}}를 이용하여 -[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. +[노드 컨디션](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. -스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. -이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다. -예를 들어 `DiskPressure` 노드 조건이 활성화된 경우 +스케줄러는 스케줄링 결정을 내릴 때 노드 컨디션을 확인하는 것이 아니라 테인트를 확인한다. +이렇게 하면 노드 컨디션이 스케줄링에 직접적인 영향을 주지 않는다. +예를 들어 `DiskPressure` 노드 컨디션이 활성화된 경우 컨트롤 플레인은 `node.kubernetes.io/disk-pressure` 테인트를 추가하고 영향을 받는 노드에 새 파드를 할당하지 않는다. -`MemoryPressure` 노드 조건이 활성화되면 +`MemoryPressure` 노드 컨디션이 활성화되면 컨트롤 플레인이 `node.kubernetes.io/memory-pressure` 테인트를 추가한다. -새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 조건을 무시하도록 할 수 있다. +새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 컨디션을 무시하도록 할 수 있다. 또한 컨트롤 플레인은 `BestEffort` 이외의 {{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}를 가지는 파드에 `node.kubernetes.io/memory-pressure` 톨러레이션을 추가한다. diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index bb7a9154c3..b7e5b26056 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -1,4 +1,8 @@ --- + + + + title: 서비스와 애플리케이션 연결하기 content_type: concept weight: 30 @@ -50,7 +54,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP 클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다. -만약 궁금하다면 [우리가 이것을 달성하는 방법](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)을 자세히 읽어본다. +만약 궁금하다면 [쿠버네티스 네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델)을 자세히 읽어본다. ## 서비스 생성하기 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 3544d7e745..c23556172b 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -39,7 +39,7 @@ DNS 쿼리는 그것을 생성하는 파드의 네임스페이스에 따라 다 DNS 쿼리는 파드의 `/etc/resolv.conf` 를 사용하여 확장될 수 있을 것이다. Kubelet은 각 파드에 대해서 파일을 설정한다. 예를 들어, `data` 만을 위한 쿼리는 -`data.test.cluster.local` 로 확장된다. `search` 옵션의 값은 +`data.test.svc.cluster.local` 로 확장된다. `search` 옵션의 값은 쿼리를 확장하기 위해서 사용된다. DNS 쿼리에 대해 더 자세히 알고 싶은 경우, [`resolv.conf` 설명 페이지.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)를 참고한다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 821ca34989..c77bba06c8 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -1,4 +1,9 @@ --- + + + + + title: IPv4/IPv6 이중 스택 feature: title: IPv4/IPv6 이중 스택 @@ -11,7 +16,7 @@ weight: 70 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. @@ -42,8 +47,6 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 ## IPv4/IPv6 이중 스택 구성 -IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.) - IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다. * kube-apiserver: @@ -60,9 +63,6 @@ IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도 IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.) -1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다. -필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에 -`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다. {{< /note >}} ## 서비스 @@ -76,7 +76,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `PreferDualStack`: - * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.) + * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다. * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. @@ -119,7 +119,7 @@ IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서 #### 기존 서비스의 이중 스택 기본값 -이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.) +이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (기존 클러스터를 1.21 이상으로 업그레이드하면 이중 스택이 활성화된다.) 1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index c66a9b6e84..a8b2cf1d5f 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -28,6 +28,7 @@ weight: 40 컨트롤러다. * [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다. * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다. +* [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe)는 [BFE](https://www.bfe-networks.net) 기반 인그레스 컨트롤러다. * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는 Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다. * [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index bafb216014..cccd947bb9 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -51,7 +51,7 @@ graph LR; 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 -[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는 +[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 또는 [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. ## 전제 조건들 @@ -219,20 +219,98 @@ Events: {{< codenew file="service/networking/external-lb.yaml" >}} -IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한 -추가 구현 별 구성을 참조하는데 사용할 수 있다. +인그레스클래스의 `.spec.parameters` 필드를 사용하여 +해당 인그레스클래스와 연관있는 환경 설정을 제공하는 다른 리소스를 참조할 수 있다. -#### 네임스페이스 범위의 파라미터 +사용 가능한 파라미터의 상세한 타입은 +인그레스클래스의 `.spec.parameters` 필드에 명시한 인그레스 컨트롤러의 종류에 따라 다르다. -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +### 인그레스클래스 범위 -`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데 -사용할 수 있는 `scope` 및 `namespace` 필드가 있다. -`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의 -리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를 -설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다. +인그레스 컨트롤러의 종류에 따라, 클러스터 범위로 설정한 파라미터의 사용이 가능할 수도 있고, +또는 한 네임스페이스에서만 사용 가능할 수도 있다. -{{< codenew file="service/networking/namespaced-params.yaml" >}} +{{< tabs name="tabs_ingressclass_parameter_scope" >}} +{{% tab name="클러스터" %}} +인그레스클래스 파라미터의 기본 범위는 클러스터 범위이다. + +`.spec.parameters` 필드만 설정하고 `.spec.parameters.scope` 필드는 지정하지 않거나, +`.spec.parameters.scope` 필드를 `Cluster`로 지정하면, +인그레스클래스는 클러스터 범위의 리소스를 참조한다. +파라미터의 `kind`(+`apiGroup`)는 +클러스터 범위의 API (커스텀 리소스일 수도 있음) 를 참조하며, +파라미터의 `name`은 +해당 API에 대한 특정 클러스터 범위 리소스를 가리킨다. + +예시는 다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-1 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 "external-config-1" 라는 + # ClusterIngressParameter(API 그룹 k8s.example.net)에 기재되어 있다. + # 이 정의는 쿠버네티스가 + # 클러스터 범위의 파라미터 리소스를 검색하도록 한다. + scope: Cluster + apiGroup: k8s.example.net + kind: ClusterIngressParameter + name: external-config-1 +``` +{{% /tab %}} +{{% tab name="네임스페이스" %}} +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +`.spec.parameters` 필드를 설정하고 +`.spec.parameters.scope` 필드를 `Namespace`로 지정하면, +인그레스클래스는 네임스페이스 범위의 리소스를 참조한다. +사용하고자 하는 파라미터가 속한 네임스페이스를 +`.spec.parameters` 의 `namespace` 필드에 설정해야 한다. + +파라미터의 `kind`(+`apiGroup`)는 +네임스페이스 범위의 API (예: 컨피그맵) 를 참조하며, +파라미터의 `name`은 +`namespace`에 명시한 네임스페이스의 특정 리소스를 가리킨다. + +네임스페이스 범위의 파라미터를 이용하여, +클러스터 운영자가 워크로드에 사용되는 환경 설정(예: 로드 밸런서 설정, API 게이트웨이 정의)에 대한 제어를 위임할 수 있다. +클러스터 범위의 파라미터를 사용했다면 다음 중 하나에 해당된다. + +- 다른 팀의 새로운 환경 설정 변경을 적용하려고 할 때마다 + 클러스터 운영 팀이 매번 승인을 해야 한다. 또는, +- 애플리케이션 팀이 클러스터 범위 파라미터 리소스를 변경할 수 있게 하는 + [RBAC](/docs/reference/access-authn-authz/rbac/) 롤, 바인딩 등의 특별 접근 제어를 + 클러스터 운영자가 정의해야 한다. + +인그레스클래스 API 자신은 항상 클러스터 범위이다. + +네임스페이스 범위의 파라미터를 참조하는 인그레스클래스 예시가 +다음과 같다. +```yaml +--- +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb-2 +spec: + controller: example.com/ingress-controller + parameters: + # 이 인그레스클래스에 대한 파라미터는 + # "external-configuration" 환경 설정 네임스페이스에 있는 + # "external-config" 라는 IngressParameter(API 그룹 k8s.example.com)에 기재되어 있다. + scope: Namespace + apiGroup: k8s.example.com + kind: IngressParameter + namespace: external-configuration + name: external-config +``` + +{{% /tab %}} +{{< /tabs >}} ### 사용중단(Deprecated) 어노테이션 @@ -559,12 +637,12 @@ Events: 사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다. * [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용. -* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용. +* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#type-nodeport) 사용. ## {{% heading "whatsnext" %}} -* [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 +* [인그레스](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md index f658cd6cfa..8088d05366 100644 --- a/content/ko/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되 ## {{% heading "whatsnext" %}} -* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기 +* [토폴로지 인식 힌트](/docs/concepts/services-networking/topology-aware-hints/)에 대해서 읽기 * [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 798c0b4e97..db1c510ed0 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -550,7 +550,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 * `ClusterIP`: 서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면 클러스터 내에서만 서비스에 도달할 수 있다. 이것은 `ServiceTypes`의 기본 값이다. -* [`NodePort`](#nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를 +* [`NodePort`](#type-nodeport): 고정 포트 (`NodePort`)로 각 노드의 IP에 서비스를 노출시킨다. `NodePort` 서비스가 라우팅되는 `ClusterIP` 서비스가 자동으로 생성된다. `:`를 요청하여, 클러스터 외부에서 @@ -568,7 +568,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다. -### NodePort 유형 {#nodeport} +### NodePort 유형 {#type-nodeport} `type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은 `--service-node-port-range` 플래그로 지정된 범위에서 포트를 할당한다 (기본값 : 30000-32767). diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 4bc8926e3b..e8d9e083e4 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -10,14 +10,13 @@ feature: title: 스토리지 오케스트레이션 description: > 로컬 스토리지, GCP나 AWS와 같은 퍼블릭 클라우드 공급자 또는 NFS, iSCSI, Gluster, Ceph, Cinder나 Flocker와 같은 네트워크 스토리지 시스템에서 원하는 스토리지 시스템을 자동으로 마운트한다. - content_type: concept weight: 20 --- -이 페이지는 쿠버네티스의 _퍼시스턴트 볼륨_ 의 현재 상태를 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. +이 페이지에서는 쿠버네티스의 _퍼시스턴트 볼륨_ 에 대해 설명한다. [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 익숙해지는 것을 추천한다. @@ -221,19 +220,19 @@ spec: {{< feature-state for_k8s_version="v1.11" state="beta" >}} -이제 퍼시스턴트볼륨클레임(PVC) 확장 지원이 기본적으로 활성화되어 있다. 다음 유형의 +퍼시스턴트볼륨클레임(PVC) 확장 지원은 기본적으로 활성화되어 있다. 다음 유형의 볼륨을 확장할 수 있다. -* gcePersistentDisk +* azureDisk +* azureFile * awsElasticBlockStore -* Cinder +* cinder (deprecated) +* {{< glossary_tooltip text="csi" term_id="csi" >}} +* flexVolume (deprecated) +* gcePersistentDisk * glusterfs * rbd -* Azure File -* Azure Disk -* Portworx -* FlexVolumes -* {{< glossary_tooltip text="CSI" term_id="csi" >}} +* portworxVolume 스토리지 클래스의 `allowVolumeExpansion` 필드가 true로 설정된 경우에만 PVC를 확장할 수 있다. @@ -270,7 +269,7 @@ CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 볼륨 확 경우에만 파일시스템의 크기가 조정된다. 파일시스템 확장은 파드가 시작되거나 파드가 실행 중이고 기본 파일시스템이 온라인 확장을 지원할 때 수행된다. -FlexVolumes는 `RequiresFSResize` 기능으로 드라이버가 `true`로 설정된 경우 크기 조정을 허용한다. +FlexVolumes(쿠버네티스 v1.23부터 사용 중단됨)는 드라이버의 `RequiresFSResize` 기능이 `true`로 설정된 경우 크기 조정을 허용한다. FlexVolume은 파드 재시작 시 크기를 조정할 수 있다. #### 사용 중인 퍼시스턴트볼륨클레임 크기 조정 @@ -299,6 +298,11 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 #### 볼륨 확장 시 오류 복구 +사용자가 기반 스토리지 시스템이 제공할 수 있는 것보다 더 큰 사이즈를 지정하면, 사용자 또는 클러스터 관리자가 조치를 취하기 전까지 PVC 확장을 계속 시도한다. 이는 바람직하지 않으며 따라서 쿠버네티스는 이러한 오류 상황에서 벗어나기 위해 다음과 같은 방법을 제공한다. + +{{< tabs name="recovery_methods" >}} +{{% tab name="클러스터 관리자 접근 권한을 이용하여 수동으로" %}} + 기본 스토리지 확장에 실패하면, 클러스터 관리자가 수동으로 퍼시스턴트 볼륨 클레임(PVC) 상태를 복구하고 크기 조정 요청을 취소할 수 있다. 그렇지 않으면, 컨트롤러가 관리자 개입 없이 크기 조정 요청을 계속해서 재시도한다. 1. 퍼시스턴트볼륨클레임(PVC)에 바인딩된 퍼시스턴트볼륨(PV)을 `Retain` 반환 정책으로 표시한다. @@ -307,6 +311,30 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 4. PV 보다 작은 크기로 PVC를 다시 만들고 PVC의 `volumeName` 필드를 PV 이름으로 설정한다. 이것은 새 PVC를 기존 PV에 바인딩해야 한다. 5. PV의 반환 정책을 복원하는 것을 잊지 않는다. +{{% /tab %}} +{{% tab name="더 작은 크기로의 확장을 요청하여" %}} +{{% feature-state for_k8s_version="v1.23" state="alpha" %}} + +{{< note >}} +PVC 확장 실패의 사용자에 의한 복구는 쿠버네티스 1.23부터 제공되는 알파 기능이다. 이 기능이 작동하려면 `RecoverVolumeExpansionFailure` 기능이 활성화되어 있어야 한다. 더 많은 정보는 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 문서를 참조한다. +{{< /note >}} + +클러스터에 `ExpandPersistentVolumes`와 `RecoverVolumeExpansionFailure` +기능 게이트가 활성화되어 있는 상태에서 PVC 확장이 실패하면 +이전에 요청했던 값보다 작은 크기로의 확장을 재시도할 수 있다. +더 작은 크기를 지정하여 확장 시도를 요청하려면, +이전에 요청했던 값보다 작은 크기로 PVC의 `.spec.resources` 값을 수정한다. +이는 총 용량 제한(capacity constraint)으로 인해 큰 값으로의 확장이 실패한 경우에 유용하다. +만약 확장이 실패했다면, 또는 실패한 것 같다면, 기반 스토리지 공급자의 용량 제한보다 작은 값으로 확장을 재시도할 수 있다. +`.status.resizeStatus`와 PVC의 이벤트를 감시하여 리사이즈 작업의 상태를 모니터할 수 있다. + +참고: +이전에 요청했던 값보다 작은 크기를 요청했더라도, +새로운 값이 여전히 `.status.capacity`보다 클 수 있다. +쿠버네티스는 PVC를 현재 크기보다 더 작게 축소하는 것은 지원하지 않는다. +{{% /tab %}} +{{% /tabs %}} + ## 퍼시스턴트 볼륨의 유형 @@ -318,7 +346,6 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨 * [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI) * [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지 -* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume * [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk * [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨 * [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨 @@ -336,6 +363,8 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마 * [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지) (v1.18에서 **사용 중단**) +* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexvolume) - FlexVolume + (v1.23에서 **사용 중단**) * [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지 (v1.22에서 **사용 중단**) * [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨 @@ -417,9 +446,12 @@ spec: `ReadWriteOnce` : 하나의 노드에서 해당 볼륨이 읽기-쓰기로 마운트 될 수 있다. ReadWriteOnce 접근 모드에서도 파트가 동일 노드에서 구동되는 경우에는 복수의 파드에서 볼륨에 접근할 수 있다. -`ReadWriteMany` +`ReadOnlyMany` : 볼륨이 다수의 노드에서 읽기 전용으로 마운트 될 수 있다. +`ReadWriteMany` +: 볼륨이 다수의 노드에서 읽기-쓰기로 마운트 될 수 있다. + `ReadWriteOncePod` : 볼륨이 단일 파드에서 읽기-쓰기로 마운트될 수 있다. 전체 클러스터에서 단 하나의 파드만 해당 PVC를 읽거나 쓸 수 있어야하는 경우 ReadWriteOncePod 접근 모드를 사용한다. 이 기능은 CSI 볼륨과 쿠버네티스 버전 1.22+ 에서만 지원된다. diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md index 4aeb1ba8c1..86c95ae13a 100644 --- a/content/ko/docs/concepts/storage/storage-capacity.md +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -7,7 +7,7 @@ title: 스토리지 용량 content_type: concept -weight: 45 +weight: 70 --- @@ -16,7 +16,6 @@ weight: 45 예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며, 또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다. -{{< feature-state for_k8s_version="v1.19" state="alpha" >}} {{< feature-state for_k8s_version="v1.21" state="beta" >}} 이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index c915b65fad..c47f053a31 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -470,14 +470,14 @@ parameters: vSphere 스토리지 클래스에는 두 가지 유형의 프로비저닝 도구가 있다. -- [CSI 프로비저닝 도구](#csi-프로비저닝-도구): `csi.vsphere.vmware.com` +- [CSI 프로비저닝 도구](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` - [vCP 프로비저닝 도구](#vcp-프로비저닝-도구): `kubernetes.io/vsphere-volume` 인-트리 프로비저닝 도구는 [사용 중단](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)되었다. CSI 프로비저닝 도구에 대한 자세한 내용은 [쿠버네티스 vSphere CSI 드라이버](https://vsphere-csi-driver.sigs.k8s.io/) 및 [vSphereVolume CSI 마이그레이션](/ko/docs/concepts/storage/volumes/#csi-마이그레이션)을 참고한다. #### CSI 프로비저닝 도구 {#vsphere-provisioner-csi} -vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml)를 참조한다. +vSphere CSI 스토리지클래스 프로비저닝 도구는 Tanzu 쿠버네티스 클러스터에서 작동한다. 예시는 [vSphere CSI 리포지터리](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml)를 참조한다. #### vCP 프로비저닝 도구 diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index e9857885d7..365f780230 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -1,7 +1,12 @@ --- + + + + + title: CSI 볼륨 복제하기 content_type: concept -weight: 30 +weight: 60 --- diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 862c900fee..594d100772 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -8,7 +8,7 @@ title: 볼륨 스냅샷 클래스 content_type: concept -weight: 30 +weight: 41 # just after volume snapshots --- diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index b01a8affa4..d54ed5c45c 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -1,7 +1,14 @@ --- + + + + + + + title: 볼륨 스냅샷 content_type: concept -weight: 20 +weight: 40 --- diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 5983c37647..a4245a7daa 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -44,12 +44,21 @@ weight: 10 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다. -컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 -뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는 -파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에 -마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 -가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로 -지정해야 한다. +컨테이너의 프로세스는 +{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}의 최초 내용물과 +컨테이너 안에 마운트된 볼륨(정의된 경우에 한함)으로 구성된 파일시스템을 보게 된다. +프로세스는 컨테이너 이미지의 최초 내용물에 해당되는 루트 파일시스템을 +보게 된다. +쓰기가 허용된 경우, 해당 파일시스템에 쓰기 작업을 하면 +추후 파일시스템에 접근할 때 변경된 내용을 보게 될 것이다. +볼륨은 이미지의 [특정 경로](#using-subpath)에 +마운트된다. +파드에 정의된 각 컨테이너에 대해, +컨테이너가 사용할 각 볼륨을 어디에 마운트할지 명시해야 한다. + +볼륨은 다른 볼륨 안에 마운트될 수 없다 +(하지만, [서브패스 사용](#using-subpath)에서 관련 메커니즘을 확인한다). +또한, 볼륨은 다른 볼륨에 있는 내용물을 가리키는 하드 링크를 포함할 수 없다. ## 볼륨 유형들 {#volume-types} @@ -802,142 +811,7 @@ spec: ### projected `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. - -현재, 다음 유형의 볼륨 소스를 프로젝티드한다. - -* [`secret`](#secret) -* [`downwardAPI`](#downwardapi) -* [`configMap`](#configmap) -* `serviceAccountToken` - -모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 -[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다. - -#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - downwardAPI: - items: - - path: "labels" - fieldRef: - fieldPath: metadata.labels - - path: "cpu_limit" - resourceFieldRef: - containerName: container-test - resource: limits.cpu - - configMap: - name: myconfigmap - items: - - key: config - path: my-group/my-config -``` - -#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: volume-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: all-in-one - mountPath: "/projected-volume" - readOnly: true - volumes: - - name: all-in-one - projected: - sources: - - secret: - name: mysecret - items: - - key: username - path: my-group/my-username - - secret: - name: mysecret2 - items: - - key: password - path: my-group/my-password - mode: 511 -``` - -각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. -파라미터는 두 가지 예외를 제외하고 거의 동일하다. - -* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록 - `name` 으로 변경되었다. -* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 - 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` - 를 명시적으로 설정할 수 있다. - -`TokenRequestProjection` 기능이 활성화 되면, 현재 -[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 -대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: sa-token-test -spec: - containers: - - name: container-test - image: busybox - volumeMounts: - - name: token-vol - mountPath: "/service-account" - readOnly: true - volumes: - - name: token-vol - projected: - sources: - - serviceAccountToken: - audience: api - expirationSeconds: 3600 - path: token -``` - -예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 -있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데 -사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 -포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, -그렇지 않으면 토큰을 거부해야 한다. 이 필드는 -선택 사항이며 기본값은 API 서버의 식별자이다. - -`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효 -기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는 -API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서 -최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한 -상대 경로를 지정한다. - -{{< note >}} -projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 -해당 볼륨 소스의 업데이트를 수신하지 않는다. -{{< /note >}} +더 자세한 사항은 [projected volumes](/docs/concepts/storage/projected-volumes/)를 참고한다. ### quobyte (사용 중단됨) {#quobyte} @@ -975,6 +849,38 @@ RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를 참고한다. +#### RBD CSI 마이그레이션 {#rbd-csi-migration} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +`RBD`를 위한 `CSIMigration` 기능이 활성화되어 있으면, +사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`rbd.csi.ceph.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} +드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 +[Ceph CSI 드라이버](https://github.com/ceph/ceph-csi)가 설치되어 있고 +`CSIMigration`, `CSIMigrationRBD` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. + +{{< note >}} + +스토리지를 관리하는 쿠버네티스 클러스터 관리자는, +RBD CSI 드라이버로의 마이그레이션을 시도하기 전에 +다음의 선행 사항을 완료해야 한다. + +* 쿠버네티스 클러스터에 Ceph CSI 드라이버 (`rbd.csi.ceph.com`) v3.5.0 + 이상을 설치해야 한다. +* CSI 드라이버가 동작하기 위해 `clusterID` 필드가 필수이지만 + 트리 내(in-tree) 스토리지클래스는 `monitors` 필드가 필수임을 감안하여, + 쿠버네티스 저장소 관리자는 monitors 값의 + 해시(예: `#echo -n '' | md5sum`) + 기반으로 clusterID를 CSI 컨피그맵 내에 만들고 + 이 clusterID 환경 설정 아래에 monitors 필드를 유지해야 한다. +* 또한, 트리 내(in-tree) 스토리지클래스의 + `adminId` 값이 `admin`이 아니면, 트리 내(in-tree) 스토리지클래스의 + `adminSecretName` 값이 `adminId` 파라미터 값의 + base64 값으로 패치되어야 하며, 아니면 이 단계를 건너뛸 수 있다. + ### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 @@ -1144,6 +1050,16 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 `vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다. +#### Portworx CSI 마이그레이션 +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +Portworx를 위한 `CSIMigration` 기능이 쿠버네티스 1.23에 추가되었지만 +알파 상태이기 때문에 기본적으로는 비활성화되어 있다. +이 기능은 사용 중이 트리 내(in-tree) 플러그인의 모든 플러그인 동작을 +`pxd.portworx.com` CSI 드라이버로 리다이렉트한다. +이 기능을 사용하려면, 클러스터에 [Portworx CSI 드라이버](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)가 +설치되어 있고, kube-controller-manager와 kubelet에 `CSIMigrationPortworx=true`로 설정해야 한다. + ## subPath 사용하기 {#using-subpath} 때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. @@ -1239,8 +1155,7 @@ spec: ## 아웃-오브-트리(out-of-tree) 볼륨 플러그인 아웃-오브-트리 볼륨 플러그인에는 -{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 -FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 +{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 FlexVolume(사용 중단됨)이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. 이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와 @@ -1373,13 +1288,21 @@ CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트 ### flexVolume -FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는 -아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 -접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의 -미리 정의된 볼륨 플러그인 경로에 설치해야 한다. +{{< feature-state for_k8s_version="v1.23" state="deprecated" >}} + +FlexVolume은 스토리지 드라이버와 인터페이싱하기 위해 exec 기반 모델을 사용하는 아웃-오브-트리 플러그인 인터페이스이다. +FlexVolume 드라이버 바이너리 파일은 각 노드의 미리 정의된 볼륨 플러그인 경로에 설치되어야 하며, +일부 경우에는 컨트롤 플레인 노드에도 설치되어야 한다. 파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다. -더 자세한 내용은 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 예제를 참고한다. +더 자세한 내용은 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 문서를 참고한다. + +{{< note >}} +FlexVolume은 사용 중단되었다. 쿠버네티스에 외부 스토리지를 연결하려면 아웃-오브-트리 CSI 드라이버를 사용하는 것을 권장한다. + +FlexVolume 드라이버 메인테이너는 CSI 드라이버를 구현하고 사용자들이 FlexVolume 드라이버에서 CSI로 마이그레이트할 수 있도록 지원해야 한다. +FlexVolume 사용자는 워크로드가 동등한 CSI 드라이버를 사용하도록 이전해야 한다. +{{< /note >}} ## 마운트 전파(propagation) diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 3ae5659806..34ac547b73 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -17,8 +17,6 @@ _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text=" 하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. -추가로, 크론잡 스케줄은 타임존(timezone) 처리를 지원해서, 크론잡 스케줄 시작 부분에 "CRON_TZ=