[ko] Update outdated files in dev-1.24-ko.3 [M6-7/M35-49]
Co-authored-by: Jihoon Seo <46767780+jihoon-seo@users.noreply.github.com> Co-authored-by: Sanghong Kim <58922834+bconfiden2@users.noreply.github.com>pull/35880/head
Yoon PyungHo
parent
cc2f29f21a
commit
b92b779fcb
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - mikedanese
|
||||
title: 구성 모범 사례
|
||||
content_type: concept
|
||||
weight: 10
|
||||
|
|
@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
|
|||
|
||||
## 레이블 사용하기
|
||||
|
||||
- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
|
||||
- `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app.kubernetes.io/name: MyApp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
|
||||
|
||||
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - tallclair
|
||||
# - dchen1107
|
||||
title: 런타임클래스(RuntimeClass)
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -81,7 +81,7 @@ handler: myconfiguration
|
|||
|
||||
## 사용
|
||||
|
||||
클러스터에 런타임클래스를 설정하고 나면,
|
||||
클러스터에 런타임클래스를 설정하고 나면,
|
||||
다음과 같이 파드 스펙에 `runtimeClassName`를 명시하여 해당 런타임클래스를 사용할 수 있다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -116,7 +116,7 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
|
|||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
|
||||
```
|
||||
|
||||
더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를
|
||||
더 자세한 내용은 containerd의 [구성 문서](https://github.com/containerd/cri/blob/master/docs/config.md)를
|
||||
살펴본다.
|
||||
|
||||
#### {{< glossary_tooltip term_id="cri-o" >}}
|
||||
|
|
@ -136,7 +136,7 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
|
|||
|
||||
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
|
||||
|
||||
RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가
|
||||
RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가
|
||||
이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다.
|
||||
`scheduling`이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: 레퍼런스
|
||||
|
||||
|
||||
# approvers:
|
||||
# - chenopis
|
||||
linkTitle: "레퍼런스"
|
||||
main_menu: true
|
||||
weight: 70
|
||||
|
|
@ -86,7 +86,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
|
|||
[kube-scheduler 환경설정 (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)
|
||||
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
|
||||
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
|
||||
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및
|
||||
* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) 및
|
||||
[클라이언트 인증 API (v1)](/docs/reference/config-api/client-authentication.v1/)
|
||||
* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
|
||||
* [이미지 정책 API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/)
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - lavalamp
|
||||
# - deads2k
|
||||
# - liggitt
|
||||
title: 인가 개요
|
||||
content_type: concept
|
||||
weight: 60
|
||||
|
|
@ -74,6 +74,10 @@ PUT | update
|
|||
PATCH | patch
|
||||
DELETE | delete(개별 리소스), deletecollection(리소스 모음)
|
||||
|
||||
{{< caution >}}
|
||||
`get`, `list`, `watch` 요청은 모두 리소스의 전체 세부 내용을 반환할 수 있다. 반환된 데이터의 관점으론 모두 동일하다. 예를 들어 `secrets`에 대해 `list` 요청은 반환된 리소스의 `data` 속성을 여전히 드러낼 것이다.
|
||||
{{< /caution >}}
|
||||
|
||||
쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,
|
||||
|
||||
* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/security/pod-security-policy/)
|
||||
|
|
@ -134,7 +138,7 @@ kubectl auth can-i list secrets --namespace dev --as dave
|
|||
no
|
||||
```
|
||||
|
||||
유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가
|
||||
유사하게, `dev` 네임스페이스의 `dev-sa` 서비스어카운트가
|
||||
`target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다.
|
||||
|
||||
```bash
|
||||
|
|
@ -209,7 +213,7 @@ status:
|
|||
|
||||
## 워크로드 생성 및 수정을 통한 권한 확대 {#privilege-escalation-via-pod-creation}
|
||||
|
||||
네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는
|
||||
네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는
|
||||
해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
|
|
@ -230,8 +234,8 @@ status:
|
|||
- 다른 워크로드를 위한 정보의 획득 및 수정에 사용될 수 있음
|
||||
|
||||
{{< caution >}}
|
||||
시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다.
|
||||
이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다.
|
||||
시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다.
|
||||
이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다.
|
||||
RBAC 제어에 대해 결정할 때 이와 같은 사항을 고려해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ card:
|
|||
각 쿠버네티스 컴포넌트를 사용하면 해당 컴포넌트와 관련된 기능 게이트 집합을
|
||||
활성화 또는 비활성화할 수 있다.
|
||||
모든 컴포넌트에 대한 전체 기능 게이트 집합을 보려면 `-h` 플래그를 사용한다.
|
||||
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
||||
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
||||
기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
|
||||
|
||||
```shell
|
||||
|
|
@ -603,9 +603,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
|
||||
- `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다.
|
||||
- `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다.
|
||||
- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는
|
||||
플러그인의 초기 형태를 제공하였으며, 사용 중단되었다.
|
||||
대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
|
||||
- `Accelerators`: 도커 엔진 사용 시 Nvidia GPU 지원을 활성화하는
|
||||
플러그인의 초기 형태를 제공하였으며, 사용 중단되었다.
|
||||
대안을 위해서는 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을
|
||||
확인한다.
|
||||
- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug/debug-cluster/audit/#advanced-audit) 기능을 활성화한다.
|
||||
- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
|
||||
|
|
@ -619,7 +619,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
자세한 내용은 [AppArmor 튜토리얼](/ko/docs/tutorials/security/apparmor/)을 참고한다.
|
||||
- `AttachVolumeLimit`: 볼륨 플러그인이 노드에 연결될 수 있는 볼륨 수에
|
||||
대한 제한을 보고하도록 한다.
|
||||
자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을
|
||||
자세한 내용은 [동적 볼륨 제한](/ko/docs/concepts/storage/storage-limits/#동적-볼륨-한도)을
|
||||
참고한다.
|
||||
- `BalanceAttachedNodeVolumes`: 스케줄링 시 균형 잡힌 리소스 할당을 위해 고려할 노드의 볼륨 수를
|
||||
포함한다. 스케줄러가 결정을 내리는 동안 CPU, 메모리 사용률 및 볼륨 수가
|
||||
|
|
@ -627,35 +627,35 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `BlockVolume`: 파드에서 원시 블록 장치의 정의와 사용을 활성화한다.
|
||||
자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을
|
||||
참고한다.
|
||||
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록
|
||||
서비스어카운트 볼륨을 마이그레이션한다.
|
||||
클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
|
||||
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다.
|
||||
이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
|
||||
`kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
|
||||
- `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록
|
||||
서비스어카운트 볼륨을 마이그레이션한다.
|
||||
클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여
|
||||
확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다.
|
||||
이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로
|
||||
`kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
|
||||
자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다.
|
||||
- `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가
|
||||
kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면,
|
||||
cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록
|
||||
[kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와
|
||||
[kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의
|
||||
리더 마이그레이션(Leader Migration)을 활성화한다.
|
||||
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
|
||||
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
|
||||
- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의
|
||||
미세 조정을 허용한다.
|
||||
- `CPUManagerPolicyAlphaOptions`: CPUManager 정책 중 실험적이며 알파 품질인 옵션의
|
||||
미세 조정을 허용한다.
|
||||
이 기능 게이트는 품질 수준이 알파인 CPUManager 옵션의 *그룹*을 보호한다.
|
||||
이 기능 게이트는 베타 또는 안정(stable) 상태로 변경되지 않을 것이다.
|
||||
- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의
|
||||
미세 조정을 허용한다.
|
||||
- `CPUManagerPolicyBetaOptions`: CPUManager 정책 중 실험적이며 베타 품질인 옵션의
|
||||
미세 조정을 허용한다.
|
||||
이 기능 게이트는 품질 수준이 베타인 CPUManager 옵션의 *그룹*을 보호한다.
|
||||
이 기능 게이트는 안정(stable) 상태로 변경되지 않을 것이다.
|
||||
- `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다.
|
||||
- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.
|
||||
로그 파일 사이즈 기본값은 10MB이며,
|
||||
컨테이너 당 최대 로그 파일 수 기본값은 5이다.
|
||||
이 값은 kubelet 환경설정으로 변경할 수 있다.
|
||||
더 자세한 내용은
|
||||
- `CRIContainerLogRotation`: CRI 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다.
|
||||
로그 파일 사이즈 기본값은 10MB이며,
|
||||
컨테이너 당 최대 로그 파일 수 기본값은 5이다.
|
||||
이 값은 kubelet 환경설정으로 변경할 수 있다.
|
||||
더 자세한 내용은
|
||||
[노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
|
||||
- `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다.
|
||||
자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원)을
|
||||
|
|
@ -665,11 +665,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `CSIInlineVolume`: 파드에 대한 CSI 인라인 볼륨 지원을 활성화한다.
|
||||
- `CSIMigration`: shim 및 변환 로직을 통해 볼륨 작업을 인-트리 플러그인에서
|
||||
사전 설치된 해당 CSI 플러그인으로 라우팅할 수 있다.
|
||||
- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을
|
||||
AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
- `CSIMigrationAWS`: shim 및 변환 로직을 통해 볼륨 작업을
|
||||
AWS-EBS 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 EBS CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 EBS 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
|
||||
- `CSIMigrationAWSComplete`: kubelet 및 볼륨 컨트롤러에서 EBS 인-트리
|
||||
플러그인 등록을 중지하고 shim 및 변환 로직을 사용하여 볼륨 작업을 AWS-EBS
|
||||
|
|
@ -677,27 +677,27 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고
|
||||
EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
|
||||
이 플래그는 인-트리 EBS 플러그인의 등록을 막는 `InTreePluginAWSUnregister` 기능 플래그로 인해
|
||||
더 이상 사용되지 않는다.
|
||||
더 이상 사용되지 않는다.
|
||||
- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을
|
||||
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
이 기능이 비활성화되어 있거나 AzureDisk CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 AzureDisk 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
|
||||
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
|
||||
- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서
|
||||
Azure-Disk 인-트리 플러그인 등록을 중지하고
|
||||
shim 및 변환 로직을 사용하여
|
||||
볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
|
||||
클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고
|
||||
AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
|
||||
이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는
|
||||
- `CSIMigrationAzureDiskComplete`: kubelet 및 볼륨 컨트롤러에서
|
||||
Azure-Disk 인-트리 플러그인 등록을 중지하고
|
||||
shim 및 변환 로직을 사용하여
|
||||
볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
|
||||
클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고
|
||||
AzureDisk CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
|
||||
이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는
|
||||
`InTreePluginAzureDiskUnregister` 기능 플래그로 인해 더 이상 사용되지 않는다.
|
||||
- `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을
|
||||
Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
이 기능이 비활성화되어 있거나 AzureFile CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 AzureFile 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
|
||||
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
|
||||
- `CSIMigrationAzureFileComplete`: kubelet 및 볼륨 컨트롤러에서 Azure 파일 인-트리
|
||||
|
|
@ -705,59 +705,59 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로
|
||||
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능
|
||||
플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어
|
||||
있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는
|
||||
있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는
|
||||
`InTreePluginAzureFileUnregister` 기능 플래그로 인해
|
||||
더 이상 사용되지 않는다.
|
||||
- `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을
|
||||
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 GCE 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 PD CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 GCE 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
|
||||
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
|
||||
- `CSIMigrationGCEComplete`: kubelet 및 볼륨 컨트롤러에서 GCE-PD
|
||||
인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
|
||||
인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
|
||||
CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI
|
||||
플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
|
||||
플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
|
||||
이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해
|
||||
더 이상 사용되지 않는다.
|
||||
- `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을
|
||||
Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 Cinder 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다.
|
||||
이 기능이 비활성화되어 있거나 Cinder CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 Cinder 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
|
||||
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
|
||||
- `CSIMigrationOpenStackComplete`: kubelet 및 볼륨 컨트롤러에서
|
||||
Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리
|
||||
플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다.
|
||||
클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고
|
||||
Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
|
||||
이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해
|
||||
Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
|
||||
이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해
|
||||
더 이상 사용되지 않는다.
|
||||
- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
|
||||
Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
|
||||
클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
|
||||
Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다.
|
||||
이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 `InTreePluginRBDUnregister` 기능 플래그에 의해
|
||||
- `csiMigrationRBD`: RBD 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
|
||||
Ceph RBD CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
|
||||
클러스터에 CSIMigration 및 csiMigrationRBD 기능 플래그가 활성화되어 있어야 하고,
|
||||
Ceph CSI 플러그인이 설치 및 설정되어 있어야 한다.
|
||||
이 플래그는 트리 내(in-tree) RBD 플러그인 등록을 금지시키는 `InTreePluginRBDUnregister` 기능 플래그에 의해
|
||||
사용 중단되었다.
|
||||
- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을
|
||||
라우팅하는 shim 및 변환 로직을 사용한다.
|
||||
이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
이 기능이 비활성화되어 있거나 vSphere CSI 플러그인이 설치 및 구성되어 있지 않은 노드에서의 마운트 동작에 대해
|
||||
인-트리 vSphere 플러그인으로의 폴백(falling back)을 지원한다.
|
||||
프로비전 동작에 대해서는 폴백을 지원하지 않는데,
|
||||
프로비전 동작은 해당 CSI 플러그인이 설치 및 구성되어 있어야 가능하기 때문이다.
|
||||
이 기능을 사용하려면 CSIMigration 기능 플래그가 활성화되어 있어야 한다.
|
||||
- `CSIMigrationvSphereComplete`: kubelet 및 볼륨 컨트롤러에서 vSphere 인-트리
|
||||
플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서
|
||||
vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및
|
||||
CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
|
||||
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
|
||||
클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
|
||||
이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
|
||||
더 이상 사용되지 않는다.
|
||||
- `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
|
||||
Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
|
||||
- `CSIMigrationPortworx`: Portworx 트리 내(in-tree) 플러그인으로 가는 볼륨 작업을
|
||||
Portworx CSI 플러그인으로 라우트하는 심(shim)과 변환 로직을 활성화한다.
|
||||
Portworx CSI 드라이버가 설치 및 설정되어 있어야 한다.
|
||||
- `CSINodeInfo`: `csi.storage.k8s.io` 내의 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
|
||||
- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md)
|
||||
|
|
@ -780,9 +780,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은
|
||||
[파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을
|
||||
참고한다.
|
||||
- `ContextualLogging`: 이 기능을 활성화하면,
|
||||
- `ContextualLogging`: 이 기능을 활성화하면,
|
||||
컨텍스츄얼 로깅을 지원하는 쿠버네티스 구성 요소가 로그 출력에 추가 상세를 추가한다.
|
||||
- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에
|
||||
- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에
|
||||
대한 리더 마이그레이션을 지원한다.
|
||||
- `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}}
|
||||
컨트롤러의 대체 구현을 사용한다. 그렇지 않으면,
|
||||
|
|
@ -790,8 +790,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `CronJobTimeZone`: [크론잡](/ko/docs/concepts/workloads/controllers/cron-jobs/)의 선택적 `timeZone` 필드 사용을 허용한다.
|
||||
- `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서
|
||||
`cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다.
|
||||
- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된
|
||||
검증 규칙을 기반으로 커스텀 리소스를 검증하는
|
||||
- `CustomResourceValidationExpressions`: `x-kubernetes-validations` 확장 기능으로 작성된
|
||||
검증 규칙을 기반으로 커스텀 리소스를 검증하는
|
||||
표현 언어 검증(expression language validation)을 CRD에 활성화한다.
|
||||
- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
|
||||
자세한 내용은 [파드의 DNS 설정](/ko/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)을
|
||||
|
|
@ -804,30 +804,30 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다.
|
||||
- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
|
||||
생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
|
||||
- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록
|
||||
- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록
|
||||
데몬셋 워크로드를 사용하도록 설정한다.
|
||||
[데몬셋에서 롤링 업데이트 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)을 참고한다.
|
||||
- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
|
||||
[기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
|
||||
- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해
|
||||
`fsGroup`를 전달하여 파드의 `securityContext`에서
|
||||
[기본 분배](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/#내부-기본-제약)를 수행한다.
|
||||
- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해
|
||||
`fsGroup`를 전달하여 파드의 `securityContext`에서
|
||||
`fsGroup`를 드라이브에 적용하는 역할을 위임한다.
|
||||
- `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
|
||||
기반 리소스 프로비저닝을 활성화한다.
|
||||
- `DisableAcceleratorUsageMetrics`:
|
||||
[kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/#액셀러레이터-메트릭-비활성화).
|
||||
- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
|
||||
`--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
|
||||
- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
|
||||
`--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
|
||||
모든 기능을 비활성화한다.
|
||||
- `DisableKubeletCloudCredentialProviders`: 이미지 풀 크리덴셜을 위해
|
||||
- `DisableKubeletCloudCredentialProviders`: 이미지 풀 크리덴셜을 위해
|
||||
클라우드 프로바이더 컨테이너 레지스트리에 인증을 수행하는 kubelet 내부(in-tree) 기능을 비활성화한다.
|
||||
- `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서
|
||||
hugepages 사용을 활성화한다.
|
||||
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
|
||||
요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
|
||||
- `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다.
|
||||
- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다.
|
||||
이 기능은 지원하는 버전 차이(supported skew policy) 바깥에서는 더 이상 지원되지 않는다.
|
||||
- `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다.
|
||||
이 기능은 지원하는 버전 차이(supported skew policy) 바깥에서는 더 이상 지원되지 않는다.
|
||||
이 기능 게이트는 1.24에 kubelet에서 제거되었다. [kubelet 재구성하기](/docs/tasks/administer-cluster/reconfigure-kubelet/)를 참고한다.
|
||||
- `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록
|
||||
기본 스케줄러를 확장한다.
|
||||
|
|
@ -854,13 +854,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
{{< glossary_tooltip text="임시 컨테이너" term_id="ephemeral-container" >}}를
|
||||
추가할 수 있다.
|
||||
- `EvenPodsSpread`: 토폴로지 도메인 간에 파드를 균등하게 스케줄링할 수 있다.
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 참고한다.
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/)을 참고한다.
|
||||
- `ExecProbeTimeout` : kubelet이 exec 프로브 시간 초과를 준수하는지 확인한다.
|
||||
이 기능 게이트는 기존 워크로드가 쿠버네티스가 exec 프로브 제한 시간을 무시한
|
||||
현재 수정된 결함에 의존하는 경우 존재한다.
|
||||
[준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다.
|
||||
- `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
|
||||
- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
|
||||
- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
|
||||
kubelet과 kube-apiserver를 사용하도록 설정한다.
|
||||
이 기능을 사용하려면 컨테이너 런타임이 지원해야 한다(Containerd: v1.5.6 이상, CRI-O: v1.22 이상).
|
||||
[확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다.
|
||||
|
|
@ -876,7 +876,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
|
||||
사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
|
||||
재 매핑이 활성화된 경우에만 활성화해야 한다.
|
||||
- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는
|
||||
- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는
|
||||
버그를 수정한다.
|
||||
- `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다.
|
||||
- `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인
|
||||
|
|
@ -888,13 +888,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
파드를 정상적으로 종료하려고 시도한다. 자세한 내용은
|
||||
[Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을
|
||||
참조한다.
|
||||
- `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때
|
||||
- `GracefulNodeShutdownBasedOnPodPriority`: 그레이스풀(graceful) 노드 셧다운을 할 때
|
||||
kubelet이 파드 우선순위를 체크할 수 있도록 활성화한다.
|
||||
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다.
|
||||
- `GRPCContainerProbe`: 활성 프로브(Liveness Probe), 준비성 프로브(Readiness Probe), 스타트업 프로브(Startup Probe)에 대해 gRPC 프로브를 활성화한다.
|
||||
[활성/준비성/스타트업 프로브 구성하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)를 참조한다.
|
||||
- `HonorPVReclaimPolicy`: 퍼시스턴트 볼륨 회수 정책이 `Delete`인 경우 PV-PVC 삭제 순서와 상관없이 정책을 준수한다.
|
||||
더 자세한 정보는
|
||||
[퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer)](/ko/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer) 문서를
|
||||
더 자세한 정보는
|
||||
[퍼시스턴트볼륨 삭제 보호 파이널라이저(finalizer)](/ko/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer) 문서를
|
||||
참고한다.
|
||||
- `HPAContainerMetrics`: `HorizontalPodAutoscaler` 를 활성화하여 대상 파드의
|
||||
개별 컨테이너 메트릭을 기반으로 확장한다.
|
||||
|
|
@ -907,55 +907,55 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `HyperVContainer`: 윈도우 컨테이너를 위한
|
||||
[Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)
|
||||
기능을 활성화한다.
|
||||
- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다.
|
||||
이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다.
|
||||
쿠버네티스 {{< skew currentVersion >}}에서,
|
||||
- `IdentifyPodOS`: 파드 OS 필드를 지정할 수 있게 한다.
|
||||
이를 통해 API 서버 관리 시 파드의 OS를 정석적인 방법으로 알 수 있다.
|
||||
쿠버네티스 {{< skew currentVersion >}}에서,
|
||||
`pod.spec.os.name` 에 사용할 수 있는 값은 `windows` 와 `linux` 이다.
|
||||
- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
|
||||
변경할 수 없는(immutable) 것으로 표시할 수 있다.
|
||||
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를
|
||||
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 파드 완료(completion)를
|
||||
완료 인덱스에 따라 관리할 수 있도록 허용한다.
|
||||
- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가
|
||||
`IngressClass` 리소스를 참조할 수 있도록 허용한다.
|
||||
- `IngressClassNamespacedParams`: 네임스페이스 범위의 파라미터가
|
||||
`IngressClass` 리소스를 참조할 수 있도록 허용한다.
|
||||
이 기능은 `IngressClass.spec.parameters`에 `Scope` 및 `Namespace`의 2 필드를 추가한다.
|
||||
- `Initializers`: Initializers 어드미션 플러그인을 사용하여,
|
||||
- `Initializers`: Initializers 어드미션 플러그인을 사용하여,
|
||||
오브젝트 생성 시 비동기 협조(asynchronous coordination)를 허용한다.
|
||||
- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리
|
||||
- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리
|
||||
- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginAzureFileUnregister`: kubelet 및 볼륨 컨트롤러에 azurefile 인-트리
|
||||
- `InTreePluginAzureFileUnregister`: kubelet 및 볼륨 컨트롤러에 azurefile 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginGCEUnregister`: kubelet 및 볼륨 컨트롤러에 gce-pd 인-트리
|
||||
- `InTreePluginGCEUnregister`: kubelet 및 볼륨 컨트롤러에 gce-pd 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리
|
||||
- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginPortworxUnregister`: kubelet 및 볼륨 컨트롤러에 Portworx 인-트리
|
||||
- `InTreePluginPortworxUnregister`: kubelet 및 볼륨 컨트롤러에 Portworx 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginRBDUnregister`: kubelet 및 볼륨 컨트롤러에 RBD 인-트리
|
||||
- `InTreePluginRBDUnregister`: kubelet 및 볼륨 컨트롤러에 RBD 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리
|
||||
- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리
|
||||
플러그인의 등록을 중지한다.
|
||||
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
|
||||
기능을 활성화한다.
|
||||
- `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의
|
||||
- `JobMutableNodeSchedulingDirectives`: [잡](/ko/docs/concepts/workloads/controllers/job/)의
|
||||
파드 템플릿에 있는 노드 스케줄링 지시를 업데이트할 수 있게 한다.
|
||||
- `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)이
|
||||
`Ready`인 파드의 수를 추적하는 기능을 활성화한다.
|
||||
`Ready`인 파드의 수는 [잡](/ko/docs/concepts/workloads/controllers/job/) 상태의
|
||||
[status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus)
|
||||
- `JobReadyPods`: 파드 [컨디션](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)이
|
||||
`Ready`인 파드의 수를 추적하는 기능을 활성화한다.
|
||||
`Ready`인 파드의 수는 [잡](/ko/docs/concepts/workloads/controllers/job/) 상태의
|
||||
[status](/docs/reference/kubernetes-api/workload-resources/job-v1/#JobStatus)
|
||||
필드에 기록된다.
|
||||
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
|
||||
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
|
||||
[잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
|
||||
잡 컨트롤러는 완료된 파드를 추적하기 위해
|
||||
잡 컨트롤러는 완료된 파드를 추적하기 위해
|
||||
완료된 파드의 잡 상태 필드를 사용한다.
|
||||
- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
|
||||
kubelet 구성을 로드할 수 있다.
|
||||
자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
|
||||
참고한다.
|
||||
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해
|
||||
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해
|
||||
kubelet exec 자격 증명 공급자를 활성화한다.
|
||||
- `KubeletInUserNamespace`: {{<glossary_tooltip text="user namespace" term_id="userns">}}에서
|
||||
- `KubeletInUserNamespace`: {{<glossary_tooltip text="user namespace" term_id="userns">}}에서
|
||||
kubelet 실행을 활성화한다.
|
||||
[루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다.
|
||||
- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
|
||||
|
|
@ -963,15 +963,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
|
||||
[장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을
|
||||
참고한다.
|
||||
- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스
|
||||
- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스
|
||||
`GetAllocatableResources` 기능을 활성화한다.
|
||||
이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록,
|
||||
이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록,
|
||||
할당 가능 자원에 대한 정보를
|
||||
[자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다.
|
||||
- `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은
|
||||
`NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여
|
||||
`node-role.kubernetes.io/master` 레이블을 무시한다.
|
||||
- `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반
|
||||
- `LegacyServiceAccountTokenNoAutoGeneration`: 시크릿 기반
|
||||
[서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)의 자동 생성을 중단한다.
|
||||
- `LocalStorageCapacityIsolation`:
|
||||
[로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와
|
||||
|
|
@ -986,15 +986,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
향상시킨다.
|
||||
- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여
|
||||
축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다.
|
||||
- `MaxUnavailableStatefulSet`: 스테이트풀셋의
|
||||
[롤링 업데이트 전략](/ko/docs/concepts/workloads/controllers/statefulset/#롤링-업데이트)에 대해
|
||||
`maxUnavailable` 필드를 설정할 수 있도록 한다.
|
||||
- `MaxUnavailableStatefulSet`: 스테이트풀셋의
|
||||
[롤링 업데이트 전략](/ko/docs/concepts/workloads/controllers/statefulset/#롤링-업데이트)에 대해
|
||||
`maxUnavailable` 필드를 설정할 수 있도록 한다.
|
||||
이 필드는 업데이트 동안 사용 불가능(unavailable) 상태의 파드를 몇 개까지 허용할지를 정한다.
|
||||
- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한
|
||||
- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한
|
||||
메모리 어피니티를 설정할 수 있다.
|
||||
- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여
|
||||
- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여
|
||||
파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
|
||||
- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/) 내의
|
||||
- `MinDomainsInPodTopologySpread`: 파드 [토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/topology-spread-constraints/) 내의
|
||||
`minDomains` 사용을 활성화한다.
|
||||
- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
|
||||
사용을 활성화한다.
|
||||
|
|
@ -1002,35 +1002,35 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다.
|
||||
자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다.
|
||||
- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable)
|
||||
{{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다.
|
||||
{{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다.
|
||||
(네임스페이스의 이름도 변경 불가)
|
||||
- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에
|
||||
- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에
|
||||
포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다.
|
||||
- `NetworkPolicyStatus`: 네트워크폴리시 오브젝트에 대해 `status` 서브리소스를 활성화한다.
|
||||
- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
|
||||
사용을 활성화한다.
|
||||
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
|
||||
- `NodeOutOfServiceVolumeDetach`: 노드가 `node.kubernetes.io/out-of-service` 테인트를 사용하여 서비스 불가(out-of-service)로 표시되면,
|
||||
노드에 있던 이 테인트를 허용하지 않는 파드는 강제로 삭제되며,
|
||||
종료되는 파드에 대한 볼륨 해제(detach) 동작도 즉시 수행된다.
|
||||
- `NodeOutOfServiceVolumeDetach`: 노드가 `node.kubernetes.io/out-of-service` 테인트를 사용하여 서비스 불가(out-of-service)로 표시되면,
|
||||
노드에 있던 이 테인트를 허용하지 않는 파드는 강제로 삭제되며,
|
||||
종료되는 파드에 대한 볼륨 해제(detach) 동작도 즉시 수행된다.
|
||||
이로 인해 삭제된 파드가 다른 노드에서 빠르게 복구될 수 있다.
|
||||
- `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
|
||||
반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
|
||||
더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
|
||||
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
|
||||
- `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의
|
||||
- `OpenAPIEnums`: API 서버로부터 리턴된 스펙 내 OpenAPI 스키마의
|
||||
"enum" 필드 채우기를 활성화한다.
|
||||
- `OpenAPIV3`: API 서버의 OpenAPI v3 발행을 활성화한다.
|
||||
- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록,
|
||||
[파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다.
|
||||
- `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다.
|
||||
`local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다.
|
||||
- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라
|
||||
- `PodAndContainerStatsFromCRI`: kubelet이 컨테이너와 파드 통계(stat) 정보를 cAdvisor가 아니라
|
||||
CRI 컨테이너 런타임으로부터 수집하도록 설정한다.
|
||||
- `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다.
|
||||
- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터)
|
||||
- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터)
|
||||
기능과
|
||||
[CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터)
|
||||
[CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터)
|
||||
쿼터 범위 기능을 활성화한다.
|
||||
- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
기능을 활성화한다.
|
||||
|
|
@ -1043,16 +1043,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를
|
||||
공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은
|
||||
[파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다.
|
||||
- `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에
|
||||
지정된 노드를 먼저 검사할지 여부를
|
||||
- `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에
|
||||
지정된 노드를 먼저 검사할지 여부를
|
||||
스케줄러에 알려준다.
|
||||
- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준
|
||||
`terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds)
|
||||
`terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds)
|
||||
기능을 활성화한다.
|
||||
더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다.
|
||||
- `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
|
||||
컨테이너의 proc 타입의 마운트를 제어할 수 있다.
|
||||
- `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록
|
||||
- `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록
|
||||
kube-proxy를 활성화한다.
|
||||
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
|
||||
삭제되지 않도록 한다.
|
||||
|
|
@ -1061,16 +1061,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
(현재 메모리만 해당).
|
||||
- `ReadWriteOncePod`: `ReadWriteOncePod` 퍼시스턴트 볼륨 엑세스 모드를
|
||||
사용한다.
|
||||
- `RecoverVolumeExpansionFailure`: 이전에 실패했던 볼륨 확장으로부터 복구할 수 있도록,
|
||||
사용자가 PVC를 더 작은 크기로 변경할 수 있도록 한다.
|
||||
[볼륨 확장 시 오류 복구](/ko/docs/concepts/storage/persistent-volumes/#볼륨-확장-시-오류-복구)에서
|
||||
- `RecoverVolumeExpansionFailure`: 이전에 실패했던 볼륨 확장으로부터 복구할 수 있도록,
|
||||
사용자가 PVC를 더 작은 크기로 변경할 수 있도록 한다.
|
||||
[볼륨 확장 시 오류 복구](/ko/docs/concepts/storage/persistent-volumes/#볼륨-확장-시-오류-복구)에서
|
||||
자세한 사항을 확인한다.
|
||||
- `RemainingItemCount`: API 서버가
|
||||
[청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한
|
||||
응답에서 남은 항목 수를 표시하도록 허용한다.
|
||||
- `RemoveSelfLink`: 모든 오브젝트와 콜렉션에 대해 `.metadata.selfLink` 필드를 빈 칸(빈 문자열)으로 설정한다.
|
||||
이 필드는 쿠버네티스 v1.16에서 사용 중단되었다.
|
||||
이 기능을 활성화하면, `.metadata.selfLink` 필드는 쿠버네티스 API에 존재하지만,
|
||||
- `RemoveSelfLink`: 모든 오브젝트와 콜렉션에 대해 `.metadata.selfLink` 필드를 빈 칸(빈 문자열)으로 설정한다.
|
||||
이 필드는 쿠버네티스 v1.16에서 사용 중단되었다.
|
||||
이 기능을 활성화하면, `.metadata.selfLink` 필드는 쿠버네티스 API에 존재하지만,
|
||||
항상 빈 칸으로 유지된다.
|
||||
- `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을
|
||||
관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다.
|
||||
|
|
@ -1086,7 +1086,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
[바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
|
||||
참조한다.
|
||||
- `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
|
||||
자세한 내용은
|
||||
자세한 내용은
|
||||
[kubelet 구성](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
|
||||
- `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
|
||||
자세한 사항은
|
||||
|
|
@ -1099,15 +1099,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
스케줄링할 수 있다.
|
||||
- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서
|
||||
_SCTP_ `protocol` 값을 활성화한다.
|
||||
- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로
|
||||
- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로
|
||||
`RuntimeDefault`을 사용한다.
|
||||
seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다.
|
||||
- `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여
|
||||
목록 작업을 가속화할 수 있다.
|
||||
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/)
|
||||
경로를 활성화한다.
|
||||
- `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다.
|
||||
이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라
|
||||
- `ServerSideFieldValidation`: 서버-사이드(server-side) 필드 검증을 활성화한다.
|
||||
이는 리소스 스키마의 검증이 클라이언트 사이드(예: `kubectl create` 또는 `kubectl apply` 명령줄)가 아니라
|
||||
API 서버 사이드에서 수행됨을 의미한다.
|
||||
- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및
|
||||
JWKS URL)를 활성화한다. 자세한 내용은
|
||||
|
|
@ -1116,7 +1116,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다.
|
||||
- `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다.
|
||||
- `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다.
|
||||
- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다.
|
||||
- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다.
|
||||
자세한 내용은
|
||||
[로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다.
|
||||
- `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다.
|
||||
|
|
@ -1127,11 +1127,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
있도록 한다. 자세한 내용은
|
||||
[서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를
|
||||
참고한다.
|
||||
- `ServiceIPStaticSubrange`: ClusterIP 범위를 분할하는
|
||||
서비스 ClusterIP 할당 전략을 활성화한다.
|
||||
ClusterIP 동적 할당을 주로 상위 범위에서 수행하여,
|
||||
사용자가 고정 ClusterIP를 하위 범위에서 할당하는 상황에서도 충돌 확률을 낮출 수 있다.
|
||||
더 자세한 사항은
|
||||
- `ServiceIPStaticSubrange`: ClusterIP 범위를 분할하는
|
||||
서비스 ClusterIP 할당 전략을 활성화한다.
|
||||
ClusterIP 동적 할당을 주로 상위 범위에서 수행하여,
|
||||
사용자가 고정 ClusterIP를 하위 범위에서 할당하는 상황에서도 충돌 확률을 낮출 수 있다.
|
||||
더 자세한 사항은
|
||||
[충돌 방지](/ko/docs/concepts/services-networking/service/#avoiding-collisions)를 참고한다.
|
||||
- `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
|
||||
설정하는 기능을 활성화한다.
|
||||
|
|
@ -1141,7 +1141,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
- `StartupProbe`: kubelet에서
|
||||
[스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
|
||||
프로브를 활성화한다.
|
||||
- `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를
|
||||
- `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를
|
||||
반영할 수 있다.
|
||||
- `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히
|
||||
사용 중인 경우 삭제를 연기한다.
|
||||
|
|
@ -1219,8 +1219,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면,
|
|||
|
||||
* [사용 중단 정책](/docs/reference/using-api/deprecation-policy/)은 쿠버네티스에 대한
|
||||
기능과 컴포넌트를 제거하는 프로젝트의 접근 방법을 설명한다.
|
||||
* 쿠버네티스 1.24부터, 새로운 베타 API는 기본적으로 활성화되어 있지 않다.
|
||||
베타 기능을 활성화하려면, 연관된 API 리소스도 활성화해야 한다.
|
||||
예를 들어, `storage.k8s.io/v1beta1/csistoragecapacities`와 같은 특정 리소스를 활성화하려면,
|
||||
`--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`를 설정한다.
|
||||
* 쿠버네티스 1.24부터, 새로운 베타 API는 기본적으로 활성화되어 있지 않다.
|
||||
베타 기능을 활성화하려면, 연관된 API 리소스도 활성화해야 한다.
|
||||
예를 들어, `storage.k8s.io/v1beta1/csistoragecapacities`와 같은 특정 리소스를 활성화하려면,
|
||||
`--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`를 설정한다.
|
||||
명령줄 플래그에 대한 상세 사항은 [API 버전 규칙](/ko/docs/reference/using-api/#api-버전-규칙)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -19,9 +19,9 @@ API를 이용한 축출은 [축출 API](/docs/reference/generated/kubernetes-api
|
|||
축출 API를 직접 호출해 축출 요청을 할 수 있다.
|
||||
`Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다.
|
||||
|
||||
API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및
|
||||
API를 이용한 축출은 사용자가 설정한 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및
|
||||
[`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) 값을 준수한다.
|
||||
|
||||
API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다.
|
||||
API를 이용한 축출은 [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 동일하지 않다.
|
||||
|
||||
* 더 많은 정보는 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -4,15 +4,18 @@ id: Extensions
|
|||
date: 2019-02-01
|
||||
full_link: /ko/docs/concepts/extend-kubernetes/#익스텐션
|
||||
short_description: >
|
||||
익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
익스텐션은 새로운 종류의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고
|
||||
깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- extension
|
||||
---
|
||||
익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
익스텐션은 새로운 종류의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 또한 익스텐션을 새로 만들어야 하는 사용자는 거의 없을 것이다.
|
||||
많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다.
|
||||
이러한 클러스터는 익스텐션이 미리 설치되어 제공된다.
|
||||
그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 익스텐션을 새로 만들어야 하는 사용자 역시 거의 없을 것이다.
|
||||
|
|
|
|||
|
|
@ -4,19 +4,24 @@ id: garbage-collection
|
|||
date: 2022-01-14
|
||||
full_link: /ko/docs/concepts/architecture/garbage-collection/
|
||||
short_description: >
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는
|
||||
다양한 방법을 종합한 용어이다.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는 다양한 방법을 종합한 용어이다.
|
||||
|
||||
쿠버네티스가 클러스터 자원을 정리하기 위해 사용하는
|
||||
다양한 방법을 종합한 용어이다.
|
||||
|
||||
<!--more-->
|
||||
|
||||
쿠버네티스는 [사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images),
|
||||
쿠버네티스는 가비지 수집을 이용하여
|
||||
[사용되지 않는 컨테이너와 이미지](/ko/docs/concepts/architecture/garbage-collection/#containers-images),
|
||||
[실패한 파드](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[타겟 리소스가 소유한 오브젝트](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[종료된 잡](/ko/docs/concepts/workloads/controllers/ttlafterfinished/), 그리고
|
||||
만료되거나 실패한 리소스를 정리하기 위해 가비지 수집을 사용한다.
|
||||
만료되거나 실패한 리소스 같은 리소스를 정리한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: kubectl 치트 시트
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - krousey
|
||||
# - clove
|
||||
content_type: concept
|
||||
weight: 10 # highlight it
|
||||
card:
|
||||
|
|
@ -68,6 +68,11 @@ kubectl config get-contexts # 컨텍스트 리스트
|
|||
kubectl config current-context # 현재 컨텍스트 출력
|
||||
kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정
|
||||
|
||||
kubectl config set-cluster my-cluster-name # kubeconfig에 클러스터 엔트리를 설정
|
||||
|
||||
# kubeconfig에 이 클라이언트가 발생시킨 요청에 사용할 프록시 서버의 URL을 구성한다.
|
||||
kubectl config set-cluster my-cluster-name --proxy-url=my-proxy-url
|
||||
|
||||
# 기본 인증을 지원하는 새로운 사용자를 kubeconf에 추가한다
|
||||
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
|
||||
|
||||
|
|
@ -182,6 +187,9 @@ kubectl get pods --selector=app=cassandra -o \
|
|||
kubectl get configmap myconfig \
|
||||
-o jsonpath='{.data.ca\.crt}'
|
||||
|
||||
# 밑줄(`_`) 대신 대시(`-`)를 사용하여 base64 인코딩된 값을 조회
|
||||
kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'
|
||||
|
||||
# 모든 워커 노드 조회 (셀렉터를 사용하여 'node-role.kubernetes.io/control-plane'
|
||||
# 으로 명명된 라벨의 결과를 제외)
|
||||
kubectl get node --selector='!node-role.kubernetes.io/control-plane'
|
||||
|
|
|
|||
|
|
@ -107,11 +107,11 @@ Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블
|
|||
|
||||
적용 대상: 네임스페이스
|
||||
|
||||
({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인)
|
||||
쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다.
|
||||
({{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 일부인)
|
||||
쿠버네티스 API 서버가 이 레이블을 모든 네임스페이스에 설정한다.
|
||||
레이블의 값은 네임스페이스의 이름으로 적용된다. 이 레이블의 값을 변경할 수는 없다.
|
||||
|
||||
레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면
|
||||
레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면
|
||||
이 레이블이 유용할 수 있다.
|
||||
|
||||
## beta.kubernetes.io/arch (사용 중단됨)
|
||||
|
|
@ -165,7 +165,7 @@ kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `k
|
|||
|
||||
적용 대상: 파드
|
||||
|
||||
이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을
|
||||
이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을
|
||||
설정하기 위해 사용한다. 명시된 값은 `int32` 타입으로 파싱된다.
|
||||
|
||||
### kubernetes.io/ingress-bandwidth
|
||||
|
|
@ -180,7 +180,7 @@ Example: `kubernetes.io/ingress-bandwidth: 10M`
|
|||
|
||||
적용 대상: 파드
|
||||
|
||||
파드에 QoS(quality-of-service)를 적용함으로써 가용한 대역폭을 효과적으로 제한할 수 있다.
|
||||
파드에 QoS(quality-of-service)를 적용함으로써 가용한 대역폭을 효과적으로 제한할 수 있다.
|
||||
인그레스 트래픽(파드로 향하는)은 효과적으로 데이터를 처리하기 위해 대기 중인 패킷을 큐로 관리한다.
|
||||
파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고
|
||||
`kubernetes.io/ingress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 인그레스 속도를 명시할 때 사용되는 단위는
|
||||
|
|
@ -199,7 +199,7 @@ Example: `kubernetes.io/ingress-bandwidth: 10M`
|
|||
|
||||
적용 대상: 파드
|
||||
|
||||
이그레스 트래픽(파드로부터의)은 설정된 속도를 초과하는 패킷을 삭제하는 정책에 의해 처리되며,
|
||||
이그레스 트래픽(파드로부터의)은 설정된 속도를 초과하는 패킷을 삭제하는 정책에 의해 처리되며,
|
||||
파드에 거는 제한은 다른 파드의 대역폭에 영향을 주지 않는다.
|
||||
파드의 대역폭을 제한하기 위해서는, 오브젝트를 정의하는 JSON 파일을 작성하고
|
||||
`kubernetes.io/egress-bandwidth` 어노테이션을 통해 데이터 트래픽의 속도를 명시한다. 이그레스 속도를 명시할 때 사용되는 단위는
|
||||
|
|
@ -216,9 +216,9 @@ Example: `kubernetes.io/ingress-bandwidth: 10M`
|
|||
|
||||
적용 대상: 노드
|
||||
|
||||
`클라우드 제공자`에 의해 정의된 인스턴스 타입의 값을 kubelet이 읽어서 이 레이블의 값으로 채운다.
|
||||
`클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다.
|
||||
특정 워크로드를 특정 인스턴스 타입에 할당하고 싶다면 이 레이블이 유용할 수 있다.
|
||||
`클라우드 제공자`에 의해 정의된 인스턴스 타입의 값을 kubelet이 읽어서 이 레이블의 값으로 채운다.
|
||||
`클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다.
|
||||
특정 워크로드를 특정 인스턴스 타입에 할당하고 싶다면 이 레이블이 유용할 수 있다.
|
||||
하지만 일반적으로는 자원 기반 스케줄링을 수행하는 쿠버네티스 스케줄러를 이용하게 된다. 인스턴스 타입 보다는 특성을 기준으로 스케줄링을 고려해야 한다(예: `g2.2xlarge` 를 요구하기보다는, GPU가 필요하다고 요구한다).
|
||||
|
||||
## failure-domain.beta.kubernetes.io/region (사용 중단됨) {#failure-domainbetakubernetesioregion}
|
||||
|
|
@ -239,10 +239,10 @@ Example: `kubernetes.io/ingress-bandwidth: 10M`
|
|||
|
||||
`statefulset.kubernetes.io/pod-name=mystatefulset-7`
|
||||
|
||||
스테이트풀셋(StatefulSet) 컨트롤러가 파드를 위한 스테이트풀셋을 생성하면, 컨트롤 플레인이 파드에 이 레이블을 설정한다.
|
||||
스테이트풀셋(StatefulSet) 컨트롤러가 파드를 위한 스테이트풀셋을 생성하면, 컨트롤 플레인이 파드에 이 레이블을 설정한다.
|
||||
생성되는 파드의 이름을 이 레이블의 값으로 설정한다.
|
||||
|
||||
스테이트풀셋 문서의 [파드 이름 레이블](/ko/docs/concepts/workloads/controllers/statefulset/#파드-이름-레이블)에서
|
||||
스테이트풀셋 문서의 [파드 이름 레이블](/ko/docs/concepts/workloads/controllers/statefulset/#파드-이름-레이블)에서
|
||||
상세 사항을 확인한다.
|
||||
|
||||
## topology.kubernetes.io/region {#topologykubernetesioregion}
|
||||
|
|
@ -281,7 +281,7 @@ _SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클
|
|||
|
||||
스케줄러도 (_VolumeZonePredicate_ 표시자를 이용하여) '파드가 요청하는 볼륨'이 위치하는 영역과 같은 영역에 파드를 배치한다. 여러 영역에서 볼륨에 접근할 수는 없다.
|
||||
|
||||
`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다.
|
||||
`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다.
|
||||
`PersistentVolumeLabel`이 설정되어 있으면, 스케줄러는 파드가 다른 영역에 있는 볼륨에 마운트하는 것을 막는다. 만약 사용 중인 인프라에 이러한 제약이 없다면, 볼륨에 영역 레이블을 추가할 필요가 전혀 없다.
|
||||
|
||||
## volume.beta.kubernetes.io/storage-provisioner (사용 중단됨)
|
||||
|
|
@ -340,7 +340,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo
|
|||
|
||||
Used on: 시크릿(Secret)
|
||||
|
||||
이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는
|
||||
이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는
|
||||
서비스어카운트의 {{< glossary_tooltip term_id="name" text="이름">}}을 기록한다.
|
||||
|
||||
### kubernetes.io/service-account.uid
|
||||
|
|
@ -349,7 +349,7 @@ Used on: 시크릿(Secret)
|
|||
|
||||
적용 대상: 시크릿
|
||||
|
||||
이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는
|
||||
이 어노테이션에는 토큰(`kubernetes.io/service-account-token` 타입의 시크릿에 저장되는)이 나타내는
|
||||
서비스어카운트의 {{< glossary_tooltip term_id="uid" text="고유 ID">}}를 기록한다.
|
||||
|
||||
## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by}
|
||||
|
|
@ -409,7 +409,7 @@ v1.18부터, `spec.ingressClassName`으로 대체되었다.
|
|||
|
||||
적용 대상: 스토리지클래스(StorageClass)
|
||||
|
||||
하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우,
|
||||
하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우,
|
||||
클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임 리소스는 해당 기본 클래스로 할당될 것이다.
|
||||
|
||||
## alpha.kubernetes.io/provided-node-ip
|
||||
|
|
@ -428,7 +428,7 @@ kubelet이 "외부" 클라우드 제공자에 의해 실행되었다면, 명령
|
|||
|
||||
적용 대상: 파드
|
||||
|
||||
kube-controller-manager의 잡(Job) 컨트롤러는
|
||||
kube-controller-manager의 잡(Job) 컨트롤러는
|
||||
`Indexed` [완료 모드](/ko/docs/concepts/workloads/controllers/job/#완료-모드)로 생성된 파드에 이 어노테이션을 추가한다.
|
||||
|
||||
## kubectl.kubernetes.io/default-container
|
||||
|
|
@ -451,7 +451,7 @@ v1.22 이상의 쿠버네티스 클러스터에서, 한 엔드포인트(Endpoint
|
|||
|
||||
적용 대상: 잡
|
||||
|
||||
잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers)
|
||||
잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers)
|
||||
중임을 나타낸다.
|
||||
어노테이션을 수동으로 추가하거나 제거하지 **않는다**.
|
||||
|
||||
|
|
@ -511,7 +511,7 @@ kubelet은 '`/proc/sys/kernel/pid_max`의 크기의 D-값'과 노드에서 쿠
|
|||
|
||||
예시: `node.kubernetes.io/out-of-service:NoExecute`
|
||||
|
||||
사용자는 노드에 테인트를 수동으로 추가함으로써 서비스 중이 아니라고 표시할 수 있다. 만약 `NodeOutOfServiceVolumeDetach`
|
||||
사용자는 노드에 테인트를 수동으로 추가함으로써 서비스 중이 아니라고 표시할 수 있다. 만약 `NodeOutOfServiceVolumeDetach`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 `kube-controller-manager`에 활성화되어 있으며
|
||||
노드가 이 테인트로 인해 서비스 중이 아니라고 표시되어있을 경우, 노드에서 실행되던 매칭되는 톨러레이션이 없는 파드들은 강제로 삭제됨과 동시에 볼륨이 분리된다. 이는 서비스 중이 아닌 노드의 파드들이 다른 노드에서 빠르게 복구될 수 있도록 해준다.
|
||||
|
||||
|
|
@ -540,9 +540,9 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
|
||||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
|
||||
특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는
|
||||
특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는
|
||||
레이블 네임스페이스에 모든 파드의 생성을 금지한다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
|
|
@ -555,7 +555,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
정책의 버전이 결정된다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
|
|
@ -567,9 +567,9 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
|
||||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
|
||||
특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을
|
||||
특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을
|
||||
방지하지 않지만, 해당 파드에 audit 어노테이션을 추가한다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
|
|
@ -582,7 +582,7 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
정책의 버전이 결정된다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
|
|
@ -594,11 +594,11 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
|
||||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
|
||||
`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
|
||||
특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을
|
||||
특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을
|
||||
방지하지는 않지만, 그러한 파드가 생성되면 사용자에게 경고를 반환한다.
|
||||
디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
|
||||
디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
|
||||
객체를 만들거나 업데이트할 때에도 경고가 표시된다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
|
|
@ -611,27 +611,37 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
|
|||
적용 대상: 네임스페이스
|
||||
|
||||
값은 **반드시** `latest`이거나 `v<MAJOR>.<MINOR>` 형식의 유효한 쿠버네티스 버전이어야 한다.
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
|
||||
설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
|
||||
정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
|
||||
객체를 만들거나 업데이트할 때에도 경고가 표시된다.
|
||||
|
||||
더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
|
||||
참고한다.
|
||||
|
||||
### kubernetes.io/psp (사용 중단됨) {#kubernetes-io-psp}
|
||||
|
||||
예시: `kubernetes.io/psp: restricted`
|
||||
|
||||
이 어노테이션은 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/)를 사용하는 경우에만 관련있다.
|
||||
|
||||
파드시큐리티폴리시 어드미션 컨트롤러가 파드를 승인하면,
|
||||
어드미션 컨트롤러는 파드가 이 어노테이션을 갖도록 수정한다.
|
||||
이 어노테이션 값은 유효성 검사에서 사용된 파드시큐리티폴리시의 이름이다.
|
||||
|
||||
## seccomp.security.alpha.kubernetes.io/pod (사용 중단됨) {#seccomp-security-alpha-kubernetes-io-pod}
|
||||
|
||||
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
|
||||
파드의 보안 설정을 지정하려면, 파드 스펙에 `securityContext` 필드를 추가한다.
|
||||
파드의 `.spec` 내의 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) 필드는 파드 수준 보안 속성을 정의한다.
|
||||
[파드의 보안 컨텍스트를 설정](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)하면,
|
||||
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
|
||||
파드의 보안 설정을 지정하려면, 파드 스펙에 `securityContext` 필드를 추가한다.
|
||||
파드의 `.spec` 내의 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) 필드는 파드 수준 보안 속성을 정의한다.
|
||||
[파드의 보안 컨텍스트를 설정](/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod)하면,
|
||||
해당 설정이 파드 내의 모든 컨테이너에 적용된다.
|
||||
|
||||
## container.seccomp.security.alpha.kubernetes.io/[이름] {#container-seccomp-security-alpha-kubernetes-io}
|
||||
|
||||
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
|
||||
[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/security/seccomp/) 튜토리얼에서
|
||||
seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다.
|
||||
튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며,
|
||||
이 어노테이션은 쿠버네티스 v1.19부터 사용 중단되었으며 v1.25에서는 작동하지 않을 것이다.
|
||||
[seccomp를 이용하여 컨테이너의 syscall 제한하기](/docs/tutorials/security/seccomp/) 튜토리얼에서
|
||||
seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는 단계를 확인한다.
|
||||
튜토리얼에서는 쿠버네티스에 seccomp를 설정하기 위해 사용할 수 있는 방법을 소개하며,
|
||||
이는 파드의 `.spec` 내에 `securityContext` 를 설정함으로써 가능하다.
|
||||
|
||||
### snapshot.storage.kubernetes.io/allowVolumeModeChange
|
||||
|
|
@ -642,10 +652,10 @@ seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는
|
|||
|
||||
값은 `true` 혹은 `false`만을 받는다.
|
||||
{{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}이
|
||||
볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우,
|
||||
볼륨스냅샷(VolumeSnapshot)으로부터 생성될 경우,
|
||||
사용자가 소스 볼륨의 모드를 수정할 수 있는지 여부를 결정한다.
|
||||
|
||||
자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/docs/concepts/storage/volume-snapshots/#convert-volume-mode)
|
||||
자세한 사항은 [스냅샷의 볼륨 모드 변환하기](/docs/concepts/storage/volume-snapshots/#convert-volume-mode)
|
||||
와 [쿠버네티스 CSI 개발자용 문서](https://kubernetes-csi.github.io/docs/)를 참조한다.
|
||||
|
||||
## Audit을 위한 어노테이션들
|
||||
|
|
@ -669,8 +679,8 @@ seccomp 프로파일을 파드 또는 파드 내 컨테이너에 적용하는
|
|||
|
||||
적용 대상: 노드
|
||||
|
||||
kubeadm `init`/`join`시 주어지는 CRI 소켓 정보를 유지하기 위해 사용하는 어노테이션.
|
||||
kubeadm은 노드 오브젝트를 이 정보를 주석 처리한다. 이상적으로는 KubeletConfiguration의 항목이어야 하기 때문에,
|
||||
kubeadm `init`/`join`시 주어지는 CRI 소켓 정보를 유지하기 위해 사용하는 어노테이션.
|
||||
kubeadm은 노드 오브젝트를 이 정보를 주석 처리한다. 이상적으로는 KubeletConfiguration의 항목이어야 하기 때문에,
|
||||
어노테이션은 "alpha" 상태로 남아있다.
|
||||
|
||||
### kubeadm.kubernetes.io/etcd.advertise-client-urls
|
||||
|
|
@ -688,7 +698,7 @@ etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위
|
|||
|
||||
적용 대상: 파드
|
||||
|
||||
외부로 노출시킬 API 서버의 엔드포인트를 추적하기 위해,
|
||||
외부로 노출시킬 API 서버의 엔드포인트를 추적하기 위해,
|
||||
로컬에서 관리되는 kube-apiserver 파드에 배치되는 어노테이션.
|
||||
|
||||
### kubeadm.kubernetes.io/component-config.hash
|
||||
|
|
@ -697,7 +707,7 @@ etcd 클라이언트들이 접근할 수 있는 URL 목록을 추적하기 위
|
|||
|
||||
적용 대상: 컨피그맵(ConfigMap)
|
||||
|
||||
컴포넌트 설정을 관리하는 컨피그맵에 배치되는 어노테이션.
|
||||
컴포넌트 설정을 관리하는 컨피그맵에 배치되는 어노테이션.
|
||||
사용자가 특정 컴포넌트에 대해서 kubeadm 기본값과 다른 설정값을 적용했는지 판단하기 위한 해시(SHA-256)를 가지고 있다.
|
||||
|
||||
### node-role.kubernetes.io/control-plane
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ weight: 20
|
|||
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
|
||||
|
||||
KubeSchedulerConfiguration ([v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
|
||||
또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/))
|
||||
또는 [v1beta3](/docs/reference/config-api/kube-scheduler-config.v1beta3/))
|
||||
구조에 맞게 파일을 작성하고,
|
||||
`kube-scheduler --config <filename>`을 실행하여
|
||||
스케줄링 프로파일을 지정할 수 있다.
|
||||
|
|
@ -60,7 +60,7 @@ clientConnection:
|
|||
구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로
|
||||
표시된다.
|
||||
1. `postFilter`: 이 플러그인은 파드의 실행 가능한 노드를 찾을 수 없을 때,
|
||||
구성된 순서대로 호출된다. `postFilter` 플러그인이 파드 _schedulable_ 을 표시하는 경우,
|
||||
구성된 순서대로 호출된다. `postFilter` 플러그인이 파드 _schedulable_ 을 표시하는 경우,
|
||||
나머지 플러그인은 호출 되지 않는다.
|
||||
1. `preScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는
|
||||
정보성 익스텐션 포인트이다.
|
||||
|
|
@ -78,7 +78,7 @@ clientConnection:
|
|||
플러그인은 적어도 하나 이상 필요하다.
|
||||
1. `postBind`: 파드가 바인드된 후 호출되는
|
||||
정보성 익스텐션 포인트이다.
|
||||
1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해
|
||||
1. `multiPoint`: 이 필드는 플러그인들의 모든 적용 가능한 익스텐션 포인트에 대해
|
||||
플러그인들을 동시에 활성화하거나 비활성화할 수 있게 하는 환경 설정 전용 필드이다.
|
||||
|
||||
각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나
|
||||
|
|
@ -122,7 +122,7 @@ profiles:
|
|||
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를
|
||||
구현한다.
|
||||
익스텐션 포인트: `filter`, `score`.
|
||||
- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를
|
||||
- `PodTopologySpread`: [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)을
|
||||
구현한다.
|
||||
익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`.
|
||||
- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를
|
||||
|
|
@ -174,7 +174,7 @@ profiles:
|
|||
|
||||
- `SelectorSpread`: {{< glossary_tooltip text="Services" term_id="service" >}},
|
||||
{{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}와
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우,
|
||||
{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우,
|
||||
노드간에 퍼지는 것을 선호한다.
|
||||
익스텐션 포인트: `preScore`, `score`.
|
||||
- `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/)
|
||||
|
|
@ -231,13 +231,13 @@ profiles:
|
|||
|
||||
### 다수의 익스텐션 포인트에 플러그인 적용하기 {#multipoint}
|
||||
|
||||
`kubescheduler.config.k8s.io/v1beta3` 부터,
|
||||
다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나
|
||||
비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다.
|
||||
`kubescheduler.config.k8s.io/v1beta3` 부터,
|
||||
다수의 익스텐션 포인트에 대해 플러그인을 쉽게 활성화하거나
|
||||
비활성화할 수 있게 하는 프로파일 환경 설정 `multiPoint` 가 추가되었다.
|
||||
이를 사용하여 사용자와 관리자가 커스텀 프로파일을 사용할 때 환경 설정을 간소화할 수 있다.
|
||||
|
||||
`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자.
|
||||
모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면,
|
||||
`preScore`, `score`, `preFilter`, `filter` 익스텐션 포인트가 있는 `MyPlugin` 이라는 플러그인이 있다고 가정하자.
|
||||
모든 사용 가능한 익스텐션 포인트에 대해 `MyPlugin` 을 활성화하려면,
|
||||
다음과 같은 프로파일 환경 설정을 사용한다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -251,7 +251,7 @@ profiles:
|
|||
- name: MyPlugin
|
||||
```
|
||||
|
||||
위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과
|
||||
위의 예시는 아래와 같이 모든 익스텐션 포인트에 대해 `MyPlugin` 을 수동으로 활성화하는 것과
|
||||
동일한 효과를 갖는다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -274,13 +274,13 @@ profiles:
|
|||
- name: MyPlugin
|
||||
```
|
||||
|
||||
여기서 `multiPoint` 를 사용했을 때의 이점은,
|
||||
추후 `MyPlugin` 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때,
|
||||
여기서 `multiPoint` 를 사용했을 때의 이점은,
|
||||
추후 `MyPlugin` 이 다른 익스텐션 포인트에 대한 구현을 추가했을 때,
|
||||
새로운 익스텐션에 대해서도 `multiPoint` 환경 설정이 자동으로 활성화될 것이라는 점이다.
|
||||
|
||||
`disabled` 필드를 사용하여, `MultiPoint` 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다.
|
||||
기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나,
|
||||
와일드카드(`'*'`)를 사용하여 모든 플러그인을 비활성화할 수 있다.
|
||||
`disabled` 필드를 사용하여, `MultiPoint` 확장으로부터 특정 익스텐션 포인트를 제외할 수 있다.
|
||||
기본 플러그인을 비활성화하거나, 기본이 아닌(non-default) 플러그인을 비활성화하거나,
|
||||
와일드카드(`'*'`)를 사용하여 모든 플러그인을 비활성화할 수 있다.
|
||||
다음은 `Score` 와 `PreScore` 에 대해 비활성화하는 예시이다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -300,10 +300,10 @@ profiles:
|
|||
- name: '*'
|
||||
```
|
||||
|
||||
`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다.
|
||||
그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다.
|
||||
예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고
|
||||
각각의 가중치가 `1` 이라고 하자.
|
||||
`v1beta3` 에서, `MultiPoint` 필드를 통해 내부적으로 모든 [기본 플러그인](#scheduling-plugins)이 활성화된다.
|
||||
그러나, 개별 익스텐션 포인트에 대해 기본값(예: 순서, Score 가중치)을 유연하게 재설정하는 것도 여전히 가능하다.
|
||||
예를 들어, 2개의 Score 플러그인 `DefaultScore1` 과 `DefaultScore2` 가 있고
|
||||
각각의 가중치가 `1` 이라고 하자.
|
||||
이 때, 다음과 같이 가중치를 다르게 설정하여 순서를 바꿀 수 있다.
|
||||
|
||||
```yaml
|
||||
|
|
@ -318,10 +318,10 @@ profiles:
|
|||
weight: 5
|
||||
```
|
||||
|
||||
이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데,
|
||||
이는 이 플러그인들이 기본 플러그인이기 때문이다.
|
||||
그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다.
|
||||
이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다.
|
||||
이 예제에서, 이 플러그인들을 `MultiPoint` 에 명시할 필요는 없는데,
|
||||
이는 이 플러그인들이 기본 플러그인이기 때문이다.
|
||||
그리고 `Score` 에는 `DefaultScore2` 플러그인만 명시되었다.
|
||||
이는 익스텐션 포인트를 명시하여 설정된 플러그인은 언제나 `MultiPoint` 플러그인보다 우선순위가 높기 때문이다.
|
||||
결론적으로, 위의 예시에서는 두 플러그인을 모두 명시하지 않고도 두 플러그인의 순서를 조정하였다.
|
||||
|
||||
`MultiPoint` 플러그인을 설정할 때, 일반적인 우선 순위는 다음과 같다.
|
||||
|
|
@ -363,8 +363,8 @@ profiles:
|
|||
- name: 'DefaultPlugin2'
|
||||
```
|
||||
|
||||
명시한 익스텐션 포인트 내에 `MultiPoint` 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다.
|
||||
명시한 익스텐션 포인트의 우선 순위가 더 높으므로,
|
||||
명시한 익스텐션 포인트 내에 `MultiPoint` 플러그인을 재정의해도 에러가 발생하지 않음에 유의한다.
|
||||
명시한 익스텐션 포인트의 우선 순위가 더 높으므로,
|
||||
이 재정의는 무시되고 로그에만 기록된다.
|
||||
|
||||
대부분의 환경 설정을 한 곳에서 관리하는 것 말고도, 이 예시는 다음과 같은 내용을 포함한다.
|
||||
|
|
@ -380,14 +380,14 @@ kind: KubeSchedulerConfiguration
|
|||
profiles:
|
||||
- schedulerName: multipoint-scheduler
|
||||
plugins:
|
||||
|
||||
|
||||
# 기본 QueueSort 플러그인을 비활성화한다
|
||||
queueSort:
|
||||
enabled:
|
||||
- name: 'CustomQueueSort'
|
||||
disabled:
|
||||
- name: 'DefaultQueueSort'
|
||||
|
||||
|
||||
# 커스텀 Filter 플러그인을 활성화한다
|
||||
filter:
|
||||
enabled:
|
||||
|
|
@ -396,7 +396,7 @@ profiles:
|
|||
- name: 'DefaultPlugin2'
|
||||
disabled:
|
||||
- name: 'DefaultPlugin1'
|
||||
|
||||
|
||||
# 커스텀 score 플러그인을 활성화하고 순서를 조정한다
|
||||
score:
|
||||
enabled:
|
||||
|
|
@ -406,19 +406,19 @@ profiles:
|
|||
weight: 3
|
||||
```
|
||||
|
||||
다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 `MultiPoint` 환경 설정의 유연성과
|
||||
다소 복잡한 예시를 통해, 익스텐션 포인트를 설정함에 있어서 `MultiPoint` 환경 설정의 유연성과
|
||||
기존 방법과의 끊김없는 통합을 확인할 수 있다.
|
||||
|
||||
## 스케줄러 설정 전환
|
||||
|
||||
{{< tabs name="tab_with_md" >}}
|
||||
{{% tab name="v1beta1 → v1beta2" %}}
|
||||
* 설정 버전 v1beta2 에서는, `NodeResourcesFit` 플러그인을 위한 새로운 스코어링 확장을
|
||||
* 설정 버전 v1beta2 에서는, `NodeResourcesFit` 플러그인을 위한 새로운 스코어링 확장을
|
||||
이용할 수 있다.
|
||||
새 확장은 `NodeResourcesLeastAllocated`, `NodeResourcesMostAllocated`,
|
||||
새 확장은 `NodeResourcesLeastAllocated`, `NodeResourcesMostAllocated`,
|
||||
`RequestedToCapacityRatio` 플러그인의 기능을 통합하여 제공한다.
|
||||
예를 들어, 이전에 `NodeResourcesMostAllocated` 플러그인을 사용했다면,
|
||||
대신 `NodeResourcesFit`(기본적으로 활성화되어 있음)을 사용하면서
|
||||
예를 들어, 이전에 `NodeResourcesMostAllocated` 플러그인을 사용했다면,
|
||||
대신 `NodeResourcesFit`(기본적으로 활성화되어 있음)을 사용하면서
|
||||
다음과 같이 `scoreStrategy`를 포함하는 `pluginConfig`를 추가할 수 있다.
|
||||
```yaml
|
||||
apiVersion: kubescheduler.config.k8s.io/v1beta2
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: API 개요
|
||||
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - erictune
|
||||
# - lavalamp
|
||||
# - jbeda
|
||||
content_type: concept
|
||||
weight: 10
|
||||
no_list: true
|
||||
|
|
@ -39,7 +39,7 @@ JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서
|
|||
동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다.
|
||||
|
||||
API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다.
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/design-proposals-archive/release/versioning.md)에는
|
||||
[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/sig-release/release-engineering/versioning.md)에는
|
||||
API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다.
|
||||
|
||||
API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,8 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - jlowdermilk
|
||||
# - justinsb
|
||||
# - quinton-hoole
|
||||
title: 여러 영역에서 실행
|
||||
weight: 20
|
||||
content_type: concept
|
||||
|
|
@ -58,7 +62,7 @@ content_type: concept
|
|||
[영역 정보](/ko/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다.
|
||||
|
||||
클러스터가 여러 영역 또는 지역에 걸쳐있는 경우,
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과
|
||||
[파드 토폴로지 분배 제약 조건](/ko/docs/concepts/scheduling-eviction/pod-topology-spread-constraints/)과
|
||||
함께 노드 레이블을 사용하여
|
||||
파드가 장애 도메인(지역, 영역, 특정 노드) 간 클러스터에
|
||||
분산되는 방식을 제어할 수 있다.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
# reviewers:
|
||||
# - vincepri
|
||||
# - bart0sh
|
||||
title: 컨테이너 런타임
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -15,13 +15,13 @@ weight: 20
|
|||
설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고
|
||||
노드 설정 관련 작업을 설명한다.
|
||||
|
||||
쿠버네티스 {{< skew currentVersion >}}에서는
|
||||
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는
|
||||
쿠버네티스 {{< skew currentVersion >}}에서는
|
||||
{{< glossary_tooltip term_id="cri" text="컨테이너 런타임 인터페이스">}}(CRI) 요구사항을 만족하는
|
||||
런타임을 사용해야 한다.
|
||||
|
||||
더 자세한 정보는 [CRI 버전 지원](#cri-versions)을 참조한다.
|
||||
|
||||
이 페이지는 쿠버네티스에서
|
||||
이 페이지는 쿠버네티스에서
|
||||
여러 공통 컨테이너 런타임을 사용하는 방법에 대한 개요를 제공한다.
|
||||
|
||||
- [containerd](#containerd)
|
||||
|
|
@ -30,17 +30,17 @@ weight: 20
|
|||
- [미란티스 컨테이너 런타임](#mcr)
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스 v1.24 이전 릴리스는
|
||||
_dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다.
|
||||
이 특별한 직접 통합은
|
||||
더 이상 쿠버네티스에 포함되지 않는다(이 제거는
|
||||
v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다).
|
||||
이 제거가 어떻게 영향을 미치는지 알아보려면
|
||||
[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다.
|
||||
dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면,
|
||||
쿠버네티스 v1.24 이전 릴리스는
|
||||
_dockershim_ 이라는 구성 요소를 사용하여 도커 엔진과의 직접 통합을 지원했다.
|
||||
이 특별한 직접 통합은
|
||||
더 이상 쿠버네티스에 포함되지 않는다(이 제거는
|
||||
v1.20 릴리스의 일부로 [공지](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)되었다).
|
||||
이 제거가 어떻게 영향을 미치는지 알아보려면
|
||||
[dockershim 제거가 영향을 미치는지 확인하기](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) 문서를 확인한다.
|
||||
dockershim을 사용하던 환경에서 이전(migrating)하는 방법을 보려면,
|
||||
[dockershim에서 이전하기](/docs/tasks/administer-cluster/migrating-from-dockershim/)를 확인한다.
|
||||
|
||||
v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면,
|
||||
v{{< skew currentVersion >}} 이외의 쿠버네티스 버전을 사용하고 있다면,
|
||||
해당 버전의 문서를 참고한다.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ sudo sysctl --system
|
|||
|
||||
## cgroup 드라이버
|
||||
|
||||
리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은
|
||||
리눅스에서, {{< glossary_tooltip text="control group" term_id="cgroup" >}}은
|
||||
프로세스에 할당된 리소스를 제한하는데 사용된다.
|
||||
|
||||
리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인
|
||||
|
|
@ -116,7 +116,7 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
|
|||
|
||||
### Cgroup 버전 2 {#cgroup-v2}
|
||||
|
||||
cgroup v2는 cgroup Linux API의 다음 버전이다.
|
||||
cgroup v2는 cgroup Linux API의 다음 버전이다.
|
||||
cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.
|
||||
|
||||
새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다.
|
||||
|
|
@ -125,16 +125,16 @@ cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계
|
|||
- 컨테이너로의 안전한 하위 트리 위임
|
||||
- 압력 중지 정보와 같은 새로운 기능
|
||||
|
||||
일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도,
|
||||
쿠버네티스는 모든 컨트롤러를 관리하기 위해
|
||||
일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도,
|
||||
쿠버네티스는 모든 컨트롤러를 관리하기 위해
|
||||
동일한 cgroup 버전만 지원한다.
|
||||
|
||||
systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을
|
||||
systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을
|
||||
추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.
|
||||
|
||||
```shell
|
||||
# 이 예제는 리눅스 OS에서 DNF 패키지 관리자를 사용하는 경우에 대한 것이다.
|
||||
# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해
|
||||
# 리눅스 커널이 사용하는 커맨드 라인을 설정하기 위해
|
||||
# 사용자의 시스템이 다른 방법을 사용하고 있을 수도 있다.
|
||||
sudo dnf install -y grubby && \
|
||||
sudo grubby \
|
||||
|
|
@ -142,17 +142,17 @@ sudo dnf install -y grubby && \
|
|||
--args="systemd.unified_cgroup_hierarchy=1"
|
||||
```
|
||||
|
||||
커널이 사용하는 커맨드 라인을 업데이트하려면,
|
||||
커널이 사용하는 커맨드 라인을 업데이트하려면,
|
||||
변경 사항을 적용하기 위해 노드를 재시작해야 한다.
|
||||
|
||||
cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서
|
||||
cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서
|
||||
cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.
|
||||
|
||||
cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다.
|
||||
|
||||
### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
|
||||
|
||||
기존에 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면,
|
||||
기존에 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면,
|
||||
[cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다.
|
||||
|
||||
## CRI 버전 지원 {#cri-versions}
|
||||
|
|
@ -160,7 +160,7 @@ cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야
|
|||
사용할 컨테이너 런타임이 적어도 CRI의 v1alpha2 이상을 지원해야 한다.
|
||||
|
||||
쿠버네티스 {{< skew currentVersion >}} 버전에서는 기본적으로 CRI API 중 v1을 사용한다.
|
||||
컨테이너 런타임이 v1 API를 지원하지 않으면,
|
||||
컨테이너 런타임이 v1 API를 지원하지 않으면,
|
||||
kubelet은 대신 (사용 중단된) v1alpha2 API를 사용하도록 설정된다.
|
||||
|
||||
## 컨테이너 런타임
|
||||
|
|
@ -217,7 +217,7 @@ kubeadm을 사용하는 경우,
|
|||
|
||||
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-containerd}
|
||||
|
||||
[containerd 설정](https://github.com/containerd/cri/blob/master/docs/config.md)에서
|
||||
[containerd 설정](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)에서
|
||||
아래와 같이 샌드박스 이미지를 덮어쓸 수 있다.
|
||||
|
||||
```toml
|
||||
|
|
@ -235,9 +235,9 @@ CRI-O를 설치하려면, [CRI-O 설치 방법](https://github.com/cri-o/cri-o/b
|
|||
|
||||
#### cgroup 드라이버
|
||||
|
||||
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용하며, 이는 대부분의 경우에 잘 동작할 것이다.
|
||||
`cgroupfs` cgroup 드라이버로 전환하려면, `/etc/crio/crio.conf` 를 수정하거나
|
||||
`/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 드롭-인(drop-in) 구성을 배치한다.
|
||||
CRI-O는 기본적으로 systemd cgroup 드라이버를 사용하며, 이는 대부분의 경우에 잘 동작할 것이다.
|
||||
`cgroupfs` cgroup 드라이버로 전환하려면, `/etc/crio/crio.conf` 를 수정하거나
|
||||
`/etc/crio/crio.conf.d/02-cgroup-manager.conf` 에 드롭-인(drop-in) 구성을 배치한다.
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
```toml
|
||||
|
|
@ -269,46 +269,46 @@ live configuration reload 기능을 지원한다.
|
|||
### 도커 엔진 {#docker}
|
||||
|
||||
{{< note >}}
|
||||
아래의 지침은
|
||||
당신이 도커 엔진과 쿠버네티스를 통합하는 데
|
||||
아래의 지침은
|
||||
당신이 도커 엔진과 쿠버네티스를 통합하는 데
|
||||
[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 어댑터를 사용하고 있다고 가정한다.
|
||||
{{< /note >}}
|
||||
|
||||
1. 각 노드에서, [도커 엔진 설치하기](https://docs.docker.com/engine/install/#server)에 따라
|
||||
1. 각 노드에서, [도커 엔진 설치하기](https://docs.docker.com/engine/install/#server)에 따라
|
||||
리눅스 배포판에 맞게 도커를 설치한다.
|
||||
|
||||
2. [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 소스 코드 저장소의 지침대로
|
||||
2. [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 소스 코드 저장소의 지침대로
|
||||
`cri-dockerd`를 설치한다.
|
||||
|
||||
`cri-dockerd`의 경우, CRI 소켓은 기본적으로 `/run/cri-dockerd.sock`이다.
|
||||
|
||||
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd}
|
||||
|
||||
`cri-dockerd` 어댑터는,
|
||||
`cri-dockerd` 어댑터는,
|
||||
파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
|
||||
해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
|
||||
|
||||
### 미란티스 컨테이너 런타임 {#mcr}
|
||||
|
||||
[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며
|
||||
[미란티스 컨테이너 런타임](https://docs.mirantis.com/mcr/20.10/overview.html)(MCR)은 상용 컨테이너 런타임이며
|
||||
이전에는 도커 엔터프라이즈 에디션으로 알려져 있었다.
|
||||
|
||||
오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며,
|
||||
오픈소스인 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd) 컴포넌트를 이용하여 쿠버네티스에서 미란티스 컨테이너 런타임을 사용할 수 있으며,
|
||||
이 컴포넌트는 MCR에 포함되어 있다.
|
||||
|
||||
미란티스 컨테이너 런타임을 설치하는 방법에 대해 더 알아보려면,
|
||||
미란티스 컨테이너 런타임을 설치하는 방법에 대해 더 알아보려면,
|
||||
[MCR 배포 가이드](https://docs.mirantis.com/mcr/20.10/install.html)를 참고한다.
|
||||
|
||||
CRI 소켓의 경로를 찾으려면
|
||||
CRI 소켓의 경로를 찾으려면
|
||||
`cri-docker.socket`라는 이름의 systemd 유닛을 확인한다.
|
||||
|
||||
#### 샌드박스(pause) 이미지 덮어쓰기 {#override-pause-image-cri-dockerd-mcr}
|
||||
|
||||
`cri-dockerd` 어댑터는,
|
||||
`cri-dockerd` 어댑터는,
|
||||
파드 인프라 컨테이너("pause image")를 위해 어떤 컨테이너 이미지를 사용할지 명시하는 커맨드라인 인자를 받는다.
|
||||
해당 커맨드라인 인자는 `--pod-infra-container-image`이다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
컨테이너 런타임과 더불어, 클러스터에는
|
||||
컨테이너 런타임과 더불어, 클러스터에는
|
||||
동작하는 [네트워크 플러그인](/ko/docs/concepts/cluster-administration/networking/#쿠버네티스-네트워크-모델의-구현-방법)도 필요하다.
|
||||
|
|
|
|||
|
|
@ -8,18 +8,23 @@ weight: 30
|
|||
|
||||
이 가이드는 [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 이용하여 GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal(전 Packet), Oracle Cloud infrastructure(실험적) 또는 베어메탈 등에서 운영되는 쿠버네티스 클러스터를 설치하는 과정을 보여준다.
|
||||
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md#inventory), 프로비저닝 도구와 일반적인 운영체제, 쿠버네티스 클러스터의 설정 관리 작업에 대한 도메인 지식의 결합으로 만들어졌다. Kubespray는 아래와 같은 기능을 제공한다.
|
||||
|
||||
Kubespray 지원 사항
|
||||
* 고가용성을 지닌 클러스터
|
||||
* 구성할 수 있는 속성들
|
||||
* 구성 가능 (인스턴스를 위한 네트워크 플러그인 선택)
|
||||
* 대부분의 인기있는 리눅스 배포판들에 대한 지원
|
||||
* Ubuntu 16.04, 18.04, 20.04, 22.04
|
||||
* CentOS/RHEL/Oracle Linux 7, 8
|
||||
* Debian Buster, Jessie, Stretch, Wheezy
|
||||
* Fedora 34, 35
|
||||
* Fedora CoreOS
|
||||
* openSUSE Leap 15
|
||||
* Flatcar Container Linux by Kinvolk
|
||||
- Flatcar Container Linux by Kinvolk
|
||||
- Debian Bullseye, Buster, Jessie, Stretch
|
||||
- Ubuntu 16.04, 18.04, 20.04, 22.04
|
||||
- CentOS/RHEL 7, 8
|
||||
- Fedora 34, 35
|
||||
- Fedora CoreOS
|
||||
- openSUSE Leap 15.x/Tumbleweed
|
||||
- Oracle Linux 7, 8
|
||||
- Alma Linux 8
|
||||
- Rocky Linux 8
|
||||
- Amazon Linux 2
|
||||
* 지속적인 통합 (CI) 테스트
|
||||
|
||||
클러스터를 설치해 줄 도구로 유스케이스와 가장 잘 맞는 것을 고르고 싶다면, kubespray를 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/)와 [비교한 글](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/comparisons.md)을 읽어보자.
|
||||
|
|
@ -33,13 +38,13 @@ Kubespray는 [Ansible](https://docs.ansible.com/) 플레이북, [인벤토리](h
|
|||
|
||||
언더레이(underlay) [요건](https://github.com/kubernetes-sigs/kubespray#requirements)을 만족하는 프로비전 한다.
|
||||
|
||||
* **Ansible의 명령어를 실행하기 위해 Ansible v 2.11와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**
|
||||
* **Ansible 플레이북을 실행하기 위해 2.11 (혹은 그 이상) 버전의 Jinja가 필요하다**
|
||||
* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 인터넷에 접속할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다
|
||||
* **SSH 키**가 인벤토리의 모든 서버들에 복사되어야 한다
|
||||
* **방화벽은 kubespray에 의해 관리되지 않는다**. 사용자는 필요에 따라 적절한 규칙을 구현해야 한다. 디플로이먼트 과정에서의 문제를 방지하려면 방화벽을 비활성화해야 한다
|
||||
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 확대 방법이 설정되어야 하며, `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
|
||||
* **쿠버네티스는 최소한 v1.22 이상의 버전이 필요하다.**
|
||||
* **Ansible의 명령어를 실행하기 위해 Ansible v2.11+, Jinja 2.11+와 Python netaddr 라이브러리가 머신에 설치되어 있어야 한다**.
|
||||
* 타겟 서버들은 docker 이미지를 풀(pull) 하기 위해 반드시 **인터넷에 접속**할 수 있어야 한다. 아니라면, 추가적인 설정을 해야 한다 ([오프라인 환경 확인하기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
|
||||
* 타겟 서버들의 **IPv4 포워딩**이 활성화되어야 한다.
|
||||
* 파드와 서비스에서 IPv6를 이용한다면, 대상 서버도 **IPv6 포워딩**이 활성화되어야 한다.
|
||||
* **방화벽은 kubespray가 관리하지 않는다**. 사용자는 기존 방식으로 자신의 규칙을 구현해야 한다. 배포 중에 만날 문제를 예방하려면 방화벽을 비활성화해야 한다.
|
||||
* 만약 kubespray가 루트가 아닌 사용자 계정에서 실행되었다면, 타겟 서버에서 알맞은 권한 상승 방법이 설정되어야 한다. 그 후에 `ansible_become` 플래그나 커맨드 파라미터들, `--become` 또는 `-b` 가 명시되어야 한다
|
||||
|
||||
Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 서비스를 제공한다:
|
||||
|
||||
|
|
@ -115,5 +120,5 @@ reset 플레이북을 실행할 때, 실수로 프로덕션 클러스터를 타
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
|
||||
* Kubespray의 [로드맵](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/roadmap.md)에서 계획중인 작업을 확인해보자.
|
||||
* [Kubespray](https://github.com/kubernetes-sigs/kubespray)를 더 알아보자.
|
||||
|
|
|
|||
Loading…
Reference in New Issue