[ko] Update outdated files in dev-1.22-ko.1 (p6)
Jihoon Seo
parent
3467875f92
commit
710fa9288d
|
|
@ -197,7 +197,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
|
|||
|
||||
### 파드의 setHostnameAsFQDN 필드 {#pod-sethostnameasfqdn-field}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
|
||||
|
||||
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.
|
||||
|
||||
|
|
@ -313,6 +313,28 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
|
|||
options ndots:5
|
||||
```
|
||||
|
||||
#### 확장된 DNS 환경 설정
|
||||
|
||||
{{< feature-state for_k8s_version="1.22" state="alpha" >}}
|
||||
|
||||
쿠버네티스는 파드의 DNS 환경 설정을 위해 기본적으로 최대 6개의 탐색 도메인과
|
||||
최대 256자의 탐색 도메인 목록을 허용한다.
|
||||
|
||||
kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화되어 있으면,
|
||||
쿠버네티스는 최대 32개의 탐색 도메인과
|
||||
최대 2048자의 탐색 도메인 목록을 허용한다.
|
||||
|
||||
### 기능 가용성
|
||||
|
||||
파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
|
||||
|
||||
| 쿠버네티스 버전 | 기능 지원 |
|
||||
| :---------: |:-----------:|
|
||||
| 1.14 | 안정 |
|
||||
| 1.10 | 베타 (기본값으로 켜져 있음)|
|
||||
| 1.9 | 알파 |
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@ weight: 40
|
|||
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
|
||||
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
|
||||
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
|
||||
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
|
||||
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
|
||||
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
|
||||
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: 인그레스(Ingress)
|
||||
content_type: concept
|
||||
weight: 40
|
||||
|
|
@ -222,7 +224,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
|
|||
|
||||
#### 네임스페이스 범위의 파라미터
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
|
||||
사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
|
||||
|
|
|
|||
|
|
@ -223,7 +223,7 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex
|
|||
|
||||
## 포트 범위 지정
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.
|
||||
|
||||
|
|
@ -251,17 +251,25 @@ spec:
|
|||
endPort: 32768
|
||||
```
|
||||
|
||||
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
|
||||
위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우,
|
||||
네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가
|
||||
TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
|
||||
|
||||
이 필드를 사용할 때 다음의 제한 사항이 적용된다.
|
||||
* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
|
||||
* 베타 기능으로, 기본적으로 활성화되어 있다.
|
||||
클러스터 수준에서 `endPort` 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가
|
||||
API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 이용하여
|
||||
`NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
|
||||
* `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
|
||||
* `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
|
||||
* 두 포트 모두 숫자여야 한다.
|
||||
|
||||
{{< note >}}
|
||||
클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
|
||||
네트워크폴리시 명세에서 `endPort` 필드를 지원한다.
|
||||
클러스터가 네트워크폴리시 명세의 `endPort` 필드를 지원하는
|
||||
{{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
|
||||
만약 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)이
|
||||
`endPort` 필드를 지원하지 않는데 네트워크폴리시의 해당 필드에 명시를 하면,
|
||||
그 정책은 `port` 필드에만 적용될 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
## 이름으로 네임스페이스 지정
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
|
|||
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
|
||||
새 인스턴스를 생성할 수 있다.
|
||||
서비스 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
|
||||
[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names)이어야 한다.
|
||||
|
||||
예를 들어, 각각 TCP 포트 9376에서 수신하고
|
||||
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
|
||||
|
|
@ -188,9 +188,10 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
|
|||
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
|
||||
|
||||
### 초과 용량 엔드포인트
|
||||
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
|
||||
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
|
||||
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
|
||||
엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상)
|
||||
클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: truncated` 어노테이션을 추가한다.
|
||||
이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며
|
||||
엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
|
||||
|
||||
### 엔드포인트슬라이스
|
||||
|
||||
|
|
@ -384,6 +385,40 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
|
|||
유효하지 않은 clusterIP 주소 값으로 서비스를 생성하려고 하면, API 서버는
|
||||
422 HTTP 상태 코드를 리턴하여 문제점이 있음을 알린다.
|
||||
|
||||
## 트래픽 정책
|
||||
|
||||
### 외부 트래픽 정책
|
||||
|
||||
`spec.externalTrafficPolicy` 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
|
||||
이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
|
||||
`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬
|
||||
엔드포인트가 하나도 없는 경우, kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다.
|
||||
|
||||
{{< note >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
|
||||
kube-proxy에 대해 `ProxyTerminatingEndpoints`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
활성화하면, kube-proxy는 노드에 로컬 엔드포인트가 있는지,
|
||||
그리고 모든 로컬 엔드포인트가 "종료 중(terminating)"으로 표시되어 있는지 여부를 확인한다.
|
||||
만약 로컬 엔드포인트가 존재하는데 **모두**가 종료 중이면, kube-proxy는 `Local`로 설정된 모든 외부 트래픽 정책을 무시한다.
|
||||
대신, 모든 노드-로컬 엔드포인트가 "종료 중" 상태를 유지하는 동안,
|
||||
kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 것처럼
|
||||
그 서비스에 대한 트래픽을 정상 상태의 다른 엔드포인트로 포워드한다.
|
||||
이러한 종료 중인 엔드포인트에 대한 포워딩 정책은 `NodePort` 서비스로 트래픽을 로드밸런싱하던 외부 로드밸런서가
|
||||
헬스 체크 노드 포트가 작동하지 않을 때에도 연결들을 비돌발적으로(gracefully) 종료시킬 수 있도록 하기 위해 존재한다.
|
||||
이러한 정책이 없다면, 노드가 여전히 로드밸런서 노드 풀에 있지만
|
||||
파드 종료 과정에서 트래픽이 제거(drop)되는 상황에서 트래픽이 유실될 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
### 내부 트래픽 정책
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`spec.internalTrafficPolicy` 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
|
||||
이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
|
||||
`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬
|
||||
엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 포워드하지 않는다.
|
||||
|
||||
## 서비스 디스커버리하기
|
||||
|
||||
쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
|
||||
|
|
@ -523,6 +558,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
|
|||
[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
|
||||
동등한 `nodePortAddresses` 필드를
|
||||
특정 IP 블록으로 설정할 수 있다.
|
||||
|
||||
이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
|
||||
|
||||
예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
|
||||
|
|
@ -641,12 +677,12 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정
|
|||
|
||||
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에
|
||||
대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다.
|
||||
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는
|
||||
클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
|
||||
`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
|
||||
기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
|
||||
클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
|
||||
`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
|
||||
`spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
|
||||
구현이 서비스를 감시하고 있다고 가정한다.
|
||||
모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
|
||||
|
|
@ -656,7 +692,6 @@ v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer`
|
|||
`spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는
|
||||
"`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
|
||||
접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
|
||||
이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다.
|
||||
|
||||
#### 내부 로드 밸런서
|
||||
|
||||
|
|
|
|||
|
|
@ -314,12 +314,9 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
|
|||
* [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
|
||||
* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
|
||||
* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
|
||||
* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
|
||||
(**사용 중단**)
|
||||
* [`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
|
||||
* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
|
||||
* [`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 볼륨
|
||||
|
|
@ -329,17 +326,28 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
|
|||
* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
|
||||
로컬 스토리지 디바이스
|
||||
* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지
|
||||
* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
|
||||
(이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
|
||||
작동하지 않는다.)
|
||||
* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
|
||||
* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
|
||||
* [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 볼륨
|
||||
* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
|
||||
(**사용 중단**)
|
||||
* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
|
||||
* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨
|
||||
|
||||
아래의 PersistentVolume 타입은 사용 중단되었다. 이 말인 즉슨, 지원은 여전히 제공되지만 추후 쿠버네티스 릴리스에서는 삭제될 예정이라는 것이다.
|
||||
|
||||
* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
|
||||
(v1.18에서 **사용 중단**)
|
||||
* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
|
||||
(v1.22에서 **사용 중단**)
|
||||
* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
|
||||
(v1.22에서 **사용 중단**)
|
||||
* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
|
||||
(v1.22에서 **사용 중단**)
|
||||
|
||||
이전 쿠버네티스 버전은 아래의 인-트리 PersistentVolume 타입도 지원했었다.
|
||||
|
||||
* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
|
||||
(v1.15 이후 **사용 불가**)
|
||||
* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
|
||||
(v1.21 이후 **사용 불가**)
|
||||
|
||||
## 퍼시스턴트 볼륨
|
||||
|
||||
각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다.
|
||||
|
|
@ -407,38 +415,40 @@ spec:
|
|||
* ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
|
||||
* ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다
|
||||
* ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
|
||||
* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다.
|
||||
쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다.
|
||||
|
||||
CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
|
||||
|
||||
* RWO - ReadWriteOnce
|
||||
* ROX - ReadOnlyMany
|
||||
* RWX - ReadWriteMany
|
||||
* RWOP - ReadWriteOncePod
|
||||
|
||||
> __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다.
|
||||
|
||||
|
||||
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany|
|
||||
| :--- | :---: | :---: | :---: |
|
||||
| AWSElasticBlockStore | ✓ | - | - |
|
||||
| AzureFile | ✓ | ✓ | ✓ |
|
||||
| AzureDisk | ✓ | - | - |
|
||||
| CephFS | ✓ | ✓ | ✓ |
|
||||
| Cinder | ✓ | - | - |
|
||||
| CSI | 드라이버에 따라 다름 | 드라이버에 따라 다름 | 드라이버에 따라 다름 |
|
||||
| FC | ✓ | ✓ | - |
|
||||
| FlexVolume | ✓ | ✓ | 드라이버에 따라 다름 |
|
||||
| Flocker | ✓ | - | - |
|
||||
| GCEPersistentDisk | ✓ | ✓ | - |
|
||||
| Glusterfs | ✓ | ✓ | ✓ |
|
||||
| HostPath | ✓ | - | - |
|
||||
| iSCSI | ✓ | ✓ | - |
|
||||
| Quobyte | ✓ | ✓ | ✓ |
|
||||
| NFS | ✓ | ✓ | ✓ |
|
||||
| RBD | ✓ | ✓ | - |
|
||||
| VsphereVolume | ✓ | - | - (파드가 병치될(collocated) 때 작동) |
|
||||
| PortworxVolume | ✓ | - | ✓ |
|
||||
| ScaleIO | ✓ | ✓ | - |
|
||||
| StorageOS | ✓ | - | - |
|
||||
| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod |
|
||||
| :--- | :---: | :---: | :---: | - |
|
||||
| AWSElasticBlockStore | ✓ | - | - | - |
|
||||
| AzureFile | ✓ | ✓ | ✓ | - |
|
||||
| AzureDisk | ✓ | - | - | - |
|
||||
| CephFS | ✓ | ✓ | ✓ | - |
|
||||
| Cinder | ✓ | - | - | - |
|
||||
| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver |
|
||||
| FC | ✓ | ✓ | - | - |
|
||||
| FlexVolume | ✓ | ✓ | depends on the driver | - |
|
||||
| Flocker | ✓ | - | - | - |
|
||||
| GCEPersistentDisk | ✓ | ✓ | - | - |
|
||||
| Glusterfs | ✓ | ✓ | ✓ | - |
|
||||
| HostPath | ✓ | - | - | - |
|
||||
| iSCSI | ✓ | ✓ | - | - |
|
||||
| Quobyte | ✓ | ✓ | ✓ | - |
|
||||
| NFS | ✓ | ✓ | ✓ | - |
|
||||
| RBD | ✓ | ✓ | - | - |
|
||||
| VsphereVolume | ✓ | - | - (works when Pods are collocated) | - |
|
||||
| PortworxVolume | ✓ | - | ✓ | - | - |
|
||||
| StorageOS | ✓ | - | - | - |
|
||||
|
||||
### 클래스
|
||||
|
||||
|
|
@ -785,6 +795,82 @@ spec:
|
|||
storage: 10Gi
|
||||
```
|
||||
|
||||
## 볼륨 파퓰레이터(Volume populator)와 데이터 소스
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다.
|
||||
이 알파 기능은 쿠버네티스 1.18에서 도입되었으며
|
||||
1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다.
|
||||
현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번
|
||||
확인한다. {{% version-check %}}
|
||||
커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해
|
||||
`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다.
|
||||
다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는
|
||||
`dataSource` 필드와는 다르게, `dataSourceRef` 필드는 동일 네임스페이스에 있는
|
||||
어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외).
|
||||
기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다.
|
||||
|
||||
## 데이터 소스 참조
|
||||
|
||||
`dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다.
|
||||
둘 중 하나만 명시되어 있으면, API 서버는 두 필드에 같은 값을 할당할 것이다.
|
||||
두 필드 모두 생성 이후에는 변경될 수 없으며,
|
||||
두 필드에 다른 값을 넣으려고 시도하면 검증 에러가 발생할 것이다.
|
||||
따라서 두 필드는 항상 같은 값을 갖게 된다.
|
||||
|
||||
`dataSourceRef` 필드와 `dataSource` 필드 사이에는
|
||||
사용자가 알고 있어야 할 두 가지 차이점이 있다.
|
||||
* `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만,
|
||||
`dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다.
|
||||
유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다.
|
||||
* `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는
|
||||
PVC와 VolumeSnapshot만 포함할 수 있다.
|
||||
|
||||
기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은
|
||||
클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야
|
||||
할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만
|
||||
존재하는 것이다. 상세히 설명하면, 이전 버전과 새로운 버전의 컨트롤러가 함께 동작할
|
||||
수 있는데, 이는 두 필드가 동일하기 때문이다.
|
||||
|
||||
### 볼륨 파퓰레이터 사용하기
|
||||
|
||||
볼륨 파퓰레이터는 비어 있지 않은 볼륨(non-empty volume)을 생성할 수 있는 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}이며,
|
||||
이 볼륨의 내용물은 커스텀 리소스(Custom Resource)에 의해 결정된다.
|
||||
파퓰레이티드 볼륨(populated volume)을 생성하려면 `dataSourceRef` 필드에 커스텀 리소스를 기재한다.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: populated-pvc
|
||||
spec:
|
||||
dataSourceRef:
|
||||
name: example-name
|
||||
kind: ExampleDataSource
|
||||
apiGroup: example.storage.k8s.io
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 10Gi
|
||||
```
|
||||
|
||||
볼륨 파퓰레이터는 외부 컴포넌트이기 때문에,
|
||||
만약 적합한 컴포넌트가 설치되어 있지 않다면 볼륨 파퓰레이터를 사용하는 PVC에 대한 생성 요청이 실패할 수 있다.
|
||||
외부 컨트롤러는 '컴포넌트가 없어서 PVC를 생성할 수 없음' 경고와 같은
|
||||
PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이벤트를 생성해야 한다.
|
||||
|
||||
알파 버전의 [볼륨 데이터 소스 검증기](https://github.com/kubernetes-csi/volume-data-source-validator)를
|
||||
클러스터에 설치할 수 있다.
|
||||
해당 데이터 소스를 다루는 파퓰레이터가 등록되어 있지 않다면 이 컨트롤러가 PVC에 경고 이벤트를 생성한다.
|
||||
PVC를 위한 적절한 파퓰레이터가 설치되어 있다면,
|
||||
볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다.
|
||||
|
||||
## 포터블 구성 작성
|
||||
|
||||
광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한
|
||||
|
|
|
|||
Loading…
Reference in New Issue