diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 0fa8d8658ae1e..9666cd4a14559 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -12,8 +12,8 @@

-

사용자, 기여자, 그리고 우리가 함께 구축한 문화로 구성된 쿠버네티스 커뮤니티는 이 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장 하고 변화함에 따라 우리의 문화와 가치관이 계속 성장하고 변화하고 있습니다. 우리 모두는 프로젝트의 지속적인 개선과 작업 방식을 위해 함께 노력합니다. -

우리는 이슈를 제기하고 풀 리퀘스트하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고 채택과 혁신을 옹호하며, kubectl get pods 을 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 여러분이 어떻게 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.

+

사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는 본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장하고 변화함에 따라 우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다. 우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다. +

우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고, 도입(adoption)과 혁신(innovation)을 지지하며, kubectl get pods 를 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.


diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 3ab89472d80b0..5daed120777ef 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -392,6 +392,49 @@ Message: Node is shutting, evicting pods 이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다. {{< /note >}} +## 스왑(swap) 메모리 관리 {#swap-memory} + +{{< feature-state state="alpha" for_k8s_version="v1.22" >}} + +쿠버네티스 1.22 이전에는 노드가 스왑 메모리를 지원하지 않았다. 그리고 +kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 실패하도록 되어 있었다. +1.22부터는 스왑 메모리 지원을 노드 단위로 활성화할 수 있다. + +노드에서 스왑을 활성화하려면, `NodeSwap` 기능 게이트가 kubelet에서 +활성화되어야 하며, 명령줄 플래그 `--fail-swap-on` 또는 +[구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가 +false로 지정되어야 한다. + +사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며, +이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면, + +```yaml +memorySwap: + swapBehavior: LimitedSwap +``` + +`swapBehavior`에 가용한 구성 옵션은 다음과 같다. + +- `LimitedSwap`: 쿠버네티스 워크로드는 스왑을 사용할 수 있는 만큼으로 + 제한된다. 쿠버네티스에 의해 관리되지 않는 노드의 워크로드는 여전히 스왑될 수 있다. +- `UnlimitedSwap`: 쿠버네티스 워크로드는 요청한 만큼 스왑 메모리를 사용할 수 있으며, + 시스템의 최대치까지 사용 가능하다. + +만약 `memorySwap` 구성이 명시되지 않았고 기능 게이트가 활성화되어 있다면, +kubelet은 `LimitedSwap` 설정과 같은 행동을 +기본적으로 적용한다. + +`LimitedSwap` 설정에 대한 행동은 노드가 ("cgroups"으로 알려진) +제어 그룹이 v1 또는 v2 중에서 무엇으로 동작하는가에 따라서 결정된다. + +- **cgroupsv1:** 쿠버네티스 워크로드는 메모리와 스왑의 조합을 사용할 수 있다. + 파드의 메모리 제한이 설정되어 있다면 가용 상한이 된다. +- **cgroupsv2:** 쿠버네티스 워크로드는 스왑 메모리를 사용할 수 없다. + +테스트를 지원하고 피드벡을 제공하기 위한 정보는 +[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 및 +[디자인 제안](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)에서 찾을 수 있다. + ## {{% heading "whatsnext" %}} * 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다. diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index c64dd127b3700..6db0871e48898 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -6,6 +6,18 @@ weight: 70 + +{{< note >}} +이 한글 문서는 더 이상 관리되지 않습니다. + +이 문서의 기반이 된 영어 원문은 삭제되었으며, +[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다. + +[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면, +이 문서는 삭제될 수 있습니다. +{{< /note >}} + + 가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index d4e0119c41836..5ae2aafffd0ae 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -80,7 +80,7 @@ kubectl logs counter 로테이션하도록 컨테이너 런타임을 설정할 수도 있다. 예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은 -[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해 +[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해 자세히 알 수 있다. **CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index 7e3093d51e5e7..553ce005a97b5 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -160,7 +160,7 @@ persistentvolumeclaim/my-pvc created 지금까지 사용한 예는 모든 리소스에 최대 한 개의 레이블만 적용하는 것이었다. 세트를 서로 구별하기 위해 여러 레이블을 사용해야 하는 많은 시나리오가 있다. -예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다. +예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다. ```yaml labels: diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 17fd61c6a667d..f89d873a37367 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -21,7 +21,7 @@ weight: 10 - JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다. -- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다. +- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다. - 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다. @@ -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/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다. +- `{ 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/) 앱을 참고한다. 릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다. diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 06be7d5a541be..330e89edac9a6 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -12,26 +12,33 @@ weight: 30 -쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은 -민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이 -{{< glossary_tooltip term_id="pod" >}} 정의나 -{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} -내에 그대로 두는 것보다 안전하고 유연하다. -자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다. - 시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 -포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드 -명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도 -일부 시크릿을 만들 수 있다. +포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}} +명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에 +포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를 +애플리케이션 코드에 넣을 필요가 +없음을 뜻한다. + +시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에, +파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이 +노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스 +및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성 +저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다. + +시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만 +특별히 기밀 데이터를 보관하기 위한 것이다. {{< caution >}} -쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다. -기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에 -액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다. -시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다. +쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. +또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다. + +시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다. 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/). -2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다. +2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/) + 활성화 또는 구성. +3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다. + {{< /caution >}} @@ -47,6 +54,10 @@ weight: 30 - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용. - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용. +쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어, +[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은 +노드 등록을 자동화하는 데 도움을 주는 메커니즘이다. + 시크릿 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를 @@ -1236,7 +1247,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다. API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는 시크릿을 노출하는 파드를 실행할 수 있다. - ## {{% heading "whatsnext" %}} - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기 diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 58c106fdceb4e..749eb6fbb866d 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> FOO_SERVICE_PORT=<서비스가 동작 중인 포트> ``` -서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. +서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 886f8247a3d3e..9a22f2f3e5ef8 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -1,4 +1,7 @@ --- + + + title: 이미지 content_type: concept weight: 10 @@ -16,9 +19,6 @@ weight: 10 이 페이지는 컨테이너 이미지 개념의 개요를 제공한다. - - - ## 이미지 이름 @@ -210,10 +210,6 @@ kubectl describe pods/private-image-test-1 | grep 'Failed' ### 미리 내려받은 이미지 -{{< note >}} -Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다. -{{< /note >}} - {{< note >}} 이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은 클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로 @@ -334,4 +330,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config. ## {{% heading "whatsnext" %}} -* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기 +* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기. +* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기. diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 953571ec628e4..a2142521cd82c 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -1,4 +1,7 @@ --- + + + title: 런타임클래스(RuntimeClass) content_type: concept weight: 20 @@ -115,7 +118,7 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다. 유효한 핸들러는 runtimes 단락 아래에서 설정한다. ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` 더 자세한 containerd의 구성 문서를 살펴본다. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 13313adf581a1..9d4ad5525c082 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -197,31 +197,39 @@ service PodResourcesLister { } ``` -`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID, -이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께 -실행 중인 파드의 리소스에 대한 정보를 제공한다. +`List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며, +독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID, +이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다. ```gRPC -// ListPodResourcesResponse는 List 함수가 반환하는 응답이다 +// ListPodResourcesResponse는 List 함수가 반환하는 응답이다. message ListPodResourcesResponse { repeated PodResources pod_resources = 1; } -// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다 +// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다. message PodResources { string name = 1; string namespace = 2; repeated ContainerResources containers = 3; } -// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다 +// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다. message ContainerResources { string name = 1; repeated ContainerDevices devices = 2; repeated int64 cpu_ids = 3; + repeated ContainerMemory memory = 4; } -// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다 +// ContainerMemory는 컨테이너에 할당된 메모리와 hugepage에 대한 정보를 포함한다. +message ContainerMemory { + string memory_type = 1; + uint64 size = 2; + TopologyInfo topology = 3; +} + +// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다. message TopologyInfo { repeated NUMANode nodes = 1; } @@ -231,7 +239,7 @@ message NUMANode { int64 ID = 1; } -// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다 +// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다. message ContainerDevices { string resource_name = 1; repeated string device_ids = 2; @@ -247,6 +255,7 @@ kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다 message AllocatableResourcesResponse { repeated ContainerDevices devices = 1; repeated int64 cpu_ids = 2; + repeated ContainerMemory memory = 3; } ``` diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 5d2ef83d768c7..2b6809782d62a 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -45,7 +45,7 @@ sitemap: * 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임. * 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다. * 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다. -* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. +* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. * 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다. * 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다. * 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index 245da33db3389..89334978c0dc9 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -30,6 +30,11 @@ weight: 50 } ``` +{{}} +맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자, +불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다. +{{}} + 다음은 어노테이션에 기록할 수 있는 정보의 예제이다. * 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은 diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index 0583ae0fe3fba..571c62b7db47a 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -42,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이 * `"partition" : "customerA"`, `"partition" : "customerB"` * `"track" : "daily"`, `"track" : "weekly"` -이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다. +이 예시는 [일반적으로 사용하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다. ## 구문과 캐릭터 셋 @@ -50,15 +50,13 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시 접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다. -`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다. +`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다. 유효한 레이블 값은 다음과 같다. * 63 자 이하여야 하고 (공백일 수도 있음), * (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, * 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다. -유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. - 다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다. ```yaml diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 78b7addd43c02..69afaa0069890 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -1,4 +1,7 @@ --- + + + title: 오브젝트 이름과 ID content_type: concept weight: 20 @@ -25,7 +28,7 @@ weight: 20 물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다. {{< /note >}} -다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다. +다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다. ### DNS 서브도메인 이름 @@ -38,7 +41,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. - 영숫자로 시작한다. - 영숫자로 끝난다. -### DNS 레이블 이름 +### RFC 1123 레이블 이름 {#dns-label-names} 일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로 DNS 레이블 표준을 따라야 한다. @@ -49,6 +52,17 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. - 영숫자로 시작한다. - 영숫자로 끝난다. +### RFC 1035 레이블 이름 + +몇몇 리소스 타입은 자신의 이름을 [RFC 1035](https://tools.ietf.org/html/rfc1035)에 +정의된 DNS 레이블 표준을 따르도록 요구한다. +이것은 이름이 다음을 만족해야 한다는 의미이다. + +- 최대 63개 문자를 포함 +- 소문자 영숫자 또는 '-'만 포함 +- 알파벳 문자로 시작 +- 영숫자로 끝남 + ### 경로 세그먼트 이름 일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수 diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index b5254e4300b09..b7cb48b23e81e 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -442,7 +442,7 @@ pods 0 10 ### 네임스페이스 간 파드 어피니티 쿼터 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} 오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를 제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의 @@ -493,9 +493,9 @@ plugins: 해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만 파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다. -이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 +이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) -`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다. +`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다. ## 요청과 제한의 비교 {#requests-vs-limits} diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index f46e075b5733a..1e6a007cdf3e6 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -271,16 +271,16 @@ PodSpec에 지정된 NodeAffinity도 적용된다. 연관된 `matchExpressions` 가 모두 충족되어야 한다. #### 네임스페이스 셀렉터 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} 사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. 어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다. 빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과 null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다. -이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 +이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) -`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다. +`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다. #### 더 실용적인 유스케이스 diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 8c17269a64c1a..5b0a1648c3438 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 -* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기 +* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index f14929088289c..6df4ec16b4719 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -1,4 +1,7 @@ --- + + + title: 파드 우선순위(priority)와 선점(preemption) content_type: concept weight: 70 @@ -350,21 +353,25 @@ spec: `PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를 축출 대상으로 고려한다. -QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는 -[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다. -kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라, -파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해 -먼저 축출 대상 파드의 순위를 매긴다. -더 자세한 내용은 -[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을 +kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/) 순서를 결정한다. +사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지 +예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다. + + 1. 부족한 리소스 사용량이 요청을 초과하는지 여부 + 1. 파드 우선순위 + 1. 요청 대비 리소스 사용량 + +더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을 참조한다. -kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우 +kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우 파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을 초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가 더 높은 다른 파드가 축출될 수 있다. - ## {{% heading "whatsnext" %}} -* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. +* 프라이어리티클래스와 함께 리소스쿼터 사용에 대해 읽기: [기본으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한) +* [파드 중단(disruption)](/ko/docs/concepts/workloads/pods/disruptions/)에 대해 학습한다. +* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)에 대해 학습한다. +* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 학습한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 6be3e204c882f..e2fb1cdcf9180 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 마치 100을 설정한 것처럼 작동한다. 값을 변경하려면, -[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을 +[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을 편집한 다음 스케줄러를 재시작한다. 대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다. @@ -161,4 +161,4 @@ percentageOfNodesToScore: 50 ## {{% heading "whatsnext" %}} -* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인 +* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인 diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index c47f5f995b58b..f6d8c13a19707 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -264,10 +264,10 @@ tolerations: 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다. -## 컨디션을 기준으로 노드 테인트하기 +## 조건(condition)을 기준으로 노드 테인트하기 컨트롤 플레인은 노드 {{}}를 이용하여 -[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. +[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. 스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. 이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다. @@ -298,5 +298,5 @@ tolerations: ## {{% heading "whatsnext" %}} -* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기 +* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기 * [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 64ed2675b2d86..47d0548a7ecff 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -1,17 +1,21 @@ --- + + title: 클라우드 네이티브 보안 개요 +description: > + 클라우드 네이티브 보안 관점에서 쿠버네티스 보안을 생각해보기 위한 모델 content_type: concept -weight: 10 +weight: 1 --- + 이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다. {{< warning >}} 이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다. {{< /warning >}} - ## 클라우드 네이티브 보안의 4C @@ -83,7 +87,6 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋 * 설정 가능한 클러스터 컴포넌트의 보안 * 클러스터에서 실행되는 애플리케이션의 보안 - ### 클러스터의 컴포넌트 {#cluster-components} 우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 0848c357725ff..2f5a9064da696 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외 쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를 지원한다. 전자는 기본적으로 작동하지만 후자는 -[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다. +[CoreDNS 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다. {{< note >}} 만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성, 처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서 @@ -227,7 +227,7 @@ Address 1: 10.0.162.149 * 인증서를 사용하도록 구성된 nginx 서버 * 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/ko/docs/concepts/configuration/secret/) -[nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로: +[nginx https 예제](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로: ```shell make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt @@ -299,7 +299,7 @@ nginxsecret kubernetes.io/tls 2 1m nginx-secure-app의 매니페스트에 대한 주목할만한 점: - 이것은 동일한 파일에 디플로이먼트와 서비스의 사양을 모두 포함하고 있다. -- [nginx 서버](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf) +- [nginx 서버](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf) 는 포트 80에서 HTTP 트래픽을 443에서 HTTPS 트래픽 서비스를 제공하고, nginx 서비스는 두 포트를 모두 노출한다. - 각 컨테이너는 `/etc/nginx/ssl` 에 마운트된 볼륨을 통해 키에 접근할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index b4056171182de..dea7c359658d7 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -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" %}} diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 41524039f0ced..b43467d936014 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -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) 기반의 diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 802cc486bfff2..805260d15959a 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -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` 필드가 있다. diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 5a9b16a3097bf..d8926be00cede 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -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 >}} ## 이름으로 네임스페이스 지정 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index 5c4b9edeee4ae..230b716c78781 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -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는 트래픽을 포워드하지 않는다. + ## 서비스 디스커버리하기 쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경 @@ -394,7 +429,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다. 파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해 환경 변수 세트를 추가한다. [도커 링크 호환](https://docs.docker.com/userguide/dockerlinks/) 변수 -([makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와 +([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와 보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고, 이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다. @@ -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` 기능 게이트를 활성화해야 한다. #### 내부 로드 밸런서 diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index c70b7413ad2a7..87d43ae09e3de 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -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를 위한 적절한 파퓰레이터가 설치되어 있다면, +볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다. + ## 포터블 구성 작성 광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한 diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md new file mode 100644 index 0000000000000..4aeb1ba8c1019 --- /dev/null +++ b/content/ko/docs/concepts/storage/storage-capacity.md @@ -0,0 +1,117 @@ +--- + + + + + + +title: 스토리지 용량 +content_type: concept +weight: 45 +--- + + + +스토리지 용량은 제한이 있으며, 파드가 실행되는 노드의 상황에 따라 달라질 수 있다. +예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며, +또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다. + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고 +스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에 +파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다. +스토리지 용량을 추적하지 않으면, 스케줄러는 +볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며, +스케줄링을 여러 번 다시 시도해야 한다. + +스토리지 용량 추적은 {{< glossary_tooltip +text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며, +CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다. + + + +## API + + 이 기능에는 다음 두 가지 API 확장이 있다. +- CSIStorageCapacity 오브젝트: + CSI 드라이버가 설치된 네임스페이스에 + CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는 + 하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며, + 어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다. +- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io): + `true`로 설정하면, 쿠버네티스 스케줄러가 + CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다. + +## 스케줄링 + +다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다. +- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고, +- 파드가 아직 생성되지 않은 볼륨을 사용하고, +- 해당 볼륨은 CSI 드라이버를 참조하고 + `WaitForFirstConsumer` + [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 사용하는 + {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 사용하고, +- 드라이버의 `CSIDriver` 오브젝트에 `StorageCapacity` 속성이 + true로 설정되어 있다. + +이 경우 스케줄러는 파드에 제공할 +충분한 스토리지가 있는 노드만 고려한다. +이 검사는 아주 간단한데, +볼륨의 크기를 노드를 포함하는 토폴로지를 가진 `CSIStorageCapacity` 오브젝트에 +나열된 용량과 비교한다. + +볼륨 바인딩 모드가 `Immediate` 인 볼륨의 경우에는 스토리지 드라이버는 +볼륨을 사용하는 파드와 관계없이 볼륨을 생성할 위치를 정한다. +볼륨을 생성한 후에, 스케줄러는 +볼륨을 사용할 수 있는 노드에 파드를 스케줄링한다. + +[CSI 임시 볼륨](/ko/docs/concepts/storage/volumes/#csi)의 경우에는 +볼륨 유형이 로컬 볼륨이고 +큰 자원이 필요하지 않은 특정 CSI 드라이버에서만 사용된다는 가정하에, +항상 스토리지 용량을 고려하지 않고 +스케줄링한다. + +## 리스케줄링 + +`WaitForFirstConsumer` 볼륨을 가진 파드에 대해 +노드가 선정되었더라도 아직은 잠정적인 결정이다. 다음 단계에서 +선정한 노드에서 볼륨을 사용할 수 있어야 한다는 힌트를 주고 +CSI 스토리지 드라이버에 볼륨 생성을 요청한다 + +쿠버네티스는 시간이 지난 스토리지 용량 정보를 기반으로 +노드를 선정할 수도 있으므로, 볼륨을 실제로 생성하지 않을 수도 있다. +그런 다음 노드 선정이 재설정되고 쿠버네티스 스케줄러가 +파드를 위한 노드를 찾는 것을 재시도한다. + +## 제한사항 + +스토리지 용량 추적은 첫 시도에 스케줄링이 성공할 가능성을 높이지만, +스케줄러가 시간이 지난 정보를 기반으로 +결정해야 할 수도 있기 때문에 이를 보장하지는 않는다. +일반적으로 스토리지 용량 정보가 없는 스케줄링과 +동일한 재시도 메커니즘으로 스케줄링 실패를 처리한다. + +스케줄링이 영구적으로 실패할 수 있는 한 가지 상황은 +파드가 여러 볼륨을 사용하는 경우이다. +토폴로지 세그먼트에 하나의 볼륨이 이미 생성되어 +다른 볼륨에 충분한 용량이 남아 있지 않을 수 있다. +이러한 상황을 복구하려면 +용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하며, +자동으로 처리하려면 +[추가 작업](https://github.com/kubernetes/enhancements/pull/1703)이 필요하다. + +## 스토리지 용량 추적 활성화 + +스토리지 용량 추적은 베타 기능이며, +쿠버네티스 1.21 이후 버전부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있다. +클러스터에서 스토리지 용량 추적 기능을 활성화하는 것뿐만 아니라, CSI 드라이버에서도 이 기능을 지원해야 한다. +자세한 내용은 드라이버 문서를 참조한다. + +## {{% heading "whatsnext" %}} + +- 설계에 대한 자세한 내용은 + [파드 스케줄링 스토리지 용량 제약 조건](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)을 참조한다. +- 이 기능의 추가 개발에 대한 자세한 내용은 [개선 추적 이슈 #1472](https://github.com/kubernetes/enhancements/issues/1472)를 참조한다. +- [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 살펴본다. diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index f4385419f1ffb..c915b65fadb08 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -76,7 +76,7 @@ volumeBindingMode: Immediate | Glusterfs | ✓ | [Glusterfs](#glusterfs) | | iSCSI | - | - | | Quobyte | ✓ | [Quobyte](#quobyte) | -| NFS | - | - | +| NFS | - | [NFS](#nfs) | | RBD | ✓ | [Ceph RBD](#ceph-rbd) | | VsphereVolume | ✓ | [vSphere](#vsphere) | | PortworxVolume | ✓ | [Portworx 볼륨](#portworx-볼륨) | @@ -423,6 +423,29 @@ parameters: 헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을 삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다. +### NFS + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: example-nfs +provisioner: example.com/external-nfs +parameters: + server: nfs-server.example.com + path: /share + readOnly: false +``` + +* `server`: NFS 서버의 호스트네임 또는 IP 주소. +* `path`: NFS 서버가 익스포트(export)한 경로. +* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false). + +쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다. +예시는 다음과 같다. +* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner) +* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner) + ### OpenStack Cinder ```yaml @@ -578,6 +601,12 @@ parameters: ### Quobyte +{{< feature-state for_k8s_version="v1.22" state="deprecated" >}} + +Quobyte 인-트리 스토리지 플러그인은 사용 중단되었으며, +아웃-오브-트리 Quobyte 플러그인에 대한 [예제](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml) +`StorageClass`는 Quobyte CSI 저장소에서 찾을 수 있다. + ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 29f4755172ffb..349f47a55cf23 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -124,13 +124,13 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지 -플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `true` 로 설정한다. 이 기능은 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다. +플러그인을 끄려면, `InTreePluginAWSUnregister` 플래그를 `true` 로 설정한다. ### azureDisk {#azuredisk} `azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다. -더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)을 참고한다. +더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md)을 참고한다. #### azureDisk CSI 마이그레이션 @@ -148,7 +148,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}}/staging/volumes/azure_file/README.md)을 참고한다. +더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md)을 참고한다. #### azureFile CSI 마이그레이션 @@ -176,7 +176,7 @@ Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용 CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다. {{< /note >}} -더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다. +더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)를 참조한다. ### cinder @@ -347,7 +347,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다 쿠버네티스 호스트가 해당 LUN에 접근할 수 있다. {{< /note >}} -더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)를 참고한다. +더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)를 참고한다. ### flocker (사용 중단됨(deprecated)){#flocker} @@ -365,7 +365,7 @@ Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이 `flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다. {{< /note >}} -더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다. +더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다. ### gcePersistentDisk @@ -462,7 +462,8 @@ spec: required: nodeSelectorTerms: - matchExpressions: - - key: failure-domain.beta.kubernetes.io/zone + # 1.21 이전 버전에서는 failure-domain.beta.kubernetes.io/zone 키를 사용해야 한다. + - key: topology.kubernetes.io/zone operator: In values: - us-central1-a @@ -480,6 +481,13 @@ GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` 베타 기능을 활성화해야 한다. +#### GCE CSI 마이그레이션 완료 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +컨트롤러 매니저와 kubelet이 `gcePersistentDisk` 스토리지 플러그인을 로드하는 것을 방지하려면, +`InTreePluginGCEUnregister` 플래그를 `true`로 설정한다. + ### gitRepo (사용 중단됨) {#gitrepo} {{< warning >}} @@ -525,7 +533,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데 사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다. {{< /note >}} -더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다. +더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다. ### hostPath {#hostpath} @@ -653,7 +661,7 @@ iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수 iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있다. 동시 쓰기는 허용되지 않는다. -더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다. +더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/master/volumes/iscsi)를 본다. ### local @@ -741,7 +749,7 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla 사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다. {{< /note >}} -더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다. +더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다. ### persistentVolumeClaim {#persistentvolumeclaim} @@ -789,7 +797,7 @@ spec: 있는지 확인한다. {{< /note >}} -자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) 예제를 참고한다. +자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) 예제를 참고한다. ### projected @@ -803,7 +811,7 @@ spec: * `serviceAccountToken` 모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 -[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다. +[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다. #### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap} @@ -931,7 +939,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마 해당 볼륨 소스의 업데이트를 수신하지 않는다. {{< /note >}} -### quobyte +### quobyte (사용 중단됨) {#quobyte} `quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을 파드에 마운트할 수 있다. @@ -964,52 +972,9 @@ RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 동시 쓰기는 허용되지 않는다. -더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를 +더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를 참고한다. -### scaleIO (사용 중단됨) {#scaleio} - -ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를 -생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨 -플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수 -있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는 -방법에 대한 자세한 내용은 -[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다. - -{{< note >}} -사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고 -생성한 볼륨과 함께 실행해야 한다. -{{< /note >}} - -다음의 예시는 ScaleIO를 사용하는 파드 구성이다. - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: pod-0 -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: pod-0 - volumeMounts: - - mountPath: /test-pd - name: vol-0 - volumes: - - name: vol-0 - scaleIO: - gateway: https://localhost:443/api - system: scaleio - protectionDomain: sd0 - storagePool: sp1 - volumeName: vol-0 - secretRef: - name: sio-secret - fsType: xfs -``` - -더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) 예제를 참고한다. - ### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 @@ -1029,7 +994,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토 더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다. -### storageOS {#storageos} +### storageOS (사용 중단됨) {#storageos} `storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) 볼륨을 파드에 마운트할 수 있다. @@ -1177,7 +1142,7 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 {{< feature-state for_k8s_version="v1.19" state="beta" >}} -`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다. +`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다. ## subPath 사용하기 {#using-subpath} diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 6935cf8fb404e..740929b05c7cd 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는 ## 크론잡 -크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인 -작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을 -스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다. +크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다. +각 작업은 무기한 반복되도록 구성해야 한다(예: +1일/1주/1달마다 1회). +작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다. ### 예시 diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 1496b25ec382a..dc8f543048fa7 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, 업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 -디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, -다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다. +디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면, +파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다. + +예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index a3ed4ea68d4ed..225ff28948024 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -6,6 +6,18 @@ weight: 60 + +{{< note >}} +이 한글 문서는 더 이상 관리되지 않습니다. + +이 문서의 기반이 된 영어 원문은 삭제되었으며, +[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다. + +[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면, +이 문서는 삭제될 수 있습니다. +{{< /note >}} + + 쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상 소유자가 없는 오브젝트들을 삭제하는 역할을 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index c24beb0fca921..21da00ff5a343 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -187,14 +187,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 ### 완료 모드 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} - -{{< note >}} -인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/) -및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서 -`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화해야 한다. -{{< /note >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} 완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은 `.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다. @@ -203,8 +196,14 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드 완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는 잡은 암시적으로 `NonIndexed` 이다. -- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index` - 어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다. +- `Indexed`: 잡의 파드는 연결된 완료 인덱스를 0에서 `.spec.completions-1` 까지 + 가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다. + - 파드 어노테이션 `batch.kubernetes.io/job-completion-index`. + - 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). 인덱스된(Indexed) 잡과 + {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고 + 있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된 + 호스트네임을 사용할 수 있다. + - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수. 각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로 간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은 [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다. @@ -255,7 +254,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 ## 잡의 종료와 정리 -잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다. 이를 유지하면 +잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다. +이를 유지하면 완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다. 잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다. `kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다. @@ -402,14 +402,12 @@ spec: ### 잡 일시 중지 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} {{< note >}} -잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을 -사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/) -및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서 -`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -활성화해야 한다. +이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며, +이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다. +[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다. {{< /note >}} 잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해 @@ -568,6 +566,46 @@ spec: `manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런 불일치를 허용한다. +### 종료자(finalizers)를 이용한 잡 추적 + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +{{< note >}} +이 기능을 이용하기 위해서는 +[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와 +[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해 +`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +기본적으로는 비활성화되어 있다. + +이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다. +기존에 존재하던 잡은 영향을 받지 않는다. +사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다. +{{< /note >}} + +이 기능이 활성화되지 않으면, 잡 +{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 +`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다. +그런데, 파드는 다음과 같은 이유로 제거될 수 있다. +- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거 +- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를 + 일정 임계값 이후에 제거 +- 잡에 속한 파드를 사용자가 임의로 제거 +- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나 + 교체 + +클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면, +컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고 +API 서버에서 파드가 제거되면 이를 알아챈다. +이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다. +컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로, +이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다. + +잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다. +이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다. +잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여, +잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다. +이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**. + ## 대안 ### 베어(Bare) 파드 @@ -594,7 +632,7 @@ spec: 시작하기에는 다소 복잡할 수 있으며 쿠버네티스와의 통합성이 낮아진다. 이 패턴의 한 예시는 파드를 시작하는 잡이다. 파드는 스크립트를 실행해서 -스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)를 본다)를 시작하고, +스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)를 본다)를 시작하고, 스파크 드라이버를 실행한 다음, 정리한다. 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도, diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 7cf399d24275c..c795332625cfa 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -323,9 +323,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron 모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다. ### 파드 삭제 비용 -{{< feature-state for_k8s_version="v1.21" state="alpha" >}} +{{< feature-state for_k8s_version="v1.22" state="beta" >}} -[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, +[`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다. 이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다. @@ -335,9 +335,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron 파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다. 유효하지 않은 값은 API 서버가 거부한다. -이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다. -kube-apiserver와 kube-controller-manager에서 `PodDeletionCost` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다. +이 기능은 베타 상태이며 기본적으로 활성화되어 있다. +kube-apiserver와 kube-controller-manager에 대해 `PodDeletionCost` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다. {{< note >}} - 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 3a1f784259870..d39559e24c750 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -32,7 +32,7 @@ weight: 30 ## 제한사항 -* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. +* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다. @@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 ## 업데이트 전략 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 +스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 -구성하거나 비활성화 할 수 있다. +구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다. -### 삭제 시(On Delete) - -`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 -`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 -스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 +`OnDelete`(삭제시) +: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, +스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. +사용자는 컨트롤러가 스테이트풀셋의 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다. -### 롤링 업데이트 +`RollingUpdate`(롤링 업데이트) +: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 +구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. + +## 롤링 업데이트 + +스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 +스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이 +순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로), +각 파드의 업데이트는 한 번에 하나씩 한다. -`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 -구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 -스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 -순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), -각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 -때까지 기다린다. +쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다. +`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다. -#### 파티션(Partition) +### 파티션 롤링 업데이트 {#partitions} `롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` 를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 @@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다. -#### 강제 롤백 +### 강제 롤백 기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 @@ -273,8 +277,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 실행하려고 시도한 모든 파드를 삭제해야 한다. -그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다. +그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다. + +### 최소 준비 시간 초 {#minimum-ready-seconds} + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록 +컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다. +기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다). +파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면, +[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다. +이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 22b98b705c6a2..54fdf4a9a2acc 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -257,8 +257,12 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여 ## 컨테이너에 대한 특권 모드 -파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다. -특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다. +리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다. +클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다. + +파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다. + +HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다. {{< note >}} 이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다. @@ -282,6 +286,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버 즉, 노드에서 실행되는 파드는 API 서버에서 보이지만, 여기에서 제어할 수는 없다는 의미이다. +## 컨테이너 프로브 + +_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다. + +- `ExecAction` (컨테이너 런타임의 도움을 받아 수행) +- `TCPSocketAction` (kubelet에 의해 직접 검사) +- `HTTPGetAction` (kubelet에 의해 직접 검사) + +[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은 +파드 라이프사이클 문서를 참고한다. + ## {{% heading "whatsnext" %}} * [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다. diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 9aa9e9bf51764..136413b88f5ff 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -6,15 +6,15 @@ weight: 80 -{{< feature-state state="alpha" for_k8s_version="v1.16" >}} +{{< feature-state state="alpha" for_k8s_version="v1.22" >}} -이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 -트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 -임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 -컨테이너를 사용한다. +이 페이지는 임시 컨테이너에 대한 개요를 제공한다. +이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해 +기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다. +임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다. {{< warning >}} -임시 컨테이너는 초기 알파 상태이며, +임시 컨테이너 기능은 알파 상태이며, 프로덕션 클러스터에는 적합하지 않다. [쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. @@ -72,119 +72,8 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 임시 컨테이너 사용 시 [프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 -활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다. - -임시 컨테이너를 사용해서 문제를 해결하는 예시는 -[임시 디버깅 컨테이너로 디버깅하기] -(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다. - -## 임시 컨테이너 API - -{{< note >}} -이 섹션의 예시는 `EphemeralContainers` [기능 -게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 -활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다. -{{< /note >}} - -이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지 -보여준다. 일반적으로 `kubectl debug` 또는 -다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을 -사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다. - -임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 -사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 -`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다. - -```json -{ - "apiVersion": "v1", - "kind": "EphemeralContainers", - "metadata": { - "name": "example-pod" - }, - "ephemeralContainers": [{ - "command": [ - "sh" - ], - "image": "busybox", - "imagePullPolicy": "IfNotPresent", - "name": "debugger", - "stdin": true, - "tty": true, - "terminationMessagePolicy": "File" - }] -} -``` - -이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다. - -```shell -kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json -``` - -그러면 새로운 임시 컨테이너 목록이 반환된다. - -```json -{ - "kind":"EphemeralContainers", - "apiVersion":"v1", - "metadata":{ - "name":"example-pod", - "namespace":"default", - "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers", - "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c", - "resourceVersion":"15886", - "creationTimestamp":"2019-08-29T06:41:42Z" - }, - "ephemeralContainers":[ - { - "name":"debugger", - "image":"busybox", - "command":[ - "sh" - ], - "resources":{ - - }, - "terminationMessagePolicy":"File", - "imagePullPolicy":"IfNotPresent", - "stdin":true, - "tty":true - } - ] -} -``` - -사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다. - -```shell -kubectl describe pod example-pod -``` - -``` -... -Ephemeral Containers: - debugger: - Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f - Image: busybox - Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70 - Port: - Host Port: - Command: - sh - State: Running - Started: Thu, 29 Aug 2019 06:42:21 +0000 - Ready: False - Restart Count: 0 - Environment: - Mounts: -... -``` - -예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서 -다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와 -상호작용할 수 있다. - -```shell -kubectl attach -it example-pod -c debugger -``` +활성화하면 다른 컨테이너 안의 프로세스를 보는 데 도움이 된다. + +## {{% heading "whatsnext" %}} + +* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기. diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index c8c70554086fc..a1c01b17ab0b7 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -290,8 +290,9 @@ myapp-pod 1/1 Running 0 9m 초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한 다음의 규칙이 적용된다. -* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장 - 높은 것은 *유효한 초기화 요청량/상한* 이다. +* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 + 가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는 + 이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다. * 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다. * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계 * 리소스에 대한 유효한 초기화 요청량/상한 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 11aeaa31b0e4a..1e2754ebaf8a3 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다. 확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료 프로세스를 시작한다. 1. 파드의 컨테이너 중 하나가 `preStop` - [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은 + [훅](/ko/docs/concepts/containers/container-lifecycle-hooks)을 정의한 경우, kubelet은 컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이 계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을 요청한다. diff --git a/content/ko/docs/contribute/generate-ref-docs/quickstart.md b/content/ko/docs/contribute/generate-ref-docs/quickstart.md index 6855696b9d798..531b1ad50b752 100644 --- a/content/ko/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/ko/docs/contribute/generate-ref-docs/quickstart.md @@ -6,7 +6,7 @@ weight: 40 -이 문서에서는 `update-imported-docs` 스크립트를 사용하여 +이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여 쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다. 이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다. @@ -39,7 +39,7 @@ git clone git@github.com:/website.git ## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs} -`update-imported-docs` 스크립트는 `/update-imported-docs/` +`update-imported-docs.py` 스크립트는 `/update-imported-docs/` 디렉터리에 존재한다. 이 스크립트는 다음 레퍼런스를 생성한다. @@ -48,7 +48,7 @@ git clone git@github.com:/website.git * `kubectl` 명령어 레퍼런스 * 쿠버네티스 API 레퍼런스 -`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 +`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를 생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와 `kubernetes-sigs/reference-docs` 저장소를 클론하며, @@ -69,7 +69,7 @@ git clone git@github.com:/website.git `kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다. `K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다. -`update-imported-docs` 스크립트는 다음의 과정을 수행한다. +`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다. 1. 환경설정 파일에 있는 관련 저장소를 클론한다. 레퍼런스 문서 생성을 위해 @@ -152,11 +152,11 @@ repos: ## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool} -다음과 같이 `update-imported-docs` 도구를 실행할 수 있다. +다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다. ```shell cd /update-imported-docs -./update-imported-docs +./update-imported-docs.py ``` 예를 들면 다음과 같다. @@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon * [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/) * [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/) - diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 55401988b4a6d..8bfa706ea4de6 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -71,8 +71,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 제공하지 않는다. +* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) * [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) * [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) * [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) * [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) * [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/) @@ -82,6 +84,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로 ## kubeadm을 위한 API 설정 * [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/) +* [v1beta3](/docs/reference/config-api/kubeadm-config.v1beta3/) ## 설계 문서 diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md index ca06783465e04..55615e55de8fa 100644 --- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md @@ -57,10 +57,9 @@ weight: 50 #### 바인딩된 서비스 어카운트 토큰 볼륨 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} -`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, -토큰 컨트롤러에 의해 생성된 무기한 서비스 어카운트 토큰을 위해, 서비스 어카운트 어드미션 컨트롤러가 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. +서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. ```yaml - name: kube-api-access- @@ -91,10 +90,6 @@ weight: 50 상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다. -`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우, -위의 프로젝티드 볼륨을 파드 스펙에 추가하여 -시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다. - ### 토큰 컨트롤러 토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는, diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 97262073a1a5e..7b1bdb7c42cf4 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -2,6 +2,9 @@ weight: 10 title: 기능 게이트 content_type: concept +card: + name: reference + weight: 60 --- @@ -25,7 +28,7 @@ content_type: concept kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다. ```shell ---feature-gates="...,DynamicKubeletConfig=true" +--feature-gates="...,GracefulNodeShutdown=true" ``` 다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를 @@ -55,65 +58,60 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 | | `APIResponseCompression` | `true` | 베타 | 1.16 | | | `APIServerIdentity` | `false` | 알파 | 1.20 | | +| `APIServerTracing` | `false` | 알파 | 1.22 | | | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | | | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | | | `AppArmor` | `true` | 베타 | 1.4 | | -| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | | -| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 | -| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | | | `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | | | `CPUManager` | `false` | 알파 | 1.8 | 1.9 | | `CPUManager` | `true` | 베타 | 1.10 | | +| `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | | | `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 | | `CSIInlineVolume` | `true` | 베타 | 1.16 | - | | `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigration` | `true` | 베타 | 1.17 | | | `CSIMigrationAWS` | `false` | 알파 | 1.14 | | | `CSIMigrationAWS` | `false` | 베타 | 1.17 | | -| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | | `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | | -| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 | | `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | | -| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigrationGCE` | `false` | 베타 | 1.17 | | -| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 | | `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | | -| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationvSphere` | `false` | 베타 | 1.19 | | -| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | | -| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 | -| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | | | `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 | | `CSIStorageCapacity` | `true` | 베타 | 1.21 | | | `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 | | `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | | | `CSIVolumeHealth` | `false` | 알파 | 1.21 | | +| `CSRDuration` | `true` | 베타 | 1.22 | | | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 | | `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | | -| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 | -| `CronJobControllerV2` | `true` | 베타 | 1.21 | | +| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 | +| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | | | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | +| `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 | +| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | | | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 | | `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | | +| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | | | `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 | | `DevicePlugins` | `true` | 베타 | 1.10 | | | `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 | | `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | | +| `DisableCloudProviders` | `false` | 알파 | 1.22 | | | `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 | | `DownwardAPIHugePages` | `false` | 베타 | 1.21 | | -| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | -| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | | -| `EfficientWatchResumption` | `false` | 알파 | 1.20 | | -| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 | -| `EndpointSliceProxying` | `true` | 베타 | 1.19 | | -| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | | +| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 | +| `EfficientWatchResumption` | `true` | 베타 | 1.21 | | +| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 | +| `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | | | `EphemeralContainers` | `false` | 알파 | 1.16 | | | `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 | | `ExpandCSIVolumes` | `true` | 베타 | 1.16 | | +| `ExpandedDNSConfig` | `false` | 알파 | 1.22 | | | `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 | | `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | | | `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | @@ -125,70 +123,83 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `GracefulNodeShutdown` | `true` | 베타 | 1.21 | | | `HPAContainerMetrics` | `false` | 알파 | 1.20 | | | `HPAScaleToZero` | `false` | 알파 | 1.16 | | -| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 | -| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | | -| `IndexedJob` | `false` | 알파 | 1.21 | | -| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | | +| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 | +| `IndexedJob` | `true` | 베타 | 1.22 | | +| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | | +| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 | +| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | | +| `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | | +| `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | | +| `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | | +| `InTreePluginGCEUnregister` | `false` | 알파 | 1.21 | | +| `InTreePluginOpenStackUnregister` | `false` | 알파 | 1.21 | | +| `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | | | `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 | | `IPv6DualStack` | `true` | 베타 | 1.21 | | +| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | | | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | | -| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | -| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | -| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | | +| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 | +| `LogarithmicScaleDown` | `true` | 베타 | 1.22 | | +| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | | | `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | | +| `MemoryManager` | `false` | 알파 | 1.21 | 1.21 | +| `MemoryManager` | `true` | 베타 | 1.22 | | +| `MemoryQoS` | `false` | 알파 | 1.22 | | | `MixedProtocolLBService` | `false` | 알파 | 1.20 | | -| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | | -| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | | -| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | -| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | +| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 | +| `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | | +| `NodeSwap` | `false` | 알파 | 1.22 | | | `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | 베타 | 1.19 | | -| `PodDeletionCost` | `false` | 알파 | 1.21 | | -| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | | +| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 | +| `PodDeletionCost` | `true` | 베타 | 1.22 | | +| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 | +| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | | | `PodOverhead` | `false` | 알파 | 1.16 | 1.17 | -| `PodOverhead` | `true` | 베타 | 1.18 | | -| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | | +| `PodOverhead` | `true` | 베타 | 1.18 | | +| `PodSecurity` | `false` | 알파 | 1.22 | | +| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 | +| `PreferNominatedNode` | `true` | 베타 | 1.22 | | +| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 | +| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | | +| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | | | `ProcMountType` | `false` | 알파 | 1.12 | | | `QOSReserved` | `false` | 알파 | 1.11 | | +| `ReadWriteOncePod` | `false` | 알파 | 1.22 | | | `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 | | `RemainingItemCount` | `true` | 베타 | 1.16 | | | `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 | | `RemoveSelfLink` | `true` | 베타 | 1.20 | | | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | -| `RunAsGroup` | `true` | 베타 | 1.14 | | -| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | -| `ServerSideApply` | `true` | 베타 | 1.16 | | -| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | | -| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | | -| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | | -| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | -| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | -| `ServiceTopology` | `false` | 알파 | 1.17 | | -| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | -| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | | -| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | | +| `SeccompDefault` | `false` | 알파 | 1.22 | | +| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 | +| `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | | +| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 | +| `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | | +| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 | +| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | | +| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 | +| `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | | +| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | | | `StorageVersionAPI` | `false` | 알파 | 1.20 | | | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | -| `SuspendJob` | `false` | 알파 | 1.21 | | +| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 | +| `SuspendJob` | `true` | 베타 | 1.22 | | | `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 | | `TTLAfterFinished` | `true` | 베타 | 1.21 | | | `TopologyAwareHints` | `false` | 알파 | 1.21 | | | `TopologyManager` | `false` | 알파 | 1.16 | 1.17 | | `TopologyManager` | `true` | 베타 | 1.18 | | -| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | -| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | | | `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - | -| `WarningHeaders` | `true` | 베타 | 1.19 | | | `WinDSR` | `false` | 알파 | 1.14 | | | `WinOverlay` | `false` | 알파 | 1.14 | 1.19 | | `WinOverlay` | `true` | 베타 | 1.20 | | -| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 | -| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | | +| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | | {{< /table >}} ### GA 또는 사용 중단된 기능을 위한 기능 게이트 @@ -206,9 +217,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `AffinityInAnnotations` | - | 사용중단 | 1.8 | - | | `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 | | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | +| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 | +| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 | +| `AttachVolumeLimit` | `true` | GA | 1.17 | - | +| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | 1.21 | +| `BalanceAttachedNodeVolumes` | `false` | 사용중단 | 1.22 | | | `BlockVolume` | `false` | 알파 | 1.9 | 1.12 | | `BlockVolume` | `true` | 베타 | 1.13 | 1.17 | | `BlockVolume` | `true` | GA | 1.18 | - | +| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 | +| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | 1.21 | +| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - | | `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | | `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 | | `CRIContainerLogRotation` | `true` | GA | 1.21 | - | @@ -218,15 +237,30 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 | | `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 | | `CSIDriverRegistry` | `true` | GA | 1.18 | | +| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationAWSComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationAzureDiskComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationAzureFileComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationGCEComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | 1.20 | +| `CSIMigrationOpenStackComplete` | - | 사용중단 | 1.21 | - | +| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | 1.21 | +| `CSIMigrationvSphereComplete` | - | 사용중단 | 1.22 | - | | `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 | | `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 | | `CSINodeInfo` | `true` | GA | 1.17 | | -| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 | -| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 | -| `AttachVolumeLimit` | `true` | GA | 1.17 | - | | `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 | | `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 | | `CSIPersistentVolume` | `true` | GA | 1.13 | - | +| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 | +| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | 1.21 | +| `CSIServiceAccountToken` | `true` | GA | 1.22 | | +| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 | +| `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 | +| `CronJobControllerV2` | `true` | GA | 1.22 | - | | `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 | | `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 | | `CustomPodDNS` | `true` | GA | 1.14 | - | @@ -250,8 +284,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `DryRun` | `true` | GA | 1.19 | - | | `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 | | `DynamicAuditing` | - | 사용중단 | 1.19 | - | +| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | +| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 | +| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - | | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 | | `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - | +| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | +| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 | +| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - | | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | | `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - | @@ -263,6 +303,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `EndpointSlice` | `true` | GA | 1.21 | - | | `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 | | `EndpointSliceNodeName` | `true` | GA | 1.21 | - | +| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 | +| `EndpointSliceProxying` | `true` | 베타 | 1.19 | 1.21 | +| `EndpointSliceProxying` | `true` | GA | 1.22 | - | | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | | `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - | | `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | @@ -272,9 +315,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | +| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 | +| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 | +| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - | | `HugePages` | `false` | 알파 | 1.8 | 1.9 | | `HugePages` | `true` | 베타| 1.10 | 1.13 | | `HugePages` | `true` | GA | 1.14 | - | +| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 | +| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 | +| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - | | `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 | | `HyperVContainer` | `false` | 사용중단 | 1.20 | - | | `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 | @@ -290,16 +339,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | | `KubeletPodResources` | `true` | 베타 | 1.15 | | | `KubeletPodResources` | `true` | GA | 1.20 | | +| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | +| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | | `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | | `MountContainers` | `false` | 알파 | 1.9 | 1.16 | | `MountContainers` | `false` | 사용중단 | 1.17 | - | | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | - | +| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | +| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | | `NodeDisruptionExclusion` | `true` | GA | 1.21 | - | | `NodeLease` | `false` | 알파 | 1.12 | 1.13 | | `NodeLease` | `true` | 베타 | 1.14 | 1.16 | | `NodeLease` | `true` | GA | 1.17 | - | +| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 | +| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - | | `PVCProtection` | `false` | 알파 | 1.9 | 1.9 | | `PVCProtection` | - | 사용중단 | 1.10 | - | | `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | @@ -329,15 +384,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `RootCAConfigMap` | `true` | GA | 1.21 | - | | `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 | | `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - | +| `RunAsGroup` | `true` | 베타 | 1.14 | 1.20 | +| `RunAsGroup` | `true` | GA | 1.21 | - | | `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 | | `RuntimeClass` | `true` | 베타 | 1.14 | 1.19 | | `RuntimeClass` | `true` | GA | 1.20 | - | -| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 | -| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 | -| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - | | `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 | | `SCTPSupport` | `true` | 베타 | 1.19 | 1.19 | | `SCTPSupport` | `true` | GA | 1.20 | - | +| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 | +| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 | +| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - | +| `SelectorIndex` | `false` | 알파 | 1.18 | 1.18 | +| `SelectorIndex` | `true` | 베타 | 1.19 | 1.19 | +| `SelectorIndex` | `true` | GA | 1.20 | - | +| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | +| `ServerSideApply` | `true` | 베타 | 1.16 | 1.21 | +| `ServerSideApply` | `true` | GA | 1.22 | - | | `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 | | `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 | | `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - | @@ -347,15 +410,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | +| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | +| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | | `ServiceNodeExclusion` | `true` | GA | 1.21 | - | +| `ServiceTopology` | `false` | 알파 | 1.17 | 1.19 | +| `ServiceTopology` | `false` | 사용중단 | 1.20 | - | +| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | +| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | 1.21 | +| `SetHostnameAsFQDN` | `true` | GA | 1.22 | - | | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | | `StartupProbe` | `true` | 베타 | 1.18 | 1.19 | | `StartupProbe` | `true` | GA | 1.20 | - | | `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 | | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | | `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | -| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 | -| `StreamingProxyRedirects` | - | GA | 1.19 | - | +| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.17 | +| `StreamingProxyRedirects` | `true` | 사용중단 | 1.18 | 1.21 | +| `StreamingProxyRedirects` | `false` | 사용중단 | 1.22 | - | | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | @@ -380,6 +451,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 | | `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 | | `TokenRequestProjection` | `true` | GA | 1.20 | - | +| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | +| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | 1.21 | +| `ValidateProxyRedirects` | `true` | 사용중단 | 1.22 | - | | `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 | | `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 | | `VolumePVCDataSource` | `true` | GA | 1.18 | - | @@ -393,12 +467,18 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 | | `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 | | `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - | +| `WarningHeaders` | `true` | 베타 | 1.19 | 1.21 | +| `WarningHeaders` | `true` | GA | 1.22 | - | | `WatchBookmark` | `false` | 알파 | 1.15 | 1.15 | | `WatchBookmark` | `true` | 베타 | 1.16 | 1.16 | | `WatchBookmark` | `true` | GA | 1.17 | - | +| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 | +| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | 1.21 | +| `WindowsEndpointSliceProxying` | `true` | GA | 1.22| - | | `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 | | `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 | | `WindowsGMSA` | `true` | GA | 1.18 | - | +| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | | `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 | | `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 | | `WindowsRunAsUserName` | `true` | GA | 1.18 | - | @@ -453,6 +533,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨) - `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다. - `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다. +- `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다. - `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다. - `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다. - `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) @@ -486,6 +567,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 리더 마이그레이션(Leader Migration)을 활성화한다. - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다. +- `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다. - `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며, 컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다. 더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. @@ -506,6 +588,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고 EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + 이 플래그는 인-트리 EBS 플러그인의 등록을 막는 `InTreePluginAWSUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. - `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리 @@ -516,7 +600,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능 플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어 - 있어야 한다. + 있어야 한다. 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. - `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을 Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 @@ -527,7 +612,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능 플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어 - 있어야 한다. + 있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는 + `InTreePluginAzureFileUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. - `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에 PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을 @@ -536,7 +623,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI - 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. - `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에 Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 @@ -545,7 +633,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고 - Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. + Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. - `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅하는 shim 및 변환 로직을 사용한다. 노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 @@ -554,7 +643,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및 CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이 - 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. + 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해 + 더 이상 사용되지 않는다. - `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다. - `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) 호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고 @@ -570,14 +660,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다. - `CSIVolumeHealth`: 노드에서의 CSI 볼륨 상태 모니터링 기능을 활성화한다. +- `CSRDuration`: 클라이언트가 쿠버네티스 CSR API를 통해 발급된 인증서의 기간을 + 요청할 수 있다. - `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. +- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에 + 대한 리더 마이그레이션을 지원한다. - `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면, 동일한 컨트롤러의 버전 1이 선택된다. - 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다. - `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서 `cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다. - `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다. @@ -591,12 +684,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다. - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. +- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록 + 데몬셋 워크로드를 사용하도록 설정한다. - `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여 [기본 분배](/ko/docs/concepts/workloads/pods/pod-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`의 + 모든 기능을 비활성화한다. - `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서 hugepages 사용을 활성화한다. - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 @@ -635,6 +736,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 현재 수정된 결함에 의존하는 경우 존재한다. [준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다. - `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다. +- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면 + kubelet과 kube-apiserver를 사용하도록 설정한다. + [확장된 DNS 구성](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration)을 참고한다. - `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다. [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다. - `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다. @@ -671,8 +775,24 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 기능을 활성화한다. - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다. +- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리 + 플러그인의 등록을 중지한다. +- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리 + 플러그인의 등록을 중지한다. +- `InTreePluginAzureFileUnregister`: kubelet 및 볼륨 컨트롤러에 azurefile 인-트리 + 플러그인의 등록을 중지한다. +- `InTreePluginGCEUnregister`: kubelet 및 볼륨 컨트롤러에 gce-pd 인-트리 + 플러그인의 등록을 중지한다. +- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리 + 플러그인의 등록을 중지한다. +- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리 + 플러그인의 등록을 중지한다. - `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다. +- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고 + [잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다. + 잡 컨트롤러는 완료된 파드를 추적하기 위해 + 완료된 파드의 잡 상태 필드를 사용한다. - `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로 한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에 `Scope` 와 `Namespace` 2개의 필드를 추가한다. @@ -680,11 +800,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 비동기 조정을 허용한다. - `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/) 기능을 활성화한다. +- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아있는 파드에 + 의존하지 않고 잡 완료를 추적할 수 있다. + 파드 finalizers는 잡 상태 필드와 + 아직 구성되지 않은 파드를 추적할 수 있다. - `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다. 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 참고한다. - `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다. +- `KubeletInUserNamespace`: {{}}에서 kubelet 실행을 활성화한다. + [루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다. - `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은 플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다. - `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은 @@ -709,6 +835,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 향상시킨다. - `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여 축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다. +- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한 + 메모리 어피니티를 설정할 수 있다. +- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다. - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다. - `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. @@ -720,6 +849,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. +- `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다. + 반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다. + 더 자세한 정보는 [스왑 메모리](/docs/concepts/architecture/nodes/#swap-memory)를 참고한다. - `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다. - `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 삭제되지 않도록 한다. @@ -737,17 +869,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 참고한다. +- `PodSecurity`: `PodSecurity` 어드미션 플러그인을 사용하도록 설정한다. - `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은 [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다. +- `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에 + 지정된 노드를 먼저 검사할지 여부를 + 스케줄러에 알려준다. - `ProbeTerminationGracePeriod`: 파드의 [프로브-수준 `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`일 때 종료 엔드포인트를 처리하도록 + kube-proxy를 활성화한다. - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다 (현재 메모리만 해당). +- `ReadWriteOncePod`: `ReadWriteOncePod` 퍼시스턴트 볼륨 엑세스 모드를 + 사용한다. - `RemainingItemCount`: API 서버가 [청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한 응답에서 남은 항목 수를 표시하도록 허용한다. @@ -779,6 +919,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 스케줄링할 수 있다. - `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다. +- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다. + seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다. +- `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여 + 목록 작업을 가속화할 수 있다. - `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다. - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 @@ -806,6 +950,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다. +- `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를 + 반영할 수 있다. - `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히 사용 중인 경우 삭제를 연기한다. - `StorageVersionAPI`: [스토리지 버전 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageversion-v1alpha1-internal-apiserver-k8s-io)를 @@ -867,6 +1013,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다. - `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다. - `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다. +- `WindowsHostProcessContainers`: 윈도우 HostProcess 컨테이너에 대한 지원을 사용하도록 설정한다. - `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은 [RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을 @@ -875,7 +1022,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. [엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. - +- `WindowsHostProcessContainers`: 윈도우 노드에서 `HostProcess` + 컨테이너 지원을 활성화한다. + ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/reference/glossary/api-eviction.md b/content/ko/docs/reference/glossary/api-eviction.md index f8a65c606eb49..7d5ee60667032 100644 --- a/content/ko/docs/reference/glossary/api-eviction.md +++ b/content/ko/docs/reference/glossary/api-eviction.md @@ -2,7 +2,7 @@ title: API를 이용한 축출(Eviction) id: api-eviction date: 2021-04-27 -full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction +full_link: /ko/docs/concepts/scheduling-eviction/api-eviction/ short_description: > API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는 축출 오브젝트를 만드는 프로세스이다 diff --git a/content/ko/docs/reference/glossary/csi.md b/content/ko/docs/reference/glossary/csi.md new file mode 100644 index 0000000000000..64053db20b773 --- /dev/null +++ b/content/ko/docs/reference/glossary/csi.md @@ -0,0 +1,21 @@ +--- +title: 컨테이너 스토리지 인터페이스(CSI) +id: csi +date: 2018-06-25 +full_link: /ko/docs/concepts/storage/volumes/#csi +short_description: > + 컨테이너 스토리지 인터페이스(CSI)는 컨테이너에 스토리지 시스템을 노출하는 표준 인터페이스를 정의한다. + + +aka: +tags: +- storage +--- + 컨테이너 스토리지 인터페이스(CSI)는 컨테이너에 스토리지 시스템을 노출하는 표준 인터페이스를 정의한다. + + + +CSI를 통해 공급업체는 쿠버네티스 저장소(트리 외 플러그인)를 추가하지 않고도 쿠버네티스용 사용자 스토리지 플러그인을 생성할 수 있다. 스토리지 제공자가 CSI 드라이버를 사용하려면, 먼저 [클러스터에 배포](https://kubernetes-csi.github.io/docs/deploying.html)해야 한다. 그런 다음 해당 CSI 드라이버를 사용하는 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 생성할 수 있다. + +* [쿠버네티스 문서에서 CSI](/ko/docs/concepts/storage/volumes/#csi) +* [사용 가능한 CSI 드라이버 목록](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/ko/docs/reference/kubectl/kubectl.md b/content/ko/docs/reference/kubectl/kubectl.md index 81e4d3fa74156..b2a16bf452c58 100644 --- a/content/ko/docs/reference/kubectl/kubectl.md +++ b/content/ko/docs/reference/kubectl/kubectl.md @@ -328,7 +328,31 @@ kubectl [flags] +## {{% heading "envvars" %}} + ++++ + + + + + + + + + + + + + + + + + +
KUBECONFIG
kubectl 구성 ("kubeconfig") 파일 경로. 기본: "$HOME/.kube/config"
KUBECTL_COMMAND_HEADERS
false로 설정하면, 호출된 kubectl 명령(쿠버네티스 버전 v1.22 이상)을 자세히 설명하는 추가 HTTP 헤더를 해제
## {{% heading "seealso" %}} diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index 3d8179a08a9ef..247489a6ee5aa 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -87,7 +87,7 @@ kubectl [command] [TYPE] [NAME] [flags] `cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다. `completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다. `config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다. -`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. +`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다. `cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다. `cp` | `kubectl cp [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다. `create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다. diff --git a/content/ko/docs/reference/labels-annotations-taints.md b/content/ko/docs/reference/labels-annotations-taints.md index 0854c1b5cf692..2577531042330 100644 --- a/content/ko/docs/reference/labels-annotations-taints.md +++ b/content/ko/docs/reference/labels-annotations-taints.md @@ -200,7 +200,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다. -## experimental.windows.kubernetes.io/isolation-type +## experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type} 예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"` @@ -210,6 +210,7 @@ Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려 {{< note >}} 이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다. +v1.20부터 이 어노테이션은 더이상 사용되지 않는다. 실험적인 Hyper-V 지원은 1.21버전에서 제거되었다. {{< /note >}} ## ingressclass.kubernetes.io/is-default-class @@ -262,11 +263,29 @@ kube-controller-manager의 잡(Job) 컨트롤러는 ## endpoints.kubernetes.io/over-capacity -예시: `endpoints.kubernetes.io/over-capacity:warning` +예시: `endpoints.kubernetes.io/over-capacity:truncated` 적용 대상: 엔드포인트(Endpoints) -v1.21 이상의 쿠버네티스 클러스터에서, 엔드포인트(Endpoints) 컨트롤러가 1000개 이상의 엔드포인트를 관리하고 있다면 각 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 엔드포인트 리소스가 용량 초과 되었음을 나타낸다. +v1.22 이상의 쿠버네티스 클러스터에서, 한 엔드포인트(Endpoints) 리소스가 관리하고 있는 엔드포인트의 수가 1000개 이상이면 엔드포인트 컨트롤러가 해당 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 해당 엔드포인트 리소스가 용량 초과 되었으며 엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다. + +## batch.kubernetes.io/job-tracking + +예시: `batch.kubernetes.io/job-tracking: ""` + +적용 대상: 잡 + +잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers) +중임을 나타낸다. +어노테이션을 수동으로 추가하거나 제거하지 **않는다**. + +## scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated) {#scheduleralphakubernetesio-preferavoidpods} + +적용 대상: 노드 + +이 어노테이션을 사용하려면 [NodePreferAvoidPods 스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins)이 활성화되어 있어야 한다. +해당 플러그인은 쿠버네티스 1.22에서 사용 중단되었다. +대신 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 사용한다. **이 이후로 나오는 테인트는 모두 '적용 대상: 노드' 이다.** @@ -323,3 +342,87 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드 예시: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule` 노드의 상태가 클라우드 공급자가 정의한 'shutdown' 상태이면, 이에 따라 노드에 `node.cloudprovider.kubernetes.io/shutdown` 테인트가 `NoSchedule` 값으로 설정된다. + +## pod-security.kubernetes.io/enforce + +예시: `pod-security.kubernetes.io/enforce: baseline` + +적용 대상: 네임스페이스 + +값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 +`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다. +특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 +레이블 네임스페이스에 모든 파드의 생성을 금지한다. + +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +참고한다. + +## pod-security.kubernetes.io/enforce-version + +예시: `pod-security.kubernetes.io/enforce-version: {{< skew latestVersion >}}` + +적용 대상: 네임스페이스 + +값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다. +설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) +정책의 버전이 결정된다. + +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +참고한다. + +## pod-security.kubernetes.io/audit + +예시: `pod-security.kubernetes.io/audit: baseline` + +적용 대상: 네임스페이스 + +값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 +`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다. +특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을 +방지하지 않지만, 해당 파드에 audit 어노테이션을 추가한다. + +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +참고한다. + +## pod-security.kubernetes.io/audit-version + +예시: `pod-security.kubernetes.io/audit-version: {{< skew latestVersion >}}` + +적용 대상: 네임스페이스 + +값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다. +설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) +정책의 버전이 결정된다. + +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +참고한다. + +## pod-security.kubernetes.io/warn + +예시: `pod-security.kubernetes.io/warn: baseline` + +적용 대상: 네임스페이스 + +값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는 +`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다. +특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을 +방지하지는 않지만, 그러한 파드가 생성되면 사용자에게 경고를 반환한다. +디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 +객체를 만들거나 업데이트할 때에도 경고가 표시된다. + +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +참고한다. + +## pod-security.kubernetes.io/warn-version + +예시: `pod-security.kubernetes.io/warn-version: {{< skew latestVersion >}}` + +적용 대상: 네임스페이스 + +값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다. +설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards) +정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는 +객체를 만들거나 업데이트할 때에도 경고가 표시된다. + +더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을 +참고한다. \ No newline at end of file diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index 2f46c78d8bd1b..07f06863d49af 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -18,7 +18,8 @@ weight: 20 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. -[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +또는 [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)) 구조에 맞게 파일을 작성하고, `kube-scheduler --config `을 실행하여 스케줄링 프로파일을 지정할 수 있다. @@ -26,7 +27,7 @@ weight: 20 최소 구성은 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig @@ -48,38 +49,41 @@ clientConnection: 스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서 발생한다. -1. `QueueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를 +1. `queueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를 정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다. 사용할 수 있다. -1. `PreFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를 +1. `preFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를 사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로 표시할 수 있다. -1. `Filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며 +1. `filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며 파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는 구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로 표시된다. -1. `PreScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는 +1. `postFilter`: 이 플러그인은 파드의 실행 가능한 노드를 찾을 수 없을 때, + 구성된 순서대로 호출된다. `postFilter` 플러그인이 파드 _schedulable_ 을 표시하는 경우, + 나머지 플러그인은 호출 되지 않는다. +1. `preScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는 정보성 익스텐션 포인트이다. -1. `Score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를 +1. `score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를 제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은 노드를 선택한다. -1. `Reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에 +1. `reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에 알리는 정보성 익스텐션 포인트이다. 플러그인은 또한 `Reserve` 도중 또는 이후에 실패한 경우 호출 되는 `Unreserve` 호출을 구현한다. -1. `Permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다. -1. `PreBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다. -1. `Bind`: 플러그인은 파드를 노드에 바인딩한다. Bind 플러그인은 순서대로 호출되며 - 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. Bind +1. `permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다. +1. `preBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다. +1. `bind`: 플러그인은 파드를 노드에 바인딩한다. `bind` 플러그인은 순서대로 호출되며 + 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. bind 플러그인은 적어도 하나 이상 필요하다. -1. `PostBind`: 파드가 바인드된 후 호출되는 +1. `postBind`: 파드가 바인드된 후 호출되는 정보성 익스텐션 포인트이다. 각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나 자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - plugins: @@ -99,98 +103,100 @@ profiles: ### 스케줄링 플러그인 -1. `UnReserve`: 파드가 예약된 후 거부되고 `Permit` 플러그인에 의해 보류된 경우 - 호출되는 정보성 익스텐션 포인트이다. - -## 스케줄링 플러그인 - 기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중 하나 이상을 구현한다. -- `SelectorSpread`: {{< glossary_tooltip text="서비스" term_id="service" >}}, - {{< glossary_tooltip text="레플리카셋(ReplicaSets)" term_id="replica-set" >}} 및 - {{< glossary_tooltip text="스테이트풀셋(StatefulSets)" term_id="statefulset" >}}에 - 속하는 파드에 대해 노드 간 분산을 선호한다. - 익스텐션 포인트: `PreScore`, `Score`. - `ImageLocality`: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를 선호한다. - 익스텐션 포인트: `Score`. + 익스텐션 포인트: `score`. - `TaintToleration`: [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 구현한다. - 익스텐션 포인트 구현: `Filter`, `Prescore`, `Score`. + 익스텐션 포인트 구현: `filter`, `preScore`, `score`. - `NodeName`: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다. - 익스텐션 포인트: `PreFilter`, `Filter`. + 익스텐션 포인트: `preFilter`, `filter`. - `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}} `scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라 노드 점수를 매긴다. - 익스텐션 포인트: `Score`. + 익스텐션 포인트: `score`. - `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를 구현한다. - 익스텐션 포인트: `Filter`, `Score`. + 익스텐션 포인트: `filter`, `score`. - `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를 구현한다. - 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`. + 익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`. - `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를 필터링한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `NodeResourcesFit`: 노드에 파드가 요청하는 모든 리소스가 있는지 - 확인한다. - 익스텐션 포인트: `PreFilter`, `Filter`. + 확인한다. 점수는 `LeastAllocated`(기본값), `MostAllocated`, `RequestedToCapacityRatio` 등 3가지 전략 중 하나를 사용할 수 있다. + 익스텐션 포인트: `preFilter`, `filter`, `score`. - `NodeResourcesBalancedAllocation`: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을 얻을 수 있는 노드를 선호한다. - 익스텐션 포인트: `Score`. + 익스텐션 포인트: `score`. - `NodeResourcesLeastAllocated`: 리소스 할당이 적은 노드를 선호한다. 익스텐션 포인트: `Score`. - `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지 또는 바인딩할 수 있는지 확인한다. - 익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`. + 익스텐션 포인트: `preFilter`, `filter`, `reserve`, `preBind`, `score`. {{< note >}} - `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이 + `score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이 활성화되어 있어야 활성화되며, 요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다. {{< /note >}} - `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 제한 사항을 충족하는지 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `VolumeZone`: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `NodeVolumeLimits`: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `EBSLimits`: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `GCEPDLimits`: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `AzureDiskLimits`: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `filter`. - `InterPodAffinity`: [파드 간 어피니티 및 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 구현한다. - 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`. + 익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`. - `PrioritySort`: 기본 우선 순위 기반 정렬을 제공한다. - 익스텐션 포인트: `QueueSort`. + 익스텐션 포인트: `queueSort`. - `DefaultBinder`: 기본 바인딩 메커니즘을 제공한다. - 익스텐션 포인트: `Bind`. + 익스텐션 포인트: `bind`. - `DefaultPreemption`: 기본 선점 메커니즘을 제공한다. - 익스텐션 포인트: `PostFilter`. + 익스텐션 포인트: `postFilter`. 기본으로 활성화되지 않는 다음의 플러그인을 컴포넌트 구성 API를 통해 활성화할 수도 있다. +- `SelectorSpread`: {{< glossary_tooltip text="Services" term_id="service" >}}, + {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}와 + {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우, + 노드간에 퍼지는 것을 선호한다. + 익스텐션 포인트: `preScore`, `score`. +- `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/) + 볼륨 제한이 충족될 수 있는지 확인한다. + 익스텐션 포인트: `filter`. + +다음 플러그인은 더 이상 사용되지 않으며 `v1beta1`에서만 +사용할 수 있다. + +- `NodeResourcesLeastAllocated`: 리소스 할당이 낮은 노드를 + 선호한다. + Extension points: `score`. - `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를 선호한다. - 익스텐션 포인트: `Score`. + 익스텐션 포인트: `score`. - `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를 선호한다. - 익스텐션 포인트: `Score`. -- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지 - 확인한다. - 익스텐션 포인트: `Filter`. + 익스텐션 포인트: `score`. - `NodeLabel`: Filters and / or scores a node according to configured {{< glossary_tooltip text="label(s)" term_id="label" >}}. 익스텐션 포인트: `Filter`, `Score`. @@ -198,7 +204,10 @@ profiles: 속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지 확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에 분산하는 것을 선호한다. - 익스텐션 포인트: `PreFilter`, `Filter`, `Score`. + 익스텐션 포인트: `preFilter`, `filter`, `score`. +- `NodePreferAvoidPods`: 노드 주석 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라 + 노드의 우선 순위를 지정한다. + 익스텐션 포인트: `score`. ### 여러 프로파일 @@ -211,7 +220,7 @@ profiles: 실행된다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler @@ -243,7 +252,7 @@ profiles: {{< /note >}} {{< note >}} -모든 프로파일은 QueueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며 +모든 프로파일은 `queueSort` 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며 동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을 단 하나만 가질 수 있기 때문이다. {{< /note >}} @@ -253,3 +262,4 @@ profiles: * [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 * [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기 +* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기 \ No newline at end of file diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index c2b9cbbdffee7..1146ba033abf3 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -98,5 +98,5 @@ weight: 10 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기 * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기 -* [kube-scheduler configuration 레퍼런스 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1) 읽어보기 +* [kube-scheduler configuration 레퍼런스 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) 읽어보기 * [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기 diff --git a/content/ko/docs/reference/tools/_index.md b/content/ko/docs/reference/tools/_index.md index 6ac3b1dc82309..b854bc3bd5128 100644 --- a/content/ko/docs/reference/tools/_index.md +++ b/content/ko/docs/reference/tools/_index.md @@ -8,8 +8,7 @@ no_list: true --- -쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다. - +쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 필요한 공통적으로 사용되거나 관련성 있는 여러 내장 도구와 외부 도구를 포함한다. diff --git a/content/ko/docs/reference/using-api/health-checks.md b/content/ko/docs/reference/using-api/health-checks.md index 07857ea5d2ea1..2e00d338a7241 100644 --- a/content/ko/docs/reference/using-api/health-checks.md +++ b/content/ko/docs/reference/using-api/health-checks.md @@ -91,7 +91,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd' {{< feature-state state="alpha" >}} -각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다. +각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다. 개별 체크를 위한 스키마는 `/livez/` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다. `` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다. 이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다. diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index 899c63f6b7e4d..5cf90e840e672 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -121,3 +121,6 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 [클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는 여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는 노드 수를 실행할 수 있도록 도와준다. + +[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)는 +클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다. \ No newline at end of file diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index fb749a23464e5..18c8a9cbb1ec2 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -26,7 +26,7 @@ weight: 20 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. {{< /note >}} -## Cgroup 드라이버 +## cgroup 드라이버 Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. @@ -57,6 +57,38 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. 교체하거나, 자동화를 사용하여 다시 설치한다. {{< /caution >}} +## cgroup v2 + +cgroup v2는 cgroup Linux API의 다음 버전이다. +cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다. + +새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다. + +- API를 더 쉽고 깔끔하게 사용할 수 있음 +- 컨테이너로의 안전한 하위 트리 위임 +- 압력 중지 정보와 같은 새로운 기능 + +일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도, +쿠버네티스는 모든 컨트롤러를 관리하기 위해 +동일한 cgroup 버전만 지원한다. + +systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을 +추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다. + +```shell +# dnf install -y grubby && \ + sudo grubby \ + --update-kernel=ALL \ + --args=”systemd.unified_cgroup_hierarchy=1" +``` + +구성을 적용하려면 노드를 재부팅해야 한다. + +cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서 +cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다. + +cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다. + ### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기 kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면 diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index cae9a85b0abd6..f1c905c98258d 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -1,78 +1,108 @@ --- -reviewers: -title: kubeadm으로 컨트롤 플레인 사용자 정의하기 + + +title: kubeadm API로 컴포넌트 사용자 정의하기 content_type: concept weight: 40 --- +이 페이지는 kubeadm이 배포하는 컴포넌트(component)들을 사용자 정의하는 방법을 다룬다. 컨트롤 플레인 컴포넌트에 +대해서는 `ClusterConfiguration` 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과 +kube-proxy의 경우, `KubeletConfiguration`과 `KubeProxyConfiguration`을 각각 사용할 수 있다. + +이 모든 옵션이 kubeadm 구성 API를 통해 가용하다. +구성의 각 필드 상세 사항은 +[API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 찾아볼 수 있다. + +{{< note >}} +kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지 않는다. +`kube-system/coredns` {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수동으로 +패치하고, 그 이후에 CoreDNS {{< glossary_tooltip text="파드" term_id="pod" >}}를 다시 생성해야 한다. 또는, +기본 CoreDNS 디플로이먼트를 생략하고 자체 변형(variant)을 배포할 수 있다. +더 자세한 사항은 [kubeadm에서 초기화 단계 사용하기](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)을 참고한다. +{{< /note >}} + + + {{< feature-state for_k8s_version="v1.12" state="stable" >}} -kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 -기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다. +## `ClusterConfiguration`의 플래그로 컨트롤 플레인 사용자 정의하기 + +kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러, Etcd와 같은 컨트롤 플레인 컴포넌트에 전달되는 +기본 플래그를 사용자가 덮어쓸 수 있도록 노출한다. +이 컴포넌트는 다음 구조체를 사용하여 정의된다. - `apiServer` - `controllerManager` - `scheduler` +- `etcd` -`extraArgs` 필드는 `key: value` 쌍으로 구성되어 있다. 컨트롤 플레인 구성요소를 위한 플래그를 대체하려면 다음을 수행한다. +이 구조체들은 공통 필드인 `extraArgs`를 포함하며, 이 필드는 `키: 값` 쌍으로 구성된다. +컨트롤 플레인 컴포넌트를 위한 플래그를 덮어쓰려면 다음을 수행한다. -1. 사용자 구성에서 적절한 필드를 추가한다. -2. 필드에 대체할 플래그를 추가한다. +1. 사용자 구성에 적절한 `extraArgs` 필드를 추가한다. +2. `extraArgs` 필드에 플래그를 추가한다. 3. `kubeadm init`에 `--config ` 파라미터를 추가해서 실행한다. -각 필드의 구성에서 자세한 정보를 보려면, -[API 참고 문서](/docs/reference/config-api/kubeadm-config.v1beta2/)에서 확인해 볼 수 있다. - {{< note >}} -`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 저장하여 기본값인 `ClusterConfiguration` 오브젝트를 생성할 수 있다. +`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 +저장하여 기본값들로 구성된 `ClusterConfiguration` 오브젝트를 생성할 수 있다. {{< /note >}} +{{< note >}} +`ClusterConfiguration` 오브젝트는 현재 kubeadm 클러스터에서 전역(global)으로 사용된다. 즉, 사용자가 추가하는 모든 플래그는 +다른 노드에 있는 동일한 컴포넌트에도 모두 적용될 것이다. 다른 노드에서 +컴포넌트별로 개별 구성을 적용하려면 [패치](#patches)를 사용하면 된다. +{{< /note >}} +{{< note >}} +플래그(키)를 복제하거나 동일한 플래그 `--foo`를 여러 번 전달하는 것은 현재 지원하지 않는다. +이 문제를 해결하려면 [패치](#patches)를 사용해야 한다. +{{< /note >}} - - -## APIServer 플래그 +### APIServer 플래그 자세한 내용은 [kube-apiserver 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다. -예시: +사용 예시: + ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.16.0 apiServer: extraArgs: - advertise-address: 192.168.0.103 anonymous-auth: "false" enable-admission-plugins: AlwaysPullImages,DefaultStorageClass audit-log-path: /home/johndoe/audit.log ``` -## 컨트롤러매니저 플래그 +### 컨트롤러매니저 플래그 자세한 내용은 [kube-controller-manager 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다. -예시: +사용 예시: + ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.16.0 controllerManager: extraArgs: cluster-signing-key-file: /home/johndoe/keys/ca.key - bind-address: 0.0.0.0 deployment-controller-sync-period: "50" ``` -## 스케줄러 플래그 +### 스케줄러 플래그 자세한 내용은 [kube-scheduler 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다. -예시: +사용 예시: + ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.16.0 scheduler: @@ -85,3 +115,96 @@ scheduler: readOnly: true pathType: "File" ``` + +### Etcd 플래그 + +자세한 사항은 [etcd 서버 문서](https://etcd.io/docs/)를 확인한다. + +사용 예시: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +etcd: + local: + extraArgs: + election-timeout: 1000 +``` + +## 패치를 통해 컨트롤 플레인 사용자 정의하기 {#patches} + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 대한 `InitConfiguration`과 `JoinConfiguration`에 +전달할 수 있다. 이 패치는 컨트롤 플레인 컴포넌트 메니패스트가 디스크에 기록되기 전에 +최종 사용자 정의 단계로 사용될 수 있다. + +`--config `을 사용하여 이 파일을 `kubeadm init`에 전달할 수 있다. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +nodeRegistration: + patches: + directory: /home/user/somedir +``` + +{{< note >}} +`kubeadm init`의 경우, `---`로 구분된 `ClusterConfiguration`과 `InitConfiguration`을 모두 +포함하는 파일을 전달할 수 있다. +{{< /note >}} + +`--config `을 사용하여 이 파일을 `kubeadm join`에 전달할 수 있다. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +nodeRegistration: + patches: + directory: /home/user/somedir +``` + +디렉토리는 `target[suffix][+patchtype].extension` 형태의 파일을 포함해야 한다. +예를 들면, `kube-apiserver0+merge.yaml` 또는 단순히 `etcd.json`의 형태이다. + +- `target`은 `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` 그리고 `etcd` 중 하나가 될 수 있다. +- `patchtype`은 `strategic`, `merge` 그리고 `json` 중 하나가 될 수 있으며 +[kubectl에서 지원하는](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch) 패치 형식을 준수해야 한다. +`patchtype`의 기본값은 `strategic`이다. +- `extension`은 `json` 또는 `yaml` 중 하나여야 한다. +- `suffix`는 어떤 패치가 먼저 적용되는지를 결정하는 데 사용할 수 있는 영숫자 형태의 +선택적 문자열이다. + +{{< note >}} +`kubeadm upgrade`를 사용하여 kubeadm 노드를 업그레이드하는 경우, 업그레이드 이후에도 +사용자 정의를 유지하려면 동일한 패치를 다시 제공해야 한다. 이는 동일한 디렉토리로 지정된 `--patches` +플래그를 사용하여 처리할 수 있다. `kubeadm upgrade`는 동일 목적으로 재사용할 수 있는 구성 +API 구조를 현재는 지원하지 않는다. +{{< /note >}} + +## kubelet 사용자 정의하기 + +kubelet을 사용자 정의하려면, `KubeletConfiguration`을 동일한 구성 파일 내에서 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration` 다음에 추가하면 +된다. 그런 다음 `kubeadm init`에 해당 파일을 전달한다. + +{{< note >}} +kubeadm은 클러스터의 모든 노드에 동일한 `KubeletConfiguration`을 적용한다. 노드별 설정을 +적용하려면 kubelet 플래그를 덮어쓰기(overrides)로 사용하여, `InitConfiguration` 및 +`JoinConfiguration` 모두에서 지원되는 `nodeRegistration.kubeletExtraArgs`에 전달할 수 있다. +일부 kubelet 플래그는 더 이상 사용되지 않는다(deprecated). 따라서 사용하기 전에 [kubelet 참조 문서](/docs/reference/command-line-tools-reference/kubelet)를 통해 +상태를 확인해야 한다. +{{< /note >}} + +자세한 사항은 [kubeadm을 통해 클러스터의 각 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)에서 살펴본다. + +## kube-proxy 사용자 정의하기 + +kube-proxy를 사용자 정의하려면, `KubeProxyConfiguration`을 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration` +다음에 두고 `kubeadm init`에 전달하면 된다. + +자세한 사항은 [API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 살펴볼 수 있다. + +{{< note >}} +kubeadm은 kube-proxy를 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로 배포한다. 이것은 +`KubeProxyConfiguration`이 클러스터의 모든 kube-proxy 인스턴스에 적용된다는 것을 의미한다. +{{< /note >}} diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 6f50124f8d837..3138aad1f8a68 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -239,8 +239,9 @@ CNI 플러그인 설치(대부분의 파드 네트워크에 필요) ```bash CNI_VERSION="v0.8.2" +ARCH="amd64" sudo mkdir -p /opt/cni/bin -curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz ``` 명령어 파일을 다운로드할 디렉터리 정의 @@ -259,15 +260,17 @@ crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에 ```bash CRICTL_VERSION="v1.17.0" -curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz +ARCH="amd64" +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` `kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가 ```bash RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" +ARCH="amd64" cd $DOWNLOAD_DIR -sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} sudo chmod +x {kubeadm,kubelet,kubectl} RELEASE_VERSION="v0.4.0" diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index 67db901778444..c4cc773ad9bcf 100644 --- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -67,10 +67,9 @@ weight: 65 | 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 | | --- | --- | --- | --- | -| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | | *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | | *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | - +| *Kubernetes v1.22* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | 지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 @@ -98,12 +97,16 @@ weight: 65 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, 제한 및 호환성 규칙이 변경될 것이다. -#### 퍼즈(Pause) 이미지 +#### 퍼즈(Pause) 이미지 {#pause-image} + +쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다. +쿠버네티스 v1.22의 경우 권장 퍼즈 이미지는 `k8s.gcr.io/pause:3.5`이다. +[소스 코드](https://github.com/kubernetes/kubernetes/tree/master/build/pause)는 +GitHub에서 찾을 수 있다. -Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1`에서 -윈도우 퍼즈 인프라 컨테이너를 유지한다. -이외에도 `k8s.gcr.io/pause:3.5`를 통해 쿠버네티스에서 관리하는 다중 아키텍처 이미지를 -사용할 수도 있는데, 이 이미지는 리눅스와 윈도우를 모두 지원한다. +Microsoft는 리눅스, 윈도우 amd64를 지원하는 다중 아키텍처 이미지를 `mcr.microsoft.com/oss/kubernetes/pause:3.5`에서 유지보수하고 있다. +이 이미지는 쿠버네티스가 유지 관리하는 이미지와 동일한 소스코드에서 생성되었지만, 모든 윈도우 바이너리는 Microsoft에 의해 서명된 [인증 코드](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode)이다. +프로덕션 환경에서 서명된 바이너리가 필요한 경우, Microsoft가 유지 관리하는 이미지를 사용하는 것을 권장한다. #### 컴퓨트 @@ -237,7 +240,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume ##### CSI 플러그인 -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} {{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) @@ -246,9 +249,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 -다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 -일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 -플러그인으로 구성된다. +다양한 볼륨 관리 작업을 처리한다. CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 @@ -262,6 +263,13 @@ CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에 내용은 배포하려는 CSI 플러그인의 배포 가이드를 참조한다. +윈도우 노드에서 CSI 노드 플러그인은 일반적으로 로컬 스토리지 작업을 처리하는 +커뮤니티에서 관리하는 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)에 의해 노출된 API를 호출한다. + +설치에 대한 자세한 내용은 윈도우 CSI 플러그인을 +배포할 환경의 배포 가이드를 참고한다. +또한 다음 [설치 단계](https://github.com/kubernetes-csi/csi-proxy#installation)를 참고할 수도 있다. + #### 네트워킹 윈도우 컨테이너용 네트워킹은 @@ -1068,9 +1076,8 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 kubelet.exe를 등록한다. ```powershell - # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다. nssm install kubelet C:\k\kubelet.exe - nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config + nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config nssm set kubelet AppDirectory C:\k nssm start kubelet ``` @@ -1224,13 +1231,13 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 * 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다. - pause 이미지가 OS 버전과 호환되는지 확인한다. + 퍼즈 이미지가 OS 버전과 호환되는지 확인한다. [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. - 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 + 그럼에도 불구하고, 퍼즈 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다. * DNS 확인(resolution)이 제대로 작동하지 않는다. @@ -1239,12 +1246,18 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 * `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다. - 이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 + 이는 쿠버네티스 1.15 및 퍼즈 인프라 컨테이너 `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다. - 해당 버전 또는 최신 버전을 사용해야 한다. 자체 pause + 해당 버전 또는 최신 버전을 사용해야 한다. 자체 퍼즈 인프라 컨테이너를 빌드하려면 [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다. + 윈도우에서 포트 포워딩을 지원하려면 [퍼즈 인프라 컨테이너](#pause-image)를 이용하기 위해서 + wincat.exe가 필요하다. + 윈도우 OS 버전과 호환되는 지원되는 이미지를 사용하고 있는지 확인해야 한다. + 자신만의 퍼즈 인프라 컨테이너를 구축하려면 + [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat)을 포함해야 한다. + * 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 설치가 실패한다. @@ -1256,20 +1269,18 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) ``` -* `pause` 컨테이너란 무엇인가? +* 퍼즈(`pause`) 컨테이너란 무엇인가? 쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 - 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 + 먼저 인프라 또는 "퍼즈" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 - 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 + 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 퍼즈 컨테이너가 필요하다. - "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 - 호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다. - 자세한 내용은 - [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다. - + 퍼즈 이미지 추천 버전을 찾기 위해서는 + [퍼즈 이미지](#pause-image)를 참고한다. + ### 추가 조사 이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index 5c3d52e475507..2e1694834e187 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -20,8 +20,8 @@ weight: 75 ## 시작하기 전에 -* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 -포함한 쿠버네티스 클러스터를 생성한다. +* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를 +포함하는 쿠버네티스 클러스터를 생성한다. * 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. @@ -100,15 +100,15 @@ spec: 1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자. * 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다. - * 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다. - * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을 + * 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다. + * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. * 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다). - * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 + * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다. * 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다. - * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. + * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 `curl`을 실행한다. * 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. {{< note >}} @@ -178,8 +178,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동 예를 들면, `--register-with-taints='os=windows:NoSchedule'` 모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). -윈도우 파드가 윈도우 노드에 스케줄링되려면, -윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다. +윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면, +윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다. ```yaml nodeSelector: diff --git a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index 333001af81530..6aa257dca4c95 100644 --- a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -31,7 +31,7 @@ min-kubernetes-server-version: v1.10 1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml ``` 성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다. @@ -84,7 +84,7 @@ min-kubernetes-server-version: v1.10 2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml ``` 성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다. diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md index 2d44a51b0e24c..41b2225549816 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -30,7 +30,7 @@ content_type: task kubectl config view ``` -많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를 +많은 [예제](https://github.com/kubernetes/examples/tree/master/)는 kubectl 사용에 대한 소개를 제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다. ### REST API에 직접 접근 diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md index f681bc8778d36..8d67bea2db867 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -23,7 +23,7 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한 ## 소개 -DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 +DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/master/cluster/addons/README.md)을 사용하여 자동으로 시작되는 쿠버네티스 내장 서비스이다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index e67a08a74e84b..d70669a93e9e8 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -157,10 +157,10 @@ Install-WindowsFeature -Name containers #### wins, kubelet 및 kubeadm 설치 - ```PowerShell - curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 - .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} - ``` +```PowerShell +curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 +.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} +``` #### `kubeadm` 실행하여 노드에 조인 @@ -201,7 +201,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates #### wins, kubelet 및 kubeadm 설치 ```PowerShell -curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 +curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD ``` diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index de6feb480df32..fe34d7a7f70e7 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -126,7 +126,17 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서 `kubeadm certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다. -이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다. +이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다. + +명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다. +이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다. +[스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)는 API 서버가 아닌 로컬 kubelet에서 관리되므로 +kubectl을 사용하여 삭제 및 재시작할 수 없다. +스태틱 파드를 다시 시작하려면 `/etc/kubernetes/manifests/`에서 매니페스트 파일을 일시적으로 제거하고 +20초를 기다리면 된다 ([KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)의 `fileCheckFrequency` 값을 참고한다). +파드가 매니페스트 디렉터리에 더 이상 없는 경우 kubelet은 파드를 종료한다. +그런 다음 파일을 다시 이동할 수 있으며 또 다른 `fileCheckFrequency` 기간이 지나면, +kubelet은 파드를 생성하고 구성 요소에 대한 인증서 갱신을 완료할 수 있다. {{< warning >}} HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다. @@ -161,10 +171,10 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다. -새 클러스터를 생성하는 경우, kubeadm [구성 파일](/docs/reference/config-api/kubeadm-config.v1beta2/)을 사용할 수 있다. +새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)을 사용할 수 있다. ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration controllerManager: extraArgs: @@ -223,7 +233,7 @@ TLS로 보안되지 않음을 의미한다. 다음의 최소 구성을 `kubeadm init` 에 전달해야 한다. ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration --- apiVersion: kubelet.config.k8s.io/v1beta1 diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index eb953143bef8d..4a6a769556476 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -22,44 +22,59 @@ weight: 20 실리움에 쉽게 친숙해지기 위해 Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는 -[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다. +[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)를 따라 해볼 수 있다. -Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고, +Minikube를 시작하려면 최소 버전으로 >= v1.5.2 이 필요하고, 다음의 실행 파라미터로 실행한다. ```shell minikube version ``` ``` -minikube version: v1.3.1 +minikube version: v1.5.2 ``` ```shell -minikube start --network-plugin=cni --memory=4096 +minikube start --network-plugin=cni ``` -BPF 파일시스템을 마운트한다 +minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다. +실리움은 클러스터 구성을 자동으로 감지하고 +성공적인 설치를 위해 적절한 구성 요소를 설치한다. ```shell -minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf +curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz +sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin +rm cilium-linux-amd64.tar.gz +cilium install ``` -Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을 -간단한 ``올인원`` YAML 파일로 배포할 수 있다. - ```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml -``` -``` -configmap/cilium-config created -serviceaccount/cilium created -serviceaccount/cilium-operator created -clusterrole.rbac.authorization.k8s.io/cilium created -clusterrole.rbac.authorization.k8s.io/cilium-operator created -clusterrolebinding.rbac.authorization.k8s.io/cilium created -clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created -daemonset.apps/cilium create -deployment.apps/cilium-operator created +🔮 Auto-detected Kubernetes kind: minikube +✨ Running "minikube" validation checks +✅ Detected minikube version "1.20.0" +ℹ️ Cilium version not set, using default version "v1.10.0" +🔮 Auto-detected cluster name: minikube +🔮 Auto-detected IPAM mode: cluster-pool +🔮 Auto-detected datapath mode: tunnel +🔑 Generating CA... +2021/05/27 02:54:44 [INFO] generate received request +2021/05/27 02:54:44 [INFO] received CSR +2021/05/27 02:54:44 [INFO] generating key: ecdsa-256 +2021/05/27 02:54:44 [INFO] encoded CSR +2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642 +🔑 Generating certificates for Hubble... +2021/05/27 02:54:44 [INFO] generate received request +2021/05/27 02:54:44 [INFO] received CSR +2021/05/27 02:54:44 [INFO] generating key: ecdsa-256 +2021/05/27 02:54:44 [INFO] encoded CSR +2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574 +🚀 Creating Service accounts... +🚀 Creating Cluster roles... +🚀 Creating ConfigMap... +🚀 Creating Agent DaemonSet... +🚀 Creating Operator Deployment... +⌛ Waiting for Cilium to be installed... ``` 시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여 @@ -82,14 +97,14 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, H 파드의 목록을 보려면 다음을 실행한다. ```shell -kubectl get pods --namespace=kube-system +kubectl get pods --namespace=kube-system -l k8s-app=cilium ``` 다음과 유사한 파드의 목록을 볼 것이다. ```console -NAME READY STATUS RESTARTS AGE -cilium-6rxbd 1/1 Running 0 1m +NAME READY STATUS RESTARTS AGE +cilium-kkdhz 1/1 Running 0 3m23s ... ``` diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md index 8b3f62217efaf..7a5e502c47600 100644 --- a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md +++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -67,7 +67,7 @@ kubectl create secret generic db-user-pass \ 다음 커맨드를 실행한다. ```shell -kubectl create secret generic dev-db-secret \ +kubectl create secret generic db-user-pass \ --from-literal=username=devuser \ --from-literal=password='S!B\*d$zDsb=' ``` diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md new file mode 100644 index 0000000000000..0145967dd8828 --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -0,0 +1,340 @@ +--- + + + +title: 동작 중인 파드 디버그 +content_type: task +--- + + + +이 페이지는 노드에서 동작 중인(혹은 크래시된) 파드를 디버그하는 방법에 대해 설명한다. + + + +## {{% heading "prerequisites" %}} + + +* 여러분의 {{< glossary_tooltip text="파드" term_id="pod" >}}는 이미 스케줄링 되어 + 동작하고 있을 것이다. 만약 파드가 아직 동작중이지 않다면, [애플리케이션 + 트러블슈팅](/docs/tasks/debug-application-cluster/debug-application/)을 참고한다. +* 일부 고급 디버깅 과정에서는 해당 파드가 어떤 노드에서 동작하고 있는지 + 알아야 하고, 해당 노드에서 쉘 명령어를 실행시킬 수 있어야 한다. + `kubectl`을 사용하는 일반적인 디버깅 과정에서는 이러한 접근 권한이 필요하지 않다. + + + + + +## 파드의 로그 확인하기 {#examine-pod-logs} + +먼저, 확인하고자 하는 컨테이너의 로그를 확인한다. + +```shell +kubectl logs ${POD_NAME} ${CONTAINER_NAME} +``` + +만약 컨테이너가 이전에 크래시 되었다면, 다음의 명령을 통해 컨테이너의 크래시 로그를 살펴볼 수 있다. + +```shell +kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME} +``` + +## exec를 통해 컨테이너 디버깅하기 {#container-exec} + +만약 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에 +디버깅 도구가 포함되어 있다면, `kubectl exec`을 통해 특정 컨테이너에서 해당 명령들을 +실행할 수 있다. (리눅스나 윈도우 OS를 기반으로 만들어진 이미지에는 대부분 디버깅 도구를 포함하고 +있다.) + +```shell +kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN} +``` + +{{< note >}} +`-c ${CONTAINER_NAME}` 인자는 선택적이다. 만약 하나의 컨테이너만 포함된 파드라면 해당 옵션을 생략할 수 있다. +{{< /note >}} + +예를 들어, 동작 중인 카산드라 파드의 로그를 살펴보기 위해서는 다음과 같은 명령을 실행할 수 있다. + +```shell +kubectl exec cassandra -- cat /var/log/cassandra/system.log +``` + +`kubectl exec`에 `-i`와 `-t` 옵션을 사용해서 터미널에서 접근할 수 있는 쉘을 실행시킬 수도 있다. +예를 들면 다음과 같다. + +```shell +kubectl exec -it cassandra -- sh +``` + +더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기]( +/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라. + +## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container} + +{{< feature-state state="alpha" for_k8s_version="v1.18" >}} + +컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼 +컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아 +`kubectl exec`가 충분하지 않을 경우에는 +{{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이 +인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18` +버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의 +명령어가 있다. + +### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example} + +{{< note >}} +이 섹션에서 소개하는 예시를 사용하기 위해서는 +여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다. +{{< /note >}} + +`kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다. +먼저, 다음과 같이 파드를 추가한다. + +```shell +kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never +``` + +이 섹션의 예시에서는 디버깅 도구가 포함되지 않은 이미지의 사례를 보여드리기 위해 +`pause` 컨테이너 이미지를 사용했는데, 이 대신 어떠한 이미지를 사용해도 +될 것이다. + +만약 `kubectl exec`을 통해 쉘을 생성하려 한다면 다음과 같은 에러를 +확인할 수 있을 텐데, 그 이유는 이 이미지에 쉘이 존재하지 않기 때문이다. + +```shell +kubectl exec -it ephemeral-demo -- sh +``` + +``` +OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown +``` + +이 명령어 대신 `kubectl debug`을 사용해서 디버깅 컨테이너를 생성할 수 있다. +만약 `-i`/`--interactive` 인자를 사용한다면, `kubectl`은 임시 +컨테이너의 콘솔에 자동으로 연결할 것이다. + +```shell +kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo +``` + +``` +Defaulting debug container name to debugger-8xzrl. +If you don't see a command prompt, try pressing enter. +/ # +``` + +이 명령어는 새로운 busybox 컨테이너를 추가하고 해당 컨테이너로 연결한다. `--target` +파라미터를 사용하면 다른 컨테이너의 프로세스 네임스페이스를 대상으로 하게 된다. 여기서는 +이 옵션이 꼭 필요한데, `kubectl run`이 생성하는 파드에 대해 +[프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 +활성화하지 않기 때문이다. + +{{< note >}} +`--target` 파라미터는 사용 중인 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}에서 +지원해야지만 사용할 수 있다. 만일 지원되지 않는다면, +임시 컨테이너가 시작되지 않을 수 있거나 독립적인 프로세스 +네임스페이스를 가지고 시작될 수 있다. +{{< /note >}} + +`kubectl describe` 명령을 사용하면 새롭게 생성된 임시 컨테이너의 상태를 확인할 수 있다. + +```shell +kubectl describe pod ephemeral-demo +``` + +``` +... +Ephemeral Containers: + debugger-8xzrl: + Container ID: docker://b888f9adfd15bd5739fefaa39e1df4dd3c617b9902082b1cfdc29c4028ffb2eb + Image: busybox + Image ID: docker-pullable://busybox@sha256:1828edd60c5efd34b2bf5dd3282ec0cc04d47b2ff9caa0b6d4f07a21d1c08084 + Port: + Host Port: + State: Running + Started: Wed, 12 Feb 2020 14:25:42 +0100 + Ready: False + Restart Count: 0 + Environment: + Mounts: +... +``` + +디버깅이 다 끝나면 `kubectl delete`을 통해 파드를 제거할 수 있다. + +```shell +kubectl delete pod ephemeral-demo +``` + +## 파드의 복제본을 이용해서 디버깅하기 + +때때로 파드의 설정 옵션에 따라 특정 상황에서 트러블슈팅을 하기가 어려울 수 있다. +예를 들어, 만일 여러분의 컨테이너 이미지가 쉘을 포함하고 있지 않거나, 여러분의 +애플리케이션이 컨테이너 시작에서 크래시가 발생한다면 `kubectl exec`을 이용해서 +컨테이너를 트러블슈팅할 수 없을 수 있다. 이러한 상황에서는 `kubectl debug`을 사용해서 +파드의 복제본을 디버깅을 위한 추가적인 설정 옵션과 함께 생성할 수 있다. + +### 새 컨테이너와 함께 파드의 복제본 생성하기 + +만일 여러분의 애플리케이션이 동작은 하고 있지만 예상과는 다르게 동작하는 경우, +파드의 복제본에 새로운 컨테이너를 추가함으로써 추가적인 트러블슈팅 도구들을 +파드에 함께 추가할 수 있다. + +가령, 여러분의 애플리케이션 컨테이너 이미지는 `busybox`를 기반으로 하고 있는데 +여러분은 `busybox`에는 없는 디버깅 도구를 필요로 한다고 가정해 보자. 이러한 +시나리오는 `kubectl run` 명령을 통해 시뮬레이션 해볼 수 있다. + +```shell +kubectl run myapp --image=busybox --restart=Never -- sleep 1d +``` + +다음의 명령을 실행시켜 디버깅을 위한 새로운 우분투 컨테이너와 함께 `myapp-debug`이란 +이름의 `myapp` 컨테이너 복제본을 생성할 수 있다. + +```shell +kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug +``` + +``` +Defaulting debug container name to debugger-w7xmf. +If you don't see a command prompt, try pressing enter. +root@myapp-debug:/# +``` + +{{< note >}} +* 만일 여러분이 새로 생성되는 컨테이너의 이름을 `--container` 플래그와 함께 지정하지 않는다면, + `kubectl debug`는 자동으로 새로운 컨테이너 이름을 생성한다. +* `-i` 플래그를 사용하면 `kubectl debug` 명령이 새로운 컨테이너에 기본적으로 연결되게 된다. + 이러한 동작은 `--attach=false`을 지정하여 방지할 수 있다. 만일 여러분의 세션이 + 연결이 끊어진다면 `kubectl attach`를 사용해서 다시 연결할 수 있다. +* `--share-processes` 옵션은 이 파드에 있는 컨테이너가 해당 파드에 속한 다른 컨테이너의 + 프로세스를 볼 수 있도록 한다. 이 옵션이 어떻게 동작하는지에 대해 더 알아보기 위해서는 + 다음의 [파드의 컨테이너 간 프로세스 네임스페이스 공유]( + /docs/tasks/configure-pod-container/share-process-namespace/)를 참고하라. +{{< /note >}} + +사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다. + +```shell +kubectl delete pod myapp myapp-debug +``` + +### 명령어를 변경하며 파드의 복제본 생성하기 + +때때로 컨테이너의 명령어를 변경하는 것이 유용한 경우가 있는데, 예를 들면 디버그 플래그를 추가하기 +위해서나 애플리케이션이 크래시 되는 경우이다. + +다음의 `kubectl run` 명령을 통해 즉각적으로 크래시가 발생하는 애플리케이션의 +사례를 시뮬레이션해 볼 수 있다. + +``` +kubectl run --image=busybox myapp -- false +``` + +`kubectl describe pod myapp` 명령을 통해 이 컨테이너에 크래시가 발생하고 있음을 확인할 수 있다. + +``` +Containers: + myapp: + Image: busybox + ... + Args: + false + State: Waiting + Reason: CrashLoopBackOff + Last State: Terminated + Reason: Error + Exit Code: 1 +``` + +이러한 경우에 `kubectl debug`을 통해 명령어를 지정함으로써 해당 파드의 +복제본을 인터랙티브 쉘로 생성할 수 있다. + +``` +kubectl debug myapp -it --copy-to=myapp-debug --container=myapp -- sh +``` + +``` +If you don't see a command prompt, try pressing enter. +/ # +``` + +이제 인터랙티브 쉘에 접근할 수 있으니 파일 시스템 경로를 확인하거나 +동작 중인 컨테이너의 명령어를 직접 확인하는 등의 작업이 가능하다. + +{{< note >}} +* 특정 컨테이너의 명령어를 변경하기 위해서는 `--container` 옵션을 통해 해당 컨테이너의 + 이름을 지정해야만 한다. 이름을 지정하지 않는다면 `kubectl debug`은 이전에 지정한 명령어를 + 그대로 사용해서 컨테이너를 생성할 것이다. +* 기본적으로 `-i` 플래그는 `kubectl debug` 명령이 컨테이너에 바로 연결되도록 한다. + 이러한 동작을 방지하기 위해서는 `--attach=false` 옵션을 지정할 수 있다. 만약 여러분이 세션이 + 종료된다면 `kubectl attach` 명령을 통해 다시 연결할 수 있다. +{{< /note >}} + +사용이 모두 끝나면, 디버깅에 사용된 파드들을 잊지 말고 정리한다. + +```shell +kubectl delete pod myapp myapp-debug +``` + +### 컨테이너 이미지를 변경하며 파드의 복제본 생성하기 + +특정한 경우에 여러분은 제대로 동작하지 않는 파드의 이미지를 +기존 프로덕션 컨테이너 이미지에서 디버깅 빌드나 추가적인 도구를 포함한 +이미지로 변경하고 싶을 수 있다. + +이 사례를 보여주기 위해 `kubectl run` 명령을 통해 파드를 생성하였다. + +``` +kubectl run myapp --image=busybox --restart=Never -- sleep 1d +``` + +여기서는 `kubectl debug` 명령을 통해 해당 컨테이너 이미지를 `ubuntu`로 변경하며 +복제본을 생성하였다. + +``` +kubectl debug myapp --copy-to=myapp-debug --set-image=*=ubuntu +``` + +`--set-image`의 문법은 `kubectl set image`와 동일하게 `container_name=image` +형식의 문법을 사용한다. `*=ubuntu`라는 의미는 모든 컨테이너의 이미지를 `ubuntu`로 +변경하겠다는 의미이다. + +사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다. + +```shell +kubectl delete pod myapp myapp-debug +``` + +## 노드의 쉘을 사용해서 디버깅하기 {#node-shell-session} + +만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아 +호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다. +다음 `kubectl debug` 명령을 통해 해당 노드에서 인터랙티브한 쉘을 생성할 수 있다. + +```shell +kubectl debug node/mynode -it --image=ubuntu +``` + +``` +Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode. +If you don't see a command prompt, try pressing enter. +root@ek8s:/# +``` + +노드에서 디버깅 세션을 생성할 때 유의해야 할 점은 다음과 같다. + +* `kubectl debug`는 노드의 이름에 기반해 새로운 파드의 이름을 + 자동으로 생성한다. +* 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다. +* 노드의 루트 파일시스템은 `/host`에 마운트된다. + +사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다. + +```shell +kubectl delete pod node-debugger-mynode-pdx84 +``` diff --git a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md new file mode 100644 index 0000000000000..34a91a600cf04 --- /dev/null +++ b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md @@ -0,0 +1,77 @@ +--- +title: 종속 환경 변수 정의하기 +content_type: task +weight: 20 +--- + + + +본 페이지는 쿠버네티스 파드의 컨테이너를 위한 종속 환경 변수를 +정의하는 방법에 대해 설명한다. + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} + + + + +## 컨테이너를 위한 종속 환경 변수 정의하기 + +파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다. +종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다. + +이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다. + +{{< codenew file="pods/inject/dependent-envars.yaml" >}} + +1. YAML 구성 파일을 활용해 파드를 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml + ``` + ``` + pod/dependent-envars-demo created + ``` + +2. 실행 중인 파드의 목록을 조회한다. + + ```shell + kubectl get pods dependent-envars-demo + ``` + ``` + NAME READY STATUS RESTARTS AGE + dependent-envars-demo 1/1 Running 0 9s + ``` + +3. 파드 안에서 동작 중인 컨테이너의 로그를 확인한다. + + ```shell + kubectl logs pod/dependent-envars-demo + ``` + ``` + + UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + SERVICE_ADDRESS=https://172.17.0.1:80 + ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80 + ``` + +위에서 보듯이, `SERVICE_ADDRESS`는 올바른 종속성 참조, `UNCHANGED_REFERENCE`는 잘못된 종속성 참조를 정의했으며 `ESCAPED_REFERENCE`는 종속성 참조를 건너뛴다. + +환경 변수가 참조될 때 해당 환경 변수가 미리 정의되어 있으면 `SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다. + +환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다. +일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다. + +`$(VAR_NAME)` 구문은 이중 $로 이스케이프될 수 있다. (예: `$$(VAR_NAME)`) +이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다. +이는 위의 `ESCAPED_REFERENCE`를 통해 확인할 수 있다. + +## {{% heading "whatsnext" %}} + + +* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다. +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다. + diff --git a/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md new file mode 100644 index 0000000000000..0ff081f99ac78 --- /dev/null +++ b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md @@ -0,0 +1,256 @@ +--- +title: 시크릿(Secret)을 사용하여 안전하게 자격증명 배포하기 +content_type: task +weight: 50 +min-kubernetes-server-version: v1.6 +--- + + +본 페이지는 암호 및 암호화 키와 같은 민감한 데이터를 파드에 안전하게 +주입하는 방법을 설명한다. + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} + +### 시크릿 데이터를 base-64 표현으로 변환하기 + +사용자 이름 `my-app`과 비밀번호 `39528$vdg7Jb`의 두 가지 시크릿 데이터가 필요하다고 가정한다. +먼저 base64 인코딩 도구를 사용하여 사용자 이름과 암호를 base64 표현으로 변환한다. 다음은 일반적으로 사용 가능한 base64 프로그램을 사용하는 예제이다. + +```shell +echo -n 'my-app' | base64 +echo -n '39528$vdg7Jb' | base64 +``` + +사용자 이름의 base-64 표현이 `bXktYXBw`이고 암호의 base-64 표현이 `Mzk1MjgkdmRnN0pi`임을 +출력을 통해 확인할 수 있다. + +{{< caution >}} +사용자의 OS가 신뢰하는 로컬 툴을 사용하여 외부 툴의 보안 위험을 줄이자. +{{< /caution >}} + + + +## 시크릿 생성하기 + +다음은 사용자 이름과 암호가 들어 있는 시크릿을 생성하는 데 사용할 수 있는 +구성 파일이다. + +{{< codenew file="pods/inject/secret.yaml" >}} + +1. 시크릿을 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml + ``` + +2. 시크릿에 대한 정보를 확인한다. + + ```shell + kubectl get secret test-secret + ``` + + Output: + + ``` + NAME TYPE DATA AGE + test-secret Opaque 2 1m + ``` + +3. 시크릿에 대한 자세한 정보를 확인한다. + + ```shell + kubectl describe secret test-secret + ``` + + Output: + + ``` + Name: test-secret + Namespace: default + Labels: + Annotations: + + Type: Opaque + + Data + ==== + password: 13 bytes + username: 7 bytes + ``` + +### kubectl로 직접 시크릿 생성하기 + +Base64 인코딩 단계를 건너뛰려면 `kubectl create secret` 명령을 사용하여 +동일한 Secret을 생성할 수 있다. 다음은 예시이다. + +```shell +kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb' +``` + +이와 같이 더 편리하게 사용할 수 있다. 앞에서 설명한 자세한 접근 방식은 각 단계를 +명시적으로 실행하여 현재 상황을 확인할 수 있다. + + +## 볼륨을 통해 시크릿 데이터에 접근할 수 있는 파드 생성하기 + +다음은 파드를 생성하는 데 사용할 수 있는 구성 파일이다. + +{{< codenew file="pods/inject/secret-pod.yaml" >}} + +1. 파드를 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml + ``` + +2. 파드가 실행중인지 확인한다. + + ```shell + kubectl get pod secret-test-pod + ``` + + Output: + ``` + NAME READY STATUS RESTARTS AGE + secret-test-pod 1/1 Running 0 42m + ``` + +3. 파드에서 실행 중인 컨테이너의 셸을 가져오자. + ```shell + kubectl exec -i -t secret-test-pod -- /bin/bash + ``` + +4. 시크릿 데이터는 `/etc/secret-volume`에 마운트된 볼륨을 통해 +컨테이너에 노출된다. + + 셸에서 `/etc/secret-volume` 디렉터리의 파일을 나열한다. + ```shell + # 컨테이너 내부의 셸에서 실행하자 + ls /etc/secret-volume + ``` + 두 개의 파일과 각 파일의 시크릿 데이터 조각을 확인할 수 있다. + ``` + password username + ``` + +5. 셸에서 `username` 및 `password` 파일의 내용을 출력한다. + ```shell + # 컨테이너 내부의 셸에서 실행하자 + echo "$( cat /etc/secret-volume/username )" + echo "$( cat /etc/secret-volume/password )" + ``` + 사용자 이름과 비밀번호가 출력된다. + ``` + my-app + 39528$vdg7Jb + ``` + +## 시크릿 데이터를 사용하여 컨테이너 환경 변수 정의하기 + +### 단일 시크릿 데이터로 컨테이너 환경 변수 정의하기 + +* 환경 변수를 시크릿의 키-값 쌍으로 정의한다. + + ```shell + kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' + ``` + +* 시크릿에 정의된 `backend-username` 값을 파드 명세의 `SECRET_USERNAME` 환경 변수에 할당한다. + + {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}} + +* 파드를 생성한다. + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml + ``` + +* 셸에서 `SECRET_USERNAME` 컨테이너 환경 변수의 내용을 출력한다. + + ```shell + kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME' + ``` + + 출력은 다음과 같다. + ``` + backend-admin + ``` + +### 여러 시크릿 데이터로 컨테이너 환경 변수 정의하기 + +* 이전 예제와 마찬가지로 시크릿을 먼저 생성한다. + + ```shell + kubectl create secret generic backend-user --from-literal=backend-username='backend-admin' + kubectl create secret generic db-user --from-literal=db-username='db-admin' + ``` + +* 파드 명세에 환경 변수를 정의한다. + + {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}} + +* 파드를 생성한다. + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml + ``` + +* 셸에서 컨테이너 환경 변수를 출력한다. + + ```shell + kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME' + ``` + 출력은 다음과 같다. + ``` + DB_USERNAME=db-admin + BACKEND_USERNAME=backend-admin + ``` + + +## 시크릿의 모든 키-값 쌍을 컨테이너 환경 변수로 구성하기 + +{{< note >}} +이 기능은 쿠버네티스 v1.6 이상에서 사용할 수 있다. +{{< /note >}} + +* 여러 키-값 쌍을 포함하는 시크릿을 생성한다. + + ```shell + kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb' + ``` + +* envFrom을 사용하여 시크릿의 모든 데이터를 컨테이너 환경 변수로 정의한다. 시크릿의 키는 파드에서 환경 변수의 이름이 된다. + + {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}} + +* 파드를 생성한다. + + ```shell + kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml + ``` + +* `username` 및 `password` 컨테이너 환경 변수를 셸에서 출력한다. + + ```shell + kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"' + ``` + + 출력은 다음과 같다. + ``` + username: my-app + password: 39528$vdg7Jb + ``` + +### 참고 + +* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) +* [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + +## {{% heading "whatsnext" %}} + +* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기. +* [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 더 배워 보기. diff --git a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md new file mode 100644 index 0000000000000..2a8a206d6d9df --- /dev/null +++ b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -0,0 +1,259 @@ +--- +title: 파일로 컨테이너에 파드 정보 노출하기 +content_type: task +weight: 40 +--- + + + +본 페이지는 파드가 DownwardAPIVolumeFile을 사용하여 파드에서 실행되는 컨테이너에 +자신에 대한 정보를 노출하는 방법에 대해 설명한다. DownwardAPIVolumeFile은 파드 필드와 +컨테이너 필드를 노출할 수 있다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## 다운워드(Downward) API + +실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다. + +* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api) +* 볼륨 파일 + +파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다. + +## 파드 필드 저장 + +이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다. +다음은 파드에 대한 구성 파일이다. + +{{< codenew file="pods/inject/dapi-volume.yaml" >}} + +구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너가 `/etc/podinfo`에 볼륨을 마운트하는 +것을 확인할 수 있다. + +`downwardAPI` 아래의 배열을 살펴보자. 배열의 각 요소는 +[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다. +첫 번째 요소는 파드의 `metadata.labels` 필드 값이 `labels`라는 파일에 저장되어야 함을 지정한다. +두 번째 요소는 파드의 `annotations` 필드 값이 `annotations`라는 파일에 저장되어야 함을 지정한다. + +{{< note >}} +이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다. +{{< /note >}} + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml +``` + +파드의 컨테이너가 실행 중인지 확인한다. + +```shell +kubectl get pods +``` + +컨테이너의 로그를 본다. + +```shell +kubectl logs kubernetes-downwardapi-volume-example +``` + +출력은 `labels` 파일과 `annotations` 파일의 내용을 보여준다. + +```shell +cluster="test-cluster1" +rack="rack-22" +zone="us-est-coast" + +build="two" +builder="john-doe" +``` + +파드에서 실행 중인 컨테이너의 셸을 가져오자. + +```shell +kubectl exec -it kubernetes-downwardapi-volume-example -- sh +``` + +셸에서 `labels` 파일을 보자. + +```shell +/# cat /etc/podinfo/labels +``` + +출력을 통해 모든 파드의 레이블이 `labels` 파일에 기록되었음을 확인할 수 있다. + +```shell +cluster="test-cluster1" +rack="rack-22" +zone="us-est-coast" +``` + +마찬가지로 `annotations` 파일을 확인하자. + +```shell +/# cat /etc/podinfo/annotations +``` + +`etc/podinfo` 디렉터리에 파일을 확인하자. + +```shell +/# ls -laR /etc/podinfo +``` + +출력에서 `labels` 및 `annotations` 파일이 +임시 하위 디렉터리에 있음을 알 수 있다. 이 예제에서는 +`..2982_06_02_21_47_53.299460680`이다. `/etc/podinfo` 디렉터리에서 `..data`는 +임시 하위 디렉토리에 대한 심볼릭 링크이다. `/etc/podinfo` 디렉토리에서 +`labels`와 `annotations` 또한 심볼릭 링크이다. + +``` +drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680 +lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680 +lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations +lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels + +/etc/..2982_06_02_21_47_53.299460680: +total 8 +-rw-r--r-- ... Feb 6 21:47 annotations +-rw-r--r-- ... Feb 6 21:47 labels +``` + +심볼릭 링크를 사용하면 메타데이터의 동적(dynamic) 원자적(atomic) 갱신이 가능하다. +업데이트는 새 임시 디렉터리에 기록되고, `..data` 심볼릭 링크는 +[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)을 사용하여 +원자적(atomic)으로 갱신한다. + +{{< note >}} +다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath) +볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다. +{{< /note >}} + +셸을 종료한다. + +```shell +/# exit +``` + +## 컨테이너 필드 저장 + +이전 연습에서는 파드 필드를 DownwardAPIVolumeFile에 저장하였다. +이 다음 연습에서는 컨테이너 필드를 저장한다. 다음은 하나의 컨테이너를 가진 파드의 구성 파일이다. + +{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}} + +구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너는 `/etc/podinfo`에 볼륨을 +마운트하는 것을 확인할 수 있다. + +`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 DownwardAPIVolumeFile이다. + +첫 번째 요소는 `client-container`라는 컨테이너에서 +`1m`으로 지정된 형식의 `limits.cpu` 필드 값이 +`cpu_limit`이라는 파일에 저장되어야 함을 지정한다. `divisor` 필드는 선택 사항이며 +기본값인 `1`은 CPU에 대한 코어 및 메모리에 대한 바이트를 의미한다. + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml +``` + +파드에서 실행 중인 컨테이너의 셸을 가져온다. + +```shell +kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh +``` + +셸에서 `cpu_limit` 파일을 확인한다. + +```shell +/# cat /etc/podinfo/cpu_limit +``` +비슷한 명령을 통해 `cpu_request`, `mem_limit` 및 +`mem_request` 파일을 확인할 수 있다. + + + + + +## 다운워드 API의 기능 + +다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해 컨테이너에서 사용할 수 있다. + +* `fieldRef`를 통해 다음 정보를 사용할 수 있다. + * `metadata.name` - 파드의 이름 + * `metadata.namespace` - 파드의 네임스페이스(Namespace) + * `metadata.uid` - 파드의 UID + * `metadata.labels['']` - 파드의 레이블 `` 값 (예를 들어, `metadata.labels['mylabel']`) + * `metadata.annotations['']` - 파드의 어노테이션 `` 값 (예를 들어, `metadata.annotations['myannotation']`) +* `resourceFieldRef`를 통해 다음 정보를 사용할 수 있다. + * 컨테이너의 CPU 한도(limit) + * 컨테이너의 CPU 요청(request) + * 컨테이너의 메모리 한도(limit) + * 컨테이너의 메모리 요청(request) + * 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우) + * 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우) + * 컨테이너의 임시-스토리지 한도(limit) + * 컨테이너의 임시-스토리지 요청(request) + +`downwardAPI` 볼륨 `fieldRef`를 통해 다음 정보를 사용할 수 있다. + +* `metadata.labels` - 한 줄에 하나의 레이블이 있는 +`label-key="escaped-label-value"` 형식의 모든 파드 레이블 +* `metadata.annotations` - 한 줄에 하나의 어노테이션이 있는 `annotation-key="escaped-annotation-value"` 형식의 모든 파드 어노테이션 + +환경 변수를 통해 다음 정보를 사용할 수 있다. + +* `status.podIP` - 파드의 IP 주소 +* `spec.serviceAccountName` - 파드의 서비스 계정 이름, v1.4.0-alpha.3부터 사용 가능 +* `spec.nodeName` - 노드의 이름, v1.4.0-alpha.3부터 사용 가능 +* `status.hostIP` - 노드의 IP, v1.7.0-alpha.1 이후 사용 가능 + +{{< note >}} +컨테이너에 대해 CPU 및 메모리 한도(limit)가 지정되지 않은 경우 다운워드 API는 기본적으로 +CPU 및 메모리에 대해 할당 가능한 노드 값으로 설정한다. +{{< /note >}} + +## 특정 경로 및 파일 권한에 대한 프로젝트 키 + +키(key)를 파드 안의 특정 경로에, 특정 권한으로, 파일 단위로 투영(project)할 수 있다. +자세한 내용은 +[시크릿(Secrets)](/ko/docs/concepts/configuration/secret/)을 참조한다. + +## 다운워드 API에 대한 동기 + +컨테이너가 쿠버네티스에 과도하게 결합되지 않고 자체에 대한 정보를 갖는 것이 때때로 유용하다. +다운워드 API를 사용하면 컨테이너가 쿠버네티스 클라이언트 또는 API 서버를 사용하지 않고 +자체 또는 클러스터에 대한 정보를 사용할 수 있다. + +예를 들어 잘 알려진 특정 환경 변수에 고유 식별자가 있다고 가정하는 +기존 애플리케이션이 있다. 한 가지 가능성은 애플리케이션을 래핑하는 것이지만 +이는 지루하고 오류가 발생하기 쉬우며 낮은 결합 목표를 위반한다. +더 나은 옵션은 파드의 이름을 식별자로 사용하고 +파드의 이름을 잘 알려진 환경 변수에 삽입하는 것이다. + + + + +## {{% heading "whatsnext" %}} + + +* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) +* [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core) +* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core) +* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) + + + + + diff --git a/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md new file mode 100644 index 0000000000000..033e0afa79775 --- /dev/null +++ b/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md @@ -0,0 +1,157 @@ +--- +title: 환경 변수로 컨테이너에 파드 정보 노출하기 +content_type: task +weight: 30 +--- + + + +본 페이지는 파드에서 실행 중인 컨테이너에게 파드가 환경 변수를 사용해서 자신의 정보를 노출하는 방법에 +대해 설명한다. 환경 변수는 파드 필드와 컨테이너 필드를 노출할 수 있다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + + +## 다운워드(Downward) API + +파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다. + +* 환경 변수 +* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) + +파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다. + + +## 파드 필드를 환경 변수의 값으로 사용하자 + +이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다. 다음은 파드에 대한 구성 파일이다. + +{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}} + +구성 파일에서 5개의 환경 변수를 확인할 수 있다. `env` 필드는 +[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_NODE_NAME` 환경 변수가 파드의 `spec.nodeName` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 파드 필드에서 이름을 가져온다. + +{{< note >}} +이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다. +{{< /note >}} + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml +``` + +파드의 컨테이너가 실행중인지 확인한다. + +```shell +kubectl get pods +``` + +컨테이너의 로그를 본다. + +```shell +kubectl logs dapi-envars-fieldref +``` + +출력은 선택된 환경 변수의 값을 보여준다. + +``` +minikube +dapi-envars-fieldref +default +172.17.0.4 +default +``` + +이러한 값이 로그에 출력된 이유를 보려면 구성 파일의 `command` 및 `args` 필드를 확인하자. +컨테이너가 시작되면 5개의 환경 변수 값을 stdout에 쓰며 10초마다 이를 반복한다. + +다음으로 파드에서 실행 중인 컨테이너의 셸을 가져오자. + +```shell +kubectl exec -it dapi-envars-fieldref -- sh +``` + +셸에서 환경 변수를 보자. + +```shell +/# printenv +``` + +출력은 특정 환경 변수에 파드 필드 값이 할당되었음을 보여준다. + +``` +MY_POD_SERVICE_ACCOUNT=default +... +MY_POD_NAMESPACE=default +MY_POD_IP=172.17.0.4 +... +MY_NODE_NAME=minikube +... +MY_POD_NAME=dapi-envars-fieldref +``` + +## 컨테이너 필드를 환경 변수의 값으로 사용하기 + +이전 연습에서는 파드 필드를 환경 변수의 값으로 사용했다. 이 다음 연습에서는 컨테이너 필드를 +환경 변수의 값으로 사용한다. 다음은 하나의 컨테이너가 있는 파드의 구성 파일이다. + +{{< codenew file="pods/inject/dapi-envars-container.yaml" >}} + +구성 파일에서 4개의 환경 변수를 확인할 수 있다. `env` 필드는 +[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_CPU_REQUEST` 환경 변수가 `test-container`라는 컨테이너의 +`requests.cpu` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 컨테이너 필드에서 +값을 가져온다. + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml +``` + +파드의 컨테이너가 실행중인지 확인한다. + +```shell +kubectl get pods +``` + +컨테이너의 로그를 본다. + +```shell +kubectl logs dapi-envars-resourcefieldref +``` + +출력은 선택된 환경 변수의 값을 보여준다. + +``` +1 +1 +33554432 +67108864 +``` + + + +## {{% heading "whatsnext" %}} + + +* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/) +* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core) +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core) +* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core) +* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core) + + + diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 50a3a6ad2b2d1..a3575704ae39f 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -11,6 +11,8 @@ weight: 10 ## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} + ## 데몬셋 업데이트 전략 @@ -33,9 +35,11 @@ weight: 10 `.spec.updateStrategy.type` 에 `RollingUpdate` 를 설정해야 한다. [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable) -(기본값은 1)과 +(기본값은 1), [`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초) -(기본값은 0)으로 +(기본값은 0), +[`.spec.maxSurge`](/ko/docs/concepts/workloads/controllers/deployment/#최대-서지-max-surge) +(베타 기능, 기본값은 25%)를 설정할 수도 있다. ### `RollingUpdate` 업데이트 전략으로 데몬셋 생성 diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index 981efb6719a38..40ca1a8726780 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -113,9 +113,3 @@ spec: - 네임스페이스에서의 huge page 사용은 `hugepages-` 토큰을 사용하는 `cpu` 또는 `memory` 와 같은 다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수 있다. -- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다. - {{}} 및 - {{}} - (`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize` - [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 - 사용하여 비활성화할 수 있다. diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index 5a3fdc477e5df..97753165f12a4 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -16,7 +16,7 @@ content_type: task * 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.) -* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico) +* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예: Calico, Cilium 또는 Kubenet) * [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터 {{< version-check >}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 61f1dbc7583f2..a3c6285aac27a 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -183,7 +183,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. ```shell -kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml +kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml ``` 에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다. diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index b4cc1b3be5f5e..bc39ab4d9109f 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -1,4 +1,8 @@ --- + + + + title: Horizontal Pod Autoscaler feature: title: Horizontal 스케일링 @@ -9,10 +13,6 @@ content_type: concept weight: 90 --- - - - - Horizontal Pod Autoscaler는 CPU 사용량 @@ -181,6 +181,7 @@ HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한 API 오브젝트에 대한 자세한 내용은 [HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다. + ## kubectl에서 Horizontal Pod Autoscaler 지원 Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다. @@ -197,14 +198,17 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl` ## 롤링 업데이트 중 오토스케일링 -현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다. -Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고, -디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다. - -Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다. -즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`) -작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때, -Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다. +쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다. +이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다. +디플로이먼트에 오토스케일링을 설정하려면, +각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다. +HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다. +디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여 +롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다. + +오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면, +스테이트풀셋이 직접 파드의 숫자를 관리한다(즉, +레플리카셋과 같은 중간 리소스가 없다). ## 쿨-다운 / 지연에 대한 지원 diff --git a/content/ko/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ko/docs/tasks/run-application/run-stateless-application-deployment.md new file mode 100644 index 0000000000000..ea5bfd76af443 --- /dev/null +++ b/content/ko/docs/tasks/run-application/run-stateless-application-deployment.md @@ -0,0 +1,160 @@ +--- +title: 디플로이먼트(Deployment)로 스테이트리스 애플리케이션 실행하기 +min-kubernetes-server-version: v1.9 +content_type: tutorial +weight: 10 +--- + + + +이 페이지에서는 쿠버네티스 디플로이먼트 오브젝트를 사용하여 애플리케이션을 실행하는 방법을 설명한다. + + + + +## {{% heading "objectives" %}} + + +* nginx 디플로이먼트 생성하기 +* kubectl을 사용하여 디플로이먼트 정보 나열하기 +* 디플로이먼트 업데이트하기 + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + + +## nginx 디플로이먼트 생성하고 탐색하기 + +쿠버네티스 디플로이먼트 오브젝트를 생성하여 애플리케이션을 실행할 수 있으며, +디플로이먼트에 대한 명세를 YAML 파일에 기술할 수 있다. 예를 들어 이 YAML 파일은 +nginx:1.14.2 도커 이미지를 실행하는 디플로이먼트에 대한 명세를 담고 있다. + +{{< codenew file="application/deployment.yaml" >}} + + +1. YAML 파일을 기반으로 디플로이먼트를 생성한다. + + kubectl apply -f https://k8s.io/examples/application/deployment.yaml + +1. 디플로이먼트에 대한 정보를 살펴본다. + + kubectl describe deployment nginx-deployment + + 출력은 다음과 유사하다. + + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=1 + Selector: app=nginx + Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 1 max unavailable, 1 max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.14.2 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created) + No events. + +1. 디플로이먼트에 의해 생성된 파드를 나열한다. + + kubectl get pods -l app=nginx + + 출력은 다음과 유사하다. + + NAME READY STATUS RESTARTS AGE + nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h + nginx-deployment-1771418926-r18az 1/1 Running 0 16h + +1. 파드에 대한 정보를 살펴본다. + + kubectl describe pod + + ``은 파드 중 하나의 이름이다. + +## 디플로이먼트 업데이트하기 + +새 YAML 파일을 적용하여 디플로이먼트를 업데이트할 수 있다. 이 YAML 파일은 +nginx 1.16.1을 사용하도록 디플로이먼트를 업데이트해야 함을 명시하고 있다. + +{{< codenew file="application/deployment-update.yaml" >}} + +1. 새 YAML 파일을 적용한다. + + kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml + +1. 디플로이먼트가 새 이름으로 파드를 생성하고 이전 파드를 삭제하는 것을 확인한다. + + kubectl get pods -l app=nginx + +## 레플리카 수를 늘려 애플리케이션 확장하기 + +새 YAML 파일을 적용하여 디플로이먼트의 파드 수를 늘릴 수 있다. +이 YAML 파일은 `replicas`를 4로 설정하여 디플로이먼트에 +4개의 파드가 있어야 함을 명시하고 있다. + +{{< codenew file="application/deployment-scale.yaml" >}} + +1. 새 YAML 파일을 적용한다. + + kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml + +1. 디플로이먼트에 4개의 파드가 있는지 확인한다. + + kubectl get pods -l app=nginx + + 출력은 다음과 유사하다. + + NAME READY STATUS RESTARTS AGE + nginx-deployment-148880595-4zdqq 1/1 Running 0 25s + nginx-deployment-148880595-6zgi1 1/1 Running 0 25s + nginx-deployment-148880595-fxcez 1/1 Running 0 2m + nginx-deployment-148880595-rwovn 1/1 Running 0 2m + +## 디플로이먼트 삭제하기 + +이름으로 디플로이먼트를 삭제한다. + + kubectl delete deployment nginx-deployment + +## ReplicationControllers -- 예전 방식 + +애플리케이션을 복제하여 생성하는 기본적인 방법은 내부적으로 레플리카셋(ReplicaSet)을 활용하는 디플로이먼트를 +사용하는 것이다. 쿠버네티스에 디플로이먼트 및 레플리카셋이 도입되기 전에는 +[레플리케이션컨트롤러(ReplicationController)](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 사용하여 복제 애플리케이션을 +구성했었다. + + + + +## {{% heading "whatsnext" %}} + + +* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워보기 + + + + diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md index 90fefb0c3a518..cd03eb91b7385 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-macos.md +++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md @@ -228,7 +228,7 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력 1. kubectl-convert 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다. ```bash - sudo mv ./kubectl /usr/local/bin/kubectl-convert + sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert sudo chown root: /usr/local/bin/kubectl-convert ``` diff --git a/content/ko/docs/tasks/tools/install-kubectl-windows.md b/content/ko/docs/tasks/tools/install-kubectl-windows.md index bb5b45831e657..b05bd7ab021d1 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-windows.md +++ b/content/ko/docs/tasks/tools/install-kubectl-windows.md @@ -47,20 +47,20 @@ card: kubectl 바이너리를 체크섬 파일을 통해 검증한다. - - 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다. + - 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다. ```cmd CertUtil -hashfile kubectl.exe SHA256 type kubectl.exe.sha256 ``` - - `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다. + - PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다. ```powershell $($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256) ``` -1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다. +1. `PATH`로 설정된 디렉터리 중 하나에 kubectl 바이너리를 추가한다. 1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다. @@ -160,20 +160,20 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력 kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다. - - 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다. + - 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다. ```cmd CertUtil -hashfile kubectl-convert.exe SHA256 type kubectl-convert.exe.sha256 ``` - - `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다. + - PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다. ```powershell $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) ``` -1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다. +1. `PATH`로 설정된 디렉터리 중 하나에 kubectl-convert 바이너리를 추가한다. 1. 플러그인이 정상적으로 설치되었는지 확인한다. diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 43b07e293bcde..7b11ea772249e 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -348,6 +348,11 @@ Events: ### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy} +{{< note >}} +PodSecurityPolicy는 쿠버네티스 v1.21에서 사용 중지되었으며, v1.25에서 제거될 예정이다. +더 자세한 내용은 [PodSecurityPolicy 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다. +{{< /note >}} + 만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다. PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다. diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index fcad9b42b3ae8..7c66225037dfa 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -26,7 +26,7 @@
홈으로 이동 - 모듈 2로 진행하기 > + 모듈 2로 진행하기 >
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index ce5be2cfc09ca..d5aca028e7404 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -37,9 +37,9 @@
- < 모듈 1로 돌아가기 + < 모듈 1로 돌아가기 홈으로 이동 - 모듈 3으로 진행하기 > + 모듈 3으로 진행하기 >
diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index e3b67a1daeab0..d467fc9b2c9a1 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -29,9 +29,9 @@
- < 모듈 2로 돌아가기 + < 모듈 2로 돌아가기 홈으로 이동 - 모듈 4로 진행하기 > + 모듈 4로 진행하기 >
diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index 09dde78cb88a3..fa68a4c40e816 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -26,9 +26,9 @@
- < 모듈 3으로 돌아가기 + < 모듈 3으로 돌아가기 홈으로 이동 - 모듈 5로 진행하기 > + 모듈 5로 진행하기 >
diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html index aac6298a7add5..8dbfde0c63170 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -37,7 +37,7 @@

쿠버네티스 서비스들에 대한 개요

  • ClusterIP (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.
  • NodePort - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <NodeIP>:<NodePort>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.
  • LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
    • -
  • ExternalName - CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, `foo.bar.example.com`)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.
    • +
  • ExternalName - CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, foo.bar.example.com)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.

    • 다른 서비스 타입들에 대한 추가 정보는 소스 IP 이용하기 튜토리얼에서 확인 가능하다. 또한 서비스들로 애플리케이션에 접속하기도 참고해 보자.

    부가적으로, spec에 selector를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. selector 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 type: ExternalName을 이용하겠다고 확고하게 의도하는 경우이다.

    diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index 22b5d41342939..18a371fff2915 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -26,9 +26,9 @@
    - < 모듈 4로 돌아가기 + < 모듈 4로 돌아가기 홈으로 이동 - 모듈 6으로 진행하기 > + 모듈 6으로 진행하기 >
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html index 4038e3b35890a..0f25073ca3d3b 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -26,7 +26,7 @@
    - < 모듈 5로 돌아가기 + < 모듈 5로 돌아가기 쿠버네티스 기초로 돌아가기
    diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index ee7cccb70da92..b879049c55846 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -20,7 +20,7 @@ weight: 10 * [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/) * [헤드리스 서비스(Headless Services)](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) * [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/) -* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +* [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) * [kubectl](/ko/docs/reference/kubectl/kubectl/) 커맨드 라인 도구 diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 3ebb7ec3874c6..4e82a6d07fb8f 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -50,7 +50,7 @@ weight: 30 ### 추가적인 Minikube 설정 요령 {{< caution >}} -[Minikube](https://minikube.sigs.k8s.io/docs/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. +[Minikube](https://minikube.sigs.k8s.io/docs/)는 2048MB 메모리와 2개 CPU가 기본 설정이다. 이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 3fca0a6749a4e..839f7dc7b421f 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -19,7 +19,7 @@ weight: 40 - [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) - [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) - [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/) -- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) - [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) - [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets) - [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) @@ -929,7 +929,7 @@ kubernetes-node-i4c4 [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)를 이용하자. ```shell -kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` ``` @@ -964,7 +964,7 @@ zk-0 1/1 Running 0 1m `zk-1` 이 스케줄된 노드를 비워보자. ```shell -kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned +kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned ``` ``` @@ -1007,7 +1007,7 @@ zk-1 0/1 Pending 0 0s `zk-2`가 스케줄된 노드를 비워보자. ```shell -kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` ``` @@ -1094,7 +1094,7 @@ zk-1 1/1 Running 0 13m `zk-2`가 스케줄된 노드를 비워보자. ```shell -kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` 출력은 diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 1a5e4a60797da..9f6481396e889 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -19,7 +19,7 @@ _(운영 수준이 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고 이 예제는 다음과 같은 구성으로 이루어져 있다. -* 방명록 항목을 저장하기 위한 단일 인스턴스 [Redis](https://www.redis.com/) +* 방명록 항목을 저장하기 위한 단일 인스턴스 [Redis](https://www.redis.io/) * 여러 개의 웹 프론트엔드 인스턴스 ## {{% heading "objectives" %}} diff --git a/content/ko/examples/application/deployment-scale.yaml b/content/ko/examples/application/deployment-scale.yaml new file mode 100644 index 0000000000000..01fe96d84565e --- /dev/null +++ b/content/ko/examples/application/deployment-scale.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 4 # Update the replicas from 2 to 4 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/ko/examples/application/deployment-update.yaml b/content/ko/examples/application/deployment-update.yaml new file mode 100644 index 0000000000000..1c0b9d1ab8a4f --- /dev/null +++ b/content/ko/examples/application/deployment-update.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.16.1 # Update the version of nginx from 1.14.2 to 1.16.1 + ports: + - containerPort: 80 diff --git a/content/ko/examples/pods/inject/dapi-envars-container.yaml b/content/ko/examples/pods/inject/dapi-envars-container.yaml new file mode 100644 index 0000000000000..55bd4dd263a00 --- /dev/null +++ b/content/ko/examples/pods/inject/dapi-envars-container.yaml @@ -0,0 +1,45 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-envars-resourcefieldref +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox:1.24 + command: [ "sh", "-c"] + args: + - while true; do + echo -en '\n'; + printenv MY_CPU_REQUEST MY_CPU_LIMIT; + printenv MY_MEM_REQUEST MY_MEM_LIMIT; + sleep 10; + done; + resources: + requests: + memory: "32Mi" + cpu: "125m" + limits: + memory: "64Mi" + cpu: "250m" + env: + - name: MY_CPU_REQUEST + valueFrom: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + - name: MY_CPU_LIMIT + valueFrom: + resourceFieldRef: + containerName: test-container + resource: limits.cpu + - name: MY_MEM_REQUEST + valueFrom: + resourceFieldRef: + containerName: test-container + resource: requests.memory + - name: MY_MEM_LIMIT + valueFrom: + resourceFieldRef: + containerName: test-container + resource: limits.memory + restartPolicy: Never diff --git a/content/ko/examples/pods/inject/dapi-envars-pod.yaml b/content/ko/examples/pods/inject/dapi-envars-pod.yaml new file mode 100644 index 0000000000000..071fa82bb3b26 --- /dev/null +++ b/content/ko/examples/pods/inject/dapi-envars-pod.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-envars-fieldref +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "sh", "-c"] + args: + - while true; do + echo -en '\n'; + printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE; + printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT; + sleep 10; + done; + env: + - name: MY_NODE_NAME + valueFrom: + fieldRef: + fieldPath: spec.nodeName + - name: MY_POD_NAME + valueFrom: + fieldRef: + fieldPath: metadata.name + - name: MY_POD_NAMESPACE + valueFrom: + fieldRef: + fieldPath: metadata.namespace + - name: MY_POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP + - name: MY_POD_SERVICE_ACCOUNT + valueFrom: + fieldRef: + fieldPath: spec.serviceAccountName + restartPolicy: Never diff --git a/content/ko/examples/pods/inject/dapi-volume-resources.yaml b/content/ko/examples/pods/inject/dapi-volume-resources.yaml new file mode 100644 index 0000000000000..ecb231e0cf96c --- /dev/null +++ b/content/ko/examples/pods/inject/dapi-volume-resources.yaml @@ -0,0 +1,57 @@ +apiVersion: v1 +kind: Pod +metadata: + name: kubernetes-downwardapi-volume-example-2 +spec: + containers: + - name: client-container + image: k8s.gcr.io/busybox:1.24 + command: ["sh", "-c"] + args: + - while true; do + echo -en '\n'; + if [[ -e /etc/podinfo/cpu_limit ]]; then + echo -en '\n'; cat /etc/podinfo/cpu_limit; fi; + if [[ -e /etc/podinfo/cpu_request ]]; then + echo -en '\n'; cat /etc/podinfo/cpu_request; fi; + if [[ -e /etc/podinfo/mem_limit ]]; then + echo -en '\n'; cat /etc/podinfo/mem_limit; fi; + if [[ -e /etc/podinfo/mem_request ]]; then + echo -en '\n'; cat /etc/podinfo/mem_request; fi; + sleep 5; + done; + resources: + requests: + memory: "32Mi" + cpu: "125m" + limits: + memory: "64Mi" + cpu: "250m" + volumeMounts: + - name: podinfo + mountPath: /etc/podinfo + volumes: + - name: podinfo + downwardAPI: + items: + - path: "cpu_limit" + resourceFieldRef: + containerName: client-container + resource: limits.cpu + divisor: 1m + - path: "cpu_request" + resourceFieldRef: + containerName: client-container + resource: requests.cpu + divisor: 1m + - path: "mem_limit" + resourceFieldRef: + containerName: client-container + resource: limits.memory + divisor: 1Mi + - path: "mem_request" + resourceFieldRef: + containerName: client-container + resource: requests.memory + divisor: 1Mi + diff --git a/content/ko/examples/pods/inject/dapi-volume.yaml b/content/ko/examples/pods/inject/dapi-volume.yaml new file mode 100644 index 0000000000000..0f0a9f2e5cc06 --- /dev/null +++ b/content/ko/examples/pods/inject/dapi-volume.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: kubernetes-downwardapi-volume-example + labels: + zone: us-est-coast + cluster: test-cluster1 + rack: rack-22 + annotations: + build: two + builder: john-doe +spec: + containers: + - name: client-container + image: k8s.gcr.io/busybox + command: ["sh", "-c"] + args: + - while true; do + if [[ -e /etc/podinfo/labels ]]; then + echo -en '\n\n'; cat /etc/podinfo/labels; fi; + if [[ -e /etc/podinfo/annotations ]]; then + echo -en '\n\n'; cat /etc/podinfo/annotations; fi; + sleep 5; + done; + volumeMounts: + - name: podinfo + mountPath: /etc/podinfo + volumes: + - name: podinfo + downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "annotations" + fieldRef: + fieldPath: metadata.annotations + diff --git a/content/ko/examples/pods/inject/dependent-envars.yaml b/content/ko/examples/pods/inject/dependent-envars.yaml new file mode 100644 index 0000000000000..2509c6f47b56d --- /dev/null +++ b/content/ko/examples/pods/inject/dependent-envars.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dependent-envars-demo +spec: + containers: + - name: dependent-envars-demo + args: + - while true; do echo -en '\n'; printf UNCHANGED_REFERENCE=$UNCHANGED_REFERENCE'\n'; printf SERVICE_ADDRESS=$SERVICE_ADDRESS'\n';printf ESCAPED_REFERENCE=$ESCAPED_REFERENCE'\n'; sleep 30; done; + command: + - sh + - -c + image: busybox + env: + - name: SERVICE_PORT + value: "80" + - name: SERVICE_IP + value: "172.17.0.1" + - name: UNCHANGED_REFERENCE + value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)" + - name: PROTOCOL + value: "https" + - name: SERVICE_ADDRESS + value: "$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)" + - name: ESCAPED_REFERENCE + value: "$$(PROTOCOL)://$(SERVICE_IP):$(SERVICE_PORT)" diff --git a/content/ko/examples/pods/inject/pod-multiple-secret-env-variable.yaml b/content/ko/examples/pods/inject/pod-multiple-secret-env-variable.yaml new file mode 100644 index 0000000000000..f285e4193262c --- /dev/null +++ b/content/ko/examples/pods/inject/pod-multiple-secret-env-variable.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envvars-multiple-secrets +spec: + containers: + - name: envars-test-container + image: nginx + env: + - name: BACKEND_USERNAME + valueFrom: + secretKeyRef: + name: backend-user + key: backend-username + - name: DB_USERNAME + valueFrom: + secretKeyRef: + name: db-user + key: db-username diff --git a/content/ko/examples/pods/inject/pod-secret-envFrom.yaml b/content/ko/examples/pods/inject/pod-secret-envFrom.yaml new file mode 100644 index 0000000000000..eb1d3213efe34 --- /dev/null +++ b/content/ko/examples/pods/inject/pod-secret-envFrom.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envfrom-secret +spec: + containers: + - name: envars-test-container + image: nginx + envFrom: + - secretRef: + name: test-secret diff --git a/content/ko/examples/pods/inject/pod-single-secret-env-variable.yaml b/content/ko/examples/pods/inject/pod-single-secret-env-variable.yaml new file mode 100644 index 0000000000000..af4cf8732fe38 --- /dev/null +++ b/content/ko/examples/pods/inject/pod-single-secret-env-variable.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: env-single-secret +spec: + containers: + - name: envars-test-container + image: nginx + env: + - name: SECRET_USERNAME + valueFrom: + secretKeyRef: + name: backend-user + key: backend-username diff --git a/content/ko/examples/pods/inject/secret-pod.yaml b/content/ko/examples/pods/inject/secret-pod.yaml new file mode 100644 index 0000000000000..8be694cddee0d --- /dev/null +++ b/content/ko/examples/pods/inject/secret-pod.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: secret-test-pod +spec: + containers: + - name: test-container + image: nginx + volumeMounts: + # name must match the volume name below + - name: secret-volume + mountPath: /etc/secret-volume + # The secret data is exposed to Containers in the Pod through a Volume. + volumes: + - name: secret-volume + secret: + secretName: test-secret diff --git a/content/ko/examples/pods/inject/secret.yaml b/content/ko/examples/pods/inject/secret.yaml new file mode 100644 index 0000000000000..706ca8670fa8d --- /dev/null +++ b/content/ko/examples/pods/inject/secret.yaml @@ -0,0 +1,7 @@ +apiVersion: v1 +kind: Secret +metadata: + name: test-secret +data: + username: bXktYXBw + password: Mzk1MjgkdmRnN0pi